從這張屏幕截圖可以看出，Allocations認為我的應(yīng)用程序（Ongo）僅使用7.55 MB的內(nèi)存，而Memory Monitor則為53.30。此外，可用系統(tǒng)內(nèi)存與應(yīng)用程序正在使用的內(nèi)存量幾乎沒有關(guān)聯(lián)。有誰知道為什么這兩個工具之間會有如此大的分歧？另外，是否可以找到低系統(tǒng)內(nèi)存的來源，或者如何防止其很快耗盡？我的應(yīng)用程序似乎沒有泄漏內(nèi)存，但是以某種方式耗盡了系統(tǒng)資源。
3 回答
慕蓋茨4494581
TA貢獻1850條經(jīng)驗 獲得超11個贊
對于那些在2012年之后看到此帖子的人：
真正加載到設(shè)備物理內(nèi)存中的內(nèi)存是VM Tracker Instrument中的常駐內(nèi)存。
分配工具僅標記由malloc / [NSObject alloc]和某些框架緩沖區(qū)創(chuàng)建的內(nèi)存，例如，解壓縮的圖像位圖未包含在分配工具中，但它始終占用您的大部分內(nèi)存。
請觀看WWDC 2012 Session 242 iOS App性能：內(nèi)存以從Apple獲取信息。
暮色呼如
TA貢獻1853條經(jīng)驗 獲得超9個贊
我認為這是由于OpenGL ES的內(nèi)存使用情況已從ObjectAlloc中隱藏，但已計入“內(nèi)存監(jiān)視器”中。例如，在這里的問題中，請參見zoul的測試，他在創(chuàng)建紋理時觀察到ObjectAlloc略有上升，但隨后該內(nèi)存在傳遞給OpenGL ES時從該儀器中消失了。內(nèi)存監(jiān)視器仍會跟蹤該紋理內(nèi)存。
這應(yīng)該包括UI元素（如圖層和視圖）的視覺外觀，因為CALayers實際上是OpenGL ES紋理的包裝。UI元素的實際2D圖像表示似乎沒有被ObjectAlloc跟蹤，這導(dǎo)致ObjectAlloc中的總值較低。
ObjectAlloc仍然可以很好地跟蹤分配的數(shù)量和類型，并且自從出現(xiàn)堆快照功能以來，它就變得更加有價值。您只想與Memory Monitor配合使用，以查看您真正的整體內(nèi)存使用情況。
明月笑刀無情
TA貢獻1828條經(jīng)驗 獲得超4個贊
內(nèi)存監(jiān)視器將計算應(yīng)用程序擁有的大部分或全部資源，包括在內(nèi)核級別間接分配的資源。這包括Brad建議的AFAIK視頻內(nèi)存（紋理等），還包括內(nèi)存映射文件以及可能比較大的內(nèi)核結(jié)構(gòu)（如套接字）。清單可能很長...
- 3 回答
- 0 關(guān)注
- 577 瀏覽
添加回答
舉報
0/150
提交
取消