本發(fā)明涉及移動互聯(lián)網與服務計算領域，尤其涉及一種基于會話保持的方法以支持應用的跨終端遷移。

背景技術：

目前，全球范圍內已掀起移動互聯(lián)網熱潮，我國也進入了移動互聯(lián)網高速發(fā)展時代。隨著移動智能終端的廣泛普及和移動服務生態(tài)系統(tǒng)的日益發(fā)展，用戶可以隨時隨地的獲取信息并享受互聯(lián)網服務。特別地，http(超文本傳輸協(xié)議)應用的不斷豐富和多元化使得用戶幾乎可以滿足包括社交、工作、資訊、娛樂等在內的各個方面的需求?？梢哉f，移動終端和移動應用已經深深地滲透到人們日常的工作、學習和生活中，并進而影響甚至重塑人們的日?；顒?。與此同時，應用的用戶體驗也已經成為人們和開發(fā)者最為關心的問題之一。通常情況下，在用戶使用一款應用處理任務的過程中，由于環(huán)境等因素的限制和影響，用戶有時需要從當前終端切換到一個更合適的終端去處理任務。例如，考慮這樣一個場景：在用戶使用臺式機處理任務過程中，他突然接到通知需要去參加一個緊急會議，那么此時他就完全可以切換到自己的智能手機上并在路途中接著處理剛才未完成的任務。然而，現(xiàn)有的應用幾乎都不支持這種動態(tài)切換。有調查顯示，62.9％的人們依然通過手工的方式轉移信息以便在新終端上繼續(xù)處理任務。但是，通過在新終端上重復相同的操作去手工地恢復應用狀態(tài)無疑會導致極差的用戶體驗。因此，如何高效地支持應用跨終端遷移是一個十分重要問題。

目前現(xiàn)有的一些應用遷移技術大都專注于解決某一特定平臺(系統(tǒng))上的應用遷移問題。由于此類技術與平臺緊密相關，因此它們只能作為特定平臺下應用遷移的解決方案，并沒有實現(xiàn)真正意義上的跨終端遷移。其次，由于移動終端自身特點的限制，類似流程遷移和虛擬機遷移等一些流行的、重量級的遷移方法并不適合在這類終端上應用，因此這類技術也不能真正地解決應用的跨終端遷移。此外，谷歌提出的基于屏幕快照和圖像特征匹配的應用遷移技術雖然可以自動地在異質終端間遷移應用狀態(tài)，但是由于應用的各版本間(比如web版本和android版本)在應用布局和操作邏輯等方面常常存在一定的差異，因此這項技術在很多場景下是不可靠的，甚至是失效的。

技術實現(xiàn)要素：

針對以上的問題，本發(fā)明提出一種基于會話保持的方法去支持應用的跨終端遷移，使得應用狀態(tài)可以在不同終端間進行自動化保存和恢復，實現(xiàn)了http應用在不同終端間實現(xiàn)無縫切換，優(yōu)化移動用戶交互模式、提升交互體驗有重要意義。

為了解決上述技術問題，本發(fā)明提出的一種基于會話保持的跨終端應用狀態(tài)遷移方法，所用的設備包括源終端、目的終端，所述源終端和目的終端的共享服務器，所述源終端的目標應用上安裝有目標應用數(shù)據(jù)捕獲單元，所述目的終端的目標應用上安裝有目標應用數(shù)據(jù)注入單元，所述目標應用數(shù)據(jù)捕獲單元和目標應用數(shù)據(jù)注入單元之間連接有第三方服務器，所述第三方服務器具有一個獨立的數(shù)據(jù)庫，并包括以下步驟：

步驟一、創(chuàng)建并存儲應用描述文件：將預使用的目標應用在源終端和目的終端上根據(jù)其工作流分別劃分為n個一一相互對應的連續(xù)的任務，將上述n個一一相互對應的連續(xù)的任務創(chuàng)建為一個xml格式的應用描述文件，用于描述目標應用的頁面布局、視圖邏輯和各個任務的啟動入口；將所述應用描述文件存入所述數(shù)據(jù)庫中；

