在性能優(yōu)化中一個(gè)最具參考價(jià)值的屬性是FPS:Frames Per Second,其實(shí)就是屏幕刷新率朋鞍，蘋果的iphone推薦的刷新率是60Hz咬展，也就是說GPU每秒鐘刷新屏幕60次，這每刷新一次就是一幀frame，F(xiàn)PS也就是每秒鐘刷新多少幀畫面。靜止不變的頁面FPS值是0叨叙，這個(gè)值是沒有參考意義的，只有當(dāng)頁面在執(zhí)行動(dòng)畫或者滑動(dòng)的時(shí)候堪澎，F(xiàn)PS值才具有參考價(jià)值擂错，F(xiàn)PS值的大小體現(xiàn)了頁面的流暢程度高低，當(dāng)?shù)陀?5的時(shí)候卡頓會(huì)比較明顯樱蛤。

圖層混合：

每一個(gè)layer是一個(gè)紋理钮呀，所有的紋理都以某種方式堆疊在彼此的頂部剑鞍。對于屏幕上的每一個(gè)像素，GPU需要算出怎么混合這些紋理來得到像素RGB的值爽醋。

當(dāng)Sa = 0.5時(shí)蚁署，RGB值為(0.5, 0, 0)，可以看出蚂四，當(dāng)兩個(gè)不是完全不透明的CALayer覆蓋在一起時(shí),GPU大量做這種復(fù)合操作光戈，隨著這中操作的越多，GPU越忙碌遂赠，性能肯定會(huì)受到影響久妆。

推薦學(xué)習(xí)iOS技術(shù)加油站網(wǎng)站：docs.qq.com/doc/DVWlQam9Qd3B1cEF2

公式：

R = S + D * ( 1 – Sa )

結(jié)果的顏色是源色彩(頂端紋理)+目標(biāo)顏色(低一層的紋理)*(1-源顏色的透明度)。

當(dāng)Sa = 1時(shí)跷睦，R = S,GPU將不會(huì)做任何合成筷弦，而是簡單從這個(gè)層拷貝，不需要考慮它下方的任何東西(因?yàn)槎急凰趽踝×?送讲，這節(jié)省了GPU相當(dāng)大的工作量奸笤。

一、入門級

1哼鬓、用ARC管理內(nèi)存

2、在正確的地方使用 reuseIdentifier

3边灭、盡量把views設(shè)置為透明

4异希、避免過于龐大的XIB

5、不要阻塞主線程

6绒瘦、在ImageViews中調(diào)整圖片大小称簿。如果要在UIImageView中顯示一個(gè)來自bundle的圖片，你應(yīng)保證圖片的大小和UIImageView的大小相同惰帽。在運(yùn)行中縮放圖片是很耗費(fèi)資源的憨降，特別是UIImageView嵌套在UIScrollView中的情況下。如果圖片是從遠(yuǎn)端服務(wù)加載的你不能控制圖片大小该酗，比如在下載前調(diào)整到合適大小的話授药，你可以在下載完成后，最好是用background

thread呜魄，縮放一次悔叽，然后在UIImageView中使用縮放后的圖片。

7爵嗅、選擇正確的Collection娇澎。

Arrays: 有序的一組值。使用index來lookup很快睹晒，使用value lookup很慢趟庄， 插入/刪除很慢括细。

Dictionaries: 存儲(chǔ)鍵值對。 用鍵來查找比較快戚啥。

Sets: 無序的一組值奋单。用值來查找很快，插入/刪除很快虑鼎。

8辱匿、打開gzip壓縮。app可能大量依賴于服務(wù)器資源炫彩，問題是我們的目標(biāo)是移動(dòng)設(shè)備匾七，因此你就不能指望網(wǎng)絡(luò)狀況有多好。減小文檔的一個(gè)方式就是在服務(wù)端和你的app中打開gzip江兢。這對于文字這種能有更高壓縮率的數(shù)據(jù)來說會(huì)有更顯著的效用昨忆。

