统一出口：所有模块复用的单例，统一 domain、tag（）与格式模板，Log 面板一条过滤条件看全应用。分级克制：INFO 记流程、ERROR 记失败（必带err.code）、DEBUG 记细节；可用预期的分支不要用 ERROR。敏感字段脱敏：默认模板%{public}s用于内部标识，用户数据等敏感字段改用或只记派生值。模块 TAG 前缀：在调用方叠加之类模块标识，实现"应用级过滤 + 模块级定

颜色一律走与限定词：深浅色取值声明在basedark两份color.json中，业务代码不做任何条件判断，系统自动匹配；dark目录只覆盖需要变化的资源，其余自动回退。业务态主题用 Provider/Consumer 管理：当"哪个页面是深色"由业务逻辑决定（而非系统主题）时，用广播、消费，避免逐层透传；断点参与决策时组合。图标成对管理、命名可识别：深色变体统一_dark_light后缀（），或用

启动链路按"onCreate 极简 → loadContent 先行 → 窗口配置后置 → 数据懒加载"的顺序编排；冷启动优化优先保证首帧时间：任何非必要同步工作都不要放在的同步段；首帧路径精简靠惰性构建：页签内容@Builder延迟执行、空态页签零成本、播放器不可见不初始化；防重入；多设备启动策略差异化：手表减组件、TV 保焦点、PC 并发窗口配置，但共享公共代码；启动性能同样要量化：用 Pro

stringify的 key 用法适合小对象；大数据集改用id或提升性能；JSON.parse返回值的as强转不提供运行时保护，必须逐字段校验并在构造函数兜底；嵌套结构采用"逐层 map 到模型类"的解析策略，与第 36 篇的嵌套模型一一对应；位图、资源、函数等运行时对象不可 JSON 化，传输层用标识字符串，展示层再映射；ArkTS 禁止eval，序列化只适用于纯数据 class，模型禁止循环引

分栏即效率：主列表 + 侧面板的并置布局用空间换时间，评论/个人作品从「串行进出」变为「并行切换」；断点裁决形态决定分栏还是半模态，一个开关（）驱动模式、点击拦截、空白关闭的全链路；动画响应式：评论面板无条件禁动画、个人作品按断点决定——动画策略随形态切换而非一刀切；面板内部继续断点化calc预留高度、背景色按断点切换、内容按密度筛选，侧面板不是手机的放大版；机制复用：平板、折叠屏展开态、PC、T

性能优化围绕卡顿、功耗、内存三个维度展开，先定位再动手，避免盲目微调；DevEco Profiler（帧率 / CPU / 内存三面板）与 HiChecker 是主要分析工具，Logger打点是工程级辅助；掉帧监控要落到关键路径事件（如 Swiper 切换、列表滑动）上，用数据说话；本项目的性能敏感点高度集中：视频流、评论列表、作品网格、路由转场与冷启动；结构性优化（懒加载、复用、释放）优先于样式

46 — 性能优化路径总览一、引言短视频应用是性能敏感的典型场景：主界面一启动就要承载视频流（Swiper + 多实例 AVPlayer）、评论列表（List + 嵌套回复）、个人作品九宫格（Grid + 图片墙），且要同时跑在手表、直板机、折叠屏、平板、电脑与智慧屏六类设备上。设备算力、内存、屏幕刷新率差异巨大，任何一个环节失控都会表现为滑动掉帧、发热掉电、内存暴涨甚至被系统回收。本项目从工程初

多设备兼容性的本质是"用版本约束圈住边界，用能力抽象消化差异"。双版本约束：compatibleSdkVersion 定下限、targetSdkVersion 定目标，二者随 SDK 演进同步维护，并在 README 中明确对外约束（HarmonyOS 5.0.5+、DevEco 6.0.2+），文档承诺与工程配置保持一致。deviceTypes 分组隔离：按交互形态而非屏幕尺寸分组，phone/

多设备兼容性与版本管理一、引言 多设备应用最大的技术债务不在 UI，而在"同一套代码跑在能力悬殊的六类设备上"。HarmonyOS 通过 compatibleSdkVersion/targetSdkVersion 双版本机制约束 API 面，通过模块 deviceTypes 约束安装目标，但真正的兼容性风险来自运行时差异：屏幕尺寸、交互方式、系统版本、性能水位。一个典型的翻车现

备份恢复是把"换机零丢失"变成产品卖点的系统能力，成本极低但收益明显。本工程四个产品模块通过"一个 backup 扩展 + 一个配置开关"即完成了能力接入，值得所有应用参考。显式声明：在 module.json5 注册扩展并在 metadata 中关联置 true。默认空实现：无预处理逻辑时 onBackup/onRestore 保持空实现，系统自动完成归档；不要在里面做耗时业务，备份回调有超时约