【问题标题】:iOS Download & Parsing Large JSON responses is causing CFData (store) leaksiOS 下载和解析大型 JSON 响应导致 CFData(存储)泄漏
【发布时间】:2013-01-31 20:40:05
【问题描述】:

用户第一次打开我的应用时,我需要下载大量数据。我以 JSON 格式从服务器获取所有这些数据。根据用户的不同,这些 JSON 文件的大小可以从 10kb 到 30mb 不等,而且有 10 多个。

当 JSON 的记录不超过 500 条左右时,我这样做没有问题,但就像我说的那样,有些记录有 10,000 多条,大小可达 30mb。

下载较大的 JSON 时,我的应用程序分配了大量内存,直到我最终收到内存警告并且应用程序崩溃。

CFData 似乎必须是我在 didReceiveData 中构建的 NSMutableData。当我下载单个 JSON 时,CFData(存储)上升——当我开始解析时它停止上升。

如何在继续下载和解析下一个 JSON 之前清除该数据?

如下所示,内存中有 200mb 的 CFData(存储):

--

深入研究 CFData 并没有对我有太大帮助:

这是我创建操作以获取这些不同 JSON 的代码--

- (void)checkForUpdates
{
    if(!_globals)
        _globals = [MySingleton sharedInstance];

    MyAFHTTPClient* client = [MyAFHTTPClient sharedClient];
    NSString* path = [NSString stringWithFormat:@"cache?deviceUID=%@&token=%@",[_globals getMacAddress], [_globals getToken]];
    NSURLRequest* request = [client requestWithMethod:@"GET" path:path parameters:nil];

     _currentEnvironment = [_globals getActiveEnvironment];       

    if(!_currentEnvironment.didDownloadDataValue)
        [self setupAndShowHUDinView:self.view withText:@"Checking for updates..."];

    AFJSONRequestOperation* operation = [AFJSONRequestOperation JSONRequestOperationWithRequest:request success:^(NSURLRequest *request, NSHTTPURLResponse *response, id JSON) {

        for(NSString *str in [JSON valueForKey:@"Views"])
        {
            //for each table i need to update, create a request to
            NSString* path = [NSString stringWithFormat:@"cache/%@/?deviceUID=%@&token=%@", str, @"00000-00000-0000-00001", [_globals getToken]];
            NSURLRequest* request = [client requestWithMethod:@"GET" path:path parameters:nil];
            AFJSONRequestOperation* operation2 = [AFJSONRequestOperation JSONRequestOperationWithRequest:request success:^(NSURLRequest *request, NSHTTPURLResponse *response, id JSON) 
            {
                    // even if this is comment this out and I do nothing but download, app crashes
                    //[self updateTable:str withJSON:JSON];
            } failure:nil];

            [operation2 setSuccessCallbackQueue:backgroundQueue];
            [client.operationQueue addOperation:operation2];
            numRequests++;
        }
    } failure:^(NSURLRequest *request, NSHTTPURLResponse *response, NSError *error, id JSON) {

    }];

    [operation start];
}

CFData 是我在内存中的 JSON 响应吗?我试图清除我的 NSURLCache 但没有运气--

我还对 JSON 流式传输进行了一些研究。这对我减少内存中的对象数量有帮助吗?

除了我能想到的唯一其他选择是实现某种分页..但我需要我的用户拥有所有数据

非常感谢任何帮助/建议!谢谢!

--

编辑

好的,我决定使用剥离 AFNetworking 并尝试使用本机功能。在这样做时,我仍然得到相同的 CFData 版本。我正在使用this subclass of NSOperation,我正在创建/添加我的操作,如下所示:

 NSOperationQueue *operationQueue;
 operationQueue = [[NSOperationQueue alloc]init];
 [operationQueue setMaxConcurrentOperationCount:1];
 for(NSString *str in [views valueForKey:@"Views"])
 {

     NSString* path = [NSString stringWithFormat:@"%@cache/%@/?deviceUID=%@&token=%@", _globals.baseURL, str, @"00000-00000-0000-00001", [_globals getToken]];

     LibSyncOperation *libSyncOperation = [[LibSyncOperation alloc] initWithURL:path];
     [operationQueue addOperation:libSyncOperation];

 }

【问题讨论】:

    标签: ios memory-management out-of-memory nsoperationqueue cfdata


    【解决方案1】:

    我使用原生 JSON 转换函数处理海量数据,没有内存问题。

    我只是使用标准的NSURLConnection 来下载NSData 然后执行以下操作...

    NSData *data = [NSURLConnection sendSynchronous...
    
    // use NSDictionary or NSArray here
    NSArray *array = [NSJSONSerialization JSONObjectWithData:data ...
    
    Now deal with the objects.
    

    没有泄漏,因为它是本机功能。比第三方框架快很多。

    【讨论】:

    • 是的,我在考虑不使用 AFNetworking 并使用本地化.. 但我认为有人可能已经完成了我尝试使用 AFNetworking 所做的事情(老实说,我认为使用 AFNetworking 会比我尝试的更好完全编码)。明天我试试看——
    • 我在上面的问题中添加了一些新的信息和代码。即使不使用 AFNetworking,我仍然会看到问题。
    • 好的,我已经查看了您的 NSOperation 和 TBH 我不能 100% 确定发生了什么。不过,非常有用的是 XCode 中内置的静态分析器。尤其是在静态内存分配中发现泄漏(尤其是在像 CFData 这样的 Core Foundation 对象中)。试试看。而不是点击“运行”,按住并选择“分析”。
    • 我最终首先将 JSON 文件下载到磁盘——我没有使用 AFNetworking 就这样做了,它运行良好并且没有像以前那样泄漏。
    猜你喜欢
    • 1970-01-01
    • 2017-03-14
    • 1970-01-01
    • 2011-10-18
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-07-03
    • 1970-01-01
    相关资源
    最近更新 更多