在我的测试Android应用程序中，我需要处理一个大文件，例如压缩、加密、删除编码等...
为了加快这个过程，我产生了多个线程，每个线程读取和处理文件的不同部分，最后将结果合并/附加在一起。 (使用 Java NIO)
我已经尝试过了，确实有一些加速，50% 或更多，具体取决于所涉及的存储技术。
这个上面有很多类似的SO问题，但他们主要讨论的是由于单个旋转硬盘的限制，它不会提高I/O速度。
但就我而言，它是在使用闪存的多核 Android 设备上。
因此，我不确定加速是由于并行处理还是由于 RAM 中的缓存。
我的主要问题是:
我做对了吗？ (因为我使用的是多核 Android 设备)
还是这种方法不好？坏在什么方面？
鉴于其他系统上的互操作性(压缩、加密)在这里不是问题。
更多详情:
我也以某种方式使用流水线的概念。
例如:
i) [Sequential] 压缩然后加密文件需要 10 + 20 = 30 秒，
ii) [Pipelining] 压缩文件的前半部分，压缩完成后立即开始加密。同时开始压缩文件的后半部分，压缩完成后最后对后半部分进行加密。可能只需要 20 秒。
(我知道这是一个不好的例子，但只是为了给出将存储技术应用到管道中的想法)
我不确定这一点，但由于文件的每个 block 都不依赖于前一个 block (没有数据依赖性问题)，流水线化文件应该没问题吧？
最佳答案
它是否真的会加速你的程序取决于很多因素。这包括——文件是在 RAM 中还是在磁盘上？如果它在磁盘上是程序 IO 绑定(bind)或 CPU 绑定(bind)(如果 IO 绑定(bind)那么它不会帮助)？操作系统的调度器实际上是如何分配线程的——它是将它们分配给同一个内核还是多个内核？不同的线程是否需要交互(它们是否会等待锁定太长时间以致于它不是加速或非常错误)？
您的技术是一种相当标准的并行处理技术。它是否适合您的应用程序需要大量的实现和检查。
关于android - 将大文件分成 block 并在单独的线程中处理每个 block ，加快速度？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/18177046/