前言

? ? ? 現(xiàn)在App的頁(yè)面越來(lái)越復(fù)雜，頁(yè)面初始化的工作越來(lái)越多，加載頁(yè)面所需的時(shí)間也隨之增長(zhǎng)燃少，如果頁(yè)面加載的時(shí)間過(guò)長(zhǎng)，這將會(huì)影響App的流暢度及用戶體驗(yàn)铃在，我們需要解決這一問(wèn)題阵具。觀察過(guò)一些日常使用的App，頁(yè)面間跳轉(zhuǎn)的性能問(wèn)題總結(jié)為以下三種情形：

? ? ? 1).A頁(yè)面跳轉(zhuǎn)到B頁(yè)面定铜，由于B頁(yè)面需要加載大量的數(shù)據(jù)阳液，所以導(dǎo)致頁(yè)面跳轉(zhuǎn)延遲。

? ? ? 2).A頁(yè)面跳轉(zhuǎn)到B頁(yè)面揣炕，由于B頁(yè)面需要加載大量UI元素帘皿，所以導(dǎo)致頁(yè)面跳轉(zhuǎn)延遲。

? ? ? 3).A頁(yè)面跳轉(zhuǎn)到B頁(yè)面畸陡，由于A或B頁(yè)面的GPU使用率過(guò)高鹰溜，所以導(dǎo)致面頁(yè)跳轉(zhuǎn)時(shí)出現(xiàn)過(guò)場(chǎng)動(dòng)畫不流暢，緩慢等丁恭。

? ? ? 情形一比較容易解決曹动，利用輔助線程加數(shù)據(jù)即可；由于圖層樹的更新(即UI頁(yè)面的更新)需要在主線程上完成牲览，所以情形二的性能優(yōu)化讓很多開發(fā)人員頭痛墓陈；雖然網(wǎng)上有很多視圖性能優(yōu)化的技術(shù)文，但據(jù)了解竭恬，其實(shí)大部份團(tuán)隊(duì)都不會(huì)去做視圖的性能優(yōu)化跛蛋，情形三也是最普遍存在。本文將會(huì)講述這三種情形的性能優(yōu)化痊硕，但并不會(huì)講述頁(yè)面間跳轉(zhuǎn)的過(guò)渡動(dòng)畫赊级，及頁(yè)面間跳轉(zhuǎn)的原理，這部份在網(wǎng)上已經(jīng)有大量技術(shù)文講述岔绸。關(guān)于情形三所涉及的像素混合理逊，像素對(duì)齊，離屏渲染等知識(shí)點(diǎn)將不進(jìn)行講述盒揉，本文會(huì)講述一種偷懶的方式來(lái)優(yōu)化情形三晋被。

? ? ? 點(diǎn)擊下載Demo，或https://github.com/IOSDelpan/SmoothTransitionDemo刚盈。

目錄

基礎(chǔ)知識(shí)

?-渲染服務(wù)進(jìn)程

?-UIView與CALayer

?-圖層樹羡洛，呈現(xiàn)樹，渲染樹

?-UI更新過(guò)程

?-RunLoop更新UI的工作

情形一

情形二

續(xù)言

情形三

總結(jié)

下期預(yù)告

基礎(chǔ)知識(shí)

? ? ? 想在屏幕上顯示一個(gè)視圖藕漱，我們只需要簡(jiǎn)單地實(shí)現(xiàn)以下代碼欲侮，并運(yùn)行Application到模擬器或真機(jī)即可崭闲。

-渲染服務(wù)進(jìn)程

? ? ? 雖然看到的效果跟Application的代碼是一一對(duì)應(yīng)的，但視圖繪制渲染的工作并不是由Application完成的威蕉，而是由一個(gè)名為渲染服務(wù)的進(jìn)程(BackBoard)來(lái)完成的刁俭，這個(gè)進(jìn)程的工作便是你在屏幕上看到的一切內(nèi)容。既然做實(shí)際繪制渲染工作的是渲染服務(wù)進(jìn)程韧涨，那么渲染服務(wù)進(jìn)程要進(jìn)行繪制渲染的依據(jù)是什么呢牍戚？而Application跟渲染服務(wù)進(jìn)程又是怎么交互的呢？

