多線程：

進(jìn)程和線程的區(qū)別：進(jìn)程是火車, 線程是車廂挚冤。進(jìn)程間不共享上下文, 同一進(jìn)程下的線程共享進(jìn)程的上下文
? 同步（sync）：阻塞當(dāng)前線程, 任務(wù)立即執(zhí)行
? 異步（async）：可以在新的線程中執(zhí)行任務(wù), 具備開啟新線程的能力慎璧。
? 串行：同一時間只有一個任務(wù)執(zhí)行
? 并行：同一時間有多個任務(wù)執(zhí)行（多核）
? 并發(fā)：單核通過時間片輪轉(zhuǎn)宏觀上實(shí)現(xiàn)并行的機(jī)制

數(shù)據(jù)結(jié)構(gòu)：

? 堆：邏輯結(jié)構(gòu)完全二叉樹, 可以用一維數(shù)組實(shí)現(xiàn), 這種數(shù)據(jù)結(jié)構(gòu)方便求極值烈疚。向上調(diào)整算法/向下調(diào)整算法
? 棧：先進(jìn)后出, 可以用一維數(shù)組或者鏈表實(shí)現(xiàn)

內(nèi)存：

? 堆：動態(tài)分配, 主要為了解決棧空間釋放后變量也被釋放的問題
? 棧：邏輯上先進(jìn)后出, 由系統(tǒng)控制黎休。

Swift:

函數(shù)調(diào)用方式：

靜態(tài), 動態(tài)。動態(tài)包括函數(shù)表調(diào)用和消息發(fā)送。擴(kuò)展（extension）沒有函數(shù)表, 所以只能使用靜態(tài)或者消息發(fā)送的方式翼虫。結(jié)構(gòu)體及其擴(kuò)展靜態(tài)調(diào)用；類默認(rèn)函數(shù)表調(diào)用, final-靜態(tài), @objc-函數(shù)表, dynamic-消息發(fā)送屡萤；類擴(kuò)展默認(rèn)使用靜態(tài)調(diào)用, 類擴(kuò)展+@objc/dynamic-消息發(fā)送

Swift與OC區(qū)別：

1. Swift是靜態(tài)語言, 有類型推斷, OC是動態(tài)語言
2. Swift面向協(xié)議編程, OC面向?qū)ο缶幊?/li>
3. Swift注重值類型, OC注重引用類型
4. Swift支持泛型, OC只支持輕量泛型
5. Swift支持靜態(tài)派發(fā)(效率高)珍剑、動態(tài)派發(fā)(函數(shù)表派發(fā)、消息派發(fā)), OC支持動態(tài)派發(fā)(消息派發(fā))
6. Swift支持函數(shù)式編程
7. Swift的協(xié)議不僅可以被類實(shí)現(xiàn), 也可以被struct和enum實(shí)現(xiàn)
8. Swift有元組類型死陆、支持運(yùn)算法重載
9. Swift支持命名空間
10. Swift支持默認(rèn)參數(shù)(函數(shù))
11. Swift比OC代碼更簡潔
12. 值類型優(yōu)化:如寫時拷貝

Block：

全局block在數(shù)據(jù)區(qū), 沒有捕獲變量的block原本應(yīng)該在棧, 但是編譯器優(yōu)化, 轉(zhuǎn)移到了數(shù)據(jù)區(qū)招拙。捕獲變量的block變量會在堆, 但如果是block對象, 因?yàn)闆]有變量名, 所以不會再其他地方調(diào)用, 會在棧。捕獲變量的block對象如果對其使用copy, 會在堆措译。（MRC下, 如果不對捕獲變量的block使用COPY, 就在棧）

layoutSubviews調(diào)用時機(jī)：

有尺寸且添加到父View上時, 父視圖是ScrollView且滾動時, 改變尺寸時

load别凤、initialize方法的區(qū)別:

? 調(diào)用方式

