2

非常に優れた本「Beginning iPhone Development」(Apress) の第 9 章で、ナビゲーション コントローラと階層テーブル ビューを使用してアプリケーションを構築する方法を説明しています。
Instrument/Activity モニターを使用してアプリケーションを起動すると、アプリケーションは正常に動作しますが、大きな問題があります。テーブル ビューから子テーブルにドリルダウンするたびに、1Mo 以上のメモリが必要になります。このメモリは決して解放されず、もちろん最後にアプリケーションがクラッシュします。私にとって、問題は「RootViewController.h」の次のメソッドから発生します: (元のソース コードは、このZIP ファイル
の「09 Nav」です)

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath {
    NSUInteger row = [indexPath row];
    SecondLevelViewController *nextController = [self.controllers objectAtIndex:row];

    NavAppDelegate *delegate = [[UIApplication sharedApplication] delegate];
    [delegate.navController pushViewController:nextController animated:YES];

}

このメソッドでは、「nextcontroller」が解放されることはありません。コマンド [nextController release] を使用するため。次の変更を加えました。

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath {
    NSUInteger row = [indexPath row];
    SecondLevelViewController *nextController = [[SecondLevelViewController alloc] init ];
    nextController = [self.controllers objectAtIndex:row];
    NavAppDelegate *delegate = [[UIApplication sharedApplication] delegate];
    [delegate.navController pushViewController:nextController animated:YES];
    [nextController release];
}

これで、アプリケーションを実行すると、メモリが十分に解放されます! しかし、すでに "訪問" した子テーブルをドリルダウンしようとすると、アプリケーションがクラッシュします。

どうすればメモリを適切に解放できますか?
前もって感謝します。

4

3 に答える 3

1

Clang チェッカー ( http://clang.llvm.org/StaticAnalysis.html ) を使用してソース コードをチェックすると、3 つのリークがあることがわかります。

1) PresidentDetailController.m、オブジェクト NSIndexPath *newPath (75 行目) は解放されません 2) PresidentDetailController.m、オブジェクト UITextField *textField (166 行目) は解放されません 3) PresidentsViewController.m、オブジェクト PresidentDetailController *childController (86 行目) ) はリリースされません

あなたが提案するのはリークではありません。ソース コードへの変更が、アプリケーションのクラッシュの原因です。Clang チェッカーの使用は非常に簡単です。

http://clang.llvm.org/StaticAnalysisUsage.html#BasicUsage

敬具

于 2009-04-15T22:21:15.857 に答える
1

「Clang Checker」というツールを知りませんでした。テストに時間を割いていただき、ありがとうございます。「Clang Checker」はとても強力なようです。試してみます。

私はあなたに完全に同意します RootViewController:"nextController" はリークではありませんが、メモリを食べる人です。Instrument/Activity モニターを使用してアプリケーションを実行すると、最初はアプリケーションに 7 Mo かかり、子テーブルに移動するたびに 1 Mo のメモリが必要になります。

  • 10回後、アプリケーションは17Moかかり、
  • 20回後、アプリケーションは27 Moかかります

そのため、最後にアプリケーションがクラッシュし (よく覚えていれば、アプリケーションは 40Mo 以上かかることはありません)、このアプリケーションはメモリ管理に関して Apple の規則に従っていません。

私の修正では、子テーブルに移動すると 1Mo のメモリが必要ですが、「ルート」テーブルに戻ると 1Mo のメモリが解放されます。別の子テーブルに移動して戻ってくると、メモリが解放されます。「唯一の」問題は、既にアクセスした子テーブルに再度アクセスすると、アプリケーションがクラッシュすることです。そのため、子テーブルにアクセスした後にアプリケーションに強制的にメモリを解放させるソリューションを探しています。

確認のため、Instrument/Activity モニターで、Apple Settings アプリ（階層テーブルビューアプリも）が使用するメモリをたどってみました。バック、メモリが解放されます。

于 2009-04-16T08:14:50.640 に答える