1.造成tableView卡頓的原因有哪些？
-
1.最常用的就是cell的重用， 注冊重用標識符
如果不重用cell時，每當一個cell顯示到屏幕上時，就會重新創建一個新的cell
如果有很多數據的時候，就會堆積很多cell。
如果重用cell，為cell創建一個ID，每當需要顯示cell 的時候，都會先去緩沖池中尋找可循環利用的cell，如果沒有再重新創建cell
-
2.避免cell的重新布局
cell的布局填充等操作 比較耗時，一般創建時就布局好
如可以將cell單獨放到一個自定義類，初始化時就布局好
-
3.提前計算并緩存cell的屬性及內容
當我們創建cell的數據源方法時，編譯器并不是先創建cell 再定cell的高度
而是先根據內容一次確定每一個cell的高度，高度確定后，再創建要顯示的cell，滾動時，每當cell進入憑虛都會計算高度，提前估算高度告訴編譯器，編譯器知道高度后，緊接著就會創建cell，這時再調用高度的具體計算方法，這樣可以方式浪費時間去計算顯示以外的cell
-
4.減少cell中控件的數量
盡量使cell得布局大致相同，不同風格的cell可以使用不用的重用標識符，初始化時添加控件，
不適用的可以先隱藏
-
5.不要使用ClearColor，無背景色，透明度也不要設置為0
渲染耗時比較長
-
6.使用局部更新
如果只是更新某組的話，使用reloadSection進行局部更
7.加載網絡數據，下載圖片，使用異步加載，并緩存
8.少使用addView 給cell動態添加view
9.按需加載cell，cell滾動很快時，只加載范圍內的cell
10.不要實現無用的代理方法，tableView只遵守兩個協議
11.緩存行高：estimatedHeightForRow不能和HeightForRow里面的layoutIfNeed同時存在，這兩者同時存在才會出現“竄動”的bug。所以我的建議是：只要是固定行高就寫預估行高來減少行高調用次數提升性能。如果是動態行高就不要寫預估方法了，用一個行高的緩存字典來減少代碼的調用次數即可
12.不要做多余的繪制工作。在實現drawRect:的時候，它的rect參數就是需要繪制的區域，這個區域之外的不需要進行繪制。例如上例中，就可以用CGRectIntersectsRect、CGRectIntersection或CGRectContainsRect判斷是否需要繪制image和text，然后再調用繪制方法。
13.預渲染圖像。當新的圖像出現時，仍然會有短暫的停頓現象。解決的辦法就是在bitmap context里先將其畫一遍，導出成UIImage對象，然后再繪制到屏幕；
14.使用正確的數據結構來存儲數據。
2.如何提升 tableview 的流暢度？
-
本質上是降低 CPU、GPU 的工作，從這兩個大的方面去提升性能。
CPU：對象的創建和銷毀、對象屬性的調整、布局計算、文本的計算和排版、圖片的格式轉換和解碼、圖像的繪制
GPU：紋理的渲染
-
卡頓優化在 CPU 層面
盡量用輕量級的對象，比如用不到事件處理的地方，可以考慮使用 CALayer 取代 UIView
不要頻繁地調用 UIView 的相關屬性，比如 frame、bounds、transform 等屬性，盡量減少不必要的修改
盡量提前計算好布局，在有需要時一次性調整對應的屬性，不要多次修改屬性
Autolayout 會比直接設置 frame 消耗更多的 CPU 資源
圖片的 size 最好剛好跟 UIImageView 的 size 保持一致
控制一下線程的最大并發數量
盡量把耗時的操作放到子線程
文本處理（尺寸計算、繪制）
圖片處理（解碼、繪制）
-
卡頓優化在 GPU層面
盡量避免短時間內大量圖片的顯示，盡可能將多張圖片合成一張進行顯示
GPU能處理的最大紋理尺寸是 4096x4096，一旦超過這個尺寸，就會占用 CPU 資源進行處理，所以紋理盡量不要超過這個尺寸
盡量減少視圖數量和層次
減少透明的視圖（alpha<1），不透明的就設置 opaque 為 YES
盡量避免出現離屏渲染
-
iOS 保持界面流暢的技巧
1.預排版，提前計算
在接收到服務端返回的數據后，盡量將 CoreText 排版的結果、單個控件的高度、cell 整體的高度提前計算好，將其存儲在模型的屬性中。需要使用時，直接從模型中往外取，避免了計算的過程。
盡量少用 UILabel，可以使用 CALayer 。避免使用 AutoLayout 的自動布局技術，采取純代碼的方式
2.預渲染，提前繪制
例如圓形的圖標可以提前在，在接收到網絡返回數據時，在后臺線程進行處理，直接存儲在模型數據里，回到主線程后直接調用就可以了
避免使用 CALayer 的 Border、corner、shadow、mask 等技術，這些都會觸發離屏渲染。
3.異步繪制
4.全局并發線程
5.高效的圖片異步加載
3.APP啟動時間應從哪些方面優化？
App啟動時間可以通過xcode提供的工具來度量，在Xcode的Product->Scheme-->Edit Scheme->Run->Auguments中，將環境變量DYLD_PRINT_STATISTICS設為YES，優化需以下方面入手
-
dylib loading time
核心思想是減少dylibs的引用
合并現有的dylibs（最好是6個以內）
使用靜態庫
-
rebase/binding time
核心思想是減少DATA塊內的指針
減少Object C元數據量，減少Objc類數量，減少實例變量和函數（與面向對象設計思想沖突）
減少c++虛函數
多使用Swift結構體（推薦使用swift）
-
ObjC setup time
核心思想同上，這部分內容基本上在上一階段優化過后就不會太過耗時
initializer time
-
使用initialize替代load方法
減少使用c/c++的attribute((constructor))；推薦使用dispatch_once() pthread_once() std:once()等方法
推薦使用swift
不要在初始化中調用dlopen()方法，因為加載過程是單線程，無鎖，如果調用dlopen則會變成多線程，會開啟鎖的消耗，同時有可能死鎖
不要在初始化中創建線程
4.如何降低APP包的大小
降低包大小需要從兩方面著手
-
可執行文件
編譯器優化：Strip Linked Product、Make Strings Read-Only、Symbols Hidden by Default 設置為 YES，去掉異常支持，Enable C++ Exceptions、Enable Objective-C Exceptions 設置為 NO， Other C Flags 添加 -fno-exceptions 利用 AppCode 檢測未使用的代碼：菜單欄 -> Code -> Inspect Code
編寫LLVM插件檢測出重復代碼、未被調用的代碼
-
資源（圖片、音頻、視頻 等）
優化的方式可以對資源進行無損的壓縮
去除沒有用到的資源
5.如何檢測離屏渲染與優化
檢測，通過勾選Xcode的Debug->View Debugging-->Rendering->Run->Color Offscreen-Rendered Yellow項。
優化，如陰影，在繪制時添加陰影的路徑
6.怎么檢測圖層混合
1、模擬器debug中color blended layers紅色區域表示圖層發生了混合
2、Instrument-選中Core Animation-勾選Color Blended Layers
避免圖層混合：
確保控件的opaque屬性設置為true，確保backgroundColor和父視圖顏色一致且不透明
如無特殊需要，不要設置低于1的alpha值
確保UIImage沒有alpha通道
UILabel圖層混合解決方法：
iOS8以后設置背景色為非透明色并且設置label.layer.masksToBounds=YES讓label只會渲染她的實際size區域，就能解決UILabel的圖層混合問題
iOS8 之前只要設置背景色為非透明的就行
為什么設置了背景色但是在iOS8上仍然出現了圖層混合呢？
UILabel在iOS8前后的變化，在iOS8以前，UILabel使用的是CALayer作為底圖層，而在iOS8開始，UILabel的底圖層變成了_UILabelLayer，繪制文本也有所改變。在背景色的四周多了一圈透明的邊，而這一圈透明的邊明顯超出了圖層的矩形區域，設置圖層的masksToBounds為YES時，圖層將會沿著Bounds進行裁剪 圖層混合問題解決了
7.日常如何檢查內存泄露？
-
目前我知道的方式有以下幾種
Memory Leaks
Alloctions
Analyse
Debug Memory Graph
MLeaksFinder
-
泄露的內存主要有以下兩種：
Laek Memory 這種是忘記 Release 操作所泄露的內存。
Abandon Memory 這種是循環引用，無法釋放掉的內存。
需要iOS開發學習資料、大廠面試真題，可加 iOS技術探討群：937194184，群文件直接獲取
如下圖所示:
