CN107295075B - 一种基于会话保持的跨终端应用状态迁移方法 - Google Patents

Abstract

本发明公开了一种基于会话保持的跨终端应用状态迁移方法，所用的设备包括源终端、目的终端，所述源终端和目的终端的共享服务器，所述源终端的目标应用上安装有目标应用数据捕获单元，所述目的终端的目标应用上安装有目标应用数据注入单元，所述目标应用数据捕获单元和目标应用数据注入单元之间连接有第三方服务器，所述第三方服务器具有一个独立的数据库，主要包括的步骤是：创建并存储应用描述文件，目标应用数据的捕获、存储和会话标记的获取，目标应用数据的注入及任务A的状态再现和会话的共享。本发明使得应用状态在不同终端间进行自动化保存和恢复，实现了HTTP应用在不同终端间实现无缝切换，优化移动用户交互模式、提升交互体验有重要意义。

Description

一种基于会话保持的跨终端应用状态迁移方法

技术领域

本发明涉及移动互联网与服务计算领域，尤其涉及一种基于会话保持的方法以支持应用的跨终端迁移。

背景技术

目前，全球范围内已掀起移动互联网热潮，我国也进入了移动互联网高速发展时代。随着移动智能终端的广泛普及和移动服务生态系统的日益发展，用户可以随时随地的获取信息并享受互联网服务。特别地，HTTP(超文本传输协议)应用的不断丰富和多元化使得用户几乎可以满足包括社交、工作、资讯、娱乐等在内的各个方面的需求。可以说，移动终端和移动应用已经深深地渗透到人们日常的工作、学习和生活中，并进而影响甚至重塑人们的日常活动。与此同时，应用的用户体验也已经成为人们和开发者最为关心的问题之一。通常情况下，在用户使用一款应用处理任务的过程中，由于环境等因素的限制和影响，用户有时需要从当前终端切换到一个更合适的终端去处理任务。例如，考虑这样一个场景：在用户使用台式机处理任务过程中，他突然接到通知需要去参加一个紧急会议，那么此时他就完全可以切换到自己的智能手机上并在路途中接着处理刚才未完成的任务。然而，现有的应用几乎都不支持这种动态切换。有调查显示，62.9％的人们依然通过手工的方式转移信息以便在新终端上继续处理任务。但是，通过在新终端上重复相同的操作去手工地恢复应用状态无疑会导致极差的用户体验。因此，如何高效地支持应用跨终端迁移是一个十分重要问题。

目前现有的一些应用迁移技术大都专注于解决某一特定平台(系统)上的应用迁移问题。由于此类技术与平台紧密相关，因此它们只能作为特定平台下应用迁移的解决方案，并没有实现真正意义上的跨终端迁移。其次，由于移动终端自身特点的限制，类似流程迁移和虚拟机迁移等一些流行的、重量级的迁移方法并不适合在这类终端上应用，因此这类技术也不能真正地解决应用的跨终端迁移。此外，谷歌提出的基于屏幕快照和图像特征匹配的应用迁移技术虽然可以自动地在异质终端间迁移应用状态，但是由于应用的各版本间(比如Web版本和Android版本)在应用布局和操作逻辑等方面常常存在一定的差异，因此这项技术在很多场景下是不可靠的，甚至是失效的。

发明内容

针对以上的问题，本发明提出一种基于会话保持的方法去支持应用的跨终端迁移，使得应用状态可以在不同终端间进行自动化保存和恢复，实现了HTTP应用在不同终端间实现无缝切换，优化移动用户交互模式、提升交互体验有重要意义。

为了解决上述技术问题，本发明提出的一种基于会话保持的跨终端应用状态迁移方法，所用的设备包括源终端、目的终端，所述源终端和目的终端的共享服务器，所述源终端的目标应用上安装有目标应用数据捕获单元，所述目的终端的目标应用上安装有目标应用数据注入单元，所述目标应用数据捕获单元和目标应用数据注入单元之间连接有第三方服务器，所述第三方服务器具有一个独立的数据库，并包括以下步骤：

步骤一、创建并存储应用描述文件：将预使用的目标应用在源终端和目的终端上根据其工作流分别划分为N个一一相互对应的连续的任务，将上述N个一一相互对应的连续的任务创建为一个XML格式的应用描述文件，用于描述目标应用的页面布局、视图逻辑和各个任务的启动入口；将所述应用描述文件存入所述数据库中；

