前言

這篇文章介紹了作者開發工作中總結的25個iOS開發tips, 多年之前讀過這篇文章，收益良多，基本每一個tips在我的應用開發過程中都使用過。今天把這篇文章重新整理轉發下，與大家一起學習，不論你處於什麼開發階段，這些tips都值得你反覆熟悉。

介紹

本文來自iOS Tutorial Team 的 Marcelo Fabri，他是Movile的一名 iOS 程式設計師。

效能對 iOS 應用的開發尤其重要，如果你的應用失去反應或者很慢，失望的使用者會把他們的失望寫滿App Store的評論。然而由於iOS裝置的限制，有時搞好效能是一件難事。開發過程中你會有很多需要注意的事項，你也很容易在做出選擇時忘記考慮效能影響。

這正是我寫下這篇文章的原因。這篇文章以一個方便檢視的核對錶的形式整合了你可以用來提升你app效能的25條建議和技巧。

請耐心讀完這篇文章，為你未來的app提個速！

注意：每在優化程式碼之前，你都要注意一個問題，不要養成”預優化”程式碼的錯誤習慣。時常使用Instruments去profile你的程式碼來發現需要提升的方面。Matt Galloway寫過一篇很棒的如何利用Instruments來優化程式碼的文章。

還要注意的是，這裡列出的其中一些建議是有代價的，所建議的方式會提升app的速度或者使它更加高效，但也可能需要花很多功夫去應用或者使程式碼變得更加複雜，所以要仔細選擇。

1. 用ARC管理記憶體

ARC(Automatic Reference Counting, 自動引用計數)和iOS5一起釋出，它避免了最常見的也就是經常是由於我們忘記釋放記憶體所造成的記憶體洩露。它自動為你管理retain和release的過程，所以你就不必去手動干預了。

下面是你會經常用來去建立一個View的程式碼段:

UIView *view = [[UIView alloc] init];

// ...
[self.view addSubview:view];
[view release];

忘掉程式碼段結尾的release簡直像記得吃飯一樣簡單。而ARC會自動在底層為你做這些工作。

除了幫你避免記憶體洩露，ARC還可以幫你提高效能，它能保證釋放掉不再需要的物件的記憶體。這都啥年代了，你應該在你的所有專案裡使用ARC!

博主發現很多公司，因為專案開發的時間比較早期，還沒有ARC, 使用的是MRC, 後期的不斷擴充套件中因為架構的問題的考慮，沒有使用ARC，這種現象還是有一些的。從長遠考慮，趕快換上ARC吧！

ARC當然不能為你排除所有記憶體洩露的可能性。由於阻塞, retain 週期, 管理不完善的CoreFoundation object(還有C結構)或者就是程式碼太爛依然能導致記憶體洩露。

2. 在正確的地方使用 reuseIdentifier

一個開發中常見的錯誤就是沒有給UITableViewCells， UICollectionViewCells（這兩貨的使用像極了！），甚至是UITableViewHeaderFooterViews設定正確的reuseIdentifier。

為了效能最優化，table view用 tableView:cellForRowAtIndexPath: 為rows分配cells的時候，它的資料應該重用自UITableViewCell。 一個table view維持一個佇列的資料可重用的UITableViewCell物件。

不使用reuseIdentifier的話，每顯示一行table view就不得不設定全新的cell。這對效能的影響可是相當大的，尤其會使app的滾動體驗大打折扣。

自iOS6起，除了UICollectionView的cells和補充views，你也應該在header和footer views中使用reuseIdentifiers。

想要使用reuseIdentifiers的話，在一個table view中新增一個新的cell時在data source object中新增這個方法：

//可重用cell標識， ReuseCell要與cell的indentifier相同
static NSString *CellIdentifier = @"ReuseCell";

//在緩衝池中呼叫可重用cell
UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier forIndexPath:indexPath];

這個方法把那些已經存在的cell從佇列中排除，或者在必要時使用先前註冊的nib或者class創造新的cell。如果沒有可重用的cell，你也沒有註冊一個class或者nib的話，這個方法返回nil。

3.儘量把views設定為不透明

如果你有不透明的Views，你應該設定它們的opaque屬性為YES。

原因是這會使系統用一個最優的方式渲染這些views。這個簡單的屬性在IB或者程式碼裡都可以設定。

Apple的文件對於為圖片設定不透明屬性的描述是：

