內存管理 & 內存優化技巧 淺析

內存管理 淺析

下列行爲都會增長一個app的內存佔用：

    一、建立一個OC對象；

    二、定義一個變量；

    三、調用一個函數或者方法。

    若是app佔用內存過大，系統可能會強制關閉app，形成閃退現象，影響用戶體驗。如何讓回收那些再也不使用的對象呢？本文着重介紹OC中的內存管理。

    所謂內存管理，就是對內存進行管理，涉及的操做有：

    一、分配內存：好比建立一個對象，會增長內存佔用；

    二、清除內存：好比銷燬一個對象，會減小內存佔用。

    內存管理的管理範圍：

    一、任何繼承了NSObject的對象；

    二、對其餘非對象類型無效（int、char、float、double、struct、enum等）

    只有OC對象才須要進行內存管理的本質緣由：

    一、OC對象存放於堆裏；

    二、非OC對象通常放在棧裏面（棧內存會被系統自動回收）

    系統是如何判斷何時須要回收一個對象所佔用的內存呢？在這裏涉及到對象的「引用計數器」的概念。

    引用計數器：

    每一個OC對象都有本身的引用計數器，它是一個整數；每一個OC對象內部都有4個字節的存儲空間來存放引用計數器。

    從字面上看，引用計數器能夠理解爲「對象被引用的次數」。

    簡單來講，能夠理解爲：引用計數器表示有多少人正在使用這個對象。

    當沒有任何人使用這個對象時，系統纔會回收這個對象；也就是說：

    一、當對象的引用計數器爲0時，對象佔用的內存就會被系統回收；

    二、若是對象的計數器不爲0，那麼在整個程序運行過程，它佔用的內存就不可能被回收（除非整個程序已經退出）。

    任何一個對象，剛生下來的時候，引用計數器都爲1；當使用alloc、new或者copy建立一個對象時，對象的引用計數器默認就是1.

    要想管理對象佔用的內存，就得學會操做對象的引用計數器。

    引用計數器的常見操做：

    一、給對象發送一條retain消息，可使引用計數器值+1（retain方法返回對象自己）；

    二、給對象發送一條release消息，可使引用計數器值-1；

    三、給對象發送retainCount消息，能夠得到當前的引用計數器值。

    須要注意的是：release並不表明銷燬\回收對象，僅僅是計數器值-1。

    當一個對象的引用計數器值爲0時：

    一、這個對象即將被銷燬，其佔用的內存被系統回收；

    二、系統會自動給對象發送一條dealloc消息（所以，從dealloc方法有沒有被調用，就能夠判斷出對象是否被銷燬）。

    dealloc方法的重寫；

    一、通常會重寫dealloc方法，在這裏釋放相關資源，dealloc就是相關的遺言；

    二、一旦重寫了dealloc方法，就必須調用[super dealloc]，而且放在最後面調用。

    使用注意：

    一、不能直接調用dealloc方法；

    二、一旦對象被回收了，它佔用的內存就再也不可用，堅持使用會致使程序崩潰（野指針錯誤）。

    野指針\空指針概念：

    殭屍對象：已經被銷燬的對象（不能再使用的對象）。

    野指針：指向殭屍對象的指針；給野指針發消息會報「EXC_BAD_ACCESS」錯誤。

    空指針：沒有指向存儲空間的指針（裏面存的時nil，也就是0）；給空指針發消息是沒有任何反應的。

    爲了不野指針錯誤的常見方法是：在對象被銷燬後，將指向對象的指針變爲空指針。

    多對象內存管理規律：

    單個對象內存管理比較簡單，若是對多個對象進行內存管理，而且對象之間是有聯繫的，那麼管理就會變得比較複雜；總的來講，多對象內存管理有幾點規律：

    一、只要還有人在用某個對象，那麼這個對象就不會被回收；

    二、只要你想用這個對象，就讓對象的計數器+1；

    三、當你再也不使用這個對象時，就讓對象的計數器-1；

    蘋果官方規定的內存管理原則：

    一、誰建立誰release：若是你經過alloc、new或[mutable]copy來建立一個對象，那麼你必須調用調用release或autorrelease。

    二、誰retain誰release：只要你調用了retain，就必須調用一次release。

    總的來講就是：

    一、有加就有減；

    二、曾經讓對象的計數器+1，就必須在最後讓對象計數器-1.

    set方法的內存管理以下：

1 2 3 4 5 6 7 8 9 10 11