iOS已經(jīng)在NSURLConnection中默認(rèn)支持了gzip壓縮，當(dāng)然AFNetworking這些基于它的框架亦然杉允。

二邑贴、中級

1、重用和延遲加載(lazy load) Views

更多的view意味著更多的渲染叔磷，也就是更多的CPU和內(nèi)存消耗拢驾，對于那種嵌套了很多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)存警告.移除對緩存，圖片object和其他一些可以重創(chuàng)建的objects的strong references.

5端仰、重用大開銷對象

6敢订、一些objects的初始化很慢敦腔，比如NSDateFormatter和NSCalendar怠苔。然而刚盈，你又不可避免地需要使用它們，比如從JSON或者XML中解析數(shù)據(jù)鹤竭。想要避免使用這個(gè)對象的瓶頸你就需要重用他們踊餐，可以通過添加屬性到你的class里或者創(chuàng)建靜態(tà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 來解析XML就像解析本地文件一樣幕帆，你不需像解析json一樣等到整個(gè)文檔下載完成才開始解析。當(dāng)你處理很大的數(shù)據(jù)的時(shí)候就會(huì)極大地減低內(nèi)存消耗和增加性能赖条。

9蜓肆、正確設(shè)定背景圖片

全屏背景圖，在view中添加一個(gè)UIImageView作為一個(gè)子View

只是某個(gè)小的view的背景圖谋币，你就需要用UIColor的colorWithPatternImage來做了，它會(huì)更快地渲染也不會(huì)花費(fèi)很多內(nèi)存：

10症概、減少使用Web特性蕾额。想要更高的性能你就要調(diào)整下你的HTML了。第一件要做的事就是盡可能移除不必要的javascript彼城，避免使用過大的框架诅蝶。能只用原生js就更好了。盡可能異步加載例如用戶行為統(tǒng)計(jì)script這種不影響頁面表達(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來重用cells

盡量使所有的view opaque，包括cell自身

避免漸變姨拥，圖片縮放绅喉，后臺(tái)選人

緩存行高

如果cell內(nèi)現(xiàn)實(shí)的內(nèi)容來自web，使用異步加載叫乌，緩存請求結(jié)果

使用shadowPath來畫陰影

減少subviews的數(shù)量

盡量不適用cellForRowAtIndexPath:柴罐，如果你需要用到它，只用-一次然后緩存結(jié)果

使用正確的數(shù)據(jù)結(jié)構(gòu)來存儲(chǔ)數(shù)據(jù)

使用rowHeight, sectionFooterHeight 和 sectionHeaderHeight來設(shè)定固定的高综芥，不要請求delegate

13丽蝎、選擇正確的數(shù)據(jù)存儲(chǔ)選項(xiàng)

NSUserDefaults的問題是什么？雖然它很nice也很便捷膀藐，但是它只適用于小數(shù)據(jù)屠阻，比如一些簡單的布爾型的設(shè)置選項(xiàng)，再大點(diǎn)你就要考慮其它方式了

XML這種結(jié)構(gòu)化檔案呢额各？總體來說国觉，你需要讀取整個(gè)文件到內(nèi)存里去解析，這樣是很不經(jīng)濟(jì)的虾啦。使用SAX又是一個(gè)很麻煩的事情麻诀。

NSCoding？不幸的是傲醉，它也需要讀寫文件蝇闭，所以也有以上問題。

在這種應(yīng)用場景下硬毕，使用SQLite 或者 Core Data比較好呻引。使用這些技術(shù)你用特定的查詢語句就能只加載你需要的對象。

在性能層面來講吐咳，SQLite和Core Data是很相似的逻悠。他們的不同在于具體使用方法。

Core Data代表一個(gè)對象的graph model韭脊，但SQLite就是一個(gè)DBMS童谒。

Apple在一般情況下建議使用Core Data，但是如果你有理由不使用它沪羔，那么就去使用更加底層的SQLite吧饥伊。

如果你使用SQLite，你可以用FMDB這個(gè)庫來簡化SQLite的操作，這樣你就不用花很多經(jīng)歷了解SQLite的C API了撵渡。

三融柬、高級

1、加速啟動(dòng)時(shí)間趋距×Ｑ酰快速打開app是很重要的，特別是用戶第一次打開它時(shí)节腐，對app來講外盯，第一印象太太太重要了。你能做的就是使它盡可能做更多的異步任務(wù)翼雀，比如加載遠(yuǎn)端或者數(shù)據(jù)庫數(shù)據(jù)饱苟，解析數(shù)據(jù)。避免過于龐大的XIB狼渊，因?yàn)樗麄兪窃谥骶€程上加載的箱熬。所以盡量使用沒有這個(gè)問題的Storyboards吧！一定要把設(shè)備從Xcode斷開來測試啟動(dòng)速度

2狈邑、使用Autorelease Pool城须。NSAutoreleasePool`負(fù)責(zé)釋放block中的autoreleased objects。一般情況下它會(huì)自動(dòng)被UIKit調(diào)用米苹。但是有些狀況下你也需要手動(dòng)去創(chuàng)建它糕伐。假如你創(chuàng)建很多臨時(shí)對象，你會(huì)發(fā)現(xiàn)內(nèi)存一直在減少直到這些對象被release的時(shí)候蘸嘶。這是因?yàn)橹挥挟?dāng)UIKit用光了autorelease pool的時(shí)候memory才會(huì)被釋放良瞧。消息是你可以在你自己的@autoreleasepool里創(chuàng)建臨時(shí)的對象來避免這個(gè)行為。

3训唱、選擇是否緩存圖片褥蚯。常見的從bundle中加載圖片的方式有兩種，一個(gè)是用imageNamed况增，二是用imageWithContentsOfFile遵岩，第一種比較常見一點(diǎn)。

4巡通、避免日期格式轉(zhuǎn)換。如果你要用NSDateFormatter來處理很多日期格式舍哄，應(yīng)該小心以待宴凉。就像先前提到的，任何時(shí)候重用NSDateFormatters都是一個(gè)好的實(shí)踐表悬。如果你可以控制你所處理的日期格式弥锄，盡量選擇Unix時(shí)間戳。你可以方便地從時(shí)間戳轉(zhuǎn)換到NSDate:

- (NSDate*)dateFromUnixTimestamp:(NSTimeInterval)timestamp {

return[NSDate dateWithTimeIntervalSince1970:timestamp];

}

這樣會(huì)比用C來解析日期字符串還快！需要注意的是籽暇，許多web API會(huì)以微秒的形式返回時(shí)間戳温治，因?yàn)檫@種格式在javascript中更方便使用。記住用dateFromUnixTimestamp之前除以1000就好了戒悠。

平時(shí)你是如何對代碼進(jìn)行性能優(yōu)化的熬荆？

利用性能分析工具檢測，包括靜態(tài) Analyze 工具绸狐，以及運(yùn)行時(shí) Profile 工具卤恳，通過Xcode工具欄中Product->Profile可以啟動(dòng),

比如測試程序啟動(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)一使用場景真實(shí)需要注意一定要使用真機(jī),因?yàn)榇藭r(shí)模擬器是運(yùn)行在Mac上寒矿，而Mac上的CPU往往比iOS設(shè)備要快突琳。

為了防止一個(gè)應(yīng)用占用過多的系統(tǒng)資源，開發(fā)iOS的蘋果工程師門設(shè)計(jì)了一個(gè)“看門狗”的機(jī)制符相。在不同的場景下拆融，“看門狗”會(huì)監(jiān)測應(yīng)用的性能。如果超出了該場景所規(guī)定的運(yùn)行時(shí)間啊终，“看門狗”就會(huì)強(qiáng)制終結(jié)這個(gè)應(yīng)用的進(jìn)程镜豹。開發(fā)者們在crashlog里面，會(huì)看到諸如0x8badf00d這樣的錯(cuò)誤代碼孕索。

優(yōu)化Table View

正確使用reuseIdentifier來重用cells

盡量使所有的view opaque逛艰，包括cell自身

如果cell內(nèi)現(xiàn)實(shí)的內(nèi)容來自web，使用異步加載搞旭，緩存請求結(jié)果

減少subviews的數(shù)量

盡量不適用cellForRowAtIndexPath:散怖，如果你需要用到它，只用一次然后緩存結(jié)果

使用rowHeight, sectionFooterHeight和sectionHeaderHeight來設(shè)定固定的高肄渗，不要請求delegate

UIImage加載圖片性能問題

imagedNamed初始化

imageWithContentsOfFile初始化

imageNamed默認(rèn)加載圖片成功后會(huì)內(nèi)存中緩存圖片,這個(gè)方法用一個(gè)指定的名字在系統(tǒng)緩存中查找并返回一個(gè)圖片對象.如果緩存中沒有找到相應(yīng)的圖片對象,則從指定地方加載圖片然后緩存對象镇眷，并返回這個(gè)圖片對象.

imageWithContentsOfFile則僅只加載圖片,不緩存.

加載一張大圖并且使用一次，用imageWithContentsOfFile是最好,這樣CPU不需要做緩存節(jié)約時(shí)間.

使用場景需要編程時(shí)翎嫡，應(yīng)該根據(jù)實(shí)際應(yīng)用場景加以區(qū)分欠动，UIimage雖小，但使用元素較多問題會(huì)有所凸顯.

不要在viewWillAppear 中做費(fèi)時(shí)的操作：viewWillAppear: 在view顯示之前被調(diào)用惑申，出于效率考慮具伍，方法中不要處理復(fù)雜費(fèi)時(shí)操作；在該方法設(shè)置 view 的顯示屬性之類的簡單事情圈驼，比如背景色人芽，字體等。否則绩脆，會(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è)簡單的屬性在IB或者代碼里都可以設(shè)定。

避免過于龐大的XIB：盡量簡單的為每個(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è)子線程來執(zhí)行耗時(shí)操作

dispatch_async(dispatch_get_main_queue(), ^{

// 返回主線程更新UI

});

});

在Image Views中調(diào)整圖片大小

如果要在UIImageView中顯示一個(gè)來自bundle的圖片捎谨，你應(yīng)保證圖片的大小和UIImageView的大小相同民效。在運(yùn)行中縮放圖片是很耗費(fèi)資源的.

講講你用Instrument優(yōu)化動(dòng)畫性能的經(jīng)歷吧（別問我什么是Instrument）

Apple的instrument為開發(fā)者提供了各種template去優(yōu)化app性能和定位問題。很多公司都在趕feature涛救，并沒有充足的時(shí)間來做優(yōu)化畏邢，導(dǎo)致不少開發(fā)者對instrument不怎么熟悉。但這里面其實(shí)涵蓋了非常完整的計(jì)算機(jī)基礎(chǔ)理論知識體系检吆，memory舒萎，disk，network蹭沛，thread臂寝，cpu，gpu等等摊灭，順藤摸瓜去學(xué)習(xí)咆贬，是一筆巨大的知識財(cái)富。動(dòng)畫性能只是其中一個(gè)template帚呼，重點(diǎn)還是理解上面問題當(dāng)中CPU GPU如何配合工作的知識掏缎。

facebook啟動(dòng)時(shí)間優(yōu)化

1.瘦身請求依賴

2.UDP啟動(dòng)請求先行緩存

3.隊(duì)列串行化處理啟動(dòng)響應(yīng)

為自己的面試，為自己的跳槽煤杀，加油吧 iOS開發(fā)

簡歷模板+最新iOS題目+提升視頻：docs.qq.com/doc/DVWlQam9Qd3B1cEF2