最近在看FOOM，翻譯一下facebook的解決方案。
原文鏈接在Facebook iOS app中減少FOOMs

在Facebook iOS app中減少FOOMs

在Facebook，我們致力于使我們的應(yīng)用程序穩(wěn)定、快速和可靠。我們一直在努力減少Facebook IOS應(yīng)用中的崩潰次數(shù)，并提高其整體的可靠性。過去，大多數(shù)crash是由于程序錯誤引起的，并且它們總是帶有可以定位錯誤的堆棧和一直提供crash根源的提示。

隨著我們不斷修復(fù)Crash問題，我們觀察到Crash率不斷下降，但是從App Store的評論中我們注意到社區(qū)仍然對應(yīng)用crash感到崩潰。我們深入研究了用戶報告，和開始推斷可能發(fā)生了OOM（out of memory）。當(dāng)系統(tǒng)內(nèi)存不足時，操作系統(tǒng)會終止應(yīng)用程序以回收內(nèi)存時，會發(fā)生OOM。無論應(yīng)用程序在前臺還是在后臺，都可能發(fā)生OOM。我們在內(nèi)部分別將它們稱為FOOMs和BOOMs——可以說應(yīng)用程序發(fā)生BOOM是有點有趣的。

從用戶的角度來看，前臺OOM（FOOM）與Crash是無法區(qū)分的。在這兩種情況下，應(yīng)用都會意外終止，出現(xiàn)消失和用戶被帶回到設(shè)備的主屏幕。如果內(nèi)存消耗率急劇增加，則應(yīng)用程序被殺死而不會收到任何有關(guān)內(nèi)存用盡的信號。在IOS上，操作系統(tǒng)會盡力向應(yīng)用程序發(fā)送內(nèi)存警告，但不能保證在操作系統(tǒng)退出進程之前始終收到警告。這使我們無法輕松知道該應(yīng)用由于內(nèi)存不足而被操作系統(tǒng)殺死。

處理問題

為了了解我們的應(yīng)用由于OOM Crash而閃退的頻率，我們首先枚舉了可以終止應(yīng)用的所有已知路徑，然后對其進行記錄。我們研究的問題是“什么導(dǎo)致應(yīng)用程序啟動？”

應(yīng)用可能由于以下原因需要啟動：

• 程序是否升級
• 程序是否調(diào)用exit()和abort()
• 程序是否crash
• 用戶向上滑動強制退出應(yīng)用程序
• 設(shè)備重啟（包括操作系統(tǒng)升級）
• 程序在后臺或前臺內(nèi)存不足（OOM）

通過排除法，尋找不屬于其他情況的實例，然后我們可以確定何時發(fā)生OOM。同時我們也跟蹤應(yīng)用程序是否在前臺還是后臺，以便我們可以準(zhǔn)確的將OOM分解為BOOMs和FOOMs。

日志記錄表明，內(nèi)存較少的設(shè)備上的OOM發(fā)生率較高，這是可以預(yù)期的并且令人放心的，因為應(yīng)用程序更有可能在受限內(nèi)存的設(shè)備上退出。看到日志記錄中的相關(guān)性有助于我們驗證排除的實例是否正確并繼續(xù)改進日志（我們最初并未識別所有情況，例如應(yīng)用程序升級）。

我們減少OOM的數(shù)量的第一個嘗試是盡可能回收應(yīng)用程序不在需要的內(nèi)存。不幸的是，我們觀察到OOM崩潰的次數(shù)并沒有變化。因此我們將重點轉(zhuǎn)移到了大的內(nèi)存分配上。首先是可能泄漏的內(nèi)存（未清理過），尤其是通過潛在的保留周期。

分析內(nèi)存使用情況

當(dāng)我們開始修復(fù)內(nèi)存泄漏時，我們看到OOM率有所降低，但是我們?nèi)匀粵]有看到我們希望的顯著降低。接下來，我們深入研究了Apple的Instruments 應(yīng)用程序中的內(nèi)存分析器和注意到一旦應(yīng)用程序打開任何頁面，UIWebView就會重復(fù)分配大量內(nèi)存。我們還發(fā)現(xiàn)，即使用戶關(guān)閉web視圖離開頁面后，也常常無法回收內(nèi)存。
我們嘗試了許多優(yōu)化措施，例如清理緩存和清理內(nèi)容，但是導(dǎo)航到Web視圖后，我們應(yīng)用程序進程的內(nèi)存占用始終顯著增加。iOS 8引入了一個新類WKWebView，該類實際上是在一個單獨的進程中執(zhí)行其大部分工作，這意味著大多數(shù)與Web視圖相關(guān)的內(nèi)存使用情況不會統(tǒng)計到我們的進程。在內(nèi)存不足的情況下，web視圖的進程可能會被殺死，而我們的應(yīng)用程序更有可能繼續(xù)運行。在將應(yīng)用程序遷移到WKWebView之后，我們確實看到了應(yīng)用程序中的OOM的顯著減少。Yay！

內(nèi)存分配率

