CN115941674B - 多设备应用接续方法、设备及存储介质 - Google Patents

Abstract

本申请提供了一种多设备应用接续方法、设备及存储介质。该方法中，发起应用接续请求的设备通过确定本次要进行接续传输的文件是否为首次进行接续传输，进而在确定该文件为非首次传输，即接收端已经存在本次编辑前的文件的情况下，在接收到接收端做出的应用接续响应后，直接采用差量传输方式与接收端进行应用接续，即仅向接收端传输当前编辑后的文件与之前版本存在区别的差量数据，从而大大缩短了应用接续过程中数据传输的耗时。

Description

多设备应用接续方法、设备及存储介质

技术领域

本申请涉及多设备通信技术领域，尤其涉及一种多设备应用接续方法、设备及存储介质。

背景技术

多设备应用接续是发生在近场同账号下的多个设备间接续任务的无缝流转。例如，用户在设备A中操作支持接续的应用编辑某一内容，当产生切换设备的需求时，用户只需在需要切换到的设备，如设备B中响应接续请求，即可实现在设备B上继续操作上述内容。

然而，在实际使用场景中，用户可能在设备A和设备B中对同一应用处理的同一内容频繁进行接续传输。因此，缩短多设备应用接续传输的耗时，保证多设备应用接续传输的成功率尤为重要。

发明内容

为了解决上述技术问题，本申请提供一种多设备应用接续方法、设备及存储介质，旨在缩短多设备应用接续传输的耗时，同时保证多设备应用接续传输的成功率。

第一方面，本申请提供一种多设备应用接续方法，应用于第一设备。该方法包括：在使用注册为接续应用的第一应用编辑第一文件的过程中，向第二设备发送针对第一应用的应用接续请求；在第一文件为非首次进行接续传输时，在接收到第二设备针对应用接续请求做出的应用接续响应后，采用差量传输方式，将第一文件中的差量数据传输至第二设备；其中，在第一文件为非首次进行接续传输时，采用差量传输方式传输第一文件的时间小于采用全量传输方式传输第一文件的时间。

这样，当要进行接续传输的第一文件不是首次进行接续传输时，直接采用差量传输方式传输差量数据，而非将第一文件的全部数据都传输给第二设备，从而大大缩短了多设备应用接续过程中接续传输文件所花费的时间。

此外，由于第一设备和第二设备之间，对第一文件多次进行的接续传输均采用的差量传输方式，因此每次接续传输的数据量相对整个第一文件的数据要少很多，从而能够有效避免多设备应用接续过程中传输失败的情况，大大提升了保证多设备应用接续传输的成功率。

根据第一方面，检测本地是否存在与第一文件对应的文件数据信息表，文件数据信息表中的信息用于指示第二设备做出应用接续响应后，启动安装在第二设备上的第一应用，并加载第一文件；在存在与第一文件对应的文件数据信息表时，确定第一文件为非首次进行接续传输；在不存在与第一文件对应的文件数据信息表时，确定第一文件为首次进行接续传输。

这样，只有首次进行接续传输的第一文件才采用全量传输方式传输，后续对第一文件进行接续传输时，直接采用差量传输方式传输的差量部分，从而大大缩短了多设备应用接续过程中接续传输文件所花费的时间。

根据第一方面，或者以上第一方面的任意一种实现方式，在确定第一文件为首次进行接续传输之后，方法还包括：根据第一应用和第一文件，构建与第一文件对应的文件数据信息表，文件数据信息表携带了第一文件的全部数据；在接收到第二设备针对应用接续请求做出的应用接续响应后，采用全量传输方式，将文件数据信息表传输至第二设备。

根据第一方面，或者以上第一方面的任意一种实现方式，根据第一应用和第一文件，构建与第一文件对应的文件数据信息表，包括：根据第一应用和第一文件，生成文件唯一标识，文件唯一标识指示了第一文件和第一应用的关系；根据第一文件生成文件基础公共信息和数据原子集合，数据原子集合携带了第一文件的全部数据；根据数据原子集合中的数据，生成文件数据特征码，文件数据特征码用于标识第一文件中的数据；根据文件唯一标识、文件基础公共信息、数据原子集合和文件数据特征码，生成文件数据信息表。

根据第一方面，或者以上第一方面的任意一种实现方式，在采用差量传输方式，将第一文件中的差量数据传输至第二设备之前，方法还包括：对第一文件进行随机扫描，生成临时数据原子集合；根据临时数据原子集合中的数据，生成临时文件数据特征码；在临时文件数据特征码与文件数据信息表中记录的文件数据特征码不同时，执行采用差量传输方式，将第一文件中的差量数据传输至第二设备的步骤；在临时文件数据特征码与文件数据信息表中记录的文件数据特征码相同时，不向第二设备传输第一文件的数据。

根据第一方面，或者以上第一方面的任意一种实现方式，方法还包括：在采用差量传输方式，将第一文件中的差量数据传输至第二设备，或者采用全量传输方式，将文件数据信息表传输至第二设备之后，保存第一文件，并退出可以编辑第一文件的界面。

这样，在第一文件被接续到第二设备中的第一应用编辑处理时，退出第一设备中对第一文件进行编辑的界面，从而避免第一设备持续与第二设备进行数据传输，降低设备功耗和资源的占用。

根据第一方面，或者以上第一方面的任意一种实现方式，在退出可以编辑第一文件的界面之后，方法还包括：在第一应用不处于前台运行时，在接收到第二设备发送的针对第一应用的应用接续请求时，在第一应用对应的第一应用图标上添加应用接续标识；响应于对添加了应用接续标识的第一应用图标的操作，将第一应用切换为前台运行，并加载本地的第一文件，以及第二设备采用差量传输方式传输的第一文件的差量数据。即，在多设备应用接续的场景中，第一设备可以作为数据的发送端，也可以作为数据的接收端，从而在第一设备和第二设备之间，更好的实现应用接续业务的无缝协同作业。

根据第一方面，或者以上第一方面的任意一种实现方式，根据差量数据，更新文件数据信息表。

这样，能够便于后续进行应用接续时，精准的判断是否需传输数据。

根据第一方面，或者以上第一方面的任意一种实现方式，在第一应用对应的第一应用图标上添加应用接续标识后，方法还包括：在设定时间内没有接收到对添加了应用接续标识的第一应用图标的操作时，取消第一应用图标上的应用接续标识；其中，取消应用接续标识后，第一设备无法与第二设备针对第一应用进行应用接续。

这样，通过设置在设定时间内允许第一设备与第二设备进行应用接续，如果设定时间内用户没有在第一设备针对应用接续请求做出应用接续响应，即触发携带应用接续标识的第一应用图标，则取消应用接续标识，避免第一设备一直处于等待用户做出应用响应的状态，降低第一设备的功耗。

根据第一方面，或者以上第一方面的任意一种实现方式，方法还包括：在采用差量传输方式，将第一文件中的差量数据传输至第二设备，或者采用全量传输方式，将文件数据信息表传输至第二设备之后，继续停留在可以编辑第一文件的界面；其中，第一文件的界面中显示的第一文件的内容与第二设备中第一文件的内容保持同步。

由此，在第一设备和第二设备之间实现了对第一应用的无缝协同处理。

可理解的，在第二设备显示第一文件后，用户在哪一个终端设备编辑第一文件，该设备就作为应用接续过程中，数据的发送端，另一个则为接收端。

根据第一方面，或者以上第一方面的任意一种实现方式，在向第二设备发送针对第一应用的应用接续请求前，方法还包括：确保第一设备和第二设备开启了应用接续功能、蓝牙功能和无线局域网功能。

这样，保证第一设备和第二设备能够组成超级终端，在第一设备和第二设备之间实现应用接续业务的无缝协同作业。

第二方面，本申请提供一种多设备应用接续方法，应用于第二设备。该方法包括：在第二设备安装了第一应用的情况下，在接收到第一设备发送的针对第一应用的应用接续请求时，在第一应用对应的第一应用图标上添加应用接续标识；响应于对添加了应用接续标识的第一应用图标的操作，向第一设备发送针对应用接续请求做出的应用接续响应，并将第一应用切换为前台运行；在接收到第一设备采用全量传输方式传输的文件数据信息表后，从文件数据信息表中的数据原子集合中解析出第一文件的全部数据，加载显示，并将文件数据信息表保存到本地；在接收到第一设备采用差量传输方式传输的第一文件的差量数据后，加载差量数据，以及本地存储的第一文件进行显示，并根据差量数据更新本地存储的文件数据信息表。

这样，只有首次进行接续传输的第一文件采用全量传输方式传输时，才需要等待加载，后续对第一文件进行接续传输时，直接加载第一设备采用差量传输方式传输的差量部分，其余相同部分从本地加载，从而大大缩短了多设备应用接续过程中接续传输文件所花费的时间。

根据第二方面，方法还包括：在接收到第一设备发送的针对第一应用的应用接续请求后，在设定时间内没有接收到对添加了应用接续标识的第一应用图标的操作时，取消第一应用图标上的应用接续标识；其中，取消应用接续标识后，第二设备无法与第一设备针对第一应用进行应用接续。

这样，通过设置在设定时间内允许第二设备与第一设备进行应用接续，如果设定时间内用户没有在第二设备针对应用接续请求做出应用接续响应，即触发携带应用接续标识的第一应用图标，则取消应用接续标识，避免第二设备一直处于等待用户做出应用响应的状态，降低第二设备的功耗。

根据第二方面，或者以上第二方面的任意一种实现方式，方法还包括：在第二设备未安装第一应用的情况下，在接收到第一设备发送的针对第一应用的应用接续请求时，提示用户安装第一应用。

这样，提醒用户安装第一应用后，后续第一设备和第二设备便可以针对第一应用进行应用接续，实现对第一应用中第一文件在第一设备和第二设备的无缝切换，协同作业。

第三方面，本申请提供了一种终端设备。该终端设备包括：存储器和处理器，存储器和处理器耦合；存储器存储有程序指令，程序指令由处理器执行时，使得所述终端设备执行第一方面或第一方面的任意可能的实现方式中的方法的指令，或者使得所述终端设备执行第二方面或第二方面的任意可能的实现方式中的方法的指令。

其中，终端设备可以是上述所说的第一设备，也可以是上述所说的第二设备。

示例性的，在终端设备为上述所说的第一设备时，第三方面以及第三方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。故而，第三方面以及第三方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。

示例性的，在终端设备为上述所说的第二设备时，第三方面以及第三方面的任意一种实现方式分别与第二方面以及第二方面的任意一种实现方式相对应。故而，第三方面以及第三方面的任意一种实现方式所对应的技术效果可参见上述第二方面以及第二方面的任意一种实现方式所对应的技术效果，此处不再赘述。

第四方面，本申请提供了一种计算机可读介质，用于存储计算机程序，该计算机程序包括用于执行第一方面或第一方面的任意可能的实现方式中的方法的指令，或者执行第二方面或第二方面的任意可能的实现方式中的方法的指令。

示例性的，在计算机可读存储介质中存储的计算机程序是用于执行第一方面或第一方面的任意可能的实现方式中的方法的指令时，第四方面以及第四方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。故而，第四方面以及第四方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。

