※ 引述《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給人看 不是嗎?
--
: 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給人看 不是嗎?
--
All Comments