跨平台统一会同时违反两边惯例
别名: 像素级统一 · 两边都不像 · 跨端同一套 UI
概念解释
把同一套像素界面发到 iOS 和 Android（或发到鸿蒙和微信小程序），看起来是在维护品牌一致，结果往往是两边的惯例各被踩一脚。iOS 用户失去导航栈提供的返回箭头和边缘滑动；Android 用户失去系统返回和他们预期的顶栏、悬浮按钮位置。这不是「只在一端交了学费」，而是两群已经被不同操作系统预训练过的人，同时被要求忘掉自己的那一套。统一最大化了品牌的相同，也最大化了惯例的破坏。
它处理的是「一套外观打两个平台」这种结构错误，不是单端跑偏有多贵，也不是该统一对象模型还是统一按钮皮肤。错误在于把两个人群当成了一个人群。
机制
两端惯例在关键动作上是不可调和的：返回是栈内的父级，还是系统级的上一步；主操作是导航栏右侧文字按钮，还是右下角的圆形悬浮按钮；设置是应用内齿轮，还是系统设置里的应用页。取交集会得到一个两端都不存在的第三种界面；取其中一端会把另一端变成「移植过来的异物」；取品牌自定义则两端都不像。三种取法都在同时向两群人收费。
像素统一的驱动力通常来自一套设计稿、一套组件库、一次评审，而不是来自用户。内部看并排截图时，两端长得一样会被当成完成；用户从来不并排使用两个客户端。他们各自带着自己平台的反射进来，所以「两边截图一致」和「两边都好用」不但不等价，还经常负相关：截图越像，反射被打断的对称性就越高。
边界
内容站点、营销页、游戏画布这类本来就没有系统列表、没有系统返回的表面，像素统一的伤害小得多，因为两端都没有可违反的框架惯例。内部工具若强制全员使用同一硬件，实际上只有一个平台，不存在「两边」。桌面端的 Web 应用面对的是浏览器惯例而不是 iOS / Android 惯例，统一的是浏览器之间，不能拿移动双端的逻辑来套。非常小的功能（一个开关、一行状态）两端惯例已经碰巧相同，统一没有额外破坏。真正的破坏发生在导航、返回、分享、支付这些框架动作上。
怎么落地
- 禁止用一张设计稿加两套切图作为双端交付；导航、返回、主操作位置、分享和系统面板按平台各出一版框架，再套同一套内容。
- 评审时不要把两端截图并排放到「像不像」上打分；分别找只使用该平台的人走同一条任务。
- 若业务坚持视觉统一，把统一限制在插画、品牌色和内容排版，明确列出哪些框架动作允许两端不同。
- 验证：同一任务分别找只用 iOS 和只用 Android 的人完成，记录各自在返回、主按钮、分享上的停顿。若两端都出现「这不像我的手机」且停顿点对称，说明统一正在两边同时收费。把框架改回各平台惯例后再走一次，品牌识别若仍在内容上成立，就证明先前卖掉的是惯例而不是识别度。