我们总是不想自己的Android service被系统清理,以前时候大家最常用的办法就是在JNI里面fork出子进程,然后监视 service进程状态,被系统杀死了就重启它.
我分别在android4.3和android5.0上面测试了LBE的清理内存功能,看看是不是会达到不被清理的目的,发现在这两个版本上还是有一些区别的
先说一下我们的代码,我们的service在单独的进程中,在service中调用JNI的代码,然后fork出一个进程,然后让我们的service进程和fork出来的子进程一直运行.
看清理之后的状态
android4.4上面,JNI fork出来的进程没有被杀死,可以把被杀死的service进程重启
android5.0上面还有效么?清理内存操作之后,可以看到fork出来的进程也会被杀死..看来这种方法已经失效了..
为什么5.0上面就不行了呢,咱们看一下activitymanagerservice,LBE的清理内存应该调用的killBackgroundProcesses,看看他们有什么区别
5.0的代码
Process.killProcessQuiet(app.pid);Process.killProcessGroup(app.info.uid, app.pid);
4.3的代码
Process.killProcessQuiet(pid);
5.0的代码增加了killprocessgroup..
看来fork进程的方式来让android服务常驻内存的方式在5.0上面不管用了…
Android 5.0以后防止Service被清理的挑战
在Android 4.3和5.0上,开发者尝试通过JNI fork子进程来保持Service不被系统清理。在4.3上,这种方法有效,子进程能在Service被杀死后重启它。然而,在5.0上,由于`killProcessGroup`的引入,fork出来的进程也会被一同清理,导致这种方法失效。这表明Android系统在不同版本间对后台进程管理的策略有所改变,影响了Service的持久运行策略。
884

被折叠的 条评论
为什么被折叠?



