ios - LZMA SDK 为 iOS (xcode) 解压缩使用太多 RAM

Question

我正在尝试在 iPhone/iPad 应用程序中使用 LZMA SDK，我的起点是 Mo Dejong 提供的适用于 iPhone 的 LZMA 示例项目，可在此处获取: https://github.com/jk/lzmaSDK 原件在这里:http://www.modejong.com/iOS/lzmaSDK.zip (我都试过了，结果都一样)。

问题是提取物使用的 RAM 与 .7z 包含未压缩的 RAM 一样多。换句话说，假设我有一个 40MB 的压缩文件，未压缩的文件是一个大约 250MB 的二进制 sqlite DB，它会慢慢地用掉越来越多的内存，因为它将文件一直解压缩到 250MB。这将使 iPad1 或 iPhone4(256MB RAM)之前的任何东西崩溃。我感觉很多人最终都会遇到同样的问题，因此现在的解决方案可以帮助很多开发人员。

我最初使用基于 Windows 的 7-zip(最新版本)和 16MB 字典大小在 PC 上创建了 .7z 文件。它应该只需要 18MB 的 RAM 来解压缩(在查看任务管理器的 PC 上进行测试时就是这种情况)。我还尝试使用 keka(开源 mac 存档器)创建存档，但它没有解决任何问题，尽管我可以确认 keka 本身在 mac 上提取文件期间仅使用 19MB 的 ram，这是我所期望的。我想下一步是将 Keka 的源代码与 LZMA SDK 的源代码进行比较。

在创建 .7z 文件时，我试过不同的字典大小和其他设置，但没有任何帮助。我还尝试在压缩之前将我的单个二进制文件拆分为 24 个较小的部分，但这也无济于事(仍然使用超过 250MB 的 RAM 来提取 24 个部分)。

请注意，我对原始代码所做的唯一更改是使用更大的 .7z 文件。另请注意，提取完成后它会立即释放 RAM，但这无济于事。我觉得它并没有像它应该提取的那样释放 RAM，或者它将整个内容放入 RAM 中，直到完成后才将其移出 RAM。此外，如果我尝试使用 mac 应用程序提取完全相同的文件，同时运行仪器，我看不到相同的行为(例如 StuffIt Expander 在提取文件时最大内存约为 60MB，Keka，开源 mac存档器最大内存为 19MB)。

我(目前)还不是 mac/xcode/objective-c 开发人员，因此非常感谢任何帮助。我可以改用 zip 或 rar，但我使用 LZMA 获得了更好的压缩，所以如果可能的话我想坚持使用这个解决方案，但显然我需要让它在不崩溃的情况下工作。

谢谢!

Answer 1

7zip 的作者 Igor Pavlov 给我发了电子邮件，他基本上说我在原始问题中所做的观察是 SDK 的 c 版本的已知限制。 C++ 版本没有此限制。实际报价:

“7-Zip 使用另一个用 C++ 编写的多线程解码器。该 C++ .7z 解码器不需要为整个实体 block 分配 RAM block 。另请阅读此线程:

http://sourceforge.net/projects/sevenzip/forums/forum/45797/topic/5655623 "

因此，在有人修复适用于 iOS 的 SDK 之前，解决方法是:

1) 确定文件解压缩操作的 RAM 限制。

2) 存档中超过 1 限制的任何单个文件都必须拆分，您可以使用任何二进制拆分器应用程序执行此操作，例如拆分: http://www.fourmilab.ch/splits/

3) 文件准备就绪后，使用 MoDJ 在他的回答中描述的字典/ block 大小选项创建 7z 文件，例如限制为 24 兆: 7za a -mx=9 -md=24m -ms=24m CompressedFile.7z 源文件*

4) 在您的 iOS 应用程序中，解压缩文件后，确定哪些文件已拆分，然后再次将它们连接起来。代码并没有那么复杂(我假设 splits.exe 使用的命名约定是 file.001、file.002 等)

    if(iParts>1)
    {
        //If this is a multipart binary split file, we must combine all of the parts before we can use it
        NSString *finalfilePath = whateveryourfinaldestinationfilenameis
        NSString *splitfilePath = [finalfilePath stringByAppendingString:@".001"];

        NSFileHandle *myHandle;
        NSFileManager *fileManager = [NSFileManager defaultManager];
        NSError *error;

        //If the target combined file exists already, remove it
        if ([fileManager fileExistsAtPath:finalfilePath]) 
        {
            BOOL success = [fileManager removeItemAtPath:finalfilePath error:&error];
            if (!success) NSLog(@"Error: %@", [error localizedDescription]);
        }

        myHandle  = [NSFileHandle fileHandleForUpdatingAtPath:splitfilePath];
        NSString *nextPart;
        //Concatenate each piece in order
        for (int i=2; i<=iParts; i++) {
            //Assumes fewer than 100 pieces
            if (i<10) nextPart = [splitfilePath stringByReplacingOccurrencesOfString:@".001" withString:[NSString stringWithFormat:@".00%d", i]];
            else nextPart = [splitfilePath stringByReplacingOccurrencesOfString:@".001" withString:[NSString stringWithFormat:@".0%d", i]];
            NSData *datapart = [[NSData alloc] initWithContentsOfFile:(NSString *)nextPart];
            [myHandle seekToEndOfFile];
            [myHandle writeData:datapart];
        }    
        [myHandle closeFile];
        //Rename concatenated file
        [fileManager moveItemAtPath:splitfilePath toPath:finalfilePath error:&error];
    }