步骤二、目标应用数据的捕获、存储和会话标记的获取：用户在源终端上进行目标应用登录后，所述目标应用数据捕获单元解析应用描述文件来判断当前正在执行的任务，该任务记为任务A，并捕获用户在任务A中所输入的任务数据，与此同时，所述目标应用数据捕获单元获取源终端与服务器交互时的会话标记和源终端在共享服务器中的用户标记；所述用户标记、目标应用名称、会话标记、任务A的名称及其任务A的数据形成一条状态消息；所述目标应用数据捕获单元将上述状态消息及其该状态消息生成的时间存储至所述数据库；

步骤三、目标应用数据的注入及任务A的状态再现：用户切换到目的终端上进行应用状态恢复时，所述目标应用数据注入单元根据用户标识和目标应用名称向第三方服务器请求相应的状态消息，第三方服务器收到请求后根据状态消息生成的时间从所述数据库中查找并返回离当前最近的状态信息；与此同时，所述目标应用数据注入单元根据目标应用名称向第三方服务器请求相应的应用描述文件；之后，所述目标应用数据注入单元根据状态消息中与任务A的名称匹配的应用描述文件中相应的任务A的数据，并获取该任务A在目的终端的启动入口，紧接着在目的终端从任务A直接启动目标应用并将状态消息中与该任务A相关的数据直接注入、填充到任务A对应的页面中，从而再现源终端目标应用环境下的任务A的状态；

步骤四、会话的共享：所述目标应用数据注入单元从上述状态消息中获取源终端与服务器交互时的会话标记，并当用户在目的终端的目标应用与服务器继续交互时携带上上述会话标记，从而实现目的终端共享源终端与服务器的会话，使得用户在目的终端的目标应用继续会话。

与现有技术相比，本发明的有益效果是：

本发明通过对HTTP应用的主流架构和应用状态进行分析和建模，提出了一种基于会话保持的跨终端应用状态迁移方法。可以方便地为应用增加可迁移特性并通过会话的保持和应用数据的自动注入实现应用在不同终端上的自动迁移，实现应用的无缝切换。在此基础上，用户只需通过简单的操作便可实现应用在不同终端间的迁移，有效的提升用户的交互体验。

附图说明

图1为本发明所述跨终端应用状态迁移方法的总体架构图；

图2为本发明所述跨终端应用状态迁移方法的基本构思图；

图3为本发明所述应用在不同终端间切换示意图；

图4为本发明所述Demo应用的应用描述片段示意图；

图5为本发明所述Demo应用的“票务预订”案例的跨终端迁移示意图；

图6为本发明所述跨终端迁移应用状态时的状态消息示意图；

图7为本发明所述OSChina应用的“博客阅读”案例的跨终端迁移示意图；

图8为本发明所述“票务预订”案例在系统迁移和手工迁移下的全程耗时条形图；

图9为本发明所述“博客阅读”案例在系统迁移和手工迁移下的全程耗时条形图；

图10为本发明所述“票务预订”和“博客阅读”两个案例在系统迁移方式下比手工迁移方式迁移耗时减少率箱线图。

具体实施方式

下面结合附图和具体实施例对本发明技术方案作进一步详细描述，所描述的具体实施例仅对本发明进行解释说明，并不用以限制本发明。

如图1所示，基于会话保持的跨终端应用状态迁移方法的总体架构所用的设备包括源终端、目的终端，所述源终端和目的终端的共享服务器，所述源终端的目标应用上安装有目标应用数据捕获单元，所述目的终端的目标应用上安装有目标应用数据注入单元，所述目标应用数据捕获单元和目标应用数据注入单元之间连接有第三方服务器，所述第三方服务器具有一个独立的数据库。本发明通过目标应用数据捕获单元、第三方服务器及其连接的数据库和目标应用数据注入单元三个组件协同完成应用状态在不同终端间的迁移。

本发明的核心思想是通过会话数据的共享和目标应用数据的捕获/注入来实现应用状态的跨终端迁移，如图2所示。HTTP应用的主流架构是“云-端”架构，即由后台服务器和前台终端两部分构成。无论HTTP应用的实现遵从B/S模式还是C/S模式，其本身都可以看作是一种具有特定表现层的服务。基于HTTP应用的这种架构模式，实现应用从源终端到目的终端的无缝切换关键在于两点：1)目的终端共享源终端与服务器的会话状态，2)目的终端重现目标应用在源终端切换时的状态，这也是本发明的主要步骤中的两个重要的技术实现。

鉴于HTTP协议的无状态性，为了保持源终端与服务器的会话状态，HTTP应用常常采用Cookie/Session机制来实现会话状态管理。在源终端与服务器交互过程中，服务器会开辟一块内存来保存源终端与服务器的会话状态并生成一个与源终端相关联的会话标记(JESSIONID)返回给源终端，之后源终端每次访问服务器时携带上这个会话标记就可以访问其与服务器之前的交互状态，从而实现会话状态的保持。在本发明中，目标应用从源终端切换到目的终端后，使目的终端在访问服务器时携带上源终端与服务器交互时的会话标记就可以共享源终端与服务器的会话状态。

