包体积问题通常不是某一次提交突然造成的而是每次迭代都多一点资源、多一点依赖、多一点无用文件最后安装包变得越来越重。上架前才发现包太大再回头清理就很被动。这篇按 HarmonyOS 7 / API 26 工程来拆包体积治理。重点不是“删文件”三个字而是建立一套可复现的检查哪些资源重复哪些文件没有被引用依赖带来了什么产物构建前后体积变化是否超过阈值。先把体积分成几类类型常见来源处理方式图片资源多套重复截图、未压缩大图压缩、按尺寸拆分、删除未引用配置文件老活动配置、测试 JSON按环境隔离不进 release三方依赖只用一个函数却引入整包替换、拆 adapter、评估必要性本地调试文件mock、日志、临时导出构建前拦截重复代码产物多模块重复打包检查依赖边界先分类后面治理才不会变成到处乱删。建一个构建产物快照我会在每次 release 构建后记录一个体积快照。~~~tstype BundleFile {path: stringsize: numbertype: image | config | dependency | code | other}type BundleSnapshot {buildNo: stringtotalSize: numberfiles: BundleFile[]}function summarizeBundle(snapshot: BundleSnapshot): Recordstring, number {return snapshot.files.reduce((sum, file) {sum[file.type] (sum[file.type] || 0) file.sizereturn sum}, {} as Recordstring, number)}~~~这个快照不一定要一开始就很复杂。先能统计总大小和分类大小就能发现哪一类在涨。案例一图片重复导致体积慢慢涨图片重复很常见。比如同一张示意图在不同目录放了两份或者列表缩略图和详情图没有区分。~~~tstype ResourceHash {path: stringhash: stringsize: number}function findDuplicatedResources(resources: ResourceHash[]): ResourceHash[][] {const groups new Mapstring, ResourceHash[]()for (const item of resources) {const list groups.get(item.hash) || []list.push(item)groups.set(item.hash, list)}return Array.from(groups.values()).filter(list list.length 1)}~~~输出重复文件后不要马上删。先确认引用关系再决定保留哪一份。~~~tstype ResourceUsage {path: stringreferencedBy: string[]}function canRemoveResource(usage: ResourceUsage): boolean {return usage.referencedBy.length 0}~~~这一步能避免误删。资源治理不是越狠越好核心是删得有证据。案例二调试文件混进 release第二类问题是 mock、测试 JSON、临时日志混进 release 包。~~~tsconst forbiddenReleasePatterns [/mock/,/debug/,sample-data,temp-export,.log]function findForbiddenReleaseFiles(files: BundleFile[]): BundleFile[] {return files.filter(file {return forbiddenReleasePatterns.some(pattern file.path.includes(pattern))})}~~~这类检查适合放在 CI。只要 release 产物里出现这些路径就直接失败。~~~tsfunction assertNoForbiddenFiles(files: BundleFile[]): void {const forbidden findForbiddenReleaseFiles(files)if (forbidden.length 0) {console.info([bundle-check] no forbidden files)return}for (const file of forbidden) {console.error([bundle-check] forbidden file, file.path, file.size)}throw new Error(release bundle contains forbidden files)}~~~对比构建前后变化只看当前体积不够要看和上一次相比涨了多少。~~~tsfunction diffSnapshot(before: BundleSnapshot, after: BundleSnapshot): { type: string, delta: number }[] {const a summarizeBundle(before)const b summarizeBundle(after)const types new Set([...Object.keys(a), ...Object.keys(b)])return Array.from(types).map(type ({type,delta: (b[type] || 0) - (a[type] || 0)}))}function assertBundleDelta(before: BundleSnapshot, after: BundleSnapshot, limit: number): void {const delta after.totalSize - before.totalSizeif (delta limit) {throw new Error(bundle size increased too much: delta)}}~~~阈值要根据项目定。比如普通迭代超过 500KB 就提示超过 1MB 就阻断。大功能可以单独申请阈值但要写明原因。本地验证脚本先造两份快照看检查是否能跑通。~~~tsfunction verifyBundleCheck(): void {const before: BundleSnapshot {buildNo: api26-001,totalSize: 10_000_000,files: [{ path: /resources/a.png, size: 300_000, type: image },{ path: /src/main.abc, size: 2_000_000, type: code }]}const after: BundleSnapshot {buildNo: api26-002,totalSize: 11_300_000,files: [{ path: /resources/a.png, size: 300_000, type: image },{ path: /resources/mock/sample-data.json, size: 800_000, type: config },{ path: /src/main.abc, size: 2_100_000, type: code }]}console.info([bundle-diff], JSON.stringify(diffSnapshot(before, after)))assertNoForbiddenFiles(after.files)assertBundleDelta(before, after, 1_000_000)}~~~预期结果是 sample-data.json 被拦住总体积增长也会触发阈值。这样就能在 CI 阶段发现问题而不是上架前靠人工翻目录。包体积治理的取舍做法好处风险手动删大文件快容易漏容易误删每次构建生成快照可追踪需要维护脚本CI 设置阈值能阻断体积失控大功能需要例外机制资源 hash 去重能发现重复文件需要配合引用检查我的选择是快照加阈值作为基本盘重复资源和禁用路径作为专项检查。这样成本不高但能挡住大部分体积失控。上架前检查清单检查项通过标准release 产物没有 mock、debug、临时日志文件图片资源没有明显重复 hash体积变化相比上一版本涨幅在阈值内依赖变化新依赖有用途说明回归记录产物快照随版本保存小结HarmonyOS 7 / API 26 包体积治理要从构建产物出发不要靠临时翻目录。先做快照再查重复资源、禁用路径、依赖变化和体积阈值。这样安装包变大时能知道是哪一类在涨也能在 CI 阶段提前拦住。
包体积问题通常不是某一次提交突然造成的而是每次迭代都多一点资源、多一点依赖、多一点无用文件最后安装包变得越来越重。上架前才发现包太大再回头清理就很被动。这篇按 HarmonyOS 7 / API 26 工程来拆包体积治理。重点不是“删文件”三个字而是建立一套可复现的检查哪些资源重复哪些文件没有被引用依赖带来了什么产物构建前后体积变化是否超过阈值。先把体积分成几类类型常见来源处理方式图片资源多套重复截图、未压缩大图压缩、按尺寸拆分、删除未引用配置文件老活动配置、测试 JSON按环境隔离不进 release三方依赖只用一个函数却引入整包替换、拆 adapter、评估必要性本地调试文件mock、日志、临时导出构建前拦截重复代码产物多模块重复打包检查依赖边界先分类后面治理才不会变成到处乱删。建一个构建产物快照我会在每次 release 构建后记录一个体积快照。~~~tstype BundleFile {path: stringsize: numbertype: image | config | dependency | code | other}type BundleSnapshot {buildNo: stringtotalSize: numberfiles: BundleFile[]}function summarizeBundle(snapshot: BundleSnapshot): Recordstring, number {return snapshot.files.reduce((sum, file) {sum[file.type] (sum[file.type] || 0) file.sizereturn sum}, {} as Recordstring, number)}~~~这个快照不一定要一开始就很复杂。先能统计总大小和分类大小就能发现哪一类在涨。案例一图片重复导致体积慢慢涨图片重复很常见。比如同一张示意图在不同目录放了两份或者列表缩略图和详情图没有区分。~~~tstype ResourceHash {path: stringhash: stringsize: number}function findDuplicatedResources(resources: ResourceHash[]): ResourceHash[][] {const groups new Mapstring, ResourceHash[]()for (const item of resources) {const list groups.get(item.hash) || []list.push(item)groups.set(item.hash, list)}return Array.from(groups.values()).filter(list list.length 1)}~~~输出重复文件后不要马上删。先确认引用关系再决定保留哪一份。~~~tstype ResourceUsage {path: stringreferencedBy: string[]}function canRemoveResource(usage: ResourceUsage): boolean {return usage.referencedBy.length 0}~~~这一步能避免误删。资源治理不是越狠越好核心是删得有证据。案例二调试文件混进 release第二类问题是 mock、测试 JSON、临时日志混进 release 包。~~~tsconst forbiddenReleasePatterns [/mock/,/debug/,sample-data,temp-export,.log]function findForbiddenReleaseFiles(files: BundleFile[]): BundleFile[] {return files.filter(file {return forbiddenReleasePatterns.some(pattern file.path.includes(pattern))})}~~~这类检查适合放在 CI。只要 release 产物里出现这些路径就直接失败。~~~tsfunction assertNoForbiddenFiles(files: BundleFile[]): void {const forbidden findForbiddenReleaseFiles(files)if (forbidden.length 0) {console.info([bundle-check] no forbidden files)return}for (const file of forbidden) {console.error([bundle-check] forbidden file, file.path, file.size)}throw new Error(release bundle contains forbidden files)}~~~对比构建前后变化只看当前体积不够要看和上一次相比涨了多少。~~~tsfunction diffSnapshot(before: BundleSnapshot, after: BundleSnapshot): { type: string, delta: number }[] {const a summarizeBundle(before)const b summarizeBundle(after)const types new Set([...Object.keys(a), ...Object.keys(b)])return Array.from(types).map(type ({type,delta: (b[type] || 0) - (a[type] || 0)}))}function assertBundleDelta(before: BundleSnapshot, after: BundleSnapshot, limit: number): void {const delta after.totalSize - before.totalSizeif (delta limit) {throw new Error(bundle size increased too much: delta)}}~~~阈值要根据项目定。比如普通迭代超过 500KB 就提示超过 1MB 就阻断。大功能可以单独申请阈值但要写明原因。本地验证脚本先造两份快照看检查是否能跑通。~~~tsfunction verifyBundleCheck(): void {const before: BundleSnapshot {buildNo: api26-001,totalSize: 10_000_000,files: [{ path: /resources/a.png, size: 300_000, type: image },{ path: /src/main.abc, size: 2_000_000, type: code }]}const after: BundleSnapshot {buildNo: api26-002,totalSize: 11_300_000,files: [{ path: /resources/a.png, size: 300_000, type: image },{ path: /resources/mock/sample-data.json, size: 800_000, type: config },{ path: /src/main.abc, size: 2_100_000, type: code }]}console.info([bundle-diff], JSON.stringify(diffSnapshot(before, after)))assertNoForbiddenFiles(after.files)assertBundleDelta(before, after, 1_000_000)}~~~预期结果是 sample-data.json 被拦住总体积增长也会触发阈值。这样就能在 CI 阶段发现问题而不是上架前靠人工翻目录。包体积治理的取舍做法好处风险手动删大文件快容易漏容易误删每次构建生成快照可追踪需要维护脚本CI 设置阈值能阻断体积失控大功能需要例外机制资源 hash 去重能发现重复文件需要配合引用检查我的选择是快照加阈值作为基本盘重复资源和禁用路径作为专项检查。这样成本不高但能挡住大部分体积失控。上架前检查清单检查项通过标准release 产物没有 mock、debug、临时日志文件图片资源没有明显重复 hash体积变化相比上一版本涨幅在阈值内依赖变化新依赖有用途说明回归记录产物快照随版本保存小结HarmonyOS 7 / API 26 包体积治理要从构建产物出发不要靠临时翻目录。先做快照再查重复资源、禁用路径、依赖变化和体积阈值。这样安装包变大时能知道是哪一类在涨也能在 CI 阶段提前拦住。
)
