用J2ME存储大量数据的最佳实践

对于超过几千字节的内容,您需要使用JSR75或远程服务器。RMS记录的大小和速度都非常有限,甚至在某些高端手机中也是如此。如果您需要在J2ME中处理1MB的数据,唯一可靠的、可移植的方法就是将其存储在网络上。始终支持httpConnection类和get和post方法。

在支持JSR75文件连接的手机上,它可能是有效的替代方案,但如果没有代码签名,这将是一个用户体验的噩梦。几乎每一个API调用都会调用一个没有覆盖权限选择的安全提示。使用JSR75部署应用程序的公司通常需要为每个端口提供六个二进制文件,以覆盖可能的证书的一小部分。这只是为了获得制造商的证书;有些手机只有带载波锁定的证书。

rms的性能和实现在不同的设备之间差异很大,因此如果平台可移植性是一个问题,您可能会发现您的代码在某些设备上工作得很好,而不是在其他设备上。RMS设计用于存储少量数据(高分表或其他)而不是大量数据。

您可能会发现,有些平台在多个记录存储中存储文件时速度更快。有些在一个存储中使用多个记录更快。许多存储都可以,但从存储中删除大量数据时速度会变得非常慢。

您最好的选择是在可用的地方使用JSR-75,并创建自己的文件存储接口,如果没有更好的支持,它将返回到RMS。

不幸的是,当涉及到javame时,您常常被吸引到编写特定于设备的代码变体。

我认为最灵活的方法是在RMS之上实现您自己的文件系统。您可以像处理硬盘上的块一样处理RMS记录,并使用 inode structure 或类似于在多个块上分布逻辑文件。我建议在块的顶部实现一个面向字节或流的接口,然后可能在块的顶部创建另一个API层,用于编写特殊的数据结构(或者简单地将对象序列化为数据流)。

Tanenbaum's classical book on operating systems 介绍如何实现一个简单的文件系统,但我相信如果您不喜欢纸张,您可以在网上找到其他资源。

在BlackBerry OS 4.6下,RMS存储大小限制已增加到512KB,但这没有多大帮助,因为许多设备可能不支持4.6。BlackBerry上的另一个选项是持久存储,它的记录大小限制为64KB,但不限制存储的大小(设备的物理限制除外)。

我认为卡洛斯和伊兹布是对的。

这非常简单,使用JSR75(FileConnection)并记住使用有效(可信)证书对您的MIDlet进行签名。

对于只读,我将通过索引一个资源文件到达可接受的时间(在10秒内)。我有两个~800kbcsv价目表导出。程序类和这两个文件都压缩到一个300kb的JAR。

搜索时显示 List 运行两个 Thread 在背景中填充,所以第一个结果很快就会出现,并且可以立即查看。我首先实现了一个简单的线性搜索,但是太慢了(大约2分钟)。

然后我索引了文件(按字母顺序排序),以找到每个字母的开头。在逐行分析之前,我先 InputStreamReader.skip() 根据第一个字母到达所需位置。我怀疑延迟主要来自于对资源的解压缩,因此拆分资源会进一步加快速度。我不想这样做,也不想失去升级的便利。导出csv时不进行任何预处理。

我刚开始为javame编写代码,但是我对Palmos的旧版本有经验,在旧版本中,所有数据块的大小都受到限制,需要使用记录索引和偏移量设计数据结构。

感谢大家对我的评价。最后,最简单的解决方案是限制存储的数据量,实现根据存储的大小调整数据的代码,如果数据不存储在本地,则按需从服务器获取数据。有趣的是,OS 4.6中的限制增加了,如果幸运的话,我的代码只需自己调整并存储更多数据:)

在不使用.cod编译器的情况下,为BlackBerry开发J2ME应用程序限制了JSR75的使用,因为我们无法对存档文件进行签名。正如卡洛斯所指出的,这在任何平台上都是一个问题,我在使用PIM部分时也遇到过类似的问题。在BlackBerry平台上,RMS的速度似乎非常慢,所以我不确定Inode/B-Tree文件系统在顶部有多有用,除非数据缓存在内存中,并在低优先级的后台线程中写入RMS。