应用从源终端切换到目的终端后，除了需要共享源终端与服务器的会话状态，还需要在目的终端重现目标应用在源终端切换时的状态。如图3所示，目标应用在源终端执行到任务2时切换到目的终端，并在目的终端从与源终端任务2对应的任务继续执行。在这个切换过程中，将捕获用户在源终端的任务2中所输入的数据并在切换到目的终端后将这些数据注入到目的终端对应的任务中就可以在目的终端重现目标应用在源终端切换时的状态。

因此，在本发明中，通过使目的终端在访问服务器时携带上源终端与服务器会话时的会话标记就可以实现目的终端共享源终端与服务器的会话状态；在目标应用从源终端切换到目的终端的过程中，通过捕获用户在源终端当前任务中所输入的数据并在切换到目的终端后将这些数据注入到目的终端对应的任务中就可以在目的终端重现目标应用在源终端切换时的状态。基于上述的两个重要技术实现，下面结合图1详细叙述基于会话保持的跨终端应用状态迁移方法的具体实现步骤。

(1)创建并存储应用描述文件。首先，将预使用的目标应用在源终端和目的终端上根据其工作流分别划分为N个一一相互对应的连续的任务，并将上述N个一一相互对应的连续的任务描述为一个XML格式的应用描述文件。上述的每个任务都对应于目标应用的若干个页面，每个任务不但描述了其所对应的页面中需要用户输入的数据以及这些数据在页面中对应的位置标识，即页面的视图逻辑，而且描述了目标应用从该任务启动时的入口。在创建目标应用的应用描述文件时，如果目标应用所在的源终端和目的终端是不同类型的终端，那么在源终端和目的终端安装的就是目标应用的两个不同的版本，目标应用在源终端和目的终端下的页面布局和视图逻辑也就互不相同，这时在应用描述文件中描述目标应用时对目标应用在源终端和目的终端的各版本进行分别描述；如果目标应用所在的源终端和目的终端是相同类型的终端，则在应用描述文件中描述目标应用时对目标应用当前版本进行描述即可。在创建完成应用描述文件后，将该应用描述文件存入第三方服务器对应的数据库中。

(2)目标应用数据的捕获、存储和会话标记的获取。用户在源终端上的目标应用登录后，所述目标应用数据捕获单元首先会根据目标应用名称向第三方服务器请求目标应用的应用描述文件并解析该应用描述文件中对目标应用在源终端的版本的描述来判断源终端上的目标应用当前正在执行的任务，该任务记为任务A。然后，所述目标应用数据捕获单元根据对应的描述捕获用户在任务A中所输入的数据，与此同时，所述目标应用数据捕获单元获取源终端与服务器交互时的会话标记和源终端在共享服务器中的用户标记，并将所述的用户标记、目标应用名称、会话标记、任务A的名称及用户在任务A输入的数据形成一条状态消息。然后，所述目标应用数据捕获单元将上述状态消息及该状态消息生成的时间发送给第三方服务器并存储至所述数据库；

(3)目标应用数据的注入及任务A的状态再现。用户切换到目的终端上进行应用状态恢复时，所述目标应用数据注入单元首先根据用户标识和目标应用名称向第三方服务器请求相应的状态消息，第三方服务器收到请求后根据状态消息生成的时间从所述数据库中查找并返回离当前最近的状态信息。与此同时，所述目标应用数据注入单元根据目标应用名称向第三方服务器请求相应的应用描述文件，并根据上述状态消息中任务A的名称匹配并找到应用描述文件中对目标应用在目的终端的版本的描述中对任务A的描述。然后，所述目标应用数据注入单元从对任务A的描述中获取任务A在目的终端的启动入口并在目的终端从任务A直接启动目标应用，同时根据上述描述将上述状态消息中与该任务A相关的数据直接注入、填充到任务A在目的终端对应的页面中，从而再现源终端目标应用环境下的任务A的状态。

(4)会话的共享。所述目标应用数据注入单元从上述状态消息中获取源终端与服务器交互时的会话标记，并当用户在目的终端的目标应用与服务器继续交互时携带上上述会话标记，从而实现目的终端共享源终端与服务器的会话，使得用户在目的终端的目标应用继续会话。

为验证基于会话保持的跨终端应用状态迁移方法的有益效果，选取了两个案例(“票务预订”案例和“博客阅读”案例)进行了实验。

“票务预订”案例

