1000次控件更新，老方案1.9秒，新方案114毫秒。这不是优化，是换了一条路。
Flutter生态里有个叫Duit的BDUI（后端驱动UI）框架，最近干了件反直觉的事：他们把精心设计的类型安全体系拆了，退回了最原始的Map。结果性能翻了17倍。本文还原这个决策的完整时间线。
老方案：每个JSON字段都要"翻译"成Dart对象
Duit的早期设计很"正统"。服务端下发JSON，客户端解析成Dart的attribute类，每次更新都新建实例，再合并新旧状态。这套流程清晰、可维护、类型安全——直到动画场景暴露真相。
问题不在解析本身，而在解析的时机和频率。 热路径上，每一帧都可能触发更新，意味着每帧都在：解析JSON、创建对象、复制数据、分配内存、等待GC。1.9秒完成1000次迭代的代价，是用户能感知的卡顿。
作者的原话很直接：「It was structured. It was explicit. In a hot path, especially during animations, it was also too expensive.」
结构化的代价是速度。显式的代价是冗余。类型安全的代价，在特定场景下变成了性能债务。
转折点：为什么"正确"的抽象成了瓶颈
团队一度认为JSON是动态的，typed attribute classes是安全的，所以后者是正确抽象。这个逻辑漏掉了一个变量：对象的生命周期成本。
真正的开销不是类型转换，而是"过早地转换成太多短生命周期的对象"。 每次更新都走完整流程，相当于用豪华轿车的油耗跑通勤。
作者回溯了最初想回避的东西：裸Map。不是 unstructured 地信任 payload，而是重新设计Map的访问层。
DuitDataSource：给Map穿上类型外套
新方案的核心是一个extension type（扩展类型）：
extension type DuitDataSource(Map _json)
implements Map {
// typed accessors and converters
}
底层仍是廉价的Map存储，但暴露强类型的getter和转换方法：Color、Duration、Alignment、Curve、Border、Action、动画设置、命令载荷等。框架不再需要为每个widget维护独立的attributes类，DuitDataSource直接成为payload的类型访问层。
关键变化：解析延迟到真正需要时，对象复用代替重复创建，memoization缓存热点转换结果。 1000次更新从1.9秒压到114毫秒，差距17倍。
作者强调这不是微优化的胜利，而是数据层角色的根本转变。DuitDataSource现在承担解析、局部更新、缓存和大量热路径优化工作。
BDUI架构的隐性成本
Duit的定位是帮团队快速迭代UI、减少客户端发版、让小团队也能用上BDUI架构而不用自建平台。这些目标有个共同前提：远程描述UI的 runtime 成本必须可控。
老方案的类型安全是开发时的舒适区，但把成本转嫁给了运行时。新方案把舒适区压缩到访问层，释放了下层的性能空间。这个权衡对动画密集的场景尤其关键。
作者没有否认类型安全的价值，只是指出了上下文的重要性：「The problem was not that the framework started from Map. The problem was converting that map into too many short-lived objects too early.」
一个值得追问的细节
DuitDataSource的memoization策略具体如何失效？局部更新的粒度控制有没有边界案例？作者留了个口子：「This article explains why DuitDataSource is not just a typed wrapper... but the runtime layer that now handles... a large share of the framework's hot-path optimization work.」
"large share"意味着还有 share 没覆盖到。哪些场景仍需要回退到完整重建？extension type在 Dart 3 的完整能力有没有被榨干？
热门跟贴