續(xù) 性能優(yōu)化(上)
iOS最全性能優(yōu)化(上)http://www.reibang.com/p/bd91f0347000
iOS最全性能優(yōu)化(中)http://www.reibang.com/p/f86221a69d4c
iOS最全性能優(yōu)化(下)http://www.reibang.com/p/e47aba73d975
9. 重用和延遲加載(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)存分配呛讲。
創(chuàng)建views的能效問(wèn)題也適用于你app的其它方面。想象一下一個(gè)用戶點(diǎn)擊一個(gè)按鈕的時(shí)候需要呈現(xiàn)一個(gè)view的場(chǎng)景返奉。有兩種實(shí)現(xiàn)方法：
創(chuàng)建并隱藏這個(gè)view當(dāng)這個(gè)screen加載的時(shí)候贝搁，當(dāng)需要時(shí)顯示它；
當(dāng)需要時(shí)才創(chuàng)建并展示芽偏。
每個(gè)方案都有其優(yōu)缺點(diǎn)雷逆。
用第一種方案的話因?yàn)槟阈枰婚_(kāi)始就創(chuàng)建一個(gè)view并保持它直到不再使用，這就會(huì)更加消耗內(nèi)存污尉。然而這也會(huì)使你的app操作更敏感因?yàn)楫?dāng)用戶點(diǎn)擊按鈕的時(shí)候它只需要改變一下這個(gè)view的可見(jiàn)性膀哲。
第二種方案則相反-消耗更少內(nèi)存，但是會(huì)在點(diǎn)擊按鈕的時(shí)候比第一種稍顯卡頓被碗。
10. Cache, Cache, 還是Cache!
一個(gè)極好的原則就是某宪，緩存所需要的，也就是那些不大可能改變但是需要經(jīng)常讀取的東西锐朴。
我們能緩存些什么呢兴喂？一些選項(xiàng)是，遠(yuǎn)端服務(wù)器的響應(yīng)焚志，圖片衣迷，甚至計(jì)算結(jié)果，比如UITableView的行高酱酬。
NSURLConnection默認(rèn)會(huì)緩存資源在內(nèi)存或者存儲(chǔ)中根據(jù)它所加載的HTTP Headers壶谒。你甚至可以手動(dòng)創(chuàng)建一個(gè)NSURLRequest然后使它只加載緩存的值。
下面是一個(gè)可用的代碼段膳沽，你可以可以用它去為一個(gè)基本不會(huì)改變的圖片創(chuàng)建一個(gè)NSURLRequest并緩存它：
+ (NSMutableURLRequest *)imageRequestWithURL:(NSURL *)url {
NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url];
request.cachePolicy = NSURLRequestReturnCacheDataElseLoad;// this will make sure the request always returns the cached image
request.HTTPShouldHandleCookies = NO;
request.HTTPShouldUsePipelining = YES;
[request addValue:@"image/*"forHTTPHeaderField:@"Accept"];
returnrequest;
}
注意你可以通過(guò) NSURLConnection 獲取一個(gè)URL request佃迄， AFNetworking也一樣的泼差。這樣你就不必為采用這條tip而改變所有的networking代碼了。
如果想了解更多關(guān)于HTTP caching, NSURLCache, NSURLConnection的相關(guān)知識(shí)呵俏，可以讀下這篇文章()
如果你需要緩存其它不是HTTP Request的東西堆缘，你可以用NSCache。
NSCache和NSDictionary類(lèi)似普碎，不同的是系統(tǒng)回收內(nèi)存的時(shí)候它會(huì)自動(dòng)刪掉它的內(nèi)容吼肥。
11. 權(quán)衡渲染方法
在iOS中可以有很多方法做出漂亮的按鈕。你可以用整幅的圖片麻车，可調(diào)大小的圖片缀皱，uozhe可以用CALayer， CoreGraphics甚至OpenGL來(lái)畫(huà)它們动猬。
當(dāng)然每個(gè)不同的解決方法都有不同的復(fù)雜程度和相應(yīng)的性能啤斗。有一篇Apple UIKit team中的一員Andy Matuschak推薦過(guò)的很棒的關(guān)于graphic性能的帖子很值得一讀。
-
簡(jiǎn)單來(lái)說(shuō)赁咙，就是用事先渲染好的圖片更快一些钮莲，因?yàn)槿绱艘粊?lái)iOS就免去了創(chuàng)建一個(gè)圖片再畫(huà)東西上去然后顯示在屏幕上的程序。問(wèn)題是你需要把所有你需要用到的圖片放到app的bundle里面彼水，這樣就增加了體積 – 這就是使用可變大小的圖片更好的地方了: 你可以省去一些不必要的空間崔拥，也不需要再為不同的元素(比如按鈕)來(lái)做不同的圖。
然而凤覆，使用圖片也意味著你失去了使用代碼調(diào)整圖片的機(jī)動(dòng)性链瓦，你需要一遍又一遍不斷地重做他們，這樣就很浪費(fèi)時(shí)間了盯桦，而且你如果要做一個(gè)動(dòng)畫(huà)效果慈俯，雖然每幅圖只是一些細(xì)節(jié)的變化你就需要很多的圖片造成bundle大小的不斷增大。
總得來(lái)說(shuō)拥峦，你需要權(quán)衡一下利弊贴膘，到底是要性能能還是要bundle保持合適的大小。
12. 處理內(nèi)存警告
一旦系統(tǒng)內(nèi)存過(guò)低事镣，iOS會(huì)通知所有運(yùn)行中app步鉴。在官方文檔中是這樣記述:
如果你的app收到了內(nèi)存警告揪胃，它就需要盡可能釋放更多的內(nèi)存璃哟。最佳方式是移除對(duì)緩存，圖片object和其他一些可以重創(chuàng)建的objects的strong references.
幸運(yùn)的是喊递，UIKit提供了幾種收集低內(nèi)存警告的方法:
在app delegate中使用
applicationDidReceiveMemoryWarning:的方法在你的自定義UIViewController的子類(lèi)(subclass)中覆蓋
didReceiveMemoryWarning注冊(cè)并接收 UIApplicationDidReceiveMemoryWarningNotification 的通知
一旦收到這類(lèi)通知随闪，你就需要釋放任何不必要的內(nèi)存使用。
例如骚勘，UIViewController的默認(rèn)行為是移除一些不可見(jiàn)的view铐伴， 它的一些子類(lèi)則可以補(bǔ)充這個(gè)方法撮奏，刪掉一些額外的數(shù)據(jù)結(jié)構(gòu)。一個(gè)有圖片緩存的app可以移除不在屏幕上顯示的圖片当宴。
這樣對(duì)內(nèi)存警報(bào)的處理是很必要的畜吊，若不重視，你的app就可能被系統(tǒng)殺掉户矢。
然而玲献，當(dāng)你一定要確認(rèn)你所選擇的object是可以被重現(xiàn)創(chuàng)建的來(lái)釋放內(nèi)存。一定要在開(kāi)發(fā)中用模擬器中的內(nèi)存提醒模擬去測(cè)試一下梯浪。
13. 重用大開(kāi)銷(xiāo)對(duì)象
一些objects的初始化很慢捌年，比如NSDateFormatter和NSCalendar。然而挂洛，你又不可避免地需要使用它們礼预，比如從JSON或者XML中解析數(shù)據(jù)。
想要避免使用這個(gè)對(duì)象的瓶頸你就需要重用他們虏劲，可以通過(guò)添加屬性到你的class里或者創(chuàng)建靜態(tài)變量來(lái)實(shí)現(xiàn)托酸。
注意如果你要選擇第二種方法，對(duì)象會(huì)在你的app運(yùn)行時(shí)一直存在于內(nèi)存中伙单，和單例(singleton)很相似获高。
下面的代碼說(shuō)明了使用一個(gè)屬性來(lái)延遲加載一個(gè)date formatter. 第一次調(diào)用時(shí)它會(huì)創(chuàng)建一個(gè)新的實(shí)例，以后的調(diào)用則將返回已經(jīng)創(chuàng)建的實(shí)例：
// in your .h or inside a class extension
@property (nonatomic, strong) NSDateFormatter *formatter;
// inside the implementation (.m)
// When you need, just use self.formatter
- (NSDateFormatter *)formatter {
if(! _formatter) {
_formatter = [[NSDateFormatter alloc] init];
_formatter.dateFormat = @"EEE MMM dd HH:mm:ss Z yyyy";// twitter date format
}
return_formatter;
}
還需要注意的是吻育，其實(shí)設(shè)置一個(gè)NSDateFormatter的速度差不多是和創(chuàng)建新的一樣慢的念秧！所以如果你的app需要經(jīng)常進(jìn)行日期格式處理的話，你會(huì)從這個(gè)方法中得到不小的性能提升布疼。
14. 使用Sprite Sheets
你是一個(gè)游戲開(kāi)發(fā)者嗎摊趾，那么Sprite sheets一定是一個(gè)你的最好的朋友了。Sprite sheet可以讓渲染速度加快游两，甚至比標(biāo)準(zhǔn)的屏幕渲染方法節(jié)省內(nèi)存砾层。
我們有兩個(gè)很好的關(guān)于Sprite的教程：
How To Use Animations and Sprite Sheets in Cocos2D
How to Create and Optimize Sprite Sheets in Cocos2D with Texture Packer and Pixel Formats
第二個(gè)教程涵蓋了可能在很大程度上影響你游戲性能的pixel格式的細(xì)節(jié)。
如果你對(duì)于spirte sheet還不是很熟悉贱案，可以看下這兩個(gè)(youtube)視頻SpriteSheets – The Movie, Part 1 和Part 2肛炮。視頻的作者是創(chuàng)建Sprite sheet很流行的工具之一Texture Packer的作者Andreas L?w。
除了使用Sprite sheets宝踪，其它寫(xiě)在這里的建議當(dāng)然也可以用于游戲開(kāi)發(fā)中侨糟。比如你需要很多的Sprite sheets，像敵人瘩燥，導(dǎo)彈之類(lèi)的動(dòng)作類(lèi)必備元素秕重，你可以重用這些sprites而不用每次都要重新創(chuàng)建。
15. 避免反復(fù)處理數(shù)據(jù)
許多應(yīng)用需要從服務(wù)器加載功能所需的常為JSON或者XML格式的數(shù)據(jù)厉膀。在服務(wù)器端和客戶端使用相同的數(shù)據(jù)結(jié)構(gòu)很重要溶耘。在內(nèi)存中操作數(shù)據(jù)使它們滿足你的數(shù)據(jù)結(jié)構(gòu)是開(kāi)銷(xiāo)很大的二拐。
比如你需要數(shù)據(jù)來(lái)展示一個(gè)table view,最好直接從服務(wù)器取array結(jié)構(gòu)的數(shù)據(jù)以避免額外的中間數(shù)據(jù)結(jié)構(gòu)改變。
類(lèi)似的凳兵，如果需要從特定key中取數(shù)據(jù)百新，那么就使用鍵值對(duì)的dictionary。
16. 選擇正確的數(shù)據(jù)格式
從app和網(wǎng)絡(luò)服務(wù)間傳輸數(shù)據(jù)有很多方案庐扫，最常見(jiàn)的就是JSON和XML吟孙。你需要選擇對(duì)你的app來(lái)說(shuō)最合適的一個(gè)。
解析JSON會(huì)比XML更快一些聚蝶，JSON也通常更小更便于傳輸杰妓。從iOS5起有了官方內(nèi)建的JSON deserialization 就更加方便使用了。
但是XML也有XML的好處碘勉，比如使用SAX 來(lái)解析XML就像解析本地文件一樣巷挥，你不需像解析json一樣等到整個(gè)文檔下載完成才開(kāi)始解析。當(dāng)你處理很大的數(shù)據(jù)的時(shí)候就會(huì)極大地減低內(nèi)存消耗和增加性能验靡。
17. 正確設(shè)定背景圖片
在View里放背景圖片就像很多其它iOS編程一樣有很多方法:
使用UIColor的 colorWithPatternImage來(lái)設(shè)置背景色倍宾；
在view中添加一個(gè)UIImageView作為一個(gè)子View。
如果你使用全畫(huà)幅的背景圖胜嗓，你就必須使用UIImageView因?yàn)閁IColor的colorWithPatternImage是用來(lái)創(chuàng)建小的重復(fù)的圖片作為背景的高职。這種情形下使用UIImageView可以節(jié)約不少的內(nèi)存：
// You could also achieve the same result in Interface Builder
UIImageView *backgroundView = [[UIImageView alloc] initWithImage:[UIImage imageNamed:@"background"]];
[self.view addSubview:backgroundView];
如果你用小圖平鋪來(lái)創(chuàng)建背景，你就需要用UIColor的colorWithPatternImage來(lái)做了辞州，它會(huì)更快地渲染也不會(huì)花費(fèi)很多內(nèi)存：
self.view.backgroundColor = [UIColor colorWithPatternImage:[UIImage imageNamed:@"background"]];
18. 減少使用Web特性
UIWebView很有用怔锌，用它來(lái)展示網(wǎng)頁(yè)內(nèi)容或者創(chuàng)建UIKit很難做到的動(dòng)畫(huà)效果是很簡(jiǎn)單的一件事。
但是你可能有注意到UIWebView并不像驅(qū)動(dòng)Safari的那么快变过。這是由于以JIT compilation 為特色的Webkit的Nitro Engine的限制埃元。
所以想要更高的性能你就要調(diào)整下你的HTML了。第一件要做的事就是盡可能移除不必要的javascript媚狰，避免使用過(guò)大的框架岛杀。能只用原生js就更好了。
另外崭孤，盡可能異步加載例如用戶行為統(tǒng)計(jì)script這種不影響頁(yè)面表達(dá)的javascript类嗤。
最后，永遠(yuǎn)要注意你使用的圖片辨宠，保證圖片的符合你使用的大小遗锣。使用Sprite sheet提高加載速度和節(jié)約內(nèi)存。
更多相關(guān)信息可以看下 WWDC 2012 session #601 – Optimizing Web Content in UIWebViews and Websites on iOS
19. 設(shè)定Shadow Path
如何在一個(gè)View或者一個(gè)layer上加一個(gè)shadow呢彭羹，QuartzCore框架是很多開(kāi)發(fā)者的選擇：
#import <QuartzCore/QuartzCore.h>
// Somewhere later ...
UIView *view = [[UIView alloc] init];
// Setup the shadow ...
view.layer.shadowOffset = CGSizeMake(-1.0f, 1.0f);
view.layer.shadowRadius = 5.0f;
view.layer.shadowOpacity = 0.6;
看起來(lái)很簡(jiǎn)單黄伊，對(duì)吧泪酱。
可是派殷，壞消息是使用這個(gè)方法也有它的問(wèn)題… Core Animation不得不先在后臺(tái)得出你的圖形并加好陰影然后才渲染还最，這開(kāi)銷(xiāo)是很大的。
使用shadowPath的話就避免了這個(gè)問(wèn)題：
view.layer.shadowPath = [[UIBezierPath bezierPathWithRect:view.bounds] CGPath];
使用shadow path的話iOS就不必每次都計(jì)算如何渲染毡惜，它使用一個(gè)預(yù)先計(jì)算好的路徑拓轻。但問(wèn)題是自己計(jì)算path的話可能在某些View中比較困難，且每當(dāng)view的frame變化的時(shí)候你都需要去update shadow path.
想了解更多可以看看Mark Pospesel的這篇经伙。
20. 優(yōu)化Table View
Table view需要有很好的滾動(dòng)性能扶叉，不然用戶會(huì)在滾動(dòng)過(guò)程中發(fā)現(xiàn)動(dòng)畫(huà)的瑕疵。
為了保證table view平滑滾動(dòng)帕膜，確保你采取了以下的措施:
正確使用
reuseIdentifier來(lái)重用cells盡量使所有的view opaque枣氧，包括cell自身
避免漸變，圖片縮放垮刹，后臺(tái)選人
緩存行高
如果cell內(nèi)現(xiàn)實(shí)的內(nèi)容來(lái)自web达吞，使用異步加載，緩存請(qǐng)求結(jié)果
使用
shadowPath來(lái)畫(huà)陰影減少subviews的數(shù)量
盡量不適用
cellForRowAtIndexPath:荒典，如果你需要用到它酪劫，只用一次然后緩存結(jié)果使用正確的數(shù)據(jù)結(jié)構(gòu)來(lái)存儲(chǔ)數(shù)據(jù)
盡量使用
rowHeight,sectionFooterHeight和sectionHeaderHeight來(lái)設(shè)定固定的高，不要請(qǐng)求delegate
21. 選擇正確的數(shù)據(jù)存儲(chǔ)選項(xiàng)
當(dāng)做本地?cái)?shù)據(jù)存儲(chǔ)時(shí)你會(huì)怎么做寺董？
你有很多選擇覆糟，比如：
使用
NSUerDefaults使用XML, JSON, 或者 plist
使用NSCoding存檔
使用類(lèi)似SQLite的本地SQL數(shù)據(jù)庫(kù)
使用 Core Data
NSUserDefaults的問(wèn)題是什么？雖然它很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？不幸的是背率，它也需要讀寫(xiě)文件话瞧，所以也有以上問(wèn)題放接。
當(dāng)存儲(chǔ)大塊數(shù)據(jù)時(shí),以上的方法都不適用. 在這種應(yīng)用場(chǎng)景下凳忙，使用SQLite 或者 Core Data比較好。使用這些技術(shù)你用特定的查詢(xún)語(yǔ)句就能只加載你需要的對(duì)象扑媚。
在性能層面來(lái)講饵筑，SQLite和Core Data是很相似的埃篓。他們的不同在于具體使用方法。Core Data代表一個(gè)對(duì)象的graph model根资，但SQLite就是一個(gè)DBMS架专。Apple在一般情況下建議使用Core Data同窘，但是如果你有理由不使用它，那么就去使用更加底層的SQLite吧部脚。