示例性的，在计算机可读存储介质中存储的计算机程序是用于执行第二方面或第二方面的任意可能的实现方式中的方法的指令时，第四方面以及第四方面的任意一种实现方式分别与第二方面以及第二方面的任意一种实现方式相对应。故而，第四方面以及第四方面的任意一种实现方式所对应的技术效果可参见上述第二方面以及第二方面的任意一种实现方式所对应的技术效果，此处不再赘述。

第五方面，本申请提供了一种计算机程序，该计算机程序包括用于执行第一方面或第一方面的任意可能的实现方式中的方法的指令，或者执行第二方面或第二方面的任意可能的实现方式中的方法的指令。

示例性的，在计算机程序是用于执行第一方面或第一方面的任意可能的实现方式中的方法的指令时，第五方面以及第五方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第五方面以及第五方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。

示例性的，在计算机程序是用于执行第二方面或第二方面的任意可能的实现方式中的方法的指令时，第五方面以及第五方面的任意一种实现方式分别与第二方面以及第二方面的任意一种实现方式相对应。第五方面以及第五方面的任意一种实现方式所对应的技术效果可参见上述第二方面以及第二方面的任意一种实现方式所对应的技术效果，此处不再赘述。

第六方面，本申请提供了一种芯片，该芯片包括处理电路、收发管脚。其中，该收发管脚、和该处理电路通过内部连接通路互相通信，该处理电路执行第一方面或第一方面的任一种可能的实现方式中的方法，或者第二方面或第二方面的任一种可能的实现方式中的方法，以控制接收管脚接收信号，以控制发送管脚发送信号。

示例性的，在芯片中的处理电路执行第一方面或第一方面的任一种可能的实现方式中的方法时，第六方面以及第六方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。故而，第六方面以及第六方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。

示例性的，在芯片中的处理电路执行第二方面或第二方面的任一种可能的实现方式中的方法时，第六方面以及第六方面的任意一种实现方式分别与第二方面以及第二方面的任意一种实现方式相对应。故而。第六方面以及第六方面的任意一种实现方式所对应的技术效果可参见上述第二方面以及第二方面的任意一种实现方式所对应的技术效果，此处不再赘述。

附图说明

图1为示例性示出的多设备应用接续的场景示意图；

图2为示例性示出的终端设备的硬件结构示意图；

图3为示例性示出的终端设备的软件结构示意图；

图4为示例性示出的超级终端的示意图；

图5至图10为示例性示出的设置多设备应用接续实现的前提条件的用户界面示意图；

图11和图12为示例性示出的触发应用接续请求的用户界面示意图；

图13至图16为示例性示出的响应应用接续请求的用户界面示意图；

图17为示例性示出的开始应用接续后，作为接收端的用户界面示意图；

图18为示例性示出的作为接收端显示接续传输的数据后，作为发送端的用户界面示意图；

图19为示例性示出的在接收到接续传输的数据的设备中进行编辑的用户界面示意图；

图20为示例性示出的再次触发应用接续后，作为接收端的用户界面示意图；

图21为示例性示出的本申请实施例提供的多设备应用接续方法的示意图；

图22为示例性示出的本申请实施例提供的多设备应用接续方法的示意图；

图23为示例性示出的本申请实施例提供的多设备应用接续方法的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。

本申请实施例的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象，而不是用于描述对象的特定顺序。例如，第一目标对象和第二目标对象等是用于区别不同的目标对象，而不是用于描述目标对象的特定顺序。

在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

在本申请实施例的描述中，除非另有说明，“多个”的含义是指两个或两个以上。例如，多个处理单元是指两个或两个以上的处理单元；多个***是指两个或两个以上的***。

为了更好的理解本申请实施例提供的技术方案，在对本申请实施例提供的技术方案说明之前，先对本申请涉及的多设备应用接续场景进行说明。

具体的说，多设备应用接续是发生在近场同账号下的多个设备间接续任务的无缝流转。如图1所示，假设用户在手机A中操作支持接续的应用编辑文档1（文档1的大小为100M），当产生切换设备的需求时，用户只需在要切换到的设备，如电脑B中响应接续请求，即可将手机A中文件大小为100M的文档1，接续传输到电脑B中，这样用户就可以在电脑B中继续编辑文档1，从而能够满足用户在不同场景下，使用不同设备编辑文档1，如在没有电脑B的场景下，使用便于携带的手机A编辑文档1，在有电脑B的场景下，则使用电脑B编辑文档1。

需要说明的是，在实际应用场景中，大多数情况下，多设备应用接续过程中传输的可能为同一内容，即用户只是在不同设备中对该内容进行了部分的新增和修改。但是，目前多设备应用接续过程中，不同设备间的接续传输使用的是全量重写的方式。仍以用户在手机A和电脑B中接续传输的内容为文档1为例，在使用全量重写的方式在手机A和电脑B间进行接续传输时，不论文档1新增的内容或者修改的内容有多少，每次都是全量传输，如在从手机A接续传输到电脑B时，将100M的文档1整个传输给电脑B，当用户使用电脑B删除文档1中2M的内容，将更新后的文档1接续传输给手机A时，会将98M的文件1整个传输给手机A，或者当用户使用电脑B在文档1中新增了5M的内容，将更新后的文档1接续传输给手机A时，会将105M的文件1整个传输给手机A。

由此，基于全量重写的方式进行多设备应用接续传输，对于相同内容的反复接续传输，每次都需要花费大量时间，耗时较长，用户体验较差。

此外，对于多设备应用接续传输的内容为大容量文件的场景，反复全量传输，容易出现传输失败的情况。

有鉴于此，本申请提供了一种多设备应用接续方法，旨在缩短不同设备间反复对同一内容进行应用接续传输的耗时，并保证多设备应用接续传输的成功率。

为了更好的理解本申请实施例提供的技术方案，在对本申请实施例的技术方案说明之前，首先结合附图对本申请实施例的适用于的终端设备的硬件结构进行说明。

关于本申请实施例适用于的终端设备，例如可以是手机、平板电脑、笔记本电脑、台式机、智能手表等，此处不再一一列举，本实施例对此不作限制。为了便于说明，本实施例以为手机为例进行说明。

参见图2，终端设备100可以包括：处理器110，外部存储器接口120，内部存储器121，通用串行总线（universal serial bus，USB）接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块（subscriber identificationmodule，SIM）卡接口195等。

示例性的，在一些实现方式中，传感器模块180可以包括压力传感器，陀螺仪传感器，气压传感器，磁传感器，加速度传感器，距离传感器，接近光传感器，指纹传感器，温度传感器，触摸传感器，环境光传感器，骨传导传感器等，此处不再一一例举，本申请对此不作限制。

此外，需要说明的是，处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器（application processor，AP），调制解调处理器，图形处理器（graphics processing unit，GPU），图像信号处理器（image signal processor，ISP），控制器，存储器，视频编解码器，数字信号处理器（digital signal processor，DSP），基带处理器，和/或神经网络处理器（neural-network processing unit，NPU）等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

可理解的，控制器可以是终端设备100的神经中枢和指挥中心。在实际应用中，控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

此外，还需要说明的是，处理器110中还可以设置存储器，用于存储指令和数据。在一些实现方式中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从所述存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了***的效率。

示例性的，在一些实现方式中，处理器110可以包括一个或多个接口。接口可以包括集成电路（inter-integrated circuit，I2C）接口，集成电路内置音频（inter-integrated circuit sound，I2S）接口，脉冲编码调制（pulse code modulation，PCM）接口，通用异步收发传输器（universal asynchronousreceiver/transmitter，UART）接口，移动产业处理器接口（mobile industry processorinterface，MIPI），通用输入输出（general-purpose input/output，GPIO）接口，用户标识模块（subscriber identitymodule，SIM）接口，和/或通用串行总线（universal serial bus，USB）接口等。

继续参见图2，示例性的，充电管理模块140用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。在一些有线充电的实现方式中，充电管理模块140可以通过USB接口130接收有线充电器的充电输入。在一些无线充电的实现方式中，充电管理模块140可以通过终端设备100的无线充电线圈接收无线充电输入。充电管理模块140为电池142充电的同时，还可以通过电源管理模块141为终端设备供电。

继续参见图2，示例性的，电源管理模块141用于连接电池142，充电管理模块140与处理器110。电源管理模块141接收电池142和/或充电管理模块140的输入，为处理器110，内部存储器121，外部存储器，显示屏194，摄像头193，和无线通信模块160等供电。电源管理模块141还可以用于监测电池容量，电池循环次数，电池健康状态（漏电，阻抗）等参数。在其他一些实现方式中，电源管理模块141也可以设置于处理器110中。在另一些实现方式中，电源管理模块141和充电管理模块140也可以设置于同一个器件中。

继续参见图2，示例性的，终端设备100的无线通信功能可以通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器等实现。

需要说明的是，天线1和天线2用于发射和接收电磁波信号。终端设备100中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实现方式中，天线可以和调谐开关结合使用。

继续参见图2，示例性的，移动通信模块150可以提供应用在终端设备100上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块150可以包括至少一个滤波器，开关，功率放大器，低噪声放大器（low noise amplifier，LNA）等。移动通信模块150可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。移动通信模块150还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。在一些实现方式中，移动通信模块150的至少部分功能模块可以被设置于处理器110中。在一些实现方式中，移动通信模块150的至少部分功能模块可以与处理器110的至少部分模块被设置在同一个器件中。

此外，需要说明的是，调制解调处理器可以包括调制器和解调器。其中，调制器用于将待发送的低频基带信号调制成中高频信号。解调器用于将接收的电磁波信号解调为低频基带信号。随后解调器将解调得到的低频基带信号传送至基带处理器处理。低频基带信号经基带处理器处理后，被传递给应用处理器。应用处理器通过音频设备（不限于扬声器170A，受话器170B等）输出声音信号，或通过显示屏194显示图像或视频。在一些实现方式中，调制解调处理器可以是独立的器件。在另一些实现方式中，调制解调处理器可以独立于处理器110，与移动通信模块150或其他功能模块设置在同一个器件中。

继续参见图2，示例性的，无线通信模块160可以提供应用在终端设备100上的包括无线局域网（wireless local area networks，WLAN）（如无线保真（wireless fidelity，Wi-Fi）网络），蓝牙（bluetooth，BT），全球导航卫星***（global navigation satellitesystem，GNSS），调频（frequency modulation，FM），近距离无线通信技术（near fieldcommunication，NFC），红外技术（infrared，IR）等无线通信的解决方案。无线通信模块160可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块160经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器110。无线通信模块160还可以从处理器110接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。

具体到本申请实施例提供的技术方案中，终端设备100可通过无线通信模块160，具体为WLAN和BT，判断周围是否有满足近场通信条件的其他终端设备。并在确定周围有满足近场通信条件的其他终端设备，且这些终端设备与终端设备100登录的为同一个用户账号时，实现在这些终端设备间的应用接续。

此外，还需要说明的是，终端设备100通过GPU，显示屏194，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏194和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。

继续参见图2，示例性的，显示屏194用于显示图像，视频等。显示屏194包括显示面板。显示面板可以采用液晶显示屏（liquid crystal display，LCD），有机发光二极管（organic light-emitting diode，OLED），有源矩阵有机发光二极体或主动矩阵有机发光二极体（active-matrix organic light emitting diode的，AMOLED），柔性发光二极管（flex light-emitting diode，FLED），Miniled，MicroLed，Micro-oLed，量子点发光二极管（quantum dot light emitting diodes，QLED）等。在一些实现方式中，终端设备100可以包括1个或N个显示屏194，N为大于1的正整数。