1. load是根據(jù)函數(shù)地址直接調(diào)用
2. initialize是通過objc_msgSend調(diào)用

? 調(diào)用時刻

1. load是runtime加載類、分類的時候調(diào)用（只會調(diào)用1次）
2. initialize是類第一次接收到消息的時候調(diào)用, 每一個類只會initialize一次,

如果有SubClass繼承Class.
則在SubClass第一次收到消息時, 會先調(diào)用SubClass-initialize, 再調(diào)用Class-initialize;
如果SubClass沒有重寫initialize, 則在SubClass-initialize過程中觸發(fā)Class-initialize, 表現(xiàn)為Class-initialize被調(diào)用了兩次. 即一個類向上的繼承樹上有N個類, 在接收到消息時就會觸發(fā)N+1次initialize, 如果某個類沒有重寫initialize, 則會向上調(diào)用最近的initialize
綜上: 重寫initialize時需用考慮使用dispatchonce避免重復(fù)調(diào)用和初始化.

熱啟動與冷啟動

參考: http://events.jianshu.io/p/783d8b3ef884 领虹、 http://www.reibang.com/p/4c1adabc8b90

1. 熱啟動：就是按下home鍵的時候, app還存在一段時間, 這時點(diǎn)擊app馬上就能恢復(fù)到原狀態(tài), 這種啟動我們稱為熱啟動规哪。當(dāng)APP 啟動時需要的 dylibs 仍然停留在設(shè)備的磁盤緩存的時候,這個時候就是熱啟動,熱啟動的速度會更快。
2. 冷啟動：app被kill掉之后, 重新打開啟動過程為冷啟動掠械。

性能優(yōu)化：

冷啟動:

冷啟動可大致分為兩個階段, 分別為main函數(shù)之前由缆、main之后到didFinishLaunching執(zhí)行完畢, 很多時候, 首頁的完成展示前的階段可包含在啟動階段內(nèi). 上述兩個階段為pre-main和main.

pre-main階段:

pre-main的過程

1. 加載mach-o可執(zhí)行文件
2. 加載dyld到App進(jìn)程,
3. 加載動態(tài)庫（包括所依賴的所有動態(tài)庫）
4. Rebase 內(nèi)部指針調(diào)整。
5. Bind 把指針正確的指向Image外部的內(nèi)容猾蒂。通過符號表查找
6. 初始化Objective-C Runtime, Objc運(yùn)行時的初始化處理, 包括Objc相關(guān)類的注冊均唉、category注冊、selector唯一性檢查
7. 其他初始化, 包括執(zhí)行了+load()方法肚菠、attribute((constructor))修飾的函數(shù)調(diào)用舔箭、創(chuàng)建C++靜態(tài)全局變量

針對pre-main的優(yōu)化:

1. 盡量縮小mach-o的大小(待研究) - 1
2. 減少動態(tài)庫, 在動態(tài)庫較多時將多個動態(tài)庫合并 - 3
3. 減少Objc類, category的數(shù)量, 清除用不到的類、函數(shù) - 4, 6
4. 使用dispatchonce+initialize代替+load, 盡量減少attribute((constructor))的調(diào)用, 也可以考慮用dispatchonce+initialize代替 - 7
5. 二進(jìn)制重排.

t1.png

main階段:

1. dyld調(diào) main()
2. 調(diào)UIApplicationMain()
3. 調(diào)applicationWillFinishLaunching
4. 調(diào)didFinishLaunchingWithOptions

這部分包含大量APP配置和業(yè)務(wù)代碼, 梳理好其內(nèi)容, 將能延后的內(nèi)容盡量延后, 此階段可用的辦法有:

1. 延后部分代碼執(zhí)行
2. 使用閃屏優(yōu)化體驗(yàn)
3. 內(nèi)嵌啟動首頁展示數(shù)據(jù)
4. 多線程

熱啟動