步驟二、目標應用數(shù)據(jù)的捕獲、存儲和會話標記的獲取：用戶在源終端上進行目標應用登錄后，所述目標應用數(shù)據(jù)捕獲單元解析應用描述文件來判斷當前正在執(zhí)行的任務，該任務記為任務a，并捕獲用戶在任務a中所輸入的任務數(shù)據(jù)，與此同時，所述目標應用數(shù)據(jù)捕獲單元獲取源終端與服務器交互時的會話標記和源終端在共享服務器中的用戶標記；所述用戶標記、目標應用名稱、會話標記、任務a的名稱及其任務a的數(shù)據(jù)形成一條狀態(tài)消息；所述目標應用數(shù)據(jù)捕獲單元將上述狀態(tài)消息及其該狀態(tài)消息生成的時間存儲至所述數(shù)據(jù)庫；

步驟三、目標應用數(shù)據(jù)的注入及任務a的狀態(tài)再現(xiàn)：用戶切換到目的終端上進行應用狀態(tài)恢復時，所述目標應用數(shù)據(jù)注入單元根據(jù)用戶標識和目標應用名稱向第三方服務器請求相應的狀態(tài)消息，第三方服務器收到請求后根據(jù)狀態(tài)消息生成的時間從所述數(shù)據(jù)庫中查找并返回離當前最近的狀態(tài)信息；與此同時，所述目標應用數(shù)據(jù)注入單元根據(jù)目標應用名稱向第三方服務器請求相應的應用描述文件；之后，所述目標應用數(shù)據(jù)注入單元根據(jù)狀態(tài)消息中與任務a的名稱匹配的應用描述文件中相應的任務a的數(shù)據(jù)，并獲取該任務a在目的終端的啟動入口，緊接著在目的終端從任務a直接啟動目標應用并將狀態(tài)消息中與該任務a相關的數(shù)據(jù)直接注入、填充到任務a對應的頁面中，從而再現(xiàn)源終端目標應用環(huán)境下的任務a的狀態(tài)；

步驟四、會話的共享：所述目標應用數(shù)據(jù)注入單元從上述狀態(tài)消息中獲取源終端與服務器交互時的會話標記，并當用戶在目的終端的目標應用與服務器繼續(xù)交互時攜帶上上述會話標記，從而實現(xiàn)目的終端共享源終端與服務器的會話，使得用戶在目的終端的目標應用繼續(xù)會話。

與現(xiàn)有技術相比，本發(fā)明的有益效果是：

本發(fā)明通過對http應用的主流架構和應用狀態(tài)進行分析和建模，提出了一種基于會話保持的跨終端應用狀態(tài)遷移方法?？梢苑奖愕貫閼迷黾涌蛇w移特性并通過會話的保持和應用數(shù)據(jù)的自動注入實現(xiàn)應用在不同終端上的自動遷移，實現(xiàn)應用的無縫切換。在此基礎上，用戶只需通過簡單的操作便可實現(xiàn)應用在不同終端間的遷移，有效的提升用戶的交互體驗。

附圖說明

圖1為本發(fā)明所述跨終端應用狀態(tài)遷移方法的總體架構圖；

圖2為本發(fā)明所述跨終端應用狀態(tài)遷移方法的基本構思圖；

圖3為本發(fā)明所述應用在不同終端間切換示意圖；

圖4為本發(fā)明所述demo應用的應用描述片段示意圖；

圖5為本發(fā)明所述demo應用的“票務預訂”案例的跨終端遷移示意圖；

圖6為本發(fā)明所述跨終端遷移應用狀態(tài)時的狀態(tài)消息示意圖；

圖7為本發(fā)明所述oschina應用的“博客閱讀”案例的跨終端遷移示意圖；

圖8為本發(fā)明所述“票務預訂”案例在系統(tǒng)遷移和手工遷移下的全程耗時條形圖；

圖9為本發(fā)明所述“博客閱讀”案例在系統(tǒng)遷移和手工遷移下的全程耗時條形圖；

圖10為本發(fā)明所述“票務預訂”和“博客閱讀”兩個案例在系統(tǒng)遷移方式下比手工遷移方式遷移耗時減少率箱線圖。

具體實施方式

