這篇文章主要為大家展示了“iOS如何優(yōu)化性能”，內(nèi)容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領(lǐng)大家一起研究并學習一下“iOS如何優(yōu)化性能”這篇文章吧。

屏幕顯示的原理

屏幕顯示原理

我們知道，遠古時代的CRT顯示器的顯示原理是用電子槍掃描熒光屏來發(fā)光。如上圖所示，電子槍按照從左到右，然后從上到下的順序掃描。當電子槍換到新的一行準備進行掃描時，也就是上圖A4、B4、C4、D4的位置，顯示器會發(fā)出一個水平同步信號；而當一幀畫面繪制完成后，電子槍回復(fù)到原位準備畫下一幀前，也就是上圖D4的位置，顯示器會發(fā)出一個垂直同步信號。垂直同步信號的作用一方面是通知顯示器回到A1位置，另外一方面，也通知顯卡，準備輸出下一幀畫面?，F(xiàn)在已經(jīng)是液晶顯示器的時代了，不再使用電子槍掃描了，但是原理還是類似的，水平同步信號和垂直同步信號還是一樣被使用的。

計算機工作原理

計算機系統(tǒng)的工作原理如上圖所示：首先是CPU的工作，包括創(chuàng)建視圖分配內(nèi)存、計算布局、圖片解碼以及文本繪制等；接下來輪到GPU工作了，GPU負責視圖變換、合成和渲染等；GPU渲染完提交到幀緩沖區(qū)中，等收到垂直同步信號后將幀緩沖區(qū)的內(nèi)容顯示到屏幕上。

屏幕撕裂(Screen tearing)

上述的簡單的屏幕顯示原理其實會產(chǎn)生這樣一個問題：假設(shè)我們的顯卡速度很快，每秒生產(chǎn)的幀數(shù)肯定要超過顯示器刷新率。那么在實際數(shù)據(jù)處理過程中，緩沖區(qū)的數(shù)據(jù)，在被輸出之前，就被顯卡不斷的刷新重寫。但是緩沖區(qū)并不是“先清空再寫入數(shù)據(jù)”，這太沒有效率，而是采用“新數(shù)據(jù)覆蓋老數(shù)據(jù)”的方式。

假設(shè)這樣一種情況，緩沖區(qū)已經(jīng)有一副完整的幀畫面(A幀)，然后顯卡生成了下一幀畫面(B幀)，新一幀的數(shù)據(jù)開始寫入緩沖區(qū)，寫到一半的時候，垂直同步信號來 了，于是緩沖區(qū)的數(shù)據(jù)被輸出到顯示器。但問題是，這時緩沖區(qū)的數(shù)據(jù)，是由一半A幀和一半B幀數(shù)據(jù)合成的。因此最終顯示器上顯示出來的畫面就不是一副完整的 畫面，這就是“畫面撕裂”現(xiàn)象出現(xiàn)的原因(如下圖)。

屏幕撕裂

那怎么才能解決畫面撕裂呢？簡單來說只要讓幀緩沖區(qū)里的數(shù)據(jù)始終保持一副完整的畫面就可以了。從技術(shù)角度出發(fā)，其實就是利用剛剛提到的垂直同步信號。

具體說起來就是，當顯卡生成了一副完整畫面并寫入了幀緩沖區(qū)之后，暫停！然后開始等待垂直同步信號，當?shù)玫酱怪蓖叫盘柡螅倮^續(xù)渲染下一幀寫入緩沖區(qū)。這樣就可以保證在緩沖區(qū)的數(shù)據(jù)始終是一副完整的畫面，不會出現(xiàn)前后幀混合的問題。

卡頓產(chǎn)生原因

但是呢，垂直同步帶來了一個新的問題—掉幀。所謂的掉幀，跟垂直同步有一定關(guān)系，因為垂直同步機制決定了如果在一個時鐘周期內(nèi)CPU或者GPU沒有完成各自的任務(wù)的話，就會將幀緩沖區(qū)里的內(nèi)容直接丟棄！掉幀并不能完全怪罪于垂直同步機制，更重要的原因是我們作為開發(fā)者沒有進行足夠的優(yōu)化，將過重的任務(wù)派發(fā)到了CPU或者GPU上，下圖(from：iOS 保持界面流暢的技巧)是掉幀的圖示，表明CPU或者GPU任意一個沒能在時鐘周期內(nèi)完成自己的任務(wù)的話都會導致卡頓掉幀。