(opaque)這個屬性給渲染系統提供了一個如何處理這個view的提示。如果設為YES， 渲染系統就認為這個view是完全不透明的，這使得渲染系統優化一些渲染過程和提高效能。如果設定為NO，渲染系統正常地和其它內容組成這個View。預設值是YES。

在相對比較靜止的畫面中，設定這個屬性不會有太大影響。然而當這個view嵌在scroll view裡邊，或者是一個複雜動畫的一部分，不設定這個屬性的話會在很大程度上影響app的效能。

你可以在模擬器中用Debug\Color Blended Layers選項來發現哪些view沒有被設定為opaque。

目標就是，能設為opaque的就全設為opaque!

4. 避免過於龐大的XIB

iOS5中加入的Storyboards(分鏡)正在快速取代XIB。然而XIB在一些場景中仍然很有用。比如你的app需要適應iOS5之前的裝置，或者你有一個自定義的可重用的view,你就不可避免地要用到他們。

如果你不得不XIB的話，使他們儘量簡單。嘗試為每個Controller配置一個單獨的XIB，儘可能把一個View Controller的view層次結構分散到單獨的XIB中去。

需要注意的是，當你載入一個XIB的時候所有內容都被放在了記憶體裡，包括任何圖片。如果有一個不會即刻用到的view，你這就是在浪費寶貴的記憶體資源了。Storyboards就是另一碼事兒了，storyboard僅在需要時例項化一個view controller.

當載入XIB時，所有圖片都被chache，如果你在做OS X開發的話，聲音檔案也是。Apple在相關文件中的記述是：

當你載入一個引用了圖片或者聲音資源的nib時，nib載入程式碼會把圖片和聲音檔案寫進記憶體。在OS X中，圖片和聲音資源被快取在named cache中以便將來用到時獲取。在iOS中，僅圖片資源會被存進named caches。取決於你所在的平臺，使用NSImage 或UIImage 的imageNamed:方法來獲取圖片資源。

很明顯，同樣的事情也發生在storyboards中，但我並沒有找到任何支援這個結論的文件。如果你瞭解這個操作，寫信給我！

想要了解更多關於storyboards的內容的話你可以看看 Matthijs Hollemans的Beginning Storyboards in iOS 5 Part 1 和 Part 2

5. 不要阻塞主執行緒

永遠不要使主執行緒承擔過多。因為UIKit在主執行緒上做所有工作，渲染，管理觸控反應，迴應輸入等都需要在它上面完成。

一直使用主執行緒的風險就是如果你的程式碼真的block了主執行緒，你的app會失去反應。這正是在App Store中拿到一顆星的捷徑 :]

大部分阻礙主程序的情形是你的app在做一些牽涉到讀寫外部資源的I/O操作，比如儲存或者網路。

你可以使用NSURLConnection非同步地做網路操作:

+ (void)sendAsynchronousRequest:(NSURLRequest *)request queue:(NSOperationQueue *)queue completionHandler:(void (^)(NSURLResponse*, NSData*, NSError*))handler

或者使用像 AFNetworking這樣的框架來非同步地做這些操作。

如果你需要做其它型別的需要耗費巨大資源的操作(比如時間敏感的計算或者儲存讀寫)那就用 Grand Central Dispatch，或者 NSOperation 和 NSOperationQueues.

下面程式碼是使用GCD的模板

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{

    //切換到子執行緒非同步執行一些開銷比較大的操作

    dispatch_async(dispatch_get_main_queue(), ^{
    //切換到主執行緒，更新UI等操作

    });
});

發現程式碼中有一個巢狀的dispatch_async嗎？

這是因為任何UIKit相關的程式碼需要在主執行緒上進行。

如果你對 NSOperation 或者GCD 的細節感興趣的話，看看Ray Wenderlich的 Multithreading and Grand Central Dispatch on iOS for Beginners， 還有 Soheil Azarpour 的 How To Use NSOperations and NSOperationQueues 教程。

6. 在ImageView中調整圖片大小

如果要在UIImageView中顯示一個來自bundle的圖片，你應保證圖片的大小和UIImageView的大小相同。

在執行中縮放圖片是很耗費資源的，特別是UIImageView巢狀在UIScrollView中的情況下。

如果圖片是從遠端服務載入的你不能控制圖片大小，比如在下載前調整到合適大小的話，你可以在下載完成後，最好是用background thread，縮放一次，然後在UIImageView中使用縮放後的圖片。

