說(shuō)起性能調(diào)優(yōu)宛乃，感覺枯燥的語(yǔ)言不能引起大家對(duì)于性能調(diào)優(yōu)的重視征炼，所以舉個(gè)不太恰當(dāng)?shù)睦印?br> 曾經(jīng)有這么一家工廠，他們的產(chǎn)品從原材料到出廠一共需要經(jīng)過(guò)30條產(chǎn)品線眼坏。這家公司的老板對(duì)底下的員工曾多次強(qiáng)調(diào)過(guò)質(zhì)量的重要性宰译，員工們卻不以為然魄懂，他們覺得自己做的都很不錯(cuò)市栗。
有一次，老板去視察蛛淋，走到了一條產(chǎn)品線上褐荷，問(wèn)起工人嘹悼，這條產(chǎn)品線的合格率能達(dá)到多少，那個(gè)工人自豪的說(shuō)合溺，“98%”棠赛。老板卻并沒(méi)有十分滿意膛腐，搖著頭走開了。那位工人非常的疑惑辩涝。這么高的合格率勘天，老板為什么還是不滿意呢捉邢？于是這位工人就去向領(lǐng)導(dǎo)打聽伏伐，領(lǐng)導(dǎo)也不知道藐翎，于是后來(lái)這位工人直接找到了老板家里实幕，向老板請(qǐng)教昆庇。
老板很是詫異，于是就給這位工人簡(jiǎn)單科普了一下未舟，一條產(chǎn)品線的合格率是98%掂为，并不代表最后總的合格率是98%勇哗。應(yīng)該是這樣計(jì)算最后的合格率的：x=0.980.980.98...=0.545
所以欲诺，這家公司的生產(chǎn)線的合格率實(shí)際上只有54.5%渺鹦。
這個(gè)故事說(shuō)明的問(wèn)題其實(shí)很簡(jiǎn)單，我們開發(fā)的app的最終性能塞颁，都是由每一個(gè)細(xì)小的部分組合而成的祠锣，其中很多部分的內(nèi)容是進(jìn)行的乘法咽安，而不是加減，所以想要自己設(shè)計(jì)的app讓用戶用的爽澡腾，任何一個(gè)小的性能問(wèn)題我們都不能忽略。那么毅糟，iOS性能測(cè)試是什么留特？

** iOS性能測(cè)試是：**
l 資源消耗
l 內(nèi)存泄漏
l 流量消耗
l 耗電功率
l 渲染效果
l 加載時(shí)間
l 玛瘸。。右核。

** 性能調(diào)優(yōu)的方式：**
l 通過(guò)專門的性能調(diào)優(yōu)工具instruments
l 通過(guò)優(yōu)化代碼

** instruments的三種打開方式：**
l Open Developer Tool->instruments
l 右鍵點(diǎn)擊Xcode->Open Developer Tool->instruments
l 工具通過(guò)Xcode工具欄中Product->Profile可以啟動(dòng)
（1） Open Developer Tool->instruments

（2）右鍵點(diǎn)擊Xcode->Open Developer Tool->instruments

圖2

           （3）工具通過(guò)Xcode工具欄中Product->Profile可以啟動(dòng)

圖3

啟動(dòng)后界面如下：

圖4

性能工具按需求分類如下：

圖5
下面根據(jù)需求分類詳細(xì)介紹instruments。

時(shí)間

我們就啟動(dòng)耗時(shí)來(lái)分析躏鱼。
l Time profiler
CPU Usage估量時(shí)間
Call Tree計(jì)算時(shí)間
l NSLog

1.1啟動(dòng)耗時(shí)--Time profiler
1.1.1根據(jù)CPU Usage估量時(shí)間
l Profiler你的app染苛，手動(dòng)測(cè)量主到，點(diǎn)擊Record開始運(yùn)行

1.1.2根據(jù)Call Tree 去計(jì)算時(shí)間
l instruments -> Time Profiler
l Profiler你的app
l 切換到CPU strategy view登钥，找到你的app的啟動(dòng)的第一幀
剛開始我們拿到分析數(shù)據(jù)時(shí)往往是這樣的：

這里顯示的是執(zhí)行代碼完整路徑牧牢，其中系統(tǒng)和應(yīng)用本身一些調(diào)用路徑完全揉捏在一起。完全看不到我們關(guān)心的應(yīng)用程序中實(shí)際代碼執(zhí)行耗時(shí)和代碼路徑實(shí)際所在位置度陆。
怎么辦献幔？我們可以看到右側(cè)有一個(gè)“齒輪形狀”的設(shè)置按鈕。

