iphone - 将大量数据从 iPad 转换/上传到 Dropbox

Question

我正在通过 Instruments 运行它并用大量数据对其施加压力来完成我的应用程序。仪器测试进行得很顺利，但压力测试是我遇到问题的地方。在不涉及太多细节的情况下，我给我的应用增加了 Core Data 的数量。它需要用来推断数据、制作图表和在 MKMapView 上显示位置的事件实例。我开始很小，然后增加到 56000 个事件，它处理得很好，没有任何泄漏或内存警告(我为处理这一切感到非常自豪)。

我的应用实现了 Dropbox API 以允许上传和下载用于同步目的的模板和数据。从我的应用程序上传的文件是从 Core Data 转换而来的到 NSDictionary ，然后到 NSData .我为数据创建了一个临时文件夹，然后将该文件上传到 Dropbox，它正常工作......如果我尝试上传包含 56000 个事件的数据文件，它就会崩溃。我已经记录了它并观察了数据的转换。它顺利到达最后一个事件，但是当它应该开始上传到 Dropbox 时，应用程序崩溃了，我终生无法弄清楚原因。我看到我的日志上弹出内存警告。通常，它会去 Level=1、Level=2、Level=1、Level=2，然后崩溃，这让我很困惑，因为它永远不会达到 Level=3。

我找到的大部分信息都在我在底部的编辑中。下面是一些相关的代码:

- (void)uploadSurveys:(NSDictionary *)dict {
    NSArray *templateArray = [dict objectForKey:@"templates"];
    NSArray *dataArray = [dict objectForKey:@"data"];
    NSString *filename;
    NSLog(@"upload called");
    if ([templateArray count] || [dataArray count]) {
        if ([templateArray count]) {
            // irrelevent code;
        }
        if ([dataArray count]) {
            SurveyData *survey;
            for (int i = 0; i < [dataArray count]; i++) {
                BOOL matchExists = NO;
                // ...... code to make sure no file exists in dropbox folder and creates new version if necessary;

                dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
                NSData *data = [self convertSurvey:survey];
                dispatch_async(dispatch_get_main_queue(), ^{
                    [self uploadData:data withFilename:filename];
                    NSLog(@"converted and uploading");
                });
            });
        }
    }
}

[self convertSurvey:survey]简单地转换我的 Core Data反对 NSData .

- (void)uploadData:(NSData *)data withFilename:(NSString *)filename {
    NSFileManager *manager = [NSFileManager defaultManager];
    NSString *pathComponent = [NSString stringWithFormat:@"tempData.%@", filename];
    NSString *path = [NSTemporaryDirectory() stringByAppendingPathComponent:pathComponent];
    if ([manager createFileAtPath:path contents:data attributes:nil]) {
        [self.restClient uploadFile:filename toPath:[NSString stringWithFormat:@"/%@", currentSearch] fromPath:path];
        NSLog(@"uploading data");
    }
}

任何帮助都会非常感谢，我在此先感谢您。我只是想弄清楚我是否对大文件采取了错误的方法，或者是否根本不允许这样做。如果我必须拆分文件，那很好，但是在我尝试解决方法之前，我更想知道是什么阻止了我的应用程序执行此操作。再次感谢你。

更新:由于这个问题现在是我的应用程序发布的唯一障碍，我正在向这个问题添加一个悬赏以希望得到解决方案或变通方法。它将持续一周，之后给定的时间，我很可能会在上传文件时将它们分开，以确保不会达到这个明显的大小限制。这种方法并不理想，这就是为什么更好的解决方案很受欢迎的原因，但如果这不能带来更方便的东西，这是我的备用计划。

编辑:看来 NSTemporaryDirectory根本不参与其中。这是新的情况。正如你在上面的代码中看到的， NSData *data = [self convertSurvey:survey];在辅助线程中调用(这不是问题)。我一直在记录创建的对象并知道它们已经到达最后一个，但从未想过检查 NSData文件被退回。事实证明，事实并非如此。简而言之，我将所有 Core Data 对象转换为数组并将它们放入字典中(仅用于要转换的相关调查/数据)。这确实有效，并且创建了字典。然后我创建了一个 NSData文件使用 NSData *data = [NSKeyedArchiver archivedDataWithRootObject:d];哪里 d是我的字典。在那之后，我直接调用了 return data;设置 NSData *data = [self convertSurvey:survey]; 的值.既然如此，看来 NSData或 NSKeyedArchiver错在这里。根据苹果文档:

Using 32-bit Cocoa, the size of the data is subject to a theoretical 2GB limit (in practice, because memory will be used by other objects this limit will be smaller); using 64-bit Cocoa, the size of the data is subject to a theoretical limit of about 8EB (in practice, the limit should not be a factor).

我已经以小增量检查了文件大小，以查看发生故障的位置。我已经成功地通过了 48.2MB 的数据，但不是 51.5MB，这让我相信问题发生在 50MB 左右，远低于 NSData 的理论限制。 (除非 iOS 和 OS X 在这方面存在差异)。

希望这些新信息有助于解决这个问题

Answer 1

NSData 的 2 GB 限制在 iOS 上完全是理论上的，即使 iPhone 4 只有 512 MB 的 RAM 并且 iOS(与 Mac OS X 不同)无法交换，因此如果您的物理 RAM 已满，您将崩溃(或者您的应用程序在此之前被终止)那)。

50 MB NSData对象本身已经非常大，而且它不是您内存中唯一的对象——假设您将数据从 Core Data 转换为字典表示，然后转换为 NSData ，您可能至少消耗两倍的内存(可能更多)。系统和其他应用程序也需要 RAM，因此您可能已达到限制。

尝试在 Instruments 中运行您的应用程序以查看您实际消耗了多少内存。

为了减少峰值内存使用量，您有几个主要取决于您的数据模型的选项:

如 Jason Foreman在他的回答中建议，尽量避免一次将整个文件放入内存中。使用 NSFileHandle ，您可以将数据块写入文件，而无需一次将整个数据保存在内存中。当然，这需要您相应地准备数据，以便将其拆分为多个块。更高级别的方法可能是将您的数据序列化为 XML 格式，您可以将其作为流写出。如果您的数据格式非常简单，CSV 之类的格式也可能适用。

请勿使用 NSData用于上传到 Dropbox。改为将您的数据写入文件(见上文)并将 Dropbox SDK 指向该文件。 Dropbox SDK 可以很容易地做到这一点(DBRestClient 有一个 uploadFile:toPath:fromPath: 方法)。

如果您的数据模型难以采用流式方法，请尝试将数据分割成更易于管理的部分。然后，您可以使用旧的字典序列化方法，只需使用多个文件。

小心 Core Data 的内存使用。尝试使用 refreshObject:mergeChanges: 重新故障对象如果可能的话，打破数据中的循环引用(查看 Core Data Programming Guide 了解详细信息)。

避免在长时间运行的循环中使用自动释放池或创建单独的 NSAutoreleasePool在循环的每次迭代中都会耗尽。