Hybrid App開發框架的實現及性能優化①

賈軍營, 張大成,2, 高 春

1(中國科學院 沈陽計算技術研究所，沈陽 110168)

2(中國科學院大學，北京 100049)

3(遼寧大學，沈陽 110036)

Hybrid App開發框架的實現及性能優化①

賈軍營1, 張大成1,2, 高 春3

1(中國科學院 沈陽計算技術研究所，沈陽 110168)

2(中國科學院大學，北京 100049)

3(遼寧大學，沈陽 110036)

Hybrid App融合了Native開發和Web開發的優勢, 其開發方式在移動應用開發和桌面應用開發中所占的比重越來越大. 本文實現了WebView和Native的雙向通信機制, 建立了Hybrid App的開發框架, 并通過對Web數據進行本地離線存儲, 對Web文件采用基于字節流的差量更新的方式對框架進行優化. 最后對開發框架和優化機制進行了實際測試, 采集數據并進行分析, 實驗結果表明開發框架和優化機制具有實用性和可行性.

Hybrid App; 離線緩存; 差量更新; 優化機制

Hybrid App兼具Web App跨平臺的優勢和Native原生應用擁有良好的交互體驗的優勢. 目前Hybrid App開發方式有兩類, 第一類通過第三方中間件平臺實現, 比如借助PhoneGap或者Ionic[1,2]. 第二類是在移動端或者PC端軟件中嵌入一個或者多個WebView, 并實現WebView和Native的雙向通信, 使得WebView具有訪問本地硬件和本地代碼的能力, 同時Native也具有訪問WebView中JavaScript代碼的能力. 本文實現的Hybrid App框架和優化方案基于課題組的融合通信項目, 該項目具有Andorid, IOS和Windows三個終端. 為了提高各終端開發效率, 在已有框架基礎上引入Hybrid App開發方式, 最終使得三個終端的界面用一套Web文件來展現. 由于在PhoneGap等平臺中提供了大量的本地能力封裝機制, 既增加軟件的復雜度, 又降低了引入后軟件的效率, 而在融合通信系統Web和Native交互的過程中,Native提供的API主要由融合通信系統中已經成熟的業務邏輯模塊提供, 所以在項目改進過程中只需實現一個輕量級的Hybrid App框架[3,4], 而不需要引入第三方平臺.

正文中首先介紹了Native和WebView的雙向交互機制, 在此基礎上實現了Hybrid開發基本框架, 并針對該框架設計和實現了優化方案, 最后對框架和優化方案進行測試. 在設計優化機制的過程中參考了HTML5技術. 目前HTML5的manifest機制提供了Web文件的離線訪問, HTML5的Localstorage機制提供了數據緩存的功能. 但其均存在不足, 當Web文件被改改動, manifest發生改變, 其中所有定義的緩存文件全部重新以全量的方式獲取, 消耗流量, 而且控制不夠靈活. Localstorage提供了非常易用的API, 通過setItem,getItem, removeItem, clear四個接口可以實現數據離線存儲, 但是按照目前標準, 存儲空間太小, 瀏覽器只給每個獨立的域名提供5M的存儲空間. 雖然HTML5還提供了Web SQL Database, 它擁有一套使用SQL語句操作客戶端數據庫的API, 在本地建立輕量級的數據庫, 但此規范工作已經停止. 綜上, 借鑒manifest和Localstorage機制, 利用Hybrid app的Native端的優勢, 在Hybrid App開發框架的基礎上設計了一套數據離線緩存和Web文件增量更新方案, 提高了hybrid App應用的性能和效率.

1 Hybrid App開發框架

1.1 在軟件中嵌入WebView

