iOS面試題--性能優化篇

時間 2021-03-26

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

原文原文鏈接

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

收錄：原文地址