关于热聊的iOS13“杀后台”问题的一些感想

自带光环的小蘑菇

你是否有这样的情况：

某个下午，你用手机愉快的浏览着网友的帖子，看到一个有意思的帖子，此时感触颇深想回复一下，你吃着火锅，唱着歌，飞快的图文并貌的编辑着信息，此时一条推送或者一个电话来了，你接完电话或者查看完另一个推送后，打算回到此前的app 继续编辑时，这时那个 app 被杀后台了！！！！ WTF！！！¥%&*$

没错，我就亲身经历过，不只是手机上，电脑上一样有过。

    回到主题，关于“杀后台”这件事，如果是触发了苹果的内存管理机制，那么就不是iOS13才有的了。

除了内存问题，还有可能是其他问题导致了app的“被杀”。

最近有网友看到微信的日志，显示可能是触发了“wakeups”，大概理解就是频繁的线程唤醒出问题了。

至于为啥出问题了，相信微信工程师正在定位问题和解决问题，一定会解决的。可能是微信的下一个版本修复或者苹果发下一个版本修复。

有兴趣的话，大家可以看一下这个文章【iOS 13.2 为何杀 App 这么频繁以及什么是 wakeup】https://imtx.me/archives/2809.html

---

关于内存的管理机制导致的“杀后台”，这里想聊一下。

    如果是苹果开发者的话，对于苹果的内存管理机制都是很熟悉的。

通俗的描述下：就是当你在使用app时，这个app就在使用系统内存，而手机内存就那么多，当这个app使用的内存多了，不够了咋办？

这时苹果为了保证你正在用的这个app能正常的、流畅的使用，系统就会将在后台挂起的那些app 占用的内存释放，给你正在使用的app来使用，而此时在后台的某个或者某些app的内存就可能被释放了，所以当你再次切回到后台的某个app到前台时，这个app就会出现app重新启动的样子了。这个就是苹果在内存管理上的机制了，而这个机制是一直存在的。

其实“杀后台”不可怕，如果出现了杀后台，但是当用户打开app后，能够自动展示之前用户离开的页面，用户可以继续浏览或者编辑，这样的话，才是最好的体验和解决方案。

在苹果的官方人机交互指南中，苹果的交互设计指南有这样一段描述：

https://developer.apple.com/design/human-interface-guidelines/ios/system-capabilities/multitasking/

Multitasking
Be prepared for interruptions, and be ready to resume. Your app can be interrupted at any time. When an interruption occurs, your app should save the current state quickly and precisely so people can seamlessly continue where they left off when they return. For developer guidance, see Preserving Your App’s Visual Appearance Across Launches in App Programming Guide for iOS.

翻译如下（来自百度翻译）：

多任务
准备好被打断，准备好重新开始。您的应用程序可以随时中断。当中断发生时，你的应用程序应该快速准确地保存当前状态，这样人们在返回时可以无缝地继续他们中断的位置。

    没错，一个好的 app 应该有这样的设计，如果做到位了，做好了这种情景的设计和开发，相信大家也就不会讨论这个话题了，也不会有文章开头那种情况了。

写在最后的感受：

    大家一定深有感受，当下的app相比几年前，app 的体积越来越大，app 的功能越来越多，越来越复杂。手机的硬件设备也是越来越强大，更多的存储空间、更大的内存、更快的处理器，也是保证了这些app 的正常运行和良好的使用体验。

    但是在当下，各家都在快速的推出产品（app），快速的迭代试错，抢占市场。在“体验”上（性能的调优），就不去做了，当然理由也就是“先活下来”、“快速迭代试错”。这也没有错，一个产品肯定是先活下来。

    但还是希望设计者、开发者，在设计产品、开发产品时，能考虑这些因素。作为开发者，应该具备或者提升这些技能，并把这些工作“顺便”做好。而不是“以后有时间再做”。