点击"在平板继续编辑"，到底发生了什么？

前四篇分别讲了实时同步、复杂对象、附件、持久化。这篇把它们串起来：从点击"在平板继续编辑"开始，一直到完整跨设备协作，整个链路是什么样的。

一、拉起远端应用是第一步

第一步：手机上点"在平板继续编辑"，先把平板上的应用拉起来。

这个用 startAbilityByCall。注意：这个要求两边是同一个应用，还要有 DISTRIBUTED_DATASYNC 权限。

这段代码解决什么问题： 拉起对端应用。
文件： distributed/CollabManager.ets
用途： 跨设备协作入口
接入位置： 点击"继续编辑"按钮

import { UIAbility } from '@kit.AbilityKit';

// 拉起对端 Ability
let want = {
  deviceId: targetDeviceId,
  bundleName: 'com.example.notes',
  abilityName: 'NoteAbility'
};

this.context.startAbilityByCall(want)
  .then((caller) => {
    // 拿到 caller，建立连接
    this.caller = caller;
  })
  .catch((err) => {
    console.error('拉起失败');
  });

二、拉起成功不代表数据链路建立

很多人以为：Ability 拉起来了，就可以同步数据了。不对。

拉起来只是把对端应用启动了。数据同步是另一条链路：还要建 Session、建分布式对象。

三、完整协作链路

完整的协作链路是这样的：

1. 选目标设备；
2. startAbilityByCall 拉起对端应用；
3. 生成 SessionId；
4. 建分布式数据对象同步；
5. KV 持久化；
6. Asset 附件同步；
7. 设备离线后清理 Session。

四、几个容易踩的坑

第一个坑：把 networkId 当永久设备标识。设备变了，networkId 也会变。

第二个坑：Ability 启动成功就认为数据链路建立成功。不对，还要建 Session。

第三个坑：SessionId 写死。每次协作用新的 SessionId。

第四个坑：退出协同时监听和 Caller 未释放。资源泄漏。

五、实时和持久化要分层

实时状态（正在编辑的笔记）用 DistributedDataObject，持久化数据（历史笔记）用 DistributedKVStore。

不要混在一起。实时的要快，持久化的要可靠。

这次做完整协作最大的体会是：跨设备协作不是一个 API 就搞定的。是拉起应用、建 Session、实时同步、持久化、附件，一整套链路串起来的。每一步都有它的作用，也都有它的坑。