在OpenHarmony中，

表盘首先是一份图纸，不是一堆硬编码控件。主题框架干的事很朴素：读 JSON、长出一棵能跟数据说话的树，再交给 ui_lite 去画。业务侧真正该关心的，是图纸写没写对、数据从哪路进来，而不是每个像素谁在 OnDraw。

你可以把它想成装修公司。业务只需要说「这一套叫机械风，首页指针听时钟，数字听车速」；安装、切换、解析、刷新，都走同一扇门。最外面是 C 接口，C 和 C++ 都能调，静态库链进产品即可。里面是主题套管理器，套的安装、卸载、切换、配置落盘都从这里进出，避免各模块自己改目录、自己改当前套名。再往下，解析器把 theme_info.json 变成组件；数据代理挡住车上的真实数据，产品换适配器就行，不必改框架内核。ZIP、文件、缓存和加锁横着托住各层，让嵌入式上少漏内存、少留下半套皮肤。

真正让框架活得久的，是两处注入。启动时把数据源适配塞进去，时间、车辆、健康都走同一套回调门面；以后要加一种新控件，给解析器登记一种 theme_type 即可。加皮肤、加数据，尽量别去改共享仓——这是我们后来踩过的协作成本。共享仓一动，别的产品线、别的分辨率方案都可能被带上。能 overlay、能注册，就不要去改公共头文件。

还有一对容易混的概念：主题套是货架上的「这一套皮肤」，里面按 key 放首页、顶栏、停车页；ThemeRoot 才是屏幕上正在长着的那棵树。套可以换来换去，树的指针最好稳住，换的是叶子不是根。

如果你正在写第一张表盘，建议顺序是：先看管理器怎么装套，再看解析器怎么认 theme_type，最后才打开某个控件的 HandleFloatData。倒过来读，很容易把产品问题和框架问题缠在一起。一句话带走：先把图纸和注入点搞清楚，再去碰控件实现