※ 引述《AmosYang (Zzz...)》之銘言： ※ 引述《PsMonkey (痞子軍團團長)》之銘言： 我對 Android 不熟, 能否就「看到heap/free比例不對」多說一些? 感覺是個蠻有意思的方向, 感謝 orz ----- 我好一陣子（一兩年）沒寫Android了。Android來講，很多動作都會造成Fragmentation 這些都可以在DDMS(Android的一種除錯機制)看到Dalvik目前的記憶體使用情形 這東西有一個表格，可以列出你目前的記憶體使用情況 (順帶一提 當年Bitmap用的是完全不同的獨立空間，現在我不知道還是不是) 記憶體裡面有幾個數值，包括Used, Free, Heap 基本上Used很淺顯易懂就不解釋，Free也很直觀不解釋 重點在於最後一個Heap Android的Heap基本上是個只增不減的東西(4.0以後有新的做法 但是我已經沒在寫了) 他也是很直觀的"跟系統要的記憶體"數量，VM系統大概都是有這種類似概念 問題在於，Heap什麼時候會被allocate到呢？當然是app需要空間但是free卻不夠的時候 一直到這裡為止都還只是常識等級的概念 但是表格上有一個東西沒有提到，就是破碎度。 我先假設閱讀這篇的人都對破碎度有完全的了解，知道什麼是記憶體破碎 Free可能是破碎的，所以即使還有10M，但是App要從Free拿10M卻不見得拿的到 因為Free可能最連續的部分只有8M。有些VM實作的JVM會在GC的時候做Memory Trim Trim以後「也許」有機會拿到連續的10M 那就不用再去跟JVM靠背 所以大概也只有在最嚴苛的狀況下才會變成這篇文章提到的部分 但是這是Android，這東西是Dalvik，基本上是一個沙箱化的設計 他不可能在ui thread那麼猖狂的環境下沒事情給你trim一下 UI Thread = 超高負載 = 使用者體驗 = 消費者 = 所有系統都要極力討好的對象 Dalvik唯一合理的做法就是多跟heap要一點記憶體(通常就是直接要個10M了) 所以我們在DDMS裡面會看到Free在一定範圍內上上下下但是Heap卻越來越多 更慘的情況（像是以前我手機需要寫一個加解密Relay Server）下 基本上看Free就知道情況會越來越不妙，Free會開始節節高陞 但是大家都知道原因不是因為程式寫的好用的記憶體少 而是因為Android的記憶體配置策略簡單，而且不要說Trim 連GC都是不到最後關頭不幹 所以要是你寫的code會造成大量空洞化，或者Fragmentation越來越嚴重 你就會看到很神奇的Free/Heap比例，Heap不停長，Free也跟著長 反正大家都猜的到Free裡面是什麼？蜂窩嗎.... XD (這是一個當初Android開發者的雙關笑話，Android 3.0叫做Honeycomb蜂窩 而這剛好也是一個記憶體空洞化（讓整塊記憶體看起來像蜂窩）很嚴重的版本） 這很好猜，超好猜，我相信做久一點的或者做深一點的Android開發者都會碰到 看數字就知道發生什麼事情了. 現在的Dalvik我不知道，但是我那時代的Android之所以開機都馬不持久 一天大概要重開機個一次，我始終高度的懷疑跟這記憶體策略有關 叫我寫一個系統用這種策略 我大概得天天重新開機才行了... --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.160.18.161 ※ 文章網址: http://webptt.com/m.aspx?n=bbs/java/M.1398525322.A.2B4.html ※ 編輯: Killercat (118.160.18.161), 04/26/2014 23:21:39