Dumb Game Lab

ブログ · 開発の裏側

個人開発の失敗ログ

クラッシュレポートを試すためにアプリをわざと落とそうとしたら、落ちなかった

Justin Lee, Dumb Game Lab ·

チチのバックパックの戦闘画面。傘やノートPCなどの持ち物をマスに合わせて詰めたカバンの下にスキルカードが並んでいる

アプリが落ちたらスマホにすぐ知らせるクラッシュ収集の仕組みを複数のゲームに入れて、最初の1週間に2回判断を間違えました。わざとアプリを落とすスイッチは実機のiPhoneでアプリを落とせず、Playにアップした直後に届いた起動エラー2件はユーザーではなくGoogleのプレローンチテスト端末で起きたものでした。どちらも、試す側が間違っていたケースです。

収集の仕組みを試すには、アプリが本当に落ちる必要がある

ゲームがスマホで落ちたら、レビューが付く前に自分で気づきたいと思っていました。そこでエラーを集める小さな仕組みを作り、10本前後のゲームに入れました。WebViewのエラー、直前の操作、アプリごと消えてしまうネイティブクラッシュまで受け取ります。

難しいのは試験です。クラッシュを拾えるか確かめるには、アプリが実際に落ちなければなりません。そこで、わざとアプリを落とすスイッチを別に入れました。隠しボタンを押すと、アプリのプロセスにSIGSEGV(メモリアクセス違反を示すシグナル)を送ります。

誤判断その1:シグナルを送れば落ちると思い込んだ

iPhone 11 Proの実機でスイッチを押しましたが、アプリは落ちませんでした。画面はそのままで、収集の仕組みには何も届きません。

ここで一番危ない結論は、クラッシュを拾えない仕組みだと決めつけることです。落とせなかったのはスイッチなのに収集側のせいにすると、動いているコードを直して本当の穴は残ります。調べると原因はスイッチでした。WebViewがすでに設定していたシグナルハンドラが、そのシグナルを先に横取りしていたのです。

直したのは1行です。シグナルを送る前に、SIGSEGVを既定の動作に戻します。するとアプリが落ち、次の起動でWebView側の異常終了の記録と、iOSがまとめてくれるSIGSEGVのレポートが両方届きました。試験の道具が試験の対象より先に間違うことがあると、この日に知りました。

チチのバックパックのカバン整理画面。新人と主任の枠に持ち物の形が置かれている
このゲームにも収集の仕組みが入っています。落ちるか見るために、落とすコードを先に直しました。

誤判断その2:アップ直後のエラーはユーザーのものだと思い込んだ

収集の仕組みには深刻度の基準があります。起動から8秒以内に出る起動エラーが2セッション以上あれば深刻と見なし、すぐホットフィックスの準備に入ります。最初の1週間で、この基準に2本のゲームが引っかかりました。ワクプタワー1.0.10とチチのバックパック1.0.0が、Playに上がった直後です。どちらも同じエラーで、シェーダーのリンクに失敗し、ユニフォーム数は261でした。

自分のゲームがユーザーのスマホで起動中に落ちているのだと読みました。違いました。ワクプタワー1.0.10を業務用スマホ(Adreno 740)で動かすとエラーは0で、261という数字はGoogleの仮想端末が使うソフトウェアレンダラー(SwiftShader)の上限値でした。Playがアップ直後に走らせるプレローンチテストのロボットが出したエラーを、人のエラーとして数えていたのです。

最初の読み実際
エラー内容起動中のシェーダーリンク失敗(ユニフォーム261)同じエラー、仮想端末の上限値
どこで起きたかユーザーのスマホFirebase Test Labの仮想端末(SwiftShader)
業務用スマホ(Adreno 740)の1.0.10未確認エラー0
深刻度の判定ホットフィックス対象2件ホットフィックス不要
ワクプタワーのプレイ画面。黄色いヒヨコが緑色のゼリーのような階段の上に立っている
ワクプタワー。エラーが出た端末は、この画面を描くことすらできない仮想端末でした。

それで変えたこと

収集の仕組みがソフトウェアレンダラーやFirebase Test Labの端末で動いたら、セッションもエラーもそもそも送らないようにしました。業務用スマホで目印をオンにするとロボットと判定され、オフにすると人と判定されるところまで自分で確認しています。同じ対策が抜けたコピーができないよう、同期チェックにも入れました。

最初の1週間で得たルールは2つです。試験用スイッチは、まずそのスイッチが本当に動くか確認する。新しい監視は、自分が出すノイズから先に取り除く。

ワクプタワーのロビー画面。おやつのテーマ別に選ぶカードが5枚並んでいる
同じエラーが出た2本のうち、1本の開始画面です。

同じ立場の人が最初にやること

クラッシュ収集を新しく入れる個人開発者なら、この順番をおすすめします。

  • わざと落とすコードを作ったら、まず実機でアプリが本当に落ちるか確かめる。
  • 落ちた後、次の起動でレポートが届くところまで見る。
  • Playにアップした直後のエラーは、プレローンチレポートの端末一覧と先に照らし合わせる。
  • 怪しいエラーは、同じバージョンを実機1台で再現してみる。
  • 新しい通知の基準は、最初の1週間に自分が出したノイズの件数から数える。

FAQ

iOSアプリをわざとクラッシュさせてクラッシュレポートを試すにはどうしますか?

私はアプリのプロセスにSIGSEGVシグナルを送るスイッチを使いました。iPhone 11 Proの実機では、WebViewが設定したシグナルハンドラが横取りしてアプリが落ちず、送る前にSIGSEGVを既定の動作に戻したら落ちました。落ちた後、次の起動でレポートが届くかも一緒に確認してください。

Play Consoleのプレローンチレポートでクラッシュが出ました。ユーザーも同じ目に遭っていますか?

私の場合は違いました。アップ直後にFirebase Test Labの仮想端末でだけ出たレンダラーのエラーで、ワクプタワー1.0.10を実機(Adreno 740)で動かしたらエラーは0でした。まずレポートの端末一覧を確認してみてください。

クラッシュレポートの仕組みは何を集めますか?

私が使っているものは、WebViewのエラー、直前の操作、セッション数に対するエラーの割合、ネイティブクラッシュを集めます。起動から8秒以内の起動エラーが2セッション以上あれば深刻と見なし、ホットフィックスの準備をします。

ほかの記事

新作ゲームと小さなお知らせを、月に1回ほどお届けします。

他の言語English한국어日本語繁體中文