Question

这是前面两个问题的背叛。我正在使用快照来检查我的内存在提交到应用程序商店之前的行为，我发现每次用户完成程序循环时它会增加3-5KB。我回到绘图板，评论了程序的大部分内容，然后慢慢将这些部分重新上线。我能够把它缩小到我认为是问题的核心。

我会注意到：我转换为ARC并仍然遇到同样的问题。这是（我相信）相关的代码区域。

行类：

@interface Row : NSObject {
int rowID;
NSString *rowProblem;
NSString *rowAnswer;
int rowTimes_Right;
int rowTimes_Wrong;
Boolean marked;
}

@property (nonatomic) int rowID;
@property (nonatomic, copy) NSString *rowProblem;
@property (nonatomic, copy) NSString *rowAnswer;
@property (nonatomic) int rowTimes_Wrong;
@property (nonatomic) int rowTimes_Right;
@property (nonatomic) Boolean marked;

数据库功能（获取一行）：

-(Row *) getRow {
Row *holder = [[[Row alloc] init] autorelease];

//Pick a random problem to give to the User
int randomrow = (arc4random() % [self getNumberOfRows]) + 1;



NSString *querysql = [NSString stringWithFormat:@"SELECT * FROM problems WHERE id = %d", randomrow];

const char *sql = [querysql UTF8String];    
sqlite3_stmt *statement;

//Execute the Query
if (sqlite3_prepare_v2(wordsDB, sql, -1, &statement, NULL) == SQLITE_OK)
{

    while (sqlite3_step(statement) == SQLITE_ROW) 
    {
        char *problem = (char *)sqlite3_column_text(statement, 1);
        char *answer = (char *)sqlite3_column_text(statement, 2);

        holder.rowID = sqlite3_column_int(statement, 0);
        holder.rowProblem = [NSString stringWithUTF8String:problem];
        holder.rowAnswer = [NSString stringWithUTF8String:answer];
        holder.rowTimes_Right = sqlite3_column_int(statement, 3);
        holder.rowTimes_Wrong = sqlite3_column_int(statement, 4);
        holder.marked = sqlite3_column_int(statement, 5);

    }

    sqlite3_finalize(statement);
}
else
{
    NSLog(@"SQL Error Message: %s", sqlite3_errmsg(wordsDB));
}

return holder;
}

在视图中将所有内容捆绑在一起：

-(void)setToWord{
[currentRow release];
 currentRow = [[dataB getRow] retain];

[problemLabel setText:currentRow.rowProblem];
[definitionLabel setText:currentRow.rowAnswer];
}

任何想法都会非常感激。

Answer 1

我不担心5KB的泄漏。苹果公司自己的可可程序在这个程度上是漏洞，苹果显然不担心它。例如，在我的一个简单的应用程序中，我们将视图控制器推到导航控制器上，然后再将其弹出，仪器显示我的所有物体都被正确拆除，但是有一点点泄漏，显然来自内部深处可可。您应该能够非常清楚地看到使用Instruments，生成每个快照中遗留的对象的代码是否是您的代码。您可以尝试在getRow中包裹@autoreleasepool{}方法的内部，但我怀疑它会有所不同。

Answer 2

好的，这通常是令人沮丧的。在之前的两个问题中，您都会发布详细的堆栈跟踪。这是仪器向您展示的一件不太有趣的事情。

选择程序中的任何一点 - 当它运行时它使用内存 - 这是堆栈，你不需要仪器告诉你。

仪器可以显示应用程序中所有活动对象的计数 - 从快照到快照的增加不应该是什么？可能会意外地拥有您认为已被破坏的物体，徘徊，泄漏，但不会泄漏，因为从技术上讲，它们仍然可以从某个地方到达。如果您发现一个泄漏或者不存在的对象，那么创建它的行的堆栈跟踪并不重要，这就是为什么它没有被清除？你在哪里忘了释放或免费？仪器将显示每个对象的保留历史记录，以便您可以在不平衡保留或清理财产的地方找到工作。

这只是基本的乐器内容，即使是我也很容易接受。

作为旁注。虽然框架确实很少有泄漏，但是对于我来说，更常见的是在Leaks中表现出一个错误，因为在某些框架中会泄漏一大块字节。

自定义类+数据库调用导致内存上升？

2 个答案: