正在开发的一个游戏，由于读地图的时候做了图片切割，所以速度比较慢。（在我开发上一个游戏的时候，读取地图时没有装载切割图片，速度非常快，看来ＩＯ操作的速度和createImage,drawImage相比是微不足道的）对于IO的优化也许根本不会明显的提高速度，但我还是试了一下。
分析了一下代码，在最初的代码中为了比较方便的读取各种类型的数据，使用DataInputStream套接InputStream。可是我仔细看了一下我读取得数据，居然都是byte,唯一的一个char也是被我用两个byte手工组装起来的。这下，DataInputStream看来是不需要了。于是我做了个实验，没改动之前读取地图耗时1242ms,将DataInputStream去掉直接使用InputStream耗时1065ms,虽然每次试验的结果都稍有不同，但大概还是节约了200ms左右。
还能再加快点吗？再观察一下代码，我发现数据是通过多次的read操作读取进来的。太过频繁的io操作会不会降低速度呢？如果用一个字节数组作缓冲一次性将数据都读进来会不会快点？嗯，试一试才知道。但是我怎么知道一个流的大小呢？InputStream的avaliable方法总是返回-1啊！打开两次流，第一次先计算大小？对了，还有一个方法。直接将文件大小写到文件前面。地图文件是用自己的编辑器生成的，知道大小很容易。于是我在文件前面用两个byte纪录了文件的大小，先从流中读取2个byte,得到文件大小后，再用read(byte[],int,int)方法将整个流读取到缓冲中。然后，我的所有数据操作都从缓冲中读取。好，试验一下，结果是：1154ms。阿? 慢了近100ms。事实证明了这个猜想是错误的。原因？也许只有了解KVM的机制才知道。
弄完速度的问题，我又觉得读取文件的try块太大了，因为是边读边处理数据，所以try块变得很大。try块太大会增加class文件的大小。于是我用一个方法将读取byte的操作封装起来，当然这个方法是声明为private static的，但究竟能不能内联，只有编译器和kvm才知道。在这个方法内部从流中读取一个字节的时候采用了try,catch结构，这就使一个大try块分散成若干小try块。试验了一下，耗时1089ms,诶，还是慢了点。现在对于速度的要求比空间更高，更何况减小try块节省的10几个字节打包后基本忽略不计了。所以这个优化又失败了。
小结：能使用简单流的时候就不要使用复杂流，不要太相信理论上的说法，只有试了才知道。
注：试验数据是Nokia3100手机的实机测试数据，在Nokia 3300上这个数据更小些，最快约800多ms
