开发J2ME应用程序时，out momory内存溢出这种痛苦经常经常出现，所以J2ME应用程序内存的优化是非常必要而必须的，这里向大家简单描述一下，相信本文介绍一定会让你有所收获。
J2ME应用程序内存优化
开发J2ME应用程序时，out momory内存溢出这种痛苦经常经常出现。要知道在手机上用内存必须勒紧裤腰带，手机是以K来计算的。写手机程序让人回到了8086时代。J2ME应用程序内存的优化是非常必要而必须的。
一．代码优化
内存会溢出肯定和代码逃不了关系,垃圾回收器是java的一大优点,显然这个特性为代码编写者省了不少事，但这个特性却带来了不少隐患。
举个例子在游戏当中经常有不同场景的切换，如从游戏逻辑退到主菜单逻辑,对游戏逻辑对象的态度,很多人会选择忘记内存的释放，就等着垃圾回收器自己来善后。但是实际上垃圾回收器并非实时的,它不像C++的Delete语句马上释放不用的内存。当从游戏逻辑切换到主菜单逻辑这时两个对象同时存在很可能这时内存就不够用了。
实际上垃圾回收器在j2me上并不怎么好用，在j2me上所有垃圾手工释放才比较直接有效,除简单类型以外所有对象都必须显式地置空例如 imgs=null; 实际上java提供了一个不错的工具用来查找内存溢出,java.lang.Runtime.freeMemory() 。它可以返回当前的剩余内存数，将它适当的安放在代码中可以有效的监测内存使用状况。
有一部份的j2me程序员写代码存在不良习惯。
例1：
- //a 不为空
- a=new menu();
这里面包含两个问题：
1. 该段代码是先创建对象然后再进行赋值操作的，也就是说在这期间有两个对象同时存在这就很可能会产生溢出。
2. 这样做也会妨碍垃圾回收器的工作
较好的写法如下:
- a=null;
- System.gc(); // 回收a以前引用的对象
- a=new menu();
虽然麻烦了点但在j2me中还是必要的。
例2：
drawString(”游戏时间:” + time ,50,50,Graphics.LEFT|Graphics.TOP);
“游戏时间:” + time 很***在paint()方法当中每次都被刷一遍显示在屏幕上。该语句每次运行时会重新分配内存来存储 ”游戏时间:” + time 而显示完以后又必须由垃圾回收器释放，用了双倍时间,并且容易发生内存溢出。依此类推在重复执行的方法里应尽量避免重复定义对象。与paint()方法类似在循环里也有类似的情况存在。
例3：
把所有对象的初始化放在构造函数里,大多数人通常的做法是把当前所要用到的资源通通一次初始化完毕。
很大一部份的内存溢出都是发生在构造函数中。内存使用的高峰期都是在构造函数中所以避开这个高峰能有效的防止溢出。
比较好的做法是***次使用时初始化。如下所示
- if (img==null){
- //初始化
- }
现在做游戏都需要地图数组，声音数组，还有一些其它资源。
这些资源可以放在代码中也可以放在文件当中,但是建议将这些资源放在文件中需要时在loading进来。这些资源如果放在代码中则会占用不小的代码段空间，而代码一般是程序一运行就装载到内存当中。
除上面列举的方法外还有其他的小方法, 比如关闭没用的rms ，关闭没用的网络连接，关闭没用的流。正确地停止线程。良好的程序架构减少代码偶合性也是一个不错的方法。#p#
二．图片优化
下面我们来看一下J2ME应用程序内存优化的图片优化的概念。j2me的内存杀手无疑非图片莫属,一张3k的图片可以占用20多k的内存。防止内存溢出最直接的办法就是从图片入手。图片压缩: 多数人马上会想到这个办法。不错这个办法是最有效的。在网上有许多图片压缩工具,这里就不详细说明了。
假如你有多张规格一样的图片，那么建议你把它做成一张长条图片。有两个原因：
1>这样节省存储空间和内存空间。10张图片的内容放在一张当中和10张小图片相比，文件大小减少了不少。
2>10张图片需要10个image 对象需要进行10次io操作浪费时间还浪费内存。当把所有图片都存成一张，内存又容易溢出了… 图片太大了不要把不同界面的图片整合在一起否则经常会得不偿失，这就需要在实践中不断调整了。
作图时也有一些细节需要注意,颜色数量，分辩率，图像模式（***是索引颜色),画布大小都会影响到图片大小。J2ME应用程序内存优化如何使用工具进行优化呢。
三．工具优化
混淆器是用来保护代码的以加大反编译的难度,实际上用它来优化程序也是不错的选择。
其实有两点好处：
1> 压缩程序大小: 一个60k的程序经常可以压掉10多k。10k的空间对于低端手机来说可不是个小数
2> 节省内存空间: 代码减小了内存里的代码段自然就短了。
【编辑推荐】
