HarmonyOS应用实战-启示散页-39-资源包体变大别只怪图片用资源账本解释动画、封面和 rawfile 来源一次发布前的包体对比突然多出数 MB团队先删了几张封面图体积却几乎没有变化。真正占空间的是默认题库 rawfile、重复放入多个模块的资源以及没人能说明用途的调试文件。只看图片会让排查从一开始就走偏。本文的边界先区分已有事实与设计建议已核对的工程边界是默认题库由 entry 的 rawfile 读取entry、HAR、HSP 分别拥有模块描述和资源目录。资源账本是本文建议增加的发布侧资料不属于应用运行时功能。因此本文不会把建议类代码当作已经上线的功能。它关注的是把问题放到正确 owner页面负责表达意图服务负责业务判断仓储负责稳定数据发布或启动期的检查只承担自己的职责。先还原故障链而不是直接修表面现象这类问题通常跨越三个阶段输入或构建产物进入系统、某个 owner 做出判断、结果在下一个入口或下次启动才被看见。只在症状页面补一行状态更新会让当前路径看似恢复却把错误留给重进页面、冷启动、另一个窗口或发布阶段。阶段应问的问题常见错误输入数据、资源或操作从哪里来直接相信页面数组或目录内容判断谁拥有校验、冲突和回退组件回调顺手写持久化提交什么结果应稳定保存半完成状态提前落库反馈哪些 owner 需要重新读取共享完整可变对象用一个小结果模型把判断说清楚下面的模型是这条链路需要对外解释的最小信息。它不等同于底层 Preferences JSON也不应混入State、导航栈或弹层开关。保持这种隔离存储结构或页面布局变化时业务判断仍可独立复查。interfaceResourceLedgerItem{path:string;ownerModule:entry|libraryHAR|libraryHSP;purpose:string;packaged:boolean;budgetBytes:number;}模型的字段要能回答两件事这次动作的结论是什么以及下一层需要据此做什么。无法解释业务结果的字段留在页面或诊断记录中不借机进入持久化对象。资源账本先回答文件为什么存在constledger:ResourceLedgerItem[][{path:entry/src/main/resources/rawfile/seed/default_deck.json,ownerModule:entry,purpose:首次启动默认题库,packaged:true,budgetBytes:48*1024},{path:media/the_book_of_answers/39/the_book_of_answers_39_cover.png,ownerModule:entry,purpose:CSDN 文章配图,packaged:false,budgetBytes:0}];constunexplainedledger.filter((item)item.packaged!item.purpose);if(unexplained.length0){thrownewError(存在没有用途说明的包内资源);}这里的关键不在语法而在边界临界输入先被规范化或校验输出保持可解释没有把组件实例、动画状态或整份用户内容带进这条路径。接入现有工程时应复用已存在的模型和仓储接口而不是并行复制一套名字相近的结构。从产物差异回推模块 ownerfunctioncompareLedger(before:ResourceLedgerItem[],after:ResourceLedgerItem[]):string[]{constknownnewSet(before.map((item)item.path));returnafter.filter((item)item.packaged!known.has(item.path)).map((item)${item.path}|${item.ownerModule}|${item.purpose});}这段处理放在服务或发布/启动编排层而不是按钮回调中。只有在关键操作成功后页面才更新展示并通知相关 owner 重新读取一旦失败旧数据应保持可见用户得到可以理解的下一步而不是一个已经变空的页面。当一个资源既没有启动调用点也没有发布用途时不能因为它位于 resources 目录就默认保留。默认题库 rawfile 的价值能被SeedLoader解释文章流程图只能由 Markdown 引用解释。两类文件即使都叫 PNG 或 JSON是否入 HAP 的结论完全不同。资源账本应成为发布评审材料每个新增包内文件对应一个模块 owner 和替代策略。若未来替换为网络资源、共享 HAR 资源或按需下载也应保留这次取舍而不是让下一位维护者再次从体积曲线猜来源。给失败路径一个与成功路径同等清楚的结果很多实现只写了成功分支资源能读就继续、草稿能保存就更新、导出能生成就分享。真正让问题难排的是失败后谁来保留旧状态、谁来给出可理解结果。下面的记录结构不要求原样进入工程它表达的是本文必须留下的证据字段操作对象、阶段、结果和下一步而不是用户题库正文或完整原始输入。interfaceArticle39OperationRecord{topic:资源包体变大别只怪图片用资源账本解释动画、封面和 rawfile 来源;subject:string;phase:prepare|commit|recover;outcome:ok|rejected|fallback;reason?:string;}functiondescribeArticle39Failure(subject:string,reason:string):Article39OperationRecord{return{topic:资源包体变大别只怪图片用资源账本解释动画、封面和 rawfile 来源,subject,phase:recover,outcome:fallback,reason};}这段边界避免了两个极端其一失败后只把页面清空导致用户不知道是否已经写入其二为了排障直接记录问题、答案或整份配置。本文所涉及的每个操作都应能在不泄露内容的前提下说明“失败在哪里、旧状态是否保留、下一步该做什么”。落地步骤按顺序消除不确定性从构建产物列出资源而不是从文件夹猜测。为新增条目写 owner、用途、是否入包和预算。将前后两次账本做差只审查新增的包内条目。对重复资源决定保留唯一来源、共享资源或明确接受重复。实施时先完成第一步的事实核对再添加设计层。特别是本文涉及当前工程尚未提供的能力时代码片段是落地方案不是对现状的描述不要为让页面尽快可点而绕过既有 Service 或 Repository。验证不只看一次正常操作构建前后导出资源清单每一条新增包内资源都能在账本中找到 owner 和用途media/the_book_of_answers/39下的三张文章 PNG 不出现在应用资源输入中。建议把验证结果按“静态结构、服务路径、真机运行”分开记录源码或清单只能证明配置与调用关系运行路径才证明生命周期、资源读取、持久化和页面接线发布平台的提交结果则需要在平台实际操作后再确认。constarticle39Acceptance{topic:资源包体变大别只怪图片用资源账本解释动画、封面和 rawfile 来源,staticEvidence:owner、目录或依赖方向已复查,serviceEvidence:异常输入、成功提交与回退结果可区分,runtimeEvidence:重进页面与冷启动后的结果一致,releaseEvidence:截图、日志和导出内容不包含用户正文};这份记录的作用不是替代真机或发布平台操作而是防止“源码看起来合理”被误报为“用户路径已经证明”。特别是涉及资源、发布截图和隐私的主题静态路径正确与实际产物正确之间仍隔着一次真实构建和设备复查。常见问题与定位顺序现象首先确认处理删除图片体积不降rawfile、动画或重复资源是否更大从构建产物重新分组不按扩展名猜测多模块各有同名文件是否真的需要各自携带指定唯一 owner必要时共享公共资源资源无来源是否缺用途和负责人禁止无账本条目进入发布候选排查时先从本文的 owner 和结果模型找起再回到页面调用点。只搜索某个按钮或文案大概率只能找到症状不会找到导致重进、重启或并发后出错的事实来源。取舍保持轻量但不把边界省掉这不是要求轻量应用引入庞大框架。真正需要的是一个可审查的判断点、稳定的数据边界和可复查的验证路径。只影响当前动画、展开和按钮禁用的状态可以留在页面会影响本地数据、多个入口、恢复或发布材料的规则则必须离开页面临时状态。判断合适位置只影响当前组件的展示节奏页面State会改变题库、收藏、历史或配置Service Repository需要唤起其他页面重新读取轻量刷新信号需要解释包体、截图或发布风险发布账本或受控场景合并前再问三个问题这段逻辑如果从另一个页面、快捷入口或恢复路径触发是否仍会走同一个判断点动作失败时旧数据、当前选择或发布材料是否会保持可解释状态下一位维护者能否从模型、仓储或账本定位这次变化而无需阅读某个组件回调三个问题中只要有一个答不上来就不应把逻辑继续塞进页面。此时更合适的动作是补齐 owner、把中间状态从持久化对象中拿出来或者先建立可以复现异常的最小样本。这样做增加的代码不多却能避免后续版本把一次临时修补扩散成长期数据债务。对于“资源包体变大别只怪图片用资源账本解释动画、封面和 rawfile 来源”这一主题还要把变更前后的事实保留下来变更前谁拥有数据或资源变更后哪个入口读取它失败时是否仍能回到可信状态。这样后续版本即使替换页面、调整模块或更换发布流程也不会失去判断依据。文中的模型和记录格式可以按项目命名调整但“事实、判断、提交、回退”四个环节不应省略。小结资源账本不是运行时扫描器。它的价值是让一次包体变化可解释避免把首页加载、资源排查和发布证据混在一起。败时是否仍能回到可信状态。这样后续版本即使替换页面、调整模块或更换发布流程也不会失去判断依据。文中的模型和记录格式可以按项目命名调整但“事实、判断、提交、回退”四个环节不应省略。小结资源账本不是运行时扫描器。它的价值是让一次包体变化可解释避免把首页加载、资源排查和发布证据混在一起。
)
