PWA、Swift与Kotlin，还是Expo：如何选择移动应用架构
从代码库、应用商店覆盖范围、性能、硬件访问能力、发布速度及成本等方面对比 PWA、纯原生 Swift 和 Kotlin 应用以及 Expo，再做出选择。
来源: PWA vs Native vs Expo: Pros, Cons, and How to Choose the Right Architecture
为移动产品选择的架构日后很难更改。如果选择不当，接下来的一年将耗费在解决平台问题而非开发新功能上：框架升级后出现依赖冲突、缺少硬件API，或是两个原生团队逐渐脱节。本指南对比了三种最常见的起步方案——渐进式Web应用、用Swift和Kotlin编写的纯原生应用，以及基于React Native的Expo，并给出了在构建MVP或规划现有应用的下一阶段时选择它们的具体标准。
三种方案的对比
在详细探讨每种方案之前，先来看看它们在通常决定最终结果的几个维度上的差异。
代码库
- PWA：使用HTML、CSS和JavaScript构建的单一网页代码库。
应用商店上架情况
- PWA：存在于网页上。是否在应用商店中列出是可选的，需要借助封装工具或针对特定平台的解决方案。
- 原生开发与Expo：可直接通过Apple App Store和Google Play发布。
性能表现
- 原生开发：达到最佳性能。能够以显示器的最高刷新率实现流畅动画，在性能良好的屏幕上甚至可达120帧/秒，且没有抽象层干扰。
- Expo：大多数接口的实现方式接近原生应用。React Native能够渲染真正的原生视图，其新架构通过JSI实现了直接的JavaScript到原生的调用，取代了旧的异步桥接方式，从而消除了长期存在的瓶颈。
- PWA：受浏览器引擎的限制，尤其是在处理复杂动画和后台任务时。
硬件访问
- 原生：可以利用平台提供的所有功能。
- Expo：通过Expo SDK实现广泛的功能覆盖，必要时还可借助配置插件和自定义原生模块进行扩展。
- PWA：仅具备网页版可用的核心功能，如摄像头和地理位置服务，在iOS上的功能支持较为有限。
发布速度
- PWA：一旦部署完成，更改即可立即生效，无需经过应用商店审核。
成本
- PWA：通常在开发与维护成本上最低。
- Expo：若仅有一个团队负责，投入程度属于中等。
- 原生：成本最高，因为通常需要为两个平台分别维护代码库，也就意味着需要两个专业的团队。
渐进式网页应用：以网络为先的方案
PWA是一种网页应用，它利用服务工作者和网页应用清单等功能，使其行为更接近已安装的应用：它可以被添加到主屏幕上，在独立窗口中启动，并且能够在离线状态下继续运行。如果离线功能是您产品的核心，该博客关于利用服务工作者实现离线支持的指南会详细介绍相关原理。
优势。您与用户之间不存在应用商店这一中间环节。任何拥有该URL的人都可以使用该应用并将其添加到自己的主屏幕上。更新会在下次加载时同步到所有用户，而且内容可以被搜索引擎索引，从而带来自然流量，这是应用商店列表很难实现的。
限制。苹果仍然对iOS上的PWA加以限制。网页推送功能仅适用于添加到主屏幕的应用，且后台运行受到严格限制。Safari完全不支持网页蓝牙及类似的硬件API。如果产品依赖蓝牙、持续后台跟踪或深度设备集成，PWA很快就会遇到瓶颈。该平台的政策已多次变更，因此请查看目标iOS版本的当前规定。
原生Swift与Kotlin：最大程度的控制
采用原生开发意味着需要同时构建和维护两个应用：一个用Swift为iOS编写，另一个用Kotlin为Android编写。
优势。没有任何抽象层，因此性能与画质都能达到平台允许的最佳水平。苹果和谷歌推出的新API会在发布当天即可使用，无需等待框架进行封装。对于要求极高的图形处理、复杂的AR或VR应用以及繁重的后台处理任务而言，这是最理想的选择。
局限性。其开销相当大。两个代码库几乎使开发和测试工作量增加一倍，通常还需要具备不同技能的兩支团队。每个功能都需要开发两次并保持同步，而且每一次发布，哪怕只是修复一个小错误，都得等待应用商店的审核。
Expo：一个代码库，原生级效果
Expo 是基于 React Native 构建的开源框架和工具链。它隐藏了 iOS 和 Android 平台上原生应用的诸多复杂构建过程，因此同一个 JavaScript 或 TypeScript 代码库就能为这两个平台生成真正的原生应用。
优势。 开发效率极高。Expo Application Services（EAS）会在云端生成原生二进制文件，因此日常开发几乎无需打开 Xcode 或 Android Studio。EAS Update 可以直接为已安装的应用推送 OTA 更新。需要注意的是，OTA 更新只能修改 JavaScript 代码和资源文件，无法更改原生代码，且应用商店的政策仍会限制更新的内容；如果出现新的原生依赖项，则需要重新构建应用以适配商店要求。
局限性。配置插件以及Expo Modules API使得编写自定义原生代码比过去容易得多，开发版本还允许使用任何原生库，而不仅限于Expo Go中自带的那些。即便如此，那些需要非常底层的硬件驱动或复杂自定义C++代码的应用仍然需要真正的原生开发工作，团队也需要具备相关能力的人来处理。
如需了解除Expo之外的更多跨平台选项，包括Flutter和Kotlin Multiplatform，请参阅博客中关于跨平台移动框架的综述。
选择合适的架构
应根据产品需求来选择架构，而非仅依据团队偏好的工具：
- 当预算紧张、需要通过搜索提升可见度，且产品以内容或表单为主——如在线商店、新闻网站或SaaS控制面板时，应选择PWA。这也是在投入资源开发原生应用之前验证需求的明智方式。
- 对于初创公司、MVP产品，或是需要由单一团队快速同时发布到App Store和Google Play的正式应用，应选择Expo。这类方案适用于大多数商业和消费类应用。
- 对于高端游戏、依赖硬件的产品（如需通过蓝牙持续同步的健身设备），或是那些确实要求120帧界面且不能有任何抽象层风险的应用，应选择原生开发。
这些选择并非不可更改的固定方案。PWA可以与商店应用共存，Expo应用也可以包含用Swift和Kotlin编写的原生模块，因此当产品的某部分功能超出默认方案的能力时，通常存在混合开发路径。
总结
总体而言，这三种方案并无绝对优劣。最佳选择取决于产品需要在设备上实现的功能、推出产品的速度以及团队可投入的资金规模。在编写代码之前先明确这三个问题：错误的选择日后会表现为需要重构代码和寻找平台替代方案，而正确的选择则能让团队将时间投入到用户能感知到的功能开发上。