android进程常驻

❶ 进程保活

一 、问：什么是进程保活？

答：进程保活就是进程永远存在内存中，是杀不死的，就算杀死了也会有办法重新启动起来，其实这些并不是流氓手段，很多情况下，如果你想给你的用户提供服务，就必须有一个进程常驻着，便于在特定的时候做一些特定的事情，比如广播接受者，他就不支持静态注册，也就是说如果我们想接受屏幕开关启动的广播，必须要在进程中动态注册，这个时候如果没有一个常驻的进程，锁屏业务就无法正常的为用户展开服务。

二、问：进程是怎么死掉的呢？

答：其实进程被杀死的原因，一方面是人为的，二、可能被第三方应用杀死，如杀敌软件等。

三、问：android进程的优先级？

答：

  1、前台进程 （Foreground process）：用户当前操作所在的进程，当内存不足以承担前台进程的使用，才有可能回收

  2、可见进程（Visible process）:没有任何前台组件，但是仍然会影响屏幕上所见内容，他是一种极为重要的进程，除非为了维持前台进程，因内存不足，有可能会回收掉可见进程，否则系统是不会回收可见进程。

  3、服务进程（Service process）:他与用户所见的内容是没有直接关联，但是他们通常执行一些用户关心的操作，比如说在后台获取网络数据，后台播放音乐，后台进行一些数据计算等。被杀死的原因：也是为了

  支持前台进程和可见进程，因内存不足情况下才会被回收。

  4、后台进程（BaclGround process）:对用户的体验没有直接的影响，用户可以随时终止他们，这个进程是为了供给上面三个进程来使用的，通常在后台进程运行着很多操作，他们保存在一个列表当中，为了确保用户最近查看Activit的进程最后一个被终止，他是一个LRU算法，

  5、空进程（Empty process） :保存这个进程的唯一目的就是用来做缓存，以缩短下次在运行组件所需的启动时间，为了使系统总体的资源在进程缓存和内存底层之间保持平衡。它是不包括任何组件的进程.

四、问：Android进程的回收策略？

答：Android进程的回收策略主要是通过Low memory killer机制来完成的。

  Low memory killer：通过一些比较复杂的评分机制，对进程进行打分，然后讲分数的进程判定为bad进程，杀死并释放内存。Low memory killer是定时进行检查的，它主要是通过进程的OOM_ODJ来判断进程的优先级。当OOM_ODJ的值越小，进程的优先级越高，而OOM_ODJ越不会去回收。反之就会被回收。

  注意：Low memory killer和out memory不一样的地方：out memory机制只有当系统内存不足的时候才会启动检查，而Low memory killer是定时进行检查的，它主要是通过进程的OOM_ODJ来判断进程的优先级。

五、问：进程保活方案？

答：Android进程的回收策略主要是通过Low memory killer机制来完成的。

  1、利用系统广播拉活，在发生系统事件的时候，系统会发出相应的广播，

    详情查看：http://blog.csdn.NET/sunshinetan/article/details/53126857

  2、利用系统Service机制拉活，在Service有一个onStartCommand

    推荐博客：http://blog.csdn.net/wulianghuan/article/details/8596467

    Android开发的过程中，每次调用startService(Intent)的时候，都会调用该Service对象的onStartCommand(Intent,int,int)方法，然后在onStartCommand方法中做一些处理。然后我们注意到这个函数有一个int的返回值，这篇文章就是简单地讲讲int返回值的作用。从Android官方文档中，我们知道onStartCommand有4种返回值：

    START_STICKY：如果service进程被kill掉，保留service的状态为开始状态，但不保留递送的intent对象。随后系统会尝试重新创建service，由于服务状态为开始状态，所以创建服务后一定会调用onStartCommand

    (Intent,int,int)方法。如果在此期间没有任何启动命令被传递到service，那么参数Intent将为null。（service因内存不足的情况下，杀死的进程才可以拉活，这里要特别注意，不是所有情况都可以拉活。第一次server被杀死后，会在5秒后拉活，第二次会在10秒后，第三次会在20秒后。之后就不会在拉活。第二种情况是获得root权限通过stop停止的，也是无法通过server拉活）

    START_NOT_STICKY：“非粘性的”。使用这个返回值时，如果在执行完onStartCommand后，服务被异常kill掉，系统将会把它置为started状态，系统不会自动重启该服务，直到startService(Intent intent)方法再次被用;。

    START_REDELIVER_INTENT：重传Intent。使用这个返回值时，如果在执行完onStartCommand后，服务被异常kill掉，系统会自动重启该服务，并将Intent的值传入。

    START_STICKY_COMPATIBILITY：START_STICKY的兼容版本，但不保证服务被kill后一定能重启。

  3、利用Native进程拉活，

  4、利用JobScheler机制拉活：Android5.0之后提供的一个机制，他会监听主进程的存活，如果死掉就会激活拉活进程。

  5、利用账号同步机制拉活：android系统有一个账户系统，设置一个自己的账户，android会定期唤醒账户更新服务。我们可以自己设定同步的事件间隔，且发起更新的是系统，不会受到任何限制。需要在 AndroidManifest 中定义账号授权与同步服务。

    Android 版本（Android N）中系统对账户同步这里做了变动，该方法不再有效。

    缺点：

          a.用户会在系统设置的账户列表里面看到一个不认识的账户；

          b.同步的事件间隔是有限制的，最短1分钟，见源码，如果小雨60秒，置为60秒；

          c.用户可以卸载账户；

          d.必须联网！google提供这个组件是让你同步账户信息，不联网就不能保活！

❷ Android后台进程保活方案