下面結合附圖和具體實施例對本發(fā)明技術方案作進一步詳細描述，所描述的具體實施例僅對本發(fā)明進行解釋說明，并不用以限制本發(fā)明。

如圖1所示，基于會話保持的跨終端應用狀態(tài)遷移方法的總體架構所用的設備包括源終端、目的終端，所述源終端和目的終端的共享服務器，所述源終端的目標應用上安裝有目標應用數(shù)據(jù)捕獲單元，所述目的終端的目標應用上安裝有目標應用數(shù)據(jù)注入單元，所述目標應用數(shù)據(jù)捕獲單元和目標應用數(shù)據(jù)注入單元之間連接有第三方服務器，所述第三方服務器具有一個獨立的數(shù)據(jù)庫。本發(fā)明通過目標應用數(shù)據(jù)捕獲單元、第三方服務器及其連接的數(shù)據(jù)庫和目標應用數(shù)據(jù)注入單元三個組件協(xié)同完成應用狀態(tài)在不同終端間的遷移。

本發(fā)明的核心思想是通過會話數(shù)據(jù)的共享和目標應用數(shù)據(jù)的捕獲/注入來實現(xiàn)應用狀態(tài)的跨終端遷移，如圖2所示。http應用的主流架構是“云-端”架構，即由后臺服務器和前臺終端兩部分構成。無論http應用的實現(xiàn)遵從b/s模式還是c/s模式，其本身都可以看作是一種具有特定表現(xiàn)層的服務?；趆ttp應用的這種架構模式，實現(xiàn)應用從源終端到目的終端的無縫切換關鍵在于兩點：1)目的終端共享源終端與服務器的會話狀態(tài)，2)目的終端重現(xiàn)目標應用在源終端切換時的狀態(tài)，這也是本發(fā)明的主要步驟中的兩個重要的技術實現(xiàn)。

鑒于http協(xié)議的無狀態(tài)性，為了保持源終端與服務器的會話狀態(tài)，http應用常常采用cookie/session機制來實現(xiàn)會話狀態(tài)管理。在源終端與服務器交互過程中，服務器會開辟一塊內存來保存源終端與服務器的會話狀態(tài)并生成一個與源終端相關聯(lián)的會話標記(jessionid)返回給源終端，之后源終端每次訪問服務器時攜帶上這個會話標記就可以訪問其與服務器之前的交互狀態(tài)，從而實現(xiàn)會話狀態(tài)的保持。在本發(fā)明中，目標應用從源終端切換到目的終端后，使目的終端在訪問服務器時攜帶上源終端與服務器交互時的會話標記就可以共享源終端與服務器的會話狀態(tài)。

應用從源終端切換到目的終端后，除了需要共享源終端與服務器的會話狀態(tài)，還需要在目的終端重現(xiàn)目標應用在源終端切換時的狀態(tài)。如圖3所示，目標應用在源終端執(zhí)行到任務2時切換到目的終端，并在目的終端從與源終端任務2對應的任務繼續(xù)執(zhí)行。在這個切換過程中，將捕獲用戶在源終端的任務2中所輸入的數(shù)據(jù)并在切換到目的終端后將這些數(shù)據(jù)注入到目的終端對應的任務中就可以在目的終端重現(xiàn)目標應用在源終端切換時的狀態(tài)。

因此，在本發(fā)明中，通過使目的終端在訪問服務器時攜帶上源終端與服務器會話時的會話標記就可以實現(xiàn)目的終端共享源終端與服務器的會話狀態(tài)；在目標應用從源終端切換到目的終端的過程中，通過捕獲用戶在源終端當前任務中所輸入的數(shù)據(jù)并在切換到目的終端后將這些數(shù)據(jù)注入到目的終端對應的任務中就可以在目的終端重現(xiàn)目標應用在源終端切換時的狀態(tài)?；谏鲜龅膬蓚€重要技術實現(xiàn)，下面結合圖1詳細敘述基于會話保持的跨終端應用狀態(tài)遷移方法的具體實現(xiàn)步驟。