7. 選擇正確的Collection

學會選擇對業務場景最合適的類或者物件是寫出能效高的程式碼的基礎。當處理collections時這句話尤其正確。

Apple有一個 Collections Programming Topics的文件詳盡介紹了可用的classes間的差別和你該在哪些場景中使用它們。這對於任何使用collections的人來說是一個必讀的文件。

呵呵，我就知道你因為太長沒看…這是一些常見collection的總結：

Arrays: 有序的一組值。使用index來lookup很快，使用value lookup很慢， 插入/刪除很慢。
Dictionaries: 儲存鍵值對。 用鍵來查詢比較快。
Sets: 無序的一組值。用值來查詢很快，插入/刪除很快。

8. 開啟gzip壓縮

大量app依賴於遠端資源和第三方API，你可能會開發一個需要從遠端下載XML, JSON, HTML或者其它格式的app。

問題是我們的目標是移動裝置，因此你就不能指望網路狀況有多好。一個使用者現在還在edge網路，下一分鐘可能就切換到了3G。不論什麼場景，你肯定不想讓你的使用者等太長時間。

減小文件的一個方式就是在服務端和你的app中開啟gzip。這對於文字這種能有更高壓縮率的資料來說會有更顯著的效用。

好訊息是，iOS已經在NSURLConnection中預設支援了gzip壓縮，當然AFNetworking這些基於它的框架亦然。像Google App Engine這些雲服務提供者也已經支援了壓縮輸出。

如果你不知道如何利用Apache或者IIS(伺服器)來開啟gzip，可以讀下這篇文章。

9. 重用和延遲載入(lazy load) Views

更多的view意味著更多的渲染，也就是更多的CPU和記憶體消耗，對於那種嵌套了很多view在UIScrollView裡邊的app更是如此。

這裡我們用到的技巧就是模仿UITableView和UICollectionView的操作:

不要一次建立所有的subview，而是當需要時才建立，當它們完成了使命，把他們放進一個可重用的佇列中。

這樣的話你就只需要在滾動發生時建立你的views，避免了不划算的記憶體分配。

建立views的能效問題也適用於你app的其它方面。想象一下一個使用者點選一個按鈕的時候需要呈現一個view的場景。有兩種實現方法：

1. 建立並隱藏這個view當這個screen載入的時候，當需要時顯示它；
2. 當需要時才建立並展示。

每個方案都有其優缺點。

• 用第一種方案的話因為你需要一開始就建立一個view並保持它直到不再使用，這就會更加消耗記憶體。然而這也會使你的app操作更敏感因為當用戶點選按鈕的時候它只需要改變一下這個view的可見性。

• 第二種方案則相反-消耗更少記憶體，但是會在點選按鈕的時候比第一種稍顯示卡頓。

10. Cache, Cache, 還是Cache!

一個極好的原則就是，快取所需要的，也就是那些不大可能改變但是需要經常讀取的東西。

我們能快取些什麼呢？一些選項是:

遠端伺服器的響應，圖片，甚至計算結果，比如UITableView的行高。

NSURLConnection會根據它所載入的HTTP Headers預設快取資源在記憶體或者儲存中。你甚至可以手動建立一個NSURLRequest然後使它只加載快取的值。

下面是一個可用的程式碼段，你可以用它去為一個基本不會改變的圖片建立一個NSURLRequest並快取它：

+ (NSMutableURLRequest *)imageRequestWithURL:(NSURL *)url
{
    NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:url];

    //新增請求的快取策略,保證每次都是優先載入快取圖片
    request.cachePolicy = NSURLRequestReturnCacheDataElseLoad; 

    request.HTTPShouldHandleCookies = NO;
    request.HTTPShouldUsePipelining = YES;
    [request addValue:@"image/*" forHTTPHeaderField:@"Accept"];

    return request;
}

注意你可以通過 NSURLConnection 獲取一個URL request， AFNetworking也一樣的。這樣你就不必為採用這條tip而改變所有的networking程式碼了。

如果你需要快取其它不是HTTP Request的東西，你可以用NSCache。

• NSCache和NSDictionary類似，不同的是系統回收記憶體的時候它會自動刪掉它的內容。 Mattt Thompson有一篇很棒的關於它的文章：:http://nshipster.com/nscache/

• 如果你對HTTP感興趣可以讀下Google的這篇 best-practices document on HTTP caching。

