一:概念
1 进程概念
每个App在启动前必须先创建一个进程,该进程是由Zygote fork出来的,进程具有独立的资源空间,用于承载App上运行的各种Activity/Service等组件。
2 同一个应用定义多进程的方式
大多数情况一个App就运行在一个进程中,除非在AndroidManifest.xml中配置Android:process属性,或通过native代码fork进程。
3 分类
Android中的进程分为用户进程和内核进程。
kthreadd进程:所有内核进程的父进程。
init进程:所有用户进程的父进程。
其中用户进程中的几个重要进程:
zygote进程:是上层所有java进程的父进程。由init进程fork而来。
system_server进程:承载java层framwork的所有serveices进程,由zygote进程fork而来。
mediaserver进程:托起整个c++ framework的所有service进程,有init进程孵化而来。
servicemanager进程:管理整个Binder架构, 由init进程孵化而来。
4 android进程间通信的方式
4.1 Binder
activity启动Activity,启动Service,ContentProvider的本质都是Binder进程间通信机制。AIDL也是IPC机制的一种实现,本质也是通过Binder去实现的。
4.2 Socket
创建一个Process的时候,是通过system_server进程调用Process.start()方法请求Zygote进程去创建进程的,这种方式是通过Socket去完成的。
二:进程管理机制
1 App启动内存机制:
Android系统的设计理念正是希望应用进程能尽量长时间地存活,以提升用户体验。应用首次打开比较慢,这个过程有进程创建以及Application等信息的初始化,所以应用在启动之后,即便退到后台并非立刻杀死,而是存活一段时间,这样下次再使用则会非常快。
2 LMK策略:
为了防止剩余内存过低,Android在内核空间有LowMemoryKiller(简称LMK),是一种根据阈值级别触发相应力度的内存回收的机制。其依据就是进程优先级的量化指标:ADJ值。
ADJ值定义在ProcessList.java中。
从Android 7.0开始,ADJ采用100、200、300;在这之前的版本ADJ采用数字1、2、3,这样的调整可以更进一步地细化进程的优先级,比如在VISIBLE_APP_ADJ(100)与PERCEPTIBLE_APP_ADJ(200)之间,可以有ADJ=101、102级别的进程。
下表列出了进程adj值对应的情景:
3 查看进程ADJ值的方法:
3.1
cat /proc/[PID]/oom_adj: 使用该命令会直接显示出对应进程号的adj值,这种方式在Android N以后会因为权限问题无法查看
cat /proc/[PID]/oom_score,查看计算出的优先级值,这种方式在O上仍然可以用
3.2
dumpsys meminfo
使用dumpsys meminfo命令时,会列出当前系统的所有进程,不同进程放入不同的分类,对应的分类名基本与lmk的分类一致。
4 进程保护策略
4.1 开启一个像素的Activity
据说这个是手Q的进程保活方案,基本思想,系统一般是不会杀死前台进程的。所以要使得进程常驻,我们只需要在锁屏的时候在本进程开启一个Activity,为了欺骗用户,让这个Activity的大小是1像素,并且透明无切换动画,在开屏幕的时候,把这个Activity关闭掉,所以这个就需要监听系统锁屏广播
4.2 前台服务
这种大部分人都了解,据说这个微信也用过的进程保活方案,这方案实际利用了Android前台service的漏洞。
原理如下
对于 API level < 18 :调用startForeground(ID, new Notification()),发送空的Notification ,图标则不会显示。
对于 API level >= 18:在需要提优先级的service A启动一个InnerService,两个服务同时startForeground,且绑定同样的 ID。Stop 掉InnerService ,这样通知栏图标即被移除。
无论是QQ还是微信的进程保活策略都是通过提高进程优先级,降低adj的方式去实现,但是除非厂商愿意将你的应用加入清理白名单,否则在app层面是无法做到真正的进程不死,只能是尽量保证进程不被kill。
5 Kill进程的方式
5.1 Process.killProcess(pid)方式
Process.killProcessQuiet(pid)
用户空间流程:
Process.killProcess()-->Process.sendSignal()-->
android_util_Process. android_os_Process_sendSignal()-->kill()
注意:
kill()之后就进入内核空间调用的是内核的相关方法去完成杀进程的操作。
另外需要注意的调用这种方式杀进程,如果进程中有服务是在被杀掉以后重启的,那么是需要重启进程的,意思是说这种方式针对有这种服务的进程相当于先杀死在启动的,重启一下而已(在Log中会看到类似Scheduling restart of crashed service的信息)。
5.2 Force-stop方式:
AM.forceStopPackage(packageName) 这个是隐藏api,并且需要force-stop系统级权限
流程:
1)AMS.forceStopPackage(final String packageName, int userId);
2)AMS.forceStopPackage()-->
AMS.finishForceStopPackageLocked()
3)AMS.forceStopPackageLocked()-->
4)AMS.forceStopPackageLocked(9参的)
注意:
1)force-stop并不会杀persistent进程,当指定用户userId时,不杀其他用户空间的进程。
2)当app被force-stop后,无法接收到任何普通广播,那么也就常见的监听手机网络状态的变化或者屏幕亮灭的广播来拉起进程肯定是不可行;
3)当app被force-stop后,那么alarm闹钟一并被清理,无法实现定时响起的功能;
4)app被force-stop后,四大组件以及相关进程都被一一剪除清理,即便多进程架构的app也无法拉起自己;
5)级联诛杀:当app通过ClassLoader加载另一个app(在后一个app的ProcessRecord的pkgDeps中会有前一个app的包名信息,则杀掉后一个app,前一个app也会被干掉),则会在force-stop的过程中会被级联诛杀;
6)生死与共:当app与另个app使用了share uid,则会在force-stop的过程,任意一方被杀则另一方也被杀,建立起生死与共的强关系。
5.3 killBackgroundProcesses方式
流程:
AM.killBackgroundProcesses(String packageName)
--> AMS.killBackgroundProcesses(final String packageName, int userId)
--> killPackageProcessesLocked();
同样会调用到killPackageProcessesLocked方法杀进程,只不过入参adj的设定值是ProcessList.SERVICE_ADJ即500,进程Adj值大于这个才会执行后续杀进程方法,否则continue。这个方法需要添加权限KILL_BACKGROUND_PROCESSES(不是系统权限)。
5.4 adb shell中执行 kill +pid的命令杀进程,这种方式最后也是调用的Process. killProcess()方法杀进程。但是没有killing 相关的log打印出。这种方式需要root权限。
5.5 adb shell am force-stop +包名。这种方式会调用到AMS的forceStopPackage方法,因此会有相应log打出,需要root权限。
若使用Runtime去执行的话,也是需要force-stop权限的,系统级权限。