深度比较EMUI和MIUI后台处理

安卓的后台机制既是安卓的一个优势，也是碎片化很严重的一个特性，作为三款依赖安卓后台服务的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，我相信谷歌原生、三星以及其他厂商还是会有更多的差异，安卓的碎片化可见一斑。