私が取り組んでいるプロジェクトは、リリース構成でビルドするとクラッシュします。
レビューのためにアプリケーションをアップルに送信する必要があり、アプリに入る前にクラッシュしています。
それがどのように起こり得るかについて何か考えはありますか?
最後のリゾートでは、いくつかの最適化を備えたアプリのデバッグバージョンをアップルに送信することは可能ですか?
ありがとう。
私が取り組んでいるプロジェクトは、リリース構成でビルドするとクラッシュします。
レビューのためにアプリケーションをアップルに送信する必要があり、アプリに入る前にクラッシュしています。
それがどのように起こり得るかについて何か考えはありますか?
最後のリゾートでは、いくつかの最適化を備えたアプリのデバッグバージョンをアップルに送信することは可能ですか?
ありがとう。
私の経験では、iPhoneなどの非デバッグビルドとデバッグビルドのクラッシュを追跡するのが難しい10回のうち9回は、メモリ管理のバグが原因です。私はあなたの問題が不適切に配置されたリリースまたは保持メッセージ、またはその欠如によって引き起こされていることにお金をかけます。まだ試していない場合は、デバッグビルド構成で静的アナライザーをオンにします(私のXCodeは現在更新中ですが、ビルドプロパティで「analyzer」または「clang」を検索すると、適切なものが見つかるはずです。設定)そしてそれが何かを指しているかどうかを確認します。そうでない場合は、Instrumentsを使用して問題をチェックしたり、デバッガーで問題のある領域を特定したりできます。
デバッグ構成を変更するか、リリースビルドで発生するものとより厳密に一致する別のコンパイラフラグのセットを使用するように複製することで、実際にはリリースビルドではない問題を再現するのに役立つ場合があります(私はしません違いが頭から離れていることを思い出してください。ただし、コンパイラフラグに「-O2」を追加すると、ほとんどの場合そこに到達すると思います)。
私の最初のiPhoneアプリをビルドするときにも同じことが起こりました。プロジェクトでしばらく作業した後、デバッグからリリースに切り替えるとアプリがクラッシュしました。プロジェクトを完全にクリーンに再構築し、テスト用の電話からアプリを削除して再インストールすると、アプリが実行されました。XCodeが必要なものすべてをクリーンアップ/再構築しない場合があるように見えました。
リリース構成でビルドする場合は、.dSYM ファイルとアプリケーション バンドルのコピーを保持してください。
次に、デバイスでアプリケーションがクラッシュしたら、Xcode にプラグインして、クラッシュ レポートをダウンロードします。
Xcode を開き、Xcode 内からオーガナイザーを開きます。そこから、デバイスからのクラッシュ レポートを表示できます。
クラッシュ レポートは、.dSYM ファイルとアプリケーション バンドルを保存した場合にのみシンボル化されます。
その後、クラッシュ レポートを使用してクラッシュの原因を特定し、修正することができます。
クラッシュ ログを確認する必要があります。オーガナイザーを開き、デバイスを選択してから、[クラッシュ ログ] タブを選択します。下にスクロールして、アプリのログを見つけます。スタック トレースを確認できるように、シンボル化する必要があります。
アプリを実際にデバッグしないと、それ以上のことを言うのは非常に困難です。#ifdef DEBUG マクロを使用していますか? 複数のスレッドを使用していますか? デバッグ モードでの実行を遅くする NSLog ステートメントが多数ある場合、これにより微妙なタイミングの違いが発生し、マルチスレッド アプリに影響を与える可能性があります。
デバッグ バージョンで 'make clean' を試しましたか? プロジェクトの一部が再構築され、他の部分が変更されていない場合、あいまいなバグが隠されることがあります。