企业官网建设流程全解析

鸿蒙开发圈子里有个现象很有意思：很多人把超级终端当成一个“入口功能”，觉得那不就是碰一碰、拖一拖的炫技效果嘛，真正到自己上手做多设备协同开发时，翻开官方文档却发现分布式资产、跨端迁移的概念一个比一个抽象，Demo能跑通，但一换设备就崩，改了两个版本还在原地打转。

我自己也是从这条路走过来的。从最开始在手机上跑个单设备应用，到后来把计算、拍照、屏幕流转真正落到超级终端场景里，中间踩过的坑、翻过的源码、重新理解的系统架构，一点都不比当年从Android转鸿蒙时少。这篇东西就是想把“超级终端多设备协同开发”这件事彻底掰开揉碎，从底层原理到实战落盘，从设备认证到数据流转，完整讲清楚。

如果你正准备做鸿蒙APP开发，或者已经有单设备应用基础但不知道下一步怎么突破，这篇文章非常适合你。我会直接讲超级终端的核心机制、关键API、实战项目，以及那些文档里不会写的细节和坑。

1. 超级终端到底改变了什么：从“手机孤岛”到“设备池化”

很多做过传统移动开发的人，对超级终端的第一反应是“这不就是多屏互动吗”。如果你也这么想，后面做开发时会发现很多设计决策完全无法理解。所以第一个要解决的问题是：超级终端在系统架构层面到底做了什么。

1.1 设备从“独立硬件”变成“分布式资源”

传统开发模式下，一台手机就是一台手机，它的屏幕、摄像头、扬声器、传感器统统绑定在一个物理设备上。你做Android或者iOS开发时，拿到的API都是“本机API”——访问本机相机、本机存储、本机网络，所有能力边界都画在一个设备的外壳上。

超级终端打破的就是这层物理边界。在鸿蒙的分布式架构里，设备不再是一个不可拆分的黑盒，而是被抽象成一组可调用的分布式能力集合。你的一部手机、一块手表、一台平板、一个智慧屏音箱，连入超级终端后，它们各自的屏幕、摄像头、扬声器、麦克风，甚至算力，全部可以被上层应用按需调度。

这话不是修辞，而是实实在在的系统级能力。应用通过分布式软总线发现对端设备后，可以直接调用对端设备的摄像头进行拍摄，拍摄的数据不经过对端本地应用中转，而是通过分布式数据管理直接同步到本端应用。用户拿手机就能调用平板的摄像头、智慧屏的屏幕，这个体验就是超级终端“设备池化”的典型表现。

1.2 “一个应用多设备运行”的背后是分布式调度

再说一个很多初学者容易混淆的地方。我做第一版协同应用时，想当然以为超级终端就是把同一个APK在多个设备上装一遍，然后各跑各的，通过服务端中转数据。这其实是“多设备应用”而不是“分布式应用”，两者有本质差别。

真正的鸿蒙多设备协同开发，是通过能力调度把“逻辑分发”和“物理运行”分离。应用在一台设备上运行，但某个业务能力——比如收录音频、人脸识别、渲染复杂3D场景——可以动态决策并调度到另一台能力更适合的设备上执行。用户基本感知不到业务切换到了哪台设备，看到的只是整体任务被更高效地完成了。

这种设计对开发者的思维冲击是巨大的：你在写代码时，心里不能想“我的摄像头”或“我的屏幕”，而要开始想“业务需要调用一个摄像头能力，系统帮我找到了一个最合适的摄像头”。当这种思维转变真正建立起来后，再看超级终端相关的API，很多疑问都会迎刃而解。

1.3 开发思维要从“单设备生命周期”切换到“协同生命周期”

这可能是整个入门过程中最难跨过的一关。传统应用的生命周期跟着Activity或ViewController走，页面显示就启动，页面销毁就清理。而超级终端场景下，一个业务可能在本端启动、在对端续跑、再流转回本端，页面在某些情况下甚至处于“对端可见”状态。生命周期不再是一条直线，而是一张有多个连接点的网。

我当时梳理了一套自己的判断逻辑，后面做架构设计时一直在用：先看清楚当前业务模型到底是“分布式数据可以解决的”，还是“分布式能力必须介入的”。前者比如多端同步笔记、跨端延续播放进度，核心挑战是数据一致性和时序；后者比如调用另一台设备的相机、把渲染任务放到平板或智慧屏上，核心挑战是能力调度和生命周期对接。两个方向的技术栈不同，先用这个方式归类，后面选型就不会乱。

