我想提到的第一件事是,我所写的基本纲要是：
– 请求一个URL(使用NSData -initWithContentsOfURL获取数据)
– 使用NSJSONSerialization JSONObjectWithStream将NSData解析为NSDictionary的NSArray
– 使用解码的数据的FMDB框架,在sqlite数据库中循环解码的NSArray插入/更新/删除记录

应用程序执行上述操作,但是它在一个不确定的时间段的循环中执行,其中应用程序显示“加载”HUD.我认为这可能值得一提,尽管我发现这个过程有多少次,但是如果它正确地释放就不会影响内存使用.如果我错了,请告诉我.

我的代码工作正常,好吧,它做的是做什么.但是,当我配置应用程序代码时,内存似乎只是继续上升.它总是落在片段中,但总体来说它不断上升(IE不会完全释放以前使用的).

如前所述,我分配了分配,漏洞,VM跟踪器的应用程序,并使用了Trace Highlights.

跟踪亮点：显示内存使用量逐渐上升,但是丢弃一些内存(并非全部)意味着如果进程运行时间足够长,内存将达到高使用率并终止.

分配：好的.配置有尖峰,但总是回到起始位置.我拍摄的照片,总是下降,每片段最多500-700kb(剩下约10分钟)

虚拟机跟踪器：证明显示内存一直在上升,并且不释放完整的内存(如跟踪亮点中所发现的).居民似乎真的很高

泄漏：应用中没有泄漏

以下是分配/ VM跟踪器的一些屏幕截图：

值得注意的是,我实际上已经尝试过：
– 添加autoreleasepools
– 通过分配每个属性“释放力”如NSURL,NSRequests等;到零

我的问题：
– 我应该做些特别的事情来释放记忆吗？
– 如何进一步调试这个问题？
– 如何最好地了解数据仪器给我的错误？

—-编辑：—-
以下是发送url请求以获取数据的代码：

- (void) requestAndParse : (NSString *)url 
{
    NSURL *theURL;
    ASIHTTPRequest *request;
    NSData *collectedData;
    NSError *error;
    @try {
                    // File cache the NSData
                    theURL = [[NSURL alloc] initWithString: url];
                    request = [ASIHTTPRequest requestWithURL: theURL];
                    [request setDownloadDestinationPath: [[NSHomeDirectory() stringByAppendingPathComponent:@"Documents"] stringByAppendingString:@"/cachefile.txt"]];
                    [request startSynchronous];
                    [request waitUntilFinished];

                    collectedData = [[NSData alloc] initWithContentsOfFile:[[NSHomeDirectory() stringByAppendingPathComponent:@"Documents"] stringByAppendingString:@"/cachefile.txt"]];


                    if ([collectedData length] > 0) {
                        records = [NSJSONSerialization JSONObjectWithData:collectedData options:NSJSONReadingMutableContainers error:&error];
                    }

    }
    @catch (NSException *exception) {

                    // Failed
                    NSLog(@"Parse error: %@",error);

    }
    @finally {

                    // DB updates with the records here
                    ...

                    // remove file
                    [[NSFileManager defaultManager] removeItemAtPath:[[NSHomeDirectory() stringByAppendingPathComponent:@"Documents"] stringByAppendingString:@"/cachefile.txt"] error:nil];
                    // release properties used
                    collectedData = nil;
                    request = nil;
                    theURL = nil;
    }

}

在Application Delegate中的一个while循环内调用这个上面的方法. while循环是一个不确定的长度,如前所述.

—编辑2：—

以下是@finally语句中发生的情况(使用FMDB更新sqlite数据库).在我的课上有很多这些方法,每个表都有一个.他们都遵循相同的模式,因为它们都是从第一个重复的：

-(BOOL) insertBatchOfRecords:(NSArray *)records {

__block BOOL queueReturned = YES;

@autoreleasepool {

    FMDatabaseQueue *dbQueue = [self instantiateDatabaseQueue];
    [dbQueue inTransaction:^(FMDatabase *tdb,BOOL *rollback) {
        if (![tdb open]) {
            NSLog(@"Couldn't open DB inside Transaction");
            queueReturned = NO;
            *rollback = YES;
            return;
        }

        for (NSDictionary *record in records) {
            [tdb executeUpdate:@"INSERT OR REPLACE INTO table (attr1,attr2) VALUES (?,?)",[record valueForKey:@"attr1"],[record valueForKey:@"attr2"]];

            if ([tdb hadError]) {
                queueReturned = NO;
                *rollback = YES;
                NSLog(@"Failed to insert records because %@",[tdb lastErrorMessage]);
                return;
            }
        }
    }];

    [dbQueue close];
    dbQueue = nil;

}

return queueReturned;
}

以下是-instantiateDatabaseQueue方法：

-(FMDatabaseQueue *) instantiateDatabaseQueue {
@autoreleasepool {
    return [FMDatabaseQueue databaseQueueWithPath: [self.getDocumentsDirectory stringByAppendingPathComponent:@"localdb.db"]];
}
}

autoreleasepools可能会使它凌乱,但代码最初没有这些.我在各个地方实施了他们,看看是否有任何改善(没有).

—编辑3 —

过去几天我一直在剖析这个申请书,还没有找到答案.我把这个应用程序的一部分分离出来,它是一个独立的项目,以确保它确实导致内存使用.这被证明是正确的,因为应用程序仍然是一样的.

我已经进行了进一步的剖析,但仍然很难确定实际上是错误的.看到下面的分配看起来不错(虚拟机对我来说看起来不是太糟糕了),还没有泄漏(没有图片,因为没有！)

然而,当我对Trace Highlights进行分析时,内存使用情况不断上升,直到达到太多的使用(3GS约70 MB),然后因使用这么多内存而崩溃.

我通过使用ASIHTTPRequest抓取NSData(存储到文件)来减少问题.请参阅上面修改的代码.但问题仍然存在,只需要更长的时间才能发生！

原来,问题：
– 这个应用程序进程的第二部分是否有问题？