从安卓手机换到 iPhone 就想要改掉清理后台的习惯,查阅了一些资料,知道 iOS 后台机制不需要用户介入,在使用中也实行了这一点,奈何心里总有幽灵作祟,总是会感觉到不清理后台续航会降低,手机会发热,进而管不住清后台的手。
Let me be as clear as I can be: the iOS multitasking bar does not contain “a list of all running apps”. It contains “a list of recently used apps”. The user never has to manage background tasks on iOS.
Fraser Speirs
在网上搜索到的大部分中文内容会引用 Fraser Speirs 在他的一篇博客里很明确的指出的内容:iOS 的 Multitasking bar 实际上是 A list of recently used apps,所以,你不需要清理后台。但当我顺藤摸瓜找到这篇博客的原文时,却发现这篇博客发表时间在 2012 年。10 年过去了,这篇文章的内容自然是经不住沧海桑田,早已过时,情况早已发生了微妙的变化,苹果早就加入了各式各样的后台机制。这就衍生出了两个问题,苹果的后台机制是否真的会影响 iPhone 的续航和发热?杀后台是否有助于提升使用体验?
有趣的是,作者在某个时候关闭并存档了他的博客,在他的存档里却并未出现这篇文章,这意味着作者可能刻意删除了它。既然这种流传已久的说法是基于一篇早已过时的文章,结果自然是不可信的,根据这篇文章得出结论,是一个不负责任的营销号行为,我能做的唯有查找更新的资料以及亲身实践。
查找资料
Some apps perform work for a short time while in the foreground and must continue uninterrupted if they go to the background. Other apps defer that work to perform in the background at a later time or even at night while the device charges. And some apps need background processing time at varied and unpredictable times, such as when an external event or message arrives.
Apple Developer Docs
苹果不会也不能一刀切死后台,相反,针对不同应用对后台运行的需求,苹果举了五种场景的例子。
Continue Foreground Work in the Background
Defer Intensive Work
Update Your App’s Content
Wake Your App with a Background Push
Request Background Time and Notify the User
为了用户体验,苹果对应用的后台限制非常严格。针对这五种场景,苹果设计了多样且易于使用的 API 来满足不同的需求,在默认情况下,当一个 App 进入后台时,系统会给 App 最多5秒的时间来进行回写数据等操作,随后系统便会将这个 App 挂起(Suspend),5秒的时间对于大多数 App 来说已经足够。当 App 需要在后台完成更多操作时,可以参照苹果给出的 5种场景设计 App 的后台策略。例如:一个新闻类 App 可以在收到新闻时被系统唤醒到后台接收这则新闻,调用application(_:didReceiveRemoteNotification:fetchCompletionHandler:)
,App 便可以取得至多 30 秒的时间完成接收新闻的操作。同时,App 完成操作后必须要调用endBackgroundTask(_:)
以告知系统自己完成了操作。否则在超过30秒后,系统便会杀死(Kill) App 的进程。得益于 AppStore 严格的审核,上架的 App 基本都经过了规范的编写。
又例如:某网盘需要备份用户今天新拍摄的照片,这是一个密集且工作量大的工作(不知道怎么翻译,原文是 Intensive Works),那么调用BGProcessingTask
以计划一个备份工作,系统会自动根据用户充电的时段、睡觉的时段等信息训练出来的模型自动选择最佳的时段来执行计划好的 Intensive Works。
Schedule these types of background tasks using
BGProcessingTask
, and the system decides the best time to launch your background task.
如你所见,得益于苹果给开发者提供的一套强大易用的 API 以及 AppStore 对于应用在上架前严格的审核,iOS 的后台机制在保持对应用严格限制的情况下却没有增加开发难度,在开发文档里,出现的最频繁的一句话是。
The system decides the best time to launch your task.
苹果将自己用心开发的优质 API 提供给开发者,这些 API 看似简单,实则需要有大量的技术沉淀,看似简单的“选择最佳时间”,背后却充斥着大量的机器学习算法,既然开发者直接调用现成优质的 API 就能将用户体验提升几个层级,那么何乐而不为呢?在同一个开发者付出相同的工作量的情况下,开发 iPhone App 能够实现同功能 Andriod App 高出几个层次的质量,这也难怪早期 iPhone 在抢占市场份额时,App Store 能够在审核如此严格,抽成如此高的情况下涌现大量优质应用。AppStore 里应用调用后台的规范程度也就不必多言了。完全可以像谷歌一样用1倍的努力把体验做到90分,却还是要花10倍的努力把体验做到极致,这很苹果。
杀后台是否有助于提升使用体验?
我们已经知晓苹果的后台机制是十分智能的,可后台机制再智能也依旧有失灵的时候。这就是第二个问题,杀后台是否有助于提升使用体验?
可以说,除了能让心里更好受,以及可能在这几个咖喱味十足的iOS版本提升滑动桌面的顺滑度以外,杀后台无助于提升使用体验,甚至会降低使用体验。
滑动关闭后台应用程序可能会降低iPhone的续航时间,除非是无响应的情况,否则不应该强制关闭应用。
Craig Federighi
当应用程序被从“后台”划掉,其会被移出RAM,这样,应用程序将不会再运行。按照苹果的逻辑,前面所提到的一系列智能的后台机制都不会运作。不仅如此,重新从闪存载入APP会增加电量的消耗且徒增发热,比从直接从RAM“解冻”APP更加费时。这么一看,Craig说的是不是很有道理?是的,在Craig所处的环境里,这句话绝对可以称得上是“金玉良言”。
可惜在中国,情况有些许不同。第一种情况是流氓应用,以中国第一产品经理的微信为例,在之前很长一段时间里(可能现在也是)微信会通过某种手段尽可能延长自己的后台存活时间,甚至于后台活动超过前台使用的时间。这自然会使耗电量增加。从后台列表,准确的说,是最近使用的应用列表强行杀掉微信,的确可以避免这种情况的发生。但微信在国内的地位不必我多说,从后台划掉微信会大幅增加微信的启动时长,每次打开微信看到“连接中……收取中”转圈转个老半天可比耗电更烦人。再者,没有人会希望为了省电而错过女朋友或者上司只打一次的微信电话。这种时候,停用微信的后台刷新可能是一个更好的选择。
类似的情况发生在国内被墙的服务上,在没有代理的情况下,除非开发者专门对此作过优化,国内被封锁的服务、应用会出现一个较为尴尬的问题:按照计划,这些应用需要更新内容,但因遭到GFW的封锁,一直收不到服务器的回应,于是一直运行,直到触发系统的时间限制。前面已经提到过,这种情况下,APP会被系统“杀死”。对于第二种情况,解决方法有二:一是做好分流,24小时挂代理。二是和微信一样,停用这些应用的后台刷新。但无论如何,不要从后台直接杀死这些应用,因为直接杀死这些应用造成的体验远比耗电更糟。
写个总结
在写这篇文章时,我发现,越是写下去,越是背离了写这篇文章的初衷,即“提升使用体验”。技术为人文服务,智能手机归根结底只是我们手边的一个工具,与其费尽心机省电,不如按照自己觉得舒服的方式使用手机。耗电也好,卡顿也好,都由技术的进步解决。我们可以因兴趣使然研究这些技术问题,但绝不能让这些技术问题成为我们生活的全部,放下手机,放下这些技术问题,我们还有很多更有意义的事可以做,很多人可以聚,很多地方可以去玩。
参考
题图来自:https://www.macworld.com/article/667789/iphone-xs-review.html