这周做到超大地图寻路的时候，进行一次性能测试。在超大地图 5500 * 5500 的地图中，若每个网格的大小为 20 像素。 那么总共需要创建 col : 275, row : 275 个 Node 对象。 那么 单单Astar 的寻路样本数组中就包含了共75625个Node对象，这还不包括寻路中临时创建的open数组和close数组。 就75625个Node对象来说，需要占用的内存在6kb,由于avm进行gc的时机为程序请求新的内存空间，而程序自身又要大量空闲对象的时候，不是即时的。因此，当一个玩家快速的进行多次寻路后，由于之前的寻路的没有触发gc,导致内存中还驻留上一次保存的Node数据，其内存占用是几何级增长的，会达到十几MB。这显然是不科学的。
于是决定使用一种更加不科学的方法来解决这个问题。

即，使用int型而非Object对象来存储Node。好吧，这显然脱离了oop的思想，嘛~不过作为数据结构来说，一个int型可是比Object来说，省内存了多哦。
一个Node中一般保存3个数据，Col,Row,Walkable。
首先构建3个int:
[cc lang=”actionscript” nowrap=”true”]
var col : int = 200 << 24; var row : int = 400 << 12; var walkable : int = 1; var result : int = col + row + walkable; trace(result); //-937885695 [/cc] 讲解下，一个int是一个32位的数值，于是把32位抽象的拆分为 0-11 位保存 col 值， 12 - 23 位 保存 row 值, 24 - 32 位 保存 walkable 值。 将3个值合并后输出结果为 -937885695 。 当数据被保存为 -937885695 后，使用如下方法进行解析。 [cc lang="actionscript" nowrap="true"] trace("col:",result >> 24 & 0xff); //200
trace(“row:”,result >> 12 & 0xfff); //400
trace(“walkable:”,result & 0xf); //1
[/cc]

解析的原理是 result 向右移位 24 位，然后与 0xff 进行比对，取出2进制中同位置中同为1的数。
例 1011 & 0011 ， 结果为 0011 。
至于 为什么 col 与 0xff, row 与 0xfff, walkable 与 0xf 比较呢。
原因为 0xf 是十六进制，一个f的大小为16。
那么 col = 200 , 0xff(256) > 200 > 0xf(16), 0xfff(4096) > 400 > 0xff(256) , 0xf(16) > 1 > 0;

接下来是性能测试：
[cc lang=”actionscript” nowrap=”true”]
var num : Number = 100000;

var intVec:Vector. = new Vector.(num);
var objVec:Vector.