在一个类似携程应用的Demo应用上运行的。下面以该Demo应用作为目标应用，源终端为Web端，目的终端为Android端，Web端的Demo应用安装的目标应用数据捕获单元和Android端的Demo应用安装的目标应用数据注入单元分别是一个js函数库和一个Java软件包，利用本发明所述的方法将所述Demo应用从Web端切换到Android端，具体步骤如下：

(1)创建并存储Demo应用的应用描述文件。首先，如图4所示，将Demo应用在Web端和Android端上根据其工作流分别划分为四个一一相互对应的连续的任务，并将上述四个一一相互对应的连续的任务描述为一个XML格式的应用描述文件。上述的每个任务都对应于Demo应用的1～2个页面，每个任务不但描述了其所对应的页面中需要用户输入的数据以及这些数据在页面中对应的位置标识，即页面的视图逻辑，而且描述了目标应用从该任务启动时的入口。在创建Demo应用的应用描述文件时，由于Demo应用所在的Web端和Android端是不同类型的终端，因此Demo应用在Web端和Android端下的页面布局和视图逻辑互不相同，这时在应用描述文件中描述Demo应用时就对Demo应用的Web版本和Android版本分别进行描述。如图5所示，第3～55行是Demo应用的应用描述文件的一个片段，其描述了Demo应用的“用户登录”和“票务查询”两个任务；第5～28行是Demo应用的Android版本的描述，第31～54行是Demo应用的Web版本的描述。在创建完成应用描述文件后，将该应用描述文件存入第三方服务器对应的数据库中。

(2)Demo应用数据的捕获、存储和会话标记的获取。如图4所示，用户在Web端上的Demo应用登录并执行到“票务查询”任务时切换到Android端对应的“票务查询”任务并继续执行后面的任务。在切换时，目标应用数据捕获单元首先会根据Demo应用名称向第三方服务器请求Demo应用的应用描述文件并解析该应用描述文件中对Demo应用的Web版本的描述来判断Web端上的Demo应用当前正在执行的任务，即“票务查询”任务。然后，所述目标应用数据捕获单元根据对应的描述捕获用户在“票务查询”任务中所输入的数据，与此同时，所述目标应用数据捕获单元获取Web端与服务器交互时的会话标记(即JSESSIONID)和Web端在共享服务器中的用户标记，并将所述的用户标记、Demo应用名称、会话标记、“票务查询”任务的名称及用户在“票务查询”任务中输入的数据形成一条状态消息，如图6所示。然后，所述目标应用数据捕获单元将上述状态消息及该状态消息生成的时间发送给第三方服务器并存储至其对应的数据库中；

(3)目标应用数据的注入及“票务查询”任务的状态再现。用户切换到Android端上进行应用状态恢复时，目标应用数据注入单元首先根据用户标识和Demo应用名称向第三方服务器请求相应的状态消息，第三方服务器收到请求后根据状态消息生成的时间从所述数据库中查找并返回离当前最近的状态信息。与此同时，所述目标应用数据注入单元根据Demo应用名称向第三方服务器请求该Demo应用的应用描述文件，并根据上述状态消息中“票务查询”任务的名称匹配并找到应用描述文件中对Demo应用的Android版本的描述中对任务“票务查询”的描述。然后，所述目标应用数据注入单元从对“票务查询”任务的描述中获取“票务查询”任务在Android端的启动入口并在Android端从“票务查询”任务直接启动Demo应用，同时根据对任务“票务查询”的描述将上述状态消息中与“票务查询”任务相关的数据直接注入、填充到“票务查询”任务在Android端对应的页面中，从而再现Web端Demo应用环境下的“票务查询”任务的状态。

(4)会话的共享。目标应用数据注入单元从上述状态消息中获取Web端与服务器交互时的会话标记，并当用户在Android端的Demo应用继续会话时携带上该会话标记，实现Android端共享Web端与服务器的会话状态，使得用户在Android端的Demo应用上能够无缝地继续执行后面的任务，继续会话。

“博客阅读”案例

