iOS面試題，性能優化篇！

時間 2021-08-13

標籤 html ios c++ 面試 swift xcode 緩存網絡數據結構多線程欄目 iOS 简体版

原文原文鏈接

1.造成tableView卡頓的原因有哪些？

1.最常用的就是cell的重用，註冊重用標識符html
如果不重用cell時，每當一個cell顯示到屏幕上時，就會重新創建一個新的cellhtmlios
如果有很多數據的時候，就會堆積很多cell。iosc++
如果重用cell，爲cell創建一個ID，每當需要顯示cell 的時候，都會先去緩衝池中尋找可循環利用的cell，如果沒有再重新創建cellc++面試
2.避免cell的重新佈局swift
cell的佈局填充等操作比較耗時，一般創建時就佈局好面試xcode
如可以將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.怎麼檢測圖層混合

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 這種是循環引用，無法釋放掉的內存。