我正在开发一个J2ME应用程序，它有大量数据存储在设备上（在1MB但可变的区域内）。我不能依赖文件系统，因此我陷入了记录管理系统（RMS），它允许多个记录存储但每个都有有限的大小。我的初始目标平台Blackberry将每个平台限制为64KB。
我想知道是否有其他人必须解决在RMS中存储大量数据的问题以及他们如何管理它？我想要计算记录大小并在多个商店中分割一个数据集，如果它太大，但这增加了很多复杂性以保持它完整。
存储了许多不同类型的数据，但只有一组特别会超过64KB限制。
答案 0 :(得分：9)
对于超过几千字节的任何内容，您需要使用JSR 75或远程服务器。即使在一些较高端的手机中，RMS记录的大小和速度也非常有限。如果您需要在J2ME中处理1MB数据，唯一可靠，可移植的方法是将其存储在网络上。始终支持HttpConnection类和GET和POST方法。
在支持JSR 75 FileConnection的手机上，它可能是有效的替代方案，但没有代码签名，这是一个用户体验的噩梦。几乎每个API调用都会在没有一揽子权限选择的情况下调用安全提示。使用JSR 75部署应用程序的公司通常需要为每个端口提供六个二进制文件，以便覆盖一小部分可能的证书。这只是制造商证书;有些手机只有运营商锁定的证书。
答案 1 :(得分：4)
设备之间的RMS性能和实现差别很大，因此如果平台可移植性存在问题，您可能会发现您的代码在某些设备上运行良好，而在其他设备上运行良好。 RMS旨在存储少量数据（高分表或其他任何数据），而不是大量数据。
您可能会发现某些平台的文件存储在多个记录存储中的速度更快。有些在一个商店中有多个记录的速度更快。许多都可以存储，但是当从商店中删除大量数据时变得非常慢。
您最好的选择是在可用的情况下使用JSR-75，并创建自己的文件存储接口，如果没有更好的支持，则可以回退到RMS。
不幸的是，当谈到JavaME时，您经常会被编写为特定于设备的代码变体。
答案 2 :(得分：3)
我认为最灵活的方法是在RMS之上实现自己的文件系统。您可以使用与硬盘驱动器上的块类似的方式处理RMS记录，并使用inode structure或类似方法在多个块上传播逻辑文件。我建议在块之上实现一个字节或面向流的接口，然后可能在其上创建另一个API层来编写特殊的数据结构（或者只是让你的对象可序列化为数据流）。
Tanenbaum's classical book on operating systems介绍了如何实现简单的文件系统，但我相信如果您不喜欢纸张，可以在线查找其他资源。
答案 3 :(得分：2)
在Blackberry OS 4.6下，RMS存储大小限制已增加到512Kb，但这并没有太大帮助，因为许多设备可能不会支持4.6。 Blackberry上的另一个选项是持久存储，其记录大小限制为64kb，但对商店的大小没有限制（除了设备的物理限制）。
我认为Carlos和izb是对的。
答案 4 :(得分：2)
这很简单，使用JSR75（FileConnection）并记住使用有效（可信）证书签署您的midlet。
答案 5 :(得分：2)
对于只读，我通过索引资源文件到达可接受的时间（10秒内）。我有两个~800KB的CSV价格表出口。程序类和这两个文件压缩为300KB JAR。
在搜索时，我会显示List并在后台运行两个Thread来填充它，因此第一个结果非常快，可以立即查看。我首先实现了一个简单的线性搜索，但这太慢了（约2分钟）。
然后我将文件编入索引（按字母顺序排序）以查找每个字母的开头。现在，在逐行解析之前，我首先InputStreamReader.skip()到达所需位置，基于第一个字母。我怀疑延迟主要来自解压缩资源，因此拆分资源会进一步加快速度。我不想那样做，不要放松轻松升级的优势。导出CSV时不进行任何预处理。
答案 6 :(得分：1)
我刚刚开始编写JavaME代码，但是对旧版PalmOS有经验，其中所有数据块的大小都有限，需要使用记录索引和偏移来设计数据结构。
答案 7 :(得分：1)
感谢大家提供有用的通知。最后，最简单的解决方案是限制存储的数据量，实现根据存储大小调整数据的代码，如果未存储在本地，则根据需要从服务器获取数据。多数民众赞成在操作系统4.6中增加了限制，如果运气好，我的代码将自行调整并存储更多数据：）
在不使用.cod编译器的情况下为Blackberry开发J2ME应用程序限制了JSR 75的使用，因为我们无法对存档进行签名。正如卡洛斯所指出的那样，这在任何平台上都存在问题，而且我使用PIM部分也有类似的问题。在Blackberry平台上，RMS似乎非常慢，所以我不确定顶层的inode / b-tree文件系统是多么有用，除非数据缓存在内存中并以低优先级后台线程写入RMS。 / p>