很多应用开发者都会遇到这样一个需求，当程序需要处理某个敏感的核心任务，或者执行某些动画时，需要杜绝一切外部干扰，优先保证任务的完成，之后再去处理其它任务。否则如果在处理过程中受到外部事件的干扰，可能会引入严重的问题，而规避这些问题需要额外编写过多的逻辑。 例如，当程序在忙着清理应用内缓存的过程中去处理其它任务，这时候由于其它任务可能会产生新的缓存，这就会和现有的任务冲突。所以在清理缓存的过程中，app 一般会暂时中断用户和非用户的请求，优先保证缓存清理的完成。 所以，为了简化产品设计逻辑，开发者一般会选择在处理任务时暂时屏蔽其它任务，优先保障现有任务的完成。
在 iOS16 上，苹果推出了实时活动( Live Activities )。实时活动可以出现在用户锁屏界面，并可实时展示用户关心的一些核心信息。由于使用远程推送通道更新实时活动不需要主 app 保持开启，并且相比小组件需要用户手动添加到桌面这个门槛，实时活动功能是默认开启的，所以这一机制保证了信息的触达概率会远高于小组件。 笔者认为，实时活动是一种更高级的推送形态，对比传统的推送，实时活动显得灵活许多。传统推动在用户接收并读取到内容的瞬间信息就失效了，如果想要为用户提供持续更新的信息需要依赖一条接一条的推送才可以实现，这无论从成本还是用户体验上，都是难以接受的。而实时活动则会在持续期间，无干扰的保持着信息的更新，并且又会在合适的时机自行消失，因此用户体验极佳。 作为一家在线旅行产品平台，我们一直追求为用户提供极致的用户体验，在今年的上半年，我们上线了基于实时活动开发的实时出行信息展示功能，用户可以在出行全周期内，通过锁屏或者灵动岛看到最新实时的出行信息。
Monorepo 和 Bazel 给我们带了很多优势，比如快速、正确、易扩展、易协作等。虽然 Bazel 早期版本对于 iOS 开发并不太友好，甚至让一些团队产生了放弃使用 Bazel 的想法；但 Bazel 本身极其优秀的扩展性，使得社区对其一直抱有极高的热情，开发出了许多优秀的 Rules，促使社区和 Bazel 本身一直向前进化，如今的 Bazel 已不同往日，一些早期令人诟病的问题也被一一解决。目前我们正在使用 Bazel 6.1.2 版本，且即将紧跟官方的脚步更新到 6.3.0 版本。今天我们就来聊聊我们哔哩哔哩近一年（主要是Bazel 5.0.0 版本以后）所应用的一些新特性、新 rules 以及在自建 rules 方面的探索。