11. 權衡渲染方法

在iOS中可以有很多方法做出漂亮的按鈕。你可以用整幅的圖片，可調大小的圖片，uozhe可以用CALayer， CoreGraphics甚至OpenGL來畫它們。

當然每個不同的解決方法都有不同的複雜程度和相應的效能。有一篇Apple UIKit team中的一員Andy Matuschak推薦過的很棒的關於graphic效能的帖子很值得一讀。

簡單來說，就是用事先渲染好的圖片更快一些，因為如此一來iOS就免去了建立一個圖片再畫東西上去然後顯示在螢幕上的程式。

問題是你需要把所有你需要用到的圖片放到app的bundle裡面，這樣就增加了體積 。

這就是使用可變大小的圖片更好的地方了: 你可以省去一些不必要的空間，也不需要再為不同的元素(比如按鈕)來做不同的圖。

然而，使用圖片也意味著你失去了使用程式碼調整圖片的機動性，你需要一遍又一遍不斷地重做他們，這樣就很浪費時間了，而且你如果要做一個動畫效果，雖然每幅圖只是一些細節的變化你就需要很多的圖片造成bundle大小的不斷增大。

總得來說，你需要權衡一下利弊，到底是要效能能還是要bundle保持合適的大小。

12. 處理記憶體警告

一旦系統記憶體過低，iOS會通知所有執行中app。在官方文件中是這樣記述:

如果你的app收到了記憶體警告，它就需要儘可能釋放更多的記憶體。最佳方式是移除對快取，圖片object和其他一些可以重建立的objects的strong references.

幸運的是，UIKit提供了幾種收集低記憶體警告的方法:

在app delegate中使用applicationDidReceiveMemoryWarning:
的方法在你的自定義UIViewController的子類(subclass)中覆蓋didReceiveMemoryWarning。
註冊並接收 UIApplicationDidReceiveMemoryWarningNotification 的通知
的物件一旦收到這類通知，你就需要釋放任何不必要的記憶體使用。

例如，UIViewController的預設行為是移除一些不可見的view， 它的一些子類則可以補充這個方法，刪掉一些額外的資料結構。一個有圖片快取的app可以移除不在螢幕上顯示的圖片。

這樣對記憶體警報的處理是很必要的，若不重視，你的app就可能被系統殺掉。

然而，當你一定要確認你所選擇的object是可以被重現建立的來釋放記憶體。一定要在開發中用模擬器中的記憶體提醒模擬去測試一下。

13. 重用大開銷物件

一些objects的初始化很慢，比如NSDateFormatter和NSCalendar。然而，你又不可避免地需要使用它們，比如從JSON或者XML中解析資料。

想要避免使用這個物件的瓶頸你就需要重用他們，可以通過新增屬性到你的class裡或者建立靜態變數來實現。

注意如果你要選擇第二種方法，物件會在你的app執行時一直存在於記憶體中，和單例(singleton)很相似。

下面的程式碼說明了使用一個屬性來延遲載入一個date formatter. 第一次呼叫時它會建立一個新的例項，以後的呼叫則將返回已經建立的例項：

// 懶載入！
@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;
}

還需要注意的是，其實設定一個NSDateFormatter的速度差不多是和建立新的一樣慢的！所以如果你的app需要經常進行日期格式處理的話，你會從這個方法中得到不小的效能提升。

14. 使用Sprite Sheets

你是一個遊戲開發者嗎，那麼Sprite sheets一定是一個你的最好的朋友了。Sprite sheet可以讓渲染速度加快，甚至比標準的螢幕渲染方法節省記憶體。

我們有兩個很好的關於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

第二個教程涵蓋了可能在很大程度上影響你遊戲效能的pixel格式的細節。

如果你對於spirte sheet還不是很熟悉，可以看下這兩個(youtube)視訊SpriteSheets – The Movie, Part 1 和 Part 2。視訊的作者是建立Sprite sheet很流行的工具之一Texture Packer的作者Andreas Löw。

除了使用Sprite sheets，其它寫在這裡的建議當然也可以用於遊戲開發中。比如你需要很多的Sprite sheets，像敵人，導彈之類的動作類必備元素，你可以重用這些sprites而不用每次都要重新建立。

15. 避免反覆處理資料

許多應用需要從伺服器載入功能所需的常為JSON或者XML格式的資料。