此外，还需要说明的是，终端设备100可以通过ISP，摄像头193，视频编解码器，GPU，显示屏194以及应用处理器等实现拍摄功能。

此外，还需要说明的是，ISP 用于处理摄像头193反馈的数据。例如，拍照时，打开快门，光线通过镜头被传递到摄像头感光元件上，光信号转换为电信号，摄像头感光元件将所述电信号传递给ISP处理，转化为肉眼可见的图像。ISP还可以对图像的噪点，亮度，肤色进行算法优化。ISP还可以对拍摄场景的曝光，色温等参数优化。在一些实现方式中，ISP可以设置在摄像头193中。

此外，还需要说明的是，摄像头193用于捕获静态图像或视频。物体通过镜头生成光学图像投射到感光元件。感光元件可以是电荷耦合器件（charge coupled device，CCD）或互补金属氧化物半导体（complementary metal-oxide-semiconductor，CMOS）光电晶体管。感光元件把光信号转换成电信号，之后将电信号传递给ISP转换成数字图像信号。ISP将数字图像信号输出到DSP加工处理。DSP将数字图像信号转换成标准的RGB，YUV等格式的图像信号。在一些实现方式中，终端设备100可以包括1个或N个摄像头193，N为大于1的正整数。

此外，还需要说明的是，数字信号处理器用于处理数字信号，除了可以处理数字图像信号，还可以处理其他数字信号。例如，当终端设备100在频点选择时，数字信号处理器用于对频点能量进行傅里叶变换等。

此外，还需要说明的是，视频编解码器用于对数字视频压缩或解压缩。终端设备100可以支持一种或多种视频编解码器。这样，终端设备100可以播放或录制多种编码格式的视频，例如：动态图像专家组（moving picture experts group，MPEG）1，MPEG2，MPEG3，MPEG4等。

继续参见图2，示例性的，外部存储器接口120可以用于连接外部存储卡，例如Micro SD卡，实现扩展终端设备100的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。

继续参见图2，示例性的，内部存储器121可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器110通过运行存储在内部存储器121的指令，从而执行终端设备100的各种功能应用以及数据处理。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作***，至少一个功能所需的应用程序（比如声音播放功能，图像播放功能等）等。存储数据区可存储终端设备100使用过程中所创建的数据（比如音频数据，电话本等）等。此外，内部存储器121可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器（universal flashstorage，UFS）等。

此外，还需要说明的是，终端设备100可以通过音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，以及应用处理器等实现音频功能。例如音乐播放，录音等。

此外，还需要说明的是，音频模块170用于将数字音频信息转换成模拟音频信号输出，也用于将模拟音频输入转换为数字音频信号。音频模块170还可以用于对音频信号编码和解码。在一些实现方式中，音频模块170可以设置于处理器110中，或将音频模块170的部分功能模块设置于处理器110中。

继续参见图2，示例性的，按键190包括开机键，音量键等。按键190可以是机械按键。也可以是触摸式按键。终端设备100可以接收按键输入，产生与终端设备100的用户设置以及功能控制有关的键信号输入。

继续参见图2，示例性的，马达191可以产生振动提示。马达191可以用于来电振动提示，也可以用于触摸振动反馈。例如，作用于不同应用（例如拍照，音频播放等）的触摸操作，可以对应不同的振动反馈效果。作用于显示屏194不同区域的触摸操作，马达191也可对应不同的振动反馈效果。不同的应用场景（例如：时间提醒，接收信息，闹钟，游戏等）也可以对应不同的振动反馈效果。触摸振动反馈效果还可以支持自定义。

继续参见图2，示例性的，指示器192可以是指示灯，可以用于指示充电状态，电量变化，也可以用于指示消息，未接来电，通知等。

关于终端设备100的硬件结构就介绍到此，应当理解的是，图2所示终端设备100仅是一个范例，在具体实现中，终端设备100可以具有比图中所示的更多的或者更少的部件，可以组合两个或多个的部件，或者可以具有不同的部件配置。图2中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。

此外，需要说明的是，上述终端设备100，在实际应用中可以是发起多设备应用接续请求的终端设备，即文件的发送端，也可以是响应多设备应用接续请求的终端设备，即文件的接收端。

为了更好的理解图2所示终端设备100的软件结构，以下对终端设备100的软件结构进行说明。在对终端设备100的软件结构进行说明之前，首先对终端设备100的软件***可以采用的架构进行说明。

具体的，在实际应用中，终端设备100的软件***可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。

此外，可理解的，目前主流的终端设备使用的软件***包括但不限于Windows***、Android***和iOS***。为了便于说明，本申请实施例以分层架构的Android***为例，示例性说明终端设备100的软件结构。

此外，后续关于本申请实施例提供的多设备应用接续方案，在具体实现中同样适用于其他***。

参见图3，为本申请实施例的终端设备100的软件结构框图。

如图3所示，终端设备100的分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实现方式中，将Android***分为四层，从上至下分别为应用程序层，应用程序框架层，安卓运行时（Android runtime）和***库，以及内核层。

其中，应用程序层可以包括一系列应用程序包。如图3所示，应用程序包可以包括备忘录、WLAN、蓝牙、设置等应用程序，此处不再一一列举，本申请对此不作限制。

可理解的，图3中示出的备忘录应用可为预先注册到多设备应用接续服务器的应用，即在本实施例中，备忘录应用为支持文件接续传输的接续应用。

此外，通过上述硬件结构的描述可知，多设备应用接续实现的一个条件为，登录同一用户账号的多个设备，满足近场通信条件。而在本实施例中，近场通信条件，例如为开启了WLAN和蓝牙。

进一步地，在具体作业中，能够直接进行应用接续的前提，需要满足近场通信条件的多个设备，接入了同一个WLAN，且建立了蓝牙配对。

此外，关于图3中示出的设置，在本实施例中，具体用于提供开启应用接续的入口，以便用户通过设置应用开启应用接续功能。

可理解的，对于应用接续功能的开启，在一些实现方式中，也可以单独提供对应的应用供用户开启该功能。

继续参见图3，示例性的，图3中示出的应用程序框架层为应用程序层的应用程序提供应用编程接口（application programminginterface，API）和编程框架。在一些实现方式中，这些编程接口和编程框架可以描述为函数。如图3所示，应用程序框架层可以包括通知管理器、内容提供器、窗口管理器、资源管理器、多设备应用接续模块等函数，此处不再一一列举，本申请对此不作限制。

其中，多设备应用接续模块具体用于在用户开启多设备应用接续功能后，检测当前是否满足近场通信条件，且满足近场通信条件的设备是否都登录了同一个用户账号。

此外，多设备应用接续模块还用于在确定满足发起应用解析请求时，确定本次接续传输的文件究竟采用哪种传输方式，如是全量传输的传输方式，还是差量传输的方式，进而根据确定的传输方式对文件进行接续传输。

关于多设备应用接续模块处理的操作，以及具体处理细节，详见下文对多设备应用接续方法的描述。

通知管理器使应用程序可以在状态栏中显示通知信息，可以用于传达告知类型的消息，可以短暂停留后自动消失，无需用户交互。

内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。所述数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等，此处不再一一列举，本申请对此不作限制。

窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等。

资源管理器为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等，此处不再一一列举，本申请对此不作限制。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

此外，可以理解的，上述各功能模块的划分，仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。在实际应用中，上述功能也可以集成在一个功能模块中实现，本实施例对此不作限制。

继续参见图3，示例性的，对于***库和安卓运行时，其中安装运行时（AndroidRuntime）包括核心库和虚拟机。Android Runtime负责安卓***的调度和管理。

具体的，核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。

此外，可理解的，应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。

继续参见图3，示例性的，对于***库和安卓运行时，其中***库可以包括多个功能模块。例如：表面管理器（surface manager），媒体库（Media Libraries），三维（3D）图形处理库（例如：OpenGL ES），二维（2D）图形引擎（例如：SGL）等。

具体的，表面管理器用于对显示子***进行管理，并且为多个应用程序提供了2D和3D图层的融合。

媒体库支持多种常用的音频，视频格式回放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如：MPEG4，H.264，MP3，AAC，AMR，JPG，PNG等。

三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。

可理解的，上述所说的2D图形引擎是2D绘图的绘图引擎。

此外，可理解的，Android***中的内核层是硬件和软件之间的层。内核层至少包含显示驱动，蓝牙驱动，WIFI驱动等。示例性的，WIFI驱动用于驱动WIFI芯片，使终端设备接入WLAN网络，蓝牙驱动用于驱动蓝牙芯片搜索周围可配对的终端设备，并与满足近场通信条件的终端设备配对连接，以便后续在开启多设备应用接续功能的情况下，可以实现多设备应用接续。

关于终端设备100的软件结构就介绍到此，可以理解的是，图3示出的软件结构中的层以及各层中包含的部件，并不构成对终端设备100的具体限定。在本申请另一些实施例中，终端设备100可以包括比图示更多或更少的层，以及每个层中可以包括更多或更少的部件，本申请不做限定。

针对上述场景，基于图2和图3描述的终端设备的硬件结构和软件结构，以下对实现本申请实施例提供的多设备应用接续方法进行具体说明。

参见图4，示例性示出了蓝牙能够搜索到的范围内，登录了同一用户账号，且接入同一WLAN的多个终端设备，如设备10、设备20和设备30构成的超级终端。

需要说明的是，本实施例中所说的超级终端，具体是指组成超级终端的任意两个终端设备之间可以实现无缝协同作业。

示例性的，关于超级终端支持的无缝协同作业的场景，例如可以包括通话共享、通知共享、键鼠共享，以及上述所说的应用接续等。具体到本申请提供的实施例中，想要实现多设备应用接续，前提需要保证终端设备开启了超级终端功能中提供的应用接续功能。

关于开启超级终端功能和应用接续功能的方式，以图4中组成超级终端的设备10为例，结合图5至图10进行说明。

参见图5中（1），示例性示出设备10的一个界面（后续称为主界面）。示例性的，在主界面中可以包括一个或多个控件。控件包括但不限于：网络控件、电量控件、应用图标控件等。

继续参见图5中（1）所示的主界面，示例性的，应用图标控件包括但不限于：时钟应用图标控件、日历应用图标控件、图库应用图标控件、备忘录应用图标控件、文件管理应用图标控件、电子邮件应用图标控件、音乐应用图标控件、计算器应用图标控件、天气应用图标控件、浏览器应用图标控件、设置应用图标控件等，此处不再一一列举，本申请对此不作限制。

继续参见图5中（1）所示的主界面，示例性的，当用户点击了设置应用图标控件后，设备10响应于用户的操作，启动图5中（2）所示的设置界面。