这里给刚入门的朋友一个建议：不必一开始就啃所有分布式API，先把你现有App里最适合协同的那个模块单独拆出来，比如跨设备续播、跨设备传文件、跨设备投屏，针对这个模块做分布式改造。我见过太多人一上来就想把所有功能都做成多设备协同，结果光设备状态判断就写了一堆分支，项目自然难产。

2. 分布式软总线：连接所有设备的隐形高速公路

聊超级终端多设备开发，绕不开分布式软总线。这是鸿蒙最底层、也是最重要的分布式基础设施。你可以不理解它的全部实现细节，但必须理解它的设计目标和能提供的“通信错觉”。

2.1 软总线解决的第一件事：发现与连接

想象一下你家里有多少智能设备：手机、平板、电视、音箱、手表、路由设备，再加上各种IoT设备。传统方案里，不同品牌、不同协议栈的设备之间想通信，需要各自适配对方的协议，这是个无底洞。

软总线做的事情，从上层看就是：设备在同一个账号信任组下，自动互相发现，自动组网，应用层不需要关心设备之间是走Wi-Fi、蓝牙还是其他底层通道，拿到的是统一的连接能力接口。

我举个对比更强的例子。传统模式下一个手机App想调用同一局域网内的电视播放能力，你得先自己写扫描、写协议、写配对、写连接管理，一套搞下来工程量不小。而鸿蒙开发里，如果这台电视已经加入了超级终端组网，你的应用通过分布式设备管理API就能直接查询到它、调用它的投屏能力，底层通路全部由软总线接管。

2.2 数据“直达”而非“中转”

软总线的另一个设计目标是数据传输的低延迟和高效率。分布式文件、分布式数据库之所以能让你感觉不到数据在哪台设备上，很大程度依赖软总线提供的传输通道。

我在做跨端文件传输时实测过，在同一Wi-Fi环境下，通过软总线做设备间文件直传，基本可以达到带宽上限，而且整个过程不需要应用自己搭Socket、不用管理断线重连、不用处理粘包拆包，这些底层问题被软总线屏蔽掉了。

不过需要注意的是，屏蔽不意味着不存在。应用层越省事，底层的状态管理就越复杂。你仍然需要关心设备掉线、链路切换、超时重试这类问题，只是处理粒度从“字节流”上升到了“业务事件”层级。

2.3 组网形态：不止“多对多”，更是“动态代谢”

超级终端组网不是静态的。一台设备掉线、新设备加入、网络状态波动，都会影响整个协同组的拓扑。写代码时最忌讳的就是把设备组当作静态数组去遍历，设备A、设备B、设备C写死在逻辑里。

我的做法是：把设备组看作一个动态集合，每个业务模块通过回调监听设备变化事件，设备上线时注册可用能力，设备下线时自动降级处理。这样即使协同组里少了一台设备，业务也能平滑过渡，不至于整个崩溃。

而且软总线的组网能力不仅限于一台手机和一台平板的“一对一”。一台终端可以同时作为多个协同组的成员，在不同业务中承担不同角色。举个例子，同一台平板，在“办公协同”场景里可能作为扩展屏幕，在“娱乐协同”场景里又可能作为独立播放器。角色由业务动态决定，不是硬件出厂定死的。

这一点在做方案设计时很有价值：你的应用不要假设设备有固定角色，而要设计成“根据当前协同组状态，动态决定设备角色”的架构。角色的变化一旦做成动态决策，超级终端真正发挥威力时，你的应用才不会措手不及。

3. 设备认证与组网：为什么你的设备总是“找不到”

很多初学者第一次跑分布式Demo时，卡得最久的问题往往不是API不会用，而是设备根本组不上网：两台设备明明都在身边，超级终端里能看到对方，代码里却查不到对端设备。这套设备认证与组网机制里，有一些心智模型必须先建立起来。

3.1 同账号是默认门槛，不是“技术限制”

首先要弄清超级终端设备发现的基本前提：默认情况下，设备要加入同一个超级终端协同组，必须在同一华为账号下，并且开启相应的协同功能。这个设计不是为了限制什么，而是从安全和隐私角度做的策略。

原因很好理解。软总线打通的是设备能力的深层调用，比如调用你手机摄像头、读取你手机数据。如果任何设备都能随意加入协同组，那隐私防线等于没有。同账号信任模型虽然简单，却是最现实的“先认证后通信”方案。

