| 谈谈J2ME解决手机Game的内存问题 |
| |
| 作者：未知 来源：J2ME开发网 点击数：924 更新时间：2006-10-31 |
|
您可以添加到网摘 让更多人关注此文章：
你可能想，为什么要谈内存，我们可爱的Java不是有gc机制吗?可惜我们现在不是在pc上，而是只有64k内存的手机。如果不多加小心谨慎的话，我们的gc很可能每十秒钟运行一次呢。你会不会毫不犹豫地写下这样的代码:
1.
g.drawString
(“score=”+score，50，50，
Graphics.TOP|Graphics。LEFT)
?
或是
2.
for
(Enumeration e = v.elements() ;
e.hasMoreElements() ;
)
{
System.out.println(e.nextElement());
} |
有什么问题?其实它做了下面的事:
String scoreStr=“score=”+score;
g.drawString
(scoreStr，50，50，Graphics.TOP|Graphics.LEFT); |
明白了吗?在你的J2ME游戏里，这行程序很可能在paint()里面出现并且每0.1秒运行一次吧。伴随着时间的推移，成堆的String被创建出来，要不了多久，我们可爱的gc妈妈就要出来喽。想到了就简单了，根据我们midlet的实际情况，让我们灵活地建立解决de方法。
差不多也发生了同样的事情，注意到interface Enumeration只有两个method:
boolean hasMoreElement();
Object nextElement(); |
发现了什么?Enumeration不像STL的iterator，没法让一个原有的Enumeration从头开始，每遍历一次我们的Vector或Hashtable，我们就得问我们的容器要一个新的Enumeration。
常见的情况是:
碰撞检测。我们不得不在每一个frame里对容器做遍历，其结果就是生出以集装箱为单位的大把Enumeration，使用Enumeration很酷，不过为了内存，我们还是老土一点:
for (int loop ;
loop
System.out.println
(vector.elementAt(loop));
} |
最后，只要善用wtk的Monitor，就能及时地发现我们MIDlet中的内存杀手，将lag消饵于无形之中。
|
没有任何评论
*只显示最新10条评论。评论内容只代表网友观点，与本站立场无关。 更多评论
|
|
发帖须知：
一.所发文章必须遵守《互联网电子公告服务管理规定》;
二.严禁发布供求代理信息,公司介绍,产品信息等广告宣传信息;
三.严禁恶意重复发帖;
四.严禁对个人,实体,民族,国家等进行漫骂,污蔑,诽谤。 |
|
|
|
当前位置：
电子技术 >> 嵌入式软件 >> JAVA
相关文章
发表评论