-UIView與CALayer

? ? ? 為了方便往后的講述虑粥，首先簡(jiǎn)單講述一下UIView與CALayer的關(guān)系(不講述兩者的區(qū)別)如孝。簡(jiǎn)單來(lái)說(shuō)，UIView就是CALayer的管理器舀奶，CALayer的主要工作是為屏幕的繪制渲染提供所需的數(shù)據(jù)源暑竟，也就是說(shuō)，你在屏幕上看到的內(nèi)容育勺，都是來(lái)源于CALayer。每一個(gè)UIView都有一個(gè)Backing Layer罗岖，UIView的UI屬性跟CALayer的屬性是一一對(duì)應(yīng)的涧至，設(shè)置UIView的UI屬性實(shí)際上是設(shè)置CALayer對(duì)應(yīng)的屬性，即UIView的繪制渲染工作是由CALayer完成桑包。UIView對(duì)象之間存在著一定的層級(jí)關(guān)系南蓬，那么所以UIView的Backing Layer也相應(yīng)的存在著一定的層級(jí)關(guān)系，這個(gè)層級(jí)關(guān)系叫做圖層樹(模型樹)哑了。接下來(lái)的知識(shí)點(diǎn)直接用圖層來(lái)講述赘方。

-圖層樹，呈現(xiàn)樹弱左，渲染樹

? ? ? 使用Core Animation的Application(iOS默認(rèn)使用)窄陡，除了圖層樹，還有呈現(xiàn)樹和渲染樹拆火，每個(gè)圖層對(duì)象集合都扮演著不同的角色跳夭。圖層樹中的圖層對(duì)象負(fù)責(zé)存儲(chǔ)在屏幕上顯示的目標(biāo)值，呈現(xiàn)樹中的圖層對(duì)象負(fù)責(zé)存儲(chǔ)在屏幕上顯示的瞬時(shí)值们镜，而渲染樹的圖層對(duì)象是渲染服務(wù)進(jìn)程用來(lái)繪制渲染所使用的币叹。Application使用到的是圖層樹與呈現(xiàn)樹，上圖中的代碼模狭，使用的則是圖層樹中的圖層對(duì)象颈抚。既然渲染服務(wù)進(jìn)程使用的是渲染樹，那么圖層樹中的圖層對(duì)象所存儲(chǔ)的目標(biāo)值又是如何顯示在屏幕上呢嚼鹉？

-UI更新過(guò)程

? ? ? 在Application的主線程中設(shè)置圖層樹中的圖層對(duì)象時(shí)贩汉，被設(shè)置的圖層對(duì)象會(huì)被標(biāo)記為待處理狀態(tài)(在輔助線程設(shè)置圖層對(duì)象驱富，圖層對(duì)象不會(huì)被標(biāo)記)，當(dāng)Application的主線程即將處理非端口輸入源或即將進(jìn)入休眠時(shí)雾鬼，Core Animation會(huì)打包圖層樹中待處理的圖層對(duì)象萌朱，并通過(guò)IPC發(fā)送到渲染服務(wù)進(jìn)程，IPC是通過(guò)端口交互的策菜，消息在兩個(gè)端口間傳遞晶疼，而渲染服務(wù)進(jìn)程的端口是不公開的，當(dāng)打包的圖層發(fā)送到渲染服務(wù)進(jìn)程時(shí)又憨，這些圖層會(huì)被反序列化成渲染樹翠霍，渲染服務(wù)進(jìn)程便可以開始繪制渲染的工作。

-RunLoop更新UI的工作