参见图5中（2）所示的设置界面，示例性的，设置界面中可以包括一个或多个控件。控件包括但不限于：用于退出设置界面的控件、用于进入账号中心界面的控件10a-1、用于进入超级终端界面的控件10a-2、用于进入WLAN界面的控件10a-3、用于进入蓝牙界面的控件10a-4、用于进入智慧多窗界面的控件10a-5、用于进入显示和亮度界面的控件、用于进入声音和振动界面的控件、用于进入通知界面的控件、用于进入电池界面的控件、用于进入存储界面的控件、用于进入安全界面的控件等，此处不再一一列举，本申请对此不作限制。

可理解的，用户在设置界面中通过对各控件做出操作，以使设备10响应于用户的操作行为，从设置界面跳转到操作的控件对应的界面，以便用户在跳转到的界面进行相应的设置，如在显示和亮度界面设置设备10的屏幕亮度、文字大小、自动锁定时间、抬起唤醒功能等，此处不再一一列举，本申请对此不作限制。

继续参见图5中（2）所示的设置界面，示例性的，当用户点击了控件10a-1后，设备10响应于用户的操作，启动图6中所示的账号中心界面。

参见图6中所示的账号中心界面，示例性的，账号中心界面中可以包括一个或多个控件。控件包括但不限于：用于退出账号中心界面返回设置界面的控件、用于设置与用户账号相关信息的各种控件，如个人信息控件、账号与安全控件、登录设备管理控件、数据同步控件、查找设备控件、会员中心控件、隐私中心控件，以及用于退出当前登录的用户账号的退出账号控件等，此处不再一一列举，本申请对此不作限制。

继续参见图6，示例性示出设备10当前登录的用户账号为“张三123”。基于上述对图4所示组成超级终端的描述可知，设备10、设备20和设备30想要组成图4所示的超级终端，在设备10登录的用户账号为“张三123”的情况下，设备20和设备30也需要登录“张三123”这一用户账号。关于设备20和设备30登录用户账号的方式，与设备10类似，通过操作对应的控件启动登录用户账号的界面，在该界面中输入“张三123”，以及“张三123”这一用户账号对应的密码，然后进行登录即可，具体实现细节，此处不再赘述，本申请也不作限制。

由此，设备10、设备20和设备30通过登录相同的用户账号，如“张三123”，完成了组成超级终端的一个必要条件。

示例性的，在将设备10、设备20和设备30均登录“张三123”这一用户账号后，可以依次操作这三个终端设备，开启应用接续功能。关于应用接续功能的启动入口具体是从超级终端界面进入的，为了便于说明，以下仍以设备10为例，对开启应用接续功能的方式进行说明。

参见图7中（1），示例性的，当用户点击了控件10a-2后，设备10响应于用户的操作，启动图7中（2）所示的超级终端界面。

参见图7中（2）所示的超级终端界面，示例性的，超级终端界面中可以包括一个或多个控件。控件包括但不限于：用于从超级终端界面退回到设置界面的控件、用于进入应用接续界面的控件10b-1、用于进入通话共享界面的控件、用于进入通知共享界面的控件、用于进入键鼠共享界面的控件等，此处不再一一列举，本申请对此不作限制。

继续参见图7中（2）所示的超级终端界面，示例性的，当用户点击了控件10b-1后，设备响应于用户的操作，启动图8中（1）或图8中（2）所示的应用接续界面。

需要说明的是，支持超级终端功能的设备，超级终端支持的应用接续、通话共享、通知共享、键鼠共享等功能通常默认是开启的。即，在超级终端界面点击对应功能的控件，进入对应界面后，该界面中的开关控件是处于开启状态，如图8中（1）示出的控件10c-1。

示例性的，在实际应用中，用户可能手动关闭了超级终端支持的某个功能，如将应用接续功能关闭。对应这种情况，当用户点击了控件10b-1后，设备响应于用户的操作，启动的应用接续界面会如图8中（2）所示，即控件10c-1处于关闭状态。对于这种情况，用户想要使设备10、设备20和设备30实现应用接续，则需要通过上述操作进入管理应用接续功能的应用接续界面，通过操作控件10c-1，开启应用接续功能，即将控件10c-1从图8中（2）所示状态切换为图8中（1）所示状态。

关于设备20和设备3开启应用接续功能的方式，与设备10类似，通过操作对应的控件启动应用接续的界面，在该界面中通过操作类似控件10c-1的控件，开启应用接续功能，具体实现细节，此处不再赘述，本申请也不作限制。

由此，设置支持超级终端功能的设备10、设备20和设备30均开启应用接续功能，完成了实现本申请实施例提供的多设备应用接续方法的一个必要条件。

此外，需要说明的是，通过上述对图4中组成超级终端的描述可知，设备10、设备20和设备30实现无缝协同作业，例如应用接续，不仅需要它们开启了应用接续功能，还需要满足近场通信条件。而在多设备应用接续场景中，要求进行应用接续的终端设备需要同时开启蓝牙功能和WLAN功能。

基于此，在设备20和设备30没有开启蓝牙功能和WLAN功能时，可以在超级终端界面提示用户当前没有搜索到可协同的设备的原因。以设备10为例，在设备10登录的用户账号为“张三123”时，如果没有搜索到可以协同作业的设备20和设备30，那么可能的原因可能是设备20和设备30没有登录用户账号“张三123”，或者设备20和设备30没有开启WLAN和蓝牙功能，如图9中（1）所示。

示例性的，对于没有搜索到可协同的设备的情况，用户可以根据超级终端界面中给出的提示，分别前往设备20和设备30的账号中心确定这2个设备登录的用户账号是否为“张三123”，并在用户账号不是“张三123”时通过上述类似图6中示出账号中心界面中的退出账号控件，退出设备20和设备30当前登录的用户账号，重新登录“张三123”这一用户账号，从而解决图9中（1）给出的第一个原因。

示例性的，如果解决图9中（1）给出的第一个原因，即保证设备10、设备20和设备30登录的用户账号均为“张三123”后，设备10的超级终端界面中依旧没有显示可协同作业的设备20和设备30。可以进一步查看设备10、设备20和设备30的蓝牙和WLAN是否均开启。

示例性的，仍以设备10为例，关于蓝牙和WLAN的开启，在一些实现方式中可以如图10中（1）所示，通过从设备10的显示界面的上边缘沿箭头方向下行滑动，设备10响应于该操作行为，在显示界面的上边缘区域显示下拉通知栏，如图10中（2）所示。

参见图10中（2），示例性的，在显示下拉通知栏后，用户可以直接点击下拉通知栏中的WLAN控件和蓝牙控件，一键开启WLAN功能和蓝牙功能。

可理解的，如果设备20和设备30之前与设备10分别两两蓝牙佩戴过，并且接入过设备10当前接入的WIFI，则在开启WLAN功能和蓝牙功能后，设备20和设备30会自动接入设备10当前接入的WIFI，并相互蓝牙连接，以及与设备10进行蓝牙连接。

此外，可以理解的，在另一些实现方式中，WLAN的开启，也可以通过操作设置界面中进入WLAN界面的控件10a-3，进而进入WLAN界面，在该界面中操作对应的控件开启WLAN，以及选择合适的WIFI接入，具体实现细节此处不再赘述，本申请也不作限制。

相应地，蓝牙的开启，也可以通过操作设置界面中进入蓝牙界面的控件10a-4，进而进入蓝牙界面，在该界面中操作对应的控件开启蓝牙，以及选择合适的设备完成蓝牙佩戴，具体实现细节此处不再赘述，本申请也不作限制。

由此，在通过上述任意一种方式开启设备10、设备20和设备30的WLAN和蓝牙，这3个设备会分别搜索到对方作为协同作业的设备。仍以设备10为例，在设备10的超级终端界面，会显示搜索到的可协同的设备为设备20和设备30，如图9中（2）所示。

关于设备20和设备3开启蓝牙和WLAN的方式，与设备10类似，通过操作对应的控件启动蓝牙界面和WLAN界面，在该界面中通过操作对应的控件，使得设备20和设备30开启蓝牙，接入对应的WLAN，或者通过下拉通知栏，直接点击开启WLAN和蓝牙的控件，具体实现细节，此处不再赘述，本申请也不作限制。

由此，设置开启应用接续功能的设备10、设备20和设备30均开启蓝牙和WLAN，完成了实现本申请实施例提供的多设备应用接续方法的另一个必要条件。

应当理解的是，上述说明仅是为了更好的理解实现本实施例的技术方案前应该具备的前提而列举的示例，不作为对本实施例的唯一限制。

此外，还需要说明的是，为了实现本申请实施例提供的多设备应用接续方法，另一个必要条件是需要预先将支持应用接续的应用注册到对应的服务器。具体的，这一前提条件可以是由应用的开发者通过对应的注册平台，将支持应用接续的应用，如备忘录应用、各种音视频类应用、可以查看文件的应用等注册到对应的服务器。这样，后续在组成超级终端后，用户在其中一个终端设备（发送端）使用注册为接续应用的应用时，超级终端中的其他终端设备便会接收到该终端设备发起的应用接续请求，当用户在对应终端设备（接收端）做出响应时，便可以将在发送端中该应用中查看、编辑的文件接续到接收端中相同的应用中进行显示，使得用户能够在接收端中对该文件进行编辑。

此外，对于不同的接续应用，其可以接续传输的文件不同。因此，在注册继续应用时，可以将该应用能够查看、编辑的文件类型进行注册绑定，如对于WPS这一办公软件，其可以与PDF格式、word格式、PPT格式、Excel格式等多种格式的文件进行注册绑定。后续在进行应用接续时，当接续传输的文件为一个word文件时，通过判断确定其是与WPS这一办公软件注册绑定的文件格式时，在接收端可以直接启动WPS这一办公软件，并在该软件中加载发送端传输的word文件进行显示。

应当理解的是，上述说明仅是为了更好的理解实现本实施例的技术方案前应该具备的前提而列举的示例，不作为对本实施例的唯一限制。

基于上述前提，以用户在图4中示出的设备10中，操作备忘录这一应用时，通过备忘录编辑的笔记无缝协同到组成超级终端的设备20和设备30这一场景为例，结合附图进行具体说明。

参见图11中（1），示例性的，当用户在设备10的主界面点击备忘录应用控件后，设备10响应于该操作行为，启动备忘录应用，设备10的界面会从图11中（1）所示的主界面，切换为图11中（2）所示的显示全部笔记的备忘录界面。

参见图11中（2），示例性的，如果用户需要创建一个新的笔记，可以点击该界面中的控件10d-1，这样设备10响应于该操作行为，会创建一个新的笔记，将界面切换到图12中（1）所示的笔记界面。

参见图12中（1），示例性的，在笔记界面中包括一个或多个控件。这些控件包括但不限于：用于回退到全部笔记界面的控件、用于保存当前笔记内容的控件10d-2、用于编辑笔记标题的控件10d-3、用于编辑笔记的数据内容的控件10d-4等，此处不再一一列举，本申请对此不作限制。

示例性的，如果用户在图12中（1）所示的笔记界面，点击控件10d-3，将光标停留在控件10d-3后，通过编辑将当前笔记命名为“笔记3”，点击控件10d-4，将光标停留在控件10d-4后，通过编辑输入了“aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.”，图12中（1）示出的笔记界面会更新为图12中（2）所示的笔记界面，同时在编辑内容的时候会在笔记界面中显示控件10d-5，并在控件10d-5中显示笔记名称为“笔记3”的创建时间，如图12中（2）示出的“2023年2月6日 16：13”。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

