我正在开发一个J2ME应用程序，该应用程序具有要存储在设备上的大量数据(大约1MB，但是可变)。我不能依靠文件系统，所以我陷入了记录管理系统(RMS)的问题，它允许多个记录存储，但是每个都有有限的大小。我最初的目标平台Blackberry将每个平台限制为64KB。

我想知道是否还有其他人必须解决在RMS中存储大量数据以及它们如何管理的问题？我正在考虑计算记录大小，并且如果数据集太大，则跨多个存储区拆分一个数据集，但这会增加很多复杂性以保持其完整性。

存储了许多不同类型的数据，但是只有一组会超过64KB的限制。

解决方案

回答

我认为最灵活的方法是在RMS之上实现自己的文件系统。我们可以按照与硬盘驱动器上的块类似的方式处理RMS记录，并使用inode结构或者类似的方式将逻辑文件分布在多个块上。我建议在这些块的顶部实现一个面向字节或者流的接口，然后可能在该接口的顶部再建一个API层，以编写特殊的数据结构(或者简单地使对象可序列化为数据流)。

Tanenbaum关于操作系统的经典书籍涵盖了如何实现一个简单的文件系统，但是我敢肯定，如果我们不喜欢纸质书籍，那么我们可以在网上找到其他资源。

回答

RMS性能和实现在设备之间千差万别，因此，如果平台可移植性成为问题，则我们可能会发现代码在某些设备上运行良好，而在另一些设备上运行良好。 RMS旨在存储少量而不是大量的数据(高分表或者其他)。

我们可能会发现某些平台使用存储在多个记录存储中的文件更快。有些存储在一个存储中具有多个记录会更快。许多都可以存储，但是从存储中删除大量数据时，速度会变得异常慢。

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

不幸的是，当涉及到JavaME时，通常会吸引我们编写代码的特定于设备的变体。

回答

对于超过几千字节的内容，我们需要使用JSR 75或者远程服务器。 RMS记录的大小和速度受到极大限制，即使在某些高端手机中也是如此。如果我们需要在J2ME中处理1MB数据，那么唯一可靠，可移植的方法是将其存储在网络上。始终支持HttpConnection类以及GET和POST方法。

在支持JSR 75 FileConnection的手机上，它可能是有效的选择，但没有代码签名，这是用户体验的噩梦。几乎每个单个API调用都将调用安全提示，而没有选择全部权限。部署带有JSR 75的应用程序的公司通常每个端口都需要六个二进制文件，才能覆盖一小部分可能的证书。这仅用于制造商证书；有些手机仅具有运营商锁定的证书。

回答

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

回答

在Blackberry OS 4.6下，RMS存储大小限制已增加到512Kb，但这并没有太大帮助，因为许多设备可能不支持4.6. Blackberry上的另一个选项是Persistent Store，它的记录大小限制为64kb，但对存储大小没有限制(设备的物理限制除外)。

我认为Carlos和izb是对的。

回答

这非常简单，请使用JSR75(FileConnection)，并记住使用有效(可信)证书对Midlet进行签名。

回答

感谢大家的有用的评价。最后，最简单的解决方案是限制存储的数据量，实施根据存储量调整数据的代码，如果未在本地存储，则根据需要从服务器获取数据。有趣的是，在OS 4.6中增加了限制，如果运气好的话，我的代码将自行调整并存储更多数据:)

在不使用.cod编译器的情况下为Blackberry开发J2ME应用程序会限制JSR 75的使用，因为我们无法对归档文件进行签名。正如Carlos指出的那样，这在任何平台上都是一个问题，使用PIM部分也遇到了类似的问题。在Blackberry平台上，RMS似乎非常慢，因此，我不确定顶部的inode / b树文件系统有多有用，除非将数据缓存在内存中并在低优先级后台线程中写入RMS。

回答

对于只读，我通过索引资源文件到达可接受的时间(10秒以内)。我有两个〜800KB CSV价格清单出口。程序类和这两个文件都压缩为300KB JAR。

在搜索时，我显示一个"列表"并在后台运行两个"线程"以填充它，因此第一个结果很快就会出现并且可以立即查看。我首先实现了一个简单的线性搜索，但这太慢了(约2分钟)。

然后，我索引了文件(按字母顺序排序)，以查找每个字母的开头。现在，在逐行解析之前，我首先根据第一个字母将InputStreamReader.skip()移至所需位置。我怀疑延迟主要来自解压缩资源，因此拆分资源会进一步加快速度。我不想这样做，不要失去轻松升级的优势。 CSV无需任何预处理即可导出。