基礎部分
1: 圖片內存大小小結
a: 圖片:是占用內存的大戶,尤其是手機游戲圖片資源眾多。對圖片資源在內存中占用量的計算成為j2me游戲開發(fā)者的經常性工作,cocomo來解釋一下如何計算圖片在內存中的占用量:內存占用量=寬*高*像素字節(jié)數,其中像素字節(jié)數因機型而異。
例如一張64*64的圖片在7210上的內存占用量=64*64*1.5=6144(字節(jié))=6k、在s60上的內存占用量=64*64*2=8192 (字節(jié))=8k。像素字節(jié)數因機型而異,例如 7210是4096色機型,也就是說用12位來表示一個像素,所以乘上1.5,而s60是65536色的機型,用16位來表示一個像素,所以乘上2。
b:xcode中使用instruments 查看圖片內存的問題
如果使用的是模擬器那么默認是小屏幕的,所以最大圖片是1024 *1024 * 4 = 4 m (1024 是圖片的寬高, 4表示的是圖片的存儲類型為4字節(jié)的。也就是 rgba8888)
如果你加載了圖片那么就是使用了4m的內存。如果你需要渲染那么還需要4m的內存。
加載一般都是 **load (nsstring *)filename ,
渲染一般都是 node addchild (node)
2: 引用計數問題
引用計數增加的情況 : a: alloc 對象會使得對象引用數 +1
b:調用retain (具體細說一些實例如下)
->比如你是cocos2d用戶的會看到 addchild 會使子節(jié)點的引用計數+1
->ccarray 的addobject 也會使元素的引用計數+1
總結一下就是: 凡是添加到結合中的元素或者子節(jié)點不需要再去retain ,只需要在建立的時候調用release
減少的情況 : 調用release 使引用計數 -1(具體細說一些實例如下)
-> 集合調用remove/removechildbytag 等等變形的
-> 創(chuàng)建的時候調用autorelease 。注意:如果你的對象是局部對象,而且創(chuàng)建的時候使用的是autorelease,
那么在離開方法的時候如果你沒有retain 那么這個對象將被dealloc(引用計數-1了)
官網的介紹:
•
you own any object you create by allocating memory for it or copying it.
related methods:alloc,allocwithzone:,copy,copywithzone:,mutablecopy,mutablecopywithzone:
if you are not the creator of an object, but want to ensure it stays in memory for you to use, you can express an ownership interest in it.
related method:retain
if you own an object, either by creating it or expressing an ownership interest, you are responsible for releasing it when you no longer need it.
related methods:release,autorelease
conversely, if you are not the creator of an object and have not expressed an ownership interest, you mustnotrelease it.
3 :參考文檔
一,ios與圖片內存
在ios上,圖片會被自動縮放到2的n次方大小。比如一張1024*1025的圖片,占用的內存與一張1024*2048的圖片是一致的。圖片占用內存大小的計算的公式是;長*寬*4。這樣一張512*512占用的內存就是 512*512*4 = 1m。其他尺寸以此類推。(ps:ios上支持的最大尺寸為2048*2048)。
,cocos2d-x的圖片緩存
cocos2d-x 在構造一個精靈的時候會使用spritewithfile或者spritewithspriteframename等無論用哪種方式,cocos2d-x都會將這張圖片加載到緩存中。如果是第一次加載這個圖片,那就會先將這張圖片加載到緩存,然后從緩存讀取。如果緩存中已經存在,則直接從緩存中提取,免除了加載過程。
圖片的緩存主要由以下兩個類來處理:ccspriteframecache, cctexturecache
ccspriteframecache加載的是一張拼接過的大圖,每一個小圖只是大圖中的一個區(qū)域,這些區(qū)域信息都在plist文件中保存。用的時候只需要根據小圖的名稱就可以加載到這個區(qū)域。
cctexturecache 是普通的圖片緩存,我們所有直接加載的圖片都會默認放到這個緩存中,以提高調用效率。
因此,每次加載一張圖片,或者通過plist加載一張拼接圖時,都會將整張圖片加載到內存中。如果不去釋放,那就會一直占用著。
三,渲染內存。
不要以為,計算內存時,只計算加載到緩存中的內存就可以了。以一張1024*1024的圖片為例。
ccsprite *psprite = ccsprite::spritewithfile(a.png);
調用上邊這行代碼以后,可以在leaks工具中看到,增加了大約4m的內存。然后接著調用
addchild(psprite);
這時,內存又增加了4m。也就是,一張圖片,如果需要渲染的話,那它所占用的內存將要x2。
再看看通過plist加載的圖片,比如這張大圖尺寸為2048*2048。想要加載其中的一張32*32的小圖片
ccspriteframecache::sharedspriteframecache()->addspriteframeswithfile(b.plist);
此時內存增加16m (汗)
ccsprite *pspriteframe = ccsprite::spritewithspriteframename(b1.png);
b.png 大小為32*32,想著也就是增加一點點內存,可實際情況是增加16m內存。也就是只要渲染了其中的一部分,那么整張圖片都要一起被加載。
但是情況不是那么的糟糕,這些已經渲染的圖片,如果再次加載的話,內存是不會再繼續(xù)升高的,比如又增加了100個b.plist的另一個區(qū)域,圖片內存還是共增加16+16 = 32m,而不會繼續(xù)上升。
四,緩存釋放
如果游戲有很多場景,在切換場景的時候可以把前一個場景的內存全部釋放,防止總內存過高.
cctexturecache::sharedtexturecache()->removealltextures();釋放到目前為止所有加載的圖片
cctexturecache::sharedtexturecache()->removeunusedtextures();將引用計數為1的圖片釋放掉cctexturecache::sharedtexturecache()->removetexture();單獨釋放某個圖片
ccspriteframecache與 cctexturecache 釋放的方法差不多。
值得注意的是釋放的時機,一般在切換場景的時候釋放資源,如果從a場景切換到b場景,調用的函數順序為b::init()---->a::exit()---->b::onenter()可如果使用了切換效果,比如ctransitionjumpzoom::transitionwithduration這樣的函數,則函數的調用順序變?yōu)閎::init()---->b::onenter()---->a::exit()而且第二種方式會有一瞬間將兩個場景的資源疊加在一起,如果不采取過度,很可能會因為內存吃緊而崩潰。
有時強制釋放全部資源時,會使某個正在執(zhí)行的動畫失去引用而彈出異常,可以調用ccactionmanager::sharedmanager()->removeallactions();來解決。
五,內存優(yōu)化
優(yōu)化的心得就是盡量去拼接圖片,使圖片邊長盡可能的保持2的n次方并且裝的很滿。但要注意,有邏輯關系的圖片盡量打包在一張大圖里,另外一點就是打包的時候要考慮到層的分布。因為為了渲染效率可能會用到ccspritebatchnode;同一個batchnode里的圖片都是位于一個層級的,因此必須根據各個圖片的層級關系,打包到不同的plist里。有時內存和效率不可以兼得,只能盡量平衡了。
六,其他
最后附一個各代ios設備的內存限制情況
設備 建議內存 最大內存
ipad2/iphone4s/iphone4 170-180mb 512mb
ipad/ipod touch3,4/iphone3gs 40-80mb 256mb
ipod touch1,2/iphone3g/iphone1 25mb 128mb
上述建議內存只是一些人自己測試的結果,可用的ram不大于最大內存的一半,如果程序超過最大內存的一半,則可能會掛掉。
另外在leaks里查看模擬器中和真機總的內存,會有較大出入。在模擬器中的結果與實際更接近一些。
七, 泄漏的情況
我所碰到的主要內存泄露的方式:
1、最常見的就是,申請了引用,然后最后忘記釋放。具體么就是,使用oc的 alloc, retain, copy, new, c的malloc, realloc, c++的new等,然后沒有對應的release, free, delete。這是單向泄露。
2、retain cycle,對于oc這種使用計數的方式,可能會存在retain cycle。兩個條件,一、就是a中retain了b,b又retain了a,各自給對方計數增加,這個環(huán)可以變?yōu)楹芏鄬樱褪莂->b, b->c, c->d, .... z->a,當然假如中間層越多,檢測難度就越大。二、計數減少的操作是在dealloc中,而dealloc被調用則需要計數為0。 這兩個條件相加,導致計數鎖定,內存泄露。
實戰(zhàn)演練
如何查找內存泄漏 ?
一:對工具的使用來查找
1、首先使用分析編譯,analyze build,查看歸類當中的memory警告。
這個一般能發(fā)現局部變量中忘記release,或者被中途打斷release的。
2、然后就是直接使用instruments中的leak監(jiān)測。
申請了內存,然后已經沒有指向這塊內存的指針存在,可以認為是leak了。這個檢測一般是檢測這個狀態(tài)。
3、通過instruments中allocation的mark heap。
進行不斷的重復操作,在每次場景結束后,標記內存。假如操作場景沒有泄露,內存增加應該是0。這個檢測是檢測標記點之間有哪些對象增加。另外,需要多mark幾次才會準確,不要mark兩次看到有內存增加就去找問題。
instruments中都是可以看到其中存在什么對象,調用歷史,調用堆棧。這時候大致確定在那個類當中的那個對象泄露了。
二 ,重載法。
雖然知道了哪個類泄露了,但是有時候并不知道具體是那邊的計數出現問題。我自己的方法是,假如是自己編寫的類,那就重載retain和release方法,然后加斷點。以此來監(jiān)測是什么地方retain了這個對象,卻沒有對應釋放。
如何修改內存泄漏呢 ?
1、缺啥補啥。缺release的,就補release,缺free的就加個free。
2、合理使用autorelease。對于返回給上層使用的;或者alloc對象到release中間有return等打斷操作的。建議使用autorelease。
3、合理使用assign。retain cycle,本質就是多余的雙向retain。打個比方就是應該確定哪個對象是根,哪一個是枝葉,枝葉不用去管理根,只需要知道根在那邊就可以了。所以把那些純粹是定位用的變量,屬性都改成assign方式,例如delegate。
ps:
假如對于instruments的使用不是很清楚,可以看這個視頻
游戲中我遇到的一個非常難查的泄漏這里貢獻出來 :
對于cocos2d的用戶如果使用了ccmenu ,而且也重寫了ccscene中的onexsit 函數來檢測離開場景的時候的一些變化。但是忘了去調用super onexsit
這時候ccmenu自己注冊了一個事件delegate 就無法釋放導致ccmenu一直無法釋放。當加載到了其他場景的時候事件總會不對。就是因為這個導致的
解決辦法自然是調用super onexsit 。因為在這里他釋放了delegate
更多信息請查看IT技術專欄