当前页面位置: » 丰搜网 » 文档中心 » 详细内容
java进阶篇：rms从入门到精通系列之一
顾名思义record management system是管理数据的系统，record是系统中最重要的实体。在移动设备存储空间存储的并不是字段，而是字节数组。
mobile infomation device profile(midp)规范中并没有规定什么样的数据才能存储为记录，事实上记录是任何可以被字节数组表示的数据，例如图片、文本等。record management system的职责是存储和唯一标识记录，而表示数据的任务是由应用程序来完成的，因此j2me的开发人员往往要花费更多的精力来处理存储空间中的数据。
这样做的目的是简化midp的实现，使得j2me的子系统尽量的小巧、灵活。毕竟移动信息设备的存储空间和处理器的能力都有限。
record store是一系列记录的有序集合，记录是不能单独存在的，必须属于record store。record store保证记录的读写操作都是原子的，数据不会被破坏。
在api中record store是由javax.microedition.rms.recordstore实现的，关于recordstore的具体操作在接下来的文章中会有详细的介绍。
midp规范中说明移动信息设备要提供至少8k的非易失性存储空间给应用程序来实现数据的持久性存储。但是不同的设备提供的空间并不相同。如果midlet suite使用了record management system，那么它必须在manifest文件和jad文件中通过设置midlet-data-size来说明它所需要的最小的数据存储空间，单位是字节，例如midlet-data-size：8192。
如果你的值超过了移动设备规定的最大值那么你的应用程序将不能正确安装。这个值并不是移动设备真正提供给应用程序的最大record management system的存储空间，往往要大一些，因此开发人员应该避免把应用程序需要的最小存储空间设置的过大，必要的时候应该参考相关设备的说明手册。
在非易失性存储空间内读写数据往往速度会比较慢，因此针对频繁访问的数据最好提供缓存的机制来提供性能。record management system的读写操作是线程安全的，但是由于record store是被整个midlet suite共享的，所以如果不同midlet上运行的线程操作record store的时候，我们应该进行必要的线程同步，避免数据被破坏。
midp1.0和midp2.0中关于record management system的实现有些不同，在同一个midlet suite里面的midlets可以相互访问彼此的record store。
但是在midp1.0的实现中，并没有提供在不同midlet suite之间共享record store的机制。在midp2.0中提供的了新的api来解决不同midlet suite之间共享record store的问题，在创建record store的时候通过授权模式和读写控制参数来进行共享机制的管理，我将在后续文章中进行详细的介绍。
加强对record management system的理解的最好的办法就是进行实际的开发，在进行开发中我发现并不是所有移动设备的midp实现都准确无误。当我用getsizeavaliable()方法查询nokia6108的可用record store空间的时候得到的数值是超过1m字节，但是当我写入40k的数据的时候就出现了recordstorefullexception异常，因此我编写了一个自动测试手机record store最大存储空间的软件。
原理是每隔一定时间例如100-500毫秒向record store内写入1k字节的数据，当抛出存储空间已满的异常的时候就可以得到最大值了，精确单位为k字节。
下面是程序的源代码和jad文件的内容，开发平台为eclipse3.0rc2+eclipseme0.4.1+wtk2.1+j2sdk1.4.2._03,在真机nokia 6108上测试通过并显示最大值为31k。（请不要在模拟器上进行测试，那样结果没有意义）
总结：本文只是带领读者对record management system进行了大概的了解，虽然在文章最后提供了一个应用程序。但是并没有深入分析如何使用record management system。在接下来的文章中我们会深入分析javax.microedition.rms包中的类，重点是如何使用recordstore类。
[1] [2] [3] 下一页
