对于超过几千字节的任何内容，您需要使用 JSR 75 或远程服务器。RMS 记录的大小和速度极其有限，即使在一些高端手机中也是如此。如果您需要在 J2ME 中处理 1MB 的数据，唯一可靠、可移植的方法是将其存储在网络上。始终支持 HttpConnection 类以及 GET 和 POST 方法。
在支持 JSR 75 FileConnection 的手机上，它可能是有效的替代方案，但如果没有代码签名，它是用户体验的噩梦。几乎每一个 API 调用都会调用一个安全提示，而没有一揽子权限选择。使用 JSR 75 部署应用程序的公司通常需要为每个端口使用六个二进制文件，以覆盖一小部分可能的证书。这仅适用于制造商证书；有些手机只有运营商锁定的证书。
RMS 性能和实现因设备而异，因此如果平台可移植性存在问题，您可能会发现您的代码在某些设备上运行良好，而在其他设备上运行不佳。RMS 旨在存储少量数据（高分表或其他）而不是大量数据。
您可能会发现某些平台的文件存储在多个记录存储中时速度更快。有些在一个商店中有多个记录会更快。许多都可以存储，但在从存储中删除大量数据时变得无法使用。
您最好的选择是在可用的情况下使用 JSR-75，并创建您自己的文件存储接口，如果没有更好的支持，该接口将回退到 RMS。
不幸的是，当涉及到 JavaME 时，您经常被吸引到编写特定于设备的代码变体。
我认为最灵活的方法是在 RMS 之上实现您自己的文件系统。您可以以与硬盘驱动器上的块类似的方式处理 RMS 记录，并使用inode 结构或类似结构将逻辑文件分布在多个块上。我建议在块之上实现一个字节或面向流的接口，然后可能在其之上创建另一个 API 层来编写特殊的数据结构（或者只是让你的对象可序列化到数据流）。
Tanenbaum 关于操作系统的经典书籍涵盖了如何实现一个简单的文件系统，但我相信如果您不喜欢纸张，您可以在网上找到其他资源。
在 Blackberry OS 4.6 下，RMS 存储大小限制已增加到 512Kb，但这并没有多大帮助，因为许多设备可能不支持 4.6。Blackberry 上的另一个选项是 Persistent Store，它的记录大小限制为 64kb，但对存储的大小没有限制（设备的物理限制除外）。
我认为 Carlos 和 izb 是对的。
这很简单，使用 JSR75 (FileConnection) 并记住使用有效（受信任的）证书签署您的 midlet。
对于只读，我通过索引资源文件在可接受的时间（10 秒内）到达。我有两个 ~800KB CSV 价目表导出。程序类和这两个文件都压缩为一个 300KB 的 JAR。
在搜索时，我会显示 aList并在后台运行 a twoThread来填充它，因此第一个结果很快就会出现并且可以立即查看。我首先实现了一个简单的线性搜索，但这太慢了（约 2 分钟）。
然后我索引文件（按字母顺序排序）以查找每个字母的开头。现在在逐行解析之前，我首先InputStreamReader.skip()根据第一个字母到所需的位置。我怀疑延迟主要来自解压缩资源，因此拆分资源会进一步加快速度。我不想那样做，也不想失去易于升级的优势。CSV 无需任何预处理即可导出。
我刚开始为 JavaME 编写代码，但对旧版本的 PalmOS 有经验，其中所有数据块的大小都受到限制，需要使用记录索引和偏移量来设计数据结构。
感谢大家的有用评论。最后，最简单的解决方案是限制存储的数据量，实现代码根据存储的大小调整数据，如果数据没有存储在本地，则按需从服务器获取数据。有趣的是，在 OS 4.6 中增加了限制，如果幸运的话，我的代码会自行调整并存储更多数据 :)
在不使用 .cod 编译器的情况下为 Blackberry 开发 J2ME 应用程序会限制 JSR 75 的使用，因为我们无法签署档案。正如 Carlos 所指出的，这在任何平台上都是一个问题，我在使用它的 PIM 部分时也遇到过类似的问题。RMS 在黑莓平台上似乎非常慢，所以我不确定顶部的 inode/b-tree 文件系统会有多大用处，除非数据缓存在内存中并在低优先级后台线程中写入 RMS。