卡頓圖示

行之有效的優(yōu)化點

提前布局

提前布局可以說是最重要的優(yōu)化點了。其實在從服務(wù)端拿到 JSON 數(shù)據(jù)的時候，關(guān)于視圖的布局就已經(jīng)確定了，包括每個控件的frame、cell的高度以及文本排版結(jié)果等等，在這個時候完全可以在后臺線程計算并封裝為對應(yīng)的布局對象XXXTableViewCellLayout，每個cellLayout的內(nèi)存占用并不是很多，所以直接全部緩存到內(nèi)存中。當列表滾動到某個cell的時候，直接拿到對應(yīng)的cellLayout配置這個cell的對應(yīng)屬性即可。當然，該有的計算是免不了的，只是提前算好并緩存，免去了在滾動的時候計算和重復(fù)的計算。通過這一個優(yōu)化，將本來的fps50的列表優(yōu)化到了55、56左右，可以說從肉眼上已經(jīng)看不出有卡頓掉幀了。

cellLayout示例圖

上圖是項目中某個cellLayout的部分代碼，可以看到里面存的就是所有控件的frame和文本的排版結(jié)果而已，里面沒有任何的黑科技，只是將本來在滾動中才做的事情提前了而已。

按頁加載緩存

現(xiàn)狀分析：90%的APP有tableview，90%的tableview里有上拉刷新和下拉加載。以我司的項目ZAKER中的熱點新聞界面為例，簡單流程大概是這樣的：①應(yīng)用啟動的時候會將磁盤中所有的新聞一次性讀取出來顯示到屏幕上； ②在每次下拉刷新和上拉加載的時候會將內(nèi)存中所有新聞緩存到磁盤中，也即全量讀寫。這意味著大部分的新聞數(shù)據(jù)會反復(fù)寫入到磁盤中，這樣的寫入是冗余的，因為前面的這些新聞數(shù)據(jù)并沒有發(fā)生改變。

改進方案：所以優(yōu)化的方法就是將這些列表數(shù)組進行分割，分割成一頁一頁，每次寫入的數(shù)據(jù)量很小，而且避免了冗余寫入的問題?，F(xiàn)在的流程變?yōu)椋孩賳訒r只讀取第一批新聞顯示在屏幕中；②下拉刷新和上拉加載的時候只把當前服務(wù)器返回的一批新聞寫入緩存中；③在上拉加載的時候會先查看磁盤中是否有未讀的緩存，若有則讀取緩存，否則才從服務(wù)器下載一批新的文章。

直觀圖示：

按頁緩存

可以看到，優(yōu)化之前整個新聞列表以及其他配置都在一個文件里，刷新10幾次之后文件大小達到2MB，并且隨著不斷刷新而越來越大；優(yōu)化之后，其他的配置還是在剛剛的文件中，但是不斷增長的新聞數(shù)組被分割成一頁一頁的文件，每一頁里面有10多條的新聞數(shù)據(jù)，同時有一個configure文件保存這些頁的信息以及頁的順序。根據(jù)測試人員的反饋，進行按頁加載緩存優(yōu)化能減少5%~8%的CPU占用，使用的內(nèi)存也有一定的下降。還是有很明顯的優(yōu)化效果的。

后臺線程處理圖片

圓形頭像、圖片裁圓角等處理可以說是非常常見的需求了，包括從iOS11的系統(tǒng)各處都能看到，整體的頁面控件都變得更加圓潤了。但是，對圖片處理必然是消耗資源的，實現(xiàn)過圖片圓角效果的應(yīng)該都知道，最簡單的就是 layer.cornerRadius+layer.masksToBounds 的方式，但是這種做法在tableview中往往會使?jié)L動變得卡頓，因為這種實現(xiàn)方式會觸發(fā)離屏渲染，屏幕外緩沖區(qū)跟當前屏幕緩沖區(qū)上下文切換是很耗性能的，所以離屏渲染往往會造成卡頓(參考：iOS 離屏渲染的研究)。

