隐私、发烧和停滞都来自这个操作。 　　

　　最近小米MIUI的一个更新引起了轩然大波。 　　

　　小米最新的操作系统MIUI 12有一个功能叫做“flare”。顾名思义，这个功能就是把以前在黑暗中的东西暴露在强光下，让用户一眼就能看到。 　　

　　在“flare”中，用户可以看到应用程序的“自启动”、被其他应用程序启动、读取设备数据等具体行为。而手机app之前未知的动作一目了然。 　　

　　MIUI12耀斑功能截图，左侧为App自启动情况，右侧为App | MIUI唤醒情况 　　

　　个别应用在后台“反复横跳”，频繁推出各种“家庭水桶”应用，读取用户隐私信息。这些问题在社交网络上的数字圈和产品圈引起了很多讨论。为什么这些应用程序会在后台反复刷数据？对于开发者来说，自启动和读取数据有什么好处？普通用户应该如何防范？ 　　

　　#刷用户，接收数据，启动APP为了什么？ 　　

　　App自启动并不是什么新鲜事。安卓平台也赋予了开发者这种能力，但在商业语境中经常被滥用。 　　

　　了解应用程序 　　

　　自启动，首先要了解安卓的核心。这是一个开放和开源的平台，旨在被尽可能多的设备使用。所以对于安卓来说，它想覆盖的不仅仅是手机市场，还有很多基于场景的设备，比如广告机、自助售票机。 　　

　　如果想要收获更多的应用场景，就必须有足够的接口支持。对于广告机等设备，只需要自动启动应用，即插即用即可。所以安卓在设计之初就支持应用自启动，这是需求。 　　

　　应用程序可以通过调用应用编程接口来实现。 　　

　　安卓本来是好的，但是被一些开发者打破了。由于可以自启动，一些 App 就开始利用这个 API 接口暗戳戳地自己启动自己，一方面刷 　　

　　另一方面，DAU(每日用户)在后台收集数据。 　　

　　不要低估你手机里的数据，它们对应用开发者来说是珍贵的。地点、录音、通讯录、剪贴板、相册等。都是可以开采的数据金矿。 　　

　　以出租车应用为例。很多时候，为了让用户体验更好，平台会设置一个贴心的功能，用户在打开App。 　　

　　同时，系统自动猜测用户想去的目的地。比如用户早上在家附近打开叫车App，系统会自动推荐目的地是公司所在地。用户晚上在公司附近打开。 　　

　　App，系统猜测用户想接孩子放学，自动推荐孩子的学校地址。 　　

　　该功能的实现主要基于用户在平台上的交易记录。但是，如果用户的交易数据不够，系统需要更丰富的地理位置数据来预测用户的生活轨迹。这个问题有一个简单可行的解决方法，就是隔一段时间在后台醒来。 　　

　　App，自动收集用户的地理位置。 　　

　　再比如，现在支付应用有保密支付的功能。用户在经常活跃的地方进行小额交易时，不需要输入密码或刷脸验证。这背后还有一个App。 　　

　　定时唤醒获取用户的地理位置数据，从而控制风险。 　　

　　不仅仅是打车和支付两种场景受益于App的自发布。事实上，对于大多数应用程序来说 　　

　　一般来说，拥有自我启动的能力是一件有利可图的事情。甚至在某一天使用的情况下，许多应用程序在开发之初就保留了这一功能。 　　

　　一般来说，大公司的app受到更多的监管，会相对规范，自启动的目的更多的是为了更好地服务用户。相比之下，一些小公司的申请路径会更野。 　　

　　比如偷偷启动麦克风监听或录音，或者访问相册获取隐私照片等等。这些用户数据会被打包售卖，甚至有可能被卖给黑产。这 　　

　　首先，用户不仅面临隐私泄露的风险，而且更容易受到人身和财产安全的威胁。 　　

　　#互相唤醒：卡顿，发烧的罪魁祸首 　　

　　安卓的开放带来了很多“玩法”，最典型的就是App的双重流程。简单理解就是当用户启动App时，App的两个进程同时启动。当用户关机时 　　

　　App，一个进程被杀，另一个还在后台运行。 　　

　　这个操作的目的其实和自启动一样：刷牙。 　　

　　DAU，获取用户数据。两者都给用户带来了同样的困扰：隐私泄露。另外，由于这个“杀不死”的过程一直在后台运行，用户的手机很快就会变得发热卡壳，需要关机重启，使用体验会直线下降。 　　

　　事实上，“让流程活起来”一直是App开发者和安卓对抗的焦点。对于许多从叛逆期成长起来的应用程序来说， 　　

　　一般来说，如果后台进程被扼杀，其“商业模式”就会发生根本性的动摇。然而，安卓希望用户友好，所以在每一个版本的升级中，它都在更新阻止开发人员“保持流程活力”的方法。 　　

　　比魔鬼高一尺，比路高一尺。在与安卓长期斗争的过程中，App开发者开始预热。同一生态下的 App 　　

　　互相配合，一个打死，另一个再拉上来。在技术界，这种方法被称为“工艺永生技术”。 　　

在开篇的「照明弹」截图中，你会发现有些 App 会在后台唤起另一个 App，有很大可能是在互相保活。另外，一个 App 唤醒另一个

App，也可能是为了广告刷量。

比如 A 公司在 B 公司的 App 上投广告，那么通过 B 向 A 导流的每一次点击都会为 B 带来营收。所以 B 在后台假装用户点击 A，那么在 A

看来就是一个「真实用户的点击」。B 欺骗 A，从广告效果来说，肯定会对 A 造成损失。

除保活和刷量之外，App 之间互相唤醒还有交换数据的可能。举例而言，社交 App 的数据对网购 App

来说很有用。通过关系链的拉取，能够精准进行用户画像，识别购买需求。

不过，这种数据交换的操作在巨头们没有形成生态之前，是通过 API

接口发生在用户手机上的。在有了生态，特别是各公司纷纷开始建立中台之后，用户数据的交换就慢慢地转移到服务器层面了。

# 「照明」之后，接下来怎么办？

玩法这么多，感觉防不胜防？事实上， 最基本也是最有效的防范，是用户对 App 权限的控制。 如果 App

没有访问权限，那么它每天自启动多少次都是徒劳。

但并不是所有的人都有意识有能力关注手机的权限管理，对于上了年纪的人来说更似如此。因此，监管方和平台方需要共同负起责任。

平台方是否有动力负这个责任，其实是需要打个问号的。要想识别违规 App

并督促其下架整改，需要成本投入。目前国内很多应用商店的背后，是手机硬件厂商。如果手机厂商抱着「卖一台算一台」的想法，后续服务就很难跟上。

MIUI 是小米商业化的重要支点，因此从商业角度来说，小米有动力做这件事。「照明弹」功能也确实给 MIUI 平台上 App

的合规性带来了提醒。谁自启动了，谁启动了谁，谁的启动请求被系统拒绝了...... 这些原本就应该让用户知道的信息如今被清晰地展现出来。

「照明弹」推出之后，小米获得了不少好评，但也有人说是个噱头，因为并没有从根本上解决问题。即便是小米，可能也没勇气彻底让违规的 App

整改后再上架。另外，大部分人或许根本没有意识到这照明弹到底照亮了什么。所以，关于用户数据保护和商业伦理的提升，靠企业的自我约束只是起点，这件事最终只有靠更多用户的觉醒来完成。

本文作者：在野

责任编辑：宋德胜

图片来源：MIUI

本文首发于极客公园，转载请联系极客君微信geekparker 或 zhuanzai@geekpark.net

* * *