アプリがクラッシュした
Apple Storeにて公開したアプリが、使用していると徐々に重くなってきてクラッシュしてしまう問題が発生。
そこで、以下の複数の方法を使って、おおよその原因の予測を立てた。
Instruments(Xcode)
まずは、XcodeのOpen Developer Toolの中にあるInstrumentsというツールを使用。CPU使用量を見るならTimeProfiler、MemoryLeakなどを見るときはAllocationsを利用する。
TimeProfilerは上図のようになり、Allocationsではメモリーリークも起きていなかったため、とにかくCPUの負荷が高く、特にメモリの解放のし忘れなどではないことが感覚的に理解できる。
CrashSymbolicator.pyでクラッシュログ解析
もう少し正確な解析を試みる。
少し古いがUnity iOSのクラッシュレポートについて調べてみた(活用方法や注意点など) #iOS - Qiitaを参考に、クラッシュログを解析してみることに。
iPhoneのログをAirDropでMacに送信し、まずはメモリーに関するログであるJetsamEventを開くと、
"reason" : "fc-thrashing"
という記述が。先ほどのQiitaの記事に従ってIdentifying high-memory use with jetsam event reports | Apple Developer Documentationのサイトからこのreasonを探すと、
A process thrashed the system file cache. This occurs when non-sequential parts of memory-mapped files are read and written too frequently. To avoid terminating the frontmost app, the system may terminate your app in the background to free space in the file cache, even if your app isn’t thrashing the file cache. プロセスがシステム・ファイル・キャッシュをスラッシュした。これは、メモリマップされたファイルの非連続部分があまりにも頻繁に読み書きされる場合に発生します。最前面のアプリが終了するのを避けるため、あなたのアプリがファイルキャッシュをスラッシングしていなくても、システムはファイルキャッシュの空き領域を確保するために、あなたのアプリをバックグラウンドで終了させることがある（DeepL)。
また、.ipsの拡張子の方のログはシンボル化したほうが良いとのことなので、iOSアプリのクラッシュログから解析する #iOS - Qiitaの通りに。ただし、 iOS15以降のクラッシュログ解析 #iOS - Qiitaにある通り、iOS15以降はこのツールはすでに使えないようなのでCrashSymbolicator.pyを使用。これによって出来た.ipsファイルを見ると、
WatchdogEvent: scene-update
という記述がある。どうやら、アプリのシーンの更新プロセスがクラッシュの原因である可能性を示しているらしい。
以上の結果から、
1.メモリーリークは起こしていない
2.メモリマップされたファイルの非連続部分があまりにも頻繁に読み書きされる場合に発生
3.アプリのシーンの更新プロセスがクラッシュの原因である可能性
ということで、レンダリングや内部の計算の処理が重すぎるあまりに、処理落ちのような形になっている可能性が高く、より効率的な計算方法やシーン遷移の方法に代替していく必要があると結論づけた。
