BlackBerry BlackBerry Java Application performance optimization, tips

1. BlackBerry Object handler to be sufficient

Programs cannot consume too many object handles

2. Or the BlackBerry object Handler, in Persistant store persistent object handles is also limited, to save the use

Reference: Performance of the persistent store

(BlackBerry manuals & Help > documentation for developers > Java Development Guides and API Reference > D ATA storage-development guide-blackberry Java SDK-7.0 > performance of the Persistent store)

3. program main thread UI event handling and other processing (network access, CPU and resource processing) separate

4.TCP network request, sleep is recommended after an error (100 milliseconds) and then go to the next loop, empty a bit of CPU fragments to other applications, don't take up the manger.

5.TCP network server returns data to the BlackBerry the last thing to do flush action, otherwise the BlackBerry will wait for a timeout, time-consuming

6.SYSTEM.GC () garbage collection

Reference 1:displaying System busy icon

The effect is that if you find a BlackBerry running your program appears in the funnel, it is estimated that your program generated memory garbage, memory fragmentation, etc., requires the BlackBerry operating system to organize the memory.

and BlackBerry memory sorting is very time-consuming.

Note the log details in reference 1:

VM:+GC (F) w=6

Indicates that the BlackBerry OS is doing GC garbage collection.

Precautions:

Looks like you are creating excess garbage. The system GC would kick in when memory becomes constrained, whether you called it or not.
Some things for:
* String concantenation, expecially within a for...next loop.
* Unnec. Use of enumerations
* Keeping references to objects this are no longer needed (set them to null)

There is a heirarchy to garbage collection on the BB. It goes something like this:
#1-ram Collection of unused objects: < ~500 ms
#2-collection of unused objects in object cache (Flash): ~1,000 MS, then repeat #1
#3-collection of Unsued objects in store: ~2,000 MS, then repeat #2

Reference 2:blackberry:taking out the Trash:garbage Collection (> Developers _ > Resource > Developer journals > January 2005)
Reference 3:blackberry J2ME calling System.GC ()

7: Google search: BlackBerry Best Practices site:docs.blackberry.com

Best Practice:writing Efficient Code (5.0)

Best practice:writing Efficient Code (4.6)

8. General Java Memory Usage issues

Strings are used, objects that are no longer used are set to null, reusing objects as much as possible rather than repeatedly generating and discarding large numbers of small objects.

9. J2ME Performance Optimization: Mobile network environment Readbuffer use read buffer to do performance optimization, if not take into account the instability of the mobile network, it is likely to cause the program instability, the results of the operation is puzzling.
by Keyboardota

J2ME Performance Optimization: program development to pay attention to the effect of function calls on performance 2006/10/22 20:34 before the time, because I have the Java EE development experience, the boss arranged me to write a mobile phone mobile monitoring program based on J2ME development. Get the job, buy a book, and start doing it. In the development of Java-EE experience, pay more attention to the division of the program structure and level, as far as possible to reduce the coupling between the modules, the program quickly developed, but in the test process, always than the original use of C language mobile video surveillance program to monitor the efficiency of a lot of difference, Although Java is a little less efficient, it's not so much lower. Browsing the performance of the video module is critical, and it takes three steps to display a frame to the phone screen: 1, the frame parsing, must first the network receives the data to carry on the analysis, passes the complete one frame the data to decode the decoding module, 2, decodes the MPEG4 video frame into the YUV format video frame; 3, Converts the video frame YUV format to RGB format. Since the decoder library was developed by another developer, I do not have the source code, only starting from the first and third steps to optimize.
At first, I've been concentrating on improving the processing logic, minimize the processing path, but the effect received is not obvious, basically negligible; I also understand that calling a function can cause a decrease in efficiency, but I've always thought that the efficiency of this loss should be very low and negligible, so there is no undue concern, Until one day with the department manager, he let me try to the YUV to RGB code function calls are written together, did not think after such a change, performance improvement, from the original each frame of YUV to RGB need to take more than 200 ms down to 50 ms, let me surprise.
Therefore, in the J2ME development, if in some real-time requirements of the module, try to avoid function calls, you can sacrifice the readability of the code in exchange for a shorter run time.

Resources:

How do I find that memory leak! ( Part One) How do I find this Memory leak (Part Two): Detecting the leak How do I find this Memory leak (part Three): Why A Object is leaking into Memory

10.28.09 Kamen V.

Last Updated: 2011.12.29