开发时遇到的问题往往是：测试设备和开发设备登录了不同账号，导致代码里无论如何都发现不了对端。我建议准备一组专门的测试设备，统一登录同一个测试账号，并确保设备系统版本满足分布式能力要求，这能省掉大量排查时间。

3.2 设备发现逻辑的“可见性”陷阱

另一个常见坑是设备发现接口的“可见性”参数。有些开发者调用设备发现时，发现接口返回的结果里看不到那台明明就在旁边的手机，便以为软总线有问题。

实际上，设备发现结果受设备自身的对外可见策略影响。就好比你在一个区域里开放了“允许附近设备发现我”，别人才能看到你；如果你关闭了可见性，就算物理上近在咫尺，逻辑上也是“隐身”的。

遇到这种情况，别急着怀疑代码，先去系统设置里确认那台设备是否开启了“允许被发现”。这也是我在实战中总结的经验之谈：排查组网问题，优先排查账号、可见性、网络环境三件事，而不是一上来就调试API参数。

3.3 网络环境对组网的影响比想象中大

软总线虽然底层会自适应多种通道，但并不意味着任何网络环境都能稳定组网。不同网段、开启了AP隔离的Wi-Fi、防火墙拦截了发现广播等场景，都可能导致设备发现失败或连接时断时续。

我在几次公开演示环境里就吃过亏。现场网络往往是复杂的企业Wi-Fi或多AP环境，设备组网非常不稳定。后来形成了固定习惯：重要演示前，要么准备一台手机开热点给其他设备接入，要么使用USB网络共享方式有线组网。实在不行再走传统“用手机流量开热点”的路线。

在网络模块设计上，我也建议开发者在代码里加一层“网络状态漂移检测”，而不是只依赖软总线回调。软总线回调在链路中断后触发存在延迟，如果你自己维护一份心跳或状态探测，在关键业务切换时有更快的感知，用户体验会好很多。

3.4 信任组与设备生命周期的关系

设备通过认证加入信任组后，并不是一劳永逸的。系统会周期性检查设备状态、账号状态，设备长时间离线或账号退出，都会导致信任关系重置。开发中一定要写好设备离线事件的处理，尤其是涉及分布式数据库同步时，要处理“设备离线期间数据的合并策略”。

我自己处理过的一个实际场景是：手机和平板协同办公，平板端编辑了一份文档，但手机端网络波动导致平板离线，文档修改没有实时同步。等平板重新组网时，双端都以为自己是“最后修改方”，产生了数据冲突。后来引入分布式数据库的冲突合并机制，并增加了基于版本的冲突仲裁策略，这个问题才稳定解决。

所以说，组网只是开始，真正考验工程能力的，是组网后的状态管理和数据一致性。

4. 跨设备业务流转：让应用在设备间“搬着走”

超级终端最有实用价值的场景之一，就是业务在不同设备间无缝流转：一部手机上看一半的视频，流转到智慧屏继续播放；手机上正在进行的导航，流转到手表上轻量显示；手机上的通话，流转到平板或音箱继续。

这类场景在鸿蒙里有一套完整的技术支撑，核心概念是跨设备业务流转。掌握了它，你的应用才算真正实现了“多设备协同”。

4.1 流转范式选择：同设备内迁移还是跨端启动

鸿蒙的流转能力分为两类，我习惯称为“搬家式流转”和“接力式流转”。

搬家式流转是动作迁移：业务从设备A迁移到设备B，设备A的界面退出，设备B继续执行。典型例子就是视频播放从手机“搬”到智慧屏，手机上退出全屏播放，智慧屏上接着播放当前进度。适合这种流转的业务，通常是有明确“当前状态”的，比如播放进度、游戏关卡、应用页面栈。

接力式流转则更像“同一个业务多端接力”：设备A的业务进入后台悬挂不销毁，设备B启动同一业务的另一个界面实例，双端可以各自独立操作，数据通过分布式数据库保持同步。比如手机上看文档时标注笔记，平板端同步打开同一份文档继续批注，两端看到的是同一个写操作的结果。

选择哪种方式，核心看业务模型是“唯一执行者”还是“多端共享”。这个决策直接影响你的架构设计，包括页面生命周期、数据同步方式、服务端状态机设计。

4.2 流转的核心API逻辑与状态保存