在OSChina(https://www.oschina.net/)应用上运行的。实验中以该OSChina应用作为目标应用，同样以Web端为源终端，以Android端为目的终端，Web端的Demo应用安装的目标应用数据捕获单元和Android端的Demo应用安装的目标应用数据注入单元与在“票务预订”案例中提到的实现完全相同。利用本发明所述的方法将所述Demo应用从Web端切换到Android端，如图7所示，OSChina应用在Web端执行到“阅读博客”任务时切换到Android端对应的“阅读博客”任务并继续执行。由于OSChina应用的切换过程与上面所述的Demo应用的切换过程基本类似，不再赘述。

下面比较在使用系统迁移(本发明所述方法)和手动迁移两种情况下Demo应用的“票务预订”案例和OSChina应用的“博客阅读”案例的耗时情况。为了保证实验的客观性，邀请了16人参与到该实验中。

首先，参与人员被要求在PC的Web端使用浏览器去模拟以上两个案例并使用手动迁移的方式将应用状态迁移到Android端。然后，在相同条件下，还被要求采用系统迁移的方式将应用状态从Web端迁移到Android端。如图8和图9所示，对于以上“票务预订”和“博客阅读”两个案例，使用系统迁移的方式迁移应用状态的全程耗时均明显少于手动迁移情形。在T-test测试中，p-value值为0。实际上，对于Demo应用的“票务预订”案例和OSChina应用的“博客阅读”案例，使用系统迁移方式的总耗时相比使用手工迁移的方式分别减少了大约67.46％和34.09％。这里“票务预订”案例总耗时减少幅度远大于“博客阅读”案例的主要由于案例本身导致的：“博客阅读”案例中用户与应用交互较少，特别是用户需要进行的数据输入操作较少，因此较为省时；“票务预订”案例中用户与应用交互较多，而且很多交互操作都需要用户输入数据，因此较为费时。此外，在系统迁移方式下，以上两个案例的迁移耗时也都明显少于手动迁移的情形，如图10所示。在Demo应用的“票务预订”案例中，手动迁移应用状态平均需要63.375s，而系统迁移应用状态平均只需要3.75s，时间平均节省了94.03％；在OSChina应用的“博客阅读”案例中，手动迁移应用状态平均需要27s，而系统迁移应用状态平均只需要4.375s，时间平均节省了83.94％。因此，基于会话保持的跨终端应用状态迁移方法能够高效地解决应用在不同终端间的切换问题，有效地提升用户的交互体验。

尽管上面结合附图对本发明进行了描述，但是本发明并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本发明的启示下，在不脱离本发明宗旨的情况下，还可以做出很多变形，这些均属于本发明的保护之内。

Claims (1)

1.一种基于会话保持的跨终端应用状态迁移方法，所用的设备包括源终端、目的终端，所述源终端和目的终端的共享服务器，所述源终端的目标应用上安装有目标应用数据捕获单元，所述目的终端的目标应用上安装有目标应用数据注入单元，所述目标应用数据捕获单元和目标应用数据注入单元之间连接有第三方服务器，所述第三方服务器具有一个独立的数据库，其特征在于，包括以下步骤：

步骤一、创建并存储应用描述文件：将预使用的目标应用在源终端和目的终端上根据其工作流分别划分为N个一一相互对应的连续的任务，将上述N个一一相互对应的连续的任务创建为一个XML格式的应用描述文件，用于描述目标应用的页面布局、视图逻辑和各个任务的启动入口；将所述应用描述文件存入所述数据库中；

步骤二、目标应用数据的捕获、存储和会话标记的获取：用户在源终端上进行目标应用登录后，所述目标应用数据捕获单元解析应用描述文件来判断当前正在执行的任务，该任务记为任务A，并捕获用户在任务A中所输入的任务数据，与此同时，所述目标应用数据捕获单元获取源终端与共享服务器交互时的会话标记和源终端在共享服务器中的用户标记；所述用户标记、目标应用名称、会话标记、任务A的名称及其任务A的数据形成一条状态消息；所述目标应用数据捕获单元将上述状态消息及其该状态消息生成的时间存储至所述数据库；

步骤三、目标应用数据的注入及任务A的状态再现：用户切换到目的终端上进行应用状态恢复时，所述目标应用数据注入单元根据用户标识和目标应用名称向第三方服务器请求相应的状态消息，第三方服务器收到请求后根据状态消息生成的时间从所述数据库中查找并返回离当前最近的状态信息；与此同时，所述目标应用数据注入单元根据目标应用名称向第三方服务器请求相应的应用描述文件；之后，所述目标应用数据注入单元根据状态消息中与任务A的名称匹配的应用描述文件中相应的任务A的数据，并获取该任务A在目的终端的启动入口，紧接着在目的终端从任务A直接启动目标应用并将状态消息中与该任务A相关的数据直接注入、填充到任务A对应的页面中，从而再现源终端目标应用环境下的任务A的状态；

步骤四、会话的共享：所述目标应用数据注入单元从上述状态消息中获取源终端与共享服务器交互时的会话标记，并当用户在目的终端的目标应用与共享服务器继续交互时携带上上述会话标记，从而实现目的终端共享源终端与共享服务器的会话，使得用户在目的终端的目标应用继续会话。

Images