【移動(dòng)應(yīng)用開發(fā)技術(shù)】iOS性能優(yōu)化教程之頁面加載速率詳解

【移動(dòng)應(yīng)用開發(fā)技術(shù)】iOS性能優(yōu)化教程之頁面加載速率詳解

前言

我認(rèn)為在編碼過程中時(shí)刻注意性能影響是有必要的，但凡事都有個(gè)度，不能為了性能耽誤了開發(fā)進(jìn)度。在時(shí)間緊急的情況下我們往往采用“quickanddirty”的方案來快速出成果，后面再迭代優(yōu)化，即所謂的敏捷開發(fā)。與之相對(duì)應(yīng)的是傳統(tǒng)軟件開發(fā)中的瀑布流開發(fā)流程?？D產(chǎn)生的原因

在iOS系統(tǒng)中，圖像內(nèi)容展示到屏幕的過程需要CPU和GPU共同參與。CPU負(fù)責(zé)計(jì)算顯示內(nèi)容，比如視圖的創(chuàng)建、布局計(jì)算、圖片解碼、文本繪制等。隨后CPU會(huì)將計(jì)算好的內(nèi)容提交到GPU去，由GPU進(jìn)行變換、合成、渲染。之后GPU會(huì)把渲染結(jié)果提交到幀緩沖區(qū)去，等待下一次VSync信號(hào)到來時(shí)顯示到屏幕上。由于垂直同步的機(jī)制，如果在一個(gè)VSync時(shí)間內(nèi)，CPU或者GPU沒有完成內(nèi)容提交，則那一幀就會(huì)被丟棄，等待下一次機(jī)會(huì)再顯示，而這時(shí)顯示屏?xí)Ａ糁暗膬?nèi)容不變。這就是界面卡頓的原因。因此，我們需要平衡CPU和GPU的負(fù)荷避免一方超負(fù)荷運(yùn)算。為了做到這一點(diǎn)，我們首先得了解CPU和GPU各自負(fù)責(zé)哪些內(nèi)容。

上面的圖展示了iOS系統(tǒng)下各個(gè)模塊所處的位置，下面話不多說了，來一起看看本文的正文。之前搜羅了網(wǎng)上很多關(guān)于iOS性能優(yōu)化方面的資料，本人和我的小伙伴們也用了一些時(shí)間針對(duì)自己的App進(jìn)行了App的啟動(dòng)速率、頁面的加載速率和頁面的幀率方面進(jìn)行了優(yōu)化，所以結(jié)合了理論和實(shí)踐，把我們?cè)趯?shí)踐中主要踩過的坑和需要注意的東西，總結(jié)了一下，希望可以幫到正在準(zhǔn)備進(jìn)行App的性能優(yōu)化的你。今天主要講一下App的頁面加載速率的優(yōu)化。

##目的

為了找到真正使我們的App緩慢的原因，我們使用Xcode或者一些第三方平臺(tái)，進(jìn)行數(shù)據(jù)測(cè)試；

一、頁面加載速率的定義

頁面加載速率：關(guān)于頁面的加載速度的統(tǒng)計(jì)，我們是測(cè)試一個(gè)viewcontroller從viewdidload的第一行到viewdidappear的最后一行所用的時(shí)間。

二、頁面加載速率的目標(biāo)值

目標(biāo)：頁面加載速率最好完美的時(shí)間在0.3s左右

為了弄明白，到底是什么原因讓我們的App，頁面加載速度相對(duì)來說比較慢，我們對(duì)頁面的UI進(jìn)行優(yōu)化，數(shù)據(jù)也進(jìn)行了異步加載，我們hook數(shù)據(jù)一看，頁面的加載速度果然有所減少，但是減少的值大概只有0.03s,很明顯這個(gè)值不足以達(dá)到我們想要的效果，后來，通過寫了一些測(cè)試demo，針對(duì)空白頁面和有UI創(chuàng)建的頁面進(jìn)行各種對(duì)比后，似乎和我們頁面加載過程中的push動(dòng)畫有很大的關(guān)系；下面所做的實(shí)驗(yàn)主要是為了驗(yàn)證這個(gè)問題，針對(duì)這個(gè)問題，我選取了我們工程的一個(gè)類，對(duì)有push進(jìn)入到這個(gè)頁面有過場(chǎng)動(dòng)畫和沒有動(dòng)畫進(jìn)行測(cè)試，以下數(shù)據(jù)是測(cè)試結(jié)果：通過這個(gè)實(shí)驗(yàn)，我們可以看出，不加動(dòng)畫的話，我們的頁面加載的速度可以說是沒有任何的卡頓，超級(jí)迅速，但是如果把過場(chǎng)動(dòng)畫給打開，單是動(dòng)畫的時(shí)間就是在0.5s左右，而s我們是希望用戶在點(diǎn)擊跳轉(zhuǎn)頁面的時(shí)候，目標(biāo)是頁面在0.3s左右呈現(xiàn)，這如果加動(dòng)畫，這個(gè)目標(biāo)很難達(dá)到；不過通過查找相關(guān)資料，我們證實(shí)了我們可以把如果有過場(chǎng)動(dòng)畫的頁面，去掉動(dòng)畫，而是通過我們自己去給用戶添加一個(gè)過場(chǎng)動(dòng)畫，而這個(gè)時(shí)間是可以受到我們自己的控制，而不是傻傻的等動(dòng)畫結(jié)束后再加載頁面內(nèi)容。的這就是說，可以一邊動(dòng)畫的時(shí)候，一邊已經(jīng)開始加載頁面相關(guān)東西了，這樣可以大大的優(yōu)化頁面加載時(shí)間。

三、優(yōu)化前數(shù)據(jù)四、優(yōu)化后的數(shù)據(jù)到這里，你一定想問：我該如何hook數(shù)據(jù)的？？？

五、如何進(jìn)行數(shù)據(jù)的收集給UIViewController創(chuàng)建一個(gè)分類eg:UIViewController+Swizzle代碼如下

##如何進(jìn)行優(yōu)化方法：充分利用push動(dòng)畫的時(shí)間，使頁面在進(jìn)入的時(shí)候，同事進(jìn)行類似push動(dòng)畫，這樣可以充分減少頁面的加載速度（不包括網(wǎng)絡(luò)請(qǐng)求時(shí)間，網(wǎng)絡(luò)的請(qǐng)求的時(shí)間我們這邊不好控制）。具體實(shí)現(xiàn)代碼如下

重寫push方法

通過控制臺(tái)，我們就可以看到頁面的加載的速度了，主要的方法是swiz_viewDidLoad

和swiz_viewDidAppear六、優(yōu)化后的結(jié)果七、結(jié)果分析

我們可以看出，我們的頁面的viewDidAppear是在過場(chǎng)動(dòng)畫結(jié)束后被調(diào)用的，而過場(chǎng)動(dòng)畫的持續(xù)時(shí)間是0.5秒左右。所以我們的頁面平均在0.8秒左右的頁面，如果要優(yōu)化得更