iOS 的多核編程和記憶體管理

來源:互聯網
上載者:User

 

本文轉載自:Anxonli 

 

 

隔上一次寫iPad app開發文章已經是10個月,那篇iPad app開發概述還不錯,曾經成為了google關鍵字“iPad app 開發”搜尋的第一位,可能是大牛們都太忙於賺app store的錢了,留下我這個小蝦來寫文章。這次的文章集中與iOS的多核編程和記憶體管理,為什嗎?因為iPad 2已經是雙核CPU了!雖然iPad 1的應用已經不慢了,但大家完全可以使用蘋果的多核編程架構來寫出更加responsive的應用。

 

多核運算

在iOS中concurrency編程的架構就是GCD(Grand Central Dispatch), GCD的使用非常簡單。它把任務指派到不同的queue隊列來處理。開發人員把任務代碼裝到一個個block裡面,作業系統把這些任務代碼指派到不同的資源裡去處理,一個簡單的例子來說,為什麼初學者寫tableview的時候,滑動列表時總會很卡,因為很多初學者把圖片裝載放到main thread主線程去執行,例如我們要滑動暢順的話,iOS最快可以1秒內重新整理60次,如何你的一個cell的文字和圖片裝載超過1/60秒的話,自然就會卡。所以一般我們會把圖片裝載這些需要多點時間的移出main thread來處理,對於用GCD來說,就是把圖片載入放到另外一個queue隊列中來非同步執行,當資源準備好了後,放回到main thread中顯示出來。main thread在GCD中就是main queue。

 

建立一個新queue隊列的代碼:

dispatch_queue_t network_queue;<br />network_queue = dispatch_queue_create("com.myapp.network", nill);

例如,我們圖片讀取放到network_queue來進行非同步執行

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

 

 

dispatch_async的意思就是將任務進行非同步平行處理,不一定需要一個任務處理完後才能處理下一個。以上代碼loadMyImageFromNetwork的意思就是從網路中讀取圖片,這個任務交給network_queue來處理。這樣讀取圖片的時間過長也不會阻塞主線程介面的處理。

 

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

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

 

 

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

 

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

 

 

記憶體管理

我一直驚歎iOS和Objective-C記憶體處理能力,例如iPad版本的iWork,Pages應用就是一個記憶體處理技術應用的鬼斧神工之作。想想256M記憶體的iPad,可以帶來如此的華麗的介面同時獲得如此流暢的使用者體驗,真是不簡單。原因就是iOS一直提倡開發人員在有限硬體資源內寫出最佳化的代碼,使用CPU最少,佔用記憶體最小。

 

(以下代碼適用於iOS SDK 4.1, 由於新SDK 4.2對記憶體使用量有新改動,所以可能有不同。。。)

1. 盡量少的UIView層

通常我們喜歡把很多控制項層(UILabel,UIButton,UIView等)一起放到一個大的UIView容器來顯示我們的內容,這個方法一般是可以的,但是如果要經常重新重新整理內容的大地區介面,多數發生在iPad的應用中,這個方法會帶來過多的記憶體使用量和動畫的延遲(比較卡),例如,scrollview的動畫比較卡,又或者,經常收到記憶體警告。其中一個重要原因是每個控制項,特別是透明底的,會多次重新繪製(drawRect)過多。其解決辦法是,盡量將幾個控制項合并到一個層上來顯示,這樣系統會減少系統調用drawRect,從而帶來效能上的提升。

 

很簡單的一個例子,就是iNotes提供手寫功能,使用者可以在iPad螢幕上寫出不同的筆畫,開始的設計是,使用者每寫一划,iNotes就會產生一個新的透明底UIView來保持這個筆畫,使用者寫了10筆,系統就生產了10個UIView,每個view的大小都是整個螢幕的,以便使用者的undo操作。這個方案帶來嚴重的記憶體問題,因為系統將每個層都保持一個bitmap圖,一個像素需要4bit來算,一個層的大小就是 4x1024x768 ~ 3M, 10個層就是 10x3M = 30M,很明顯,iPad很快爆出記憶體警告。

 

這個例子最後的方案是,所有筆畫都畫在同一個層,iNotes可以儲存筆畫的點進行undo操作。這樣的方案就是無論使用者畫多少筆畫,介面重畫需要的資源都是一樣的。

 

2. 顯示最佳尺寸的圖片

很多程式員比較懶,網路上拿下來的圖片,直接就用UIImageView將其顯示給使用者,這樣的後果就是,程式需要一直儲存著大尺寸的圖片到記憶體。解決辦法應該是先將圖片縮小到需要顯示的尺寸,釋放大尺寸圖片的記憶體,然後再顯示到介面給使用者。

 

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

例如,很多介面設計者喜歡在介面上放一個大底圖,但這個底圖是老是佔用著記憶體的,最佳方案是,設計出一個小的pattern圖,然後用這個方案顯示成底圖。

 

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

 

 

4. 使用完資源後,立即釋放

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

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

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

 

 

5. 迴圈中大量產生的自動釋放autorelease對象,可以考慮使用autorelease pool封裝

代碼範例:

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

 

 自動釋放對象池把每個迴圈內產生的臨時對象使用完後立即釋放

 

以上的意見是本人多年來編寫iPad/iPhone程式的經驗,另外iOS4.0的multi-tasking特性發布後,程式可以被調入後台運行,蘋果工程師的意見是,進入後台運行時,你的應用應該釋放掉能釋放的對象,盡量保持在16M左右,這樣別的程式運行時才不容易把你的應用擠掉。

 

--------------------------------------------------

太久沒有寫東西了,中文寫作能力退步了,大家別見怪,多給給意見

 

 

 

 

 

 

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.