R4.14.1renderer-for-behavior tradeoff设计
统一渲染换来外观一致，代价是失去系统行为
别名: 自绘框架 · Flutter canvas · 统一渲染代价
概念解释
Flutter、游戏引擎、许多自绘 UI 框架在每一端用自己的渲染器画出像素，按钮在 iOS 和 Android 上可以做到外观同一。买到的是跨端静帧一致。付掉的是系统替你做的那些行为：滚动物理、文本选择手柄、分享表、返回手势、过度滚动、听写插入点。这份交换叫渲染换行为（renderer-for-behavior tradeoff）。外观一致不是品牌决策的副产品，而是渲染架构的直接后果。
它和「跨端统一外观会同时违反两边惯例」不是同一机制。那条说的是品牌选择站在哪一边。这条说的是：一旦像素由自家画布产出，系统行为基板默认不在了，要行为就得自己再做一遍，或者没有。
机制
系统控件是行为的寄宿处。滚动的惯性曲线、选择范围的放大镜、输入框与键盘的协同，都挂在系统对象上。自绘控件是一张会响应触摸的图，默认不接入这些寄宿处。框架可以模仿一部分——自己写滚动、自己画光标——但模仿是白名单：没被重做的行为就消失。操作系统一升级，系统应用自动跟上，自绘应用停在框架上次实现的那一版。
一致外观之所以便宜，正因为少接了基板。每一端少接一次，两端看起来更像。像的代价在第一次用户按系统肌肉记忆去操作时出现：该弹的选择菜单没有，该跟手的惯性不对，该被系统接管的手势被画布吃掉。
边界
只发一端、或明确做成游戏式全屏画布的产品，用户不带着系统肌肉记忆进来，交换的痛感低。用平台视图把个别系统控件嵌进自绘树，可以赎回局部行为，但嵌缝本身会在滚动和焦点上再开裂。Web 在浏览器里已经是一层自绘，代价结构类似，只是基板换成了浏览器而不是 UIKit。纯展示、无编辑、无系统分享的表面，失去的行为清单更短，交换可能划算。
怎么落地
- 在选定自绘框架时，列出必须保留的系统行为（选择、滚动物理、分享、返回、输入），并标明框架是提供、模仿，还是缺失。
- 把编辑、系统分享、支付、权限这些必须像系统的表面，优先用平台视图嵌回，而不是全部自绘。
- 设计稿不要把「两端像素级同一」写成成功标准；改成「两端任务同一，行为各自跟系统」。
- 验证：在真机上用系统备忘录或信息应用做对照任务（选中一段字、分享一张图、从边缘返回）。自绘应用里缺了或走样的每一步，都是这次交换付掉的行为。记入清单，而不是当成缺陷偶然。