3. 多屏系统架构
做多屏测试这么多年，我最大的感触是：架构选型决定了测试策略的走向。你想想看，如果连屏幕之间怎么通信的都不清楚，那测试用例写得再漂亮也是白搭。
这一章，咱们就聊聊三种主流的多屏架构。我会结合自己踩过的坑，帮你把每种架构的特点、适用场景和测试要点理清楚。
3.1 主从屏架构（Master-Slave）
这是最常见、也最成熟的多屏方案。说白了，就是一块屏说了算，其他屏听指挥。
核心特征：
- 主屏负责业务逻辑、状态管理、数据分发
- 从屏只负责渲染和交互事件上报
- 通信链路单一，通常走 Wi-Fi 或蓝牙
我在做车载多屏项目时遇到过这么个事：主屏是中控，从屏是后排娱乐屏。用户在后排切歌，结果主屏的导航也跟着跳了。查了半天，发现是从屏把事件广播到了所有服务——典型的权限边界没划清楚。
测试要点
- 主屏故障容灾：主屏挂了，从屏能不能降级独立运行？
- 事件隔离：从屏的交互事件不能影响主屏的核心业务
- 同步延迟：主屏下发状态变更，从屏多久能响应？
避坑指南：我曾经在测试主从屏时忽略了一个细节——主屏重启后，从屏的状态恢复。结果上线后，主屏 OTA 升级完，后排屏全部卡在加载界面。后来加了个「心跳+状态同步」机制才解决。
3.2 分布式架构（Distributed）
这种架构下，每块屏都是对等的。没有谁依赖谁，各自独立运行，通过消息总线通信。
我参与过一个智能家居项目，客厅屏、卧室屏、厨房屏全是分布式架构。你猜怎么着？用户在厨房看菜谱，走到客厅想接着看——状态迁移成了最大的坑。
架构特点
| 维度 | 主从屏 | 分布式 |
|---|---|---|
| 控制权 | 集中 | 分散 |
| 故障影响 | 主屏故障影响全局 | 单点故障不影响其他屏 |
| 状态一致性 | 容易保证 | 需要分布式共识 |
| 测试复杂度 | 中等 | 高 |
测试难点
- 状态冲突：两块屏同时修改同一个状态，谁说了算？
- 网络分区：部分屏断连后，重新连上时状态怎么合并？
- 消息顺序：分布式环境下，消息到达顺序可能不一致
我的经验：测试分布式架构时，一定要引入「混沌工程」的思路。我习惯在测试环境中随机杀掉某个节点的进程，看看系统能不能自愈。说白了，分布式系统不是测它正常时多好，而是测它出问题时多稳。
3.3 云端协同架构（Cloud-Edge）
这种架构把计算和存储往云上搬，屏幕端只做轻量渲染。最近几年特别火，尤其是智能座舱和智慧零售场景。
嗯，这里要注意：云端协同不是简单的「屏幕连云端」，而是边缘节点和云端的分工协作。
三层结构
- 云端层：负责大数据处理、模型训练、全局状态管理
- 边缘层：负责实时计算、本地缓存、低延迟响应
- 终端层：负责 UI 渲染、传感器采集、用户交互
我做过一个智慧门店项目，20 块屏分布在 5 个楼层，全部走云端协同。结果上线第一天就出事了——网络抖动导致屏幕黑屏了 3 秒。后来加了边缘缓存策略，把常用数据预拉到本地，才解决这个问题。
测试关键指标
| 指标 | 说明 | 建议阈值 |
|---|---|---|
| 首帧加载时间 | 从点击到屏幕显示第一帧 | < 1.5s |
| 断网恢复时间 | 网络恢复后状态同步时长 | < 3s |
| 云端下发延迟 | 云端指令到终端执行 | < 500ms |
| 边缘缓存命中率 | 本地缓存满足请求的比例 | > 85% |
特别注意：云端协同架构下，离线体验是测试的重中之重。我曾经遇到一个场景：门店网络故障，所有屏幕直接变成「砖头」。后来强制要求：即使断网，屏幕也必须能展示本地缓存的最后状态。
3.4 三种架构对比总览
为了让你看得更清楚，我把三种架构的核心差异整理成了一张图：
3.5 架构选型决策树
在实际项目中，我一般按这个逻辑来选型：
- 屏幕数量：2-3 块 → 主从屏；4 块以上 → 分布式或云端协同
- 网络条件：局域网稳定 → 主从屏或分布式；广域网/弱网 → 云端协同 + 边缘缓存
- 实时性要求：毫秒级 → 分布式；秒级可接受 → 云端协同
- 运维能力：团队小 → 主从屏；有专业运维 → 云端协同
一个小技巧：我习惯在项目初期先搭一个「最小原型」，用最简单的架构跑通核心流程。等业务稳定了，再考虑要不要往分布式或云端协同迁移。别一开始就上最复杂的架构，否则测试成本会把你拖垮。
3.6 本章小结
三种架构没有绝对的好坏，关键看你的业务场景。主从屏简单可靠，分布式灵活高可用，云端协同适合大规模部署。但不管选哪种，测试的核心永远是：状态一致性、故障恢复、网络容错。
我个人建议：如果你刚开始做多屏项目，先从主从屏入手。等把通信机制、状态同步这些基本功练扎实了，再挑战分布式和云端协同。毕竟，架构可以演进，但测试思维得一步到位。