J2me性能优化，避免内存储器溢出小结
日期：2014-05-20 浏览次数：20671 次
J2me性能优化，避免内存溢出小结
最近在做一个手机浏览器的客户端，最初以为一个浏览器的客户端不用考虑太多的内存使用，结果做完才发现在高端的手机上运行没有任何问题，在低端的手机上不是响应速度过慢，就是内存溢出。所以就开始对代码进行优化，在这个过程总结一些自己的经验，希望对有困惑的朋友有所帮助，有好的办法也希望大家共同探讨，zxhwolfe@hotmail.com
以下内容有些是自己实践所得，有些是参考高人经验或书本上的经验，如有不正确请立即指正；如果侵犯了他人版权请高台贵手，借鉴您的经验不是用于商业，只是希望大家共同进步请不要追究呵呵。
在写程序初期由于是面向midp2.0的手机而且不是游戏的开发，所以没有对性能方面做太多的考虑，大胆的使用了很多vector数组（使用起来方便：））等等，而且程序写的也是随心所欲，似乎不是在手机上开发j2me的东西。结果让我大跌眼镜，没办法只能重新优化，这期间可想而知浪费了很多时间，也使开发效率降低到了最低。说到这，只有一句话奉劝大家，不管你是开发什么样手机程序，一定要把性能放在第一位，不要重蹈我的覆辙。
我的几个vector存放的是链接的内容，文本框的内容，图片的内容和普通文本的内容，每个vector中包含的其他信息还有它所占的行数，它的位置和它的标志。我用线程控制paint（只要目的是实现持续按键的机制），这样的话，每次重绘都要把所有内容重新画到屏幕上，而且还要对当前焦点进行重绘。在重绘的过程中每一次都要遍历一遍几乎所有的vector然后重绘，这样肯定是浪费资源。结果也一样，在稍微低端一点手机上响应明显的慢。优化这样程序，我首先想到的就是把vector用别的方法替换掉，正常的性能使用是字符串-〉一维数组-〉二维数组->vector。一维数组肯定是替代不了我的vector了，那只能是使用二维数组了。费了好大劲把vector转换位二维数组，发现性能上并没有提升多少。大概只节省了20k左右的内存，只能再想别的办法。这里简单说下在手机上获得当前内存和剩余内存的方式：
long tempMin = 1000000；
long temp = Runtime.getRuntime().freeMemory();
if (tempMin > temp) {
tempMin = temp;
}
g.drawString("total = " + Runtime.getRuntime().totalMemory(), 10, 10, 0);
g.drawString("frees = " + temp, 10, 10 + lineHeight, 0);
g.drawString("hiegh = " + tempMin, 10, 10 + 2 * lineHeight, 0);
把这些东西画到你的画布上，在真机上运行的时候方便你查看内存的使用率。（每种机器的内存最大值是不同的）。
而且可以查看内存峰值。当然你也可以使用wtk自带的内存和方法查看器来判断。相关内容参考我的另外2篇文章：
J2ME性能优化之--方法和内存的评测：
/Article/Class2/200603/1650.html
J2ME性能优化之—优化方法探讨：
/Article/Class2/200603/1658.html
既然转换vector不能解决问题，那就继续优化。内存的主要使用看来是在每次重画的时候产生的，这样就要减少每次重画的内容，我采取的方式是把所有固定要重画的东西用双缓冲的方式画到一张图片上，这样只有初始化的时候才去遍历数组，经过一次的遍历把所有内容画到一张图片上，然后每一次的重画都是在重画一张图片。经过这样的处理性能上有了很大的提升。高兴还为时尚早，nokia的低端机器没有问题了，结果在moto的机器上出了问题，根本就不能初始化，也就是说创建那张图片的时候就应用程序错误了。继续查找原因，结果发现是因为moto的机器不支持创建一张那么大图片。也就是说你创建一张大图的时候，在moto的机器上根本就不能申请到内存。找到原因后，把大图分割为两个比较小的图，ok没有问题了。当然至于moto支持创建多大的图片可能每种机器不同吧，只能在需要的时候自己测试了。对于浏览器，一张分割为两张需要做些代码的处理。实际上为了性能的更加优化可以把一张大图分割为多张小图，每张小图的大小可以根据屏幕的几倍大小确定也可以根据机型固定。初始化的时候也可以先初始化一部分图。因人而异。
至此，程序的主要瓶颈已经找到，并且解决。正应了一句话，程序是花80%的时间在执行20%的代码。也就是说我们要把主要精力放在那20%的代码的优化上，但实际中我发现对另外80%代码的优化也很重要，主要是一些编程细节上的处理。在细节的代码书写上多注意些也有利于程序性能的提升。关于细节上觉得以下几个方面对程序性能的提升很有帮助。
首先系统垃圾回收的利用：关于堆内存（heap）与栈内存（stack）我们知道，heap存放的是对象实例与变量；而stack存放的是静态方法。堆内存在JVM启动的时候被创建，堆内存中所存储的对象可以被JVM自动回收。在这里，要手动把不用对象置为null，特别是较大的对象，如果不用一定要记得置为空。比如说较大的数组，vector或者是image对象。（切忌）在这里，浏览器中页面图片的读取我是采用的是后台读取，即先显示文字部分，而后后台读取页面中的图片，读取完成后再一起重新显示。重新显示的时候要重新构建那个双缓冲图片，而我当时就忘记了把原来创建的那个双缓冲图片置为null了，走了很多弯路才解决问题。所以要切忌至少把大的对象置空，不要指望垃圾回收。
其次是static的使用：静态变量在程序运行期间内存空间对所有该类的对象实例而言是共享的，即只在内存中保存一份拷贝，这样节约了不比要的内存开销。但是static生命周期较长，而且不容易被垃圾回收机制所回收，所以要合理运用，不要适得其反。建议在全部具备下列条件的情况下尽量使用静态变量：
1），变量所包含的对象体积较大，占用内存较多。
2），变量所包含的对象生命周期较长。
3），变量所包含的对象数据稳定。
4），该类的对象实例有对该变量所包含的对象的共享需求。
在我的程序中对静态变量的优化后，使程序占用内存量至少提升了5k-10k。所以也不容忽视。
还有就是String类相关的东西：1。字符串累加的时候一定要用StringBuffer的append方法，不要使用+操作符连接两个字符串。差别很大。而且在循环或某些重复执行的动作中不要去创建String对象，因为String对象是要用StringBuffer对象来处理的，一个String对象应该是产生了3个对象（大概是这样：））。
2，字符串length()方法来取得字符串长度的时候不要把length放到循环中，可以在循环外面对其取值。(包括vector的size方法)。特别是循环次数多的时候，尽量把length放到循环外面。
int size = xmlVector.size();
for (int i = 2; i < size; i++) {
。。。
}
在程序中我曾经误写了这样一句：if(i=5){...}，编译器没有报错，而且结果好像是把i的值改变了，没有记清，大家有兴趣可以测验下。书写上尽量认真，否则查找bug的时候可能会折腾死人的。
关于优化方面也就能想起这些来了，如果还有对大家有用的东西我再补充吧，希望大家多提宝贵意见。共同进步嘛。
最近在做一个手机浏览器的客户端，最初以为一个浏览器的客户端不用考虑太多的内存使用，结果做完才发现在高端的手机上运行没有任何问题，在低端的手机上不是响应速度过慢，就是内存溢出。所以就开始对代码进行优化，在这个过程总结一些自己的经验，希望对有困惑的朋友有所帮助，有好的办法也希望大家共同探讨，zxhwolfe@hotmail.com
以下内容有些是自己实践所得，有些是参考高人经验或书本上的经验，如有不正确请立即指正；如果侵犯了他人版权请高台贵手，借鉴您的经验不是用于商业，只是希望大家共同进步请不要追究呵呵。
在写程序初期由于是面向midp2.0的手机而且不是游戏的开发，所以没有对性能方面做太多的考虑，大胆的使用了很多vector数组（使用起来方便：））等等，而且程序写的也是随心所欲，似乎不是在手机上开发j2me的东西。结果让我大跌眼镜，没办法只能重新优化，这期间可想而知浪费了很多时间，也使开发效率降低到了最低。说到这，只有一句话奉劝大家，不管你是开发什么样手机程序，一定要把性能放在第一位，不要重蹈我的覆辙。
我的几个vector存放的是链接的内容，文本框的内容，图片的内容和普通文本的内容，每个vector中包含的其他信息还有它所占的行数，它的位置和它的标志。我用线程控制paint（只要目的是实现持续按键的机制），这样的话，每次重绘都要把所有内容重新画到屏幕上，而且还要对当前焦点进行重绘。在重绘的过程中每一次都要遍历一遍几乎所有的vector然后重绘，这样肯定是浪费资源。结果也一样，在稍微低端一点手机上响应明显的慢。优化这样程序，我首先想到的就是把vector用别的方法替换掉，正常的性能使用是字符串-〉一维数组-〉二维数组->vector。一维数组肯定是替代不了我的vector了，那只能是使用二维数组了。费了好大劲把vector转换位二维数组，发现性能上并没有提升多少。大概只节省了20k左右的内存，只能再想别的办法。这里简单说下在手机上获得当前内存和剩余内存的方式：
long tempMin = 1000000；
long temp = Runtime.getRuntime().freeMemory();
if (tempMin > temp) {
tempMin = temp;
}
g.drawString("total = " + Runtime.getRuntime().totalMemory(), 10, 10, 0);
g.drawString("frees = " + temp, 10, 10 + lineHeight, 0);
g.drawString("hiegh = " + tempMin, 10, 10 + 2 * lineHeight, 0);
把这些东西画到你的画布上，在真机上运行的时候方便你查看内存的使用率。（每种机器的内存最大值是不同的）。
而且可以查看内存峰值。当然你也可以使用wtk自带的内存和方法查看器来判断。相关内容参考我的另外2篇文章：
J2ME性能优化之--方法和内存的评测：
/Article/Class2/200603/1650.html
J2ME性能优化之—优化方法探讨：
/Article/Class2/200603/1658.html
既然转换vector不能解决问题，那就继续优化。内存的主要使用看来是在每次重画的时候产生的，这样就要减少每次重画的内容，我采取的方式是把所有固定要重画的东西用双缓冲的方式画到一张图片上，这样只有初始化的时候才去遍历数组，经过一次的遍历把所有内容画到一张图片上，然后每一次的重画都是在重画一张图片。经过这样的处理性能上有了很大的提升。高兴还为时尚早，nokia的低端机器没有问题了，结果在moto的机器上出了问题，根本就不能初始化，也就是说创建那张图片的时候就应用程序错误了。继续查找原因，结果发现是因为moto的机器不支持创建一张那么大图片。也就是说你创建一张大图的时候，在moto的机器上根本就不能申请到内存。找到原因后，把大图分割为两个比较小的图，ok没有问题了。当然至于moto支持创建多大的图片可能每种机器不同吧，只能在需要的时候自己测试了。对于浏览器，一张分割为两张需要做些代码的处理。实际上为了性能的更加优化可以把一张大图分割为多张小图，每张小图的大小可以根据屏幕的几倍大小确定也可以根据机型固定。初始化的时候也可以先初始化一部分图。因人而异。
至此，程序的主要瓶颈已经找到，并且解决。正应了一句话，程序是花80%的时间在执行20%的代码。也就是说我们要把主要精力放在那20%的代码的优化上，但实际中我发现对另外80%代码的优化也很重要，主要是一些编程细节上的处理。在细节的代码书写上多注意些也有利于程序性能的提升。关于细节上觉得以下几个方面对程序性能的提升很有帮助。
首先系统垃圾回收的利用：关于堆内存（heap）与栈内存（stack）我们知道，heap存放的是对象实例与变量；而stack存放的是静态方法。堆内存在JVM启动的时候被创建，堆内存中所存储的对象可以被JVM自动回收。在这里，要手动把不用对象置为null，特别是较大的对象，如果不用一定要记得置为空。比如说较大的数组，vector或者是image对象。（切忌）在这里，浏览器中页面图片的读取我是采用的是后台读取，即先显示文字部分，而后后台读取页面中的图片，读取完成后再一起重新显示。重新显示的时候要重新构建那个双缓冲图片，而我当时就忘记了把原来创建的那个双缓冲图片置为null了，走了很多弯路才解决问题。所以要切忌至少把大的对象置空，不要指望垃圾回收。
其次是static的使用：静态变量在程序运行期间内存空间对所有该类的对象实例而言是共享的，即只在内存中保存一份拷贝，这样节约了不比要的内存开销。但是static生命周期较长，而且不容易被垃圾回收机制所回收，所以要合理运用，不要适得其反。建议在全部具备下列条件的情况下尽量使用静态变量：
1），变量所包含的对象体积较大，占用内存较多。
2），变量所包含的对象生命周期较长。
3），变量所包含的对象数据稳定。
4），该类的对象实例有对该变量所包含的对象的共享需求。
在我的程序中对静态变量的优化后，使程序占用内存量至少提升了5k-10k。所以也不容忽视。
还有就是String类相关的东西：1。字符串累加的时候一定要用StringBuffer的append方法，不要使用+操作符连接两个字符串。差别很大。而且在循环或某些重复执行的动作中不要去创建String对象，因为String对象是要用StringBuffer对象来处理的，一个String对象应该是产生了3个对象（大概是这样：））。
2，字符串length()方法来取得字符串长度的时候不要把length放到循环中，可以在循环外面对其取值。(包括vector的size方法)。特别是循环次数多的时候，尽量把length放到循环外面。
int size = xmlVector.size();
for (int i = 2; i < size; i++) {
。。。
}
在程序中我曾经误写了这样一句：if(i=5){...}，编译器没有报错，而且结果好像是把i的值改变了，没有记清，大家有兴趣可以测验下。书写上尽量认真，否则查找bug的时候可能会折腾死人的。
关于优化方面也就能想起这些来了，如果还有对大家有用的东西我再补充吧，希望大家多提宝贵意见。共同进步嘛。
免责声明： 本文仅代表作者个人观点，与爱易网无关。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请读者仅作参考，并请自行核实相关内容。