1. 數(shù)據(jù)優(yōu)化,將耗時操作做異步處理。
2. 檢查NSUserDefaults的存儲,NSUserDefaults實(shí)際上是在Library文件夾下會生產(chǎn)一個plist文件,加載的時候是整個plist配置文件全部load到內(nèi)存中层扶。所以非常頻繁的存取大量數(shù)據(jù)也是有可能導(dǎo)致APP啟動卡頓的

卡頓

參考 https://zhuanlan.zhihu.com/p/502990984

手機(jī)成像過程

產(chǎn)生卡頓是由于屏幕的成像顯示導(dǎo)致, 而屏幕畫面的顯示離不開手機(jī)的CPU和GPU. CPU主要負(fù)責(zé)計算, 比如說界面的布局排版, 文字的大小和顏色, 圖片顯示的解碼等操作都需要CPU計算, CPU將計算好的數(shù)據(jù)提交給GPU, GPU就將CPU計算好的數(shù)據(jù)進(jìn)行渲染箫章。因?yàn)槠聊伙@示的數(shù)據(jù)是特定格式的,只有通過GPU渲染過的數(shù)據(jù)才能顯示在屏幕上；GPU把渲染過的數(shù)據(jù)放到幀緩存區(qū), 視頻控制器從幀緩存區(qū)讀取數(shù)據(jù)顯示到屏幕上.

卡頓.png

卡頓的主要原因

CPU和GPU所花費(fèi)的時間太長從而造成俗稱的丟幀（掉幀）. 垂直同步信號的發(fā)射頻率是固定的, 信號發(fā)出, 表明著即將顯示數(shù)據(jù)镜会。若是期間, CPU或GPU有一步耗時較長（第3幀的渲染）, 垂直信號已發(fā)出, 可是GPU尚未渲染完, 那么就是顯示渲染好的第2幀數(shù)據(jù), 連續(xù)顯示相同的幀, 就形成了畫面卡頓; 第3幀會在第4次同步信號過來時再顯示檬寂。這就是卡頓的根本原因.

1. CPU和GPU

CUP(Central processing Unit,中央處理器)
對象的創(chuàng)建和銷毀、對象屬性的調(diào)整戳表、布局計算桶至、文本的計算和排版、圖片的格式轉(zhuǎn)換和解碼匾旭、圖像的繪制(Core Graphics)

GPU (Graphics Processing Unit镣屹，圖形處理器)
紋理的渲染

優(yōu)化:

• 盡可能減少CPU、GPU資源消耗
• 盡量用輕量級的對象价涝，比如用不到事件處理的地方女蜈，可以考慮使用CALayer取代UIView
• 不要頻繁地調(diào)用UIView的相關(guān)屬性，比如frame色瘩、bounds伪窖、transform等屬性，盡量減少不必要的修改
• 盡量提前計算好布局泞遗，在有需要時一次性調(diào)整對應(yīng)的屬性惰许，不要多次修改屬性
• Autolayout會比直接設(shè)置frame消耗更多的CPU資源
• 圖片的size最好剛好跟UIImageView的size保持一致
• 控制一下線程的最大并發(fā)數(shù)量
• 盡量避免短時間內(nèi)大量圖片的顯示，盡可能將多張圖片合成一張進(jìn)行顯示
• GPU能處理的最大紋理尺寸是4096x4096史辙，一旦超過這個尺寸汹买，就會占用CPU資源進(jìn)行處理，所以紋理盡量不要超過這個尺寸
• 盡量減少視圖數(shù)量和層次
• 減少透明的視圖(alpha<1)聊倔，不透明的就設(shè)置opaque為YES
• 盡量把耗時的操作放到子線程（文本尺寸晦毙、圖片處理）

2. 離屏渲染（盡量避免出現(xiàn)離屏渲染）

在OpenGL中，GPU有2種渲染方式
On-Screen Rendering:當(dāng)前屏幕渲染耙蔑，在當(dāng)前用于顯示的屏幕緩沖區(qū)進(jìn)行渲染操作
Off-Screen Rendering:離屏渲染见妒，在當(dāng)前屏幕緩沖區(qū)以外新開辟一個緩沖區(qū)進(jìn)行渲染操作

