Re: [翻譯] 死法無法預測
※ 引述《AmosYang (Zzz...)》之銘言：
※ 引述《PsMonkey (痞子軍團團長)》之銘言：
推
04/26 17:09,
04/26 17:09
→
04/26 19:12,
04/26 19:12
→
04/26 19:13,
04/26 19:13
我對 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://www.ptt.cc/bbs/java/M.1398525322.A.2B4.html
※ 編輯: Killercat (118.160.18.161), 04/26/2014 23:21:39
推
04/26 23:35, , 1F
04/26 23:35, 1F
推
04/28 11:35, , 2F
04/28 11:35, 2F
推
05/06 17:32, , 3F
05/06 17:32, 3F
討論串 (同標題文章)