運用保守大事（Crashlytics編）

みなさんこんにちは

運用保守大事スローガン呼びかけエンジニアの金子です。

弊社は開発力に強みのある会社ですが、開発のみ携わってお渡しするというパターンはほとんど無く、そのまま運用保守も継続して対応させていただく場合が基本となっています。
運用保守作業というと、新しいものを作るというような実装作業の華やかなイメージとは違い、システム監視などルーチンワーク化されたような作業や、本来起きてほしくない不具合修正などの、どちらかというと暗いイメージもありますが、大変重要なものです。

弊社が提供しているEAPではFirebaseのCrashlyticsが標準で導入されており、アプリをリリースした後のクラッシュ割合をいかに減らせるか、クラッシュ率下げ職人と化した運用担当エンジニアが日々しのぎを削るのというのもよく見かける光景となっています。

私が運用担当させていただいている、とあるiOSアプリ見てみたところ、クラッシュの影響を受けていないユーザーは99.91%でした。
なんだか99.9%いくとすごいらしいのでそれを目指すようにしています。（適当）

真面目な話をすると、限られた時間のなかで対応しますので、プロジェクト内で相談しながら優先度を付けて対応しています。

EAPは提供開始からバージョンアップを重ね、アプリのベースの品質が良くなり続けているので、採用した時点でクラッシュ率は低い状態で始められます。

よくみかけるクラッシュのパターン

クラッシュレポート対応の中で結構見かけるパターンとしては、ビューがロードされる前にoutletで接続したものにアクセスして落ちるというものがあります。
通常@IBOutletで接続したコントロールにはビューがロードされたあとにアクセスするようになりますが、ビューが入れ子になっていたりするとタイミングによっては有効になる前にアクセスされて落ちることがあります。
このパターンは通常のテストでは検出されない場合がほとんどで再現が難しいため、そういう場合にはコードを慎重に追っていってあたりをつけて対応するようにしています。

エラーになっている可能性がある箇所に以下のようにisViewLoadでビューがロードされているかのチェックをいれます。

func updateUI(_ content: Content) {
    guard isViewLoaded else { return }
    ,,,後続処理
}

今後も良いユーザー体験を提供できるように日々研鑽していきたいと思います。