本文集中與iOS的多核編程和內(nèi)存管理，為什么？因為iPad 2已經(jīng)是雙核CPU了！雖然iPad 1的應用已經(jīng)不慢了，但大家完全可以使用蘋果的多核編程框架來寫出更加responsive的應用。

多核運算

在iOS中concurrency編程的框架就是GCD(Grand Central Dispatch)， GCD的使用非常簡單。它把任務分派到不同的queue隊列來處理。開發(fā)者把任務代碼裝到一個個block里面，操作系統(tǒng)把這些任務代碼分派到不同的資源里去處理，一個簡單的例子來說，為什么初學者寫tableview的時候，滑動列表時總會很卡，因為很多初學者把圖片裝載放到main thread主線程去執(zhí)行，例如我們要滑動暢順的話，iOS最快可以1秒內(nèi)刷新60次，如何你的一個cell的文字和圖片裝載超過1/60秒的話，自然就會卡。

所以一般我們會把圖片裝載這些需要多點時間的移出main thread來處理，對于用GCD來說，就是把圖片載入放到另外一個queue隊列中來異步執(zhí)行，當資源準備好了后，放回到main thread中顯示出來。main thread在GCD中就是main queue。

創(chuàng)建一個新queue隊列的代碼：

dispatch_queue_t network_queue;    
network_queue = dispatch_queue_create("com.myapp.network", nill);    
dispatch_queue_t network_queue;  
network_queue = dispatch_queue_create("com.myapp.network", nill);  

例如，我們圖片讀取放到network_queue來進行異步執(zhí)行

dispatch_async(network_queue, ^{      
    UIImage *cellImage = [self loadMyImageFromNetwork:image_url];      
    // 將圖片cache到本地       
    [self cacheImage:cellImage];       
    .....         
} );    
dispatch_async(network_queue, ^{    
    UIImage *cellImage = [self loadMyImageFromNetwork:image_url];    
    // 將圖片cache到本地    
    [self cacheImage:cellImage];    
    .....    
} );  

dispatch_async的意思就是將任務進行異步并行處理，不一定需要一個任務處理完后才能處理下一個。以上代碼loadMyImageFromNetwork的意思就是從網(wǎng)絡中讀取圖片，這個任務交給network_queue來處理。這樣讀取圖片的時間過長也不會阻塞主線程界面的處理。

當我們處理完圖片后，應該更新界面，從queue的概念去設計，就是要將更新界面的代碼放到main queue中去，因為iOS里面永遠是主線程來刷新重畫UI。所以代碼應該為，

dispatch_async(network_queue, ^{      
    UIImage *cellImage = [self loadMyImageFromNetwork:image_url];      
    // 將圖片cache到本地       
    [self cacheImage:cellImage];      
   // 回到主線程       
   dispatch_async(dispatch_get_main_queue(), ^{      
      // 顯示圖片到界面       
      [self displayImageToTableView:cellImage];      
   }];        
} );    
dispatch_async(network_queue, ^{    
  UIImage *cellImage = [self loadMyImageFromNetwork:image_url];    
    // 將圖片cache到本地    
    [self cacheImage:cellImage];    
   // 回到主線程    
   dispatch_async(dispatch_get_main_queue(), ^{    
      // 顯示圖片到界面    
      [self displayImageToTableView:cellImage];    
   }];    
} );  

dispatch_get_main_queue() 函數(shù)就是返回主線程，^{} 封裝的就是任務代碼，這樣嵌套方式就可以從一個隊列queue，跳到另一個queue，就是這么簡單。

我們一般可以把networking有關的代碼放到一個queue，把圖片resize的代碼放到另外一個queue，處理完后更新界面，只需要嵌套跳回到 main queue。這樣加上幾行代碼，你的程序就可以利用到系統(tǒng)多核資源，把具體的調(diào)度工作交給了操作系統(tǒng)自己來分配。有了這樣的代碼，不管你的硬件是單核，雙核還是iMac的4核，甚至8核，都可以非常好地并行處理。

內(nèi)存管理

我一直驚嘆iOS和Objective-C內(nèi)存處理能力，例如iPad版本的iWork，Pages應用就是一個內(nèi)存處理技術應用的鬼斧神工之作。想想256M內(nèi)存的iPad，可以帶來如此的華麗的界面同時獲得如此流暢的用戶體驗，真是不簡單。原因就是iOS一直提倡開發(fā)者在有限硬件資源內(nèi)寫出最優(yōu)化的代碼，使用CPU最少，占用內(nèi)存最小。

（以下代碼適用于iOS SDK 4.1, 由于新SDK 4.2對內(nèi)存使用有新改動，所以可能有不同。。。）

1. 盡量少的UIView層

