1.形成tableView卡頓的緣由有哪些？
-
1.最經常使用的就是cell的重用， 注冊重用標識符
若是不重用cell時，每當一個cell顯示到屏幕上時，就會從新建立一個新的cellhtml
若是有不少數據的時候，就會堆積不少cell。ios
若是重用cell，為cell建立一個ID，每當須要顯示cell 的時候，都會先去緩沖池中尋找可循環利用的cell，若是沒有再從新建立cellc++
-
2.避免cell的從新布局
cell的布局填充等操做 比較耗時，通常建立時就布局好面試
如能夠將cell單獨放到一個自定義類，初始化時就布局好swift
-
3.提早計算并緩存cell的屬性及內容
當咱們建立cell的數據源方法時，編譯器并非先建立cell 再定cell的高度xcode
而是先根據內容一次肯定每個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.怎么檢測圖層混合
一、模擬器debug中color blended layers紅色區域表示圖層發生了混合
二、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開發交流群：130 595 548，不管你是小白還是大牛都歡迎入駐 ，讓我們一起進步，共同發展！（群內會免費提供一些群主收藏的免費學習書籍資料以及整理好的幾百道面試題和答案文檔！）
以下圖所示:
