Symbian OS C ++ programmer coding tips-use of system resources (ROM and RAM ))

Source: Nokia Forum

Importance

A mobile phone is a device with limited resources. However, it has a lot of available functions, which puts forward high requirements on existing system resources. Developers need to pay attention to these constraints and use these limited resources as little as possible.

DecreaseCodeQuantity

The final compiled code must be as small as possible to leave as much available space as possible for the device, which is very important. The following tips provide some guiding opinions on how to ensure that the storage space is not wasted. To solve this problem, you need to spend some time checking the code and consider other methods to reduce the amount of compiled code.

Unnecessary export functions

When import_c and export_c are used to export some functions from a DLL, they consume space because of the export table. You only need to export the functions that must be used outside the DLL.

Copy and paste

Copying and pasting often results in code bloated. When you need to reuse the code in other modules, ask yourself the following questions:

1. Is this Code actually required?

2. Have you copied too much code for this task?

3. Is it better to extract the function to a base class or to a help module so that it can be used in more than one place?

4. Can the code be rewritten for the required task to make it more effective, rather than copying something close to the requirement?

Unrecoverable Functions

In many places, some functions appear in the same class, and these functions implement very similar tasks. It is often the case that the public code can be extracted to a single function, and the function can be parameterized to complete different tasks.

Excessive trap Module

When compilation errors capture code modules, they consume memory space. Code containing many trap macros (for example, containing more than five trap Macros in a class) consumes too much space. Another possible scenario is: Incorrect Design, making the trap module not widely used in normal code. Here, we allow special error handling and recovery in advanced development.Program.

Debug release code

If any code is used for logon, debugging, or testing, it must be removed from the release. You can use the Compilation instruction # ifdef_debug for this purpose.

Unnecessary virtual functions

Unnecessary virtual functions are harmful because they are similar to function export. They create additional vtable functions.

Use public controls

If possible, use the framework controls provided by the system (or other shared DLL) instead of developing new controls.

_ L misuse of macros

We do not recommend that you use a macro with letters _ L. Instead, we recommend you use a more efficient _ character macro.

Reduce RAM usage

There are many ways to reduce the use of RAM. Some of these methods (such as bitfields) may make the code less readable, so it is often necessary to compromise between reducing RAM usage and increasing Code complexity.

Bitfields is used instead of too many tbools. bitfields is used to store a large amount of boolean data in the class. Each tbool requires 32-bit ram, and the 32-bit can save 32 boolean values in the form of a bitwise meta combination. As mentioned above, we can compare the benefits of improving Code complexity and using bitfields.

Array granularity usage warning

The granularity can be defined for all classes inherited from carray. The purpose is to allocate space for arrays only with blocks of a certain size to make the code more efficient. This method is very effective, but the issue of granularity selection needs to be considered. If you need to prepare an array of 5 to 8 objects, it is wise to set the granularity to 4 to 5. If an array always contains 15 objects, the granularity should be set to 15. However, if the number of objects is two to three, it would be silly to set the granularity to 100. Similarly, if there are 101 to 105 objects, it would be silly to have a granularity of 100, because 200 space needs to be allocated each time. Of course, the granularity of 1 is also irrational, because it will need to be re-allocated too many times. The final choice depends on the usage method.

Avoid global data

Do not use global data. For variables used only in a function, use local variables instead of member variables.

Be careful with the member data of the base class

If you want to write a base class that is widely used, be careful with the member data. Do not add member data that is only used for some inheritance classes, because each inheritance class has no choice but to own it. Note that only common member functions are included.

Correct use of clear Stack

If you use the clear stack correctly, there should be no memory leakage in the Code, so that the application does not use more than the required Ram.

Delete as soon as possible

If temporary objects are assigned to the heap, delete them immediately if they are no longer needed. If the life of these temporary objects is longer than the time required, the RAM overhead of the application is usually higher than the actual needs. Remember, if a temporary object is deleted and the pointer to this object is still present, you need to set this pointer to null to prevent unauthorized access or deletion.

Hardware testing with the largest Dataset

If a dataset has an upper limit, the maximum dataset is used for hardware testing. If you have never performed a limit test on the hardware, it is very likely that some very slow operations will be ignored, or cause problems.

3.3.8 splitting complex long run computing. displaying a lengthy list on the screen puts pressure on RAM usage. In addition, the list controls (such as the list of all contacts on the device, or the note list) are poorly initialized. You can write special controls to avoid this situation. These controls only assemble visible columns on the screen. When scrolling, release those columns that have left the screen area and add new columns.

The stack available for an application on the target hardware is much smaller than the huge stack available for simulators in the Windows NT environment. The result is that codes that run well in the WINS simulator cannot run in the hardware, and serious random prompts (panic) appear ). It is not easy to reduce stack usage, but it still requires close attention.
Use descriptor correctly

two types of descriptors are available: heap Descriptor (hbufc) and stack Descriptor (hbufc ). All descriptors are stored using one of them. When the stack overflows, the 90% time is caused by the large descriptor in the stack. Take care of the operations that will cause the implicit replication Descriptor and avoid this situation as much as possible. In some cases, it is best to allocate hbuf c s instead of tbufs. Some related Symbian OS classes, such as tparse, can overhead many stack spaces. You can consider using versions that consume less stack space (such as tparsebase ).
it is better to pass parameters to descriptors than to pass values.

use recursion with caution and generate within the limit
If recursive Programs are required, pay attention to stack requirements. Efforts should be made to reduce the size of the downstream parameter and try to remove the local automatic variable from the recursive part of the function. Generate (build) code within the recursion limit depth as much as possible to avoid stack overflow.
pay attention to the logon Code
the logon Code usually involves formatting the long Descriptor and writing it into a file. For this reason, they are often the cause of stack overflow.
processing of disk capacity reduction
for flash file systems (the alias of FLASH file system and FFS is C: Drive) for free space monitoring systems, we define two levels: Warning Level (WL) and critical level (critical level, Cl ). When a free disk space encounters one of these levels, the system (eiksrvui) displays a global prompt to warn users about the current situation. Since then, various applications and servers have ignored the warning level and focused on the critical level. All operations on creating or writing disk files with known file sizes must first use that size as the ffsspacebelowcriticallevell parameter to check the critical level. If the disk space is already very low, or is already below the critical level, this method will return etrue. The application can no longer write data and notify the user that the disk is full. (This can be achieved by using the kerrdiskfull error code for abnormal exit .)

all operations on creating or writing a disk file in an unknown file size must first check the critical level, pass an appropriate estimated size or '0' (default) to the ffsspacebelowcriticallevell method as the parameter. Here '0' can be used to check whether it is already below the critical level. It is troublesome to create a single project in several databases (such as contacts. In these cases, you can use an estimate as the size increment of the database required to add the project. Sysutil. h/sysutil. dll has a critical check method. Its API looks like this:

/*** checks if the free FFs (Internal flash file system) Storage
* space is or will fall below critical level (CL ).
* the CL and FFS drive letter is defined by this module.
* @ Param AFS File Server session.
* must be given if available in the caller,
* e.g. from Eikon environment.
* If null this method will create a temporary session for
* a check, but then the check is more expensive.
* @ Param abytestowrite number of bytes the caller is about to add
* FFs, if known by the caller beforehand.
* the default value 0 checks if the current
* space is already below the Cl.
* @ return etrue if storage space wocould go below Cl after adding
* abytes more data, efalse otherwise.
* Leaves on error.
*/
import_c static tbool ffsspacebelowcriticallevell
(RFS * AFS, tint abytestowrite = 0);