一屏放两种视野：分屏导航要付的是双份管线与双份状态
一、贵的不是多一个视图，是每样东西都变成两份
外有一条适配消息值得从工程角度读：某地图产品完成了对某类折叠形态的适配，并把导航做成分屏，一侧显示车道级引导，另一侧显示常规地图上的前方路线与路况。机型参数、发布时间与体验评价都不在本篇范围。要看的只有一件事：两种视野并排之后，系统里原本按“一个视图”假设写下的每一处代码，都要重新回答一次。
单视图导航的隐性假设很强：只有一个相机、一条数据请求链路、一份可见区域、一组手势。分屏把它们全部拆成两路。三维车道级模型和常规矢量地图还是两套不同的绘制路径，它们对精度、层级切换和细节的要求不一样。多数地图引擎里，两个视图实例是各自持有瓦片解码结果与纹理资源的，除非显式做成共用一层数据源；字形图集有可能共用，但上传到图形上下文的那部分通常按上下文各留一份。这意味着面积没增加，资源却接近翻倍。
所以第一条结论是：把两路当成两条独立预算来谈，而不是当成“多画一次”。
二、状态必须只有一个真相
同一辆车的位置，在左右两侧显示出来不是同一个瞬间的事。左侧按车道级模型对齐，右侧按道路中心线投影；如果两侧各自维护一份车与路线状态，两侧就会在路口、隧道与匝道处出现分歧——一边显示已经过了路口，另一边还没到。这类分歧在单视图里不会出现，因为它只有一份位置。
一致性要按三条判据来设计。第一条，位置与朝向的唯一来源：两路渲染读取同一份定位与路径状态，禁止任何一路自行做平滑或外推，两侧的显示延迟差必须能被测量并被限定。第二条，重算时的更新顺序：路线一旦重算，先冻结两路的展示更新，等新路径在两侧都构造完成，再一次性切换；过渡期允许做遮罩或淡化，不允许出现左右两条不同的线。第三条，请求合并：两侧对同一路段、同一层级、同一版本数据的请求要能去重，切到后台时两路请求要合并成一条链路而不是各自继续拉取。
还有一处容易被忽略：路况这类时效数据在两侧的刷新节奏不同。右侧关注更远的路段、左侧关注近处路口，两侧对“多旧的数据还可以显示”的判断不一样。这个差值要显式配置并在日志里可见，否则排查时无法解释为什么两侧显示不一致。
三、面积减半之后要重算的东西
分屏把单侧可用面积切小，但没把任务切简单。原来按整屏尺寸定的东西要逐项重算：触控目标尺寸、最小可读字号、图标间距、路名标注密度、左侧三维模型的可视纵深。字号和触控目标不是等比缩小就行的，它们受可读性与命中率的物理约束，缩到临界点以后误触率会明显上去，而这是行驶中的场景。
误触容错的设计方向不是“更灵敏的撤销”，而是让高危动作不落在易误触区。路线切换、视图互换、全览这一类改变全局状态的动作，应放在明确的、面积足够的位置，并要求一次可确认的交互；纯浏览类的拖拽与缩放可以放宽。两侧各自持有独立手势时，边界处的归属要先定义清楚：一侧的缩放手势不能越界改写另一侧的相机，跨侧的手势要有一个优先级规则。
折叠形态本身还带来第三个问题：角度变化与展开收起时，两侧尺寸连续变化。布局重排要能在中间态稳定住，不要出现“每变一度重算一次样式”的抖动，也不要让两侧的渲染分辨率在临界比例来回切换。分屏比例可调这件事，还要考虑分辨率按面积分配与重采样带来的额外成本。
四、性能预算要按两路合并来定
单视图时代的预算常写成“帧率达标”，两路并行时这个口径不够用。有效的做法是把预算拆成四项，每项都能测、能归因。
- 合并帧率与最差帧时间：两侧同帧提交，取整帧的合计耗时与掉帧计数，而不是分别看两侧
- 每帧 CPU 与 GPU 时间上限：给瓦片解码、模型抽取、绘制提交各设一个可核对的时间片
- 冷启动与切换延迟：分屏首次进入、从单视图切到双视图、折叠状态改变后的重排耗时
- 热与降频：设备温度状态升高时，按预先定义的顺序削细节，而不是等系统强制限频后一起变糊
降级顺序要提前写成一张表并让它被测试覆盖：先削绘制细节与动态元素，再降非主视侧的分辨率或刷新节奏，最后才允许收回单视野。顺序反了就会出现“两侧一起变卡但都没坏”这种最难解释的现象。
五、断线与降级要告诉用户，不能悄悄变糊
三种典型退化情形要分别设计。网络质量差时，右侧的路况与更远的路线数据会缺，而左侧的近处引导仍可继续——此时应显式标注该侧数据不可用并保持最后已知状态，不要让缺失看起来像“这条路不堵”。定位漂移时，两侧的车位会各自表现出不同的抖动，要有一个统一的可信度判定决定车位是否继续更新显示，并在低可信度时给出提示。设备能力不足时，直接退回单视野是可接受方案，前提是退回了、为什么退回，用户能看到。
这三条的共同原则是同一条：降级是产品状态，不是渲染技巧。悄悄降分辨率，用户会归因为“这软件不行”；明确告知并已保留关键信息，用户知道功能边界在哪。
六、核心交付物表与给企业 App 的清单
| 成本或一致性项 | 两路并行时新增的开销与风险 | 验收判据 | 降级处理顺序 |
|---|---|---|---|
| 瓦片与三维模型数据 | 两侧层级不同，解码与内存占用翻倍 | 同一区域的数据请求去重命中率可查 | 先停远侧非关键层级 |
| 纹理与字形资源 | 各自持有上传资源，显存不随面积线性下降 | 双视图常驻显存与单视图的差值被记录 | 复用图集，禁止各建一份 |
| 渲染分辨率 | 按像素硬铺会白白多画 | 分辨率按可见面积分配，比例变更有重采样上限 | 先降非主视侧 |
| 车位与路线状态 | 两侧各自平滑会产生分歧 | 位置来源唯一，两侧显示延迟差可测量 | 冻结更新后一次性切换 |
| 路况刷新节奏 | 时效数据两侧节奏不同 | 最大允许陈旧度可配置并写进日志 | 标注不可用，保留最后已知态 |
| 手势与命中区 | 面积变小导致误触与边界归属冲突 | 跨侧手势优先级明确，高危动作不在易误触区 | 收起非必要的可交互元素 |
| 帧时间与热 | 两路提交叠加后更早触发限频 | 合并帧时间、掉帧数与温度状态同轴记录 | 削细节、降非主视侧、收回单视野 |
| 冷启动与形态切换 | 重排与二次构造把延迟集中暴露 | 进入分屏与折叠变化后的可感知延迟有阈值 | 先给占位再补齐，不做二次白屏 |
给企业自有 App 的可执行清单不长，但每一条都要落到用例上。多形态设备要单列一组回归：展开、收起、半折角度的停留、形态切换中的导航进行中、低端机型的退回路径。性能侧要留三个常驻指标：双视图合并帧时间、可见资源占用差值、降级触发次数与触发原因分布。洹拓科技在给客户端团队做交付时，会把“降级原因是否可解释”当作验收项而不是优化项，因为线上反馈里最难复现的那一类问题，几乎都是降级没打招呼。
最后一条经验：分屏的复杂度不在布局，在两份真相。布局问题一天能改完，状态不一致要跑很多次才能撞到，而且撞到时谁都说不清哪一侧是对的。