在性能優(yōu)化中一個(gè)最具參考價(jià)值的屬性是FPS:Frames Per Second,其實(shí)就是屏幕刷新率，蘋果的iphone推薦的刷新率是60Hz，也就是說(shuō)GPU每秒鐘刷新屏幕60次，這每刷新一次就是一幀frame，F(xiàn)PS也就是每秒鐘刷新多少幀畫面。靜止不變的頁(yè)面FPS值是0，這個(gè)值是沒有參考意義的，只有當(dāng)頁(yè)面在執(zhí)行動(dòng)畫或者滑動(dòng)的時(shí)候，F(xiàn)PS值才具有參考價(jià)值，F(xiàn)PS值的大小體現(xiàn)了頁(yè)面的流暢程度高低，當(dāng)?shù)陀?5的時(shí)候卡頓會(huì)比較明顯。
圖層混合：
每一個(gè)layer是一個(gè)紋理，所有的紋理都以某種方式堆疊在彼此的頂部。對(duì)于屏幕上的每一個(gè)像素，GPU需要算出怎么混合這些紋理來(lái)得到像素RGB的值。
當(dāng)Sa = 0.5時(shí)，RGB值為(0.5, 0, 0)，可以看出，當(dāng)兩個(gè)不是完全不透明的CALayer覆蓋在一起時(shí),GPU大量做這種復(fù)合操作，隨著這中操作的越多，GPU越忙碌，性能肯定會(huì)受到影響。
公式：
R = S + D * ( 1 – Sa )
結(jié)果的顏色是源色彩(頂端紋理)+目標(biāo)顏色(低一層的紋理)*(1-源顏色的透明度)。
當(dāng)Sa = 1時(shí)，R = S,GPU將不會(huì)做任何合成，而是簡(jiǎn)單從這個(gè)層拷貝，不需要考慮它下方的任何東西(因?yàn)槎急凰趽踝×?，這節(jié)省了GPU相當(dāng)大的工作量。
一、入門級(jí)
1、用ARC管理內(nèi)存
2、在正確的地方使用 reuseIdentifier
3、盡量把views設(shè)置為透明
4、避免過于龐大的XIB
5、不要阻塞主線程
6、在ImageViews中調(diào)整圖片大小。如果要在UIImageView中顯示一個(gè)來(lái)自bundle的圖片，你應(yīng)保證圖片的大小和UIImageView的大小相同。在運(yùn)行中縮放圖片是很耗費(fèi)資源的，特別是UIImageView嵌套在UIScrollView中的情況下。如果圖片是從遠(yuǎn)端服務(wù)加載的你不能控制圖片大小，比如在下載前調(diào)整到合適大小的話，你可以在下載完成后，最好是用background thread，縮放一次，然后在UIImageView中使用縮放后的圖片。
7、選擇正確的Collection。
Arrays: 有序的一組值。使用index來(lái)lookup很快，使用value lookup很慢， 插入/刪除很慢。
Dictionaries: 存儲(chǔ)鍵值對(duì)。 用鍵來(lái)查找比較快。
Sets: 無(wú)序的一組值。用值來(lái)查找很快，插入/刪除很快。
8、打開gzip壓縮。
app可能大量依賴于服務(wù)器資源，問題是我們的目標(biāo)是移動(dòng)設(shè)備，因此你就不能指望網(wǎng)絡(luò)狀況有多好。減小文檔的一個(gè)方式就是在服務(wù)端和你的app中打開gzip。這對(duì)于文字這種能有更高壓縮率的數(shù)據(jù)來(lái)說(shuō)會(huì)有更顯著的效用。 iOS已經(jīng)在NSURLConnection中默認(rèn)支持了gzip壓縮，當(dāng)然AFNetworking這些基于它的框架亦然。
二、中級(jí)
1、重用和延遲加載(lazy load) Views。
更多的view意味著更多的渲染，也就是更多的CPU和內(nèi)存消耗，對(duì)于那種嵌套了很多view在UIScrollView里邊的app更是如此。
這里我們用到的技巧就是模仿UITableView和UICollectionView的操作: 不要一次創(chuàng)建所有的subview，而是當(dāng)需要時(shí)才創(chuàng)建，當(dāng)它們完成了使命，把他們放進(jìn)一個(gè)可重用的隊(duì)列中。這樣的話你就只需要在滾動(dòng)發(fā)生時(shí)創(chuàng)建你的views，避免了不劃算的內(nèi)存分配。
2、Cache, Cache, 還是Cache!
一個(gè)極好的原則就是，緩存所需要的，也就是那些不大可能改變但是需要經(jīng)常讀取的東西。
我們能緩存些什么呢？一些選項(xiàng)是，遠(yuǎn)端服務(wù)器的響應(yīng)，圖片，甚至計(jì)算結(jié)果，比如UITableView的行高。
NSCache和NSDictionary類似，不同的是系統(tǒng)回收內(nèi)存的時(shí)候它會(huì)自動(dòng)刪掉它的內(nèi)容。
3、權(quán)衡渲染方法.性能能還是要bundle保持合適的大小。
4、處理內(nèi)存警告.移除對(duì)緩存，圖片object和其他一些可以重創(chuàng)建的objects的strong references.
5、重用大開銷對(duì)象。
6、一些objects的初始化很慢，比如NSDateFormatter和NSCalendar。然而，你又不可避免地需要使用它們，比如從JSON或者XML中解析數(shù)據(jù)。想要避免使用這個(gè)對(duì)象的瓶頸你就需要重用他們，可以通過添加屬性到你的class里或者創(chuàng)建靜態(tài)變量來(lái)實(shí)現(xiàn)。
7、避免反復(fù)處理數(shù)據(jù).在服務(wù)器端和客戶端使用相同的數(shù)據(jù)結(jié)構(gòu)很重要。
8、選擇正確的數(shù)據(jù)格式。
解析JSON會(huì)比XML更快一些，JSON也通常更小更便于傳輸。從iOS5起有了官方內(nèi)建的JSON deserialization 就更加方便使用了。但是XML也有XML的好處，比如使用SAX 來(lái)解析XML就像解析本地文件一樣，你不需像解析json一樣等到整個(gè)文檔下載完成才開始解析。當(dāng)你處理很大的數(shù)據(jù)的時(shí)候就會(huì)極大地減低內(nèi)存消耗和增加性能。
9、正確設(shè)定背景圖片。
全屏背景圖，在view中添加一個(gè)UIImageView作為一個(gè)子View
只是某個(gè)小的view的背景圖，你就需要用UIColor的colorWithPatternImage來(lái)做了，它會(huì)更快地渲染也不會(huì)花費(fèi)很多內(nèi)存：
10、減少使用Web特性。
想要更高的性能你就要調(diào)整下你的HTML了。第一件要做的事就是盡可能移除不必要的javascript，避免使用過大的框架。能只用原生js就更好了。盡可能異步加載例如用戶行為統(tǒng)計(jì)script這種不影響頁(yè)面表達(dá)的javascript。注意你使用的圖片，保證圖片的符合你使用的大小。
11、Shadow Path 。
CoreAnimation不得不先在后臺(tái)得出你的圖形并加好陰影然后才渲染，這開銷是很大的。使用shadowPath的話就避免了這個(gè)問題。使用shadow path的話iOS就不必每次都計(jì)算如何渲染，它使用一個(gè)預(yù)先計(jì)算好的路徑。但問題是自己計(jì)算path的話可能在某些View中比較困難，且每當(dāng)view的frame變化的時(shí)候你都需要去update shadow path.
12、優(yōu)化Table View。
正確使用reuseIdentifier來(lái)重用cells。
盡量使所有的view opaque，包括cell自身。
避免漸變，圖片縮放。
緩存行高。
如果cell內(nèi)現(xiàn)實(shí)的內(nèi)容來(lái)自web，使用異步加載，緩存請(qǐng)求結(jié)果。
使用shadowPath來(lái)畫陰影。
減少subviews的數(shù)量。
盡量不適用cellForRowAtIndexPath:，如果你需要用到它，只用一次然后緩存結(jié)果。
使用正確的數(shù)據(jù)結(jié)構(gòu)來(lái)存儲(chǔ)數(shù)據(jù)。
使用rowHeight, sectionFooterHeight 和sectionHeaderHeight來(lái)設(shè)定固定的高，不要請(qǐng)求delegate。
13、選擇正確的數(shù)據(jù)存儲(chǔ)選項(xiàng)。
NSUserDefaults的問題是什么？雖然它很nice也很便捷，但是它只適用于小數(shù)據(jù)，比如一些簡(jiǎn)單的布爾型的設(shè)置選項(xiàng)，再大點(diǎn)你就要考慮其它方式了。
XML這種結(jié)構(gòu)化檔案呢？總體來(lái)說(shuō)，你需要讀取整個(gè)文件到內(nèi)存里去解析，這樣是很不經(jīng)濟(jì)的。使用SAX又是一個(gè)很麻煩的事情。
NSCoding？不幸的是，它也需要讀寫文件，所以也有以上問題。
在這種應(yīng)用場(chǎng)景下，使用SQLite 或者 Core Data比較好。使用這些技術(shù)你用特定的查詢語(yǔ)句就能只加載你需要的對(duì)象。
在性能層面來(lái)講，SQLite和Core Data是很相似的。他們的不同在于具體使用方法。
Core Data代表一個(gè)對(duì)象的graph model，但SQLite就是一個(gè)DBMS。
Apple在一般情況下建議使用Core Data，但是如果你有理由不使用它，那么就去使用更加底層的SQLite吧。
如果你使用SQLite，你可以用FMDB這個(gè)庫(kù)來(lái)簡(jiǎn)化SQLite的操作，這樣你就不用花很多經(jīng)歷了解SQLite的C API了。
三、高級(jí)
1、加速啟動(dòng)時(shí)間。
快速打開app是很重要的，特別是用戶第一次打開它時(shí)，對(duì)app來(lái)講，第一印象太太太重要了。你能做的就是使它盡可能做更多的異步任務(wù)，比如加載遠(yuǎn)端或者數(shù)據(jù)庫(kù)數(shù)據(jù)，解析數(shù)據(jù)。避免過于龐大的XIB，因?yàn)樗麄兪窃谥骶€程上加載的。所以盡量使用沒有這個(gè)問題的Storyboards吧！一定要把設(shè)備從Xcode斷開來(lái)測(cè)試啟動(dòng)速度
2、使用Autorelease Pool。
NSAutoreleasePool負(fù)責(zé)釋放block中的autoreleased objects。一般情況下它會(huì)自動(dòng)被UIKit調(diào)用。但是有些狀況下你也需要手動(dòng)去創(chuàng)建它。假如你創(chuàng)建很多臨時(shí)對(duì)象，你會(huì)發(fā)現(xiàn)內(nèi)存一直在減少直到這些對(duì)象被release的時(shí)候。這是因?yàn)橹挥挟?dāng)UIKit用光了autorelease pool的時(shí)候memory才會(huì)被釋放。消息是你可以在你自己的@autoreleasepool里創(chuàng)建臨時(shí)的對(duì)象來(lái)避免這個(gè)行為。
3、選擇是否緩存圖片。
常見的從bundle中加載圖片的方式有兩種，一個(gè)是用imageNamed，二是用imageWithContentsOfFile，第一種比較常見一點(diǎn)。
4、避免日期格式轉(zhuǎn)換。
如果你要用NSDateFormatter來(lái)處理很多日期格式，應(yīng)該小心以待。就像先前提到的，任何時(shí)候重用NSDateFormatters都是一個(gè)好的實(shí)踐。如果你可以控制你所處理的日期格式，盡量選擇Unix時(shí)間戳。你可以方便地從時(shí)間戳轉(zhuǎn)換到NSDate:
- (NSDate*)dateFromUnixTimestamp:(NSTimeInterval)timestamp {
return[NSDate dateWithTimeIntervalSince1970:timestamp];
}
這樣會(huì)比用C來(lái)解析日期字符串還快！需要注意的是，許多web API會(huì)以微秒的形式返回時(shí)間戳，因?yàn)檫@種格式在javascript中更方便使用。記住用dateFromUnixTimestamp之前除以1000就好了。
四，平時(shí)你是如何對(duì)代碼進(jìn)行性能優(yōu)化的？
利用性能分析工具檢測(cè)，包括靜態(tài) Analyze 工具，以及運(yùn)行時(shí) Profile 工具，通過Xcode工具欄中Product->Profile可以啟動(dòng),
比如測(cè)試程序啟動(dòng)運(yùn)行時(shí)間，當(dāng)點(diǎn)擊Time Profiler應(yīng)用程序開始運(yùn)行后.就能獲取到整個(gè)應(yīng)用程序運(yùn)行消耗時(shí)間分布和百分比.為了保證數(shù)據(jù)分析在統(tǒng)一使用場(chǎng)景真實(shí)需要注意一定要使用真機(jī),因?yàn)榇藭r(shí)模擬器是運(yùn)行在Mac上，而Mac上的CPU往往比iOS設(shè)備要快。
為了防止一個(gè)應(yīng)用占用過多的系統(tǒng)資源，開發(fā)iOS的蘋果工程師門設(shè)計(jì)了一個(gè)“看門狗”的機(jī)制。在不同的場(chǎng)景下，“看門狗”會(huì)監(jiān)測(cè)應(yīng)用的性能。如果超出了該場(chǎng)景所規(guī)定的運(yùn)行時(shí)間，“看門狗”就會(huì)強(qiáng)制終結(jié)這個(gè)應(yīng)用的進(jìn)程。開發(fā)者們?cè)赾rashlog里面，會(huì)看到諸如0x8badf00d這樣的錯(cuò)誤代碼。
五，imagedNamed和imageWithContentsOfFile
imageNamed默認(rèn)加載圖片成功后會(huì)內(nèi)存中緩存圖片,這個(gè)方法用一個(gè)指定的名字在系統(tǒng)緩存中查找并返回一個(gè)圖片對(duì)象.如果緩存中沒有找到相應(yīng)的圖片對(duì)象,則從指定地方加載圖片然后緩存對(duì)象，并返回這個(gè)圖片對(duì)象.
imageWithContentsOfFile則僅只加載圖片,不緩存.
加載一張大圖并且使用一次，用imageWithContentsOfFile是最好,這樣CPU不需要做緩存節(jié)約時(shí)間.
使用場(chǎng)景需要編程時(shí)，應(yīng)該根據(jù)實(shí)際應(yīng)用場(chǎng)景加以區(qū)分，UIImage雖小，但使用元素較多問題會(huì)有所凸顯.
六，講講你用Instrument優(yōu)化動(dòng)畫性能的經(jīng)歷吧（別問我什么是Instrument）
Apple的instrument為開發(fā)者提供了各種template去優(yōu)化app性能和定位問題。很多公司都在趕feature，并沒有充足的時(shí)間來(lái)做優(yōu)化，導(dǎo)致不少開發(fā)者對(duì)instrument不怎么熟悉。但這里面其實(shí)涵蓋了非常完整的計(jì)算機(jī)基礎(chǔ)理論知識(shí)體系，memory，disk，network，thread，cpu，gpu等等，順藤摸瓜去學(xué)習(xí)，是一筆巨大的知識(shí)財(cái)富。動(dòng)畫性能只是其中一個(gè)template，重點(diǎn)還是理解上面問題當(dāng)中CPU GPU如何配合工作的知識(shí)。
七，其他
不要在viewWillAppear 中做費(fèi)時(shí)的操作：viewWillAppear: 在view顯示之前被調(diào)用，出于效率考慮，方法中不要處理復(fù)雜費(fèi)時(shí)操作；在該方法設(shè)置 view 的顯示屬性之類的簡(jiǎn)單事情，比如背景色，字體等。否則，會(huì)明顯感覺到 view 有卡頓或者延遲。
在正確的地方使用reuseIdentifier：table view用 tableView:cellForRowAtIndexPath:為rows分配cells的時(shí)候，它的數(shù)據(jù)應(yīng)該重用自UITableViewCell。
盡量把views設(shè)置為透明：如果你有透明的Views你應(yīng)該設(shè)置它們的opaque屬性為YES。系統(tǒng)用一個(gè)最優(yōu)的方式渲染這些views。這個(gè)簡(jiǎn)單的屬性在IB或者代碼里都可以設(shè)定。
避免過于龐大的XIB：盡量簡(jiǎn)單的為每個(gè)Controller配置一個(gè)單獨(dú)的XIB，盡可能把一個(gè)View Controller的view層次結(jié)構(gòu)分散到單獨(dú)的XIB中去, 當(dāng)你加載一個(gè)引用了圖片或者聲音資源的nib時(shí)，nib加載代碼會(huì)把圖片和聲音文件寫進(jìn)內(nèi)存。
不要阻塞主線程：永遠(yuǎn)不要使主線程承擔(dān)過多。因?yàn)閁IKit在主線程上做所有工作，渲染，管理觸摸反應(yīng)，回應(yīng)輸入等都需要在它上面完成,大部分阻礙主進(jìn)程的情形是你的app在做一些牽涉到讀寫外部資源的I/O操作，比如存儲(chǔ)或者網(wǎng)絡(luò)。
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
// 選擇一個(gè)子線程來(lái)執(zhí)行耗時(shí)操作
dispatch_async(dispatch_get_main_queue(), ^{
// 返回主線程更新UI
});
});
在Image Views中調(diào)整圖片大小 如果要在UIImageView中顯示一個(gè)來(lái)自bundle的圖片，你應(yīng)保證圖片的大小和UIImageView的大小相同。在運(yùn)行中縮放圖片是很耗費(fèi)資源的.
