1. 用ARC管理內(nèi)存
ARC(Automatic ReferenceCounting, 自動引用計數(shù))和iOS5一起發(fā)布蹄咖，它避免了最常見的也就是經(jīng)常是由于我們忘記釋放內(nèi)存所造成的內(nèi)存泄露屡谐。它自動為你管理retain和release的過程贱呐，所以你就不必去手動干預(yù)了狭莱。忘掉代碼段結(jié)尾的release簡直像記得吃飯一樣簡單稚字。
而ARC會自動在底層為你做這些工作万搔。除了幫你避免內(nèi)存泄露仰坦，ARC還可以幫你提高性能蘸嘶，它能保證釋放掉不再需要的對象的內(nèi)存良瞧。
現(xiàn)在所有的iOS程序都用ARC了，這條可以忽略训唱。
2. 在正確的地方使用 reuseIdentifier
一個開發(fā)中常見的錯誤就是沒有給UITableViewCells褥蚯， UICollectionViewCells
甚至是UITableViewHeaderFooterViews設(shè)置正確的reuseIdentifier。
為了性能最優(yōu)化况增，table view赞庶，tableView:cellForRowAtIndexPath:為rows分配cells的時候，它的數(shù)據(jù)應(yīng)該重用自UITableViewCell澳骤。
一個table view維持一個隊列的數(shù)據(jù)可重用的UITableViewCell對象歧强。
不使用reuseIdentifier的話，每顯示一行table view就不得不設(shè)置全新的cell为肮。這對性能的影響可是相當(dāng)大的摊册，尤其會使app的滾動體驗大打折扣。
自iOS6起颊艳，除了UICollectionView的cells和補(bǔ)充views茅特，你也應(yīng)該在header和footer views中使用reuseIdentifiers。
想要使用reuseIdentifiers的話棋枕，在一個table view中添加一個新的cell時在data source object中添加這個方法：
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
// switch to a background thread and perform your expensive operation
dispatch_async(dispatch_get_main_queue(), ^{
// switch back to the main thread to update your UI
});
});
這個方法把那些已經(jīng)存在的cell從隊列中排除白修，或者在必要時使用先前注冊的nib或者class創(chuàng)造新的cell。如果沒有可重用的cell重斑，你也沒有注冊一個class或者nib的話兵睛，這個方法返回nil。
3.盡量把views設(shè)置為透明
如果你有透明的Views你應(yīng)該設(shè)置它們的opaque屬性為YES窥浪。原因是這會使系統(tǒng)用一個最優(yōu)的方式渲染這些views卤恳。這個簡單的屬性在IB或者代碼里都可以設(shè)定。
Apple的文檔對于為圖片設(shè)置透明屬性的描述是：
(opaque)這個屬性給渲染系統(tǒng)提供了一個如何處理這個view的提示寒矿。如果設(shè)為YES突琳，渲染系統(tǒng)就認(rèn)為這個view是完全不透明的，這使得渲染系統(tǒng)優(yōu)化一些渲染過程和提高性能符相。如果設(shè)置為NO拆融，渲染系統(tǒng)正常地和其它內(nèi)容組成這個View蠢琳。默認(rèn)值是YES。
在相對比較靜止的畫面中镜豹，設(shè)置這個屬性不會有太大影響傲须。然而當(dāng)這個view嵌在scroll view里邊，或者是一個復(fù)雜動畫的一部分趟脂，不設(shè)置這個屬性的話會在很大程度上影響app的性能泰讽。
你可以在模擬器中用Debug\Color Blended Layers選項來發(fā)現(xiàn)哪些view沒有被設(shè)置為opaque。目標(biāo)就是昔期，能設(shè)為opaque的就全設(shè)為opaque!
這里有一點(diǎn)需要注意已卸，只要是有中文字符的Label，哪怕你設(shè)置成不透明硼一，模擬器中這個Label依然會變紅累澡，這個猜測是字符繪制的時候出的問題，這個目前沒找到好的解決方法般贼。
4.避免過于龐大的XIB
iOS5中加入的Storyboards(分鏡)正在快速取代XIB愧哟。然而XIB在一些場景中仍然很有用。比如你的app需要適應(yīng)iOS5之前的設(shè)備哼蛆，或者你有一個自定義的可重用的view,你就不可避免地要用到他們蕊梧。
如果你不得不XIB的話，使他們盡量簡單腮介。嘗試為每個Controller配置一個單獨(dú)的XIB肥矢，盡可能把一個View Controller的view層次結(jié)構(gòu)分散到單獨(dú)的XIB中去。
需要注意的是萤厅，當(dāng)你加載一個XIB的時候所有內(nèi)容都被放在了內(nèi)存里橄抹，包括任何圖片。如果有一個不會即刻用到的view惕味，你這就是在浪費(fèi)寶貴的內(nèi)存資源了楼誓。Storyboards就是另一碼事兒了，storyboard僅在需要時實例化一個view controller.
當(dāng)家在XIB是名挥，所有圖片都被chache疟羹，如果你在做OS X開發(fā)的話，聲音文件也是禀倔。Apple在相關(guān)文檔中的記述是：
當(dāng)你加載一個引用了圖片或者聲音資源的nib時榄融，nib加載代碼會把圖片和聲音文件寫進(jìn)內(nèi)存。在OS X中救湖，圖片和聲音資源被緩存在named cache中以便將來用到時獲取愧杯。在iOS中，僅圖片資源會被存進(jìn)named caches鞋既。取決于你所在的平臺力九，使用NSImage 或UIImage的imageNamed:方法來獲取圖片資源.
這個問題我深有體會耍铜，用xib寫的界面加載速度比直接用代碼寫的要慢好多。
5.不要阻塞主線程
永遠(yuǎn)不要使主線程承擔(dān)過多跌前。因為UIKit在主線程上做所有工作棕兼，渲染，管理觸摸反應(yīng)抵乓，回應(yīng)輸入等都需要在它上面完成伴挚。一直使用主線程的風(fēng)險就是如果你的代碼真的block了主線程，你的app會失去反應(yīng)灾炭。大部分阻礙主進(jìn)程的情形是你的app在做一些牽涉到讀寫外部資源的I/O操作茎芋，比如存儲或者網(wǎng)絡(luò)。你可以使用NSURLConnection異步地做網(wǎng)絡(luò)操作:
+ (void)sendAsynchronousRequest:(NSURLRequest *)request queue:(NSOperationQueue*)queue completionHandler:(void (^)(NSURLResponse*, NSData*, NSError*))handler
或者使用像AFNetworking這樣的框架來異步地做這些操作咆贬。
如果你需要做其它類型的需要耗費(fèi)巨大資源的操作(比如時間敏感的計算或者存儲讀寫)那就用 Grand Central Dispatch败徊，或者NSOperation和 NSOperationQueues.
下面代碼是使用GCD的模板
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
// switch to a background thread and perform your expensive operation
dispatch_async(dispatch_get_main_queue(), ^{
// switch back to the main thread to update your UI
});
});
6. 在Image Views中調(diào)整圖片大小
如果要在UIImageView中顯示一個來自bundle的圖片帚呼，你應(yīng)保證圖片的大小和UIImageView的大小相同掏缎。在運(yùn)行中縮放圖片是很耗費(fèi)資源的，特別是UIImageView嵌套在UIScrollView中的情況下煤杀。
如果圖片是從遠(yuǎn)端服務(wù)加載的你不能控制圖片大小眷蜈，比如在下載前調(diào)整到合適大小的話，你可以在下載完成后沈自，最好是用background thread酌儒，縮放一次，然后在UIImageView中使用縮放后的圖片枯途。
7. 選擇正確的Collection
學(xué)會選擇對業(yè)務(wù)場景最合適的類或者對象是寫出能效高的代碼的基礎(chǔ)忌怎。當(dāng)處理collections時這句話尤其正確。
一些常見collection的總結(jié)：
- Arrays: 有序的一組值酪夷。使用index來lookup很快榴啸，使用value lookup很慢，插入/刪除很慢晚岭。
- Dictionaries: 存儲鍵值對鸥印。用鍵來查找比較快。
- Sets: 無序的一組值坦报。用值來查找很快库说，插入/刪除很快。因為Set用到了哈希片择，所以插入刪除查找速度比Array快很多
8. 打開gzip壓縮
大量app依賴于遠(yuǎn)端資源和第三方API潜的，你可能會開發(fā)一個需要從遠(yuǎn)端下載XML, JSON, HTML或者其它格式的app。
問題是我們的目標(biāo)是移動設(shè)備字管，因此你就不能指望網(wǎng)絡(luò)狀況有多好啰挪。一個用戶現(xiàn)在還在edge網(wǎng)絡(luò)疏咐，下一分鐘可能就切換到了3G。不論什么場景脐供，你肯定不想讓你的用戶等太長時間浑塞。
減小文檔的一個方式就是在服務(wù)端和你的app中打開gzip。這對于文字這種能有更高壓縮率的數(shù)據(jù)來說會有更顯著的效用政己。
好消息是酌壕，iOS已經(jīng)在NSURLConnection中默認(rèn)支持了gzip壓縮，當(dāng)然AFNetworking這些基于它的框架亦然歇由。像Google App Engine這些云服務(wù)提供者也已經(jīng)支持了壓縮輸出卵牍。
9. 重用和延遲加載(lazy load) Views
- 更多的view意味著更多的渲染，也就是更多的CPU和內(nèi)存消耗沦泌，對于那種嵌套了很多view在UIScrollView里邊的app更是如此糊昙。
- 這里我們用到的技巧就是模仿UITableView和UICollectionView的操作:不要一次創(chuàng)建所有的subview，而是當(dāng)需要時才創(chuàng)建谢谦，當(dāng)它們完成了使命释牺，把他們放進(jìn)一個可重用的隊列中。
這樣的話你就只需要在滾動發(fā)生時創(chuàng)建你的views回挽，避免了不劃算的內(nèi)存分配没咙。
創(chuàng)建views的能效問題也適用于你app的其它方面。想象一下一個用戶點(diǎn)擊一個按鈕的時候需要呈現(xiàn)一個view的場景千劈。有兩種實現(xiàn)方法：
- 創(chuàng)建并隱藏這個view當(dāng)這個screen加載的時候祭刚，當(dāng)需要時顯示它；
- 當(dāng)需要時才創(chuàng)建并展示墙牌。
每個方案都有其優(yōu)缺點(diǎn)涡驮。用第一種方案的話因為你需要一開始就創(chuàng)建一個view并保持它直到不再使用，這就會更加消耗內(nèi)存喜滨。然而這也會使你的app操作更敏感因為當(dāng)用戶點(diǎn)擊按鈕的時候它只需要改變一下這個view的可見性捉捅。
第二種方案則相反-消耗更少內(nèi)存，但是會在點(diǎn)擊按鈕的時候比第一種稍顯卡頓鸿市。
10. Cache, Cache, 還是Cache!注意你的緩存
一個極好的原則就是锯梁，緩存所需要的，也就是那些不大可能改變但是需要經(jīng)常讀取的東西焰情。
我們能緩存些什么呢陌凳？一些選項是，遠(yuǎn)端服務(wù)器的響應(yīng)内舟，圖片合敦，甚至計算結(jié)果，比如UITableView的行高验游。
NSURLConnection默認(rèn)會緩存資源在內(nèi)存或者存儲中根據(jù)它所加載的HTTP Headers充岛。你甚至可以手動創(chuàng)建一個NSURLRequest然后使它只加載緩存的值保檐。
下面是一個可用的代碼段，你可以可以用它去為一個基本不會改變的圖片創(chuàng)建一個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"];
return request;
}
注意你可以通過 NSURLConnection 獲取一個URL request崔梗， AFNetworking也一樣的夜只。這樣你就不必為采用這條tip而改變所有的networking代碼了。 如果你需要緩存其它不是HTTP Request的東西蒜魄，你可以用NSCache扔亥。
NSCache和NSDictionary類似，不同的是系統(tǒng)回收內(nèi)存的時候它會自動刪掉它的內(nèi)容谈为。
11.權(quán)衡渲染方法
在iOS中可以有很多方法做出漂亮的按鈕旅挤。你可以用整幅的圖片，可調(diào)大小的圖片伞鲫，或者可以用CALayer粘茄， CoreGraphics甚至OpenGL來畫它們。當(dāng)然每個不同的解決方法都有不同的復(fù)雜程度和相應(yīng)的性能秕脓。
簡單來說柒瓣，就是用事先渲染好的圖片更快一些，因為如此一來iOS就免去了創(chuàng)建一個圖片再畫東西上去然后顯示在屏幕上的程序撒会。問題是你需要把所有你需要用到的圖片放到app的bundle里面嘹朗，這樣就增加了體積–這就是使用可變大小的圖片更好的地方了:你可以省去一些不必要的空間师妙，也不需要再為不同的元素(比如按鈕)來做不同的圖诵肛。
然而，使用圖片也意味著你失去了使用代碼調(diào)整圖片的機(jī)動性默穴，你需要一遍又一遍不斷地重做他們怔檩，這樣就很浪費(fèi)時間了，而且你如果要做一個動畫效果蓄诽，雖然每幅圖只是一些細(xì)節(jié)的變化你就需要很多的圖片造成bundle大小的不斷增大薛训。
總得來說，你需要權(quán)衡一下利弊仑氛，到底是要性能能還是要bundle保持合適的大小乙埃。
12.處理內(nèi)存警告
一旦系統(tǒng)內(nèi)存過低，iOS會通知所有運(yùn)行中app锯岖。在官方文檔中是這樣記述:
如果你的app收到了內(nèi)存警告介袜，它就需要盡可能釋放更多的內(nèi)存。最佳方式是移除對緩存出吹，圖片object和其他一些可以重創(chuàng)建的objects的strong references.
幸運(yùn)的是遇伞，UIKit提供了幾種收集低內(nèi)存警告的方法:
- 在app delegate中使用applicationDidReceiveMemoryWarning:的方法
- 在你的自定義UIViewController的子類(subclass)中覆蓋didReceiveMemoryWarning
- 注冊并接收 UIApplicationDidReceiveMemoryWarningNotification的通知
一旦收到這類通知，你就需要釋放任何不必要的內(nèi)存使用捶牢。
例如鸠珠，UIViewController的默認(rèn)行為是移除一些不可見的view巍耗，它的一些子類則可以補(bǔ)充這個方法，刪掉一些額外的數(shù)據(jù)結(jié)構(gòu)渐排。一個有圖片緩存的app可以移除不在屏幕上顯示的圖片炬太。
這樣對內(nèi)存警報的處理是很必要的，若不重視驯耻，你的app就可能被系統(tǒng)殺掉娄琉。
然而，當(dāng)你一定要確認(rèn)你所選擇的object是可以被重現(xiàn)創(chuàng)建的來釋放內(nèi)存吓歇。一定要在開發(fā)中用模擬器中的內(nèi)存提醒模擬去測試一下孽水。
當(dāng)然，現(xiàn)在iOS設(shè)備運(yùn)行內(nèi)存越來越大城看，這一點(diǎn)很難出現(xiàn)了女气。
13.重用大開銷對象
一些objects的初始化很慢，比如NSDateFormatter和NSCalendar测柠。然而炼鞠，你又不可避免地需要使用它們，比如從JSON或者XML中解析數(shù)據(jù)轰胁。
想要避免使用這個對象的瓶頸你就需要重用他們谒主，可以通過添加屬性到你的class里或者創(chuàng)建靜態(tài)變量來實現(xiàn)。
注意如果你要選擇第二種方法赃阀，對象會在你的app運(yùn)行時一直存在于內(nèi)存中霎肯，和單例(singleton)很相似。
下面的代碼說明了使用一個屬性來延遲加載一個date formatter. 第一次調(diào)用時它會創(chuàng)建一個新的實例榛斯，以后的調(diào)用則將返回已經(jīng)創(chuàng)建的實例：
// 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è)置一個NSDateFormatter的速度差不多是和創(chuàng)建新的一樣慢的！所以如果你的app需要經(jīng)常進(jìn)行日期格式處理的話驮俗，你會從這個方法中得到不小的性能提升懂缕。
14. 使用Sprite Sheets
Sprite sheet可以讓渲染速度加快，甚至比標(biāo)準(zhǔn)的屏幕渲染方法節(jié)省內(nèi)存王凑。
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)是開銷很大的索烹。
比如你需要數(shù)據(jù)來展示一個table view,最好直接從服務(wù)器取array結(jié)構(gòu)的數(shù)據(jù)以避免額外的中間數(shù)據(jù)結(jié)構(gòu)改變工碾。
類似的，如果需要從特定key中取數(shù)據(jù)术荤，那么就使用鍵值對的dictionary倚喂。
這一點(diǎn)在處理大量數(shù)據(jù)的時候極為重要，用空間換時間的方法也許是極好的。
16.選擇正確的數(shù)據(jù)格式
從app和網(wǎng)絡(luò)服務(wù)間傳輸數(shù)據(jù)有很多方案端圈，最常見的就是JSON和XML焦读。你需要選擇對你的app來說最合適的一個。
解析JSON會比XML更快一些舱权，JSON也通常更小更便于傳輸矗晃。從iOS5起有了官方內(nèi)建的JSON deserialization就更加方便使用了。
但是XML也有XML的好處宴倍，比如使用SAX來解析XML就像解析本地文件一樣张症，你不需像解析json一樣等到整個文檔下載完成才開始解析。當(dāng)你處理很大的數(shù)據(jù)的時候就會極大地減低內(nèi)存消耗和增加性能鸵贬。
現(xiàn)在基本上都是JSON了俗他。
17.正確設(shè)定背景圖片
在View里放背景圖片就像很多其它iOS編程一樣有很多方法:使用UIColor的 colorWithPatternImage來設(shè)置背景色；
在view中添加一個UIImageView作為一個子View阔逼。
如果你使用全畫幅的背景圖兆衅，你就必須使用UIImageView因為UIColor的colorWithPatternImage是用來創(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];
如果你用小圖平鋪來創(chuàng)建背景嗜浮，你就需要用UIColor的colorWithPatternImage來做了羡亩，它會更快地渲染也不會花費(fèi)很多內(nèi)存：
self.view.backgroundColor = [UIColor colorWithPatternImage:[UIImage imageNamed:@"background"]];
18. 減少使用Web特性
UIWebView很有用，用它來展示網(wǎng)頁內(nèi)容或者創(chuàng)建UIKit很難做到的動畫效果是很簡單的一件事危融。
但是你可能有注意到UIWebView并不像驅(qū)動Safari的那么快畏铆。這是由于以JIT compilation為特色的Webkit的Nitro Engine的限制。
所以想要更高的性能你就要調(diào)整下你的HTML了吉殃。第一件要做的事就是盡可能移除不必要的JavaScript辞居，避免使用過大的框架。能只用原生js就更好了寨腔。
另外速侈，盡可能異步加載例如用戶行為統(tǒng)計script這種不影響頁面表達(dá)的javascript。
最后迫卢，永遠(yuǎn)要注意你使用的圖片，保證圖片的符合你使用的大小冶共。使用Sprite sheet提高加載速度和節(jié)約內(nèi)存乾蛤。
19. 設(shè)定Shadow Path
如何在一個View或者一個layer上加一個shadow呢，QuartzCore框架是很多開發(fā)者的選擇：
UIView *view = [[UIView alloc] init];
view.layer.shadowOffset = CGSizeMake(-1.0f, 1.0f);
view.layer.shadowRadius = 5.0f;
view.layer.shadowOpacity = 0.6;
看起來很簡單捅僵，對吧家卖。可是庙楚，壞消息是使用這個方法也有它的問題… Core Animation不得不先在后臺得出你的圖形并加好陰影然后才渲染上荡，這開銷是很大的。
使用shadowPath的話就避免了這個問題：
view.layer.shadowPath = [[UIBezierPath bezierPathWithRect:view.bounds] CGPath];
使用shadow path的話iOS就不必每次都計算如何渲染，它使用一個預(yù)先計算好的路徑酪捡。但問題是自己計算path的話可能在某些View中比較困難叁征，且每當(dāng)view的frame變化的時候你都需要去update shadow path.
我更喜歡用CALayer自己畫一個陰影出來，這樣可以設(shè)置陰影光柵化逛薇，節(jié)省大量CPU的運(yùn)算捺疼，壞處就是比較消耗內(nèi)存。因為如果給view的layer設(shè)置光柵化的話整個View都會變得模糊永罚。
20. 優(yōu)化Table View
Table view需要有很好的滾動性能啤呼，不然用戶會在滾動過程中發(fā)現(xiàn)動畫的瑕疵。
為了保證table view平滑滾動呢袱，確保你采取了以下的措施:
正確使用reuseIdentifier來重用cells
盡量使所有的view opaque官扣，包括cell自身
避免漸變，圖片縮放羞福，后臺選人
緩存行高
如果cell內(nèi)現(xiàn)實的內(nèi)容來自web醇锚，使用異步加載，緩存請求結(jié)果
使用shadowPath來畫陰影
減少subviews的數(shù)量
盡量不使用cellForRowAtIndexPath:坯临，如果你需要用到它焊唬，只用一次然后緩存結(jié)果
使用正確的數(shù)據(jù)結(jié)構(gòu)來存儲數(shù)據(jù)
使用rowHeight, sectionFooterHeight和 sectionHeaderHeight來設(shè)定固定的高，不要請求delegate
21.選擇正確的數(shù)據(jù)存儲選項
當(dāng)存儲大塊數(shù)據(jù)時你會怎么做看靠？
你有很多選擇赶促，比如：
使用NSUerDefaults
使用XML, JSON, 或者 plist
使用NSCoding存檔
使用類似SQLite的本地SQL數(shù)據(jù)庫
使用 Core Data
NSUserDefaults的問題是什么？雖然它很nice也很便捷挟炬，但是它只適用于小數(shù)據(jù)鸥滨，比如一些簡單的布爾型的設(shè)置選項，再大點(diǎn)你就要考慮其它方式了
XML這種結(jié)構(gòu)化檔案呢谤祖？總體來說婿滓，你需要讀取整個文件到內(nèi)存里去解析，這樣是很不經(jīng)濟(jì)的粥喜。使用SAX又是一個很麻煩的事情凸主。
NSCoding？不幸的是额湘，它也需要讀寫文件卿吐，所以也有以上問題。
在這種應(yīng)用場景下锋华，使用SQLite 或者 Core Data比較好嗡官。使用這些技術(shù)你用特定的查詢語句就能只加載你需要的對象。
在性能層面來講毯焕，SQLite和Core Data是很相似的衍腥。他們的不同在于具體使用方法。Core Data代表一個對象的graph model，但SQLite就是一個DBMS婆咸。Apple在一般情況下建議使用Core Data竹捉，但是如果你有理由不使用它，那么就去使用更加底層的SQLite吧擅耽。
如果你使用SQLite活孩，你可以用FMDB(https://GitHub.com/ccgus/fmdb)這個庫來簡化SQLite的操作，這樣你就不用花很多經(jīng)歷了解SQLite的C API了乖仇。
23. 使用Autorelease Pool
NSAutoreleasePool負(fù)責(zé)釋放block中的autoreleased objects憾儒。一般情況下它會自動被UIKit調(diào)用。但是有些狀況下你也需要手動去創(chuàng)建它乃沙。
假如你創(chuàng)建很多臨時對象起趾，你會發(fā)現(xiàn)內(nèi)存一直在減少直到這些對象被release的時候。這是因為只有當(dāng)UIKit用光了autorelease pool的時候memory才會被釋放警儒。好消息是你可以在你自己的@autoreleasepool里創(chuàng)建臨時的對象來避免這個行為：
NSArray *urls = <# An array of file URLs #>;
for(NSURL *url in urls) {
@autoreleasepool {
NSError *error;
NSString *fileContents = [NSString stringWithContentsOfURL:url encoding:NSUTF8StringEncoding error:&error];
/* Process the string, creating and autoreleasing more objects. */
}
}
24. 選擇是否緩存圖片
常見的從bundle中加載圖片的方式有兩種训裆，一個是用imageNamed，二是用imageWithContentsOfFile蜀铲，第一種比較常見一點(diǎn)边琉。
既然有兩種類似的方法來實現(xiàn)相同的目的，那么他們之間的差別是什么呢记劝？
imageNamed的優(yōu)點(diǎn)是當(dāng)加載時會緩存圖片变姨。imageNamed的文檔中這么說:這個方法用一個指定的名字在系統(tǒng)緩存中查找并返回一個圖片對象如果它存在的話。如果緩存中沒有找到相應(yīng)的圖片厌丑，這個方法從指定的文檔中加載然后緩存并返回這個對象定欧。
相反的，imageWithContentsOfFile僅加載圖片怒竿。
下面的代碼說明了這兩種方法的用法:
UIImage *img = [UIImage imageNamed:@"myImage"];// caching
// or
UIImage *img = [UIImage imageWithContentsOfFile:@"myImage"];// no caching
那么我們應(yīng)該如何選擇呢砍鸠？
如果你要加載一個大圖片而且是一次性使用，那么就沒必要緩存這個圖片耕驰，用imageWithContentsOfFile足矣爷辱，這樣不會浪費(fèi)內(nèi)存來緩存它。
然而耍属，在圖片反復(fù)重用的情況下imageNamed是一個好得多的選擇托嚣。
25. 避免日期格式轉(zhuǎn)換
如果你要用NSDateFormatter來處理很多日期格式，應(yīng)該小心以待厚骗。就像先前提到的，任何時候重用NSDateFormatters都是一個好的實踐兢哭。
然而领舰，如果你需要更多速度，那么直接用C是一個好的方案。Sam Soffes有一個不錯的帖子(http://soff.es/how-to-drastically-improve-your-app-with-an-afternoon-and-instruments)里面有一些可以用來解析ISO-8601日期字符串的代碼冲秽，簡單重寫一下就可以拿來用了舍咖。
嗯，直接用C來搞锉桑，看起來不錯了排霉，但是你相信嗎，我們還有更好的方案民轴！
如果你可以控制你所處理的日期格式攻柠，盡量選擇Unix時間戳。你可以方便地從時間戳轉(zhuǎn)換到NSDate:
- (NSDate*)dateFromUnixTimestamp:(NSTimeInterval)timestamp {
return[NSDate dateWithTimeIntervalSince1970:timestamp];
}
這樣會比用C來解析日期字符串還快后裸！需要注意的是瑰钮，許多web API會以微秒的形式返回時間戳，因為這種格式在javascript中更方便使用微驶。記住用dateFromUnixTimestamp之前除以1000就好了浪谴。
