1.形成tableView卡頓的緣由有哪些?
-
1.最經(jīng)常使用的就是cell的重用愈腾, 注冊重用標識符
若是不重用cell時憋活,每當一個cell顯示到屏幕上時,就會從新建立一個新的cellhtml
若是有不少數(shù)據(jù)的時候虱黄,就會堆積不少cell余掖。ios
若是重用cell,為cell建立一個ID礁鲁,每當須要顯示cell 的時候,都會先去緩沖池中尋找可循環(huán)利用的cell赁豆,若是沒有再從新建立cellc++
-
2.避免cell的從新布局
cell的布局填充等操做 比較耗時仅醇,通常建立時就布局好面試
如能夠?qū)ell單獨放到一個自定義類,初始化時就布局好swift
-
3.提早計算并緩存cell的屬性及內(nèi)容
當咱們建立cell的數(shù)據(jù)源方法時魔种,編譯器并非先建立cell 再定cell的高度xcode
而是先根據(jù)內(nèi)容一次肯定每個cell的高度析二,高度肯定后,再建立要顯示的cell,滾動時叶摄,每當cell進入憑虛都會計算高度属韧,提早估算高度告訴編譯器,編譯器知道高度后蛤吓,緊接著就會建立cell宵喂,這時再調(diào)用高度的具體計算方法,這樣能夠方式浪費時間去計算顯示之外的cell緩存
-
4.減小cell中控件的數(shù)量
盡可能使cell得布局大體相同会傲,不一樣風格的cell可使用不用的重用標識符锅棕,初始化時添加控件,網(wǎng)絡(luò)
不適用的能夠先隱藏數(shù)據(jù)結(jié)構(gòu)
-
5.不要使用ClearColor淌山,無背景色裸燎,透明度也不要設(shè)置為0
渲染耗時比較長多線程
-
6.使用局部更新
若是只是更新某組的話,使用reloadSection進行局部更
7.加載網(wǎng)絡(luò)數(shù)據(jù)泼疑,下載圖片德绿,使用異步加載,并緩存
8.少使用addView 給cell動態(tài)添加view
9.按需加載cell退渗,cell滾動很快時移稳,只加載范圍內(nèi)的cell
10.不要實現(xiàn)無用的代理方法,tableView只遵照兩個協(xié)議
11.緩存行高:estimatedHeightForRow不能和HeightForRow里面的layoutIfNeed同時存在氓辣,這二者同時存在才會出現(xiàn)“竄動”的bug秒裕。因此個人建議是:只要是固定行高就寫預(yù)估行高來減小行高調(diào)用次數(shù)提高性能。若是是動態(tài)行高就不要寫預(yù)估方法了钞啸,用一個行高的緩存字典來減小代碼的調(diào)用次數(shù)便可
12.不要作多余的繪制工做几蜻。在實現(xiàn)drawRect:的時候,它的rect參數(shù)就是須要繪制的區(qū)域体斩,這個區(qū)域以外的不須要進行繪制梭稚。例如上例中,就能夠用CGRectIntersectsRect絮吵、CGRectIntersection或CGRectContainsRect判斷是否須要繪制image和text弧烤,而后再調(diào)用繪制方法。
13.預(yù)渲染圖像蹬敲。當新的圖像出現(xiàn)時暇昂,仍然會有短暫的停頓現(xiàn)象。解決的辦法就是在bitmap context里先將其畫一遍伴嗡,導(dǎo)出成UIImage對象急波,而后再繪制到屏幕;
14.使用正確的數(shù)據(jù)結(jié)構(gòu)來存儲數(shù)據(jù)瘪校。
2.如何提高 tableview 的流暢度澄暮?
-
本質(zhì)上是下降 CPU名段、GPU 的工做,從這兩個大的方面去提高性能泣懊。
CPU:對象的建立和銷毀伸辟、對象屬性的調(diào)整、布局計算馍刮、文本的計算和排版信夫、圖片的格式轉(zhuǎn)換和解碼、圖像的繪制
GPU:紋理的渲染
-
卡頓優(yōu)化在 CPU 層面
盡可能用輕量級的對象渠退,好比用不到事件處理的地方忙迁,能夠考慮使用 CALayer 取代 UIView
不要頻繁地調(diào)用 UIView 的相關(guān)屬性,好比 frame碎乃、bounds姊扔、transform 等屬性,盡可能減小沒必要要的修改
盡可能提早計算好布局梅誓,在有須要時一次性調(diào)整對應(yīng)的屬性恰梢,不要屢次修改屬性
Autolayout 會比直接設(shè)置 frame 消耗更多的 CPU 資源
圖片的 size 最好恰好跟 UIImageView 的 size 保持一致
控制一下線程的最大并發(fā)數(shù)量
盡可能把耗時的操做放到子線程
文本處理(尺寸計算、繪制)
圖片處理(解碼梗掰、繪制)
-
卡頓優(yōu)化在 GPU層面
盡可能避免短期內(nèi)大量圖片的顯示嵌言,盡量將多張圖片合成一張進行顯示
GPU能處理的最大紋理尺寸是 4096x4096,一旦超過這個尺寸及穗,就會占用 CPU 資源進行處理摧茴,因此紋理盡可能不要超過這個尺寸
盡可能減小視圖數(shù)量和層次
減小透明的視圖(alpha<1),不透明的就設(shè)置 opaque 為 YES
盡可能避免出現(xiàn)離屏渲染
-
iOS 保持界面流暢的技巧
1.預(yù)排版埂陆,提早計算
在接收到服務(wù)端返回的數(shù)據(jù)后苛白,盡可能將 CoreText 排版的結(jié)果、單個控件的高度焚虱、cell 總體的高度提早計算好购裙,將其存儲在模型的屬性中。須要使用時鹃栽,直接從模型中往外取躏率,避免了計算的過程。
盡可能少用 UILabel民鼓,可使用 CALayer 薇芝。避免使用 AutoLayout 的自動布局技術(shù),采起純代碼的方式
2.預(yù)渲染丰嘉,提早繪制
例如圓形的圖標能夠提早在恩掷,在接收到網(wǎng)絡(luò)返回數(shù)據(jù)時,在后臺線程進行處理供嚎,直接存儲在模型數(shù)據(jù)里,回到主線程后直接調(diào)用就能夠了
避免使用 CALayer 的 Border、corner克滴、shadow逼争、mask 等技術(shù),這些都會觸發(fā)離屏渲染劝赔。
3.異步繪制
4.全局并發(fā)線程
5.高效的圖片異步加載
3.APP啟動時間應(yīng)從哪些方面優(yōu)化誓焦?
App啟動時間能夠經(jīng)過xcode提供的工具來度量,在Xcode的Product->Scheme-->Edit Scheme->Run->Auguments中着帽,將環(huán)境變量DYLD_PRINT_STATISTICS設(shè)為YES杂伟,優(yōu)化需如下方面入手
-
dylib loading time
核心思想是減小dylibs的引用
合并現(xiàn)有的dylibs(最好是6個之內(nèi))
使用靜態(tài)庫
-
rebase/binding time
核心思想是減小DATA塊內(nèi)的指針
減小Object C元數(shù)據(jù)量,減小Objc類數(shù)量仍翰,減小實例變量和函數(shù)(與面向?qū)ο笤O(shè)計思想沖突)
減小c++虛函數(shù)
多使用Swift結(jié)構(gòu)體(推薦使用swift)
-
ObjC setup time
核心思想同上赫粥,這部份內(nèi)容基本上在上一階段優(yōu)化事后就不會太過耗時
initializer time
-
使用initialize替代load方法
減小使用c/c++的attribute((constructor));推薦使用dispatch_once() pthread_once() std:once()等方法
推薦使用swift
不要在初始化中調(diào)用dlopen()方法予借,由于加載過程是單線程越平,無鎖,若是調(diào)用dlopen則會變成多線程灵迫,會開啟鎖的消耗秦叛,同時有可能死鎖
不要在初始化中建立線程
4.如何下降A(chǔ)PP包的大小
下降包大小須要從兩方面著手
-
可執(zhí)行文件
編譯器優(yōu)化:Strip Linked Product、Make Strings Read-Only瀑粥、Symbols Hidden by Default 設(shè)置為 YES挣跋,去掉異常支持,Enable C++ Exceptions狞换、Enable Objective-C Exceptions 設(shè)置為 NO避咆, Other C Flags 添加 -fno-exceptions 利用 AppCode 檢測未使用的代碼:菜單欄 -> Code -> Inspect Code
編寫LLVM插件檢測出重復(fù)代碼、未被調(diào)用的代碼
-
資源(圖片哀澈、音頻牌借、視頻 等)
優(yōu)化的方式能夠?qū)Y源進行無損的壓縮
去除沒有用到的資源
5.如何檢測離屏渲染與優(yōu)化
- 檢測,經(jīng)過勾選Xcode的Debug->View Debugging-->Rendering->Run->Color Offscreen-Rendered Yellow項割按。
- 優(yōu)化膨报,如陰影,在繪制時添加陰影的路徑
6.怎么檢測圖層混合
一适荣、模擬器debug中color blended layers紅色區(qū)域表示圖層發(fā)生了混合
二现柠、Instrument-選中Core Animation-勾選Color Blended Layers
避免圖層混合:
- 確保控件的opaque屬性設(shè)置為true弛矛,確保backgroundColor和父視圖顏色一致且不透明
- 如無特殊須要够吩,不要設(shè)置低于1的alpha值
- 確保UIImage沒有alpha通道
UILabel圖層混合解決方法:
iOS8之后設(shè)置背景色為非透明色而且設(shè)置label.layer.masksToBounds=YES讓label只會渲染她的實際size區(qū)域,就能解決UILabel的圖層混合問題
iOS8 以前只要設(shè)置背景色為非透明的就行
為何設(shè)置了背景色可是在iOS8上仍然出現(xiàn)了圖層混合呢丈氓?
UILabel在iOS8先后的變化周循,在iOS8之前强法,UILabel使用的是CALayer做為底圖層,而在iOS8開始湾笛,UILabel的底圖層變成了_UILabelLayer饮怯,繪制文本也有所改變。在背景色的四周多了一圈透明的邊嚎研,而這一圈透明的邊明顯超出了圖層的矩形區(qū)域蓖墅,設(shè)置圖層的masksToBounds為YES時,圖層將會沿著Bounds進行裁剪 圖層混合問題解決了
7.平常如何檢查內(nèi)存泄露临扮?
-
目前我知道的方式有如下幾種
Memory Leaks
Alloctions
Analyse
Debug Memory Graph
MLeaksFinder
-
泄露的內(nèi)存主要有如下兩種:
Laek Memory 這種是忘記 Release 操做所泄露的內(nèi)存论矾。
Abandon Memory 這種是循環(huán)引用,沒法釋放掉的內(nèi)存杆勇。
作為一個開發(fā)者贪壳,有一個學習的氛圍跟一個交流圈子特別重要,這是一個我的iOS開發(fā)交流群:130 595 548靶橱,不管你是小白還是大牛都歡迎入駐 寥袭,讓我們一起進步,共同發(fā)展9匕浴(群內(nèi)會免費提供一些群主收藏的免費學習書籍資料以及整理好的幾百道面試題和答案文檔4啤)
以下圖所示: