Ⅰ 如何防止android app被kill
相較於/data/app下的應用，放在/system/app下的應用享受更多的特權，比如若在其Manifest.xml文件中設置persistent屬性為true，則可使其免受out-of-memory
killer的影響。如應用程序'Phone'的AndroidManifest.xml文件：
<application
android:name="PhoneApp"
android:persistent="true"
android:label="@string/dialerIconLabel"
android:icon="@drawable/ic_launcher_phone">
...
</application>
設置後app提升為系統核心級別，任何情況下不會被kill掉, settings->applications裡面也會屏蔽掉stop操作。
這樣設置前的log: Proc #19: adj=svc /B 4067b028 255:com.xxx.xxx/10001 (started-services)
# cat /proc/255/oom_adj
4
設置後的log: PERS #19: adj=core /F 406291f0 155:com.xxx.xxx/10001 (fixed)
# cat /proc/155/oom_adj
-12 # 這是CORE_SERVER_ADJ
註：init進程的oom_adj為-16（即SYSTEM_ADJ）： cat /proc/1/oom_adj
Android相關部分分析：
在文件frameworks/base/services/java/com/android/server/am/ActivityManagerService.java中有以下的代碼：
final
ProcessRecord addAppLocked(ApplicationInfo info) {
ProcessRecord
app = getProcessRecordLocked(info.processName, info.uid);
if
(app == null) {
app
= newProcessRecordLocked(null, info, null);
mProcessNames.put(info.processName,
info.uid, app);
updateLruProcessLocked(app,
true, true);
}
if
((info.flags&(ApplicationInfo.FLAG_SYSTEM|ApplicationInfo.FLAG_PERSISTENT))
==
(ApplicationInfo.FLAG_SYSTEM|ApplicationInfo.FLAG_PERSISTENT)) {
app.persistent
= true;
app.maxAdj
= CORE_SERVER_ADJ; //
這個常數值為-12。
}
if
(app.thread == null && mPersistentStartingProcesses.indexOf(app)
< 0) {
mPersistentStartingProcesses.add(app);
startProcessLocked(app,
"added application", app.processName);
}
return
app;
}
可
見要想成為core service （即app.maxAdj =
CORE_SERVER_ADJ(-12)），應用程序需要FLAG_SYSTEM和FLAG_PERSISTENT兩個標志，FLAG_SYSTEM指
的是應用位於/system/app下，FLAG_PERSISTENT就是指persistent屬性。
而對於frameworks/base/services/java/com/android/server/SystemServer.java，則調用
ActivityManagerService.setSystemProcess();
把自己的 app.maxAdj 設置成SYSTEM_ADJ，即-16。
原理：
Android中的進程是託管的，當系統進程空間緊張的時候，會依照優先順序自動進行進程的回收。由此帶來三個問題：
1）
回收規則: 什麼時候回收與回收哪一個？
2）
避免誤殺: 如何阻止被回收？
3）
數據恢復與保存: 被回收了怎麼辦？
Android將進程分為6個等級,它們按優先順序順序由高到低依次是:
1.前台進程(
FOREGROUND_APP)
2.可視進程(VISIBLE_APP
)
3.
次要服務進程(SECONDARY_SERVER )
4.後台進程
(HIDDEN_APP)
5.內容供應節點(CONTENT_PROVIDER)
6.空進程(EMPTY_APP)
特徵：
1.如果一個進程裡面同時包含service和可視的activity，那麼這個進程應該歸於可視進程，而不是service進程。
2.另外，如果其他進程依賴於它的話，一個進程的等級可以提高。例如，一個A進程里的service被綁定到B進程里的組件上，進程A將總被認為至少和B進程一樣重要。
3.系統中的phone服務被劃分到前台進程而不是次要服務進程.
在android中，進程的oom_adj值也就代表了它的優先順序。oom_adj值越高代表該進程優先順序越低。文件/init.rc中有以下屬性設置：
setprop
ro.FOREGROUND_APP_ADJ 0
setprop
ro.VISIBLE_APP_ADJ 1
setprop
ro.SECONDARY_SERVER_ADJ 2
setprop
ro.HIDDEN_APP_MIN_ADJ 7
setprop
ro.CONTENT_PROVIDER_ADJ 14
setprop
ro.EMPTY_APP_ADJ 15
/init.rc中，將PID為1的進程(init進程)的oom_adj設置為SYSTEM_ADJ(-16):
#
Set init its forked children's oom_adj.
write
/proc/1/oom_adj -16
查看本機設置：
cat /sys/mole/lowmemorykiller/parameters/adj
0,1,2,7,14,15
回收時機：
文件/init.rc中:
setprop
ro.FOREGROUND_APP_MEM 1536 // 6M
setprop
ro.VISIBLE_APP_MEM 2048 // 8M
setprop
ro.SECONDARY_SERVER_MEM 4096 // 16M
setprop
ro.HIDDEN_APP_MEM 5120 // 20M
setprop
ro.CONTENT_PROVIDER_MEM 5632 // 22.4M
setprop
ro.EMPTY_APP_MEM 6144 // 24M
這些數字也就是對應的內存閾值，一旦低於該值，Android便開始按順序關閉相應等級的進程。
注意這些數字的單位是page： 1 page = 4 kB。所以上面的六個數字對應的就是(MB): 6,8,16,20,22,24。
查看現在的內存閾值設置：
cat /sys/mole/lowmemorykiller/parameters/minfree
要想重新設置該值（對應不同的需求）:
echo "1536,2048,4096,5120,15360,23040">/sys/mole/lowmemorykiller/parameters/minfree
這樣當可用內存低於90MB的時候便開始殺死"空進程"，而當可用內存低於60MB的時候才開始殺死"內容供應節點"類進程。
具體的回收實現在ActivityManagerService.java中的函數trimApplications()：
1.首先移除package已被卸載的無用進程；
2.基於進程當前狀態，更新oom_adj值，然後進行以下操作：
1)
移除沒有activity在運行的進程;
2)
如果AP已經保存了所有的activity狀態，結束這個AP。
3.
最後，如果目前還是有很多activities 在運行，那麼移除那些activity狀態已經保存好的activity。
更新oom_adj的值：
在ActivityManagerService.java文件的ComputeOomAdjLocked() 中計算出進程的oom_adj，例如:
if
(app == TOP_APP) {
//
The last app on the list is the foreground app.
adj
= FOREGROUND_APP_ADJ;
app.adjType
= "top-activity";
}
Android kernel中的low memory killer
Android的Low Memory Killer根據需要（當系統內存短缺時）殺死進程釋放其內存，源代碼在kernel/drivers/misc/lowmemorykiller.c中。簡單說，就是尋找一個最合適的進程殺死，從而釋放它佔用的內存。
最合適的進程是:
• oom_adj越大
• 佔用物理內存越多
一旦一個進程被選中，內核會發送SIGKILL信號將之殺死：
for_each_process(p)
{
……
if(selected
== NULL || p->oomkilladj
> selected->oomkilladj ||
(p->oomkilladj
== selected->oomkilladj && tasksize > selected_tasksize))
{
selected
= p;
}
}
if(selected
!= NULL) {
force_sig(SIGKILL,
selected);
}
查看LRU列表：adb shell mpsys activity
當activitydemo在前台時：
包含Service的進程的優先順序比較高，在computeOomAdjLocked中將其分為了兩小類:
static
final int MAX_SERVICE_INACTIVITY = 30*60*1000;
if
(now < (s.lastActivity+MAX_SERVICE_INACTIVITY)) {
if
(adj > SECONDARY_SERVER_ADJ) {
adj
= SECONDARY_SERVER_ADJ;
app.adjType
= "started-services";
app.hidden
= false;
}
}
if
(adj > SECONDARY_SERVER_ADJ) {
app.adjType
= "started-bg-services";
}
完全讓進程不被kill是不可能的，咱們可以通過一些操作，使進程被kill的幾率變小：
1)
提高進程的優先順序:
*
後台操作採用運行於前台的Service形式，因為一個運行著service的進程比一個運行著後台activity的等級高；
*
按back鍵使得進程中的activity在後台運行而不是destory，需重載back按鍵(沒有任何activity在運行的進程優先被殺).
*
依賴於其他優先順序高的進程；
2)
強制修改進程屬性：
*
在進程中設置：setPersistent(true);
*
在Manifest文件中設置（如上）。
Ⅱ 怎麼讓Android程序一直後台運行，像QQ一樣不被殺死
方法：
對於一個service，可以首先把它設為在前台運行：
public void MyService.onCreate() {
super.onCreate();
Notification notification = new Notification(android.R.drawable.my_service_icon,
"my_service_name",
System.currentTimeMillis());
PendingIntent p_intent = PendingIntent.getActivity(this, 0,
new Intent(this, MyMainActivity.class), 0);
notification.setLatestEventInfo(this, "MyServiceNotification, "MyServiceNotification is Running!", p_intent);
Log.d(TAG, String.format("notification = %s", notification));
startForeground(0x1982, notification); // notification ID: 0x1982, you can name it as you will.
}
重要設置-------------------------------
相較於/data/app下的應用，放在/system/app下的應用享受更多的特權，比如若在其Manifest.xml文件中設置persistent屬性為true，則可使其免受out-of-memory killer的影響。如應用程序'Phone'的AndroidManifest.xml文件：
<application android:name="PhoneApp"
android:persistent="true"
android:label="@string/dialerIconLabel"
android:icon="@drawable/ic_launcher_phone">
...
</application>
設置後app提升為系統核心級別，任何情況下不會被kill掉, settings->applications裡面也會屏蔽掉stop操作。
這樣設置前的log: Proc #19: adj=svc /B 4067b028 255:com.xxx.xxx/10001 (started-services)
# cat /proc/255/oom_adj
設置後的log: PERS #19: adj=core /F 406291f0 155:com.xxx.xxx/10001 (fixed)
# cat /proc/155/oom_adj
-12 # 這是CORE_SERVER_ADJ
註：init進程的oom_adj為-16（即SYSTEM_ADJ）： cat /proc/1/oom_adj
Android相關部分分析：
在文件frameworks/base/services/java/com/android/server/am/ActivityManagerService.java中有以下的代碼：
final ProcessRecord addAppLocked(ApplicationInfo info) {
ProcessRecord app = getProcessRecordLocked(info.processName, info.uid);
if (app == null) {
app = newProcessRecordLocked(null, info, null);
mProcessNames.put(info.processName, info.uid, app);
updateLruProcessLocked(app, true, true);
}
if ((info.flags&(ApplicationInfo.FLAG_SYSTEM|ApplicationInfo.FLAG_PERSISTENT))
== (ApplicationInfo.FLAG_SYSTEM|ApplicationInfo.FLAG_PERSISTENT)) {
app.persistent = true;
app.maxAdj = CORE_SERVER_ADJ; // 這個常數值為-12。
}
if (app.thread == null && mPersistentStartingProcesses.indexOf(app) < 0) {
mPersistentStartingProcesses.add(app);
startProcessLocked(app, "added application", app.processName);
}
return app;
}
可見要想成為core service （即app.maxAdj = CORE_SERVER_ADJ(-12)），應用程序需要FLAG_SYSTEM和FLAG_PERSISTENT兩個標志，FLAG_SYSTEM指的是應用位於/system/app下，FLAG_PERSISTENT就是指persistent屬性。
而對於frameworks/base/services/java/com/android/server/SystemServer.java，則調用
ActivityManagerService.setSystemProcess();
把自己的 app.maxAdj 設置成SYSTEM_ADJ，即-16。
原理：
Android中的進程是託管的，當系統進程空間緊張的時候，會依照優先順序自動進行進程的回收。由此帶來三個問題：
1） 回收規則: 什麼時候回收與回收哪一個？
2） 避免誤殺: 如何阻止被回收？
3） 數據恢復與保存: 被回收了怎麼辦？
Android將進程分為6個等級,它們按優先順序順序由高到低依次是:
1.前台進程( FOREGROUND_APP)
2.可視進程(VISIBLE_APP )
3. 次要服務進程(SECONDARY_SERVER )
4.後台進程 (HIDDEN_APP)
5.內容供應節點(CONTENT_PROVIDER)
6.空進程(EMPTY_APP)
特徵：
1.如果一個進程裡面同時包含service和可視的activity，那麼這個進程應該歸於可視進程，而不是service進程。
2.另外，如果其他進程依賴於它的話，一個進程的等級可以提高。例如，一個A進程里的service被綁定到B進程里的組件上，進程A將總被認為至少和B進程一樣重要。
3.系統中的phone服務被劃分到前台進程而不是次要服務進程.
在android中，進程的oom_adj值也就代表了它的優先順序。oom_adj值越高代表該進程優先順序越低。文件/init.rc中有以下屬性設置：
setprop ro.FOREGROUND_APP_ADJ 0
setprop ro.VISIBLE_APP_ADJ 1
setprop ro.SECONDARY_SERVER_ADJ 2
setprop ro.HIDDEN_APP_MIN_ADJ 7
setprop ro.CONTENT_PROVIDER_ADJ 14
setprop ro.EMPTY_APP_ADJ 15
/init.rc中，將PID為1的進程(init進程)的oom_adj設置為SYSTEM_ADJ(-16):
# Set init its forked children's oom_adj.
write /proc/1/oom_adj -16
查看本機設置：
cat /sys/mole/lowmemorykiller/parameters/adj
0,1,2,7,14,15
回收時機：
文件/init.rc中:
setprop ro.FOREGROUND_APP_MEM 1536 // 6M
setprop ro.VISIBLE_APP_MEM 2048 // 8M
setprop ro.SECONDARY_SERVER_MEM 4096 // 16M
setprop ro.HIDDEN_APP_MEM 5120 // 20M
setprop ro.CONTENT_PROVIDER_MEM 5632 // 22.4M
setprop ro.EMPTY_APP_MEM 6144 // 24M
這些數字也就是對應的內存閾值，一旦低於該值，Android便開始按順序關閉相應等級的進程。
注意這些數字的單位是page： 1 page = 4 kB。所以上面的六個數字對應的就是(MB): 6,8,16,20,22,24。
查看現在的內存閾值設置：
cat /sys/mole/lowmemorykiller/parameters/minfree
要想重新設置該值（對應不同的需求）:
echo "1536,2048,4096,5120,15360,23040">/sys/mole/lowmemorykiller/parameters/minfree
這樣當可用內存低於90MB的時候便開始殺死"空進程"，而當可用內存低於60MB的時候才開始殺死"內容供應節點"類進程。
具體的回收實現在ActivityManagerService.java中的函數trimApplications()：
1.首先移除package已被卸載的無用進程；
2.基於進程當前狀態，更新oom_adj值，然後進行以下操作：
1) 移除沒有activity在運行的進程;
2) 如果AP已經保存了所有的activity狀態，結束這個AP。
3. 最後，如果目前還是有很多activities 在運行，那麼移除那些activity狀態已經保存好的activity。
更新oom_adj的值：
在ActivityManagerService.java文件的ComputeOomAdjLocked() 中計算出進程的oom_adj，例如:
if (app == TOP_APP) {
// The last app on the list is the foreground app.
adj = FOREGROUND_APP_ADJ;
app.adjType = "top-activity";
}
Android kernel中的low memory killer
Android的Low Memory Killer根據需要（當系統內存短缺時）殺死進程釋放其內存，源代碼在kernel/drivers/misc/lowmemorykiller.c中。簡單說，就是尋找一個最合適的進程殺死，從而釋放它佔用的內存。
最合適的進程是:
• oom_adj越大
• 佔用物理內存越多
一旦一個進程被選中，內核會發送SIGKILL信號將之殺死：
for_each_process(p) {
……
if(selected == NULL || p->oomkilladj > selected->oomkilladj ||
(p->oomkilladj == selected->oomkilladj && tasksize > selected_tasksize))
{
selected = p;
}
}
if(selected != NULL) {
force_sig(SIGKILL, selected);
}
查看LRU列表：adb shell mpsys activity
當activitydemo在前台時：
包含Service的進程的優先順序比較高，在computeOomAdjLocked中將其分為了兩小類:
static final int MAX_SERVICE_INACTIVITY = 30*60*1000;
if (now < (s.lastActivity+MAX_SERVICE_INACTIVITY)) {
if (adj > SECONDARY_SERVER_ADJ) {
adj = SECONDARY_SERVER_ADJ;
app.adjType = "started-services";
app.hidden = false;
}
}
if (adj > SECONDARY_SERVER_ADJ) {
app.adjType = "started-bg-services";
}
完全讓進程不被kill是不可能的，我們可以通過一些操作，使進程被kill的幾率變小：
1) 提高進程的優先順序:
* 後台操作採用運行於前台的Service形式，因為一個運行著service的進程比一個運行著後台activity的等級高；
* 按back鍵使得進程中的activity在後台運行而不是destory，需重載back按鍵(沒有任何activity在運行的進程優先被殺).
* 依賴於其他優先順序高的進程；
2) 強制修改進程屬性：
* 在進程中設置：setPersistent(true);
* 在Manifest文件中設置（如上）。
Ⅲ 想讓android應用常駐後台，不被殺死，各位大神有什麼高招
方法： 對於一個service，可以首先把它設為在前台運行： public void MyService.onCreate() { super.onCreate(); Notification notification = new Notification(android.R.drawable.my_service_icon, "my_service_name", System.currentTimeMillis()); PendingIntent p_intent = PendingIntent.getActivity(this, 0, new Intent(this, MyMainActivity.class), 0); notification.setLatestEventInfo(this, "MyServiceNotification, "MyServiceNotification is Running!", p_intent); Log.d(TAG, String.format("notification = %s", notification)); startForeground(0x1982, notification); // notification ID: 0x1982, you can name it as you will. } 重要設置------------------------------- 相較於/data/app下的應用，放在/system/app下的應用享受更多的特權，比如若在其Manifest.xml文件中設置persistent屬性為true，則可使其免受out-of-memory killer的影響。如應用程序'Phone'的AndroidManifest.xml文件： <application android:name="PhoneApp" android:persistent="true" android:label="@string/dialerIconLabel" android:icon="@drawable/ic_launcher_phone"> ... </application> 設置後app提升為系統核心級別，任何情況下不會被kill掉, settings->applications裡面也會屏蔽掉stop操作。 這樣設置前的log: Proc #19: adj=svc /B 4067b028 255:com.xxx.xxx/10001 (started-services) # cat /proc/255/oom_adj 設置後的log: PERS #19: adj=core /F 406291f0 155:com.xxx.xxx/10001 (fixed) # cat /proc/155/oom_adj -12 # 這是CORE_SERVER_ADJ 註：init進程的oom_adj為-16（即SYSTEM_ADJ）： cat /proc/1/oom_adj Android相關部分分析： 在文件frameworks/base/services/java/com/android/server/am/ActivityManagerService.java中有以下的代碼： final ProcessRecord addAppLocked(ApplicationInfo info) { ProcessRecord app = getProcessRecordLocked(info.processName, info.uid); if (app == null) { app = newProcessRecordLocked(null, info, null); mProcessNames.put(info.processName, info.uid, app); updateLruProcessLocked(app, true, true); } if ((info.flags&(ApplicationInfo.FLAG_SYSTEMApplicationInfo.FLAG_PERSISTENT)) == (ApplicationInfo.FLAG_SYSTEMApplicationInfo.FLAG_PERSISTENT)) { app.persistent = true; app.maxAdj = CORE_SERVER_ADJ; // 這個常數值為-12。 } if (app.thread == null && mPersistentStartingProcesses.indexOf(app) < 0) { mPersistentStartingProcesses.add(app); startProcessLocked(app, "added application", app.processName); } return app; } 可見要想成為core service （即app.maxAdj = CORE_SERVER_ADJ(-12)），應用程序需要FLAG_SYSTEM和FLAG_PERSISTENT兩個標志，FLAG_SYSTEM指的是應用位於/system/app下，FLAG_PERSISTENT就是指persistent屬性。 而對於frameworks/base/services/java/com/android/server/SystemServer.java，則調用 ActivityManagerService.setSystemProcess(); 把自己的 app.maxAdj 設置成SYSTEM_ADJ，即-16。 原理： Android中的進程是託管的，當系統進程空間緊張的時候，會依照優先順序自動進行進程的回收。由此帶來三個問題： 1） 回收規則: 什麼時候回收與回收哪一個？ 2） 避免誤殺: 如何阻止被回收？ 3） 數據恢復與保存: 被回收了怎麼辦？ Android將進程分為6個等級,它們按優先順序順序由高到低依次是: 1.前台進程( FOREGROUND_APP) 2.可視進程(VISIBLE_APP ) 3. 次要服務進程(SECONDARY_SERVER ) 4.後台進程 (HIDDEN_APP) 5.內容供應節點(CONTENT_PROVIDER) 6.空進程(EMPTY_APP) 特徵： 1.如果一個進程裡面同時包含service和可視的activity，那麼這個進程應該歸於可視進程，而不是service進程。 2.另外，如果其他進程依賴於它的話，一個進程的等級可以提高。例如，一個A進程里的service被綁定到B進程里的組件上，進程A將總被認為至少和B進程一樣重要。 3.系統中的phone服務被劃分到前台進程而不是次要服務進程. 在android中，進程的oom_adj值也就代表了它的優先順序。oom_adj值越高代表該進程優先順序越低。文件/init.rc中有以下屬性設置： setprop ro.FOREGROUND_APP_ADJ 0 setprop ro.VISIBLE_APP_ADJ 1 setprop ro.SECONDARY_SERVER_ADJ 2 setprop ro.HIDDEN_APP_MIN_ADJ 7 setprop ro.CONTENT_PROVIDER_ADJ 14 setprop ro.EMPTY_APP_ADJ 15 /init.rc中，將PID為1的進程(init進程)的oom_adj設置為SYSTEM_ADJ(-16): # Set init its forked children's oom_adj. write /proc/1/oom_adj -16 查看本機設置： cat /sys/mole/lowmemorykiller/parameters/adj 0,1,2,7,14,15 回收時機： 文件/init.rc中: setprop ro.FOREGROUND_APP_MEM 1536 // 6M setprop ro.VISIBLE_APP_MEM 2048 // 8M setprop ro.SECONDARY_SERVER_MEM 4096 // 16M setprop ro.HIDDEN_APP_MEM 5120 // 20M setprop ro.CONTENT_PROVIDER_MEM 5632 // 22.4M setprop ro.EMPTY_APP_MEM 6144 // 24M 這些數字也就是對應的內存閾值，一旦低於該值，Android便開始按順序關閉相應等級的進程。 注意這些數字的單位是page： 1 page = 4 kB。所以上面的六個數字對應的就是(MB): 6,8,16,20,22,24。 查看現在的內存閾值設置： cat /sys/mole/lowmemorykiller/parameters/minfree 要想重新設置該值（對應不同的需求）: echo "1536,2048,4096,5120,15360,23040">/sys/mole/lowmemorykiller/parameters/minfree 這樣當可用內存低於90MB的時候便開始殺死"空進程"，而當可用內存低於60MB的時候才開始殺死"內容供應節點"類進程。 具體的回收實現在ActivityManagerService.java中的函數trimApplications()： 1.首先移除package已被卸載的無用進程； 2.基於進程當前狀態，更新oom_adj值，然後進行以下操作： 1) 移除沒有activity在運行的進程; 2) 如果AP已經保存了所有的activity狀態，結束這個AP。 3. 最後，如果目前還是有很多activities 在運行，那麼移除那些activity狀態已經保存好的activity。 更新oom_adj的值： 在ActivityManagerService.java文件的ComputeOomAdjLocked() 中計算出進程的oom_adj，例如: if (app == TOP_APP) { // The last app on the list is the foreground app. adj = FOREGROUND_APP_ADJ; app.adjType = "top-activity"; } Android kernel中的low memory killer Android的Low Memory Killer根據需要（當系統內存短缺時）殺死進程釋放其內存，源代碼在kernel/drivers/misc/lowmemorykiller.c中。簡單說，就是尋找一個最合適的進程殺死，從而釋放它佔用的內存。 最合適的進程是: • oom_adj越大 • 佔用物理內存越多 一旦一個進程被選中，內核會發送SIGKILL信號將之殺死： for_each_process(p) { …… if(selected == NULL p->oomkilladj > selected->oomkilladj (p->oomkilladj == selected->oomkilladj && tasksize > selected_tasksize)) { selected = p; } } if(selected != NULL) { force_sig(SIGKILL, selected); } 查看LRU列表：adb shell mpsys activity 當activitydemo在前台時： 包含Service的進程的優先順序比較高，在computeOomAdjLocked中將其分為了兩小類: static final int MAX_SERVICE_INACTIVITY = 30*60*1000; if (now < (s.lastActivity+MAX_SERVICE_INACTIVITY)) { if (adj > SECONDARY_SERVER_ADJ) { adj = SECONDARY_SERVER_ADJ; app.adjType = "started-services"; app.hidden = false; } } if (adj > SECONDARY_SERVER_ADJ) { app.adjType = "started-bg-services"; } 完全讓進程不被kill是不可能的，我們可以通過一些操作，使進程被kill的幾率變小： 1) 提高進程的優先順序: * 後台操作採用運行於前台的Service形式，因為一個運行著service的進程比一個運行著後台activity的等級高； * 按back鍵使得進程中的activity在後台運行而不是destory，需重載back按鍵(沒有任何activity在運行的進程優先被殺). * 依賴於其他優先順序高的進程； 2) 強制修改進程屬性： * 在進程中設置：setPersistent(true); * 在Manifest文件中設置（如上）。
Ⅳ 手機總是容易滿內存，到底是什麼在占內存
問這個問題，應該是Android手機的玩家吧，而且你對Android的內存機制也不了解，簡單來說，Android中的內存就是給你用的，不用還不正常，根本不用擔心內存怎麼只剩下幾百M呢。
像我們這些在Windows陪伴下成長起來的玩家，「內存不足」經常遇到，但是Android有著與Windows完全不一樣的內存管理機制，Windows上的那一套，對Android並沒用。
Android中可用內存是個沒意義的數字
Windows中一旦程序被關閉，分配的內存也就釋放出來，然而在Android中運行過的應用絕大多數是從前台轉入到後台，並保留在內存中並不會也不需要主動釋放，這樣下次再運行該應用時，可以更快的啟動。
無論手機的物理內存有多大，Android都能將其充分利用，將需要用到的數據從硬碟讀入到內存，以提高數據訪問性能，也就是說， 在Android系統中，可用內存越小，表明其調用的數據就越多，訪問的命中率就越高，系統也就越快 。
你可能會問，當打開的應用越來越多，佔用的內存總會爆滿的，那怎麼辦呢？
Android有著優秀的內存回收機制
Android使用了一個名為Low Memory Killer（LMK）的機制來管理內存，當內存出現不足時，LMK就開始揮舞屠刀殺掉一些進程以獲得新的內存空間。
Android有一套獨特的進程管理，它會以oom_adj來表示進程的重要性，oom_adj的值越小，則重要性越高，oom_adj的值越大，該進程被系統選中殺掉的可能性越高。
Android默認的進程管理策略
為了更好的評估進程的重要性，Android將進程分為六類，如下所述：
前台進程：oom_adj=0，指正在當前屏幕上顯示的進程和一些系統進程，一旦你回到主界面 或切換到其它程序，當前進程變為隱藏進程，前台進程是不會殺掉的；
可見進程：oom_adj=1，可見進程雖然不在前台，但依然可見，如widget、輸入法等，這部分進程也非常重要，基本上不可能被殺掉；
次要服務：oom_adj=2，目前正在運行的一些服務，如下載、播放音樂，它們雖然屬於次要服務，但與系統息息相關，一般也不會被殺掉；
隱藏進程：oom_adj=7，這個很容易理解，當應用從前台轉入到後台後，也就成為隱藏進程了，通常一鍵清理內存就是清掉這些隱藏進程；
內容提供者：oom_adj=14，沒有程序實體，只提供內容供別的程序去用的，比如日歷供應節點，顯然這類進程最有可能被先殺掉；
空進程：oom_adj=15，有些程序在程序退出後，依然會在進程中駐留一個空進程，這個進程里沒有任何數據在運行，作用往往是提高該程序下次的啟動速度或者記錄程序的一些 歷史 信息，這類進程無疑是要最先被殺掉的。
Android的內存管理機制非常適合嵌入式系統，能充分發揮出硬體的潛力，當內存越大，它的優勢就越明顯。
Android手機需要清內存嗎？不需要
那麼Android手機到底要不要清內存？結論是：不需要！其實這個結論也適用iPhone手機。
手機內存分為兩部分，運行內存和存儲內存。買手機時，一個型號的手機有很多套餐可以選擇，比如6 64GB、4+128GB，前面的4GB，6GB就是運行內存，後者則是存儲內存。
佔用手機運行內存的主要是手機運行程序時被軟體佔用的內存，安卓手機的系統會把手機里說有的軟體都放在後台運行之中，因為這樣開啟軟體的時候會節約等待啟動的時間，除非用戶自己去設置關閉開機自動啟動軟體。
可運行內存一共就那麼多，雖然現在新款手機的運行內存不斷加大但隨著軟體的不斷更新升級，佔用的手機內存也會越來越大，這都是成正比的。為了清理軟體佔用的內存，安卓手機都會配備「一鍵清理」的功能去清理運行內存，這樣可以使因為佔用運行內存過多而變卡頓的手機流暢起來。
而佔用存儲內存的東西就有很多了，比如軟體的數據緩存、微信qq的聊天記錄、相冊里的照片、下載的音樂視頻、簡訊垃圾、手機隨著系統升級，本身系統所佔的內存也會越來越大，這些都會佔用手機的存儲內存。
其中最佔用存儲內存的就當屬照片和微信了。那麼該怎麼看微信到底佔用了多少內存呢？
點開微信中的［我］－［設置］－［通用］－［清理微信存儲空間］，等待幾秒鍾後就會顯示佔了多少內存了，如果你不經常清理，那這個數字一定會讓你大吃一驚。然後點擊下方的［管理微信聊天數據］清楚就好了。
一般如果是安卓手機的話，如果手機內存較小，很容易出現內存不夠用的情況。安卓系統、應用廠商的服務、手機應用等都會佔用大量的內存，由於國內手機廠商深度定製的安卓系統，普遍存在全家桶，大量的服務和應用存在自啟和連環喚醒情況，大量消耗用戶內存，造成手機內存佔用過高，嚴重影響了用戶的使用體驗。而反觀國外很多採用原生安卓系統的手機，雖然內存並不大，但內存的佔用率卻極低，實際的應用體驗卻更優秀。所以國內手機廠商的全家桶，是造成手機內存佔用率較高的主要原因。一般可以通過手機助手清理內存，禁止應用自啟，卸載無用應用等方法解決手機內存佔用較多的問題。
國產手機系統全家桶導致手機內存佔用過大
由於目前手機的硬體利潤較低，很多國內手機廠商都是通過預裝應用的方式，提升手機的利潤。所以國產手機普遍存在以全家桶的方式，打包預裝各種應用和服務，通常會在手機中進行自啟，或者連環喚醒，佔用了大量的手機內存，嚴重影響了手機用戶的體驗。
手機內存佔用過高，可以藉助手機衛士清理內存
如果手機的內存佔用過高，可以藉助手機衛士等工具對手機的內存進行清理，對於不常用的手機應用進行卸載，提升手機的運行效率。另外也可以通過禁止手機應用的自啟，來提升手機內存的使用效率，但對於手機存在應用連喚醒的情況，是無效的。所以手機衛士或管家，只能暫時解決手機內存佔用過高的問題，無法從根本上解決問題。
使用第三方原生安卓系統，可大幅降低手機內存佔用
目前的cm等第三方原生安卓系統，一般都不夾帶國產手機廠商的全家桶，系統十分純凈，一般對於手機內存的佔用都比較小。一般如果條件允許的話，可以刷第三方的原生安卓系統，提升手機內存的使用效率。
cm系統是老手機的救星
華為榮耀暢玩4，搭載的驍龍410晶元，僅配置了1g內存，可以說硬體配置十分渣，運行華為自帶emui系統，內存佔用極高，基本卡都沒辦法使用。但刷cm13系統後，竟然滿血復活，運行普通應用十分流暢，完全可以當做備用機使用。這也充分說明，很多國產手機在硬體配置方面沒有太大瓶頸，主要是國產手機系統的全家桶，佔用大量內存，拖慢了整機的速度。
對於手機內存佔用過大的問題，主要是由於安裝和啟動的手機應用較多，特別是很多國產手機的全家桶，佔用和消耗了大量的手機內存，影響了手機的使用效率。一般可以通過手機衛士等工具，清理內存，禁止應用自啟等方法解決手機內存佔用過大的問題。如果想從根本上解決這個問題，更多的還是依靠手機廠商摒棄全家桶，推出類似cm的第三方原生安卓系統。如果條件許可的話，用戶也可以刷cm等比較純凈的第三方安卓系統。
關閉一些沒必要自動運行的軟體，瀏覽器可以選擇無圖模式，音樂播放器可以關閉歌手圖片顯示，視頻播放器要時刻的清理緩存，還有軟體安裝後自動刪除安裝包， 游戲 停止運行後，手動清理全盤緩存，QQ壓縮包，文件管理器中可以找到，格式zip，如果你知道文件夾是哪個軟體所有，覺得清理掉不會影響使用，就清理了，你會發現手機內存又多了至少2GB,不信你就試試吧
智能手機的用戶有一個無法規避的問題，那就是手機的卡頓問題，造成手機卡頓的因素有很多，內存不足便是其中的一種。為了盡量避免手機出現卡頓的這種情況，部分用戶不惜花費重金來購買高內存的手機，但是依然無法完全規避因為內存不足所導致的手機卡頓問題。低內存手機很好理解，為何高內存手機同樣也會出現該問題呢？手機中究竟是怎麼在使用內存，該如何規避因為內存不足而導致手機卡頓的這種問題呢？
關於手機內存您又了解多少呢，我們先單純的從技術面來簡單的聊聊這個問題。手機內存可以分為兩大類，一類是運行內存，一類是存儲內存。前者相當於電腦中的內存，內存空間越大同時支持的運行程序也就越多，較為常見的運行內存有6G、8G、12G等，甚至一些旗艦機型也支持32G的運行內存；後者相當於電腦中的硬碟，內存空間越大意味著能夠存儲更多的內容資源，包括下載的程序、照片、音頻、視頻等，較為常見的存儲內存有64G、128G、256G等，甚至一些旗艦機型也推出了512G以上的存儲內存。
手機廠商標稱的內存大小是否與我們實際使用的空間相同呢？
前不久岳雲鵬也因為在微博上提出了這個問題而上了熱搜！岳雲鵬購買了一款128G的手機，但是實際能夠使用的空間僅為112G，不僅發出了手機內存難道也存在「公攤面積」的疑問。無論是運行內存也好，還是存儲內存也罷，手機廠商採用的進制計算方式與系統不同，導致存在一定的偏差問題（一個採用的是1000進制，一個採用的是1024進制）。除了進制的問題外，手機內存還要被其他內容所佔用，例如運行內存開機之後的系統進程佔用，通常可供用戶使用的運行內存僅為總運行內存的一般，存儲內存需要安裝操作系統，系統的默認軟體等。
排除了這些基本因素外，再來說說智能手機剩餘內存為何會容易占滿的問題。
先來說說運行內存容易占滿的問題（因為運行機制的不同，這里主要討論的是安卓手機，蘋果手機很少會出現此類問題），主要的原因在於智能軟體的自行喚醒功能。智能手機現在所使用的軟體大部分為免費軟體，主要依靠用戶流量所帶來的廣告收益盈利。無論是前台還是後台，軟體運行才是獲得收益的前提，很多軟體或者是同廠軟體在沒有獲得用戶同意的前提下，會悄悄地自動進行喚醒，悄然運行在用戶的運行內存中，勢必會導致用戶運行內存逐漸占滿。工信部為此也擬定了個人用戶信息保護徵求意見稿，未經用戶許可的前提下，APP軟體不得自行喚醒或者更新。
那麼，存儲內存就是是何原因會逐漸占滿呢？
手機硬體的提升勢必會帶來更大的資源佔用，舉一個簡單的例子，現在供用戶手機拍照高清攝像頭成為了發展趨勢，之前一張照片或許僅為4M左右，現在一張照片將在20M以上，對於存儲的需求也越來越高。除此之外，出於個人信息安全的角度考慮，很多APP軟體並不會在伺服器端存儲用戶的個人數據，這一數據存儲在用戶的智能手機存儲內存，例如大家較為常用的微信、QQ等，隨著時間的推移，您會發現此類程序佔用的空間越來越高！
對於運行內存，我們可以通過設置、優化運行程序來降低其佔用率，確保手機不會因此而卡頓。不同品牌的手機都會自帶內存優化工具，以我手上的三星手機為例，可以在智能管理器、內存選項中查看當前的使用狀態，並且可以根據系統的提示進行內存優化。另外在手機設置、程序管理中，大家可以對具體的某款應用程序進行設置，關閉其後台自動喚醒的功能。對於手機操作並不是十分熟悉的用戶，可以下載三方手機優化軟體來自動對運行內存進行優化，不過個人並不建議如此操作，畢竟三方軟體也要耗費手機硬體資源。
對於存儲內存，只能夠是刪除不必要的數據進行優化。合理利用雲存儲是個不錯的方法，無論是手機自帶，還是三方雲存儲都能夠緩解我們存儲內存的壓力（只要能夠連接網路，有需求的數據直接從雲端下載即可）。對於微信、QQ此類占據空間的程序，只能夠通過刪除內容的方式來降低空間，為了方便也可以直接卸載、重新安裝來釋放空間。為了避免關鍵數據出現丟失，卸載之前可以將數據導致電腦端進行存儲，各款軟體基本上都提供了由手機向電腦進行數據遷移的功能。
關於手機內存總是不夠用的問題，是否也發生在您的手機上呢，最終又是如何解決的呢？歡迎大家留言討論，分享經驗。
手機佔用內存最大的就是系統和軟體，系統方面你可以通過刷機來改變大小，可以在手官網(或者其他大神資源)找一個自己機型的精減刷機包， 軟體方面你可以在安智市場裡面下載 歷史 版本，較小的軟體包可以減輕手機內存壓力，另外你還可以root手機，root後可以禁止軟體自啟，阻止軟體相互喚醒，刪除不需要的系統軟體，一星期左右可以關機一次，徹底釋放內存。
【手機總是容易滿內存，到底什麼占內存？】
手機的內存我們在這里一般稱為手機存儲數據的空間。一般它類似於電腦的硬碟，手機的內存基本上能夠給我們帶來的好處是讓我們手機能夠安裝更多的數據，存放更多的文件，不會因為手機內存的不足影響手機的流暢，讓手機卡頓。
我們在使用手機的過程中確實會擔心手機的內存不足，在我們手機內存不足的情況下，我們會建議大家考慮清理一些內存數據，這樣子的能夠讓手機的內存相對比較充足，手機會相對比較流暢。
特別是對於蘋果手機來說，蘋果手機如果內存不足的話，在日常使用過程中確實會出現非常嚴重的卡頓問題，手機在內存嚴重不足的情況下，能夠讓手機整體體驗值相對不高。
那麼，手機的內存到底是哪些那種東西呢？
手機的內存一方面指的是手機系統，手機本身的內置軟體所佔用的空間。也就是手機出產時，它所佔據的一部分的空間。這部分空間是固定的，除非是在系統之後升級，可能會有一定空間的變化，基本上是不會改變的。
手機內存另外一方面是我們在使用手機過程中下載的各種APP以及我們存儲的各種數據照片，視頻圖片等等。同樣還有我們在使用一些APP的時候會出現的一些緩存數據，特別像微信，它的緩存數據占據空間相對較大。
所以，我們在日常使用手機過程中，一定要注意清除手機APP中的一些緩存，這樣能保證手機的內存數據得到更好的使用，不會因為手機內存數據的不足影響手機的流暢。
手機內存分為運行內存（RAM，簡稱運存）和存儲內存（ROMZ）兩種。運行內存比較少，手機一般4G和6G居多。存儲內存較大，一般16G—512G，其中64G和128G居多。比如一款手機為「6+64G」的內存，就代表著6G的運行內存和64G的存儲內存。
運行內存是為手機運行的程序服務的，換句話說，就是儲存運行中的程序的這部分內存。手機不像電腦，當你退出一個程序後，這個程序不會直接關閉，而是在後台繼續運行。就比如當你在下載一部電影的時候，你返回桌面或者打開其他軟體，這部電影還在繼續下載。
只有2G運存的安卓機相信不少人都用過，只要後台運行的程序一多，分分鍾給你卡到原地爆炸。而反觀只有1G運存的蘋果卻從來不會出現這種情況，這是因為兩者的系統運行機制不同。蘋果的ios系統對於後台運行的軟體有很好的優化，系統只會分少量的資源給後台運行的應用。這樣即保證了後台應用的運行，也不會耽誤新程序的載入速度。而安卓系統就不同了，對於後台運行的程序沒有限制，所以後台一多，馬上變卡。
不過現在的安卓系統新增了一個叫Low Memory Killer（LMK）的後台程序管理機制。每當運行內存不足時，LMK都會自動關閉最不重要的後台程序來為新程序騰出運行內存和系統空間。所以現在的安卓機只要你不是開太多程序，4—6G的運行內存不會被占滿。
存儲內存相信大家更熟悉了，就是用來儲存數據的內存。手機中每個文件、軟體、圖片、視頻都需要佔用存儲內存。而且，隨著手機的使用，系統中的垃圾文件會越來越多，更新的軟體越來越大，導致內存不夠用。在這個一個QQ、微信動輒幾個G的時代，32G的手機內存是不夠用了。筆者建議大家最好買64G以上的手機，並且定期恢復出廠設置。
設置一下後台最多隻同時打開三個或四個應用軟體，其實安卓沒有必要那麼在乎還剩下多少內存，你會發現六個g和四個g內存佔用率都是差不多的。都剩下不了多少內存。系統會根據使用習慣把常用軟體從rom調入ram中供用戶隨時快速打來。
Ⅳ Android 怎麼將一個app 設置為持久app，不被low memory kill 關閉
app 持久 persistent
[Solution]
1. 將app 的manifest.xml 中的 application 中添加屬性 android:persistent="true"
2. 對這個APP 使用platform 的簽名
3. 放置在system/app 下面
注: 一個app 被設置為 persistent 後，將很難被low memory kill 殺掉(oom_adj=-12)，請在設置之前仔細確認是否必須，否則將浪費掉memory。
Ⅵ 怎樣使一個Android應用不被殺死
要讓android應用不被殺死，可以開啟一個service，一直檢測是否關閉了應用，一旦關閉馬上重新啟動。
當然首先要保證service不被殺死，應當提升service的優先順序，設為前台運行。也可以開啟兩個service互相檢測，一旦其中一個被關閉，另一個 馬上重啟對方。可以保證其生命穩定。這種方法也不是都行的，有些系統仍然能殺死。
Ⅶ 為什麼安卓後台運行的程序關掉後又自動重啟
安卓系統在後台有大量的程序運行，即使通過內存清理軟體清理後，過一會又有很多程序自動開始運行。由於安卓設計機制，當需要內存時，後台一些程序會自動關閉，釋放內存。
可以採取以下方法限制後台程序：
1.打開手機設置找到開發人員選項，點擊進入。
2.打開開發人員選項後，我們滑到最下方，找到後台進程限制，點擊。
3.選擇自己需要的模式。這里有6個選項，可根據自己需要選擇相應的模式，默認是標准限制，只在必要時關閉後台程序，建議選擇「不得超過4個進程」，限制太少的話會關閉一些需要的程序，比如。設置後系統會自動選擇重要的程序做後台，而很多垃圾軟體進程被自動清除。
另外對於一些集成應用不能卸載的可以在程序管理里停用的，可以結合一起使用。
Android採取了一種有別於Linux的進程管理策略，有別於Linux的在進程活動停止後就結束該進程，Android把這些進程都保留在內存中，直到系統需要更多內存為止。這些保留在內存中的進程通常情況下不會影響整體系統的運行速度，並且當用戶再次激活這些進程時，提升了進程的啟動速度。
Android是依據一個名為LRU（last recently used 最近使用過的程序）列表，將程序進行排序，並結束最早的進程。其實安卓的內存管理機制是這樣的，如下：
1.系統會對進程的重要性進行評估，並將重要性以「oom_adj」這個數值表示出來，賦予各個進程；（系統會根據「oom_adj」來判斷需要結束哪些進程，一般來說，「oom_adj」的值越大，該進程被系統選中終止的可能就越高）
2.前台程序的「oom_adj」值為0，這意味著它不會被系統終止，一旦它不可訪問後，會獲得個更高的「oom_adj」，我們推測「oom_adj」的值是根據軟體在LRU列表中的位置所決定的；
3.Android不同於Linux，有一套自己獨特的進程管理模塊，這個模塊有更強的可定製性，可根據「oom_adj」值的范圍來決定進程管理策略，比如可以設定「當內存小於X時，結束「oom_adj」大於Y的進程」。這給了進程管理腳本的編寫以更多的選擇。
Ⅷ 如何防止android程序被kill掉
如應用程序'Phone'的AndroidManifest.xml文件： ... 設置後app提升為系統核心級別，任何情況下不會被kill掉, settings->applications裡面也會屏蔽掉stop操作。 這樣設置前的log: Proc #19: adj=svc /B 4067b028 255:com.xxx.xxx/10001 (started-services) # cat /proc/255/oom_adj 4設置後的log: PERS #19: adj=core /F 406291f0 155:com.xxx.xxx/10001 (fixed) # cat /proc/155/oom_adj -12 # 這是CORE_SERVER_ADJ註：init進程的oom_adj為-16（即SYSTEM_ADJ）： cat /proc/1/oom_adjAndroid相關部分分析：在文件frameworks/base/services/java/com/android/server/am/ActivityManagerService.java中有以下的代碼： final ProcessRecord addAppLocked(ApplicationInfo info) { ProcessRecord app = getProcessRecordLocked(info.processName, info.uid); if (app == null) { app = newProcessRecordLocked(null, info, null); mProcessNames.put(info.processName, info.uid, app); updateLruProcessLocked(app, true, true); } if ((info.flags&(ApplicationInfo.FLAG_SYSTEM|ApplicationInfo.FLAG_PERSISTENT)) == (ApplicationInfo.FLAG_SYSTEM|ApplicationInfo.FLAG_PERSISTENT)) { app.persistent = true; app.maxAdj = CORE_SERVER_ADJ; // 這個常數值為-12。 } if (app.thread == null && mPersistentStartingProcesses.indexOf(app) < 0) { mPersistentStartingProcesses.add(app); startProcessLocked(app, "added application", app.processName); } return app; }可見要想成為core service （即app.maxAdj = CORE_SERVER_ADJ(-12)），應用程序需要FLAG_SYSTEM和FLAG_PERSISTENT兩個標志，FLAG_SYSTEM指的是應用位於/system/app下，FLAG_PERSISTENT就是指persistent屬性。而對於frameworks/base/services/java/com/android/server/SystemServer.java，則調用 ActivityManagerService.setSystemProcess();把自己的 app.maxAdj 設置成SYSTEM_ADJ，即-16。原理：Android中的進程是託管的，當系統進程空間緊張的時候，會依照優先順序自動進行進程的回收。由此帶來三個問題： 1） 回收規則: 什麼時候回收與回收哪一個？ 2） 避免誤殺: 如何阻止被回收？ 3） 數據恢復與保存: 被回收了怎麼辦？ Android將進程分為6個等級,它們按優先順序順序由高到低依次是: 1.前台進程( FOREGROUND_APP) 2.可視進程(VISIBLE_APP ) 3. 次要服務進程(SECONDARY_SERVER ) 4.後台進程 (HIDDEN_APP) 5.內容供應節點(CONTENT_PROVIDER) 6.空進程(EMPTY_APP) 特徵：1.如果一個進程裡面同時包含service和可視的activity，那麼這個進程應該歸於可視進程，而不是service進程。2.另外，如果其他進程依賴於它的話，一個進程的等級可以提高。例如，一個A進程里的service被綁定到B進程里的組件上，進程A將總被認為至少和B進程一樣重要。3.系統中的phone服務被劃分到前台進程而不是次要服務進程. 在android中，進程的oom_adj值也就代表了它的優先順序。oom_adj值越高代表該進程優先順序越低。
Ⅸ 怎麼讓 Android 程序一直後台運行，像 QQ 一樣不被殺死
1、首先要保證你的程序一直在於後台運行，也就是所謂和守護程序一樣，而且在任何認為kill和系統內存回收kill後，保證重啟。
2、獲取系統內部資源。
3、上報策略，間隔時間上報還是按月按天上報。
4、監測網路，當網路開啟的時候第一時間上報數據。
5、伺服器連接。
對於以上問題的解決：
1、利用廣播BroadcastReceiver監聽，當系統啟動時啟動服務service，監聽的action是
android.intent.action.BOOT_COMPLETED，當服務被kill時在onDestroy()再次啟動服務，在
onStartCommand()中 設置 flags = START_STICKY;return
super.onStartCommand(intent, flags, startId)，保證服務重啟。
2、利用getPackageManager(),getInstalledPackages(),getApplicationInfo()來獲取系統安裝數據。
3、上報策略可以每天（時間間隔24小時），但是不是很准確，一般按日上報不做時間間隔這樣個人認為比較准確。
4、檢測開啟網路上報數據，還是利用廣播BroadcastReceiver監聽，監聽action為android.net.conn.CONNECTIVITY_CHANGE，當發現網路開啟時就觸發數據上報。
5、伺服器連接，如果你了解java熟悉java企業級開發，那麼你對httpclient並不陌生，很幸運的是android sdk已經集成了httpclient，那我們伺服器連接首選它了。
以上是我做的解決方案，你是否有更好的替代品，希望我只是拋了塊磚頭，後面你繼續。。。。
service被系統異常kill掉後回重啟。有以下值：
onStartCommand有三種返回值：
START_STICKY：sticky的意思是「粘性的」。使用這個返回值時，我們啟動的服務跟應用程序」粘」在一起，如果在執行完onStartCommand後，服務被異常kill掉，系統會自動重啟該服務。當再次啟動服務時，傳入的第一個參數將為null;
START_NOT_STICKY：「非粘性的」。使用這個返回值時，如果在執行完onStartCommand後，服務被異常kill掉，系統不會自動重啟該服務。
START_REDELIVER_INTENT：重傳Intent。使用這個返回值時，如果在執行完onStartCommand後，服務被異常kill掉，系統會自動重啟該服務，並將Intent的值傳入。
Ⅹ android源碼下 怎麼修改內存閥值
android源碼下 修改內存閥值的方法為：
第一步:首先建立一個XXX.txt文件，輸入以下代碼:
#!/system/bin/sh
echo "1536,2048,4096,6144,8192,12288" > /sys/mole/lowmemorykiller/parameters/minfree ;
這個代碼是基於MFM配置3對應的數值，用了幾天這個數值了沒發現問題，所以暫時以這個數值為例。
然後保存，將保存好的XXX.txt文件修改為67-Jasonfix
將這個67-Jasonfix文件用RE管理器放入system/etc/init.d下(這個文件夾裡面都是開機腳本設定。
然後將許可權改為：全部打鉤。
第二步:修改install-recovery.sh(在system/etc目錄下)
(1).找到這些腳本所在行
sh /system/etc/init.d/XXXXX
對應加入
sh /system/etc/init.d/67-Jason
(2).然後找到
echo A,B,C,D,E,F /sys/mole/lowmemorykiller/parameters/minfree
刪除這行並保存即可。