(1)創(chuàng)建并存儲應用描述文件。首先，將預使用的目標應用在源終端和目的終端上根據(jù)其工作流分別劃分為n個一一相互對應的連續(xù)的任務，并將上述n個一一相互對應的連續(xù)的任務描述為一個xml格式的應用描述文件。上述的每個任務都對應于目標應用的若干個頁面，每個任務不但描述了其所對應的頁面中需要用戶輸入的數(shù)據(jù)以及這些數(shù)據(jù)在頁面中對應的位置標識，即頁面的視圖邏輯，而且描述了目標應用從該任務啟動時的入口。在創(chuàng)建目標應用的應用描述文件時，如果目標應用所在的源終端和目的終端是不同類型的終端，那么在源終端和目的終端安裝的就是目標應用的兩個不同的版本，目標應用在源終端和目的終端下的頁面布局和視圖邏輯也就互不相同，這時在應用描述文件中描述目標應用時對目標應用在源終端和目的終端的各版本進行分別描述；如果目標應用所在的源終端和目的終端是相同類型的終端，則在應用描述文件中描述目標應用時對目標應用當前版本進行描述即可。在創(chuàng)建完成應用描述文件后，將該應用描述文件存入第三方服務器對應的數(shù)據(jù)庫中。

(2)目標應用數(shù)據(jù)的捕獲、存儲和會話標記的獲取。用戶在源終端上的目標應用登錄后，所述目標應用數(shù)據(jù)捕獲單元首先會根據(jù)目標應用名稱向第三方服務器請求目標應用的應用描述文件并解析該應用描述文件中對目標應用在源終端的版本的描述來判斷源終端上的目標應用當前正在執(zhí)行的任務，該任務記為任務a。然后，所述目標應用數(shù)據(jù)捕獲單元根據(jù)對應的描述捕獲用戶在任務a中所輸入的數(shù)據(jù)，與此同時，所述目標應用數(shù)據(jù)捕獲單元獲取源終端與服務器交互時的會話標記和源終端在共享服務器中的用戶標記，并將所述的用戶標記、目標應用名稱、會話標記、任務a的名稱及用戶在任務a輸入的數(shù)據(jù)形成一條狀態(tài)消息。然后，所述目標應用數(shù)據(jù)捕獲單元將上述狀態(tài)消息及該狀態(tài)消息生成的時間發(fā)送給第三方服務器并存儲至所述數(shù)據(jù)庫；

(3)目標應用數(shù)據(jù)的注入及任務a的狀態(tài)再現(xiàn)。用戶切換到目的終端上進行應用狀態(tài)恢復時，所述目標應用數(shù)據(jù)注入單元首先根據(jù)用戶標識和目標應用名稱向第三方服務器請求相應的狀態(tài)消息，第三方服務器收到請求后根據(jù)狀態(tài)消息生成的時間從所述數(shù)據(jù)庫中查找并返回離當前最近的狀態(tài)信息。與此同時，所述目標應用數(shù)據(jù)注入單元根據(jù)目標應用名稱向第三方服務器請求相應的應用描述文件，并根據(jù)上述狀態(tài)消息中任務a的名稱匹配并找到應用描述文件中對目標應用在目的終端的版本的描述中對任務a的描述。然后，所述目標應用數(shù)據(jù)注入單元從對任務a的描述中獲取任務a在目的終端的啟動入口并在目的終端從任務a直接啟動目標應用，同時根據(jù)上述描述將上述狀態(tài)消息中與該任務a相關的數(shù)據(jù)直接注入、填充到任務a在目的終端對應的頁面中，從而再現(xiàn)源終端目標應用環(huán)境下的任務a的狀態(tài)。

(4)會話的共享。所述目標應用數(shù)據(jù)注入單元從上述狀態(tài)消息中獲取源終端與服務器交互時的會話標記，并當用戶在目的終端的目標應用與服務器繼續(xù)交互時攜帶上上述會話標記，從而實現(xiàn)目的終端共享源終端與服務器的會話，使得用戶在目的終端的目標應用繼續(xù)會話。

為驗證基于會話保持的跨終端應用狀態(tài)遷移方法的有益效果，選取了兩個案例(“票務預訂”案例和“博客閱讀”案例)進行了實驗。

