建議學(xué)會 單元測試
起因
我們公司的主App在大約17年5月份前后經(jīng)歷了一次大版本迭代，迭代之后更換了若干個一級和二級頁面，首頁就在這些個一級頁面之內(nèi)。
17年大約11月份的時候，我們的小程序第一個版本正式上線，然后我們技術(shù)的大Leader拿來了小程序給我們看看，小程序的首頁流暢性確實優(yōu)于我們客戶端，于是我們正式啟動了性能優(yōu)化。
明確優(yōu)化的目標(biāo)
優(yōu)化的第一步，肯定是要明確我們優(yōu)化具體的Case，需要達(dá)到什么樣的流暢度？是fps達(dá)到60？還是要內(nèi)存使用降到一個具體的數(shù)字？
討論之后，我們最終將第一期優(yōu)化定位為將首頁的fps優(yōu)化到60。
調(diào)研過程
雖然說是第一期將目標(biāo)定位優(yōu)先優(yōu)化首頁的流暢度，但是本著有第一次就要有第二次的原則，我還是將App中的其他流暢度敏感頁面也Review了一遍代碼，算是給自己留一個優(yōu)化思考的方向。
Review代碼發(fā)現(xiàn)一些比較顯而易見的問題：
肆意調(diào)用數(shù)據(jù)庫而沒有用cache
復(fù)雜UI大量使用約束
離屏渲染
像素混合
PS：因為我們的IM系統(tǒng)是我們自己寫的，中間又經(jīng)歷了公司分家，人員換了好幾茬，于是就導(dǎo)致了在本來架構(gòu)不合理的基礎(chǔ)上，實現(xiàn)業(yè)務(wù)和功能的代碼更是屎一樣，所以IM的問題更嚴(yán)重。而且我們已經(jīng)計劃了對于IM的重構(gòu)時間表，所以我會在另一篇Blog里寫一下我的重構(gòu)思路。
方案整理
影響流暢度的主要原因：
1、文本寬高計算、視圖布局計算
2、文本渲染、圖片解碼、圖形繪制
3、對象創(chuàng)建、對象調(diào)整、對象銷毀
CPU資源消耗原因以及解決辦法：
1、對象的創(chuàng)建：
對象的創(chuàng)建會分配內(nèi)存、設(shè)置屬性等，會消耗CPU資源。所以盡量使用輕量對象代替，比如能用CALayer的時候盡量不用UIView，敏感位置能不用IB盡量使用純代碼手寫。
推遲同一時間創(chuàng)建對象，推薦使用懶加載在需要使用時候創(chuàng)建對象。
2、對象調(diào)整
對 UIView 的這些屬性進(jìn)行調(diào)整時，消耗的資源要遠(yuǎn)大于一般的屬性。對此你在應(yīng)用中，應(yīng)該盡量減少不必要的屬性修改。
當(dāng)視圖層次調(diào)整時，UIView、CALayer 之間會出現(xiàn)很多方法調(diào)用與通知，所以在優(yōu)化性能時，應(yīng)該盡量避免調(diào)整視圖層次、添加和移除視圖。
3、對象銷毀
當(dāng)前類持有大量對象時候，其銷毀時候的資源消耗就非常明顯。建議創(chuàng)建銷毀的異步隊列，將需要銷毀的對象放到隊列中銷毀。
4、布局計算
布局計算在UITableView使用中是最常見的消耗資源的地方。建議取到數(shù)據(jù)之后，異步進(jìn)行計算布局并緩存下來，當(dāng)復(fù)用Cell時候直接調(diào)用緩存數(shù)據(jù)。
5、AutoLayout
Autolayout 對于復(fù)雜視圖來說常常會產(chǎn)生嚴(yán)重的性能問題，AutoLayout相對低效的原因是隱藏在底層的命名為”Cassowary“的約束求解系統(tǒng)，隨著視圖數(shù)量的增長，Autolayout 帶來的 CPU 消耗會呈指數(shù)級上升，當(dāng)Cell內(nèi)約束超過25個的時候，會降低滑動的幀率。
6、文本的計算以及渲染
UI中存在大量的對于文本高度的適配，可以參考：用 [NSAttributedString boundingRectWithSize:options:context:] 來計算文本寬高，用 -[NSAttributedString drawWithRect:options:context:] 來繪制文本。盡管這兩個方法性能不錯，但仍舊需要放到后臺線程進(jìn)行以避免阻塞主線程。
常見的文本控件 （UILabel、UITextView 等），其排版和繪制都是在主線程進(jìn)行的，當(dāng)顯示大量文本時，CPU 的壓力會非常大。解決辦法是利用TextKit或者是CoreText自定義文本控件。詳見：YYText。
7、圖片解碼以及圖像的繪制
當(dāng)你用 UIImage 或 CGImageSource 的那幾個方法創(chuàng)建圖片時，圖片數(shù)據(jù)并不會立刻解碼。圖片設(shè)置到 UIImageView 或者 CALayer.contents 中去，并且 CALayer 被提交到 GPU 前，CGImage 中的數(shù)據(jù)才會得到解碼。這一步是發(fā)生在主線程的，并且不可避免。如果想要繞開這個機(jī)制，常見的做法是在后臺線程先把圖片繪制到 CGBitmapContext 中，然后從 Bitmap 直接創(chuàng)建圖片。目前常見的網(wǎng)絡(luò)圖片庫都自帶這個功能。
個最常見的地方就是 [UIView drawRect:] 里面了。由于 CoreGraphic 方法通常都是線程安全的，所以圖像的繪制可以很容易的放到后臺線程進(jìn)行。
8、文件系統(tǒng)的調(diào)用
NSFileManager獲取一個目錄獲取文件信息，進(jìn)行多次遞歸計算，stat幾乎瞬間完成，NSFileManager耗時較長且消耗CPU。
GPU資源消耗原因以及解決辦法：
1、紋理的渲染
當(dāng)在較短時間顯示大量圖片時（比如 TableView 存在非常多的圖片并且快速滑動時），CPU 占用率很低，GPU 占用非常高，界面仍然會掉幀。避免這種情況的方法只能是盡量減少在短時間內(nèi)大量圖片的顯示，盡可能將多張圖片合成為一張進(jìn)行顯示。
2、視圖的混合（Blended）
視圖結(jié)構(gòu)過于復(fù)雜，混合的過程、會消耗很多 GPU 資源。為了減輕這種情況的 GPU 消耗，應(yīng)用應(yīng)當(dāng)盡量減少視圖數(shù)量和層次，并在不透明的視圖里標(biāo)明 opaque 屬性以避免無用的 Alpha 通道合成。當(dāng)然，這也可以用上面的方法，把多個視圖預(yù)先渲染為一張圖片來顯示。
Blended Layers（視圖混合）：在同一個區(qū)域內(nèi)，存在著多個有透明度的圖層，那么GPU需要更多的計算，混合上下多個圖層才能得出最終像素的RGB值。
Misaligned Images（像素對齊）：邏輯像素（point）和 物理像素（pixel)無法相匹配；圖片的size和顯示圖片的imageView的size（邏輯像素（point））不相等。
3、圖形的生成
CALayer 的 border、圓角、陰影、遮罩（mask），CASharpLayer 的矢量圖形顯示，通常會觸發(fā)離屏渲染（offscreen rendering），而離屏渲染通常發(fā)生在 GPU 中?？梢試L試開啟 CALayer.shouldRasterize 屬性，但這會把原本離屏渲染的操作轉(zhuǎn)嫁到 CPU 上去。
好的方法是使用圖片遮罩等方法，避免使用圓角和隱形等。詳細(xì)：iOS的離屏渲染
解決方案：
1、預(yù)先計算UI布局
獲取數(shù)據(jù)之后，異步計算Cell高度以及各控件高度和位置，并儲存在CellLayouModel中，當(dāng)每次Cell需要高度以及內(nèi)部布局的時候就可以直接調(diào)用，不需要進(jìn)行重復(fù)計算。
2、使用自動緩存高度
iOS 8之后出現(xiàn)了UITableView通過約束自動計算高度，但是因為iOS對于約束的算法問題，會導(dǎo)致流暢性降低，FDTemplateLayoutCell很好的優(yōu)化了這個問題。
3、異步繪制
Facebook的開源項目Texture（原AsyncDisplayKit），通過利用ASDisplayNode封裝了CALayer，實現(xiàn)了異步繪制。
第三方微博客戶端墨客的是現(xiàn)實，當(dāng)滑動時，松開手指后，立刻計算出滑動停止時 Cell 的位置，并預(yù)先繪制那個位置附近的幾個 Cell，而忽略當(dāng)前滑動中的 Cell。但也有缺點，快速滑動的時候有可能會出現(xiàn)大量空白。
3、高效圖片加載
4、預(yù)加載
列表當(dāng)中，當(dāng)滑動到一個可以設(shè)定的位置的時候，提前獲取下載下一頁的數(shù)據(jù)，并繪制UI。詳見：https://zhuanlan.zhihu.com/p/23418800。
5、針對Blended Layers以及Misaligned Images
Blended Layers：
盡量少的使用具有透明色的圖片
盡量多的將UI部件增加背景色
減少同一像素點進(jìn)行過多的顏色計算
Misaligned Images：
現(xiàn)象：
洋紅色：UIView的frame像素不對齊，即不能換算成整數(shù)像素值。
黃色：UIImageView的圖片像素大小與其frame.size不對齊，圖片發(fā)生了縮放造成。
解決：
盡量使用ceil()，保證沒有小數(shù)的UI繪制
盡量不實用0.01f標(biāo)記UITableView或者UICollectionView的header以及footer
網(wǎng)絡(luò)上獲取的圖片沒有@2x和@3x的區(qū)別，需要我們縮放圖片到與UIImageView對應(yīng)的尺寸，且縮放后的圖片的scale和[UIScreen mainScreen].scale相等，再顯示出來。
其他：
下面的情況或操作會引發(fā)離屏渲染：
為圖層設(shè)置遮罩（layer.mask）
將圖層的layer.masksToBounds / view.clipsToBounds屬性設(shè)置為true
將圖層layer.allowsGroupOpacity屬性設(shè)置為YES和layer.opacity小于1.0
為圖層設(shè)置陰影（layer.shadow *）。
為圖層設(shè)置layer.shouldRasterize=true
具有l(wèi)ayer.cornerRadius，layer.edgeAntialiasingMask，layer.allowsEdgeAntialiasing的圖層
文本（任何種類，包括UILabel，CATextLayer，Core Text等）。
使用CGContext在drawRect :方法中繪制大部分情況下會導(dǎo)致離屏渲染，甚至僅僅是一個空的實現(xiàn)。
開工
我們綜合分析了下現(xiàn)有首頁代碼的代碼結(jié)構(gòu)，發(fā)現(xiàn)主要存在問題如下
較多的使用約束進(jìn)行布局
每次Cell滑動進(jìn)入屏幕都需要根據(jù)DataSource計算一次Cell高度，浪費時間。
像素混合等問題嚴(yán)重。
存在離屏渲染。
無預(yù)加載邏輯，導(dǎo)致滑動流暢性降低。
于是我們做了以下措施：
使用frame布局來替換約束布局。
每次拉取到數(shù)據(jù)之后，異步計算Cell高度并做為單獨字段緩存在DataSource中。
按照代碼規(guī)范，規(guī)避像素混合問題和離屏渲染。
在相應(yīng)位置增加了預(yù)先拉取數(shù)據(jù)的邏輯，實現(xiàn)效果是用戶沒有將UI滑動到最后一條的時候，數(shù)據(jù)以及完成了拉取并刷新UI的邏輯。
總結(jié)
性能優(yōu)化這個東西其實很難形成一個具體的方案，為什么這么說？因為之所以稱之為優(yōu)化，是因為要在原有的代碼基礎(chǔ)上進(jìn)行優(yōu)化，原有的代碼又有各式各樣的原因?qū)е滦枰勒宅F(xiàn)有代碼來優(yōu)化，而很難完全脫離現(xiàn)有的情況完全參照某一種的既定方案進(jìn)行優(yōu)化。假如說是完全參照某一種的方案優(yōu)化的話，建議還是將某一個性能敏感的頁面利用Texture進(jìn)行完全重寫，這樣才能算是整體化一的利用了某一種方案。
