控件已经上屏、指针停在默认角时，先问有没有 Start，再去怀疑图纸。

解析成功、控件也加进屏幕了，指针却停在默认角。这种单子，我现在会先问一句：ThemeRoot 调过 Start 没有？问完这一句，不少「渲染 bug」当场结案。图纸只决定树上有什么，Start 才决定树开始听数据。

画面不会在解析完自己跳起来。Start 做两件事：向数据代理登记「我关心哪些绑定类型」，并立刻拉一轮当前值，把现在这一刻摆上去。漏掉它，树在，数据不在。这是接入时最常见的遗漏，文档里也写过，真接到产品页面上还是容易忘——尤其是有人把 CreateThemeByKey 和 Add 写进了布局函数，却把 Start 留在「以后再说」的分支里。切主题时内部会先 Stop 再 Start，等于把绑定卸掉再挂上；如果你绕过管理器自己改树，这条节奏会被打乱。

之后靠推。时间、车辆按各自节奏敲门，回调找到订过这个类型的根，根再用 bindTypeViewMap 找到订过的控件，打到 HandleFloatData 或 HandleTextData。同一路时钟可以同时喂指针和数码管，路由表在收视图时就建好了。整条链都在进程内，用观察者传递，没有跨进程代理；文档里那个代理失败码，基本是历史预留。别把 C 接口理解成「另一边还有一个主题服务进程」。

推得勤不等于画得勤。ThemeDataCache 会把相同的浮点和字符串挡掉，避免无意义重绘。嵌入式上这比「数据来了必刷」更重要。控件在树上却看不见，先看时段、条件可见，再看缓存有没有把可见性关掉。扩展数据时，产品实现自己的数据源，并在适配层挂上类型区间，框架只认接口。

还有一种错觉：模拟器里指针在走，实车上停住。那往往是适配层注入晚了，或实车数据源根本没进路由，不是 JSON 突然失效。调试顺着链走：生产者有没有 Trigger，根有没有回调，控件有没有 Handle。缺哪截补哪截，别一上来改画布尺寸。