これはかなりシンプルなインターフェースで、appdelegate と viewcontroller だけが処理を行います。
指定された患者の 1 ～ 13 個の画像サムを表示する UITableView があります。親指を表示するために、単一の UIImageView を含むカスタム セルを使用しています。セル内の UIImageView は、HTTP リクエスト経由で読み込まれた NSMutableArray から cellForRowAtIndexPath に読み込まれます。
HTTP サーバー上の各患者のサムは、1 ～ 3 個の名前付きシリーズ フォルダーにグループ化された患者フォルダーにあります。iPad の popOver から患者が選択されると、サム テーブル ビューには、HTTP サーバーの患者フォルダーで見つかった最初のシリーズが読み込まれます。
ユーザーは、シリーズ名の popOver から患者の別のシリーズを選択できます。その時点で、選択したシリーズのサムが HTTP リクエストを介して取得され、サム テーブル ビューにロードされます。
患者のポップオーバーから患者を選択した後に最初のシリーズが取得された患者が 1 人いることを除いて、すべて正常に動作しますが、シリーズを変更するか、既に読み込まれているシリーズを再選択すると、アプリがクラッシュします。シミュレーターではクラッシュせず、iPad のみがクラッシュします。xCode から実行すると、cellForRowAtIndexPath への最後の呼び出しがコンソールにエラーを表示せずに終了した後にクラッシュが発生することがわかります。そのポイントを超えると、すぐにクラッシュします。
appdelegate メソッドと viewController メソッドの両方にメモリ警告デリゲート メソッドを実装しました。メモリの警告は表示されません。
テーブルビューをロードするときに何かが足りない場合に備えて、cellForRowAtIndexPath メソッドを以下に投稿しています。
私は、記憶以外に何を疑うべきかについての提案を探しています。コンソールなしでクラッシュの原因を突き止める方法はありますか?
助けてくれてありがとう
ジョン
更新:セクションメソッドに行数を追加しましたが、これは問題になりません。
問題は必ずしも私のコードではなく、画像にあると確信しています。この 1 人の患者を除いて、患者や患者の画像シリーズを 1 日中問題なく変更できます。この患者に関連付けられた 1 つまたは複数の画像に関する何かが、iPad のメモリを消費しています。各患者は、元のサイズが 1 ～ 2 メガバイトの X 線を 1 ～ 2 枚持っています。iPad で取得できるようにディスク ファイルに保存するときに、ファイル サイズ (圧縮品質) を 300kb 未満に減らしています。1 つのシリーズでインポートされる合計は 1.5 MB 以下です。少なくとも、それはディスク ファイル サイズの合計です。iPadがファイルサイズを取得すると、ファイルサイズに実際に何が起こっているのかわかりません。
インポートした画像をテーブル ビューにロードして表示する前に、インポートした画像のサイズや破損をテストする方法はありますか?
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
static NSString *CellIdentifier = @"Cell";
ImageCell *cell = [thumbsTableView dequeueReusableCellWithIdentifier:CellIdentifier];
if (cell == nil) {
cell = [[[ImageCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier] autorelease];
}
cell.pImage.image = [thumbsArray objectAtIndex:indexPath.row];
return cell;
}
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section
{
return [thumbsArray count];
}