Hybrid App開發框架需要引入WebView層. Chromium Embedded Framework (CEF)是基于Google Chromium項目實現的一個Web控件, 下面以Windows端嵌入CEF為例. 首先設計一個CWebClient類, 這個類主要完成對瀏覽器事件的回調處理. 該類需要繼承CefClient和各種消息處理接口, 消息處理主要包括CefKeyboardHandler類提供的鍵盤輸入相關的回調處理, CefLoadHandler提供的瀏覽器頁面加載狀態的回調處理, CefFocusHandler提供的焦點相關的回調處理,CefLifeSpanHandler提供的頁面周期回調接口等. 然后將CWebClient類對象作為參數傳入CefBrowser::Create Browser生成CEF實例并顯示. 瀏覽器創建后, CefBrowser類用于對WebView進行控制, CefBrowser對象可以在cef窗口創建完成后由CefLifeSpanHandler接口中的OnAfterCreated函數的參數中獲取.

1.2 Web和native交互通信機制

Hybrid App開發框架的核心是native和Web的交互通信機制. 通信機制可以使得WebView中的Web頁面通過javascript函數訪問native的中封裝的接口API, 同樣native也可以訪問WebView中的javascript接口API.

1.2.1 Native調用Web

Windows下基于cef的WebView調用方式如下:

frame-＞ExecuteJavaScript(“alert(‘ok’)”, “”, 0); 其中frame為CefFrame實例. CefFrame實例可以通過CefBrowser對象實例獲取.

Adroid平臺和IOS平臺對于Native調用Web端的javascript代碼都有很好的原生支持.

Adroid中調用的方式如下, WebView.loadUrl("javascript:(function(){alert('ok');})()");其中Webview是WebView的實例.

IOS中的調用方式如下,

{WebView stringByEvaluatingJavaScriptFromSt

ring: @"alert('ok')"};其中WebView是UIWebview的實例.

1.2.2 Web調用Native

Windows中CEF可以通過重寫CefV8Handler接口的方式實現本地的回調.

Android中可以通過重寫WebChromeClient.onJsPrompt, onJsConfirm, 或onJsAler來實現.

IOS中可以通過監控WebView的URL變化實現Web端調用Native.

1.3 Web和native通信的Bridge

綜上, 針對windows, android, ios三個平臺分別設計三個通信Bridge[11], 通過Bridge連接Web端和native端, 實現Web與Native的雙向通信[5]. Bridge提供四個接口, 如表1所示, native的原生代碼和Web端的javascript代碼可以通過這四個接口進行雙向通信, 在通信過程中, 函數名和參數被封裝在JSON字符串中.當Web向native發送請求時, Web端的javascript代碼通過調用SendToNative來向native發送請求的JSON字符串, native得到請求之后解析JSON串, 得到函數名和參數, 并執行本地響應的API操作, 完成后natvie端通過調用JsCallback將結果返回給Web端. Natvie請求Web端的過程相類似. Web和Native通過Bridge進行通信的時序圖如圖1所示.

表1 Bridge的四個函數接口

圖1 Web和native雙向通信機制

2 數據離線存儲機制

通訊錄信息, 群組成員信息, 通話記錄等信息的獲取會增加帶寬開銷, 為了節省帶寬, 可以將以上數據進行本地緩存[7]. 基于Web和native通信, 可以實現以上功能.

離線數據以key/value鍵值對的形式進行存儲, 為了實現這樣的功能, 設計八個接口, 如表2所示. 同時,在native端封裝對數據庫的操作, 當Web端將數據通過json傳遞到本地后, native解析出key/value, 并將其寫入數據庫. 以存儲離線數據接口CacheStore為例, Web側實現如下代碼即可實現存儲數據的功能:

表2 離線存儲的八個接口

3 Web文件差量更新機制

3.1 Rsync算法

Web文件主要包括html, css, javascript文件, 為了節省帶寬, 提高加載速度, 將這些文件進行離線存儲, 當Web文件發生改變時, 采用差量更新的方式去得到新文件. 本文實現的Web文件差量更新機制基于rsync算法[6-8], 該同步算法可以將兩臺計算機中的內容不同的文件進行同步, 使之相同. 使用此算法的原因在于其滾動校驗和及三級匹配校驗和機制能保證在服務器端快速的生成差量信息包. Rsync算法的主要流程是: 機器A將Old文件分塊并計算校驗和序列, 將序列發送給機器B, 機器B通過New文件和A發送過來的校驗和序列,產生差異包, 再將差異信息包發回給A, A通過差異信息包和Old文件生成New文件. 機器A和機器B進行文件同步主要步驟如下[9]:

