为何React Native+Expo构建生成的APK包体积偏大？

• 底层运行时架构的本质差异：React + Capacitor 属于WebView嵌套方案，核心渲染、JS执行能力直接调用安卓系统自带的WebView组件，不需要额外在安装包内内置运行时环境。React Native 是独立的原生渲染方案，不依赖系统WebView，哪怕是零业务逻辑的Hello World应用，也必须全量打包独立JS引擎（默认是Hermes）、Yoga布局引擎、JS与原生层的桥接通信模块、核心原生组件的实现逻辑，这部分基础依赖的固定占用就有6-8MB。
• Expo默认打包的冗余依赖：Expo托管工作流为了实现开箱即用的开发体验，未做定制裁剪的构建包会内置大量常用原生能力模块，包括定位、相机、通知、文件系统、传感器、权限管理等，不会因为业务代码没引用就自动剔除。如果构建时没有开启原生模块按需裁剪，这部分冗余依赖会额外增加4-10MB不等的体积。如果是debug版本的APK，还会额外内置调试工具、热重载支持模块，体积比正式release包高30%以上。
• 多CPU架构的二进制冗余：安卓设备存在armeabi-v7a、arm64-v8a、x86、x86_64四种主流CPU架构，React Native 包含大量C/C++实现的原生.so库，默认构建的通用APK会把四种架构对应的二进制文件全部打包进去，这部分会让包体积接近翻倍。而Capacitor方案因为核心依赖系统WebView，自带的原生.so库体量极小，多架构带来的体积增量可以忽略。
• 资源与基础能力的固定开销：React Native 内置的动画驱动、样式解析、手势响应、图片解码等基础能力的原生实现都需要打入安装包，而Capacitor的这类能力全部由系统WebView提供，不需要额外内置。

常规优化方向：构建正式release包时开启ProGuard代码混淆与资源压缩，使用EAS构建时配置原生模块按需引入规则，按CPU架构拆分输出多渠道APK，裁剪未使用的Expo内置模块，开启Hermes引擎字节码优化，裁剪后的极简Expo应用APK体积可以压缩到5-7MB区间。

内容的提问来源于stack exchange，提问作者m_novak