“票務預訂”案例

在一個類似攜程應用的demo應用上運行的。下面以該demo應用作為目標應用，源終端為web端，目的終端為android端，web端的demo應用安裝的目標應用數(shù)據(jù)捕獲單元和android端的demo應用安裝的目標應用數(shù)據(jù)注入單元分別是一個js函數(shù)庫和一個java軟件包，利用本發(fā)明所述的方法將所述demo應用從web端切換到android端，具體步驟如下：

(1)創(chuàng)建并存儲demo應用的應用描述文件。首先，如圖4所示，將demo應用在web端和android端上根據(jù)其工作流分別劃分為四個一一相互對應的連續(xù)的任務，并將上述四個一一相互對應的連續(xù)的任務描述為一個xml格式的應用描述文件。上述的每個任務都對應于demo應用的1～2個頁面，每個任務不但描述了其所對應的頁面中需要用戶輸入的數(shù)據(jù)以及這些數(shù)據(jù)在頁面中對應的位置標識，即頁面的視圖邏輯，而且描述了目標應用從該任務啟動時的入口。在創(chuàng)建demo應用的應用描述文件時，由于demo應用所在的web端和android端是不同類型的終端，因此demo應用在web端和android端下的頁面布局和視圖邏輯互不相同，這時在應用描述文件中描述demo應用時就對demo應用的web版本和android版本分別進行描述。如圖5所示，第3～55行是demo應用的應用描述文件的一個片段，其描述了demo應用的“用戶登錄”和“票務查詢”兩個任務；第5～28行是demo應用的android版本的描述，第31～54行是demo應用的web版本的描述。在創(chuàng)建完成應用描述文件后，將該應用描述文件存入第三方服務器對應的數(shù)據(jù)庫中。

(2)demo應用數(shù)據(jù)的捕獲、存儲和會話標記的獲取。如圖4所示，用戶在web端上的demo應用登錄并執(zhí)行到“票務查詢”任務時切換到android端對應的“票務查詢”任務并繼續(xù)執(zhí)行后面的任務。在切換時，目標應用數(shù)據(jù)捕獲單元首先會根據(jù)demo應用名稱向第三方服務器請求demo應用的應用描述文件并解析該應用描述文件中對demo應用的web版本的描述來判斷web端上的demo應用當前正在執(zhí)行的任務，即“票務查詢”任務。然后，所述目標應用數(shù)據(jù)捕獲單元根據(jù)對應的描述捕獲用戶在“票務查詢”任務中所輸入的數(shù)據(jù)，與此同時，所述目標應用數(shù)據(jù)捕獲單元獲取web端與服務器交互時的會話標記(即jsessionid)和web端在共享服務器中的用戶標記，并將所述的用戶標記、demo應用名稱、會話標記、“票務查詢”任務的名稱及用戶在“票務查詢”任務中輸入的數(shù)據(jù)形成一條狀態(tài)消息，如圖6所示。然后，所述目標應用數(shù)據(jù)捕獲單元將上述狀態(tài)消息及該狀態(tài)消息生成的時間發(fā)送給第三方服務器并存儲至其對應的數(shù)據(jù)庫中；

(3)目標應用數(shù)據(jù)的注入及“票務查詢”任務的狀態(tài)再現(xiàn)。用戶切換到android端上進行應用狀態(tài)恢復時，目標應用數(shù)據(jù)注入單元首先根據(jù)用戶標識和demo應用名稱向第三方服務器請求相應的狀態(tài)消息，第三方服務器收到請求后根據(jù)狀態(tài)消息生成的時間從所述數(shù)據(jù)庫中查找并返回離當前最近的狀態(tài)信息。與此同時，所述目標應用數(shù)據(jù)注入單元根據(jù)demo應用名稱向第三方服務器請求該demo應用的應用描述文件，并根據(jù)上述狀態(tài)消息中“票務查詢”任務的名稱匹配并找到應用描述文件中對demo應用的android版本的描述中對任務“票務查詢”的描述。然后，所述目標應用數(shù)據(jù)注入單元從對“票務查詢”任務的描述中獲取“票務查詢”任務在android端的啟動入口并在android端從“票務查詢”任務直接啟動demo應用，同時根據(jù)對任務“票務查詢”的描述將上述狀態(tài)消息中與“票務查詢”任務相關的數(shù)據(jù)直接注入、填充到“票務查詢”任務在android端對應的頁面中，從而再現(xiàn)web端demo應用環(huán)境下的“票務查詢”任務的狀態(tài)。