1) 機器A將文件Fold進行分割, 得到一系列的字節塊Bi, 假設塊大小為m節. 則Bi=Fold[im, (i+1)m-1], 其中最后一個塊可能會小于m個字節.

3) 機器A將校驗和序列發送給機器B.

4) 機器B建立一個哈希值為16位, 表長度為2^16的哈希表. 將每個塊生成的校驗序列(Ui, Ri)插入到哈希表中, 其中每個塊的Ri映射為16位并作為主鍵. 此時哈希表中的每一項指向的是擁有相同hash值的校驗和列表的第一個元素.

5) 機器B從Fnew第一個字節開始, 通過三級匹配機制進行檢索[10], 依次計算長度為S字節的塊的32位滾動若校驗和并映射為16位的哈希值, 如果哈希值對應的哈希表項非空, 且在Fold生成的哈希字典對應的列表項存在相同的弱校驗和, 則再比較MD5強校驗和, 如果相等, 則認為找到了匹配塊.

6) 如果找到了匹配塊, 差量信息字段中將插入兩部分內容, 第一部分為上一次匹配位置和當前位置之間的未匹配的數據內容, 第二部分為當前匹配成功的b塊的索引信息. 跳轉步驟5, 搜索匹配塊的工作會從當前匹配塊重新啟動.

7) 如果某個位置開始沒有找到匹配, 就會前進一個字節, 跳轉步驟5繼續搜索匹配的塊.

8) 如果Fnew整個文件搜索完畢, 機器B將差量信息發送給機器A.

9) 機器A根據差量信息和Fold生成Fnew.

3.2 算法的重要細節

在rsync算法中使用的弱滾動校驗和算法基于Mark Adler的Adler32校驗算法: 此算法根據的校驗和和X1, Xn+1的字節流值可以簡單快速地計算出的校驗和. 校驗算法如公式(1)(2)(3)所示.

3.3 對rsync算法進行改進:

由于Rsync算法用于同步兩臺機器中的一個文件.本文對Rsync算法從兩個方面進行進行改進.

1) 由于服務器端保存著與客戶端相同的舊版本文件, 所以在服務器端分割舊版本文件并生成校驗和序列, 這樣避免了客戶端計算和傳輸校驗和序列的開銷.

2) 由于Web文件為多個文件, 為了對不同版本的多個Web文件進行管理, 引入版本號機制. 將同一時間的多個文件設定為相同版本.

當某個或者多個Web文件被修改, Web文件版本號增1, 并對過去版本的Web文件在服務器端生成對應版本的差量更新文件deltaXtoY, 其中X為低版本號, Y為高版本號, deltaXtoY包括更新文件列表和每個列表項對應的文件的增量更新信息, 文件列表對應全部的Web文件, 每個列表項對應一個Web文件. 服務器端生成每個列表項的增量信息的過程如圖2所示.

圖2 生成每個列表項的增量信息的過程

當客戶端啟動, 獲取最新的Web文件版本號, 檢測自己當前版本是否為最新, 如果不是, 則下載對應的差量更新包, 得到差量deltaXtoY后與本地的低版本的Web文件一起生成最新版本的Web文件. 當服務器沒有對應版本的差量更新包, 則進行全量更新. 對于每個文件的增量更新過程如圖3所示. 舊文件根據對應的差量更新列表項的差量信息, 生成新的文件, 合并過程會讀取增量更新信息中的索引信息和數據信息, 并將根據索引信息在Fold中提取數據塊, 生成新文件的JavaScipt代碼如下:

圖3 客戶端差量更新過程

