适配我们手上没有的 iPhone

我们的团队使用的是全新的iPhone手机，但我们的用户并非如此。每天打开我们应用的用户中，有相当一部分人使用的设备已有三、四年，有时甚至五年之久。如果我们只用自己口袋里的设备进行测试，最终推出的产品就无法满足目标受众的需求。.

在小型工作室里，这一点很容易被忽略。当你整天都在高性能硬件上进行开发时，“快”就成了常态，而那些在旧手机上表现尚可的功能，便不再被视为问题。我们发现的唯一可靠的解决办法，就是每次都将那部旧手机实实在在地放在眼前。.

我们的参考车队

我们保留了一套小型实体设备——过去五年中每年各一台iPhone，外加目前在售的最便宜的iPad。每个版本在通过质量保证（QA）环节之前，都会在这套设备上进行测试，而不仅仅是使用工程师办公桌上最新的硬件。那台五年前的手机能发现任何模拟器都无法检测出的问题。.

这一套流程并不起眼。安装构建版本，冷启动设备，滚动应用中最长的列表，打开最耗资源的界面，旋转设备，将应用切换到后台，然后切回。 在 iPad 上，我们还会测试分屏模式，因为一台运行两个并排应用的廉价 iPad，与一台仅运行一个应用的新机相比，表现截然不同。这些操作都不费时间，也是发布周里我们最不愿省略的部分。.

这种思路不仅适用于iPhone。 我们的 Android 应用不仅在旗舰手机上，还在性能一般的硬件上进行了测试；而我们的 iPhone 和 iPad 应用也能在搭载 Apple Silicon 的 Mac 设备上运行——在这些设备上，原本在手机上看起来很正常的界面布局，可能会突然变成一个可调整大小的窗口。.

我们的收获

在最新芯片上运行流畅的动画，在两代之前的芯片上却显得迟缓。 在 Pro Max 上几乎察觉不到的图像解码选项，却可能在基础版 SE 上导致主线程卡顿。在 8 GB 设备上绰绰有余的内存资源，到了 4 GB 设备上就显得捉襟见肘。这些问题虽不会以“ Bug”的形式显现，却会让人隐约感到：在低端手机上，应用的体验似乎更差——而这正是我们最不愿给用户留下的印象。.

我们早期犯的错误是，将旧手机视为最终测试环节，而非设计参考。我们先制作好界面，在新硬件上进行优化，直到最后才发现它在旧设备上会出现卡顿——到那时，要修复这个问题就意味着必须重新修改我们已经认为完成的部分。 现在，从第一个原型开始，旧款手机就被纳入了测试流程。如果某个动画或列表在旧款设备上运行不流畅，我们会调整设计，而不仅仅是修改代码。.

这其中存在取舍。有些特效如果只能在最新硬件上呈现出理想效果，那就不值得采用，因此我们将其剔除。这有时会导致应用在截图中看起来比竞争对手的略显朴素。我们对此并不介意。.

我们的最低

所有 Zydeno 应用均支持回溯两个主要 iOS 版本。苹果的弃用节奏相当快，若再往前追溯，代码库的维护将变得十分困难；但回溯两个版本，意味着我们既能为绝大多数用户提供良好的服务，又不会仅服务于使用最新系统的用户。.

坚持这一原则意味着，在采用新系统功能之前，我们有时需要稍作等待，或者在开发时确保应用即使没有该功能也能正常运行。这确实会消耗工程时间。与其告诉用户，他们那台原本运行良好的手机已不再符合我们的要求，我们宁愿付出这笔代价。.

这款廉价手机是位坦率的评论家。我们把它放在桌上的确有其原因。