Android 4.4只需512MB內存？別高興太早 - Android

※ 引述《Colaman ()》之銘言：
: App很肥 系統再瘦都救不了他沒錯 但是...
: 在oom之前 android 還有 application framework的OOP以及android kernel的LMK
: 所以也沒有那麼快跳到oom-killer 而且Google很愛在這邊偷吃步

系統只要進入認定的記憶體不足狀態,就會開始從高oom_adj開始清理,

當系統開始依照OOM_ADJ清理完畢後,那些被清掉的APP,下次就要重新load,

點APP到畫面出來就要一陣子,

我的GPlayer為了有人說關掉也耗記憶體,我就在退出APP的時候整個釋放掉.

結果過幾天,又有人跟我說"從LAUNCHER點GPlayer"要等好幾秒才有畫面....

現在都是高階機子,記憶體問題比較不會覺得卡,但一樣會有啟動緩慢的問題

何況如果還有一個LMK在背後弄,重點是這個LMK各OEM非常喜歡調整,

尤其是低階RAM的機種,因為這些OEM為了要過CTS以防一堆離奇的問題,

為了要過monkey以防memory leak的問題,總是很喜歡在這邊動手腳.


一個真實的案例,某OEM某1G機台,在一個測試流程中,某OEM自製的底層APP

可以重複被kernel的LMK,KILL高達300次以上,結果造成某server,memory leak,

暴肥了一百MB,本來就沒有多少空間可以用,跑了一陣子測試後,因為記憶體不足,

甚麼APP都開不了.

該OEM為了解決這個問題,直接把該APP設定成永遠不能砍,可是記憶體就永遠少了好幾十MB,

重點是這個OEM自製的底層功能,我是一輩子都不會去用它的...XD

很多事情消費者是沒有選擇的權力,OEM選擇用了低RAM,消費者只會看傳單跟DM,

根本沒人會注意細節,或者開機有多少可用,可以釋放到多少,這才是為甚麼ANDROID低階機

體驗總是有限制.(有點跟最近的假油一樣)



USER PID PPID VSIZE RSS WCHAN PC NAME
u0_a159 22329 1940 715244 127784 ffffffff 40048a70 S com.facebook.katana
u0_a179 23603 1940 549664 50888 ffffffff 40048a70 S com.facebook.orca
u0_a159 28225 1940 494260 46152 ffffffff 40048a70 S com.facebook.katana:nodex

: App肥也不見得會引發oom-killer 要看肥app在AMS的哪裡啊@@
: 再來
: 如果提到了oom/lmk/pmem/實體記憶體512MB 為什麼這裡是用VSS計算?
: 從oom/lmk的眼光 應該討論RSS

不好意思,上面那邊文章打錯了,把G-Protector看到的數值打成VSS,

我查了一下我的做法確實是RSS加總沒錯,

(把同屬一個APK使用到的每個process的RSS加總起來,應該是非常正確的檢驗方式)


請看我上面貼的PS LOG.

臉書124MB
一個不知名的臉書服務remote service(45MB),
臉書即時通49MB

CHROME
也是 85MB +70MB 兩個
u0_a146 10127 1940 711316 85920 ffffffff 40048a70 S com.android.chrome
u0_i9 10161 1940 583180 70300 ffffffff 40048a70 S com.android.chrome:sandboxed_process0



: 從App開發者的眼光討論App肥不肥 應該優先討論PSS更甚USS以及RSS
我剛上一篇的數據是RSS加總沒錯 :P

雖然說明打錯了,可是數據是該package使用的RSS的總和


: 算VSS total來討論會不會頂到512MB實體記憶體頂是不是怪怪的?
VSS都400-500的 @_@ 不會有50MB那麼小

: procrank也只算有意義的PSS/USS total給人看 不是嗎?

--