ART 作為一個令人期待的變革
甚至在 4.4 實驗的時候大家都迫不及待要打開
ART 和 Dalvik 最大的差別是從 JIT(Just In Time)
改成 AOT(Ahead Of Time) 的作法
也就是說他在安裝的時候，就先將程式編譯成 native binary
目的當然是為了獲得性能上的提昇
實際的狀況是怎樣呢？
除了安裝超慢，binary 顯著變大，以一般使用狀況來說
單純提高到 ART 就會使得 EMMC 耗用量增加 500MB~1GB
執行時的 I/O 量也顯著提升
隨之而來的就是 RAM 和 Cache 使用上的不經濟
理論上是可以減少 run time optimization 的 CPU 用量
但是就效能和耗電來說，其實有時候 I/O 性能比 CPU 重要多了
耗電這種東西看整體，影響的因素極多
升上 5.0 後覺得比較耗電不見得是因為 ART
不過如果沒有另外調整，覺得換了 5.0 比較省電
說穿了大概是使用者自我感覺良好比較多
回到效能方向，其實 Google 在之前的實驗就已經知道一件事
「ART 其實沒有想像中的好」
前面說的 I/O、RAM/cache 使用量增加是一個因素
另外最大的主因是，ART 本身還不夠成熟
目前的狀況是，高階換 L 沒有明顯的助益
然後中低階來說換 L 反而跑得更差了
AOT 太喘，但 L 沒有 JIT 的選項可選
除了 CPU intensive 的跑分以外，對實際使用的助益很有限
那為什麼已經發現問題卻不改善呢？
也許繼續走雙 VM，等 ART 再成熟一點再切過去？
應該是牽涉 politics 的問題，而且 Dalvik 的 resource 早就調走
想回頭也來不及了
--
甚至在 4.4 實驗的時候大家都迫不及待要打開
ART 和 Dalvik 最大的差別是從 JIT(Just In Time)
改成 AOT(Ahead Of Time) 的作法
也就是說他在安裝的時候，就先將程式編譯成 native binary
目的當然是為了獲得性能上的提昇
實際的狀況是怎樣呢？
除了安裝超慢，binary 顯著變大，以一般使用狀況來說
單純提高到 ART 就會使得 EMMC 耗用量增加 500MB~1GB
執行時的 I/O 量也顯著提升
隨之而來的就是 RAM 和 Cache 使用上的不經濟
理論上是可以減少 run time optimization 的 CPU 用量
但是就效能和耗電來說，其實有時候 I/O 性能比 CPU 重要多了
耗電這種東西看整體，影響的因素極多
升上 5.0 後覺得比較耗電不見得是因為 ART
不過如果沒有另外調整，覺得換了 5.0 比較省電
說穿了大概是使用者自我感覺良好比較多
回到效能方向，其實 Google 在之前的實驗就已經知道一件事
「ART 其實沒有想像中的好」
前面說的 I/O、RAM/cache 使用量增加是一個因素
另外最大的主因是，ART 本身還不夠成熟
目前的狀況是，高階換 L 沒有明顯的助益
然後中低階來說換 L 反而跑得更差了
AOT 太喘，但 L 沒有 JIT 的選項可選
除了 CPU intensive 的跑分以外，對實際使用的助益很有限
那為什麼已經發現問題卻不改善呢？
也許繼續走雙 VM，等 ART 再成熟一點再切過去？
應該是牽涉 politics 的問題，而且 Dalvik 的 resource 早就調走
想回頭也來不及了
--
All Comments