安卓的后台机制既是安卓的一个优势，也是碎片化很严重的一个特性，作为三款依赖安卓后台服务的App的开发者，写下这篇文章来比较一下EMUI和MIUI这两个最常见的安卓系统的后台处理逻辑，先把要比较的系统列一下：
- EMUI 10.0.0， Android 10
- MIUI 12.0.6， Android 10
比较后台机制的前提是两个系统均使用缺省设置，不考虑诸如省电模式、极简模式等特殊情况，这样符合大部分用户的使用情况。
概述
常见的安卓App驻留后台方式有三种：
- 注册系统服务，比如无障碍服务
- 使用安卓定时服务
- 常驻通知栏的前台服务，即Foreground Service
这三种后台模式，我都开发过相应的App，下面会分别举例来比较。除此以后，还有一些匪夷所思，也非官方认可的谋取驻留后台的方式，比如播放一个无声的音乐、开启一个单像素的悬浮窗等等，毕竟不属于正道，本文就不比较了。
在比较之前，有必要说明一下，对于现在各厂商安卓系统，比如我们要比较的EMUI和MIUI，仅仅按照这种正规方式注册服务是不够的，还是很容易被系统冻结或杀掉，原因是因为按正规方式注册服务，所有的应用都可以做到，后台多了，加上一些应用没有节制，手机就必然卡顿费电，所以厂商们的做法也很好理解，默认全杀，做一个只能手工配置的白名单，用户加入白名单才允许后台服务，这样对于大部分普通用户，不用做任何设置就免受恶意软件之苦。
需要注意，不同系统白名单配置稍有不同：
- MIUI 设置 》应用设置 》应用管理 》选择应用 》 设置省电策略、自启动
- EMUI 设置 》 应用 》 应用启动管理 》 选择应用 》 设置允许后台活动、自启动
下面开始测试三种后台方式。
无障碍服务
我开发的微动手势，就是一个典型的无障碍服务类应用，安卓系统支持应用注册为无障碍服务，无障碍服务不仅提供了一种驻留后台的方法，其本身还提供了很多普通应用无法做到的功能，比如模拟系统交互、模拟手势等。所以很多安卓App都借助无障碍服务来完成某些功能，比如就连抖音App都提供了一个无障碍服务。
这里就以微动手势为例，安装完成并打开无障碍服务，然后我分别测试以下四种情况：
- 默认：就是默认安装后不做任何设置
- 加锁：在多任务界面中给应用的卡片加锁
- 白名单：在系统中将应用加入后台白名单
- 锁+白名单：上面两个都设置
每种情况下我进行四种操作测试，这四种情况都是用户常做的一些操作，然后判断微动手势的后台是否工作正常，四种操作分别如下：
- 锁屏：锁屏等一分钟后再解锁
- 划卡片：直接在多任务页面中划去应用
- 一键清理：在多任务页面中点一键清理
- 耗尽内存：通过启动多个大型软件或游戏挤占剩余内存
测试结果，我绘制表格如下：
| EMUI | MIUI | EMUI(加锁) | MIUI(加锁) | EMUI(白名单) | MIUI(白名单) | EMUI(锁+白名单) | MIUI(锁+白名单) | |
|---|---|---|---|---|---|---|---|---|
| 锁屏 | 正常 | 冻结 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 |
| 一键清理 | 被杀 | 被杀 | 正常 | 正常 | 正常 | 被杀 | 正常 | 正常 |
| 划卡片 | 被杀 | 被杀 | 被杀 | 被杀 | 正常 | 被杀 | 正常 | 被杀 |
| 耗尽内存 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 |
我们仔细看下这里的结果，明显MIUI比EMUI的后台控制更严格，大概总结一下：
- MIUI认为用户操作优先于用户白名单，所以即使加入白名单，通过划卡片依然将应用杀掉。
- EMUI认为用户白名单优先，只要加入白名单，用户即使划卡片，后台都能正常保留，只将前台界面关闭。
两种方式孰优孰劣，我不做评价，但显然MIUI的方式，如果想保留后台，用户在设置白名单之后，还需要加锁并小心避免划卡片。提醒一点，如果你在系统里同时为应用设置了允许自启动，那么一些后台应用在被杀之后会立刻重启，也就是杀的效果变成了重启。
定时服务
这里说的定时服务是个统称，指借助安卓的某个"定时"API来实现一个定时运行的后台，安卓自己在这里也很乱，前前后后提供了AlarmManager、JobSchedule、WorkManager等很多不兼容的API来支持后台的定时任务，我这里统称为定时服务，我开发的碎片记忆就是典型的定时服务，这是一个背单词的应用，需要定时来检查卡片是否需要复习，然后自动从后台弹出。
依然按上述测试方法，结果如下：
| EMUI | MIUI | EMUI(加锁) | MIUI(加锁) | EMUI(白名单) | MIUI(白名单) | EMUI(锁+白名单) | MIUI(锁+白名单) | |
|---|---|---|---|---|---|---|---|---|
| 锁屏 | 正常 | 冻结 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 |
| 一键清理 | 被杀 | 被杀 | 正常 | 正常 | 被杀 | 被杀 | 正常 | 正常 |
| 划卡片 | 被杀 | 被杀 | 被杀 | 被杀 | 被杀 | 被杀 | 被杀 | 被杀 |
| 耗尽内存 | 被杀 | 被杀 | 被杀 | 正常 | 正常 | 被杀 | 正常 | 正常 |
从这个结果来看，定时服务相对无障碍服务，优先级要低一些，在某些无障碍服务仍然可以正常工作的场景下（比如划卡片和内存耗尽），定时服务就被杀了，不过这次MIUI和EMUI表现的相对一致一些。
这里有一点值得一提，安卓提供的定时机制里，有一部分是允许应用被杀后依然能被定时唤醒的，但这样的话，恶意软件显然可以利用这一点做到永生不死，所以像EMUI和MIUI这样的系统对这种定时都做了额外的限制，这里不再展开详述了。
前台服务
Android的前台服务是一个术语：Foreground Service，表示用户可以感知到的后台服务，所以会在通知栏给出一个常驻通知，这是很多应用使用的后台机制，我开发的电池守护就使用了这个机制，通过这个机制，让应用可以在后台获取电量变化信息，从而对用户进行充电或拔除充电器的告警。
依然使用相同的测试方法，测试结果如下：
| EMUI | MIUI | EMUI(加锁) | MIUI(加锁) | EMUI(白名单) | MIUI(白名单) | EMUI(锁+白名单) | MIUI(锁+白名单) | |
|---|---|---|---|---|---|---|---|---|
| 锁屏 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 |
| 一键清理 | 被杀 | 被杀 | 正常 | 正常 | 正常 | 被杀 | 正常 | 正常 |
| 划卡片 | 被杀 | 被杀 | 被杀 | 被杀 | 正常 | 被杀 | 正常 | 被杀 |
| 耗尽内存 | 被杀 | 正常 | 被杀 | 正常 | 正常 | 正常 | 正常 | 正常 |
从耗尽内存的测试结果来看，前台服务的优先级级似乎介于无障碍服务和定时服务之间，并且EMUI和MIUI依然有不小的差异。
总结
从上面的测试来看，无障碍服务、定时服务、前台服务几种服务类型之间有微妙的差异。而且MIUI和EMUI的的处理也有不少的差异，从我测试的两个版本看，MIUI更严苛一些，某些情况下EMUI不杀，MIUI会杀。对于开发者来说这是比较痛苦的事情，而对于用户来说，就更难理解这些细微的差异了。好在添加白名单和加锁之后，基本上还是能保住后台，所以这类需要后台的应用，通常只能引导用户去做这些设置。
这个测试只对比了MIUI和EMUI，我相信谷歌原生、三星以及其他厂商还是会有更多的差异，安卓的碎片化可见一斑。
网友评论