? ? ? Application的主線程為了保持存活狀態(tài)蠢莺，啟動(dòng)了運(yùn)行循環(huán)(RunLoop)寒匙，RunLoop是一個(gè)事件處理循環(huán)，使用RunLoop的目的是讓你的線程在有工作的時(shí)候忙于工作躏将，而沒工作的時(shí)候處于休眠狀態(tài)锄弱。下圖為RunLoop調(diào)度的順序。

? ? ? 從RunLoop調(diào)度的順序得知祸憋，當(dāng)沒有未處理事件時(shí)会宪，線程就會(huì)進(jìn)入休眠狀態(tài)。在RunLoop中注冊(cè)了一個(gè)觀察者蚯窥，這個(gè)觀察者用于監(jiān)聽線程即將處理非端口輸入源或即將進(jìn)入休眠的狀態(tài)掸鹅，當(dāng)線程即將處理非端口輸入源或即將進(jìn)入休眠時(shí)，觀察者會(huì)執(zhí)行監(jiān)聽回調(diào)_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()拦赠，這個(gè)函數(shù)實(shí)現(xiàn)了Core Animation打包圖層樹中待處理的圖層對(duì)象巍沙，并通過(guò)IPC發(fā)送到渲染服務(wù)進(jìn)程的工作。

情形一

? ? ? 絕大多數(shù)的App頁(yè)面都是用來(lái)展示各式各樣的數(shù)據(jù)荷鼠，如果跳轉(zhuǎn)頁(yè)面的同時(shí)句携，在主線程加載大量的數(shù)據(jù)，便會(huì)出現(xiàn)以下情況颊咬。

? ? ? 如Ｇif圖所示务甥，屏幕卡頓了一會(huì)才出現(xiàn)頁(yè)面跳轉(zhuǎn)的過(guò)場(chǎng)動(dòng)畫，即出現(xiàn)了頁(yè)面跳轉(zhuǎn)延遲的情況喳篇。從基礎(chǔ)知識(shí)的UI更新過(guò)程敞临，RunLoop更新UI的工作中得知，Application的UI更新在于主線程RunLoop觀察者的回調(diào)函數(shù)_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()麸澜，只要該函數(shù)執(zhí)行完挺尿，我們就可以在屏幕上看到UI更新的結(jié)果。既然知道這是由于在主線程加載大量數(shù)據(jù)所致，那么我們來(lái)解決這一情形编矾，首先需要知道是那個(gè)函數(shù)占用了CPU熟史，使用Instruments的Time Profiler測(cè)試一下。

? ? ? 從測(cè)試的結(jié)果可以看到窄俏，是setUpData這個(gè)方法占用了主線程蹂匹，而setUpData方法是在viewDidLoad里被調(diào)用的，那么viewDidLoad又是在何時(shí)被調(diào)用的呢凹蜈？

? ? ? 從主線程活動(dòng)的狀態(tài)以及執(zhí)行堆椣弈可以看出，viewDidLoad是在_ZN2CA11Transaction17observer_callbackEP19__CFRunLoopObservermPv()里被調(diào)用的仰坦，大致過(guò)程如下圖履植。

? ? ? 知道了問(wèn)題函數(shù)和主線程的執(zhí)行堆棧，那么解決這一問(wèn)題就變得很簡(jiǎn)單悄晃。只需要把加載數(shù)據(jù)的setUpData方法放到輔助線程中執(zhí)行并返回結(jié)果到主線程顯示即可玫霎。

? ? ? 當(dāng)我們使用多線程去加載數(shù)據(jù)時(shí)，由于主線程沒有被阻塞妈橄，所以沒有出現(xiàn)頁(yè)面跳轉(zhuǎn)延遲的情況庶近，具體代碼請(qǐng)看Demo。

情形二

? ? ? 在頁(yè)面跳轉(zhuǎn)時(shí)眷蚓，除了加載數(shù)據(jù)拦盹，還需要加載UI元素，而加載UI元素的工作一般會(huì)在viewDidLoad中完成溪椎，如果需要加載的UI元素過(guò)多，同樣會(huì)出現(xiàn)頁(yè)面跳轉(zhuǎn)延遲的情況恬口。