鸿蒙提供了一个关键接口来承接业务流转：continuation。调用方设备把业务状态打包成可序列化的数据，通过系统分发到目标设备，目标设备重启一个页面实例并恢复这些状态。这套流程对开发者最大的要求是：业务的“可恢复状态”必须彻底、完整。

我做过一个跨端文档编辑流转，踩过的最大的坑是：流转过去的界面看起来正常，但文档内部的“撤销/重做栈”没有同步过去。用户在原设备上做了几十步编辑，流转到新设备上想撤销，发现栈是空的。后来不得不把编辑历史也纳入状态打包范围，问题才真正解决。

这给开发者的启示很直接：当你梳理流转业务的状态时，不要只考虑展示层状态（当前页面、滚动位置、输入框文本），更要考虑交互历史状态和业务内部状态。只要有一项遗漏，流转到对端后就会出现“看起来正常，用起来不对劲”的怪异现象，也是最难排查的问题类型。

4.3 跨端数据同步：状态一致性的工程挑战

流转过程中，单次状态打包恢复只解决了“瞬间交接”，而更多协同场景要求“持续一致”。比如手机正在记步，手表需要同步显示实时数据；平板正在播放视频，手机上的遥控器面板需要实时显示播放进度。这种持续同步，靠的是分布式数据管理能力。

实务上我最常用的是分布式数据库和分布式对象。分布式对象适合结构复杂但数据量小的场景，同一时刻多端操作同一份逻辑对象，系统负责同步变更，你的代码模型就像一个“主对象”在不同设备上展示出不同视图，相当直观。分布式数据库则更适合结构化查询和分页加载场景。

使用分布式对象时有个关键认知：跨端同步的单元不是“字段级”而是“变更级”，你需要对自己的业务对象设计好版本控制。多个设备同时修改同一个对象时，谁赢谁输、怎么合并，是需要你明确设计的，不是甩给系统就可以。

我在“办公协同白板”项目里就吃过这个亏。多个用户同时对白板元素做修改，最初直接依赖分布式对象同步，结果经常出现元素位置跳动和写入覆盖，体验很差。后来我引入操作日志模型，每个设备上的操作先写本地日志，再加全局顺序同步冲突仲裁，才把多端写入的乱象理顺。涉及多人协同编辑类需求时，这个经验可以直接复用。

4.4 流转场景的典型适配：“手机为中心，多端为延伸”

从业务设计角度给个参考思路。在我做过的几个较成功的超级终端应用里，产品定位都是“手机作为计算中心和数据中心，其他设备作为能力延伸和信息窗口”。手机承载完整业务和重度计算，手表承载轻量提醒和快捷操作，平板和智慧屏承载大屏展示和沉浸交互。

这种设计的好处有两点。第一是逻辑清晰，每个设备的定位明确，开发时可以针对性设计界面复杂度和功能集；第二是符合用户直觉，超级终端本身就是以手机为核心拓展出去的形态，用户接受成本低。

做反过来的设计方案我也试过，比如让平板作为主计算中心，手机作为遥控器，但在当前生态下实现成本和体验成熟度都不如前者。如果你刚开始做多设备协同，建议先按“手机中心、多端延伸”这个模式走，跑通之后再尝试更复杂的角色动态分配。

5. 从零搭建多设备协同实战：跨设备投屏与续播Demo

原理讲再多，不落地都是空中楼阁。这里我直接给一个可以照着做的实战项目框架：做一个手机控制平板播放视频、手机端可随时接管播放进度的小应用。这个Demo覆盖面很典型：涉及设备发现、能力流转、分布式数据同步，等于把前面讲的核心机制全部串起来了。

5.1 项目结构设计与开发准备

先交代一下准备环境。我用的组合是两台运行HarmonyOS NEXT的设备，一台手机一台平板，登录同一个测试账号，共用一个Wi-Fi网络，开发者模式都开启。开发工具使用DevEco Studio，创建工程时选择支持分布式能力的模板。

工程建议拆成三个模块：

• 应用入口模块：负责初始化和全局状态管理
• 设备管理模块：负责设备发现、连接、状态监听，对上层提供统一的设备状态回调
• 播放业务模块：负责视频播放、进度上报、播放控制，不关心数据具体在哪台设备上渲染，只关心业务状态同步

这个模块划分的核心思路是：把设备生命周期和业务生命周期解耦。设备上下线只通知设备管理模块，播放业务模块不直接感知设备变化，收到的是上游整理后的“可用对端设备变化”事件。这样每层逻辑简单清晰，调试起来也非常顺。