此外，需要说明的是，在实际作业中，后续如果对笔记3进行了编辑，如新增或删除了某些内容，控件10d-5中显示的时间将随之更新为笔记3的最新更新时间。

继续参见图4，由于设备10、设备20和设备30是基于上述登录相同用户账号，开启WLAN和蓝牙的方式，组成的超级终端，因此在这3个终端设备都开启了应用接续功能的情况下，当用户在设备10的备忘录应用中进行笔记3的编辑时，在超级终端中的设备20和设备30均安装了相同的备忘录应用的情况下，笔记3的内容会同步到设备20和设备30的备忘录中，从而实现超级终端中各设备之间的无缝协同作业。

为了便于说明，本实施例以与设备10进行应用接续的终端设备为设备20为例，基于本实施例提供的多设备应用接续方法，对设备10和设备20实现备忘录接续的过程进行具体说明。

具体的说，当用户在设备10中使用备忘录应用编辑笔记3的过程中，设备10会向设备20发起针对备忘录应用的应用接续请求。可理解的，实际作业中设备10会向组成超级终端的每一个终端设备发起该应用接续请求。

相应地，设备20会接收到设备10发送的针对备忘录应用的应用接续请求，并做出响应。

示例性的，在一些实现方式中，对于设备20中没有安装备忘录应用的情况，设备20响应于设备10发送的针对备忘录应用的应用接续请求，可以直接在界面中弹窗提示用户下载安装备忘录应用，如图13中所示。

参见图13，示例性的，该提示窗口中可以提供用于同意下载安装备忘录应用的控件20a-1，以及用于拒绝下载安装备忘录应用的控件20a-2。

示例性的，在一些实现方式中，当用户点击控件20a-1后，可以直接启动设备20中安装的用于下载应用的应用市场，在该应用市场中自动下载备忘录应用，并在下载完成后进行安装。

示例性的，在另一些实现方式中，当用户点击控件20a-1后，设备20也可以从设备10中获取备忘录应用的下载地址，然后根据下载地址在浏览器中下载备忘录应用，并在下载完成后进行安装。

此外，需要说明的是，当用户根据提示安装备忘录应用后，在一些实现方式中，可以直接进行触发应用接续，即启动安装的备忘录应用。关于启动备忘录应用后进行的操作可以参见下文点击携带了小图标20b-1的备忘录应用后的描述，此处不再赘述。

示例性的，在另一种实现方式中，当用户根据提示安装备忘录应用后，也可以不自动触发应用接续，即是否选择与设备10进行接续，由用户自己决定。对于这种情况，在安装备忘录应用后，备忘录应用图标上可以显示如下文所说的小图标20b-1。具体实现细节可以参见下文，此处不再赘述。

示例性的，当用户点击控件20a-2后，取消显示在设备20界面中的提示窗口。

此外，为了不影响用户对设备20的正常使用，还可以在设定时间，比如10s内没有接收到用户对控件20a-1的操作时，设置提示窗口自动从设备20的界面消失。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

示例性的，在另一些实现方式中，对于设备20中安装了备忘录应用的情况，设备20响应于设备10发送的针对备忘录应用的应用接续请求，会在备忘录应用图标上显示一个小图标，如图14中的20b-1。

需要说明的是，在实际应用中，为了更好的提醒用户当前可以操作设备20中的备忘录进行应用接续，小图标20b-1可以为闪缩状态，即在用户通过设备10中的备忘录应用编辑笔记的过程中，设备20中备忘录应用图标上的小图标20b-1可以一直闪缩。可理解的组成超级终端的其他终端设备，如设备30在安装了备忘录应用的情况下，也会在备忘录应用图标上显示类似图14中所示小图标20b-1；反之如果设备30没有安装备忘录应用，则会弹出类似图13所示的提示窗口。

示例性的，在另一些实现方式中，对于设备20中安装了备忘录应用的情况，设备20响应于设备10发送的针对备忘录应用的应用接续请求，同样可以在备忘录应用图标上显示一个小图标，依旧如图14中的20b-1。但是，对于用户当前处于其他操作界面，即不处于图14示出的主界面的情况下，为了便于用户快速启动设备20中的备忘录应用，可以通过设置界面中用于进入智慧多窗界面的控件10a-5，开启智慧多窗功能。

示例性的，在一些实现方式中，在开启智慧多窗功能后，当用户在设备20中如图15中（1）所示的视频播放界面观看视频时，从设备20的显示屏的右边缘沿箭头方向滑动，设备20响应于该操作行为，会拉出如图15中（2）所示的侧边栏20b-2。

需要说明的是，如果用户在开启智慧多窗功能后，在侧边栏20b-2中通过拖拽的方式添加了部分应用，则在侧边栏20b-2中会显示添加的应用对应的图标，如图15中（2）为添加了备忘录应用、电子邮件应用和图库应用到侧边栏中。

此外，还需要说明的是，关于在侧边栏中添加应用的方式，还可以是通过在智慧多窗界面中选择设备20安装的应用作为要添加到侧边栏的应用。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

继续参见图15中（2），示例性的，在拉出的侧边栏20b-1中显示了备忘录应用图标时，备忘录应用图标上便会显示小图标20b-1，以提示用户当前触发备忘录应用可以实现与其他终端设备，如设备10之间的针对备忘录应用中当前编辑笔记的接续。

示例性的，在另一些实现方式中，对于设备20中安装了备忘录应用的情况，设备20响应于设备10发送的针对备忘录应用的应用接续请求，同样可以在备忘录应用图标上显示一个小图标，依旧如图14中的20b-1。但是，对于用户当前处于其他操作界面，即不处于图14示出的主界面的情况下，为了便于用户快速启动设备20中的备忘录应用，也可以直接在当前界面显示可由用户操作的悬浮球控件，如图16中示出的控件20b-3。

应当理解的是，上述各种针对应用接续请求做出的响应方式，仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

以图14示出的场景为例，示例性的，当用户点击显示了小图标20b-1的备忘录应用图标后，设备20响应于该操作行为，会做出针对备忘录应用的应用接续请求的响应，该响应会基于近场通信技术，即配对建立的蓝牙通道和/或通过无线网络，反馈给设备10。此时设备10中的多设备应用接续模块会根据本实施例提供的多设备应用接续方法，进行如下操作：首先，确定笔记3是否是首次进行传输。由于笔记3为首次传输，设备20中不存在与笔记3相关的任何数据。这种情况下，基于本实施例提供的多设备应用接续方法，设备10会以全量传输方式，将与笔记3相关的全部内容传输给设备10，而设备10则会启动其上安装的备忘录应用，进入笔记3对应的笔记界面。

可理解的，在实际应用中，如果设备10传输的数据内容较多，设备20的笔记界面可能无法立马加载出设备10传输的数据内容，因此在设备20的笔记界面可以显示如图17中（1）示出的加载提示框20c-1，以提示用户当前正在加载笔记内容。

示例性的，在数据加载成功后，设备20的笔记界面会从图17中（1）所示更新为图17中（2）所示，即显示与图12中（2）示出的设备10中笔记界面相同的笔记内容，由此实现了设备10和设备20使用备忘录应用编辑笔记3的无缝协同。

示例性的，在一些实现方式中，当笔记3从设备10被无缝接续到设备20后，设备10可以自动保存笔记3，并退回到全部笔记的界面，此时设备10中全部笔记的界面可如图18所示。

示例性的，在另一些实现方式中，当笔记3从设备10被无缝接续到设备20后，设备10可以继续停留在笔记3的界面，即图12中（2）示出的界面，与设备20保持同步，即用户在设备20的笔记界面编辑笔记3的内容时，设备10中笔记3的内容同步更新。可理解的，对于这种场景，设备20作为了发送端，设备10作为了接收端，即用户在设备20对笔记3进行编辑的过程中，设备20会将更新的笔记3，根据本实施例提供的多设备应用接续方法，将更新后的差量内容传输给设备10，由于只传输差量内容，因此速度较快，设备10可以实现与设备20的同步显示，用户体验较佳。

为了便于说明，本实施例以用户将设备10中备忘录应用编辑的笔记3接续到设备20后，退出了备忘录应用为例。对于这种使用场景，用户在使用设备20对笔记进行编辑，如在原有笔记内容后，新增了如图19所示的“bbbb.”的过程中，设备20切换为了应用接续的发起端，此时设备20会向超级终端内的各终端设备发起针对备忘录应用的应用接续请求。

以用户使用设备10与设备10进行多设备应用接续为例，在设备20发起针对备忘录应用的应用接续请求后，设备10的备忘录应用图标上同样会显示用于提示用户当前备忘录应用可以进行应用接续的小图标，如图20中（1）示出的小图标10b-1。

参见图20中（1），示例性的，当用户点击主界面中的备忘录应用图标后，设备10响应于该操作行为，会做出针对备忘录应用的应用接续请求的响应，该响应会基于近场通信技术，即配对建立的蓝牙通道和/或通过无线网络，反馈给设备20。此时设备20中的多设备应用接续模块会根据本实施例提供的多设备应用接续方法，进行如下操作：首先，确定笔记3是否是首次进行传输。由于笔记3为非首次传输，这种情况下会进一步判断笔记3的内容是否存在更新，如新增了内容或上传了内容。以图19示出的笔记3的内容为例，可以确定笔记3相较于上次传输新增了“bbbb.”。这种情况下，基于本实施例提供的多设备应用接续方法，设备20会以差量传输方式，仅将更新的部分，如“bbbb.”，以及该内容的更新时间，位置等传输给设备10，而设备10则会启动其上安装的备忘录应用，进入笔记3对应的笔记界面。

此外，可以理解的，由于设备20本次是以差量传输的方式进行的数据传输，笔记3的其他内容在设备10中存在，而传输的更新内容较小，因此传输速度较快，故而设备10启动其上安装的备忘录应用，进入笔记3对应的笔记界面后，可以直接加载出笔记3最新的内容，即可以直接从图20中（1）所示的界面切换为图20中（2）所示的笔记3对应的笔记界面，用户感知不到数据加载的过程，大大提高了用户体验。

此外，即便差量传输的数据较大，相较于现有直接全量传输的方式，加载数据的耗时也更短，用户等待也较短。

此外，还需要说明的，基于本实施例提供的多设备应用传输方法，作为发送端的终端设备中的多设备应用接续模块确定当前需要传输的数据不存在更新时，发送端可以不传输笔记3的数据内容，这样作为接收端的终端设备，在启动备忘录应用后，直接从本地加载笔记3的内容即可。

应当理解的是，上述场景说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。为了更好的理解本申请提供的多设备应用接续方法，以下结合图21至图23示出的实现流程进行说明。

参见图21，示例性示出应用于第一设备，即作为应用接续请求发起方，负责发送要接续的数据的终端设备（也可以称为：发送端），实现本实施例提供的多设备应用接续方法的流程。如图21所示，应用于第一设备的多设备应用接续方法，具体包括：

S101，在使用注册为接续应用的第一应用编辑第一文件的过程中，向第二设备发送针对第一应用的应用接续请求。

关于将第一应用注册为接续应用的具体细节，可以参见上述实施例的描述，此处不再赘述。

