引用:
|
作者野口隆史
pixel3 我是覺得不用太在意 4GB RAM 這點上
因為其它給你更多 RAM 的廠商
很少有廠商真正花心思去調校它
有不少廠商甚至還故意改成過度開銷
一般人不懂到底 KERNEL 怎麼處理記憶體需求調度上的原理
網路上才會有一堆所謂"SPEED TEST" 的影片
把 APP 依序打開跑個一兩輪，作為記憶體多寡的測試依據
廠商不打算教育用戶，還特意去迎合這種現象
最近這一兩年，由於上游代碼合併了 zswap
我基於好奇，檢查了後期新出的 ANDROID 手機
發現很多根本都已經原生支援 zswap
可惜卻沒有使用，浪費了一個能大幅增加 RAM 靈活度的特性
將近十年前，我還在做 kernel 優化的時候
就發現很多人，其實根本連 OS 最基礎的認知也沒有
只會寫 CODE
比較有名的例子，就是 HTC 出的那個 Boots+
PM 不懂就算了，RD 看起來也沒人去跟他講原由
因為在我看來，這幾乎就是告訴別人
"手機廠商系統...
|
野口兄說的ZSwap我也認同，我之前寫Android App有用過類似的ZRAM。
兩者差別應該是ZSwap的Hierarchy比較完整，可以將要Swap的資料先放回RAM裡的ZSwap Pool，等到RAM真的不夠時再將LRU Pages放回HDD/SSD/eMMC/UFS上的Swap空間，而且ZSwap是在Kernel Space打開就可以全機適用。
不用像ZRAM還要在User Space開啟，寫APP時要下API打開才能用。
我之前在我那台LG G3裝Customized ROM時，有打開ZSwap測試，但我猜可能是S801不夠力，LZ4壓縮讓CPU變燙，相對電池噴電也像澆花一樣，而且RAM也沒因為LZ4省掉多少，3GB RAM依然都吃光。
我從這幾年的心得產生一個強烈的偏見，認為Android App的原罪就是用了Java這種肥大拖效能，還要Dalvik/ART VM的語言在行動裝置上。
讀書時學到的知識總是告訴我們，在嵌入式裝置這種效能與功耗有限制的裝置上，用C/C++等Compiled Language是較為妥善的作法，執行效率和記憶體用量絕對會勝出需要VM跑Intermediate Code的語言。
而且最根本的是Android APP開發者對RAM的用量更是完全不知節制，一個比一個大，就連Google Chrome本身就是一個吃RAM怪獸，因此買Android手機時，我才會對RAM大小很在意。