離屏渲染消耗性能的原因

1、需要創(chuàng)建新的緩沖區(qū)
2甸陌、離屏渲染的整個過程须揣，需要多次切換上下文環(huán)境，先是從當(dāng)前屏幕(On-Screen)切換到離屏(Off-Screen);等到離屏渲染結(jié)束以后钱豁，將離屏緩沖區(qū)的渲染結(jié)果顯示到屏幕上耻卡，又需要將上下文環(huán)境從離屏切換到當(dāng)前屏幕

哪些操作會觸發(fā)離屏渲染?

光柵化，layer.shouldRasterize = YES
遮罩牲尺，layer.mask
? 圓角卵酪，同時設(shè)置layer.masksToBounds = YES幌蚊、layer.cornerRadius大于0（考慮通過CoreGraphics繪制裁剪圓角，或者叫UI提供圓角圖片）
陰影溃卡，layer.shadowXXX (如果設(shè)置了layer.shadowPath就不會產(chǎn)生離屏渲染)溢豆。

耗電

1. 盡可能降低CPU、GPU功耗
2. 少用定時器
3. 優(yōu)化I/O操作
4. 盡量不要頻繁寫入小數(shù)據(jù)瘸羡，最好批量一次性寫入
5. 讀寫大量重要數(shù)據(jù)時漩仙，考慮用dispatch_io，其提供了基于GCD的異步操作文件I/O的API犹赖。用dispatch_io系統(tǒng)會優(yōu)化磁盤訪問
6. 數(shù)據(jù)量比較大的讯赏，建議使用數(shù)據(jù)庫(比如SQLite、CoreData)

網(wǎng)絡(luò)

1. 減少冷尉、壓縮網(wǎng)絡(luò)數(shù)據(jù)
2. 如果多次請求的結(jié)果是相同的，盡量使用緩存
3. 使用斷點(diǎn)續(xù)傳系枪，否則網(wǎng)絡(luò)不穩(wěn)定時可能多次傳輸相同的內(nèi)容
4. 網(wǎng)絡(luò)不可用時雀哨，不要嘗試執(zhí)行網(wǎng)絡(luò)請求
5. 讓用戶可以取消長時間運(yùn)行或者速度很慢的網(wǎng)絡(luò)操作，設(shè)置合適的超時時間
6. 批量傳輸私爷，比如雾棺，下載視頻流時，不要傳輸很小的數(shù)據(jù)包衬浑，直接下載整個文件或者一大塊一大塊地下載捌浩。如果下載廣告，一 次性多下載一些工秩，然后再慢慢展示尸饺。如果下載電子郵件，一次下載多封助币，不要一封一封地下載

定位

1. 如果只是需要快速確定用戶位置浪听，最好用CLLocationManager的requestLocation方法。定位完成后眉菱，會自動讓定位硬件斷電
2. 如果不是導(dǎo)航應(yīng)用迹栓，盡量不要實(shí)時更新位置，定位完畢就關(guān)掉定位服務(wù)
3. 盡量降低定位精度俭缓，比如盡量不要使用精度最高的kCLLocationAccuracyBest
4. 需要后臺定位時克伊，盡量設(shè)置pausesLocationUpdatesAutomatically為YES，如果用戶不太可能移動的時候系統(tǒng)會自動暫停位置更新
5. 盡量不要使用startMonitoringSignificantLocationChanges华坦，優(yōu)先考慮startMonitoringForRegion:
6. 用戶移動愿吹、搖晃、傾斜設(shè)備時季春，會產(chǎn)生動作(motion)事件洗搂，這些事件由加速度計、陀螺儀、磁力計等硬件檢測耘拇。在不需要檢測的場合撵颊，應(yīng)該及時關(guān)閉這些硬件