(4)會話的共享。目標應用數(shù)據(jù)注入單元從上述狀態(tài)消息中獲取web端與服務器交互時的會話標記，并當用戶在android端的demo應用繼續(xù)會話時攜帶上該會話標記，實現(xiàn)android端共享web端與服務器的會話狀態(tài)，使得用戶在android端的demo應用上能夠無縫地繼續(xù)執(zhí)行后面的任務，繼續(xù)會話。

“博客閱讀”案例

在oschina(https://www.oschina.net/)應用上運行的。實驗中以該oschina應用作為目標應用，同樣以web端為源終端，以android端為目的終端，web端的demo應用安裝的目標應用數(shù)據(jù)捕獲單元和android端的demo應用安裝的目標應用數(shù)據(jù)注入單元與在“票務預訂”案例中提到的實現(xiàn)完全相同。利用本發(fā)明所述的方法將所述demo應用從web端切換到android端，如圖7所示，oschina應用在web端執(zhí)行到“閱讀博客”任務時切換到android端對應的“閱讀博客”任務并繼續(xù)執(zhí)行。由于oschina應用的切換過程與上面所述的demo應用的切換過程基本類似，不再贅述。

下面比較在使用系統(tǒng)遷移(本發(fā)明所述方法)和手動遷移兩種情況下demo應用的“票務預訂”案例和oschina應用的“博客閱讀”案例的耗時情況。為了保證實驗的客觀性，邀請了16人參與到該實驗中。

首先，參與人員被要求在pc的web端使用瀏覽器去模擬以上兩個案例并使用手動遷移的方式將應用狀態(tài)遷移到android端。然后，在相同條件下，還被要求采用系統(tǒng)遷移的方式將應用狀態(tài)從web端遷移到android端。如圖8和圖9所示，對于以上“票務預訂”和“博客閱讀”兩個案例，使用系統(tǒng)遷移的方式遷移應用狀態(tài)的全程耗時均明顯少于手動遷移情形。在t-test測試中，p-value值為0。實際上，對于demo應用的“票務預訂”案例和oschina應用的“博客閱讀”案例，使用系統(tǒng)遷移方式的總耗時相比使用手工遷移的方式分別減少了大約67.46％和34.09％。這里“票務預訂”案例總耗時減少幅度遠大于“博客閱讀”案例的主要由于案例本身導致的：“博客閱讀”案例中用戶與應用交互較少，特別是用戶需要進行的數(shù)據(jù)輸入操作較少，因此較為省時；“票務預訂”案例中用戶與應用交互較多，而且很多交互操作都需要用戶輸入數(shù)據(jù)，因此較為費時。此外，在系統(tǒng)遷移方式下，以上兩個案例的遷移耗時也都明顯少于手動遷移的情形，如圖10所示。在demo應用的“票務預訂”案例中，手動遷移應用狀態(tài)平均需要63.375s，而系統(tǒng)遷移應用狀態(tài)平均只需要3.75s，時間平均節(jié)省了94.03％；在oschina應用的“博客閱讀”案例中，手動遷移應用狀態(tài)平均需要27s，而系統(tǒng)遷移應用狀態(tài)平均只需要4.375s，時間平均節(jié)省了83.94％。因此，基于會話保持的跨終端應用狀態(tài)遷移方法能夠高效地解決應用在不同終端間的切換問題，有效地提升用戶的交互體驗。

盡管上面結合附圖對本發(fā)明進行了描述，但是本發(fā)明并不局限于上述的具體實施方式，上述的具體實施方式僅僅是示意性的，而不是限制性的，本領域的普通技術人員在本發(fā)明的啟示下，在不脫離本發(fā)明宗旨的情況下，還可以做出很多變形，這些均屬于本發(fā)明的保護之內。