15

TestFlightを使用して、アプリのパイロットを送信しています。

アプリの一部がクラッシュしていて、クラッシュを再現するのに多くの問題がありました。彼らのコードはかなり単純です。

TestFlightを介してアプリを入手したユーザーはクラッシュしますが、アプリをビルドしてIDEを使用してインストールすると、クラッシュしません。

誰もがこれを引き起こしている可能性があるものについての考えを持っていますか?

回避策のアイデアはありますか?TestFlightの使用をやめたくありません。

4

3 に答える 3

12

デバッグではなくリリースモードでアプリをビルドしてください。アプリはリリース時にのみクラッシュする可能性があります。

于 2012-08-30T08:45:26.810 に答える
5

私が最初に試みることは、クラッシュスタックトレースをアプリケーションの関数名にマップすることです。これにより、クラッシュの性質に関する有用な洞察が得られる可能性があります。

  1. クラッシュが報告されたらすぐに、クラッシュログを要求します。これはXcodeのオーガナイザーから取得できます。それがオプションでない場合は、iPhoneの[設定]->[一般]->[バージョン情報]->[診断と使用法]->[診断と使用法のデータ]から画面をキャプチャできます。アプリ名またはセクションLatestCrash-AppName.plistまでスクロールします。
  2. 理論的にはクラッシュを象徴することができますが、スタックからシンボルを取得するための確実な方法として、以下に説明する手順を見つけました。クラッシュするスレッドのすべてのスタックアドレスをメソッド名に変換します。
  3. オプションで、iDevicesyslogを要求します。これには、アサーション失敗メッセージが含まれる場合がありますが、これも非常に重要です。これは、syslogが削除される前に非常に多くのエントリしか保持しないため、できるだけ早く実行する必要があることに注意してください。これを取得するには、オーガナイザーまたはcmd行idevicesyslogを使用できます。

手動シンボル化:これは、ビルドにデバッグ情報がある限り機能します。

  1. クラッシュした_exact_same_.ipaを取得します。保存しなかった場合は、iFunBoxまたはcmd行ideviceinstallerユーティリティを使用してデバイスからダウンロードできます。
  2. .ipaを解凍します
  3. 実行可能ファイル(Payload / AppName.app / AppName)に対して次のコマンドを実行します。

    otool -tv AppName.app | c ++ filt> Listing.asm

  4. 前の手順が完了するまで待ちます(しばらく時間がかかる場合があります)。生成されるlisting.asmファイルの長さは数メガバイトになります。

  5. 大きなファイルを処理できるエディターを使用して、listing.asmでスタックトレースにリストされているアドレスを検索します。アドレスが数バイトずれている可能性があることに注意してください(通常は3バイトほど先を指しています)。また、listing.asmにないアドレスは、iOSライブラリのアドレスを示します。今のところそれらを無視してください。

もちろん、象徴化できる場合は、この手順をスキップできます。

頑張ってデバッグしてください!

于 2012-08-30T05:48:28.387 に答える
0

同様の問題がありました。私たちの問題は静的ライブラリでした。アプリを最初から作成してtestflightに移行したとき、クラッシュしていましたが、IDEからはそうではありませんでした。クラッシュは、ビルドの実行時に静的ライブラリが含まれていなかったために発生しましたが、iPadを直接接続し、XCodeを使用してインストールした場合に含まれていました。

簡単なテストでこれが証明されます:-

1.)IDEからビルドする代わりに、.appファイルを作成し、iTunes経由でロードして、クラッシュするかどうかを確認します。

これを回避するには、.iPAを手動で作成します。つまり、.appを作成してから、ペイロードフォルダーを作成し、その中に.appをinfo.plistと一緒に配置します。

その後、Testflightでも機能し始めました。

于 2012-08-30T08:35:41.493 に答える