假設服務器Web文件版本為6, 其中有一個js文件test.js, 其僅有一行數據if(jsonObj.hisTag == ‘end’), 將這行數據修改為if(jsonObj.hisTag != ‘end’). 設塊長度為4, 則對文件版本6可以分為6塊, 如表3所示.

表3 舊版本數據分塊

在服務器端, 通過對test.js, 進行三級匹配機制查找, 最終增量文件表示為數組: [1, 2, 3, “ag !=”, 5, 6], 對應的數據塊如表4所示. 進一步簡化, 可用一個數組表示為[[1, 3], “ag !=”, [5, 2]]. 由于只有這一個文件被修改, 最終得到的差量信息delta6to7中的文件列表只有一項, 這一項的文件名為test.js, 對應文件的差量信息為[[1, 3], “ag !=”, [5, 2]]. 在客戶端, 假設當前Web文件版本為6, 則獲取到delta6to7更新信息, 通過與test.js合并,從test.js就文件中提取出block1, block2, block3, block5,block6, 5個數據塊, 并與新數據“ag !=”合并, 得到新的test.js為: block1+block2+block3+“ag !=”+block5+block6.

4 測試及結果分析

4.1 測試Hybrid開發框架

在Hybrid開發框架的基礎上, 將軟件的界面設計通過Web方式實現, 三個平臺的應用采用一套Web文件進行描述, 實現了軟件界面的集中開發和集中調試, 軟件界面如圖4和圖5所示. 當用用戶通過語音通話界面和消息發送界面與應用交互, Web端會調用Native的業務邏輯, 本地在執行業務邏輯的過程中實時的將狀態回調給WebView, WebView更新界面. 同時客戶端中將通話記錄進行緩存, 每次從本地加載通話記錄, 如圖6所示.

表4 新版本數據分塊

圖4 PC端軟件界面

4.2 測試離線緩存機制[12]

本地緩存主要節省了客戶端與服務器建立連接和傳輸數據的時間, 試驗中在帶寬為200KB/s的帶寬環境下采集了13次數據, 每次分別從本地和服務器重復三次獲取相同字節大小的數據, 獲取時間時為從發起請求到數據接收完畢, 單位為毫秒, 計算平均時間并記錄.其中從服務器獲取數據通過jquery的AJAX方法獲取信息流, 服務器端采用mysql數據庫, 客戶端緩存數據從sqlite數據庫中讀取. 實驗數據中可以分析出以下趨勢:如圖7所示, 從服務器獲取數據需要一定建立連接的時間, 隨著獲取數據量的增多, 獲取時間逐漸受到網速的限制, 同時網絡狀況也會影響獲取數據的時間. 從本地數據庫獲取數據所需的時間基本是隨著數據量增多,呈線性增長的, 相比服務器時間更短.

圖5 Android端軟件界面

圖6 通話記錄界面

圖7 數據的不同獲取方式的獲取時間對比

表5 數據的獲取時間

4.3 測試差量更新機制

通過對服務器端test.js進行10次修改, 產生了10個不同的版本. 每次的具體修改信息如表格所示. 全量更新所需的傳輸流量為新文件大小, 差量更新為差量信息包的大小, 服務器端rsync算法劃分數據塊的大小為700字節. 則每次傳輸的數據量如圖7所示. 橫軸表示文件的版本, 縱軸標識需要傳輸的數據大小. 如圖8所示,位于上方的折線標識每次全量更新需要傳輸的字節,位于下方的折線標識差量更新需要傳輸的字節. 可以通過分析得出如下趨勢: 增量信息包的大小與修改文件的位置, 修改文件的內容, 塊劃分大小有一定的關系,比如增加已有的內容, 增量信息包體積小一些, 因為新文件中的數據塊會在舊文件中的數據塊中找到匹配.通過10次信息對比, 每次增量包的大小基本都與全量數據大小相差100倍. 相對全量更新節省99%的流量消耗, 同時提高傳輸時間.