? ? ? 如Gif圖所示校读，出現(xiàn)了頁(yè)面跳轉(zhuǎn)延遲的情況，這是由于在viewDidLoad中生成大量的UI元素所致祖能。在情形一中歉秫，我們用輔助線程加載數(shù)據(jù)解決了頁(yè)面跳轉(zhuǎn)延遲的情況，那么我們可以以同樣的方式來(lái)加載UI元素养铸。

? ? ? 雖然我們可以把生成UI元素的工作放到輔助線程中完成雁芙，且看到的效果相同，但這種處理方式的效率非常低钞螟，這種方式生成大量UI元素所需要的時(shí)間比直接在主線程中生成要多數(shù)倍兔甘，增加加載頁(yè)面所需要的時(shí)間，這顯然不是我們想要的結(jié)果鳞滨，我們想要的是既可以在主線程生成UI洞焙，又可以不出現(xiàn)頁(yè)面跳轉(zhuǎn)延遲的情況。

? ? ? 我們知道當(dāng)Application的主線程即將處理非端口輸入源或即將進(jìn)入休眠時(shí)，Core Animation會(huì)打包圖層樹中待處理的圖層對(duì)象澡匪，除了打包圖層對(duì)象熔任，Core Animation還會(huì)打包基礎(chǔ)動(dòng)畫對(duì)象，一并發(fā)送到渲染服務(wù)進(jìn)程唁情，渲染服務(wù)進(jìn)程接收到圖層對(duì)象和動(dòng)畫對(duì)象后疑苔，會(huì)根據(jù)動(dòng)畫對(duì)象來(lái)不斷計(jì)算和繪制圖層對(duì)象，形成屏幕上看到的動(dòng)畫效果甸鸟，所以動(dòng)畫對(duì)象能否及時(shí)發(fā)送到渲染服務(wù)進(jìn)程就顯得非常重要惦费，這關(guān)系到你App的用戶體驗(yàn)。頁(yè)面跳轉(zhuǎn)時(shí)的過(guò)場(chǎng)動(dòng)畫的打包工作哀墓，跟viewDidLoad是在同一次RunLoop中趁餐，所以viewDidLoad的執(zhí)行時(shí)間就顯得很關(guān)鍵。除了viewDidLoad以外篮绰，在UIViewController的生命周期里還有另外幾個(gè)方法后雷，我們來(lái)看一下這幾個(gè)方法的被調(diào)度的情況。

? ? ? 從打印信息中得知吠各，viewWillAppear臀突，viewWillLayoutSubviews，viewDidLayoutSubviews是緊跟viewDidLoad之后執(zhí)行的贾漏，所以這幾個(gè)方法的執(zhí)行時(shí)間同樣很重要候学，但我們發(fā)現(xiàn)viewDidAppear方法并沒有被調(diào)度，即viewDidAppear跟前面幾個(gè)方法并在不同一次RunLoop中纵散，既然如此梳码，我們可以便使用viewDidAppear來(lái)解決頁(yè)面跳轉(zhuǎn)延遲的情況。

? ? ? Gif圖顯示的效果和根據(jù)基礎(chǔ)知識(shí)猜想的結(jié)果一樣伍掀，解決了頁(yè)面跳轉(zhuǎn)延遲的情況掰茶，那么viewDidAppear何時(shí)被調(diào)用？

? ? ? 從主線程的執(zhí)行堆椕垠裕可得知濒蒋，viewDidAppear是在過(guò)場(chǎng)動(dòng)畫結(jié)束后被調(diào)用的，而過(guò)場(chǎng)動(dòng)畫的持續(xù)時(shí)間是0.35秒把兔。

