做鸿蒙跨平台项目做到现在这个阶段功能早已稳定用户量和业务压力都上来了反馈最多的问题反而不再是功能而是两个词包太大、启动白屏。这两个问题听起来像性能调优落到根子上一半都出在 React Native 的 Bundle 上。我这个项目三端共用一套 RN 代码一份 JS Bundle 会同时打进 HAP、APK 和 IPA所以 Bundle 每膨胀 1MB等于三个渠道同时被放大了一遍优化的性价比高到让人没法无视。这篇文章把我这次从“拆解体积构成”到“逐项减重”的完整过程写出来。工具怎么用、配置怎么改、哪些优化立竿见影、哪些是网上经常被误解的做法还有最后那几次差点让我回滚的翻车记录我都会写清楚。如果你也在搞 RN 跨平台尤其是目标平台里带鸿蒙的这份经验应该能帮你省不少弯路。1. 先交代一下项目背景和这次优化的缘起1.1 一个鸿蒙跨平台工程的实际形态先说项目的组成。整套 RN 代码跑在 Android、iOS 和鸿蒙三端平时主要维护一份 TypeScript 源码。鸿蒙侧并不是一套独立实现而是通过适配层把 React Native 的核心运行时接到鸿蒙系统上。也就是说RN 的 JS 引擎、渲染管线、原生模块桥接在鸿蒙侧都有对应实现JS 逻辑本身三端共用。这带来一个容易被忽略的问题很多人觉得鸿蒙适配层是不是要单独维护一份代码体积是不是要另算。实际不是JS Bundle 是所有平台共享的真正分平台的是 Bundle 里的平台扩展代码和原生侧的能力适配。所以当 HAP 包变大时有相当一部分来自 React Native 的 JS Bundle还有一部分来自适配层的原生 so 和资源目录。这次我们优化的重点是前者但后面也会提到原生侧怎么配合。项目开发前期大家的重心都放在功能迭代上依赖库越加越多图片越来越精美自定义字体一个接一个等到准备做一轮规模化推广时才发现 HAP 的体积已经不太好看。更要命的是鸿蒙侧如果走线下包分发或渠道包分发用户下载阶段的流失率会直接受影响。1.2 Bundle 为什么是包体积问题的核心战场Bundle 是 React Native 打包后的 JavaScript 产物里面装的是所有业务模块、第三方依赖、组件代码以及被内联的资源。它只有一个文件却是整个 JS 层体积膨胀的集中体现。原因非常朴素任何在 JS 源码层引入的东西最终都会堆到这份 Bundle 上。不用某个依赖了忘了卸载体积在图标转成 base64 塞进组件里体积也在一个库里把全部 locale 目录带进来体积还在。RN 的打包器 Metro 是模块图形式的所有被 import 过的模块都会留在产物里依赖一多、引用不干净Bundle 就快速膨胀。正因为 Bundle 是共用的优化它等价于同时优化了三端的安装包体积。这是我推动这次专项第一优先级的原因做一次优化三端受益维护成本还低。也正因为 Bundle 在启动阶段要被完整读取和执行它和启动白屏是强相关关系这事后文会展开说。1.3 这次定下的优化目标和验收标准做优化最忌讳没有目标就开始乱试。我先与团队对齐了这次的方向性目标不追求极限体积而是让 Bundle 回落到一个“启动体验可接受、包体处于同级别产品合理区间”的范围内。具体量化成三个硬指标。第一JS Bundle 体积要控制在 3MB 以下当前基线是 8.7MB第二鸿蒙参考低端机冷启动首帧时间控制在 2 秒内当前基线是 3.4 秒第三HAP、APK、IPA 三个安装包体积分别下降至少 8MB。另外还约定了约束条件不改变产品功能不重写业务代码不把风险集中在某一个大改动上。后来又加了一个很实际的约束每一步优化都必须是可以在不拆业务的情况下回滚的。这直接影响了后面优化顺序的选择我们是先做低风险高收益的项目把复杂方案放到最后。2. 动手前先看清家底Bundle 构成分析2.1 体积分析工具与报告怎么看优化前第一步不是改配置而是先回答一个问题这 8.7MB 到底是谁占的我用了两个工具来做分析react-native-bundle-visualizer和source-map-explorer。react-native-bundle-visualizer用起来非常简单它会生成 HTML 格式的可视化报告按模块大小展示占比内部是基于 Metro 打包中间产物做的统计。常用命令是这样的npx react-native-bundle-visualizer这里有个小坑值得先说如果你的项目开启了 Hermes 字节码这个工具默认展示的是编译前的 JS 源码大小实际安装包里的字节码会更紧凑但模块排名的参考价值不变。你只需要把 JS 模块之间的相对占比当参考不要拿它输出的绝对数值直接当最终体积。分析时我会盯住三件事占用最大的 Top 10 模块是谁、有没有同一个库被重复打包、有没有明明只是局部用到却整包引入的依赖。光这三类就能定位大部分膨胀问题。2.2 我这份 Bundle 里到底谁是大头报告跑完之后结果其实很典型。我这份 8.7MB 的 Bundle 里排在最前面的几类基本可以概括为第一是 moment.js 及其全套 locale 文件。moment 的体积在现代化依赖里是出了名的因为它默认把全球 locale 全部打进产物即使你只用format(YYYY-MM-DD)这一种格式。这一项直接占了 280KB 左右。第二是 lodash 的全量引入。很多代码文件里写着import _ from lodash打包器没法对 CommonJS 模块做精细 tree shaking只能把完整库带上这又是 70KB 到 100KB。第三是动画相关的依赖链。我们项目里同时保留了 react-native-reanimated 和 gesture-handler这套体系本身是正常的但代码里混杂了老业务写的 Animated 和大量没用到的组件导致相关 JS 模块被连带打包。第四是内联在代码里的图片资源。这不是 RN 的默认打包行为而是团队历史遗留下来的习惯把一些图标转成 base64 字符串直接写在常量文件里。这个最坑不信你把任何一张 100KB 的 PNG 转成 base64 看看体积会扩大约 33%而且这些字符串还要被 JS 引擎解析执行启动阶段也会变慢。第五是 i18n 的多语言文案和一部分 polyfill。语言包以 JSON 形式被 import 进来Intl相关的 shims 在某些低版本环境下也会被条件加载。这些单项不大的东西叠加起来就是实实在在的几百 KB。2.3 “启动白屏”和体积的真实关系接下来我来解释一下为什么包体积和启动白屏会出现在一次优化专项里。RN 应用冷启动要经历这么一段链路原生容器创建 - JS 运行时初始化 - 读取 Bundle 文件 - 解析并执行 JS - 渲染首帧。前后两个阶段跟原生性能和布局有关中间三个阶段受 Bundle 影响很大。尤其是解析和执行一部低端鸿蒙设备读取 9MB 左右的 JS 文件光 IO 就要几百毫秒JS 引擎解析执行又耗掉几百毫秒甚至突破一秒这两段加起来就是一个“白屏黑洞”。更隐蔽的是Bundle 里如果充满了大量字符串常量比如 base64 图片JS 引擎解析字符串的耗时非常明显。这可能就是很多人疑惑“我 App 包没多大为什么启动还是慢”的原因因为慢的不在文件体积而在执行成本。所以这次优化我们不只看最终包拍同时拿“低端机冷启动首帧时间”当验收指标避免为了瘦身牺牲启动性能也避免只盯着包体而忽略真正拖慢启动的字符串和模块量。3. 第一轮减法引擎、压缩与调试尾巴3.1 切到 Hermes 的真正收益在哪里先做的是风险和收益比最高的一步切换到 Hermes 引擎。React Native 0.70 之后Android 和 iOS 已经默认启用 Hermes但跨平台项目尤其是早期接入鸿蒙适配层的工程往往为了兼容性还停留在老配置甚至使用的是 JSC 引擎。鸿蒙适配层目前对 Hermes 的支持已经很成熟我们这次把三端的 JS 引擎统一切到 Hermes。有人可能看过一些文章说“切到 Hermes 能大幅减少包体积”这里我要纠正一个常见误区Hermes 的字节码体积并不一定比压缩后的 JS 小很多它的主要收益是跳过了 JavaScript 解析阶段运行时内存占用也更低。实际使用中我们后端脚本对比过同一份 JS 压缩产物和 hbc 字节码的体积差距通常在 5% 到 15% 之间谈不上大幅瘦身。但为什么这一轮我仍然放在最前面因为 Hermes 对启动速度的提升是实打实的。低端机上JS 解析时间通常能省掉一半以上首屏白屏时间立刻改善。切引擎属于基础设施层面的改动它不影响业务代码形态风险相对可控。配置方式因平台略有不同Android 侧一般在android/app/build.gradle里打开开关react { enableHermes true }鸿蒙侧则是在工程构建配置里把 Hermes 运行时设为启用状态同时确保适配层带了对应的 so 库。改完之后跑完整回归测试尤其要跑一遍热更新场景因为旧缓存可能还是 JS 格式切引擎后需要强制走一次新包。3.2 关掉 sourcemap、清掉 console、顺手去重第二刀是清理调试尾巴。很多问题不是上线前没有做而是做了一部分留下来的一点就够让你吃暗亏。先看 sourcemap。开发阶段为了定位问题我们在打包脚本里开启了 sourcemap 输出结果 Release 包里 sourcemap 被打进了 assets。sourcemap 的体积经常比 JS 本身还大这种文件只影响开发调试对线上用户毫无用处必须在 Release 构建时关掉。然后是 console 语句。RN 源码里散落着大量console.log和console.warn这些在 Debug 模式下很方便进了 Release 后却会被完整编译进 Bundle。它们不是不可以去掉常规做法是借助 Babel 插件在编译阶段把它们移除。我们用的配置类似这样{ plugins: [ [transform-remove-console, { exclude: [error, warn] }] ] }顺带说下console.error和console.warn还是建议保留线上如果出现崩溃或告警至少日志里还能看到原因。只删log和debug就好。去重是这轮容易被忽略的最后一步。跑完体积分析报告后我们确实发现同一个工具函数被多个目录重复实现还有几个 lodash 插件版本并存。把代码里分散的src/utils/xxx收拢成统一的内部包再处理掉重复依赖顺手又能挤掉几百 KB。3.3 Metro 的“去除未引用模块”能力边界还有一个经常会拿来说但实际作用被夸大的手段tree shaking。必须说清楚Metro 本身不是 webpack。它的模块系统以 CommonJS 为主默认能力是把“完全没有被引用”的模块从模块图中剔除但做不了基于 ES Module 的细粒度函数级 tree shaking。也就是说如果代码里写了import _ from lodashMetro 只会看到整个 lodash 模块被引用于是整包保留。处理这类问题正确做法是从引用方式下手。比如把import _ from lodash改成import get from lodash/get或者引入babel-plugin-lodash自动转换 lodash 的模块级引用。对 moment 这种更离谱的locale 目录会被整体带进来需要显式忽略 locale 或者直接换库。这里我踩过一个不大不小的坑给某个公共模块加 tree-shaking 插件时把 Babel 配置全量接上后打包速度直接掉了 40%排查半天发现是插件把缓存策略踩了。后来只对发布构建启用该插件开发构建保持原样问题才解决。这个经验值得记一下生产优化和生产效率要分开对待不要为了发布构建的几百 KB 拖慢日常开发。4. 第二轮减法拆包、外置与按需加载4.1 用 Metro 自定义序列化做基础包与业务包拆分依赖治理做完之后我们面对一个新的现实业务功能摆在那里代码量就是这么多纯靠“减”已经见底了。这时候拆包就是绕不开的下一招。RN 的拆包和原生端拆 SO 类似就是把一个巨大的 Bundle 拆成“基础包 多个业务包”。基础包里放 react、react-native、reanimated、gesture-handler 这些公共依赖进首页就必须加载业务包按页面或模块拆分比如“订单中心”“个人中心”“直播详情”进入对应页面时再动态加载。Metro 并没有提供现成的“开一个开关就拆好”的能力需要借助自定义序列化器实现。我们参考了社区方案在metro.config.js里通过createModuleIdFactory和processModuleFilter控制哪些模块进入基础包大致思路如下const path require(path); const baseModules [ react, react-native, react-native-reanimated, react-native-gesture-handler ]; module.exports { transformer: { // ... }, serializer: { createModuleIdFactory() { let fileToIdMap new Map(); let nextId 10000; return ({ path: filePath }) { if (baseModules.some(mod filePath.includes(mod))) { // 基础包使用固定区间避免与业务包冲突 } // ... }; }, processModuleFilter(modules) { const fileName modules.path; return !baseModules.some(mod fileName.includes(mod)); } } };这里最重要的是模块 ID 的区间规划。我们给基础包预留了10000到19999的 ID 区间业务包从20000开始分配这样两边的模块 ID 不会撞车。第一次拆包时我们就没有规划好导致基础包和业务包出现了大量重复 ID运行时直接报“module not found”差点把整个功能搞挂。拆包的另一半工作在原生侧基础包要内置于 HAP、APK 和 IPA 的 assets 目录业务包初期也内置后续才能做动态下发。加载器需要按模块 ID 判断去哪个包找模块这个逻辑我们封装成了一个自定义的 runtime loader业务侧基本无感。4.2 图片资源从 Bundle 里赶出去第二件立竿见影的事是处理图片。上面分析报告里已经说过项目里有一个“base64 图标文件”这是体积大户同时也是启动时间的隐形杀手。这轮我们干脆把能外置的图片全部从 Bundle 里赶出去。RN 中图片资源有三种常见放法第一种是 require 一张图片让打包器把它放到资源目录运行时按 asset 引用第二种是远程 URL第三种就是灾难性的 base64 内联直接把图片数据写进 JS 源码。我们的处理策略是历史遗留的 base64 图标全部改造成命名资源统一放到原生资源目录UI 图标这类轻量素材转成 WebP照片类内容走远程 URL。图片转 WebP 的压缩命令很简单质量选 80 对大多数 UI 场景完全够用cwebp -q 80 input.png -o output.webp如果图片偏小、边缘清晰建议用无损模式避免出现肉眼可见的压缩痕迹。我们经过对比UI 图标这类图形元素通常用 160 的接近无损参数最稳照片类才用 80 的 lossy。这批操作做完Bundle 直接少掉 1.2MB三端安装包体积的下降也特别明显因为图片资源进的是包内资源目录而不是压进 JS 文件。这里有个细节想提醒大家图片外置之后原来直接塞在 JS 里的图标组件往往需要改造成一个包装组件让它可以同时处理“本地资源 ID”和“远程 URL”两种输入。改造量不大但提前规划接口很重要否则到处散落的图片引用会让你改到怀疑人生。4.3 字体内置改子集直接砍掉一截体积图片之后字体是另一个容易被人忽视的大头。项目早期为了 UI 统一接了一款带品牌定制的开源中文字体完整字库动辄 5MB 往上被打包进安装包后体积直线上升。字体的优化逻辑和图片完全不同它不需要把文件挪出包而是要把文件变小按业务实际用字做子集化。中文 App 的动态用户输入很多子集化字体的场景要区分清楚像标题、固定按钮文案这种字符集可控的地方完全可以只保留用到的字但文本阅读区如果用户能输入任意文字就还是得保留全字库。我们这次主要处理的是两个固定场景启动页标语和品牌 Tab 栏文案。用pyftsubset给字体做裁剪pyftsubset font.otf --text首页订单我的品牌标语 --output-filefont-min.otf跑完之后这两个场景的字体文件从 4.8MB 降到了 120KB 左右。要注意字体子集化后会丢失一些字形尤其是生僻字、特殊符号和 emoji所以业务侧一定要有兜底字体策略否则用户看到豆腐块比包体积大更让人头疼。RN 里注册字体的方式和原生端不太一样字号fontFamily必须和实际字体注册名严格一致否则不会生效。子集化其实不改变字体家族名主要坑在于只做部分字符裁剪后文本框超长时中文会直接回退到系统字体视觉上会有轻微跳变实测下来影响不大但我们还是提前跟 UI 同学打过招呼。4.4 动态下发的取舍与离线兜底拆包做完之后基础包 1.3MB、业务页包累计 1.8MB两者都内置在安装包里。这时候“动态下发”就被提上了日程把部分业务包放到自己的服务器上App 启动时先加载内置版本再异步检查是否有新版本有新版本就下载替换缓存。这个方案的收益很明显后续业务迭代不用每次都发安装包体积增量可以放在云端。但它不是没有代价最大的代价就是启动流程变复杂任何一次网络异常、缓存损坏、版本校验失败都可能导致用户卡在旧版页面。我们的取舍是只对两个运营高频改版的页面做动态下发其余页面全部保持内置。动态下发包必须有一个强兜底网络失败时用内置版本没有内置版本时直接跳过样式增强宁可页面朴素一点也不能阻塞渲染。下载链路还要做完整性校验我们用的方式是下发时同时返回文件的 SHA-256本地校验通过后替换缓存。这套机制虽然不是核心优化点但如果不提前做好后续动态下发会成为线上事故的温床。5. 第三轮减法依赖治理与原生侧协同5.1 重依赖替换的取舍清单如果把引擎切换、图片外置、字体内置这些结构性问题做完之后剩下的就是持续的依赖治理。这一步更像日常工作但收益积累起来非常可观。有个依赖替换清单值得直接抄作业原依赖问题替代方案实测收益moment默认全量 locale 打包dayjs 按需 locale约 280KB - 30KBlodash 全量引入整库打包lodash 按需路径 / babel-plugin-lodash约 100KB - 20KB自定义中文字体全量5MB 左右字体塞包pyftsubset 子集化4.8MB - 120KB内联 base64 图标体积大且拖慢解析WebP 资源外置总降 1.2MB表格里最复杂的替换是 moment 到 dayjs。moment 的使用历史长API 行为有很多微妙差异比如时区处理和日期字符串解析。我们没有激进的一次替换而是先用 wrapper 包一层对外暴露统一接口业务侧不动底层实现从 moment 换成 dayjs。换完后回归了所有和日期相关的用例包括跨时区、闰年、时间戳格式化这些边界场景。替换依赖有一条红线不要再引入一个和原库重量等级相同的依赖。很多人把 moment 换成 dayjs 后又为了“功能对齐”装了一堆 dayjs 插件体积省了个寂寞。我们的目标很明确只引入业务实际用到的插件其余一律不装。5.2 动画库和语言包的精简动画依赖链是另一个容易暗藏水分的区域。我们清理后发现项目里同时存在 react-native-reanimated 的老版本和一部分老业务使用 Animated 原生动画的代码。老 Animated 相关模块虽然没人在用但模块图里仍被某些公共组件引用着所以每次都跟着打包。处理办法是分两步先定位所有还在用 Animated 源码的地方能迁移到 reanimated 的尽量迁移迁移不了的就单独做一个兼容目录然后把 bundle 报告里明显不属于 reanimated 体系的动画模块从模块图里剔除。第二步在配置上有时需要借助resolve别名或手动改 import 路径不复杂但要细心。语言包的精简也值得一提。项目之前为了做国际化直接在入口文件里import ./locales结果所有语言文件全部加载。优化后改成运行时按当前语言动态加载对应 JSON 文件基础包只保留默认语言切换语言时再异步拉取。这个改动省掉的体积不大但它让首次启动的数据量又减了一截属于典型的“积少成多”。依赖治理的最终效果是让 Bundle 回到底层框架加业务逻辑的合理范围而不是继续膨胀下去。这个阶段没有一步登天的方案但它决定了后续优化的可持续性。5.3 鸿蒙原生侧能帮我们做些什么既然项目面向鸿蒙原生侧的配合也很有必要做一遍。JS Bundle 优化完成之后我们又把视线投向了 HAP 的结构发现还有两类空间可以压缩。第一类是架构裁剪。HAP 里的原生 so 为了兼容不同设备可能同时包含 arm64-v8a 和 x86_64 两个架构。x86_64 主要用于模拟器和极少数设备如果生产环境明确没有这类目标可以只在 Release 包保留 arm64-v8a。这一步瘦身效果非常直接但因为涉及发布产物策略必须和测试、运维对齐尤其要确认鸿蒙侧有没有用户用模拟器跑生产包。我们这次线上包只保留 arm64但保留了独立模拟器包避免排查问题时无包可用。第二类是适配层版本对齐。RN 的鸿蒙适配层会带自己的运行时依赖如果之前升级过 Hermes 版本可能同时存在新旧两套 so 文件。我们检查 HAP 后发现确实有这种情况手动清理掉旧版 runtime 后HAP 又小了 2MB 左右。这块要小心so 的版本依赖经常是隐性的删掉旧 so 前必须有完整的原生回归测试。原生侧的优化不像 JS 层那么直观但对安装包体积的贡献非常明显。做完这一轮之后HAP 体积从 44MB 降到了 31MBAPK 从 39MB 降到 27MBiOS 也同步受益。6. 实测数据、容易翻车的地方和后续维护6.1 优化前后三端体积对比整场优化做下来拿测试机完整跑了一遍回归又专门找了两部低端参考机做冷启动测试最终数据如下指标优化前优化后变化JS Bundle8.7MB3.1MB下降 64%Android APK39MB27MB下降 12MB鸿蒙 HAP44MB31MB下降 13MBiOS IPA43MB30MB下降 13MB低端机冷启动首帧3.4s1.9s提升明显这里需要说明的是Bundle 的下降并不是单靠某一个手段完成的引擎切换、资源外置、拆包、依赖治理各自贡献了一部分。如果是想在自己的项目里复现收益我建议直接按照“依赖治理 - 资源外置 - 引擎切换 - 拆包”的顺序去推进而不是先把拆包这种复杂度最高的项目放在最前头。6.2 三个差点让我回滚的坑优化过程不可能一帆风顺重放几个我们遇到的坑希望你能绕开。第一个坑是拆包后的模块 ID 冲突。前面已经提到过基础包和业务包如果没有统一的模块 ID 规划两个包会让 require 系统无所适从。第一次拆包上线后我们遇到页面白屏日志里出现大量 module not found就是 ID 冲突导致的。解决方案是给基础包分配固定 ID 区间业务包从另一个起始点按文件名哈希分配并且同一个文件在基础包和业务包里绝不重复出现。第二个坑是字体子集化后的豆腐块问题。我们在子集化字体里没有保留完整的数字和符号集结果某些价格页面里的货币符号、百分号全部显示成方块。后来把常用符号范围重新加回子集回归测试才通过。这里建议做子集化时至少保留 ASCII 可见字符、常用标点和货币符号别为了极致瘦身把基本盘丢掉。第三个坑是 WebP 压缩的视觉失真。我们对一张渐变背景图用了 lossy 80肉眼虽然看不太出来但放到低端屏幕上边缘出现轻微色带UI 同学一口咬定不能接受。最终把 UI 相关图片全部改成无损或接近无损模式只留照片类素材用 lossy。WebP 的压缩参数不是越激进越好要按素材类型分开对待。6.3 后续我会盯住的检查清单优化完成只是一个节点防止回潮才是长期工作。我把这次的经验沉淀成了一份发版前检查清单现在每次发布都按这个流程走跑一次 Bundle 体积阈值检查超过 3.5MB 直接亮红牌先解决膨胀点再讨论发布。打开体积分析报告确认新增依赖有没有把不该带的模块带进来。检查图片资源是否全部位于资源目录新增素材默认禁止 base64 内联。扫一遍代码里有没有新增的console.logRelease 构建前统一移除。检查 HAP 架构配置确认生产包没有被 x86_64 占空间。做一次低端机冷启动抽测首帧超过 2.2 秒就要回头看是哪个模块拖了后腿。这套清单执行下来整个项目已经平稳跑过了两个迭代没有出现体积明显反弹的情况。最后再分享一个我个人的体会包体积优化这件事最重要的不是掌握多少个奇技淫巧而是先建立“每次新增代码都问一句体积代价”的意识。真正解决我之前 8.7MB 问题的不是某一招神操作而是把引擎、资源、依赖、拆包这些常规动作一个不落、按正确顺序做完。如果你手头项目也有类似困扰我建议你也先跑一次体积分析看看自己家底里到底谁是大头再做减法。很多团队一上来就想着上拆包和动态下发结果基础问题没解决复杂度倒是先上来了这样的项目往往走不远。