Benjamin's Blog

从 iOS 相关机制的设计来看待滑动关闭后台 App

从 iOS 相关机制的设计来看待滑动关闭后台 App
2020-02-29 · 6 min read
Perspective

这是一篇发布于 5 年前的文章,其中的信息可能已经有所发展或是发生改变

害,都是玄学

这件事情其实是一个老调重弹的这么一个话题,早在前几年就有过类似的讨论。最近这事突然又被炒上热搜(不知道某为是不是最近又要上新机了🙄️)

回顾

最近的热搜其实是这样的。先是一些自媒体以「苹果建议不要滑动关闭后台程序」为题目或话题发布文章称,在 Apple 支持的一篇 如何在 iPhone、iPad 或 iPod touch 上强制关闭 App 的文章中称:

仅当某个 App 没有响应时,您才应该强制关闭它。

这样一句话瞬间就被解读为「苹果建议不要滑动关闭后台程序」,我太佩服现在的所谓「自媒体」了🙄️

观点

首先,相关报道提到的文章的最后修改日期是北京时间 2019 年 10 月 30 日,Apple US 官网的相关文章的最后修改日期是当地时间(应该指的是太平洋时间) Oct. 18,2019。所以这篇文章并不「新」

其次,如果说这句话说明「退出 App 后台的操作对于电池续航没有积极意义」,那么我无比赞同这个观点。因为理论上冷启动比复活更消耗资源

但有些自媒体因此推导得出「退出 App 后台的操作对于电池寿命没有积极意义」这样的结论,我并不认同。原因是:Apple 并没有在它的任何电池类技术支持文档中提到所谓退出 App 的后台对设备的电池寿命有影响。而「电池续航」和「电池寿命」这两个词也并不能够混为一谈

依据

在 iOS 现行的应用程序机制下,一个 App 要在系统政策的监管之下运行。App 需要遵守 iOS 自己的规则调度。除了常见的沙箱机制(Sandbox)外,还有 MACF、TAL(Transparent Application Lifecycle,透明的应用程序生命周期)、DAS(Duet Activity Scheduler,双重行为调度)等等这些机制。再加上 Apple 对于一个 App 上架到 App Store 的审核其实是非常严格的,所以作为用户的我们,其实没必要担心那么多

简单点来讲,一个 App 一般有两种行为:前台和后台。前台是指这个 App 在用户看得见的比如「窗口」或者「活动任务线程」。后台包括一些音乐类 App 的「后台播放」、Safari 浏览器的「下载」和一些「网络活动」等。这些后台内容基本都是由 iOS 自己调度的

一个 App 在从前台切换到后台后,一定时间内(通常是 5 s,但一些特定的 App 可以在设计和提交程序时决定和声明需要 10 min 的较长时间)它都是存活的,App 在后台并不真正运行。iOS 会将被中止(指从前台切换到后台)的 App 所占用的系统资源(通常指内存)释放,同时将该 App Suspended 化(即「暂停」)。因此,当你返回主屏幕(Home)时,原来的 App 会退到后台。如果它有额外的后台执行任务作业,超过 10 分钟也还是会被 iOS 中止。这也就是所谓的「墓碑机制」

在某些例外情况下,如持续在后台播放音乐的 App、使用 GPS 定位(已授权始终获取位置)的 App、VOIP App 以及一些周边配件附属的程序,是被允许在后台中持续执行的。但只要这些 App 不再执行动作,就会立刻被 iOS 中止,比如音乐播放完了、内容下载完了……

整个 iOS 里,唯二有完整的桌面级别多任务的 App,一个是 Safari 浏览器,一个是 Mail 邮件。这两个 App「几乎」处于无限制状态,它们是真正意义上会占用内存的 App。但它俩也会在任意时间从内存中被释放,具体取决于用户是否打开了其它 App 而导致内存资源不足。唯一不会被释放内存资源的是 Apple 的通知服务

关于国内生态下「前后台」的一点看法

在 Apple 生态下使用国内的某些 App 时,相信你一定会有这样的经验:你在后台播放着自己喜欢的歌曲,打开一个国内的 App 后,音乐被暂停了

对于以「各种手段」尝试延长自己驻留周期的 App,比如之前很多 App 通过调用 coreaudio 播放一个并没有任何声音的音频文件以达到让 iOS 以为它要在后台播放音频而长时间驻留后台的目的。这些 App 还是早退出早干净

Apple 的审核虽然严格,但它也并非能够一击命中那些找各种手段尝试与 Apple 博弈的 App,因为存在一定的误杀。和审核较劲也一直就是个猫鼠游戏。不让用或者开始严格检查这个了,就又换下一个……以前文所述的通过在后台播放无声音频的方式尝试驻留的国内 App 也不少,比如联通营业厅(我是移动,目前还未发现)

国内的 App 生态一直处于一个很有意思的状态,无论是 iOS 还是 Android。厂商或者系统授权商总是在想办法限制开发者的不规范行为,开发者也总是在想如何与审核博弈,似乎永无止境。Android 在国内由于某些众所周知的原因,无法使用 FCM 功能在后台「安静且无害」获取最新的通知,而是需要尝试激活一个甚至是数个服务来尝试驻留后台,这无疑进一步加剧了 Android 设备的耗电并带来一定程度上的安全与隐私风险。国内后来也尝试推出了统一推送系统等一系列政策,但似乎没有看到任何成效

如果你非要问我 Android 要怎么办?或许只能求助于厂商了……

从 iOS 相关机制的设计来看待滑动关闭后台 App

许可协议:CC BY-NC-SA 4.0。欲了解更多相关信息,详见 版权信息与资源使用说明 页面

本站所有内容除特别说明外,皆为原创发布。欢迎尊重原创作者版权的转载或引用。转载或引用时请注明出处


出现了影响阅读的问题?不妨 反馈 一下吧

本文已被阅读 0 次,该数据仅供参考

欢迎任何与文章内容相关并保持尊重的评论,评论时请遵守 评论准则