安卓的后台机制既是安卓的一个优点,也是碎片化很严重的一个特性,做为三款依赖安卓后台服务的App的开发者,写下这篇文章来比较一下EMUI和MIUI这两个最多见的安卓系统的后台处理逻辑,先把要比较的系统列一下:app
比较后台机制的前提是两个系统均使用缺省设置,不考虑诸如省电模式、极简模式等特殊状况,这样符合大部分用户的使用状况。测试
常见的安卓App驻留后台方式有三种:游戏
这三种后台模式,我都开发过相应的App,下面会分别举例来比较。除此之后,还有一些匪夷所思,也非官方承认的谋取驻留后台的方式,好比播放一个无声的音乐、开启一个单像素的悬浮窗等等,毕竟不属于正道,本文就不比较了。内存
在比较以前,有必要说明一下,对于如今各厂商安卓系统,好比咱们要比较的EMUI和MIUI,仅仅按照这种正规方式注册服务是不够的,仍是很容易被系统冻结或杀掉,缘由是由于按正规方式注册服务,全部的应用均可以作到,后台多了,加上一些应用没有节制,手机就必然卡顿费电,因此厂商们的作法也很好理解,默认全杀,作一个只能手工配置的白名单,用户加入白名单才容许后台服务,这样对于大部分普通用户,不用作任何设置就免受恶意软件之苦。开发
须要注意,不一样系统白名单配置稍有不一样:get
下面开始测试三种后台方式。table
我开发的微动手势,就是一个典型的无障碍服务类应用,安卓系统支持应用注册为无障碍服务,无障碍服务不只提供了一种驻留后台的方法,其自己还提供了不少普通应用没法作到的功能,好比模拟系统交互、模拟手势等。因此不少安卓App都借助无障碍服务来完成某些功能,好比就连抖音App都提供了一个无障碍服务。后台
这里就以微动手势为例,安装完成并打开无障碍服务,而后我分别测试如下四种状况:软件
每种状况下我进行四种操做测试,这四种状况都是用户常作的一些操做,而后判断微动手势的后台是否工做正常,四种操做分别以下:配置
测试结果,我绘制表格以下:
EMUI | MIUI | EMUI(加锁) | MIUI(加锁) | EMUI(白名单) | MIUI(白名单) | EMUI(锁+白名单) | MIUI(锁+白名单) | |
---|---|---|---|---|---|---|---|---|
锁屏 | 正常 | 冻结 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 |
一键清理 | 被杀 | 被杀 | 正常 | 正常 | 正常 | 被杀 | 正常 | 正常 |
划卡片 | 被杀 | 被杀 | 被杀 | 被杀 | 正常 | 被杀 | 正常 | 被杀 |
耗尽内存 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 | 正常 |
咱们仔细看下这里的结果,明显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,我相信谷歌原生、三星以及其余厂商仍是会有更多的差别,安卓的碎片化可见一斑。