在组件化的浪潮下，公司引入多仓开发对工程架构进行解耦、跨业务技术能力复用，并辅以组件(混合)二进制化进行编译提速。不过随着工程规模增长、业务复杂度提升，多仓二进制的弊端日益凸显： 合码效率低下：多仓的引入使开发流程变复杂，最有代表性的合码环节一次合码涉及到主仓和多个组件，每个组件要跑 Pipeline 流程进行版本发布。因涉及到组件发布，从而引入了 MR 锁，进而导致吞吐量有限。如果某个组件失败，那么 MR 需要重新跑一遍流程。这种模式提升了 CI 复杂度，降低了合码效率（封板排队时间可达 6h+） 依赖管理衍生问题：稳定性差，多仓使环境依赖度变高，稳定性变成多个仓库稳定性的乘积。即使每个仓库成功率是 99.9%，每次 install 成功的概率也仅有 74%；版本溯源性差，项目通过依赖动态决议生成，无法做到 single source of truth。 代码的可视性和可控性降低：跨组件重构困难，全量静态检测无从入手，并且很难统一架构规范；本地开发体验差，工程代码可信度低，无法直接对代码进行开发调试，本地开发需要更多的工具和流程来保证代码的可视性和可控性。
苹果在 WWDC22 中，提出了实时活动（Live Activity）的概念，以便于用户在锁屏查看一些应用实时活动的更新，这与盒马的配送场景十分贴合。因此，我们将 Live Activity & “灵动岛” 特性第一时间落地到盒马 30 分钟配送场景，并作为第一批适配实时活动的 iOS 应用，获得 App Store Today 推荐。 目前，盒马 App 适配“灵动岛”的最新 5.51.1 版本已正式上线，欢迎大家升级体验。在适配过程中，盒马 App 也在端侧踩过很多“坑”，特此汇总为实战经验分享给大家，欢迎交流。
包大小是衡量APP性能的一项重要指标，它直接影响用户的下载点击率（包太大不想下）、下载安装成功率（下载慢不用了）、APP卸载率（太占空间先删掉）。 包大小的计算逻辑很简单，它是各种类型的文件占用磁盘大小相加。APP瘦身的技术却很复杂，代码文件的复杂度和编译器策略决定了可执行文件的大小，业务功能和工程架构决定了代码文件的复杂度。iOS APP瘦身，需要掌握的技能有XCode构建技术、LLVM编译器技术、CocoaPods构建技术、图片压缩技术、持续集成技术。 本文总结提炼了Alibaba.com App的瘦身的技术和策略，系统化地介绍APP瘦身的业务价值、分析技术、瘦身技术、防劣化机制，让读者可以系统化地了解APP瘦身的技术体系。本文还基于实践经验，介绍各种瘦身技术的ROI，让读者可以避免踩雷，将资源浪费在效果不佳的技术上。希望对你有所帮助。