在伺服器端和客戶端使用相同的資料結構很重要。

在記憶體中操作資料使它們滿足你的資料結構是開銷很大的。

比如你需要資料來展示一個table view,最好直接從伺服器取array結構的資料以避免額外的中間資料結構改變。

類似的，如果需要從特定key中取資料，那麼就使用鍵值對的dictionary。

16. 選擇正確的資料格式

從app和網路服務間傳輸資料有很多方案，最常見的就是JSON和XML。你需要選擇對你的app來說最合適的一個。

解析JSON會比XML更快一些，JSON也通常更小更便於傳輸。從iOS5起有了官方內建的JSON deserialization 就更加方便使用了。

但是XML也有XML的好處，比如使用SAX 來解析XML就像解析本地檔案一樣，你不需像解析json一樣等到整個文件下載完成才開始解析。當你處理很大的資料的時候就會極大地減低記憶體消耗和增加效能。

17. 正確設定背景圖片

在View裡放背景圖片就像很多其它iOS程式設計一樣有很多方法:

使用UIColor的 colorWithPatternImage來設定背景色；

在view中新增一個UIImageView作為一個子View。

如果你使用全畫幅的背景圖，你就必須使用UIImageView。因為UIColor的colorWithPatternImage是用來建立小的重複的圖片作為背景的。這種情形下使用UIImageView可以節約不少的記憶體：

//You could also achieve the same result in Interface Builder

UIImageView *backgroundView = [[UIImageView alloc] initWithImage:[UIImage imageNamed:@"background"]];

[self.view addSubview:backgroundView];

如果你用小圖平鋪來建立背景，你就需要用UIColor的colorWithPatternImage來做了，它會更快地渲染也不會花費很多記憶體：

self.view.backgroundColor = [UIColor colorWithPatternImage:[UIImage imageNamed:@"background"]];

18. 減少使用Web特性

UIWebView很有用，用它來展示網頁內容或者建立UIKit很難做到的動畫效果是很簡單的一件事。

但是你可能有注意到UIWebView並不像驅動Safari的那麼快。這是由於以JIT compilation 為特色的Webkit的Nitro Engine的限制。

所以想要更高的效能你就要調整下你的HTML了。第一件要做的事就是儘可能移除不必要的javascript，避免使用過大的框架。能只用原生js就更好了。

另外，儘可能非同步載入例如使用者行為統計script這種不影響頁面表達的javascript。

最後，永遠要注意你使用的圖片，保證圖片的符合你使用的大小。使用Sprite sheet提高載入速度和節約記憶體。

更多相關資訊可以看下 WWDC 2012 session #601 – Optimizing Web Content in UIWebViews and Websites on iOS

19. 設定Shadow Path

如何在一個View或者一個layer上加一個shadow呢，QuartzCore框架是很多開發者的選擇：

#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;

看起來很簡單，對吧。可是，壞訊息是使用這個方法也有它的問題

Core Animation不得不先在後臺得出你的圖形並加好陰影然後才渲染，這開銷是很大的。

使用shadowPath的話就避免了這個問題：

view.layer.shadowPath = [[UIBezierPath bezierPathWithRect:view.bounds] CGPath];

使用shadow path的話iOS就不必每次都計算如何渲染，它使用一個預先計算好的路徑。但問題是自己計算path的話可能在某些View中比較困難，且每當view的frame變化的時候你都需要去update shadow path.

想了解更多可以看看Mark Pospesel的這篇。

20. 優化Table View

Table view需要有很好的滾動效能，不然使用者會在滾動過程中發現動畫的瑕疵。

為了保證table view平滑滾動，確保你採取了以下的措施:

• 正確使用reuseIdentifier來重用cells
• 儘量使所有的view opaque，包括cell自身
• 避免漸變，圖片縮放，後臺選人
• 快取行高
• 如果cell內現實的內容來自web，使用非同步載入，快取請求結果
• 使用shadowPath來畫陰影
• 減少subviews的數量
• 儘量不適用cellForRowAtIndexPath:，如果你需要用到它，只用一次然後快取結果
• 使用正確的資料結構來儲存資料
• 使用rowHeight, sectionFooterHeight 和 sectionHeaderHeight來設定固定的高，不要請求delegate

21. 選擇正確的資料儲存選項

當儲存大塊資料時你會怎麼做？

你有很多選擇，比如：

