android開發中，令人頭疼的保活問題始終纏繞每乙個開發者。如何保證自己的程序不被系統**呢？首當其衝應該是保證自己程序的優先順序。
android系統在執行時，如果遭遇到記憶體過低，為保證系統穩定與流暢，會**一部分不常用的程序（當然很多三方rom如miui會在電量過低也會**）。這個**過程當然不是隨意**，系統需要有乙個判斷程序優先順序的指標，幫助系統判斷哪些資源是優先順序高需要保留，哪些資源優先順序比較低需要釋放該資源。
adj就是系統殺死程序的重要指標
利用adb shell
2.cat /proc/程序號/oom_adj //檢視當前程序的adj值(早期android和linux使用，現已廢棄，但仍然有效)
3.cat /proc/程序號/oom_score_adj //這個是新版本的檢視adj的命令，adj有效值為-1000~1000
2.adj的值的各種含義
adj級別 取值 含義
native_adj -1000 native程序
system_adj -900 僅指system_server程序
persistent_proc_adj -800 系統persistent程序
persistent_service_adj -700 關聯著系統或persistent程序
service_adj 500 服務程序(a list中的service)
service_b_adj 800 b list中的service
adj是一種演算法，用於系統判斷程序優先順序以觸發linux的lmk（lowmemorykill）機制。一般觸發時機（linux下）是在系統低記憶體時，為了維護正在執行的程序，殺掉優先順序比較低（adj值比較高）的其他程序。
在android中這一機制有所改動。在activitymanagerservice裡有具體的計算adj值的原始碼。
----------adj----------------memory left------------1.native_adj(-1000)：是由init程序fork出來的native程序，並不受system管控；
2.system_adj(-900)：是指system_server程序；
3.persistent_proc_adj(-800): 是指在androidmanifest.xml中申明android:persistent=」true」的系統(即帶有flag_system標記)程序，persistent程序一般情況並不會被殺，即便被殺或者發生crash系統會立即重新拉起該程序。
4.persistent_service_adj(-700)：是由startisolatedprocess()方式啟動的程序，或者是由system_server或者persistent程序所繫結(並且帶有bind_above_client或者bind_important)的服務程序
5.總結
android程序優先順序adj的每乙個adj級別往往都有多種場景，使用adjtype完美地區分相同adj下的不同場景； 不同adj程序所對應的schedgroup不同，從而分配的cpu資源也不同，schedgroup大體分為top(t)、前台(f)、後台(b)； adj跟ams中的procstate有著緊密的聯絡。
1.adj：通過調整oom_score_adj來影響程序壽命(lowmemorykiller殺程序策略)；
2.schedgroup：影響程序的cpu資源排程與分配；
2.程序中的service工作完成後，務必主動呼叫stopservice或stopself來停止服務，避免佔據記憶體，浪費系統資源；
3.不要長時間繫結其他程序的service或者provider，每次使用完成後應立刻釋放，避免其他程序常駐於記憶體；
5.減少在保活上花心思，更應該在優化記憶體上下功夫，因為在相同adj級別的情況下，系統會選擇優先殺記憶體占用的程序。
跑步app保活 android APP保活機制
摘要 1，從官網上可以看出google為了系統更加流暢以及優化記憶體，google做了很大的處理，在手機暗屏或者睡眠狀態就停止後台執行 若要保持service的常駐，需要做一些前端的活動，notification重要屬性 notification.flags notification.flag no...
RunLoop之執行緒保活
參考文獻 在ios專案中，有時會有一些花費時間較長的操作阻塞主線程，我們通常為了防止介面卡頓，將其放入子執行緒中執行。根據執行緒知識，如果子執行緒執行完分配的任務後，就會自動銷毀。比如我們現在定義乙個執行緒，改寫它的dealloc方法，觀察它什麼時候銷毀 implementation taythre...
iOS 後台保活
關於ios為voip應用提供的特殊許可權和實現方法,我的描述如下.我盡可能的涉及到voip實現的各種細節,這樣你能對這個運作機制有乙個更好的理解,我覺得這遠比單單貼幾行 有意義.因為乙個開發者在實際實現過程中遇到的千難險阻很少會體現在最終 上,就如你永遠不知道台上的角兒在台下的挫折.你永遠也沒有辦法...