通常我們喜歡把很多控件層（UILabel，UIButton，UIView等）一起放到一個大的UIView容器來顯示我們的內(nèi)容，這個方法一般是可以的，但是如果要經(jīng)常重新刷新內(nèi)容的大區(qū)域界面，多數(shù)發(fā)生在iPad的應用中，這個方法會帶來過多的內(nèi)存使用和動畫的延遲（比較卡），例如，scrollview的動畫比較卡，又或者，經(jīng)常收到內(nèi)存警告。其中一個重要原因是每個控件，特別是透明底的，會多次重新繪制（drawRect）過多。其解決辦法是，盡量將幾個控件合并到一個層上來顯示，這樣系統(tǒng)會減少系統(tǒng)調(diào)用drawRect，從而帶來性能上的提升。

很簡單的一個例子，就是iNotes提供手寫功能，用戶可以在iPad屏幕上寫出不同的筆畫，開始的設計是，用戶每寫一劃，iNotes就會生成一個新的透明底UIView來保持這個筆畫，用戶寫了10筆，系統(tǒng)就生產(chǎn)了10個UIView，每個view的大小都是整個屏幕的，以便用戶的undo操作。這個方案帶來嚴重的內(nèi)存問題，因為系統(tǒng)將每個層都保持一個bitmap圖，一個像素需要4bit來算，一個層的大小就是 4x1024x768 ~ 3M, 10個層就是 10x3M = 30M，很明顯，iPad很快爆出內(nèi)存警告。

這個例子最后的方案是，所有筆畫都畫在同一個層，iNotes可以保存筆畫的點進行undo操作。這樣的方案就是無論用戶畫多少筆畫，界面重畫需要的資源都是一樣的。

2. 顯示最佳尺寸的圖片

很多程序員比較懶，網(wǎng)絡上拿下來的圖片，直接就用UIImageView將其顯示給用戶，這樣的后果就是，程序需要一直保存著大尺寸的圖片到內(nèi)存。解決辦法應該是先將圖片縮小到需要顯示的尺寸，釋放大尺寸圖片的內(nèi)存，然后再顯示到界面給用戶。

3. 盡量使用圖片pattern，而不是一張大的圖片

例如，很多界面設計者喜歡在界面上放一個大底圖，但這個底圖是老是占用著內(nèi)存的，最佳方案是，設計出一個小的pattern圖，然后用這個方案顯示成底圖。

UIImage *smallImage = [[UIImage alloc] initWithContentsOfFile:path];    
backgroundView.backgroundColor = [UIColor colorWithPatternImage:smallImage];    
[smallImage release];    
UIImage *smallImage = [[UIImage alloc] initWithContentsOfFile:path];  
backgroundView.backgroundColor = [UIColor colorWithPatternImage:smallImage];  
[smallImage release];  

4. 使用完資源后，立即釋放

一般objective-c的習慣是，用完的資源要立即釋放，因為明白什么時候用完某個資源的是程序員你自己。

例如，我們要讀較大的圖片，把它縮小后，顯示到界面去。當大圖片使用完成后，應該立即釋放。代碼如下：

UIImage *fullscreenImage = [[UIImage alloc] initWithContentOfFile:path];    
UIImage *smallImage = [self resizeImage:fullscreenImage];    
[fullscreenImage release];    
imageView.image = smallImage;    
......    
UIImage *fullscreenImage = [[UIImage alloc] initWithContentOfFile:path];  
UIImage *smallImage = [self resizeImage:fullscreenImage];  
[fullscreenImage release];  
imageView.image = smallImage; 

......

5. 循環(huán)中大量生成的自動釋放autorelease對象，可以考慮使用autorelease pool封裝

代碼范例：

for(UIView *subview in bigView.subviews) {    
    // 使用autorelease pool自動釋放對象池     
    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];    
    UIImageView *imageView = (UIImageView *)subview;    
        
    // subview處理代碼     
    .......    
    // 銷毀自動釋放對象     
    [pool  drain];    
}    
for(UIView *subview in bigView.subviews) {  
    // 使用autorelease pool自動釋放對象池  
    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];  
    UIImageView *imageView = (UIImageView *)subview;  
      
    // subview處理代碼  
    .......  
    // 銷毀自動釋放對象  
    [pool  drain];  
}  

自動釋放對象池把每個循環(huán)內(nèi)生成的臨時對象使用完后立即釋放

以上的意見是本人多年來編寫iPad/iPhone程序的經(jīng)驗，另外iOS 4.0的multi-tasking特性發(fā)布后，程序可以被調(diào)入后臺運行，蘋果工程師的意見是，進入后臺運行時，你的應用應該釋放掉能釋放的對象，盡量保持在16M左右，這樣別的程序運行時才不容易把你的應用擠掉。

小結(jié)：iOS應用中多核編程和內(nèi)存管理的內(nèi)容介紹完了，希望本文對你有所幫助！