之前我分享过我的CarPlay行车记录项目，这些项目得到了长途驾驶者的大量有用的反馈。

目标：
使长途CarPlay旅程记录变得足够可靠，以便用户可以在不担心应用程序中途停止的情况下驾驶数百英里。

最近，一些用户开始报告，他们的手机在长时间的驾驶中变得异常热，并且在某些情况下，iOS最终会在背景中终止应用程序。

奇怪的部分：

  • 不能可靠地在模拟器中重现
  • 初始CPU使用率看起来“良好”
  • 大多数较短的行程都完美工作

由于该问题只在长途驾驶中出现，重现它变得非常困难。最近几天我的车基本上变成了一个移动测试实验室，因为较短的行程几乎从未触发该问题。

我花了很长时间测试，既在驾驶，也在静止，偶尔有另一个驾驶员的帮助。在某个时候，我甚至感到疲倦，睡了一会儿，然后醒来继续测试。

诚实地说，尽管感到沮丧，我也感到兴奋，因为它像是在挖掘一个真正的系统级问题，只有在非常具体的真实世界条件下才会出现。

花费了多次TestFlight构建、Instruments会话、能量日志和真正的高速公路驾驶来最终分离出问题。

主要发现：
使用图像密集的磁贴面板的CarPlay应用程序可以比文本模板进行的渲染工作多得多。

CarPlay本身似乎高度优化：

  • 文本渲染
  • 视觉冲击
  • 可预测的布局
  • 低分心
  • 低热量负荷

使用文本为中心的模板，框架主要发送结构化的文本/布局信息到主机单元，汽车处理渲染使用本土汽车字体。

但是图像密集的磁贴面板是不同的。iPhone最终会反复将UI的部分渲染成位图，并将这些渲染的图像推送到CarPlay管道中。

长途驾驶，特别是在充电+导航+播客活跃时，额外的渲染工作会累积得非常快。

在重新设计后：

  • CPU使用率大幅降低
  • 热量行为改善
  • 长途行程稳定性大大改善

最新的更新现在支持在单个行程中记录数百英里更加平滑地进行，几乎没有中断。

一个使这变得困难的事情是，苹果的驾驶任务类别下真正支持全面的CarPlay应用程序的数量非常少，所以优化过程变得深入到苹果严格的UI约束的试验和错误中。

诚实地说，这给了我一个新的欣赏为什么CarPlay应用程序看起来比人们预期的简单得多。

给同行开发者：
默认使用文本为中心的模板来频繁更新驾驶数据似乎比图像密集的磁贴面板渲染要高效得多，特别是在长途驾驶时。

对好奇的CarPlay用户：
如果你曾经想知道为什么许多CarPlay应用程序看起来比预期的简单得多，热量限制、渲染负荷、分心规则和苹果的严格UI约束都是一个巨大的部分。