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緩存

如果你正在面試昆庇，或者正準備跳槽末贾，不妨看看我精心總結(jié)的iOS大廠面試資料：https://gitee.com/Mcci7/i-oser 來獲取一份詳細的大廠面試資料 為你的跳槽加薪多一份保障

• 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ā)者婆硬，有一個學(xué)習(xí)的氛圍跟一個交流圈子特別重要，這是一個我的iOS開發(fā)交流群：413038000奸例，不管你是小白還是大牛都歡迎入駐 彬犯，讓我們一起進步，共同發(fā)展２榈酢（群內(nèi)會免費提供一些群主收藏的免費學(xué)習(xí)書籍資料以及整理好的幾百道面試題和答案文檔Ｐ城）

以下圖所示:

image