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

創(chuàng)新互聯(lián)公司網(wǎng)站建設(shè)公司是一家服務(wù)多年做網(wǎng)站建設(shè)策劃設(shè)計(jì)制作的公司,為廣大用戶提供了做網(wǎng)站、成都做網(wǎng)站，成都網(wǎng)站設(shè)計(jì)，廣告投放，成都做網(wǎng)站選創(chuàng)新互聯(lián)公司，貼合企業(yè)需求，高性價(jià)比，滿足客戶不同層次的需求一站式服務(wù)歡迎致電。

屏幕顯示的原理

屏幕顯示原理

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

計(jì)算機(jī)工作原理

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

屏幕撕裂(Screen tearing)

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

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

屏幕撕裂

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

具體說(shuō)起來(lái)就是，當(dāng)顯卡生成了一副完整畫面并寫入了幀緩沖區(qū)之后，暫停！然后開(kāi)始等待垂直同步信號(hào)，當(dāng)?shù)玫酱怪蓖叫盘?hào)后，再繼續(xù)渲染下一幀寫入緩沖區(qū)。這樣就可以保證在緩沖區(qū)的數(shù)據(jù)始終是一副完整的畫面，不會(huì)出現(xiàn)前后幀混合的問(wèn)題。

卡頓產(chǎn)生原因

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

卡頓圖示

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

提前布局

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

cellLayout示例圖

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

按頁(yè)加載緩存

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

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

直觀圖示：

按頁(yè)緩存

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

后臺(tái)線程處理圖片

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

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

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

更加高效的控件

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

其他

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

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

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

異步繪制

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

Metal

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

APM？

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

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