• 使用NSUerDefaults
• 使用XML, JSON, 或者 plist
• 使用NSCoding存檔
• 使用類似SQLite的本地SQL資料庫
• 使用 Core Data

NSUserDefaults的問題是什麼？雖然它很nice也很便捷，但是它只適用於小資料，比如一些簡單的布林型的設定選項，再大點你就要考慮其它方式了

XML這種結構化檔案呢？總體來說，你需要讀取整個檔案到記憶體裡去解析，這樣是很不經濟的。使用SAX又是一個很麻煩的事情。

NSCoding？不幸的是，它也需要讀寫檔案，所以也有以上問題。

在這種應用場景下，使用SQLite 或者 Core Data比較好。使用這些技術你用特定的查詢語句就能載入你需要的物件。

在效能層面來講，SQLite和Core Data是很相似的。他們的不同在於具體使用方法。Core Data代表一個物件的graph model，但SQLite就是一個DBMS。Apple在一般情況下建議使用Core Data，但是如果你有理由不使用它，那麼就去使用更加底層的SQLite吧。

如果你使用SQLite，你可以用FMDB(https://github.com/ccgus/fmdb)這個庫來簡化SQLite的操作，這樣你就不用花很多經歷瞭解SQLite的C API了。

22. 加速啟動時間

快速開啟app是很重要的，特別是使用者第一次開啟它時，對app來講，第一印象太太太重要了。

你能做的就是使它儘可能做更多的非同步任務，比如載入遠端或者資料庫資料，解析資料。

還是那句話，避免過於龐大的XIB，因為他們是在主執行緒上載入的。所以儘量使用沒有這個問題的Storyboards吧！

注意，用Xcode debug時watchdog並不執行，一定要把裝置從Xcode斷開來測試啟動速度

23. 使用Autorelease Pool

NSAutoreleasePool負責釋放程式碼塊中的autoreleased objects。一般情況下它會自動被UIKit呼叫。但是有些狀況下你也需要手動去建立它。

假如你建立很多臨時物件，你會發現記憶體一直在減少直到這些物件被release的時候。

好訊息是你可以在你自己的@autoreleasepool裡建立臨時的物件來避免這個行為：

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. */
    }
}

這段程式碼在每次遍歷後釋放所有autorelease物件

更多關於NSAutoreleasePool請參考官方文件。

24. 選擇是否快取圖片

常見的從bundle中載入圖片的方式有兩種，一個是用imageNamed，二是用imageWithContentsOfFile，第一種比較常見一點。

既然有兩種類似的方法來實現相同的目的，那麼他們之間的差別是什麼呢？

imageNamed的優點是當載入時會快取圖片。imageNamed的文件中這麼說:
這個方法用一個指定的名字在系統快取中查詢並返回一個圖片物件如果它存在的話。如果快取中沒有找到相應的圖片，這個方法從指定的文件中載入然後快取並返回這個物件。

相反的，imageWithContentsOfFile僅載入圖片。

下面的程式碼說明了這兩種方法的用法:

UIImage *img = [UIImage imageNamed:@"myImage"]; 
// caching

// or
 UIImage *img = [UIImage imageWithContentsOfFile:@"myImage"]; 
// no caching

那麼我們應該如何選擇呢？

如果你要載入一個大圖片而且是一次性使用，那麼就沒必要快取這個圖片，用imageWithContentsOfFile足矣，這樣不會浪費記憶體來快取它。

然而，在圖片反覆重用的情況下imageNamed是一個好得多的選擇。

25. 避免日期格式轉換

如果你要用NSDateFormatter來處理很多日期格式，應該小心以待。就像先前提到的，任何時候重用NSDateFormatters都是一個好的實踐。

嗯，直接用C來搞，看起來不錯了，但是你相信嗎，我們還有更好的方案！

如果你可以控制你所處理的日期格式，儘量選擇Unix時間戳。你可以方便地從時間戳轉換到NSDate:

- (NSDate*)dateFromUnixTimestamp:(NSTimeInterval)timestamp
{
    return [NSDate dateWithTimeIntervalSince1970:timestamp];
}

這樣會比用C來解析日期字串還快！

需要注意的是，許多web API會以微秒的形式返回時間戳，因為這種格式在javascript中更方便使用。記住用dateFromUnixTimestamp之前除以1000就好了。

後記

這篇博文到這裡就要結束了，歡迎博友們在評論中討論自己在開發中遇到了一些問題。