圖8 Web文件全量更新和差量更新需要傳輸的數據量對比

表6 test.js的各個版本的具體信息

5 結束語

本文通過設計Hybrid開發框架, 屏蔽了各終端的差異, 將客戶端中的原生界面設計工作轉移到Web界面的設計, 提高了開發效率. 同時對Hybrid開發框架進行優化, 提高了Hybrid應用的頁面加載速度, 節省了帶寬. 綜上, 本文設計的Hybrid開發框架具有實用性和可行性, 同時優化方案對其他Hybrid開發方案具有一定的參考價值.

1顧學海, 胡牧, 蔣厚明, 等. 基于HTML5的混合移動應用開發. 計算機系統應用, 2016, 25(5): 236–239.

2潘春華, 李俊杰, 向花, 等. 基于PhoneGap的智能手機跨平臺應用. 計算機系統應用, 2014, 23(7): 106–109.

3李張永, 陳和平, 顧進廣. 跨平臺移動Web開發框架與數據交互方法. 計算機工程與設計, 2014, 35(5): 1827–1832.

4徐隆龍, 李瑩, 白靜. 移動混合開發框架. 計算機系統應用,2014, 23(12): 53–59. [doi: 10.3969/j.issn.1003-3254.2014.12.009]

5施偉, 王碩蘋, 郭鳴, 等. 跨平臺移動應用中間適配層設計與實現. 計算機工程與應用, 2014, 50(16): 39–44. [doi: 10.3778/j.issn.1002-8331.1208-0481]

6呂瀛, 劉杰, 馬志柔, 等. 一種云存儲服務客戶端增量同步算法. 計算機系統應用, 2014, 23(10): 152–157. [doi: 10.3969/j.issn.1003-3254.2014.10.026]

7童麗霞, 何加銘, 陳懇, 等. 基于HTML5技術的Widget引擎內容緩存模型及實現. 計算機應用研究, 2011, 28(12):4625–4628. [doi: 10.3969/j.issn.1001-3695.2011.12.058]

8Tridgell A, Mackerras P. The rsync algorithm. Canberra,Australia: Australian National University, 1996.

9Irmak U, Mihaylov S, Suel T. Improved single-round protocols for remote file synchronization. Proc. IEEE 24th Annual Joint Conference of the IEEE Computer and Communications Societies. Miami, FL, USA. 2005.1665–1676.

10Gupta D, Sagar K. Remote file synchronization single-round algorithms. International Journal of Computer Applications,2010, 4(1): 32–36. [doi: 10.5120/ijca]

11徐凱. 跨終端Web. 北京: 電子工業出版社, 2014.

12羅圣美, 王蔚, 任文慧. 兩種移動應用開發框架的性能測試比較——基于PhoneGap和Titanium. 中興通訊技術, 2013,19(3): 44–47.

Implementation and Performance Optimization of Hybrid App Development Framework

JIA Jun-Ying1, ZHANG Da-Cheng1,2, GAO Chun3

1(Shenyang Institute of Computing Technology, Chinese Academy of Sciences, Shenyang 110168, China)
2(University of Chinese Academy of Sciences, Beijing 100049, China)
3(Liaoning University, Shenyang 110036, China)

The Hybrid App combines the advantages of Native development and Web development, which takes more and more proportions in the mobile application development and desktop application development. This paper realizes bidirectional communication mechanism between WebView and Native, set up development framework for Hybrid App,and optimizes the performance of Hybrid App by means of off-line storage for Web data and delta update based on byte stream for Web files. Finally, the development framework and optimization mechanism are actually tested and the collected data are analyzed, and the experimental results reveal that development framework and optimization mechanism have good feasibility and practicability.

Hybrid App; offline cache; delta update; optimization mechanism

賈軍營,張大成,高春.Hybrid App開發框架的實現及性能優化.計算機系統應用,2017,26(7):130–136. http://www.c-s-a.org.cn/1003-3254/5839.html

2016-11-01; 收到修改稿時間: 2017-01-04