5.2 设备发现与选择：从扫描到建立协同关系

设备发现部分，核心逻辑是注册设备发现回调，系统一旦发现信任组内的对端设备，就会通过回调通知你的应用。代码大概长这样：

// 分布式设备管理：启动设备发现 DistributedDeviceManager deviceManager = DistributedDeviceManager.getInstance(context); List<DeviceInfo> devices = deviceManager.getAvailableDevices(); if (devices != null) { for (DeviceInfo device : devices) { if (device.getDeviceType() == DEVICE_TYPE_TABLET) { // 找到目标平板，记录下来 targetDeviceId = device.getDeviceId(); } } }

这里有一点需要注意：设备发现是异步过程，界面刚打开时很可能还没有任何设备被发现，需要等待回调并配合界面提示。我开发时总是在界面上放置一个实时状态的“设备发现中…”文字，防止用户以为应用卡死了。

建立协同关系这一步，不需要开发者手动处理复杂的能力协商，系统在设备完成发现和认证后就已经把链路准备好了。你要做的，是记录下目标设备的设备ID，供后续流转和同步操作使用。

发现对端设备后，强烈建议把常用设备ID持久化缓存到本地偏好存储里，下次启动时先尝试直连缓存设备，连不上再全局扫描。这个优化能显著减少一次协同操作的热启动时间。

5.3 跨设备投屏：让平板播放手机上的视频

投屏场景里，业务状态包括：当前播放的视频源标识、播放进度、播放状态（播放中/暂停）、音量等。最直接的做法是通过流转能力把整个播放业务“搬”到平板上。

但这里有个设计陷阱需要特别提醒：如果直接把整个业务流转到平板，手机端就完全退出播放界面了，用户想在手机上再控制（比如调音量、暂停、切集）就失去触点。所以我的方案采用的是“双端同业务、不同角色”模式：平板端负责播放渲染，手机端负责控制和中控态保持，通过分布式对象同步状态。

核心逻辑大致是：手机端创建一个分布式对象，里面维护播放状态字段。平板端应用启动后，也从同一名称空间下获取同一个分布式对象，两端持有的是“同一个逻辑对象”。手机端修改播放命令字段，平板端监听字段变更，执行对应播放操作；平板端上报播放进度和自然播放结束事件，手机端同步刷新界面。

这个模型下，平板端逻辑本质就是一个“带状态的播放器”，手机端则是“遥控器+状态展示”。两端不依赖任何自己的服务器中转，所有同步走鸿蒙分布式能力，性能损耗和时延都非常低。实现跨设备控制的核心体验，代码模型却相当轻量。

5.4 状态同步的细节处理：进度、命令、去重

实现分布式对象同步时，细节决定成败。我这里列几个你一定要处理的边缘场景：

命令重复执行问题。手机端连续点击两次“暂停”，平板端如果对命令字段每次变更都触发一次暂停操作，第二次执行时会被业务逻辑忽略。为了避免“重复命令导致状态错乱”，可以给命令带上自增序号，平板端只处理序号大于本端最新序号的命令。

进度同步频率问题。播放进度字段如果每次更新都同步，对通信通道压力不小。我的做法是采用“高频本地更新，低频跨端上报”策略：平板上每秒钟上报一次播放进度分布式对象，但在本地更新进度UI时每秒刷新若干次。同步频率和显示频率分离，即使对端控制界面有一两秒延迟，也不会产生明显突兀。

设备掉线问题。如果平板退出协同组，手机端不应崩溃。业务设计上要做降级策略：检测到对端不可用时，自动在手机本地接管播放能力，启动本地播放器，从最后一次同步进度附近继续播放。这个降级策略让应用的协同能力从“酷炫功能”变成了“平滑可回退的安全增强”，用户的信任感完全不同。

以上写完，你实际上已经掌握了一个完整的多设备协同业务闭环：从设备发现、协同关系建立、业务流转、分布式状态同步，到异常降级处理。这个Demo虽然小，但它几乎覆盖了超级终端开发所有核心命题。在此基础上再做复杂功能，只是规模扩张，不是范式变化。

6. 多设备开发常见的坑与性能优化

最后这部分，理论和Demo都有了，我再集中讲一批容易被忽视的实际问题。这些问题在我的开发过程中都真实出现过，且几乎每一个都能让线上应用陷入尴尬境地。

6.1 生命周期管理：协同页面“没显示”不等于“不存在”

