概覽
說起iOS的OOM問題大家第一想到的應該更多的是內存泄漏（Memory Leak），因為無論是從早期的MRC還是2011年Apple推出的ARC內存泄漏問題一直是iOS開發者比較重視的問題，比如我們熟悉的 Instruments Leaks 分析工具，Xcode 8 推出的 Memory Graph 等都是官方提供的內存泄漏分析工具，除此之外還有類似於FBRetainCycleDetector的第三方工具。不過事實上內存泄漏僅僅是造成OOM問題的一個原因而已，實際開發過程中造成OOM的原因有很多，本文試圖從實踐的角度來分析造成OOM的諸多情況以及解決辦法。
造成OOM的原因
造成OOM的直接原因是iOS的 Jetsam 機製造成的，在Apple的 Low Memory Reports中解釋了具體的運行情況：當內存不足時，系統向當前運行中的App發起applicationDidReceiveMemoryWarning(_ application: UIApplication) 調用和 UIApplication.didReceiveMemoryWarningNotification 通知，如果內存仍然不夠用則會殺掉一些後台進程，如果仍然吃緊就會殺掉當前App。
關於 Jetsam 實現機制其實蘋果已經開源了XNU代碼，可以在這裏查看，核心代碼在 kern_memorystatus 感興趣可以閱讀，其中包含了很多系統調用函數，可以幫助開發者做一些OOM監控等。
一、內存泄漏
內存泄漏造成內存被持久佔用無法釋放，對OOM的影響可大可小，多數情況下並非泄漏的類直接造成大內存佔用而是無法釋放的類引用了比較大的資源造成連鎖反應最終形成OOM。一般分析內存泄漏的工具推薦使用Leaks，後來Apple提供了比較方便的Memory Graph。
Instruments Leaks
Leaks應該是被所有開發者推薦的工具，幾乎搜索內存泄漏就會提到這個工具，但是很多朋友不清楚其實當前Leaks的作用沒有那麼大，多數時候內存泄漏使用Leaks是分析不出來的。不妨運行下面的一個再簡單不過的泄漏情況（在一個導航控制器Push到下面的控制器然後Pop出去進行驗證）：
class Demo1ViewController: UIViewController {
override func viewDidLoad() {
super.viewDidLoad()
self.customView.block = {
print(self.view.bounds)
}
self.view.addSubview(self.customView)
}
private lazy var customView:CustomView = {
let temp = CustomView()
return temp
}()
deinit {
print("Demo1ViewController deinit")
}
}
class CustomView:UIView {
var block:(()->Void)?
}
上面這段代碼有明顯的循環引用造成的內存泄漏，但是前面說的兩大工具幾乎都無能為力，首先Leaks是：
網絡上有大量的文章去介紹Leaks如何使用等以至於讓有些同學以為Leaks是一個無所不能的內存泄漏分析工具，事實上Leaks在當前iOS開發環境下檢測出來的內存泄漏比較有限。之所以這樣需要先了解一個App的內存包括哪幾部分：
-
Leaked memory: Memory unreferenced by your application that cannot be used again or freed (also detectable by using the Leaks instrument).
-
Abandoned memory: Memory still referenced by your application that has no useful purpose.
-
Cached memory: Memory still referenced by your application that might be used again for better performance.
Leaked memory正是Leaks工具所能發現的內存，這部分內存屬於沒有任何對象引用的內存，在內存活動圖中是是不可達內存。
Abandoned memory在應用內存活動圖中存在，但是因為應用程序邏輯問題而無法再次訪問的內存。和內存泄漏最主要的區別是它的引用（包括強引用和弱引用）是存在的，但是不會再用了。比如上面的循環引用問題，VC被Pop后這部分內存首先還是在內存活動圖中的，但是下次再push我們是創建一個新的VC而非使用原來的VC就造成上一次的VC成了廢棄的內存。
如果是早期MRC下創建的對象忘記release之類的使用Leaks是比較容易檢測的，但是 ARC 下就比較少了，實際驗證過程中發現更多的是引用的一些古老的OC庫有可能出現，純Swift幾乎沒有。
Abandoned memory事實上要比leak更難發現，關於如何使用Instruments幫助開發者進行廢棄的內存分析，參見官方Allocations工具的使用：Find abandoned memory
Memory Graph
當然Xcode 8 的Memory Graph也是一大利器，不過如果你這麼想上面的問題很有可能會失望（如下圖），事實上Memory Graph我理解有幾個問題：第一是這個工具要想實際捕獲內存泄漏需要多運行幾次，往往一次運行過程是無法捕獲到內存泄漏的；第二比如上面的子視圖引起的內存泄漏是無法使用它捕獲內存泄漏信息的，VC pop之後它會認為VC沒有釋放它的子視圖沒有釋放也是正確的，事實上VC就應該是被釋放的，不過調整一下上面的代碼比如刪除self.view.addSubview(self.customView)后儘管還存在循環引用但是卻是可以檢測到的（不過實際上怎麼可能那麼做呢），關於這個玄學問題沒有找到相關的說明文檔來解釋。但是事實上 Memory graph 從來也沒有聲明自己是在解決內存泄漏問題，而是內存活動圖分析工具，如果這麼去想這個問題似乎也不算是什麼bug。
第三方工具
事實上看到上面的情況相信很多同學會想要使用第三方工具來解決問題，比如大家用的比較多的MLeaksFinder和PLeakSniffer,兩者不同之處是後者除了可以默認查出 UIViewController 和 UIView 內存泄漏外還可以查出所有UIViewController屬性的內存泄漏算是對前者的一個補充。當然前者還配合了 Facebook 的FBRetainCycleDetector可以分析出循環引用出現的引用關係幫助開發者快速修復循環引用問題。
不過可惜的是這兩款工具，甚至包括 PLeakSniffer 的 Swift 版本都是不支持 Swift 的（準確的說是不支持Swift 4.2，原因是Swift 4.2繼承自 NSObject 的類不會默認添加 @objc 標記 class_copyPropertyList無法訪問其屬性列表,不僅如此Swift5.x中連添加 @objcMembers 也是沒用的）,但是 Swift 不是到了5.x才ABI穩定的嗎？，再次查看 Facebook 的 FBRetainCycleDetector 本身就不不支持Swift，具體可以查看這個issue這是官方的回答，如果稍微熟悉這個庫原理的同學應該也不難發現具體的原因，從目前的情況來看當前 FBRetainCycleDetector 的原理在當前swift上是行不通的，畢竟要獲取對象布局以及屬性在Swift 5.x上已經不可能，除非你將屬性標記為@objc，這顯然不現實，走 SWift 的Mirror當前又無法 setValue，所以研究了一下現在開源社區的情況幾乎沒有類似OC的完美解決方案。
Deubgger的LeakMonitorService
LeakMonitorService是我們自己實現的一個Swift內存泄漏分析工具，主要是為了解決上面兩個庫當前運行在Swift 5.x下的問題，首先明確的是當前 Swift 版本是無法訪問其非 @objc 屬性的，這就無法監控所有屬性，但是試想其實只要這個監控可以解決大部分問題它就是有價值的，而通常的內存泄漏也就存在於 UIViewController 和 UIView 中，因此出發點就是檢測 UIViewController 和其根視圖和子視圖的內存泄漏情況。
如果要檢測內存泄漏就要先知道是否被釋放，如果是OC只要Swizzle dealloc方法即可，但是顯然Swift中是無法Swizzle一個deinit方法的，因為這個方法本身就不是runtime method。最後我們確定的解決方案就是通過關聯屬性進行監控，具體的操作（具體實現後面開源出來）：
- 使用一個集合Objects記錄要監控存在內存泄漏的對象
- 給NSObject添加一個關聯屬性：deinitDetector，類型為 Detector 作為NSObject的代理，Detector是一個class，裏面引用一個block，在 deinit 時調用這個 block 從Objects 中移除監控對象
- 在 UIViewController 初始化時給 deinitDetector 賦值進行監控，同時將自身添加到 Objects 數組代表可能會發生內存泄漏，在 UIViewController 的將要釋放時檢測監控（一般稍微延遲一會）檢測Objects是否存在當前對象如果是被正確釋放因為其屬性deinitDetector 會將其從 Objects 移除所以就不會有問題，如果出現內存泄漏deinitDetector的內部block不會調用，此時當前控制器還在 Objects 中說明存在內存泄漏
- 使用同樣的方法監控UIViewController的根視圖和子視圖即可
需要說明的是監控UIViewController的時機，通常建議添加監控的時機放到viewDidAppear()，檢測監控的時機放到viewDidDisappear()中。原因是此時子視圖相對來說已經完成布局（避免存在動態添加的視圖沒有被監控到），而檢測監控的時機放到viewDidDisappear()中自然也不是所有調用了viewDidDisappear()的控制器就一定釋放了，可以在viewDidDisappear()中配合isMovingFromParent和isBeingDismissed屬性進行比較精準的判斷。
常見的內存泄漏
經過 LeakMonitorService 檢測確實在產品中發現了少量的內存泄漏情況，但是很有代表性，這裏簡單的說一下，當然普通的block循環引用、NSTimer、NotificationCenter.default.addObserver()等這裏就不在介紹了，產品檢測中幾乎也沒有發現。
1.block的雙重引用問題
先來看一段代碼：
class LeakDemo2ViewController: UIViewController {
override func viewDidLoad() {
super.viewDidLoad()
let customView = CustomView()
customView.block1 = {
[weak self] () -> CustomSubView? in
guard let weakSelf = self else { return nil }
let customSubview = CustomSubView()
customSubview.block2 = {
// 儘管這個 self 已經是 weak 了但是這裏也會出現循環引用
print(weakSelf)
}
return customSubview
}
self.view.addSubview(customView)
}
deinit {
print("LeakDemo2ViewController deinit")
}
}
private class CustomView:UIView {
var block1:(()->CustomSubView?)?
override init(frame: CGRect) {
super.init(frame: frame)
}
override func layoutSubviews() {
super.layoutSubviews()
if let subview = block1?() {
self.addSubview(subview)
}
}
required init?(coder: NSCoder) {
fatalError("init(coder:) has not been implemented")
}
}
private class CustomSubView:UIView {
var block2:(()->Void)?
}
上面的代碼邏輯並不複雜，customView 的 block 內部已經考慮了循環引用將 self 聲明為 weak 是沒有問題的，出問題的是它的子視圖又嵌套了一個 block2 從而造成了 block2 的嵌套引用關係，而第二個 block2 又引用了 weakSelf 從而造成循環引用（儘管此時的self是第一個 block 內已經聲明成 weakSelf）解決的辦法很簡單隻要內部的 block2 引用的 self 聲明成weak就好了（此時形成的是[weak weakSelf]的關係）。那麼為什麼會這樣的，內部 block2 訪問的也不是當前VC的self對象，而是弱引用怎麼會出問題呢？
原因是當前控制器 self 首先強引用了customView，而customView又通過 addSubview() 強引用了customSubView，這樣依賴其實 self 已經對 customSubView形成了強引用關係。但是 customSubview 本身引用的弱引用weakSelf嗎？（注意是弱引用的weakSelf，不是weakSelf的弱引用），但是需要清楚一點就是外部的弱引用是block1對self的弱引用，也就是在weak table（Swift最新實現在Side table）裏面會記錄block1的弱引用關係，但是block2是不會在這個表中的，所以這裏還是一個強引用，最終造成循環引用關係。
Swift中的weakSelf和strongSelf
補充一下OC中的weakSelf和strongSelf的內容，通常情況下常見的做法:
__weak __typeof__(self) weakSelf = self;
[self.block = ^{
__strong __typeof(weakSelf)strongSelf = weakSelf;
if (strongSelf) {
strongSelf.title = @"xxx";
}
}];
當然你可以用兩個宏簡化上面的操作：
@weakify(self);
[self.block = ^{
@strongify(self);
if (strongSelf) {
self = @"xxx";
}
}];
上面 strongSelf 的主要目的是為了避免block中引用self的方法在執行過程中被釋放掉造成邏輯無法執行完畢，swfit中怎麼做呢，其實很簡單（method1和method2要麼都執行，要麼一個也不執行）：
self.block = {
[weak self] in
if let strongSelf = self {
strongSelf.method1()
strongSelf.method2()
}
}
但是下面的代碼是不可以的（有可能會出現method2不執行，但是method1會執行的情況）：
self.block = {
[weak self] in
self?.method1()
self?.method2()
}
2.delay操作
通常大家都很清楚 NStimer 會造成循環引用（儘管在新的api已經提供了block形式，不必引用target了），但是很少注意 DispatchQueue.main.asyncAfter() 所實現的delay操作，而它的返回值是 DispatchWorkItem 類型通常可以用它來取消一個延遲操作，不過一旦對象引用了 DispatchWorkItem 而在block中又引用了當前對象就形成了循環引用關係，比如：
class LeakDemo3ViewController: UIViewController {
override func viewDidLoad() {
super.viewDidLoad()
self.delayItem = DispatchWorkItem {
print("asyncAfter invoke...\(self)")
}
DispatchQueue.main.asyncAfter(deadline: .now() + .seconds(3), execute: self.delayItem!)
}
deinit {
print("LeakDemo3ViewController deinit")
}
private var delayItem:DispatchWorkItem?
}
3.內部函數
其實，如果是閉包大家平時寫代碼都會比較在意避免循環引用，但是如果是內部函數很多同學就沒有那麼在意了，比如下面的代碼：
class LeakDemo4ViewController: UIViewController {
var block:(()->Void)?
override func viewDidLoad() {
super.viewDidLoad()
func innerFunc() {
print(self)
}
self.block = {
[weak self] in
guard let weakSelf = self else { return }
innerFunc()
print(weakSelf)
}
}
deinit {
print("LeakDemo4ViewController deinit")
}
}
innerfunc() 中強引用了self，而 innerFunc 執行上下文是在block內進行的，所以理論上在block內直接訪問了self，最終造成循環引用。內部函數在swift中是作為閉包來執行的，上面的代碼等價於：
let innerFunc = {
print(self)
}
說起block的循環引用這裏可以補充一些情況不會造成循環引用或者是延遲釋放的情況。特別是對於延遲的情況此次在產品中也做了優化，盡可能快速釋放內存避免內存峰值過高。
a.首先pushViewController()和presentViewController()本身是不會引用當前控制器的，比如說下面代碼不會循環引用：
let vc = CustomViewController()
vc.block = {
print(self)
}
self.present(vc, animated: true) {
print(self)
}
b.UIView.animation不會造成循環引用
UIView.animate(withDuration: 10.0) {
self.view.backgroundColor = UIColor.yellow
}
c.UIAlertAction的handler不會引起循環引用(iOS 8 剛出來的時候有問題)
let alertController = UIAlertController(title: "title", message: "message", preferredStyle: UIAlertController.Style.alert)
let action1 = UIAlertAction(title: "OK", style: UIAlertAction.Style.default) { (alertAction) in
print(self)
}
let action2 = UIAlertAction(title: "Cancel", style: UIAlertAction.Style.cancel) { (alertAction) in
print(self)
}
alertController.addAction(action1)
alertController.addAction(action2)
self.present(alertController, animated: true) {
print(self)
}
d.DispatchQueue asyncAfter會讓引用延遲，這裏的引用也是強引用，但是當asynAfter執行結束會得到釋放，但是不及時
DispatchQueue.main.asyncAfter(deadline: .now() + .seconds(10)) {
print(self)
}
e.網絡請求會延遲釋放
如下在請求回來之前self無法釋放:
guard let url = URL(string:"http://slowwly.robertomurray.co.uk/delay/3000/url/http://www.google.co.uk
") else { return }
let dataTask = URLSession.shared.dataTask(with: url) { (data, response, error) in
print(self,data)
}
dataTask.resume()
f.其他單例對象有可能延遲釋放，因為單例本身對外部對象強引用，儘管外部對象不會強引用單例，不過釋放是延遲的
class SingletonManager {
static let shared = SingletonManager()
func invoke(_ block: @escaping (()->Void)) {
DispatchQueue.global().async {
sleep(10)
block()
}
}
}
SingletonManager.shared.invoke {
print(self)
}
Instruments Allocation
前面說過Leaks和Memory Graph的限制，使用監控UIViewController或者UIView的工具對多數內存進行監控，但是畢竟這是多數情況，有些情況下是無法監控到的，那麼此時配合Instruments Allocation就是一個比較好的選擇，首先它可以通過快照的方式快速查對比內存的增長點也就可以幫助分析內存不釋放的原因，另外可以通過它查看當前內存被誰佔用也就有利於幫助我們分析內存佔用有針對性行的進行優化。
首先要了解，當我們向操作系統申請內存時系統分配的內存並不是物理內存地址而是虛擬內存 VM Regions 的地址。每個進程擁有的虛擬內存的空間大小是一樣的，32位的進程可以擁有4GB的虛擬內存，64位進程則更多。當真正使用內存時，操作系統才會將虛擬內存映射到物理內存。所以理論上當兩個進程A和B默認擁有相同的虛擬內存大小，當B使用內存時發現物理內存已經不夠用在OSX上會將不活躍內存寫入硬盤，叫做 swapping out。但是在iOS上面會直接發出內存警告 Memory warning 通知App清理無用內存（事實上也會引入 Compressed memory 壓縮一部分內存，需要的時候解壓）。
當然要使用這個工具之前建議先了解這個工具對內存類別劃分：
All Heap Allocations ：進程運行過程中堆上分配的內存，簡單理解就是實際分配的內存，包括所有的類實例，比如UIViewController、UIView、Foundation數據結構等。比如：
Malloc 512.00KiB: 分配的512k堆內存，類似還有 Malloc 80.00KiB等CTRun: Core Text對象內存
All Anonymous VM ：主要包含一些系統模塊的內存佔用，以 VM: 開頭
VM:CG raster data:（光柵化數據，也就是像素數據。注意不一定是圖片，一塊显示緩存里也可能是文字或者其他內容。通常每像素消耗 4 個字節）VM:Statck:棧內存（比如每個線程都會需要500KB）VM:Image IO:（圖片編解碼緩存）VM:IOSurface:用於存儲FBO、RBO等渲染數據的底層數據結構，是跨進程的，通常在CoreGraphics、OpenGLES、Metal之間傳遞紋理數據。CoreAnimation: 動畫資源佔用內存VM:IOAccelerator:圖片的CVPixelBuffer
需要注意，Allocations統計的 Heap Allocations & Anonymous VM（包括：All Heap Allocations和All Anonymous VM） 並不包括非動態的內存，以及部分其他動態庫創建的VM Region（比如：WebKit，ImageIO，CoreAnimation等虛擬內存區域），相對來說是低於實際運行內存的。
為了進一步了解內存實際分配情況，這裏不妨藉助一下 Instruments VM Tracker 這個工具，對於前面說過虛擬內存，這個工具是可以對虛擬內存實際分配情況有直觀展示的。
Virtual memory（虛擬內存） = Dirty Memory（已經寫入數據的內存） + Clean Memory（可以寫入數據的乾淨的內存） + Compressed Memory（對應OSX上的swapped memory）
Dirty Memory ： 包括所有 Heap 中的對象、以上All Anonymous VM以及每個framework的 _DATA 段和 _Dirty_Data 段
Clean Memory：可以寫數據的乾淨的內存，不過對於開發者是read-only，操作系統負責寫入和移除，比如：System Framework、Binary Executable佔用的內存，framework都有_DATA_CONST段（不過當使用framework時會變成 Dirty memory ）
Compressed Memory：由於iOS系統是沒有 swapped memory 的，取而代之的是 Compressed Memory ，通過壓縮內存可以降低大概一半的內存。不過遇到內存警告釋放內存的時候情況就複雜了些，比如遇到內存警告后通常可以試圖壓縮內存，而這時開發者會在收到警告后釋放一部分內存，遇到釋放內存的時候內存很可能會從壓縮內存再解壓去釋放反而峰值會增加。
前面提到過 Jetsam 對於內存的控制機制，這裏需要明確它做出內存警告的依據是 phys_footprint，而發生內存警告后系統默認清理的內存是 Clean Memory 而不會清理 Dirty Memory，畢竟有數據的內存系統也不知道是否還有用，無法自動清理。
Resident Memory = Dirty Memory + Clean Memory that loaded in physical memory
Resident Memory：已經被映射到虛擬內存中的物理內存，但是注意只有 phys_footprint 才是真正消耗的物理內存，也正是 Jetsam 判斷內存警告的依據。
Memory Footprint：App 實際消耗的物理內存，Jetsam 判斷內存警告的依據，包括：Dirty Memory 、Compressed Memory、NSCache， Purgeable、IOKit used
和部分加載到物理內存的Clean memory。
如果簡單總結：
Instruments Allocations 的 Heap Allocations & Anonymous VM 是整個App佔用的一部分，它又分為 Heap Allocations 為開發者申請的內存，而 Anonymous VM 是系統分配內存（但是並不是不需要優化）。這部分儘管不是 App 的所有消耗內存但卻是開發者最關注的。
Instruments VM Tracker 的 Dirty Memory 和 Swapped（對應iOS中的 Compressed Memory） 應該是開發者關注的主要內存佔用，比較接近於實際佔用內存，類似的是Xcode Navigator的內存也接近於最終的 Memory Footprint (多了調試佔用的內存而已一般可以認為是 App 實際佔用內存)
關於圖片的內存佔用有必要解釋一下：CGImage 持有原始壓縮格式DataBuffer（DataBuffer佔用本身比較小），通過類似引用計數管理真正的Image Bitmap Buffer，需要渲染時通過 RetainBytePtr 拿到 Bitmap Buffer 塞給VRAM(IOSurface)，不渲染時 ReleaseBytePtr 釋 放Bitmap Buffer。通常在使用UIImageView時，系統會自動處理解碼過程，在主線程上解碼和渲染，會佔用CPU，容易引起卡頓。推薦使用ImageIO在後台線程執行圖片的解碼操作（可參考SDWebImageCoder）。但是ImageIO不支持webp。
二、持久化對象
很多時候內存泄漏確實可以很大程度上解決OOM問題，因為類似於UIViewController或者UIView中包含大量UIImageView的情況下，兩者不釋放很可能會有很大一塊關聯的內存得不到釋放造成內存泄漏。但是另一個問題是持久化對象，即使解決了所有內存泄漏的情況也並不代表就真正解決了內存泄漏問題，其中一個重要的因素就是持久化對象。
關於持久化對象這裏主要指的是類似於App進入后在主界面永遠不會釋放的對象，以及某些單例對象。象基本上基本上不kill整個app是無法釋放的，但是如果因為設計原因又在首頁有大量這樣的持久對象那麼OOM的問題理論上更加難以解決，因為此時要修改整個App結構幾乎是不可能的。
這裏簡單對非泄漏OOM情況進行分類：
- 首頁及其關聯頁面：比如首頁是UITabbarController相應的tab點擊之後也成為了持久化對象無法釋放
- 單例對象：特別是會加載一些大模型的單例，比如說單例中封裝了人臉檢測，如果人臉檢測模型比較大，首次使用人臉識別時加載的模型也會永遠得不到釋放
- 複雜的界面層級：Push、Pop是iOS常用的導航操作，但是如果界面設計過於複雜（甚至可以無限Push）那麼層級深了以後前面UINavigationController棧中的對象一直堆疊也會OOM
- 耗資源的對象：比如說播放器這種消耗資源的對象，理論上不會在同一個app內播放兩個音視頻，設計成單例反而是比較好的方案
- 圖片資源：圖片資源是app內最佔用內存的資源，一個不合適的圖片尺寸就可以導致OOM，比如一張邊長10000px的正方形圖片解碼后的大小是10000 * 10000 * 4 = 381M左右
首先說一下第一種情況，其實在早期iOS中（5.0及其之前的版本）針對以上情況有內存警lunload機制，通常在viewDidUnload()中釋放當前view，同時也是給開發者提供資源卸載的一個比較合適的時機，當UIViewController再次展示時會重新loadView()，而從iOS 6.0之後Apple建議相關操作放到didReceiveMemoryWarning()方法中，主要的原因是因為僅僅釋放當前根視圖並不會帶來大的內存釋放同時又造成了體驗問題，原本一個UITableView已經翻了幾頁了現在又要重新加載一遍。所以結論是在didReceiveMemoryWarning()放一些大的對象釋放操作，而不建議直接釋放view，但是不管怎麼樣一定要做恢復機制。實際的實踐是在我們的MV播放器中做了卸載操作，因為MV的預覽要經過A->B->C的push過程，A、B均包含了MV預覽播放器，而實際測試兩個播放器的內存佔用大概110M上下這是一部分很大的開銷，特別是對於iPhone 6等1g內存的手機。另外針對某個頁面有多個子控制器的情況避免一次加載所有的自控制器的情況，理想的情況是切換到對應的控制器時才會加載對應的控制器。
單例對象是另一種大內存持久對象，通常情況下對象本身佔用內存很有限，做成單例沒有什麼問題，但是這個對象引用的資源才是關注的重點，比如說我們產品中中有個主體識別模塊，依賴於一個AI模型，本身這個模塊也並非App操作的必經路徑，首次使用時加載，但是之後就不會釋放了，這樣一來對於使用過一次的用戶很有可能不再使用就沒必要一直佔用，解決的辦法自然是不用單例。
關於複雜的界面層級則完全是設計上的問題，只能通過界面交互設計進行控制，而對於耗資源對象上面也提到了盡量復用同一個對象即可，這裏不再贅述。
此外，前面說到FBO相關的內存，其實這部分內存也是需要手動釋放的，比如在產品中使用的播放器在用完之後並沒有及時釋放，調用 CVOpenGLESTextureCacheFlush() 及時清理（類似的還有使用基於OpenGL的濾鏡）。
內存峰值飆升
除了持久的內存佔用意外，有時會不恰當的操作會造成內存的飆升出現OOM，儘管這部分內存可能一會會被釋放掉不會長久的佔用內存但是內存的峰值本身就是很危險的操作。
圖片壓縮
首先重點關注一下圖片的內存佔用，圖片應該是最佔用內存的對象資源，理論上UILayer最終展示也會繪製一個bitmap，不過這裏主要說的是UIImage資源。一張圖片要最終展示出來要經過解碼、渲染的步驟，解碼操作的過程就是就是從data到bitmap的過程，這個過程中會佔用大量內存，因為data是壓縮對象，而解碼出來的是實實在在的像素信息。自然在開發中重用一些控件、做圖片資源優化是必要的，不過這些事實上在我們的產品中都是現成的內容，如何進一步優化是我們最關注的的。理論上這個問題可以歸結到第一種情況的範疇，就是如何讓首頁的圖片資源盡可能的小，答案也是顯而易見的：第一解碼過程中盡可能控制峰值，第二能用小圖片的絕不解碼一張大圖片。
比如一個圖片壓縮需求一張巨大的圖片要判斷圖片大小做壓縮處理，假設這張圖片是1280 * 30000的長圖，本來的目的是要判斷圖片大小進行適當的壓縮，比如說超過50M就進行80%壓縮，如果100M就進行50%壓縮，但是遇到的情況是這樣的：本來為了判斷圖片的大小以及保留新的圖片，原圖片A內存佔用大約146M，聲明了一個新對象B保留壓縮后的圖片，但是默認值是A原圖，根據情況給B賦值，實際情況是原圖146M+146M+中間壓縮結果30M左右，當前內存322M直接崩潰。優化這個操作的過程自然是盡量少創建中間變量，也不要賦值默認值，避免峰值崩潰。
關於產品中使用合適的圖片應該是多數app都會遇到的情況，比如首頁默認有10張圖，本來尺寸是比較小的UIImageView也沒有必要使用過大的圖片，不過實際情況很可能是通過後端請求的url來加載圖片。比如說一個64pt * 64pt的UIImageView要展示一個1080 * 1920 pixal的圖片內存佔用達在2x情況下多了126倍之多是完全沒必要的，不過後端的配置自然是不可信的，即使剛開始沒有問題說不準後面運營維護的時候上一張超大的圖片也是很有可能的。解決方式自然是向下採樣，不過這裏建議不要直接使用Core Graphics繪製，避免內存峰值過高，Apple也給了推薦的做法。
常見的壓縮方法：
func compressImage(_ image:UIImage, size:CGSize) -> UIImage? {
let targetSize = CGSize(width: size.width*UIScreen.main.scale, height: size.height*UIScreen.main.scale)
UIGraphicsBeginImageContext(targetSize)
image.draw(in: CGRect(origin: CGPoint.zero, size: targetSize))
let newImage = UIGraphicsGetImageFromCurrentImageContext()
UIGraphicsEndImageContext()
return newImage
}
推薦的做法：
func downsamplingImage(url:URL, size:CGSize) -> UIImage? {
let imageSourceOptions = [kCGImageSourceShouldCache:false] as CFDictionary
guard let imageSource = CGImageSourceCreateWithURL(url as CFURL, imageSourceOptions) else { return nil }
let maxDimension = max(size.width, size.height) * UIScreen.main.scale
let downsamplingOptions = [
kCGImageSourceCreateThumbnailFromImageAlways : true,
kCGImageSourceShouldCacheImmediately : true ,
kCGImageSourceCreateThumbnailWithTransform:true,
kCGImageSourceThumbnailMaxPixelSize : maxDimension
] as CFDictionary
guard let downsampleImage = CGImageSourceCreateThumbnailAtIndex(imageSource, 0, downsamplingOptions) else { return nil }
let newImage = UIImage(cgImage: downsampleImage)
return newImage
}
大量循環操作
此外關於一些循環操作，如果操作本身比較耗內存，通常的做法就是使用 autoreleasepool 確保一個操作完成后內存及時釋放，但是在PHImageManager獲取圖片時這種方法並不是太湊效。比如說下面的一段代碼獲取相冊中30張照片保存到沙盒：
guard let cachePath = NSSearchPathForDirectoriesInDomains(.cachesDirectory, FileManager.SearchPathDomainMask.userDomainMask, true).first else { return }
let assets = getAssets() // top 30
for i in 0..<assets.count {
let option = PHImageRequestOptions()
option.isSynchronous = false
option.isNetworkAccessAllowed = true
PHImageManager.default().requestImage(for: assets[i], targetSize: CGSize(width: 1080, height: 1920), contentMode: PHImageContentMode.aspectFit, options: option) { (image, info) in
if info?[PHImageResultIsDegradedKey] as? Bool == true {
return
}
if let image = image {
do {
let savePath = cachePath + "/\(i).png"
if FileManager.default.fileExists(atPath: savePath) {
try FileManager.default.removeItem(atPath: savePath)
}
try image.pngData()?.write(to: URL(fileURLWithPath: savePath))
} catch {
print("Error:\(error.localizedDescription)")
}
}
}
}
實測在iOS 13下面內存峰值85M左右，執行后內存65M,比執行前多了52M而且這個內存應該是會一直常駐，這也是網上很多文章中提到的增加autoreleasepool來及時釋放內存的原因。改造之後代碼：
guard let cachePath = NSSearchPathForDirectoriesInDomains(.cachesDirectory, FileManager.SearchPathDomainMask.userDomainMask, true).first else { return }
let assets = getAssets()
for i in 0..<assets.count {
autoreleasepool(invoking: {
let option = PHImageRequestOptions()
option.isSynchronous = false
option.isNetworkAccessAllowed = true
PHImageManager.default().requestImage(for: assets[i], targetSize: CGSize(width: 1080, height: 1920), contentMode: PHImageContentMode.aspectFit, options: option) { (image, info) in
if info?[PHImageResultIsDegradedKey] as? Bool == true {
return
}
if let image = image {
do {
let savePath = cachePath + "/\(i).png"
if FileManager.default.fileExists(atPath: savePath) {
try FileManager.default.removeItem(atPath: savePath)
}
try image.pngData()?.write(to: URL(fileURLWithPath: savePath))
} catch {
print("Error:\(error.localizedDescription)")
}
}
}
})
}
實測之後發現內存峰值降低到了65M左右，執行之後內存在50M左右，也就是峰值和之後常駐內存都有所降低，autoreleasepool有一定作用，但是作用不大，但是理論上這個常駐內存應該恢復到之前的10M左右的水平才對為什麼多了那麼多呢？原因是Photos獲取照片是有緩存的（注意在iPhone 6及以下設備不會緩存），這部分緩存如果進入後台會釋放（主要是IOSurface）。其實這個過程中內存主要包括兩部分 IOSurface 和 CG raster data ，那麼想要降低這兩部分內存其實針對上述場景最好的辦法是使用 PHImageManager.default().requestImageDataAndOrientation() 而不是 PHImageManager.default().requestImage() 實測上述情況內存峰值 18M 左右並且瞬間可降下來。那麼如果需求場景非要使用 PHImageManager.default().requestImage() 怎麼辦呢？答案是使用串行操作降低峰值。
guard let cachePath = NSSearchPathForDirectoriesInDomains(.cachesDirectory, FileManager.SearchPathDomainMask.userDomainMask, true).first else { return }
let semaphore = DispatchSemaphore(value: 0)
self.semaphore = semaphore
DispatchQueue.global().async {
let assets = self.getAssets()
for i in 0..<assets.count {
print(1)
autoreleasepool(invoking: {
let option = PHImageRequestOptions()
option.isSynchronous = false
option.isNetworkAccessAllowed = true
PHImageManager.default().requestImageDataAndOrientation(for: assets[i], options: option) { (data, _, orientation, info) in
if info?[PHImageResultIsDegradedKey] as? Bool == true {
return
}
defer {
semaphore.signal()
print(4)
}
do {
print(3)
let savePath = cachePath + "/\(i).png"
if FileManager.default.fileExists(atPath: savePath) {
try FileManager.default.removeItem(atPath: savePath)
}
try data?.write(to: URL(fileURLWithPath: savePath))
} catch {
print("Error:\(error.localizedDescription)")
}
}
})
print(2)
_ = semaphore.wait(timeout: .now() + .seconds(10))
print(5)
}
}
通過串行控制以後內存峰值穩定在16M左右，並且執行之後內存沒有明顯增長，但是相應的操作效率自然是下降了，整體時長增高。
總結
本文從內存泄漏和內存佔用兩個角度分析了解決OOM的問題，也是產品中實際遇到問題的一次徹查結果，列舉了常見引起OOM的原因，也對持久內存佔用給了一些實踐的建議，對於比較難發現的leak情況做了示例演示，也是產品實際遇到的，事實上在我們的產品中通過上面的手段OOM降低了80%以上，整體的App框架也並沒有做其他修改，所以有類似問題的同學不妨試一下。
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】
※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!
※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線
※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整
※南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!
※教你寫出一流的銷售文案?
※超省錢租車方案
