長時間のデバッグ作業から休憩が必要なプログラマーは、Facebook のソフトウェア エンジニア 2 名によるブログ記事を熟読するとよいかもしれません。この 2 名は、ソーシャル ネットワークの iOS アプリで見つけにくいメモリ エラーを根絶するためのヒントや苦労話を提供しています。
メモリエラーはデバッグが非常に難しいため、開発者にとって特に厄介な問題となることがあります。Facebookアプリやその他の実行中のアプリが突然停止して消えてしまった経験があるなら、それはメモリエラーが原因である可能性が高いです。
「いくつかのツール、最新のiOSテクノロジーへの移行、そしてそもそも問題を測定するちょっとした工夫によって、アプリの信頼性を高めることができました」と、アリ・アンサリとグレッグ・プストルチャはFacebookエンジニアリングブログの新しい投稿に書いている。
つまり、実行中のプログラムが消えるのは、オペレーティングシステムによって強制終了されたためであり、おそらくアプリケーションが割り当てられたメモリ領域外で処理を開始したためでしょう。オペレーティングシステムは、実行中のすべてのプログラムに、その処理を実行するためにシステムメモリの範囲を割り当てます。
オペレーティングシステムは、プログラムが突然大量の追加メモリを要求し始めた場合にも、プログラムを終了することがあります。これは、最終的にシステムメモリをすべて消費する可能性のあるメモリリークが発生した場合に発生することがあります。また、システム自体のシステムメモリが他の理由で不足している場合にも、正常に動作しているプログラムが強制終了されることがあります。

Facebook のエンジニアリング用語では、BOOM (バックグラウンド メモリ不足エラー) とはバックグラウンドでプログラムが停止することであり、FOOM とは画面上のプログラムが突然停止することを指します。
iOS はシャットダウンが差し迫っていることを警告するメッセージをアプリに送信しますが、アプリがそのメッセージが空に送信される前にログに記録されるという保証はありません。
「これでは、メモリ不足のために OS がアプリを強制終了したことを簡単に知る方法がなくなる」とエンジニアらは書いている。
それでも、Facebook のエンジニアは、iOS アプリの全体的なメモリクラッシュ率を下げるいくつかの手法を開発しました。
彼らが便利だとわかったテクニックの 1 つは、オペレーティング システムに対してメモリを要求したり解放したりする点で、アプリの煩わしさを軽減することです。
Facebookのエンジニアたちは当初、必要なメモリ量だけを使用することに細心の注意を払っていました。アプリがWebページの閲覧などの操作で追加のメモリを必要とする場合は、オペレーティングシステムに追加のメモリを要求し、タスクが完了するとすぐにそのメモリを解放していました。
しかし、このアプローチではアプリのクラッシュ回数は減りませんでした。多くの場合、解放されたメモリはiOSによって回収されることさえありませんでした。
代わりに、クラッシュ率を下げるのに役立ったのは、割り当てメモリ量を少し変更することだったようです。アプリは起動時に必要なメモリをすべて要求し、その制限内で動作しようとします。
このアプローチだけで、プログラムのクラッシュが約 30 パーセント削減されました。
Appleはメモリ割り当てに関しても追加の支援を提供しました。iOSバージョン8では、Webページの表示を別のプロセスとしてオフロードするWKWebViewという新しいプログラミングクラスが提供されました。
Facebook チームは、潜在的なメモリ エラーを検出するために、社内で開発されたツールもいくつか使用しました。
一つは、Facebookが社内で開発し、オープンソースとして公開した「CT-Scanインフラストラクチャ」と呼ばれるスキャンツールです。これはもともとモバイルアプリのパフォーマンスチューニングのために開発されましたが、メモリリークの特定にも有効であることが判明しました。
チームはまた、プログラム自体にオーバーヘッドを加えることなく、プログラムによるすべてのメモリ割り当てを追跡する新しいアプリ内メモリプロファイラーを開発しました。これにより、Facebookはプログラムのテストコピーの実行中に動作特性を収集できます。
プログラムが更新されるにつれて、チームは新バージョンと旧バージョン間で、異なるプロセスによって割り当てられたメモリ量を比較することができます。両者の間に大きな差異がある場合、これまで発見されていなかったメモリリークが存在する可能性があります。