黑莓手机BlackBerry Java应用性能优化，tips

1. BlackBerry Object Handler要够用

程序不能消耗太多的对象句柄

2. 还是BlackBerry Object Handler，在Persistant Store的persistent object handles也是有限的，要节约使用

参考：Performance of the persistent store

（BlackBerry Manuals & Help > Documentation for Developers >Java Development Guides and API Reference> Data Storage - Development Guide - BlackBerry Java SDK - 7.0 >Performance of the persistent store）

3. 程序main thread的UI事件处理和其他处理（网络访问等耗CPU和资源的处理）分开

4.TCP网络请求中，出错后建议sleep(100毫秒)再进入下一个循环，空出一点CPU片段给其他应用，不要占着茅坑

5.TCP网络服务器返回数据给BlackBerry的最后要做flush动作，否则BlackBerry会等待超时，耗费很多时间

6.System.gc() 垃圾回收

参考1：displaying System busy icon

大意是说如果发现黑莓手机运行你的程序出现漏斗，估计是你的程序产生内存垃圾，内存碎片等，需要黑莓手机操作系统对内存进行整理。

而黑莓的内存整理是非常耗时的。

注意参考1中的日志细节：

VM:+GC(F)w=6

表明BlackBerry OS在做GC垃圾回收。

注意事项：

Looks like you are creating excess garbage. The system GC will kick in when memory becomes constrained, whether you called it or not.
Some things to look for:
* string concantenation, expecially within a for...next loop.
* unnec. use of Enumerations
* keeping references to objects that 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

参考2：BlackBerry: Taking Out the Trash: Garbage Collection (>Developers _>Resources>Developer Journals>January 2005)
参考3：BlackBerry J2ME calling system.gc()

7: 谷歌搜索：blackberry Best Practices site:docs.blackberry.com

Best practice: Writing efficient code （5.0）

Best practice: Writing efficient code（4.6）

8. 一般性的Java内存使用问题

字符串使用，不再使用的对象句置null，尽量重用对象而不是反复生成并丢弃大量的小对象。

9. J2ME性能优化：移动网络环境下ReadBuffer的使用

网络IO时候使用read buffer做性能优化，如果没有考虑到移动网络的不稳定性，很可能造成程序不稳定，运行结果令人费解。
by keyboardota

10. J2ME性能优化：程序开发要注意函数调用对性能的影响

2006/10/22 20:34

前段时间，由于我以前有J2EE的开发经验，老大安排我去写一个基于J2ME开发的手机移动监控程序。领到任务，买了本书看看就开始动手，本着J2EE的开发经验，比较注重程序结构和层次的划分，尽量降低模块间的耦合程度，程序很快就开发出来，但在测试过程当中，总是比原来使用C语言写的手机移动视频监控程序的效率要差很多，虽然Java的效率低一点正常，但还不至于低这么多的吧？浏览视频模块的性能是关键，要通过三个步骤才能够把一帧画面显示到手机屏幕上：1、帧解析，必须首先把网络接收到的数据进行分析，把完整一帧的数据传递给解码模块进行解码；2、把MPEG4的视频帧解码为YUV格式的视频帧；3、把视频帧YUV格式转换为RGB格式。由于解码库是另外的开发人员开发的，我没有源代码，只有从第一步和第三步着手进行优化。
刚开始，我一直集中精力在改进处理逻辑上，尽量减少处理路径，但这种做法收到的效果很不明显，基本上可以忽略不计；我也明白调用函数会引起效率的降低，但我一直以为这个损失的效率应该是很低的，也可以忽略不计，所以就没有过多的关注，直到有一天跟部门经理讨论时，他让我试把YUV to RGB的代码的函数调用都写在一起，没想到经过这么一改，性能提高不少，从原来每一帧的YUV to RGB需要耗时200多ms降为50多ms，让我大吃一惊。
因此，在J2ME开发中，如果在一些实时性要求很强的模块，尽量避免函数的调用，可以牺牲代码的可读性来换取更短的运行时间。

参考资料：

How to find that memory leak! (PartOne)

How To Find That Memory Leak (Part Two): Detecting TheLeak

How To Find That Memory Leak (Part Three): Why An Object is Leaking IntoMemory

10.28.09 Kamen V.

最后更新：2011.12.29