Java中的内存映射zip文件

以下是我试图解决的问题：

我有大约100个二进制文件（总共158KB，它们的大小大致相同+/-50%）。我只需要有选择地解析其中的几个文件（在最坏的情况下可能是50个，在其他情况下只有1到5个）。顺便说一下，这是安卓设备上的

在Java中，最快的方法是什么

一种方法是将所有内容合并到一个文件中，然后使用file seek访问每个单独的文件。这样打开的文件只需要调用一次，通常速度很慢。但是，为了知道每个文件的位置，需要在文件的开头有某种表（可以使用脚本生成），但是文件也需要在表中按连接顺序进行索引，这样文件查找就不需要做太多工作（如果我错了，请纠正我）

更好的方法是将文件内存映射，这样表就不必按连接顺序排序，因为内存映射文件将具有随机访问权限（如果我错了，请再次更正）

如果使用zip压缩，那么创建该表将是不必要的，因为zip压缩已经生成了一个表。此外，不必连接所有文件。我可以压缩目录，然后通过压缩文件中的条目访问每个单独的文件。问题解决了

除非zip文件没有内存映射，否则读取速度会慢一些，因为系统调用比直接内存访问慢（如果我错了，请纠正我）因此我得出结论，最好的解决方案是使用内存映射的zip存档。

但是，

ZipFile

条目返回一个

InputStream

来读取条目的内容。而

MappedByteBuffer

需要一个

RandomAccessFile

，它以文件名作为输入，而不是

InputStream

是否有内存映射zip文件以进行快速读取？或者对于读取选定文件的问题是否有不同的解决方案

谢谢

编辑：我测试了文件的打开、关闭和解析速度。以下是我发现的统计数据：

文件数：25个（24个用于解析，因为垃圾收集中断了计时）

总打开时间：72ms

总关闭时间：1ms

总解析时间：515ms

（这有利于Parse，因为Parse缺少一个文件）

%总打开时间：12%

%总关闭时间：0.17%

%总分析时间：88%

每个文件的平均打开时间：2.88ms

每个文件的平均关闭时间：0.04ms

---

每个文件的平均解析时间：21.46ms

我现在会使用一个简单的api，如果您真的需要，可以重新讨论这个问题

---

编辑-我不知道

MappedByteBuffer

。这似乎是一条路要走。为什么不先对单独的文件执行此操作，然后再考虑以后合并它们？

感谢MappedByteBuffer上的提示！我认为你的瓶颈不会是打开文件。在硬盘上，这需要时间——你必须寻找并等待东西旋转到位。对于固态内存，它应该是不相关的。您可能已经拒绝了此选项，但是您是否尝试过将数据存储在数据库中，以某种不需要单独解析的形式？你对这个问题的描述听起来很像数据库为你做的事情。我认为瓶颈在于文件的打开和关闭操作，而不是文件的实际读取，虽然我还不确定，因为我还没有测试过——也许使用

MappedByteBuffer

单独读取每个文件是个好主意，我想是的。至少那时你会知道打开/关闭的实际开销是多少。