首页 > 学院 > 开发设计 > 正文

谈谈J2ME解决手机Game的内存问题

2019-11-18 16:16:56
字体:
来源:转载
供稿:网友

  你可能想,为什么要谈内存,我们可爱的java不是有gc机制吗?可惜我们现在不是在pc上,而是只有64k内存的手机。如果不多加小心谨慎的话,我们的gc很可能每十秒钟运行一次呢。你会不会毫不犹豫地写下这样的代码:

1. g.drawString(“score=”+score,50,50,Graphics.TOPGraphics。LEFT)?  或是2.for (Enumeration e = v.elements() ;e.hasMoreElements() ;){System.out.PRintln(e.nextElement());  }
  

有什么问题?其实它做了下面的事:

String scoreStr=“score=”+score;g.drawString(scoreStr,50,50,Graphics.TOPGraphics.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消饵于无形之中。

(出处:http://www.VeVb.com)



发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表