簡(jiǎn)單的方式可以快速勾選右邊Call Tree中Separate by Thread和Hide System Libraries兩個(gè)選項(xiàng)[后面會(huì)解釋選項(xiàng)作用]:

圖9-10

勾選Invert Call Tree:

圖11

勾選前后對(duì)比：

圖12

圖13
l 算出啟動(dòng)時(shí)間但校。

首次加載坐了如下操作：
A: 鏈接和載入：可以在Time Profile中顯示dyld載入庫(kù)函數(shù)状囱，庫(kù)會(huì)被映射到地址空間倘是，同時(shí)完成綁定以及靜態(tài)初始化。
B: UIKit初始化：如果應(yīng)用的Root View Controller是由XIB實(shí)現(xiàn)的奶栖，也會(huì)在啟動(dòng)時(shí)被初始化.
C: 應(yīng)用回調(diào)：調(diào)用UIApplicationDeleagte的回調(diào)：application:didFinishLaunchingWithOptions。
D: 第一次Core Animation調(diào)用：在啟動(dòng)后的方法-[UIApplication _resportAppLaunchFinished]中調(diào)用CA::Transaction::commit實(shí)現(xiàn)第一幀畫面的繪制袍镀。

應(yīng)用程序首次加載中啟動(dòng)方法willFinishLaunchingWithOptions和didFinishLaunchingWithOptions只做應(yīng)用程序首次啟動(dòng)必須的要操作,而針對(duì)_dyid_start在初始化庫(kù)framework函數(shù)的操作苇羡。不必要的Framework不要鏈接，避免首次加載耗時(shí)锦茁。

搜索-[UIApplication_reportAppLaunchFinished]的最后一幀叉存，即可算出啟動(dòng)時(shí)間。

圖14

Running Time列中顯示運(yùn)行每個(gè)方法所耗費(fèi)的時(shí)間稿存，根據(jù)耗時(shí)和占比猜測(cè)是否有代碼需要優(yōu)化。雙擊中間主窗口中的方法名進(jìn)入具體的代碼行查看率翅，耗時(shí)多的代碼行有顏色標(biāo)記袖迎，并顯示占比。

圖15

當(dāng)然對(duì)于開發(fā)而已辜贵，這種利用Time Profiler的方式計(jì)算啟動(dòng)耗時(shí)比較麻煩脯宿，他們更喜歡埋點(diǎn)。

1.2 啟動(dòng)耗時(shí)--NSLog
l 獲取某段代碼的執(zhí)行時(shí)間MKBlockTimer
l 利用類庫(kù)測(cè)試代碼的運(yùn)行時(shí)間MGBenchmark
評(píng)估總體運(yùn)行時(shí)間;
評(píng)估單步代碼的運(yùn)行時(shí)間;
找到所有代碼x最耗時(shí)的代碼;
找到代碼的平均運(yùn)行時(shí)間;
可以對(duì)不同的線程進(jìn)行評(píng)估（thread safe）
l 啟動(dòng)時(shí)間
看之前XXX的性能資料榴芳，是在AppDelegate里打點(diǎn)并不合理窟感。算出的只是main
調(diào)用AppDelegate文件的時(shí)間歉井。

所以是錯(cuò)誤的哩至。

業(yè)界對(duì)此的算法不同。貼吧是在內(nèi)存創(chuàng)建完成就算是啟動(dòng)成功卢佣，即：didLoad

個(gè)人覺得其實(shí)應(yīng)該是didAppear箭阶，即ui展示出來(lái)為準(zhǔn)。

埋點(diǎn)步驟：
在main.m中記當(dāng)前時(shí)間StartTime:

圖18

不能在ALATabBarController.h函數(shù)里面聲明嘹叫，會(huì)被多次調(diào)用罩扇，相當(dāng)于多次聲明全局變量怕磨；所以在ALATabBarController.m里面定義全局變量寞缝。

圖19

但是不可見荆陆，所以在ALATabBarController.h文件用extern集侯，將extern置于變量或者函數(shù)前棠枉，以表示變量或者函數(shù)的定義在別的文件中，即CFAbsoluteTime StartTime在ALATabBarController.m文件中聲明過(guò)命浴。

圖20

計(jì)算啟動(dòng)時(shí)間（didLoad）:

圖21

計(jì)算啟動(dòng)時(shí)間（didAppear）:

圖22

在log輸出窗口看準(zhǔn)確時(shí)間輸出：

圖23