Android 安卓2.2：从大文件中读取小块二进制数据的最佳方法？

我正在为安卓2.2开发

默认情况下，放入res和assets的内容在APK中被压缩，除非它们的扩展名表明它们已经被压缩（mp3、png）。此外，在Android2.3之前，对于资产，您只能放置大小小于1MB的未压缩文件

问题1： 如果我把一个1.5MB的二进制文件放到res/raw中，我的程序用它的标准Android ID（R.raw…）引用它，那么系统会将整个文件拉入内存吗？由于1.5MB是以压缩的方式存储的，我想它一定是。这是令人不快的，因为程序可能只需要从给定的文件偏移量加载1KB的数据。这可能会对应用程序性能/速度产生严重影响

我看到两种解决办法：

（黑客）使用mp3或png扩展；但我不确定这是否允许内存高效访问（即inputstream.skipbytes等）

安装后，在应用程序的第一次启动时，应用程序会将文件复制到自己的可写工作文件夹（SD卡中）。由于这一点，它将始终从那里访问文件，而不是R.raw。。。对。因此，顺序读取肯定会工作，即内存使用量不会超过从指定文件偏移量读取的实际数据（inputstream.seek实现使用的临时读取缓冲区除外，这些缓冲区经过了很好的优化，即我认为很小）

问题2：

---

从大文件中高效读取二进制数据存储器的最佳方法是什么？我不想把我的大文件分成许多小文件，除非这是唯一的方法。

我会选择#2解决方案，然后使用随机访问文件来避免线性访问。

我也会选择解决方案#2，但不是使用随机访问文件，我将使用java.nio.MappedByteBuffer——这样您将获得具有字节缓冲语义的快速随机访问

顺便说一句，我可以将连续读取优化为顺序读取（由于程序语义的原因，无需任何努力）。也就是说，打开FileInputStream后，我可以解决它总是以递增的偏移量读取，不需要向后查找。在这种情况下，FileInputStream（没有seek）是合适的，因为我可以通过skipBytes（）解决所有seek问题。在这种情况下，RandomAccessFile比FileInputStream有什么好处吗？（也许.seek比skipBytes好，因为它使用底层操作系统函数而不是读取整个文件？）从实现（请参阅）来看，它似乎也是通过seek实现的

skip（）

。因此，在您的情况下，坚持使用

FileInputStream

可能是一个好主意。听起来不错，但因为我也需要从字节中键入读取（readInt（）等），而且我不需要编写，所以我认为FileInputStream/RandomAccessFile更合适。考虑到性能，我假设如果RandomAccessFile比FileInputStream快，那么RandomAccessFile应该和MappedByteBuffer一样快（只是使用不同的机制）。不确定。从字节缓冲区获取原语只是一个包装器方法调用，速度非常快，并且没有流带来的开销（但它必须对齐，并且必须考虑字节顺序）