通過Instruments進行內(nèi)存使用情況分析時，我們還觀察到應(yīng)用程序使用內(nèi)存情況的某些實例，在這些實例中，應(yīng)用程序臨時分配了大量內(nèi)存（約30M），不久后釋放。如果在此分配過程中CPU不空閑，則OS可能會殺死該應(yīng)用程序。如果我們能夠擺脫這些臨時分配，這有助于在某些情況下將OOM減少多達30%。我們還進行了試驗和發(fā)現(xiàn)一次性分配并保留到內(nèi)存中對于提高應(yīng)用程序的穩(wěn)定性要比重復(fù)分配和釋放更好。

阻止回歸

即使遷移到WKWebView之后，我們?nèi)匀话l(fā)現(xiàn)較小的內(nèi)存泄漏也可能會明顯影響OOM率，尤其是在內(nèi)存受限的設(shè)備上。由于我們頻繁的發(fā)布計劃，并且有許多團隊貢獻代碼到應(yīng)用程序中。因此捕獲并防止我們發(fā)布的應(yīng)用程序內(nèi)存泄漏是重要的。我們利用了最初用于測試移動性能的 CT-Scan infrastructure來記錄進程中的常駐內(nèi)存量（測試左移），允許CT-Scan在代碼被引進的時候就對回歸量（內(nèi)存）進行標(biāo)記。這會幫助我們在開始工作時將OOM率保持較低水平。

內(nèi)置的APP內(nèi)存分析器

我們在工程中使用的最后一個關(guān)鍵策略是構(gòu)造一個內(nèi)置的App內(nèi)存分析器。該分析器通過追蹤所有Objective-C對象的分配來快速對應(yīng)用程序進行性能分析。我們在CT-Scan和應(yīng)用程序的內(nèi)部版本中進行了配置。

它的工作原理如下：對于系統(tǒng)中的每個類，它會計數(shù)當(dāng)前有多少個存活實例。我們可以隨時查詢它，并記錄每個類的當(dāng)前對象數(shù)。然后，我們可以分析此數(shù)據(jù)的每個發(fā)布版本以識別應(yīng)用程序整體分配模式的變化，通常當(dāng)計數(shù)急劇變化時可以幫助我們識別是否內(nèi)存泄漏。我們設(shè)計了一種足夠有效的方法來實現(xiàn)，從而不會對用戶的應(yīng)用程序性能產(chǎn)生任何明顯的影響。

這是我們的策略以及如何跟蹤NSObject分配的示意圖。

我們首先創(chuàng)建了一個內(nèi)存分配跟蹤器類。它非常簡單，該跟蹤器會將類名和實例計數(shù)器進行映射，以及增加和減少計數(shù)的公共方法。我們選擇使用C++而不是Objective-C，以便將跟蹤器的所有內(nèi)存分配和Cpu開銷保持在最低水平。

class AllocationTracker {static AllocationTracker* tracker();void incrementInstanceCountForClass(Class aCls);void decrementInstanceCountForClass(Class aCls);std::vector<std::pair<Class, unsigned long long>> countsSnapshot();...
}

然后我們使用ios方法替換（叫做“swizzling,” 使用運行時函數(shù)class_replaceMethod）將標(biāo)準(zhǔn)的IOS方法+alloc 和 +dealloc替換為方法–fb_originalAlloc 和 –fb_originalDealloc.

然后，我們用新的實現(xiàn)替換
+alloc 和 +dealloc。這些實現(xiàn)分別會增加和減少分配和釋放的實例數(shù)量

@implementation NSObject (AllocationTracker)+ (id)fb_newAlloc
{id object = [self fb_originalAlloc];AllocationTracker::tracker()->incrementInstanceCountForClass([object class]);return object;
}- (void)fb_newDealloc
{AllocationTracker::tracker()->decrementInstanceCountForClass([object class]);[self fb_originalDealloc];
}@end

然后，當(dāng)應(yīng)用程序運行時，我們可以定期調(diào)用快照方法以記錄當(dāng)前存活實例數(shù)量

App穩(wěn)定性很重要

當(dāng)我們推出了解決Facebook iOS應(yīng)用程序中內(nèi)存問題的方法時，我們發(fā)現(xiàn)(F)OOMs以及應(yīng)用程序crash的用戶報告數(shù)量都大大減少了。OOM崩潰對我們是一個盲點，因為沒有正式的系統(tǒng)或API可以觀察OOM事件及其發(fā)生的頻率。當(dāng)應(yīng)用突然閃退時，沒有人喜歡它。借助一些工具，向最新的iOS技術(shù)遷移，以及在最開始的時候就嘗試解決這個問題（測試左移）也是可以借鑒的，我們能夠使我們的應(yīng)用程序更加可靠，并確保在打開Web視圖時不會突然關(guān)閉應(yīng)用程序。

還要感謝Linji Yang，Anoop Chaurasiya，Flynn Heiss，Parthiv Patel，Justin Pasqualini，Cloud Xu，Gautham Badrinathan，Ari Grant和其他許多人，他們幫助降低了FOOM率。

副業(yè)賺錢

說完了正文，接下來打一波廣告，程序員如何副業(yè)賺錢，我本科同學(xué)這里有一個賺錢的機會，現(xiàn)在是北大金融系碩士，有副業(yè)賺錢想法的兄弟們，請?zhí)砑铀⑿?zhengxiangpku 備注lfdanding推薦 即可。

總結(jié)

以上是生活随笔為你收集整理的在Facebook iOS app中减少FOOMs的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。