第一个坑就是生命周期感知偏差。单设备开发久了，容易默认“界面不可见=页面销毁”。但在多设备协同里，手机端业务流转到平板端后，手机端的界面可能还在后台栈里存活着，只是用户看不到它。此时手机端如果按传统逻辑在“页面不可见”时释放关键资源（比如关闭播放器、断开数据流），会导致流转过去之后，业务一恢复就异常。

针对这个问题，我总结了一套生命周期策略：协同业务必须有独立的运行状态机，不绑定在UI可见性上。播放器、连接、分布式对象这些核心资源，由状态机驱动运行，而不是跟着界面走。界面只是一个“显示器”，它显示状态机映射出来的状态变化。想清楚这个关系，多设备生命周期混乱问题能解决八成。

6.2 数据同步冲突：谁是最后一次写入的“胜者”

分布式数据库和分布式对象都提供同步能力，但同步不等同于共识。多端同时写同一份数据时，冲突在所难免。系统可能会有一版基本的解决策略，但如果你的业务对一致性要求较高（比如多人协同编辑、实时计费状态），就必须在业务层建立更严谨的冲突仲裁机制。

我采用过的最行之有效的方法，是“操作时间戳结合操作日志”的混合模式。每个操作都记录设备ID+单调递增序号，两个操作发生冲突时，按“序号大者胜”或“业务自定义优先级”处理。同时维护一份不可变操作日志，既能做冲突仲裁，又能做异常排查依据。这个设计让跨端数据一致性有了明确的交付标准，而不是交给系统碰运气。

6.3 性能优化：识别真正的网络瓶颈

超级终端开发中，最常见的性能误判是“遇到卡顿就怪软总线”。其实多数情况下瓶颈不在总线传输，而在于应用自己的数据模型设计。比如分布式对象里塞了一个巨大的Bitmap字段，每次变更都全量同步，不卡才怪。

性能优化第一原则是：控制同步数据粒度。能同步状态就不同步全量数据，能同步引用就不同步内容本身。例如视频续播场景，同步“播放进度、视频URL、播放状态”就够了，不需要把视频文件内容也搬过去。

第二原则是异步化。分布式操作天然有网络延迟，严禁在UI主线程里同步等待分布式数据库读写结果。我在早期版本里就犯过这个错误，一次分布式数据库查询直接卡顿主线程一秒多，界面直接掉帧。后来全部改为“回调/协程风格”，体验立刻恢复正常。

第三原则是合理利用缓存。设备组网后首次建立分布式连接往往有可感知的延迟，如果应用能在空闲状态提前建立并保活连接，用户正式触发协同操作时会觉得“秒开”。这个策略对超级终端应用的用户体验提升非常明显。

6.4 测试策略：多设备问题是“组合爆炸”问题

单设备测试可以穷举主要路径，多设备协同测试则完全不同。设备型号、系统版本、网络环境、设备状态、协同时机，任何一个变量变化都可能引出新问题。即使你只有一个明确的目标格局，比如“手机+平板”，也要在至少3种网络环境和两组不同设备型号上做完整测试，避免“只在这台设备上能用”的尴尬。

我的做法是建一个自动化冒烟测试脚本：启动设备发现、连接、流转、同步、断开、重连，一组标准动作跑完，任一环节失败就标记问题。再把测试设备组合在脚本里编排，一旦有新的测试机加入，先跑一遍冒烟脚本，保证基础协同能力没被破坏。这个测试习惯帮我挡住了大量回归问题。

另一个容易被忽视的测试角度是“系统级异常”：来电打断、通知弹出、应用切后台、设备息屏，这些系统事件在多设备协同状态下如何影响协同链路，非常值得专门测一轮。我经历过一个诡异Bug：电话一来，平板端播放声音就切到手机听筒，排查半天发现是音频焦点被系统按默认逻辑切换了，而应用没有重新申请音频焦点。这种问题如果只在纯功能路径里测试，永远测不出来。

关于后期演进，我的体会是多设备协同开发并不是把功能做出来就结束，整个开发过程中最花时间的不是写业务逻辑，而是把“设备从抽象概念变成你可控的资源”这个思维夯实，并在工程架构上为它留出足够的扩展空间。你今天写的一个分布式对象、一套冲突仲裁策略、一个状态机，很可能会成为明年更复杂协同业务的基石，所以在设计时不要只面向当前需求，稍微预留一点余量，后面能省掉一次大翻工。