示例性的，第一设备例如为上述实施例中的设备10，第一应用例如为上述实施例中的备忘录应用，第一文件例如为上述实施例中的笔记3，则第一设备使用注册为接续应用的第一应用编辑第一文件的过程中，向第二设备发送针对第一应用的应用接续请求的实现细节，可以具体参见上述实施例的描述，此处不再赘述。

此外，需要说明的是，由于本实施例提供的技术方案是针对多设备应用接续的，在第设备为例如为上述实施例中的设备10时，第二设备例如可以是上述实施例中与设备10组成超级终端的设备20、设备30。

基于上述针对超级终端，以及实现多设备应用接续前提的描述，在向第二设备发送针对第一应用的应用接续请求前，需要确保第一设备和第二设备开启了应用接续功能、蓝牙功能和无线局域网（WLAN）功能（WIFI）。

关于开启应用接续功能，设置第一设备和第二设备开启蓝牙功能和WLAN功能的描述可以参见上述实施例，此处不再赘述。

S102，在第一文件为非首次进行接续传输时，在接收到第二设备针对应用接续请求做出的应用接续响应后，采用差量传输方式，将第一文件中的差量数据传输至第二设备。

具体的说，在本实施例中关于第一文件是否是首次进行接续传输，还是非首次进行接续传输的确定，具体是通过检测本地是否存在与第一文件对应的文件数据信息表。

相应地，在检测到本地存在与第一文件对应的文件数据信息表时，确定第一文件为非首次进行接续传输。反之，在检测到本地不存在与第一文件对应的文件数据信息表时，确定第一文件为首次进行接续传输。

关于上述所说的第一文件对应的文件数据信息表具体携带了用于标识第一文件唯一性的标识信息，第一文件的文件公共基础信息，携带第一文件中数据内容的数据原子集合，以及基于数据原子集合中数据生成的描述文件特征的文件数据特征码。在进行多设备应用接续时，当第二设备做出应用接续响应后，便可以基于这些信息，启动安装在第二设备上的第一应用，并加载第一文件。

通过上述描述可知，在确定第一文件为首次进行接续传输之后，可以确定第一设备中不存在与第一文件对应的文件数据信息表，而第二设备与第一设备进行应用接续需要基于文件数据信息表，因此在确定第一文件为首次进行接续传输之后，第一设备需要先构建第一文件对应的文件数据信息表。

由于第一文件与第一应用存在关系，第二设备在响应应用接续请求后，要先根据文件数据信息表确定需要拉起的应用，然后才能加载正确的文件。因此，第一文件对应的文件数据信息表，需要根据第一应用和第一文件的相关信息进行构建。

例如，根据第一应用和第一文件，生成用于指示了第一文件和第一应用的关系文件唯一标识。

还例如，根据第一文件的文件名、路径、文件权限、创建及更新时间、哈希值等信息生成文件基础公共信息，以及根据第一文件中实际的文件内容生成数据原子集合，即数据原子集合携带了第一文件的全部数据。

还例如，根据数据原子集合中的数据，生成用于标识第一文件中的数据的文件数据特征码。

最后，根据文件唯一标识、文件基础公共信息、数据原子集合和文件数据特征码，便可以生成文件数据信息表。

为了更好的理解文件数据信息表，以下给出一种包括文件唯一标识，文件公共基础信息，数据原子集合和文件数据特征码的文件数据信息表的具体形式。

file：文件数据信息表

{

"id"："文件唯一主键id"，

"uuid"："文件唯一标识"，

"note_file_base"："文件基础公共信息"

{

"id"："文件基础公共信息主键id"，

"file_name"："文件唯一名称"，

"file_path"："文件路径"，

"file_size"："文件大小"，

"auth_mode"："文件读写权限"，

"create_time"："文件创建时间"，

"update_time"："文件最后更新时间"，

"file_md5"："文件md5值"

}，

"Atomic_dataset"："数据原子集合，控制文件数据流的操作"

{

"id"："主键id"，

"file_header"："文件流头文件"，

"byte_code"："字节码，二进制文件"，

"FileStream"："创建文件流并控制文件数据流的操作"，

"read_file"："读取文件中的数据"，

"write_file"："将文件字节数据写入文件流中"，

"byte_file"："文件数据内容"

}，

"attribute_code"："文件数据特征码，对应文件数据流的一串二进制串"

}

其中，文件唯一标识，是由当前终端设备产品序列号和时间戳生成的散列函数值，例如采用md5方法，生成的32位序列，具有唯一性。

数据原子集合中记录的是基于待传输的文件，如上述所说的第一文件的哈希值获得的上述各个字段对应的内容。基于数据原子集合可以完成控制文件数据流的一系列操作。

需要说明的是，在待传输文件，如第一文件是首次接续时，数据原子集合中是以全量传输方式从第一文件中截取的第一文件的全部数据的集合，即数据原子集合中携带的第一文件的全部数据。

相应地，在待传输文件，如第一文件是非首次接续时，数据原子集合中是以差量传输方式从第一文件中截取的差量数据的集合，即对于非首次接续的第一文件，采用差量传输方式传输的差量数据，实际是记录了差量数据的原子数据集合。

文件数据特征码，是通过扫描整个文件内容，即“byte_file”字段中全部的数据，然后文件基础公共信息中“file_name”字段对应的文件唯一名称、“file_path”字段对应的文件路径，以及“update_time”字段对应的文件最后更新时间等信息，使用设定的算法，如安全散列算法1（Secure Hash Algorithm 1，SHA1），进行散列计算，进而得到一个散列函数值，最终将该散列函数值作为文件数据特征码即可。。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

相应地，在构建好第一文件对应的文件数据信息表后，第一设备在接收到第二设备针对应用接续请求做出的应用接续响应后，便可以采用全量传输方式，将文件数据信息表传输至第二设备。

此外，可理解的，由于第一文件为非首次进行接续传输时，用户可能在第一设备中对第一文件进行了编辑，也可能没有，因此第一设备在采用差量传输方式，将第一文件中的差量数据传输至第二设备之前，可以先判断当前要进行接续传输的第一文件的内容和之前传输给第二设备的第一文件的内容是否存在差异。当存在差异时，再采用差量传输方式，将第一文件中的差量数据传输至第二设备。

关于判断当前要进行接续传输的第一文件的内容和之前传输给第二设备的第一文件的内容是否存在差异的方式，可以如下所述：

（1）对第一文件进行随机扫描，生成临时数据原子集合。

即，扫描第一文件中的数据内容，如上述实施例中笔记3对应的界面中控件10d-3中的数据内容，以及控件10d-3中的文件名称，以及控件10d-5中的时间信息等，即将与第一文件相关的数据进行扫描，进而生成一个临时备用的数据原子集合，即临时数据原子集合。

关于临时数据原子集合中包括的字段与上述描述的首次生成第一文件对应的文件数据信息表时，生成的数据原子集合中的相同，此处不再赘述。

（2）根据临时数据原子集合中的数据，生成临时文件数据特征码。

示例性的，在一些实现方式中，可以根据文件数据信息表中记录的文件数据特征码的生成方式，截取临时数据原子集合中“byte_file”字段中相同位置和相同长度的数据，然后结合文件基础公共信息中“file_name”字段对应的文件唯一名称、“file_path”字段对应的文件路径，以及“update_time”字段对应的文件最后更新时间等信息，使用相同的算法，如安全散列算法1（Secure Hash Algorithm 1，SHA1），生成一个散列函数值，将该散列函数值作为临时文件数据特征码即可。

示例性的，在另一些实现方式中，也可以根据文件数据信息表中记录的文件数据特征码的生成方式，截取“byte_file”字段中全部的数据，然后结合文件基础公共信息中“file_name”字段对应的文件唯一名称、“file_path”字段对应的文件路径，以及“update_time”字段对应的文件最后更新时间等信息，使用相同的算法，如安全散列算法1（SecureHash Algorithm 1，SHA1），生成一个散列函数值，将该散列函数值作为临时文件数据特征码即可。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

相应地，在临时文件数据特征码与文件数据信息表中记录的文件数据特征码不同时，才采用差量传输方式，将第一文件中的差量数据传输至第二设备。反之，在临时文件数据特征码与文件数据信息表中记录的文件数据特征码相同时，即当前没有对第一文件进行编辑，新增或删除内容，也即第一设备中当前查看的第一文件与之前传输给第二设备的第一文件的内容相同，因此第一设备不需要向第二设备传输第一文件的数据。

这样，当要进行接续传输的第一文件不是首次进行接续传输时，直接采用差量传输方式传输差量数据，而非将第一文件的全部数据都传输给第二设备，从而大大缩短了多设备应用接续过程中接续传输文件所花费的时间。

此外，由于第一设备和第二设备之间，对第一文件多次进行的接续传输均采用的差量传输方式，因此每次接续传输的数据量相对整个第一文件的数据要少很多，从而能够有效避免多设备应用接续过程中传输失败的情况，大大提升了保证多设备应用接续传输的成功率。

此外，还需要说明的是，在一些实现方式中，为了避免第一设备持续与第二设备进行数据传输，降低设备功耗和资源的占用，在第一设备采用差量传输方式，将第一文件中的差量数据传输至第二设备，或者采用全量传输方式，将文件数据信息表传输至第二设备之后，还可以设置第一设备保存第一文件，并退出可以编辑第一文件的界面，如回到上述实施例中图18所示的界面。

此外，还需要说明的是，在实际作业中，任意一个第一设备也可以作为第二设备，即第一设备既可以作为应用接续请求的发起方，发送第一文件，也可以作为应用接续请求的响应方，接收第一文件。故而，第一设备在将第一文件（差量传输方式或全量传输方式）传输至第二设备，将第一设备切换到后台运行，后者退出第一应用后，即第一应用不处于前台运行时，如果第一设备接收到第二设备发送的针对第一应用的应用接续请求时，此时第一设备作为第一文件的接收端，可以在第一设备中安装的第一应用对应的第一应用图标上添加应用接续标识，如图20中（1）示出的小图标10b-1。

相应地，当用户点击添加了应用接续标识的第一应用图标后，第一设备响应于对添加了应用接续标识的第一应用图标的操作，会重新将第一应用切换为前台运行，如从后台切换到前台，或者重新启动第一应用，并加载本地的第一文件，以及第二设备采用差量传输方式传输的第一文件的差量数据。

可理解的，如果第二设备对第一文件没有进行编辑，即不存在差量数据的情况下，此时第一设备只需加载本地的第一文件即可。

此外，第一设备在完成上述加载第一文件的操作后，还可以根据第二设备传输的差量数据，更新文件数据信息表。这样，能够便于后续进行应用接续时，精准的判断是否需传输数据。

可理解的，不论是第一设备还是第二设备，在采用差量传输方式传输第一文件的差量数据时，不仅仅会传输第一文件具体的修改后的内容，还涉及编辑时间，即第一文件的最后更新时间等。因此，本实施例中所说的差量数据，是当前要传输的第一文件与进行编辑前的第一文件的全部差异内容。

此外，还需要说明的是，在一些实现方式中，还可以设置应用接续标识的显示时间。这样，通过设置在设定时间内允许第一设备与第二设备进行应用接续，如果设定时间内用户没有在第一设备针对应用接续请求做出应用接续响应，即触发携带应用接续标识的第一应用图标，则取消应用接续标识，从而能够避免第一设备一直处于等待用户做出应用响应的状态，进而可以降低第一设备的功耗。

