文章来源：J2ME开发网
前言
上一章我们用通俗易懂的电影拍摄过程大致的了解了一下游戏引擎，希望大家可以了解一个引擎都有哪些部分。恰恰就在帖子贴出的第二天一个朋友问我：“游戏框架和游戏引擎有什么区别？”。当时我就蒙了一下，转眼我又想到了汽车与引擎的关系，于是回答“框架就相当于汽车，引擎就相当于汽车的引擎”。不知道大家看明白没有，框架决定了引擎的作用，比如一个j2me的游戏框架是不可能运行一个PC的游戏引擎，就像小汽车的引擎和客车的引擎不可能通用一样。还有朋友问我，你讲的里面那些东西每一个都是单独的类吗？请大家注意，抽象构成和现实组织有着不可分割的联系，但同样有着巨大的差距，就像钻天猴与“神州5号”飞船的差别一样。原理是一样的，可是他们差别同样巨大。一定要活学活用啊。
第一节 场景管理器（world）
在PC中我们有着海量可以使用的资源，包括各种各样的资源 ，要说有限制也是机器本身的限制。甚至里面一个小小的文件都有可能比我们的j2me游戏本身都大。于是乎在做PC游戏的时候更多考虑的是游戏的效果如何，运行速度如何，而我们也可以天马行空的使用着各种我们可以使用的特效。于是渲染器成了引擎中的重头戏，呵呵，谁不喜欢看自己的游戏能玩出好多特别Cool的效果来，反正我想。唉，虽然为PC的游戏兴奋了半天可我们毕竟不是做PC游戏的，我们做的是比PC游戏更牛X的j2me游戏。为什么说更牛X呢，敢问那个PC游戏可以在仅仅使用100k heap的情况下可以把《古墓丽影》《细胞分裂》这样的游戏做的炉火纯青，玩家爱不释手？100k heap，这是什么概念？都学过计算机理论，知道那是多大。
在这种情况下我们引出第一次从天堂的堕落：场景管理器。我们仍然拿拍电影来做分析。第一章那个小片段中的场景是一个狭窄的街道，中间要放好多道具，“导演”不停的要求“剧务”放这放那，那么如果“剧务”足够聪明的话他肯定要采取一种比较省时省力的办法，而不是一趟一趟的往库房跑。但是本身剧务可以放置道具的地方并不多，于是一次取多少道具以及道具的使用率就决定了“剧务”的劳动量。同理，我们可以把“剧务”可以控制的空间比作heap，“剧务”去库房拿“道具”比作I/O操作。既要最大程度满足“导演”的需求，又要保证“时间”不过多地浪费在去“库房”的路上又不能超出当前所能控制的空间....其实这个真的很难！就像自己的女人要求天天跟她在一起，而自己又因为要挣钱奔波一样^_^。问题出来了，至于怎么样最省力我们仍然需要不断的探索。一个好办法就是“剧务”首先掌握“库房”中“道具”存放位置，等需要的时候一步到位拿出来即可，省去找寻的时间。至于怎么满足“导演”的需要那是另一码事，咱们解决这个问题。我相信大家在学习过程中看代码是最直接，最有效的方式，为了证明我的想法我找了一个S40版的《细胞分裂》来学习研究一下。（如果大家已经看过我的msn 空间了，下面可以略过）第一步从我们的分析中就可以看出应该是“掌握道具在库房中的位置”，这个嘛和我们打的文件包是有一定关系的，需要在文件中加入一些附属的信息，下面是gameloft细胞分裂部分文件操作代码，代码中有详细说明。在我的感觉中gameloft一定采用了什么方法。我曾经大概猜测了一下，无非就是将文件的一些信息扔到一个包里然后在包里记录一些文件的数据信息，比如便移量什么的。我的包就是那么作的，但是缺点很明显，必须要一次载入所有的资源，也不是必须，如果不那样就每次根据需要
来搜索资源位置就很费CPU资源了。
首先来看gameloft的第一段代码：（反编译后的）
private static final boolean B(String s1)
{
getResourceAsStream = s1;
try
{
InputStream inputstream = I.getClass().getResourceAsStream(s1);
System.gc();
//这里取了两个byte的数据，并组合成了一个整数，仔细想想的话不难发现这是这个包中资源的个数
getState = inputstream.read() & 0xff;
getState += (inputstream.read() & 0xff) << 8;
//这段话又是什么意思呢？又＋又*的，晕死了。到最后我再告诉大家这是做什么用的，主要得根据数据结构来说
hasNextElement = 2 + 4 * getState;
//不用说了，这是分配空间
getWidth = new int[getState];
indexOf = new int[getState];
//难点终于来了
for(int i1 = 0; i1 < getState; i1++)
{
//下面这段话最有意思，明明知道是在拼一个整数，可是要整数干什么用呢？先留给大家想想
getWidth[i1] = inputstream.read() & 0xff;
getWidth[i1] += (inputstream.read() & 0xff) << 8;
getWidth[i1] += (inputstream.read() & 0xff) << 16;
getWidth[i1] += (inputstream.read() & 0xff) << 24;
//这里嘛好理解，就是indexOf中存的是两个整数差，*.....难道....接着看
if(i1 != 0)
indexOf[i1 - 1] = getWidth[i1] - getWidth[i1 - 1];
}
inputstream.close();
inputstream = null;
System.gc();
}
catch(Exception exception)
{
boolean flag = false;
return flag;
}
return true;
}
这段代码中并没有反应出系统载入了一个包，而是一些乱七八糟的东西，这段代码也是一直困扰我的地方，明明是载入东西，可是却载入了一股子整数。没办法，接着看吧，也许整合起来就知道做什么用的了。
我最敏感的就是byte[]这个词，于是我发现了这段代码
private static final byte[] addRecord(int i1)
{
//哦，有戏，一看就知道在作边界检测
if(i1 < 0 || i1 >= getState)
return null;
//obj是做什么的呢？暂时不知道
Object obj = null;
//声明byte数组，嘿嘿，找到啦
byte abyte0[] = null;
try
{ //载入资源 getResourceAsStream＝刚才的s1
InputStream inputstream = I.getClass().getResourceAsStream(getResourceAsStream);
//噢，找到啦，刚才那个什么getWidth的数组不是存了整数吗？难道整个文件后面还有东西？
//不用说了，那个数组记录的是文件的偏移量而index记录了大小，这样一切就都明白了，
inputstream.skip(getWidth[i1] + hasNextElement);
abyte0 = new byte[indexOf[i1]];
inputstream.read(abyte0);
inputstream.close();
inputstream = null;
}
catch(Exception exception) { }
System.gc();
return abyte0;
}
从上面的代码我们不难总结出，首先将所有的“道具”的大小和位置保存下来有多么大的好处。但是他也有它的限制，如果大家就这样然后一味的生搬硬套到自己的项目中那你就惨了，如果“道具”比较大比如地图数据之类的还好说，很长时间调用一回I/O，如果是一些小文件光I/O操作就能搞死手机。所以我们因该想出更好的解决方案，就是让那个addRecord可以接受一个数组，在不超出heap size的情况下调入多个文件。代码我就不给出了，有了上面的代码大家很容易就可以做出来。或许比GameLoft更好也说不定哦
呵呵，从理论到实践，我们走出第一步。我并不主张大家就照本宣科的把人家的东西拿来就用，也许有人说，晕，这么简单，对！在你做出来之前都是困难的！只要用心，只有想不到没有做不到！
上面的问题我们已经解决掉了，但是如何调度最快最省时间？这是个人者见人，妖者见妖的问题，一般要根据项目的需求来做，如果是一个RPG游戏，剧情节奏缓慢，就没有必要把好多资源一起载入，仅把需要的载入即可。而一个剧情发展迅速，对速度要求较高的空战游戏我们最好还是尽最大程度将“道具”资源载入较好。
从我的叙述中似乎对场景管理器的“管理”方面叙述不够多，我也注意到了嘿嘿。其实场景管理器除了从库房调入“道具”并加入自己的“道具”列表，更重要的一个工作就是在合适的时候将道具放回库房，释放自己能控制的“空间”并从“道具”列表中删除。那么我们怎么样才可以实现呢？这个问题也比较挠头，笔者曾经做过一些探索，但效果不甚理想。我的方案就是对当前“剧务”所能控制的每个道具进行使用频率计算，使用过就+1,在一定频率内没有使用就-1,直到变成0就释放掉，效果不是很理想。于是回归原始，每段游戏完毕后就将资源手动回收一次，呵呵。这样虽然有悖于引擎的宗旨，但的确是效率最好的。
汗！虽然本节讲的是“场景管理器”，可更多的叙述了场景资源的调度，其实这么讲是有原因的。在j2me中所谓“管理”最有可能就是用数组来实现的，所以管理方面显得就比较薄弱，而资源的调度则可能是N个函数和变量组成。先前我也说过理论与实现的关联和差距，但可以肯定地一点是由理论带动实践开发才是快速提高自身水平之路。理论不正确，方向就会错误，弯路就成不可避免的了。