那要怎么處理圖片呢？可以使用Core Graphics，Core Graphic通常是線程安全的，所以可以進行異步繪制，顯示的時候再放回主線程。我們在項目中實現(xiàn)了一個后臺處理圖片的框架，核心代碼如下：

NSBlockOperation *transformOperation = [[NSBlockOperation alloc] init];
    [transformOperation addExecutionBlock:^{    
      // 此處處理圖片
      ...
      dispatch_async(dispatch_get_main_queue(), ^{
          // 主線程設(shè)置圖片
          [self setImage:transformedImage forState:UIControlStateNormal];
        }
      });
    }];

更加高效的控件

還可以直接從開源庫中選用更加高效的控件替換項目中性能沒那么好的控件。項目中將之前的TTTAttributedLabel、M80AttributedLabel全部替換為YYLabel，開啟YYLabel的displaysAsynchronously、ignoreCommonProperties屬性可以異步繪制文本以及忽略不需要的屬性。更加追求性能的話，可以結(jié)合第1點的提前布局機制，在提前布局的階段生成好YYLabel渲染時用到的textLayout，顯示的時候直接賦值textLayout就可以了。

其他

還有一些比較微小的優(yōu)化，對性能可以說沒有多大的影響，但是可以在開發(fā)階段稍加留意，養(yǎng)成良好的習慣。

盡量減少視圖層級，合并多余的視圖。同樣以ZAKER為例，用戶顯示時的藍V標簽、達人標簽以及樓主圖片等幾個視圖，之前是用不同的view來展示的，優(yōu)化過程將這幾個view合并為一個view，一個view管理這些相似的事物，也可以減少某些相同邏輯的代碼。

減少頻繁的addSubview、removeSubview，remove之后視圖的實例對象會被釋放，再add的時候會再次調(diào)用初始化函數(shù)。替代方案的話，可以用hidden屬性隱藏不顯示的視圖。

異步繪制

從一開始接觸iOS的我們就反復(fù)被告知，UIKit的東西是絕對不能在后臺線程調(diào)用的，一定得在主線程調(diào)用，所以主線程也被叫做UI線程。在后臺線程調(diào)用UIKit的東西有一定幾率導致崩潰，或者出現(xiàn)視圖不顯示、顯示錯亂等等問題。但是呢，根據(jù)剛剛所說的，Core Graphics的那一套東西是線程安全的，所以可以通過Core Graphics在后臺將視圖渲染到一張圖片上，顯示的時候在主線程將這張圖片設(shè)置到相應(yīng)位置上。Facebook著名的AsyncDisplayKit的核心實現(xiàn)應(yīng)該也是基于這個原理，接下來的優(yōu)化可以嘗試這個方案。

Metal

根據(jù)Apple官方說法，Metal框架被設(shè)計用來實現(xiàn)兩個目標: 3D 圖形渲染和并行計算。這兩者有很多共同點。它們都在數(shù)量龐大的數(shù)據(jù)上并行運行特殊的代碼，并可以在GPU上執(zhí)行。目前正在研究學習階段，看項目中是否能利用Metal進行一定的優(yōu)化。

APM？

Application Performance Management(APM)：應(yīng)用程序性能管理， 通過對應(yīng)用的可靠性、穩(wěn)定性等方面的監(jiān)控，進而達到可以快速修復(fù)問題、提高用戶體驗的目的。目前比較有代表性的 APM 產(chǎn)品有：聽云、阿里百川、騰訊 bugly等，現(xiàn)在也在考慮自己研發(fā)一套APM系統(tǒng)，先從比較簡單的指標入手，先對卡頓和崩潰這兩個指標著手，做的順利的話再逐步擴展別的指標的檢測管理。

以上是“iOS如何優(yōu)化性能”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學習更多知識，歡迎關(guān)注創(chuàng)新互聯(lián)網(wǎng)站建設(shè)公司行業(yè)資訊頻道！

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)建站www.cdcxhl.com，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國服務(wù)器、虛擬主機、免備案服務(wù)器”等云主機租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務(wù)可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場景需求。