此外，还需要说明的是，在一些实现方式中，还可以设置第一设备采用差量传输方式，将第一文件中的差量数据传输至第二设备，或者采用全量传输方式，将文件数据信息表传输至第二设备之后，继续停留在可以编辑第一文件的界面。这样第一设备和第二设备可以持续进行应用接续，使得第一设备中可以编辑第一文件的界面中显示的第一文件的内容与第二设备中可以编辑第一文件的界面中显示的内容保持同步，从而在第一设备和第二设备之间实现了对第一应用的无缝协同处理。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

此外，关于多设备应用接续过程中，未在本实施例中示出的细节，可以参见上述实施例，此处不再赘述。

参见图22，示例性示出应用于第一设备，即作为应用接续请求发起方，负责发送要接续的数据的终端设备（也可以称为：发送端），实现本实施例提供的多设备应用接续方法的流程。如图22所示，应用于第一设备的多设备应用接续方法，具体包括：

S201，在第二设备安装了第一应用的情况下，在接收到第一设备发送的针对第一应用的应用接续请求时，在第一应用对应的第一应用图标上添加应用接续标识。

示例性的，以第二设备为上述实施例中描述的设备20为例，第一应用为备忘录应用为例，在第一应用对应的第一应用图标上添加应用接续标识可以为上述实施例中所说的在备忘录应用图标上添加的小图标20b-1。

关于应用接续图标的描述可以参见上文针对小图标20b-1的描述部分，此处不再赘述。

S202，响应于对添加了应用接续标识的第一应用图标的操作，向第一设备发送针对应用接续请求做出的应用接续响应，并将第一应用切换为前台运行。

结合上述实施例的描述，此处所说的响应于对添加了应用接续标识的第一应用图标的操作，例如为用户在设备20中点击了添加了小图标20b-1的备忘录应用图标。

此外，需要说明的是，在实际应用中，可能存在第一应用，如备忘录应用已经被启动，但是处于后台运行，前端界面没有显示备忘录应用对应的界面的情况，也可能备忘录应用本来就没有被启动运行。故而，上述将第一应用切换为前台运行，对于已经运行在后台的情况，实质为将第一应用切换到前台运行，而对于未运行的情况，则是启动第一应用在前台运行。

S203，在接收到第一设备采用全量传输方式传输的文件数据信息表后，从文件数据信息表中的数据原子集合中解析出第一文件的全部数据，加载显示，并将文件数据信息表保存到本地。

示例性的，对于第一文件的数据是从文件数据信息表中解析出的情况，通过上述实施例描述可知，第一文件为首次进行接续传输，因此接续传输的为第一文件的全部数据，故而在进行加载的过程中，可能出现等待加载的情况，第二设备的用户界面可能出现图17中（1）所示的情况。

相应地，当第一文件的数据全部从文件数据信息表中解析出并加载成功后，界面会切换为如图17中（2）所示的情况。

关于针对首次进行接续传输的第一文件的传输和加载过程中涉及的界面变化，可以参见上述实施例，此处不再赘述。

此外，由于第二设备是首次接收到第一文件，因此第二设备的本地没有第一文件对应的文件数据信息表，因此第二设备会将第一设备传输的文件数据信息表进行保存，以便后续第二设备作为应用接续请求的发起方，即发送第一文件的发送端时，能够根据文件数据信息表中记录的文件数据特征码和新生成的临时文件数据特征码，确定是否需要传输差量数据。

S204，在接收到第一设备采用差量传输方式传输的第一文件的差量数据后，加载差量数据，以及本地存储的第一文件进行显示，并根据差量数据更新本地存储的文件数据信息表。

示例性的，对于接收到的是第一文件的差量数据的情况，由于本地已经存储了一个版本的第一文件，因此第二设备在将第一应用切换到前台运行后，对于没有变更的部分直接加载本地得到第一文件，同时加载第一设备传输的差量数据进行融合，便可以显示第一设备中更新后的第一文件。

此外，为了便于后续第二设备作为应用接续请求的发起方，即发送第一文件的发送端时，能够根据文件数据信息表中记录的文件数据特征码和新生成的临时文件数据特征码，确定是否需要传输差量数据，每次接收到第一设备传输的差量数据，加载显示后，第二设备都可以根据差量数据对文件数据信息表进行一次更新，如根据差量数据对应的更新时间，更新文件数据信息表中“update_time”字段对应的文件最后更新时间，以及根据最终加载显示的内容更新“byte_file”字段对应的文件数据内容，“attribute_cod”字段对应的更新后的文件数据特征码等。

这样，只有首次进行接续传输的第一文件采用全量传输方式传输时，才需要等待加载，后续对第一文件进行接续传输时，直接加载第一设备采用差量传输方式传输的差量部分，其余相同部分从本地加载，从而大大缩短了多设备应用接续过程中接续传输文件所花费的时间。

此外，在一些实现方式中，还可以设置第二设备在接收到第一设备发送的针对第一应用的应用接续请求后，在设定时间内没有接收到对添加了应用接续标识的第一应用图标的操作时，取消第一应用图标上的应用接续标识。

具体的，在取消应用接续标识后，第二设备将无法与第一设备针对第一应用进行应用接续。

这样，通过设置在设定时间内允许第二设备与第一设备进行应用接续，如果设定时间内用户没有在第二设备针对应用接续请求做出应用接续响应，即触发携带应用接续标识的第一应用图标，则取消应用接续标识，避免第二设备一直处于等待用户做出应用响应的状态，降低第二设备的功耗。

此外，还需要说明的是，对于第二设备未安装第一应用的情况，在接收到第一设备发送的针对第一应用的应用接续请求时，可以提示用户安装第一应用。关于第二设备提示用户安装第一应用的实现细节，可以参见针对图13的描述部分，此处不再赘述。

这样，提醒用户安装第一应用后，后续第一设备和第二设备便可以针对第一应用进行应用接续，实现对第一应用中第一文件在第一设备和第二设备的无缝切换，协同作业。

由于应用于第二设备的多设备应用接续方法是与第一设备配合进行的，因此未在本实施例详尽描述的内容，可以参见上述针对第一设备实现多设备应用接续方法的实施例，以及下述图23对应的内容，此处不再赘述。

为了更好了理解本申请提供的多设备应用接续方法，仍以上述示例中所说的应用接续是针对备忘录应用为例，在进行应用接续的两个终端设备都安装了能够进行应用接续的备忘录应用的情况下，结合图23对发送端和接收端实现多设备应用接续方法进行具体说明。

参见图23，针对发送端，实现多设备应用接续的方法，具体包括：

S301，待传输笔记是否存在文件数据信息表。

具体的，当用户在发送端操作待传输笔记，如上述实施例中所说的笔记3时，接收端上备忘录应用图标上会显示应用接续标识，如上述实施例中设备20中备忘录应用图标上显示的小图标20b-1。此时表面发送端向超级终端中的其他终端设备（作为接收端）发起了应用接续请求。

示例性的，当用户操作接收端，做出针对应用接续请求的应用接续响应，如上述实施例中描述的，点击了设备20中的备忘录应用图标后，作为应用接续请求的发起方，发送段会进行两次逻辑判断，分别为判断本次要接续传输的笔记是否为首次接续，以及在该笔记为非首次接续时，进一步判断本次要接续传输的笔记的内容是否与上一次接续传输给做出应用接续响应的接收端的笔记的内容相同。

针对第一次判断，通过上述实施例的描述可知，具体为判断本地是否存在与待传输笔记对应的文件数据信息表。关于文件数据信息表包括的具体内容详见上述实施例，此处不再赘述。

相应地，若通过判断，确定本地不存在文件数据信息表，表示针对待传输笔记的接续任务是首次接续。对这种情况，需要采用全量传输方式，对待传输笔记进行传输。

具体的，在采用全量传输方式，对待传输笔记进行传输时，需要先为待传输笔记创建文件数据信息表，然后基于文件数据信息表，对笔记内容进行全量传输，即执行步骤S302和步骤S303。

关于文件数据信息表的创建，以及基于文件数据信息表对笔记内容进行全量传输的方式，详见上述实施例，此处不再赘述。

此外，若通过判断，确定本地存在文件数据信息表，表示针对待传输笔记的接续任务是非首次接续。对这种情况，需要采用差量传输方式对待传输笔记进行传输。

具体的，在采用差量传输方式对待传输笔记进行传输时，需要进一步确定本次要接续传输的笔记的内容是否与上一次接续传输给做出应用接续响应的接收端的笔记的内容相同，即进行第二逻辑判断。对于第二次逻辑判断的实现，详见步骤S304和步骤S305。

S302，为待传输笔记创建文件数据信息表。

S303，笔记内容全量传输。

S304，随机扫描待传输文件，生成临时数据原子集合，根据临时数据原子集合中的数据生成临时文件数据特征码。

关于临时文件数据特征码的生成，可以参见上述实施例，此处不再赘述。

S305，临时文件数据特征码是否与文件数据信息表中记录的文件数据特征码相同。

具体的，如果临时文件数据特征码与文件数据信息表中记录的文件数据特征码不相同，则执行步骤S206。反之，则执行步骤S307。

S306，笔记内容差量传输。

S307，不传输笔记内容。

继续参见图23，针对接收端，实现多设备应用接续的方法，具体包括：

S401，通过发送端的文件唯一标识，拉起备忘录应用，在拉起备忘录应用后，加载全量传输的笔记内容，并复制文件数据信息表。

通过上述实施例的描述可知，针对待传输笔记为首次接续的场景，发送端在与接收端进行多设备应用接续时，是将携带了待传输笔记全部数据内容的文件数据信息表，以全量传输方式传输给了接收端。而在文件数据信息表中，“uuid”字段中记录了能够标识文件唯一性的标识信息，而该标识信息是基于待传输笔记以及编辑该笔记的应用，如备忘录应用之间的关系生成的，因此在接收到文件数据信息表后，根据“uuid”字段中记录的标识信息便可以确定需要拉起哪个应用，即将哪个应用切换到前台运行。

故而，对于文件数据信息表中“uuid”字段中记录的标识信息指示的是备忘录应用时，接收端会直接将备忘录应用切换到前台运行。

此外，通过上述实施例中针对文件数据信息表的描述可知，文件数据信息表中还包括数据原子集合，而数据原子集合的“byte_file”字段中对应的待传输笔记的具体内容。因此，接收端在拉起备忘录应用后，通过解析“byte_file”字段中对应的内容，便可以在当前的界面中加载显示出发送端传输来的针对待传输笔记的全部内容。

此外，由于接收端是首次接收到待传输笔记，因此接收端的本地没有待传输笔记对应的文件数据信息表，因此接收端会将发送段传输的文件数据信息表进行保存，以便后续发送端作为应用接续请求的发起方，即发送待传输笔记的发送端时，能够根据文件数据信息表中记录的文件数据特征码和新生成的临时文件数据特征码，确定是否需要传输差量数据。

S402，通过发送端的文件唯一标识，拉起备忘录应用，并在拉起备忘录应用后，加载本地的笔记内容和差量传输的笔记内容。

