主题相关的坑，返回值经常撒谎。先对日志链路，再改资源和布局。 主题相关的坑，返回值经常撒谎。我现在习惯先对三条日志，而不是先改 JSON。这套习惯来自几次「接口成功、用户没看见」的现场：有人已经开始换图、改坐标，日志里其实连 OnThemeChanged 都没有。 第一条看切换。有没有 SwitchSuit，有没有 NotifyAllThemeRoots，每

控件已经上屏、指针停在默认角时，先问有没有 Start，再去怀疑图纸。 解析成功、控件也加进屏幕了，指针却停在默认角。这种单子，我现在会先问一句：ThemeRoot 调过 Start 没有？问完这一句，不少「渲染 bug」当场结案。图纸只决定树上有什么，Start 才决定树开始听数据。 画面不会在解析完自己跳起来。Start 做两件事：向

线上排过一类「假成功」：SwitchSuit 返回成功，预览名也变了，表盘还是旧的。根子往往不在接口，而在你手里那棵树是不是管理器认识的那棵。接口只保证「套名写进去了、通知发出去了」，并不保证你屏幕上那棵树在听众名单里。 设计选择很明确：外面拿到的 ThemeRoot 指针尽量不变，变的是肚子里的孩子。根已经挂在 ui_lite 的父容器上，若每次换套都 new 一个

在OpenHarmony中， 表盘首先是一份图纸，不是一堆硬编码控件。主题框架干的事很朴素：读 JSON、长出一棵能跟数据说话的树，再交给 ui_lite 去画。业务侧真正该关心的，是图纸写没写对、数据从哪路进来，而不是每个像素谁在 OnDraw。 你可以把它想成装修公司。业务只需要说「这一套叫机械风，首页指针听时钟，数字听车速」；安装、切换、解析、刷新，都走同一扇门。最外面是 C 接口