? ? ? 我們來(lái)算一下整個(gè)過(guò)程所需要的時(shí)間沪伙，假設(shè)生成頁(yè)面需要0.5秒，那么優(yōu)化前后所需要的時(shí)間都是0.85秒(經(jīng)測(cè)試县好，其實(shí)時(shí)間有減少围橡，只是少到可以忽略，時(shí)間減少的部份應(yīng)該是GPU計(jì)算量的問(wèn)題)聘惦，雖然問(wèn)題解決了某饰，但效果并不理想儒恋，因?yàn)橥瓿烧麄€(gè)過(guò)程所需要的時(shí)間并沒有減少，所以我們需要進(jìn)一步優(yōu)化黔漂。嘗試過(guò)很多種方式诫尽，但似乎沒有什么方式可以很好地減少生成UI元素所需要的時(shí)間，那么我們只能把優(yōu)化的方向放在過(guò)場(chǎng)動(dòng)畫的持續(xù)時(shí)間上了炬守。

? ? ? 從Gif圖顯示的效果可以看到牧嫉，完成整個(gè)過(guò)程所需要的時(shí)間明顯減少了，實(shí)現(xiàn)原理請(qǐng)看下圖减途。

? ? ? 如圖所示酣藻，把生成UI元素的任務(wù)從本次RunLoop中抽出，提交到下一次的RunLoop當(dāng)中鳍置，因?yàn)楸敬蜶unLoop沒有被阻塞辽剧，所以能及時(shí)把圖層對(duì)象和動(dòng)畫對(duì)象發(fā)送到渲染服務(wù)進(jìn)程，渲染服務(wù)進(jìn)程便開始進(jìn)行過(guò)場(chǎng)動(dòng)畫的繪制與渲染税产，與此同時(shí)怕轿，Application的主線程RunLoop進(jìn)入下一次Loop，開始執(zhí)行生成UI元素的任務(wù)辟拷，即撞羽，可以理解為渲染服務(wù)進(jìn)程繪制渲染過(guò)場(chǎng)動(dòng)畫，和Application生成UI元素的任務(wù)同時(shí)進(jìn)行衫冻，這樣我們便把動(dòng)畫的時(shí)間也利用上诀紊，從而大大減小了整個(gè)過(guò)程所需的時(shí)間。

? ? ? 在Demo中隅俘，是使用GCD的方式來(lái)實(shí)現(xiàn)邻奠，也可以使用performSelector: withObject: afterDelay:方法來(lái)實(shí)現(xiàn)同樣的效果，但不建議为居，因?yàn)檫@樣會(huì)增加主線程RunLoop的執(zhí)行時(shí)間惕澎。

? ? ? 我們還可以把這個(gè)耗時(shí)的任務(wù)分解成若干個(gè)小的任務(wù)來(lái)實(shí)現(xiàn)。

? ? ? 如Gif圖所示颜骤，沒有出現(xiàn)頁(yè)面跳轉(zhuǎn)延遲的情況。使用定器時(shí)把任務(wù)分解捣卤，可以得到同樣的結(jié)果忍抽，若是加上一些動(dòng)畫，效果會(huì)更棒董朝。在Demo中鸠项，用到的定時(shí)器是CADisplayLink，用NSTimer可以達(dá)得到樣的效果子姜，關(guān)于CADisplayLink祟绊，建議能不用就不用，因?yàn)樗鼤?huì)使目標(biāo)線程長(zhǎng)期處于活躍狀態(tài)。

? ? ? 情形三將會(huì)在頁(yè)面間跳轉(zhuǎn)的性能優(yōu)化(二)中講述牧抽。如果文中有講錯(cuò)的地方嘉熊，還望指出。

? ? ? Tips：雖然黑科技很強(qiáng)大扬舒，但也很危險(xiǎn)阐肤，在你沒有足夠了解它的情況下，不能輕易去使用讲坎，更不能濫用孕惜。本文的講述旨在如何利用基礎(chǔ)知識(shí)來(lái)解決日常開發(fā)中遇到的問(wèn)題，并不是硬式化地講解使用方式晨炕。