由于，本次应用接续，发送端对待传输笔记的内容进行更新，并采用差量传输方式传输了笔记中的差量数据，给接收端，因此接收端在拉起备忘录应用后，不仅要加载这部分差量数据，还需要加载本地的笔记内容，从而融合得到与发送端管理的存在差量数据的待传输笔记。

S403，通过发送端的文件唯一标识，拉起备忘录应用，并在拉起备忘录应用后，加载本地的笔记内容。

由于，本次应用接续，发送端没有对待传输笔记的内容进行更新，即没有笔记内容传输给接收端，因此接收端在拉起备忘录应用后，直接加载本地的笔记内容即可。

S404，更新文件数据表。

这样，后续发送端作为应用接续请求的发起方，即发送待传输笔记的发送端时，能够根据文件数据信息表中记录的文件数据特征码和新生成的临时文件数据特征码，确定是否需要传输差量数据。

为了更直观的看出本申请实施例提供的多设备应用接续方法与现有应用接续耗时的差异，仍以要进行应用接续的应用为备忘录应用为例，参见表1说明本申请实施例提供的多设备应用接续方法与现有应用接续耗时的差异。

表1 应用接续耗时对比

通过表1不难看出，目前的应用接续方案中，每次应用接续传输的笔记均是采用全量传输，因此耗时较长，这就导致用户等待时间长，用户体验差。而使用本申请实施例提供的多设备应用接续方法进行的应用接续，只有首次接续时，会使用全量传输方式对笔记进行传输，后续接续场景下，即非首次接续场景中则使用差量传输方式，从而大大减少了接续耗时，用户只有在首次接续或者差量传输内容较大的情况下短暂等待，无需每次都等待加载，大大提升了用户体验。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

由此，发送端能够根据实际情况，选择合适的传输方式，对待传输笔记进行传输，接收端则可以选择从本地加载部分数据，或者全部数据，或者仅从发送端获取数据加载，这样既保证了首次接续的待传输笔记能够被接收端接收显示，又能在后续非首次接续的过程中，降低数据传输的耗时，提高多设备应用接续的成功率。

此外，关于多设备应用接续过程中，未在本实施例中示出的细节，可以参见上述实施例，此处不再赘述。

此外，可以理解的是，终端设备为了实现上述功能，其包含了执行各个功能相应的硬件和/或软件模块。结合本文中所公开的实施例描述的各示例的算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以结合实施例对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

此外，需要说明的是，在实际的应用场景中由终端设备实现的上述各实施例提供的多设备应用接续方法，也可以由终端设备中包括的一种芯片***来执行，其中，该芯片***可以包括处理器。该芯片***可以与存储器耦合，使得该芯片***运行时调用该存储器中存储的计算机程序，实现上述终端设备执行的步骤。其中，该芯片***中的处理器可以是应用处理器也可以是非应用处理器的处理器。

另外，本申请实施例还提供一种计算机可读存储介质，该计算机存储介质中存储有计算机指令，当该计算机指令在终端设备上运行时，使得终端设备执行上述相关方法步骤实现上述实施例中的多设备应用接续方法。

另外，本申请实施例还提供了一种计算机程序产品，当该计算机程序产品在终端设备上运行时，使得终端设备执行上述相关步骤，以实现上述实施例中的多设备应用接续方法。

另外，本申请的实施例还提供一种芯片（也可以是组件或模块），该芯片可包括一个或多个处理电路和一个或多个收发管脚；其中，所述收发管脚和所述处理电路通过内部连接通路互相通信，所述处理电路执行上述相关方法步骤实现上述实施例中的多设备应用接续方法，以控制接收管脚接收信号，以控制发送管脚发送信号。

此外，通过上述描述可知，本申请实施例提供的终端设备、计算机可读存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (13)

1.一种多设备应用接续方法，其特征在于，应用第一设备，所述方法包括：

在使用注册为接续应用的第一应用编辑第一文件的过程中，向第二设备发送针对所述第一应用的应用接续请求；

检测本地是否存在与所述第一文件对应的文件数据信息表，所述文件数据信息表中的信息用于指示所述第二设备做出所述应用接续响应后，启动安装在所述第二设备上的第一应用，并加载所述第一文件；其中，所述文件数据信息表包括文件数据特征码；

在存在与所述第一文件对应的文件数据信息表时，确定所述第一文件为非首次进行接续传输；

在所述第一文件为非首次进行接续传输时，在接收到所述第二设备针对所述应用接续请求做出的应用接续响应后，对所述第一文件进行随机扫描，生成临时数据原子集合；

根据所述临时数据原子集合中的数据，生成临时文件数据特征码；

在所述临时文件数据特征码与所述文件数据信息表中记录的所述文件数据特征码不同时，采用差量传输方式，将所述第一文件中的差量数据传输至所述第二设备；其中，在所述第一文件为非首次进行接续传输时，采用差量传输方式传输所述第一文件的时间小于采用全量传输方式传输所述第一文件的时间；

在所述临时文件数据特征码与所述文件数据信息表中记录的所述文件数据特征码相同时，不向所述第二设备传输所述第一文件的数据；

在不存在与所述第一文件对应的文件数据信息表时，确定所述第一文件为首次进行接续传输；

根据所述第一应用和所述第一文件，构建与所述第一文件对应的所述文件数据信息表，所述文件数据信息表携带了所述第一文件的全部数据；

在接收到所述第二设备针对所述应用接续请求做出的应用接续响应后，采用全量传输方式，将所述文件数据信息表传输至所述第二设备；

其中，所述第一设备和所述第二设备均对所述第一文件拥有完整的编辑、存储和传输功能。

2.根据权利要求1所述的方法，其特征在于，所述根据所述第一应用和所述第一文件，构建与所述第一文件对应的所述文件数据信息表，包括：

根据所述第一应用和所述第一文件，生成文件唯一标识，所述文件唯一标识指示了所述第一文件和所述第一应用的关系；

根据所述第一文件生成文件基础公共信息和数据原子集合，所述数据原子集合携带了所述第一文件的全部数据；

根据所述数据原子集合中的数据，生成文件数据特征码，所述文件数据特征码用于标识所述第一文件中的数据；

根据所述文件唯一标识、所述文件基础公共信息、所述数据原子集合和所述文件数据特征码，生成所述文件数据信息表。

3.根据权利要求1或2所述的方法，其特征在于，所述方法还包括：

在采用差量传输方式，将所述第一文件中的差量数据传输至所述第二设备，或者采用全量传输方式，将所述文件数据信息表传输至所述第二设备之后，保存所述第一文件，并退出可以编辑所述第一文件的界面。

4.根据权利要求3所述的方法，其特征在于，在所述退出可以编辑所述第一文件的界面之后，所述方法还包括：

在所述第一应用不处于前台运行时，在接收到所述第二设备发送的针对所述第一应用的应用接续请求时，在所述第一应用对应的第一应用图标上添加应用接续标识；

响应于对添加了所述应用接续标识的所述第一应用图标的操作，将所述第一应用切换为前台运行，并加载本地的所述第一文件，以及所述第二设备采用差量传输方式传输的所述第一文件的差量数据。

5.根据权利要求4所述的方法，其特征在于，所述方法还包括：

根据所述差量数据，更新所述文件数据信息表。

6.根据权利要求4所述的方法，其特征在于，在所述第一应用对应的第一应用图标上添加应用接续标识后，所述方法还包括：

在设定时间内没有接收到对添加了所述应用接续标识的所述第一应用图标的操作时，取消所述第一应用图标上的所述应用接续标识；

其中，取消所述应用接续标识后，所述第一设备无法与所述第二设备针对所述第一应用进行应用接续。

7.根据权利要求1或2所述的方法，其特征在于，所述方法还包括：

在采用差量传输方式，将所述第一文件中的差量数据传输至所述第二设备，或者采用全量传输方式，将所述文件数据信息表传输至所述第二设备之后，继续停留在可以编辑所述第一文件的界面；

其中，所述第一文件的界面中显示的所述第一文件的内容与所述第二设备中所述第一文件的内容保持同步。

8.根据权利要求1或2所述的方法，其特征在于，在所述向第二设备发送针对所述第一应用的应用接续请求前，所述方法还包括：

确保所述第一设备和所述第二设备开启了应用接续功能、蓝牙功能和无线局域网功能。

9.一种多设备应用接续方法，其特征在于，应用第二设备，所述方法包括：

在所述第二设备安装了第一应用的情况下，在接收到第一设备发送的针对第一应用的应用接续请求时，在所述第一应用对应的第一应用图标上添加应用接续标识；

响应于对添加了所述应用接续标识的所述第一应用图标的操作，向所述第一设备发送针对所述应用接续请求做出的应用接续响应，并将所述第一应用切换为前台运行；

在接收到所述第一设备采用全量传输方式传输的文件数据信息表后，从所述文件数据信息表中的数据原子集合中解析出第一文件的全部数据，加载显示，并将所述文件数据信息表保存到本地；其中，所述第一设备采用全量传输方式传输的所述文件数据信息表为：所述第一设备检测本地不存在与所述第一文件对应的文件数据信息表时，根据所述第一应用和所述第一文件，构建出的与所述第一文件对应的所述文件数据信息表，所述文件数据信息表携带了所述第一文件的全部数据；

在接收到所述第一设备采用差量传输方式传输的所述第一文件的差量数据后，加载所述差量数据，以及对本地存储的所述第一文件进行显示，并根据所述差量数据更新本地存储的所述文件数据信息表；其中，所述第一设备采用差量传输方式传输的所述第一文件的差量数据为：所述第一设备检测本地存在与所述第一文件对应的文件数据信息表时，在接收到所述第二设备针对所述应用接续请求做出的应用接续响应后，在所述文件数据信息表中记录的文件数据特征码与根据所述第一文件生成的临时文件数据特征码不同时，所述第一设备采用差量传输方式传输的所述第一文件的差量数据；

其中，根据所述第一文件生成的所述临时文件数据特征码，具体为：

对所述第一文件进行随机扫描，生成临时数据原子集合；

根据所述临时数据原子集合中的数据，生成所述临时文件数据特征码。

10.根据权利要求9所述的方法，其特征在于，所述方法还包括：

在接收到第一设备发送的针对第一应用的应用接续请求后，在设定时间内没有接收到对添加了所述应用接续标识的所述第一应用图标的操作时，取消所述第一应用图标上的所述应用接续标识；

其中，取消所述应用接续标识后，所述第二设备无法与所述第一设备针对所述第一应用进行应用接续。

11.根据权利要求9所述的方法，其特征在于，所述方法还包括：

在所述第二设备未安装所述第一应用的情况下，在接收到第一设备发送的针对第一应用的应用接续请求时，提示用户安装所述第一应用。

12.一种终端设备，其特征在于，所述终端设备包括：存储器和处理器，所述存储器和所述处理器耦合；所述存储器存储有程序指令，所述程序指令由所述处理器执行时，使得所述终端设备执行如权利要求1至8任意一项所述的多设备应用接续方法，或者如权利要求9至11任意一项所述的多设备应用接续方法。

13.一种计算机可读存储介质，其特征在于，包括计算机程序，当所述计算机程序在终端设备上运行时，使得所述终端设备执行如权利要求1至8任意一项所述的多设备应用接续方法，或者如权利要求9至11任意一项所述的多设备应用接续方法。

Images