思想： 使用 Linux 中的 fork 机制创建 Native 进程，在 Native 进程中监控主进程的存活，当主进程挂掉后，在 Native 进程中立即对主进程进行拉活。

原理： 在 Android 中所有进程和系统组件的生命周期受 ActivityManagerService 的统一管理。Android5.0以下通过 Linux 的 fork 机制创建的进程为纯 Linux 进程，其生命周期不受 Android 的管理。

该方案主要适用于 Android5.0 以下版本手机。

该方案不受 forceclose 影响，被强制停止的应用依然可以被拉活，在 Android5.0 以下版本拉活效果非常好。
详情

对于 Android5.0 以上手机，系统虽然会将native进程内的所有进程都杀死，这里其实就是系统“依次”杀死进程时间与拉活逻辑执行时间赛跑的问题，如果可以跑的比系统逻辑快，依然可以有效拉起。在 某些 Android 5.0 以上机型有效。
详情

https://github.com/Marswin/MarsDaemon

作者5.0以下系统用一个java进程和一个fork出来的纯native进程双管道互锁监听对方的状态，无论哪个被杀后都拉起第三个进程，第三个进程来拉活常驻进程，实现拉活。
5.0以上同一进程组的进程会被同时杀死，所以5.0以上使用双java进程在native层互锁文件实现监听，但任务管理器会在短时间内杀死所有进程，只能用反射提前初始化pacel，在进程被杀的时候和系统抢那几十毫秒的时间发送一个拉活的广播。用4个文件来让两个进程实现互锁来做监听，但实际效果很一般，测试了几个5.0以上的国产机型都不行，效果是根本监听不到进程被杀，目测原因是当任务管理器查杀进程的时候将所有的进程都挂起了，随后全部杀掉，并在一段时间内禁止进程启动。

PersistedJobService.java

BootReceiver.java静态注册BroadcastReceiver

注册，开机，网络切换、拍照、拍视频时候，利用系统产生的广播也能唤醒app，不过Android N已经将这三种广播取消了

常用的拉活权限

BackgroundService.java
WakeLock

作为前台应用运行，提高应用存活几率

service被关掉后自动启动

START_STICKY
如果系统在onStartCommand返回后被销毁，系统将会重新创建服务并依次调用onCreate和onStartCommand（注意：根据测试Android2.3.3以下版本只会调用onCreate根本不会调用onStartCommand，Android4.0可以办到），这种相当于服务又重新启动恢复到之前的状态了）。

START_NOT_STICKY
如果系统在onStartCommand返回后被销毁，如果返回该值，则在执行完onStartCommand方法后如果Service被杀掉系统将不会重启该服务。

START_REDELIVER_INTENT
START_STICKY的兼容版本，不同的是其不保证服务被杀后一定能重启。

service注册，权限设置为高优先级

KeepAliveService.java
注册，在新的独立进程内启动，适用5.0以下的原生系统，5.0以上同样会被杀死

他的局限性在于：
第一，用户会在系统设置的账户列表里面看到一个不认识的账户；
第二，同步的事件间隔是有限制的，最短1分钟，见源码，如果小雨60秒，置为60秒。而且各种国产机怎么改的源码我们未可知，是不是都能用仍然未可知；
第三，很致命，某些手机比如note3需要手动设置账户，你如何骗你的用户给你手动设置账户完了之后不卸载你；
第四，也很致命，必须联网！google提供这个组件是让你同步账户信息，不联网你同步个鬼，我们要保活，可以不联网不做事，但是不能不联网就死

集成三方推送平台sdk，友盟极光等

❸ android后台服务保持，不被杀死

作者：闭关写代码
链接：https://www.hu.com/question/29826231/answer/71207109
来源：知乎
着作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

强烈建议不要这么做，不仅仅从用户角度考虑，作为Android开发者也有责任去维护Android的生态环境。现在很多Android开发工程师，主力机居然是iPhone而不是Android设备，感到相当悲哀。
从技术角度概括一下现在普遍的防杀方法

Service设置成START_STICKY，kill 后会被重启（等待5秒左右），重传Intent，保持与重启前一样
通过 startForeground将进程设置为前台进程，做前台服务，优先级和前台应用一个级别，除非在系统内存非常缺，否则此进程不会被 kill

双进程Service：让2个进程互相保护，其中一个Service被清理后，另外没被清理的进程可以立即重启进程
QQ黑科技:在应用退到后台后，另起一个只有 1 像素的页面停留在桌面上，让自己保持前台状态，保护自己不被后台清理工具杀死
在已经root的设备下，修改相应的权限文件，将App伪装成系统级的应用（Android4.0系列的一个漏洞，已经确认可行）
Android系统中当前进程(Process)fork出来的子进程，被系统认为是两个不同的进程。当父进程被杀死的时候，子进程仍然可以存活，并不受影响。鉴于目前提到的在Android-Service层做双守护都会失败，我们可以fork出c进程，多进程守护。死循环在那检查是否还存在，具体的思路如下（Android5.0以下可行）
用C编写守护进程(即子进程)，守护进程做的事情就是循环检查目标进程是否存在，不存在则启动它。
在NDK环境中将1中编写的C代码编译打包成可执行文件(BUILD_EXECUTABLE)。
主进程启动时将守护进程放入私有目录下，赋予可执行权限，启动它即可。
联系厂商，加入白名单
------------------------------------------------------
TIP: 面对各种流氓软件后台常驻问题，建议使用“绿色守护”来解决，可是杀掉那些第三方清理工具难以清除的后台程序

❹ android push 推送服务 如何做到app进程被清理掉还能收到推送 我看有少部分应用做到了

❺ 想让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文件中设置（如上）。