本节目标理解方舟编译器 2.0 的 AOT 预编译、分层 JIT 与字节码优化机制掌握编译策略对包体积与启动性能的影响掌握 TreeShaking 的工作原理与构建配置能够通过死代码消除实现代码体积精简掌握包体积分析工具链Build Analyzer、扫描工具、AppAnalyzer的使用能够精准定位体积热点掌握资源压缩与精简的核心手段WebP 转换、资源收缩、密度限定词裁剪、字体子集化掌握 so 库优化方法strip去符号、compressNativeLibs压缩打包、ABI 精简掌握 HSP 动态共享包在多包场景下消除代码与资源重复拷贝的机制理解其与 HAR 的核心区别掌握 ArkGuard 字节码混淆的配置方法能够在安全性与兼容性之间取得平衡掌握依赖冲突解决override/resolve_conflict与按需加载模块的拆分策略能够为应用建立“分析定位 → 代码精简 → 资源瘦身 → so 库优化 → 架构级共享 → 混淆配置”的包体积治理闭环一、方舟编译器 2.0 与编译优化1.1 编译策略的核心变化方舟编译器 2.0 通过AOT 预编译 运行时 JIT 字节码优化三管齐下让 ArkTS 应用的启动速度提升 30% 以上运行时性能逼近原生 C/C。相比 1.02.0 在三个层面做了关键升级。AOT 预编译增强1.0 的 AOT 比较保守很多优化不敢做怕类型推断出错2.0 的类型推断更激进能内联的函数更多能消除的冗余更多。分层 JIT1.0 的 JIT 是“全量编译”2.0 改成了分层——先快速编译跑起来再根据运行时 Profile 对热点代码做深度优化。字节码优化2.0 重新设计了字节码指令集指令更紧凑解释执行更快。1.2 编译链路与包体积的关系ArkTS 编译器方舟编译器在构建过程中自动执行以下优化链路源代码 → 词法分析 → 语法分析 → 语义分析 → TreeShaking → DCE死代码消除→ 字节码生成。编译模式的选择直接影响最终产物AOT 预编译生成机器码字节码解释执行则生成更紧凑的.abc文件。Release 构建开启的 TreeShaking 和 DCE 会显著减小.abc体积。1.3 对开发者的实践意义你不需要懂编译器的实现细节但需要知道 2.0 做了什么优化以及怎么写代码才能让编译器帮你跑得更快。实际开发中Release 构建务必开启完整的编译优化链路避免因调试模式打包导致包体积虚高。二、TreeShaking 与代码精简2.1 TreeShaking 的工作原理TreeShaking摇树优化在编译构建过程中静态分析代码的依赖关系移除那些在代码中没有被引用未被“摇晃到”的类、函数、变量。它的名字很形象——摇动一棵树枯叶无用代码就会掉落只留下健康的叶子有用代码。TreeShaking 的工作流程编译器解析入口 → 构建依赖图 → 标记阶段从入口开始遍历可达的标记为 Live Code不可达的标记为 Dead Code→ 摇树阶段保留 Live Code剔除 Dead Code→ 生成优化后的字节码。2.2 TreeShaking 与 DCE 的区别两者是不同层次的优化TreeShaking在模块级别工作分析整个模块是否被引用DCE死代码消除在语句/表达式级别工作分析单条语句是否可执行。TreeShaking 的粒度更粗DCE 的粒度更细两者在编译链路中先后执行共同完成代码精简。2.3 构建配置与开启方式TreeShaking 在 Release 构建中默认开启但需要确保构建模式正确配置。在build-profile.json5的targets中确认buildOption未关闭相关优化。手动判断“这段代码有没有被用到”几乎不可能做到准确——一个工具函数可能被间接引用一个看似无用的类可能通过反射被加载。TreeShaking 由编译器自动完成比人工判断更精确。2.4 反射场景的保留配置当代码使用反射时被反射引用的类和方法无法被 TreeShaking 识别为“可达”可能被错误剔除。此时需要在混淆配置文件中通过-keep规则显式保留。ArkGuard 提供了-keep-property-name保留属性名称、-keep-global-name保留顶层作用域或导入导出名称、-keep-file-name保留文件路径及名称等选项。三、包体积分析工具链3.1 HAP 包结构剖析一个典型的 HAP 包本质上是 ZIP 压缩文件解压后包含entry.json模块配置、resources/资源文件目录、ets/ArkTS 编译产物含modules.abc字节码和sourceMaps.map、libs/原生库目录含各 ABI 架构的 so 文件、resources.index资源索引文件。从体积占比来看代码部分约占 20%-35%资源部分约占 40%-60%原生库部分约占 10%-30%配置与索引约占 1%-5%。资源通常是体积大户so 库次之代码部分可通过 TreeShaking 和混淆进一步压缩。3.2 Build AnalyzerDevEco Studio 内置的 Build Analyzer 在构建完成后分析.hap文件以图形化方式展示各个模块、依赖和资源文件所占的体积大小。它的作用是宏观定位——快速识别出是哪个 HAP、哪个依赖库或哪类资源贡献了最大的体积。3.3 扫描工具扫描工具可用于分析检测应用包根据不同的参数设定扫描指定路径的 App、HAP、HSP 包内容并输出检测结果报告为开发者优化包结构或排查问题提供数据支撑。扫描结果重点关注三类文件重复文件同一包内的重复资源或多包间的重复资源、较大文件确认是否必需图片可压缩、特定类型文件so 文件通过压缩选项优化。3.4 AppAnalyzerAppAnalyzer 是 DevEco Studio 提供的体检工具支持规则体检和上架前体检。通过菜单栏 Tools AppAnalyzer 打开可选择自动或手动方式模块选择框选择 HarmonyOS 应用/元服务工程模块。它涵盖兼容性、性能、功耗等多种测试类型帮助开发者在发布前系统性地发现包体积问题。四、资源瘦身4.1 图片格式优化图片资源通常占据 HAP 包体积的 40%-60%是优化的首要目标。WebP 格式比 PNG/JPG 压缩率高约 30%且支持透明通道应优先将 PNG/JPG 转换为 WebP。SVG 矢量图适合图标和简单图形体积极小且无损缩放。对大图进行裁剪或压缩避免在包内携带超出显示需求的原始尺寸图片。4.2 资源收缩与精简在build-profile.json5中配置资源收缩选项移除未引用资源。移除resources下从未引用的图片、字符串、动画、布局文件。通过 DevEco Studio 的 Build Analyzer 或扫描工具定位“零引用”资源。对于公共资源只放一处仅某功能使用的资源不要放主包。4.3 密度限定词裁剪如果资源统一存放在base目录可以移除ldpi~xxxhdpi全套密度目录。系统会向上就近匹配屏幕密度不存在时回退到base。这可以显著减少多套密度图片的重复体积。4.4 字体子集化如果引入了自定义字体只保留woff2格式删除ttf/otf/eot等其他格式。若只用到了部分字符如数字、字母可使用字体子集化工具仅提取实际使用的字形大幅减小字体文件体积。4.5 资源混淆ArkGuard 字节码混淆工具对资源文件名进行短名称混淆并对重复资源进行去重。资源混淆后资源标识符被替换为短名称进一步压缩资源索引体积。五、so 库优化5.1 strip 去除调试信息通过配置strip: true来去除 so 文件中的调试信息和符号表减小 so 体积。该配置需要配置在 HAP 和 HSP 模块中release 和 debug 模式下都可以配置。// build-profile.json5 nativeLib: { debugSymbol: { strip: true, // 执行 strip去除调试信息和符号表 exclude: [] // strip 过滤正则表达式规则 } }5.2 compressNativeLibs 压缩打包DevEco Studio 默认在打包应用时不压缩 so 库文件。配置 so 压缩选项后DevEco Studio 会将 so 库文件压缩并打包到应用中从而减小应用包的大小。// module.json5 { module: { compressNativeLibs: true // true 表示压缩 so 库 } }以 C 默认库文件为例压缩率可达 34%armeabi-v7a/libc_shared.so从 1108k 压缩至 386k。5.3 ABI 精简如果应用不需要支持所有 CPU 架构可以在构建配置中指定目标 ABI移除不必要的架构目录。对于含 NAPI 的工程只保留目标 ABI并用打包工具扫描重复的 so。5.4 验证方式优化 so 库后通过扫描工具确认各 ABI 目录下的 so 文件体积变化。注意compressNativeLibs仅控制打包方式压缩或不压缩不会自动把任意目录的 so 打进安装包so 文件仍需正确放置在libs/目录下。六、HSP 动态共享包与架构级共享6.1 HAR 的重复拷贝问题HAR 是静态共享包编译时被整体打包进每个引用它的 HAP 或 HSP 中。当多个模块引用同一个 HAR 时代码和资源会在各模块中生成独立副本。HAR 静态库被多个 HSP 间接依赖时会打出多份副本导致包体膨胀。6.2 HSP 的共享机制HSP 是动态共享包在运行时复用进程内只存一份。在应用存在多包HAP、HSP的场景中可以使用 HSP 动态共享包在多个包之间共享代码和资源消除 HAR 静态共享包导致的代码和资源重复拷贝从而减小应用包大小。6.3 创建与引用 HSP在 DevEco Studio 中创建 HSP 模块选择 File New Module模板类型选择 Shared Library点击 Next配置模块信息后点击 Finish。使用方在oh-package.json5中配置依赖后引用。6.4 与 HAR 的选型边界HAR 适用于通用的工具函数、UI 组件库、资源文件等不需要运行时共享单例的场景可以上传至 ohpm 仓库供其他开发者使用。HSP 适用于需要跨 HAP 共享单例对象的场景HAR 会导致多实例问题需要按需动态下载的功能模块将非核心功能编译为 HSP首次安装不包含在主包中多安装包需要资源共享的场景。注意事项大量使用 HSP 替代 HAR会在编译引用这些 HSP 共享包的模块时触发更多的语言编译任务导致编译耗时、编译内存占用增加需要综合评估。6.5 元服务分包实践元服务主包有 2MB 上限可以将非首屏 Tab 的业务模块拆到 HSP并从 entry 模块的oh-package.json5的dependencies中移除对 HSP 的静态依赖使 HSP 体积不计入首包。跨分包跳转使用NavPushPathHelper.pushPathByName跳转到 HSP 中的 NavDestination由系统托管 HSP 的下载与跳转流程。七、依赖冲突解决与按需加载7.1 依赖冲突导致的重复编译对于 ohpm 1.5.0 之前的版本如果 HAP 依赖了不同版本的 HAR例如 V1 版本的 harC 和 V2 版本的 harC默认情况下 V1 和 V2 两个版本的 harC 都会被打包到 HAP 中。这会导致显著的体积膨胀。7.2 override 机制使用 ohpm 的override机制强制统一依赖版本减少重复编译问题。在oh-package.json5中配置overrides字段指定统一使用的版本号。7.3 resolve_conflict 配置开启resolve_conflict解决依赖冲突减少依赖包导致的重复编译问题。在.ohpmrc中配置相关选项。7.4 按需加载模块将不常用的功能作为按需加载的模块。通过 HSP 分包实现启动必需代码和真正公共资源留主包二级功能页、其专属图片/字体/动画移入分包。运行的时候按需下载或者后台提前预加载。八、ArkGuard 字节码混淆8.1 混淆的作用与原理ArkGuard 是字节码混淆工具通过重命名标识符、打乱控制流、加密字符串来保护核心逻辑同时也能减小代码体积。混淆在 Release 构建中执行增加逆向工程难度保护知识产权。8.2 基础混淆选项推荐开发者在默认混淆的基础上在混淆配置文件中开启以下基础混淆选项-enable-toplevel-obfuscation顶层作用域名称混淆-enable-property-obfuscation属性名称混淆-enable-filename-obfuscation文件名称混淆-remove-comments移除注释8.3 保留选项与白名单混淆规则写不好线上直接崩。需要使用-keep-property-name来保留指定的属性名称使用-keep-global-name保留指定的导出/导入名称使用-keep-file-name保留文件路径及名称。DevEco Studio 提供了混淆助手工具ObfuscationHelper可以根据模块和场景对源码进行扫描快速识别需要配置的保留选项和白名单字段一键生成白名单混淆规则文件。8.4 混淆与 TreeShaking 的协同混淆在 TreeShaking 和 DCE 之后执行。TreeShaking 剔除不可达代码DCE 剔除死语句混淆将剩余代码的标识符重命名为短名称。三者协同工作实现代码体积的层层压缩。九、多元化习题习题 1判断题题目在 HarmonyOS 中TreeShaking 和死代码消除DCE是同一个优化层次都在模块级别工作。答案错误解读TreeShaking 在模块级别工作分析整个模块是否被引用DCE 在语句/表达式级别工作分析单条语句是否可执行。两者是不同层次的优化在编译链路中先后执行。习题 2单选题题目以下哪个字段配置在module.json5中用于压缩 so 库文件以减小应用包大小A.stripB.compressNativeLibsC.shrinkResourcesD.enableObfuscation答案B解读compressNativeLibs配置在module.json5中设为true表示以压缩形式打包 so 库文件。strip配置在build-profile.json5的nativeLib.debugSymbol中用于去除调试信息。shrinkResources用于资源收缩enableObfuscation用于开启混淆。习题 3多选题题目关于 HSP 相比 HAR 在包体积优化上的优势以下说法正确的有多选A. HSP 在运行时复用进程内只存一份消除代码和资源的重复拷贝B. HAR 在多个模块引用时会生成独立副本导致包体积膨胀C. HSP 相比 HAR 会减少编译耗时和编译内存占用D. 元服务可以将非首屏模块拆到 HSP使 HSP 体积不计入首包答案A、B、D解读HSP 在运行时复用进程内只存一份消除重复拷贝选项 A 正确。HAR 编译时被整体打包进每个引用它的模块生成独立副本选项 B 正确。大量使用 HSP 替代 HAR 会导致编译耗时和编译内存占用增加选项 C 错误。元服务可以将非首屏 Tab 拆到 HSP并从 entry 的 dependencies 中移除静态依赖使 HSP 体积不计入首包 2MB选项 D 正确。习题 4代码填空题题目请补全以下配置去除 so 文件中的调试信息和符号表。// build-profile.json5 nativeLib: { debugSymbol: { ______________: true, exclude: [] } }答案strip解读strip配置为true时会在 cpp 编译产物 so 上执行 strip 操作去除调试信息和符号表减小 so 体积。该配置需要配置在 HAP 和 HSP 模块中。习题 5代码改错题题目某开发者使用 ohpm 1.5.0 之前的版本HAP 依赖了 V1 和 V2 两个版本的同一个 HAR发现包体积异常增大。请指出问题并给出修正方案。答案问题在于 ohpm 1.5.0 之前的版本默认将依赖的不同版本 HAR 都打包到 HAP 中导致重复编译。修正方案是使用override机制或开启resolve_conflict强制统一依赖版本。// oh-package.json5 { overrides: { harC: 2.0.0 // 强制统一为 V2 版本 } }解读依赖冲突会导致多个版本的同一 HAR 被重复打包。通过override强制统一版本或开启resolve_conflict自动解决冲突可以减少依赖包导致的重复编译问题。习题 6简答题题目简述 HAP 包的体积组成以及各部分的优化手段。答案HAP 包体积主要由四部分构成代码部分ArkTS 字节码和 SourceMap约占 20%-35%优化手段包括 TreeShaking 剔除未引用代码、ArkGuard 混淆缩短标识符、Release 构建开启完整优化链路资源部分图片、字符串、布局文件等约占 40%-60%优化手段包括图片转 WebP/SVG、资源收缩移除未引用资源、裁剪密度限定词目录、字体子集化、资源混淆原生库部分各 ABI 的 so 文件约占 10%-30%优化手段包括 strip 去除调试信息、compressNativeLibs 压缩打包、ABI 精简配置与索引部分约占 1%-5%优化空间有限。解读资源通常是体积大户so 库次之代码部分可通过编译优化进一步压缩。优化前应使用 Build Analyzer 和扫描工具定位热点再针对性地优化。习题 7简答题题目简述在多包场景下如何综合使用 HSP、override 和按需加载来实现包体积优化。答案在多包HAP、HSP场景中HSP 用于在多个包之间共享代码和资源消除 HAR 导致的重复拷贝从而减小应用包大小。对于被多个模块间接依赖的公共 HAR应将其转为公共 HSP由各业务 HSP 共享真正消除重复体积。override 机制用于强制统一依赖版本避免不同版本的同一 HAR 被重复打包。按需加载模块将不常用的功能拆分为独立的 HSP并从 entry 的dependencies中移除静态依赖使这些模块的体积不计入首包。运行时通过NavPushPathHelper.pushPathByName跳转到 HSP 中的页面由系统托管 HSP 的下载与跳转流程。三者协同使用可以从架构层面系统性地控制包体积。解读包体积优化的最高层次是架构级优化。HSP 解决“重复拷贝”override 解决“版本冲突导致的重复”按需加载解决“首包过大”。三者的共同目标是让代码和资源在正确的位置只存在一份。十、本节知识点总结方舟编译器 2.0通过 AOT 预编译增强、分层 JIT 和字节码优化三管齐下启动速度提升 30% 以上。编译链路自动执行 TreeShaking 和 DCERelease 构建务必开启完整优化。TreeShaking在模块级别静态分析依赖关系剔除不可达的类、函数、变量。与 DCE语句级死代码消除互补。反射场景需通过-keep规则保留相关代码。包体积分析工具链Build Analyzer 宏观定位体积热点扫描工具输出重复文件、较大文件、特定类型文件的分析报告AppAnalyzer 提供规则体检和上架前体检。优化前先用工具定位再针对性处理。资源瘦身图片转 WebP压缩率约 30%或 SVG配置资源收缩移除未引用资源裁剪密度限定词目录字体子集化。资源通常占 HAP 体积 40%-60%是优化首要目标。so 库优化strip: true去除调试信息和符号表compressNativeLibs: true压缩打包压缩率约 34%ABI 精简移除不必要架构。HSP 架构级共享HSP 运行时复用、单副本消除 HAR 静态打包导致的重复拷贝。适用于跨 HAP 共享单例、按需加载模块、多安装包资源共享。需评估对编译性能的影响。依赖冲突解决override强制统一版本resolve_conflict自动解决冲突避免多版本 HAR 重复打包。按需加载模块将非核心功能拆分为 HSP不计入首包。ArkGuard 混淆开启顶层作用域、属性、文件名混淆和注释移除。通过-keep-property-name、-keep-global-name、-keep-file-name保留必要标识符。使用 ObfuscationHelper 一键生成白名单。下节预告第6课将进入 ArkUI 的 NDK 进阶与原生渲染管线的学习涵盖 Native 侧组件节点的深度操作、自定义绘制管线的搭建、以及 ArkTS 与 C 之间高性能数据通道的设计与实现。