- ( void )setCar:(Car *)car {      if  (car != _car)      {          // 對當前正在使用的車（舊車）作一次release          [_car release];                    // 對新車作一次retain操做           _car = [car retain];      } }

 

    dealloc方法的內存管理

1 2 3 4 5 6 7

- ( void )dealloc {      // 當人不在了，表明不用車了      // 對車作一次release操做      [_car release];       [super dealloc]; }

 

    下面的代碼都會引起內存泄漏：

1 2	p.dog = [[Dog alloc] init];     [[Dog alloc] init].weight = 20.8;

 

內存管理小技巧：

 

1. 用ARC管理內存

ARC(Automatic ReferenceCounting, 自動引用計數)和iOS5一塊兒發佈，它避免了最多見的也就是常常是因爲咱們忘記釋放內存所形成的內存泄露。它自動爲你管理retain和release的過程，因此你就沒必要去手動干預了。忘掉代碼段結尾的release簡直像記得吃飯同樣簡單。而ARC會自動在底層爲你作這些工做。除了幫你避免內存泄露，ARC還能夠幫你提升性能，它能保證釋放掉再也不須要的對象的內存。

 

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中添加這個方法：

staticNSString *CellIdentifier = @"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:`方法來獲取圖片資源。

 

5.不要阻塞主線程

永遠不要使主線程承擔過多。由於UIKit在主線程上作全部工做，渲染，管理觸摸反應，迴應輸入等都須要在它上面完成。

一直使用主線程的風險就是若是你的代碼真的block了主線程，你的app會失去反應。

大部分阻礙主進程的情形是你的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), ^{

// 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

});

});

發現代碼中有一個嵌套的`dispatch_async`嗎？這是由於任何UIKit相關的代碼須要在主線程上進行。

 

6. 在Image Views中調整圖片大小

若是要在`UIImageView`中顯示一個來自bundle的圖片，你應保證圖片的大小和UIImageView的大小相同。在運行中縮放圖片是很耗費資源的，特別是`UIImageView`嵌套在`UIScrollView`中的狀況下。

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

 

7. 選擇正確的Collection

學會選擇對業務場景最合適的類或者對象是寫出能效高的代碼的基礎。當處理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這些雲服務提供者也已經支持了壓縮輸出。

 

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;// 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相似，不一樣的是系統回收內存的時候它會自動刪掉它的內容。

 

11.權衡渲染方法

在iOS中能夠有不少方法作出漂亮的按鈕。你能夠用整幅的圖片，可調大小的圖片，uozhe能夠用CALayer， CoreGraphics甚至OpenGL來畫它們。

固然每一個不一樣的解決方法都有不一樣的複雜程度和相應的性能。

簡單來講，就是用事先渲染好的圖片更快一些，由於如此一來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. 第一次調用時它會建立一個新的實例，之後的調用則將返回已經建立的實例：

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

}

還須要注意的是，其實設置一個NSDateFormatter的速度差很少是和建立新的同樣慢的！因此若是你的app須要常常進行日期格式處理的話，你會從這個方法中獲得不小的性能提高。

 

14. 使用Sprite Sheets

Sprite sheet可讓渲染速度加快，甚至比標準的屏幕渲染方法節省內存。

 

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提升加載速度和節約內存。

 

19. 設定Shadow Path

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

#import

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

 

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了。

 

23. 使用Autorelease Pool

`NSAutoreleasePool`負責釋放block中的autoreleased objects。通常狀況下它會自動被UIKit調用。可是有些情況下你也須要手動去建立它。

假如你建立不少臨時對象，你會發現內存一直在減小直到這些對象被release的時候。這是由於只有當UIKit用光了autorelease pool的時候memory纔會被釋放。好消息是你能夠在你本身的@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對象

 

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是一個好的方案。Sam Soffes有一個不錯的帖子(http://soff.es/how-to-drastically-improve-your-app-with-an-afternoon-and-instruments)裏面有一些能夠用來解析ISO-8601日期字符串的代碼，簡單重寫一下就能夠拿來用了。

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

若是你能夠控制你所處理的日期格式，儘可能選擇Unix時間戳。你能夠方便地從時間戳轉換到NSDate:

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

return[NSDate dateWithTimeIntervalSince1970:timestamp];

 

}

這樣會比用C來解析日期字符串還快！須要注意的是，許多web API會以微秒的形式返回時間戳，由於這種格式在javascript中更方便使用。記住用`dateFromUnixTimestamp`以前除以1000就行了。

 

 

轉載自：http://blog.csdn.net/sandyloo/article/details/51063831