新手必读 详细介绍J2ME的基础知识(七)

二十五、使用OTA来发布你的程序
　　众所周知，J2ME程序发布的形式主要有：OTA、数据线传输、红外和蓝牙传输等。这里简单说说如何通过OTA来发布你的程序。
　　OTA是Over The Air的简写，也就是通过网络下载，这是主要的发布形式之一。现在的百宝箱都是采用这种形式。
　　使用OTA来发布程序，需要如下几个步骤：
　　1、在你的WEB服务器上添加对于jad和jar文件的MIME支持。
　　后缀名:jad
　　MIME类型:text/vnd.sun.j2me.app-descriptor
　　后缀名:jar
　　MIME类型:application/java-archive
　　2、发布WML页面：
　　例如你的jar文件名test.jad，则最简单的下载页面是：

<?xml version="1.0"?> 　　<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.3//EN" 　　"http://www.wapforum.org/DTD/wml13.dtd"> 　　<wml> 　　<card id="card1" title="Download Midlet"> 　　<a href="test.jad">test</a> _fcksavedurl=""test.jad">test</a>" 　　</card> 　　</wml>

　　你可以将以上代码保存在WEB服务器上，例如保存为text.wml
　　3、修改jad文件：
　　在jad文件中增加　MIDlet-Jar-URL: http://domain/directory/test.jar
　　其中的http://domain/directory/test.jar为你的jar文件的路径。
　　经过上面的设置，你就可以将你的wml页面路径作为你的WAP下载页面发布了。用户只需要在手机上输入这个路径就可以访问和下载你的程序了。

J2ME游戏开发笔记整编版
 
1 J2ME中查表法使用三角函数
 
    CLDC和MIDP都没有提供三角函数，而且CLDC1.0中也没有浮点数，所以我们的选择是查表。使用8位定点数的sin和cos表。下面是wtk自带demo中的代码,只提供了有限的几个角度，实际使用时根据需要细化角度值。

// sines of angles 0, 10, 20, 30, 40, 50, 60, 70, 80, 90,    all *256     private static final int[] SINES =         { 0, 44, 88, 128, 165, 196, 222, 241, 252, 256 };     // angle is in degrees/10, i.e. 0..36 for full circle     private static int sineTimes256(int angle)     {         angle %= 36;    // 360 degrees         if (angle <= 9)          // 0..90 degrees         {             return SINES[angle];         }         else if (angle <= 18)    // 90..180 degrees         {             return SINES[18-angle];         }         else if (angle <= 27)    // 180..270 degrees         {             return -SINES[angle-18];         }         else                     // 270..360 degrees         {             return -SINES[36-angle];         }     }     // angle is in degrees/10, i.e. 0..36 for full circle     private static int cosineTimes256(int angle)     {         return sineTimes256(angle + 9);     // i.e. add 90 degrees     }

 

(注：有一些算法可以生成三角函数值，这样只要在游戏载入时生成一下函数表即可，节省一些数据)

2 J2ME中使用随机数

  产生0～n之间的随机数:
(ran.nextInt()>>>1)%n
或
(ran.nextInt()&0x7FFFFFFF)%n

产生-n~0之间的随机数:
(ran.nextInt() | 0x80000000 )%n

3 尝试IO优化

    正在开发的一个游戏，由于读地图的时候做了图片切割，所以速度比较慢。（在我开发上一个游戏的时候，读取地图时没有装载切割图片，速度非常快，看来ＩＯ操作的速度和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

4 压缩还是不压缩

        做J2ME的都知道Midlet Suite的容量实在太小了，于是不免想做点压缩。前些天，我就尝试了一次压缩。我自己定义的地图文件里有3层数据，其中2，3层有大片连续分布的相同的值。 唉？我一琢磨，使用一个简单的行长编码压缩，仅对这个值进行行长编码，算法很简单速度又不慢，却可以大大减小地图文件的大小。看起来真的很不错诶！说干就干，忙了半天，又改地图编辑器，又改游戏中读地图的代码。总算搞定，试了一下，原来2.23k的一个文件被压缩到900多字节。好像很不错啊，接着我打了个jar包，却突然发现这个jar文件好像并没有比原来小阿！似乎还大了点。我连忙找出备份的代码，果然原来的jar更小点！怎么回事啊？？我突然想到，jar本身就是压缩格式的。难道。。。我赶快用winrar打开两次的jar文件观察。~~~~~原来如此！原来的jar中，2.23k的文件的包大小为185字节，而我现在的jar中，900多字节的文件的包大小为216字节。也就是说，我自己先压缩一遍的文件打包后还不如不压缩的小！
       看来自己做压缩之前，一定要先看看你想压缩的文件在包里面的大小。还有对于png文件，使用某些工具优化后，在包里面的大小却变大了。这个还真是要注意阿~！
(05.12.31注：某些压缩算法确实比zip压缩效率要高，可以使用，不过副作用是解压导致loading时间变长)
(2006.5注：有些时候，需要节省一下内存，可以将数据打包压缩一下，package & compress模式，存在内存中，需要时解压)

 

查看本文来源