Hybrid App開發(fā)框架的實(shí)現(xiàn)及性能優(yōu)化①

賈軍營(yíng), 張大成,2, 高 春

1(中國(guó)科學(xué)院 沈陽(yáng)計(jì)算技術(shù)研究所，沈陽(yáng) 110168)

2(中國(guó)科學(xué)院大學(xué)，北京 100049)

3(遼寧大學(xué)，沈陽(yáng) 110036)

Hybrid App開發(fā)框架的實(shí)現(xiàn)及性能優(yōu)化①

賈軍營(yíng)1, 張大成1,2, 高 春3

1(中國(guó)科學(xué)院 沈陽(yáng)計(jì)算技術(shù)研究所，沈陽(yáng) 110168)

2(中國(guó)科學(xué)院大學(xué)，北京 100049)

3(遼寧大學(xué)，沈陽(yáng) 110036)

Hybrid App融合了Native開發(fā)和Web開發(fā)的優(yōu)勢(shì), 其開發(fā)方式在移動(dòng)應(yīng)用開發(fā)和桌面應(yīng)用開發(fā)中所占的比重越來(lái)越大. 本文實(shí)現(xiàn)了WebView和Native的雙向通信機(jī)制, 建立了Hybrid App的開發(fā)框架, 并通過(guò)對(duì)Web數(shù)據(jù)進(jìn)行本地離線存儲(chǔ), 對(duì)Web文件采用基于字節(jié)流的差量更新的方式對(duì)框架進(jìn)行優(yōu)化. 最后對(duì)開發(fā)框架和優(yōu)化機(jī)制進(jìn)行了實(shí)際測(cè)試, 采集數(shù)據(jù)并進(jìn)行分析, 實(shí)驗(yàn)結(jié)果表明開發(fā)框架和優(yōu)化機(jī)制具有實(shí)用性和可行性.

Hybrid App; 離線緩存; 差量更新; 優(yōu)化機(jī)制

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

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

1 Hybrid App開發(fā)框架

1.1 在軟件中嵌入WebView

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

1.2 Web和native交互通信機(jī)制

Hybrid App開發(fā)框架的核心是native和Web的交互通信機(jī)制. 通信機(jī)制可以使得WebView中的Web頁(yè)面通過(guò)javascript函數(shù)訪問(wèn)native的中封裝的接口API, 同樣native也可以訪問(wèn)WebView中的javascript接口API.

1.2.1 Native調(diào)用Web

Windows下基于cef的WebView調(diào)用方式如下:

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

Adroid平臺(tái)和IOS平臺(tái)對(duì)于Native調(diào)用Web端的javascript代碼都有很好的原生支持.

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

IOS中的調(diào)用方式如下,

{WebView stringByEvaluatingJavaScriptFromSt

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

1.2.2 Web調(diào)用Native

Windows中CEF可以通過(guò)重寫CefV8Handler接口的方式實(shí)現(xiàn)本地的回調(diào).

Android中可以通過(guò)重寫WebChromeClient.onJsPrompt, onJsConfirm, 或onJsAler來(lái)實(shí)現(xiàn).

IOS中可以通過(guò)監(jiān)控WebView的URL變化實(shí)現(xiàn)Web端調(diào)用Native.

1.3 Web和native通信的Bridge

綜上, 針對(duì)windows, android, ios三個(gè)平臺(tái)分別設(shè)計(jì)三個(gè)通信Bridge[11], 通過(guò)Bridge連接Web端和native端, 實(shí)現(xiàn)Web與Native的雙向通信[5]. Bridge提供四個(gè)接口, 如表1所示, native的原生代碼和Web端的javascript代碼可以通過(guò)這四個(gè)接口進(jìn)行雙向通信, 在通信過(guò)程中, 函數(shù)名和參數(shù)被封裝在JSON字符串中.當(dāng)Web向native發(fā)送請(qǐng)求時(shí), Web端的javascript代碼通過(guò)調(diào)用SendToNative來(lái)向native發(fā)送請(qǐng)求的JSON字符串, native得到請(qǐng)求之后解析JSON串, 得到函數(shù)名和參數(shù), 并執(zhí)行本地響應(yīng)的API操作, 完成后natvie端通過(guò)調(diào)用JsCallback將結(jié)果返回給Web端. Natvie請(qǐng)求Web端的過(guò)程相類似. Web和Native通過(guò)Bridge進(jìn)行通信的時(shí)序圖如圖1所示.

表1 Bridge的四個(gè)函數(shù)接口

圖1 Web和native雙向通信機(jī)制

2 數(shù)據(jù)離線存儲(chǔ)機(jī)制

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

離線數(shù)據(jù)以key/value鍵值對(duì)的形式進(jìn)行存儲(chǔ), 為了實(shí)現(xiàn)這樣的功能, 設(shè)計(jì)八個(gè)接口, 如表2所示. 同時(shí),在native端封裝對(duì)數(shù)據(jù)庫(kù)的操作, 當(dāng)Web端將數(shù)據(jù)通過(guò)json傳遞到本地后, native解析出key/value, 并將其寫入數(shù)據(jù)庫(kù). 以存儲(chǔ)離線數(shù)據(jù)接口CacheStore為例, Web側(cè)實(shí)現(xiàn)如下代碼即可實(shí)現(xiàn)存儲(chǔ)數(shù)據(jù)的功能:

表2 離線存儲(chǔ)的八個(gè)接口

3 Web文件差量更新機(jī)制

3.1 Rsync算法

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

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

3) 機(jī)器A將校驗(yàn)和序列發(fā)送給機(jī)器B.

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

5) 機(jī)器B從Fnew第一個(gè)字節(jié)開始, 通過(guò)三級(jí)匹配機(jī)制進(jìn)行檢索[10], 依次計(jì)算長(zhǎng)度為S字節(jié)的塊的32位滾動(dòng)若校驗(yàn)和并映射為16位的哈希值, 如果哈希值對(duì)應(yīng)的哈希表項(xiàng)非空, 且在Fold生成的哈希字典對(duì)應(yīng)的列表項(xiàng)存在相同的弱校驗(yàn)和, 則再比較MD5強(qiáng)校驗(yàn)和, 如果相等, 則認(rèn)為找到了匹配塊.

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

7) 如果某個(gè)位置開始沒有找到匹配, 就會(huì)前進(jìn)一個(gè)字節(jié), 跳轉(zhuǎn)步驟5繼續(xù)搜索匹配的塊.

8) 如果Fnew整個(gè)文件搜索完畢, 機(jī)器B將差量信息發(fā)送給機(jī)器A.

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

3.2 算法的重要細(xì)節(jié)

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

3.3 對(duì)rsync算法進(jìn)行改進(jìn):

由于Rsync算法用于同步兩臺(tái)機(jī)器中的一個(gè)文件.本文對(duì)Rsync算法從兩個(gè)方面進(jìn)行進(jìn)行改進(jìn).

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

2) 由于Web文件為多個(gè)文件, 為了對(duì)不同版本的多個(gè)Web文件進(jìn)行管理, 引入版本號(hào)機(jī)制. 將同一時(shí)間的多個(gè)文件設(shè)定為相同版本.

當(dāng)某個(gè)或者多個(gè)Web文件被修改, Web文件版本號(hào)增1, 并對(duì)過(guò)去版本的Web文件在服務(wù)器端生成對(duì)應(yīng)版本的差量更新文件deltaXtoY, 其中X為低版本號(hào), Y為高版本號(hào), deltaXtoY包括更新文件列表和每個(gè)列表項(xiàng)對(duì)應(yīng)的文件的增量更新信息, 文件列表對(duì)應(yīng)全部的Web文件, 每個(gè)列表項(xiàng)對(duì)應(yīng)一個(gè)Web文件. 服務(wù)器端生成每個(gè)列表項(xiàng)的增量信息的過(guò)程如圖2所示.

圖2 生成每個(gè)列表項(xiàng)的增量信息的過(guò)程

當(dāng)客戶端啟動(dòng), 獲取最新的Web文件版本號(hào), 檢測(cè)自己當(dāng)前版本是否為最新, 如果不是, 則下載對(duì)應(yīng)的差量更新包, 得到差量deltaXtoY后與本地的低版本的Web文件一起生成最新版本的Web文件. 當(dāng)服務(wù)器沒有對(duì)應(yīng)版本的差量更新包, 則進(jìn)行全量更新. 對(duì)于每個(gè)文件的增量更新過(guò)程如圖3所示. 舊文件根據(jù)對(duì)應(yīng)的差量更新列表項(xiàng)的差量信息, 生成新的文件, 合并過(guò)程會(huì)讀取增量更新信息中的索引信息和數(shù)據(jù)信息, 并將根據(jù)索引信息在Fold中提取數(shù)據(jù)塊, 生成新文件的JavaScipt代碼如下:

圖3 客戶端差量更新過(guò)程

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

表3 舊版本數(shù)據(jù)分塊

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

4 測(cè)試及結(jié)果分析

4.1 測(cè)試Hybrid開發(fā)框架

在Hybrid開發(fā)框架的基礎(chǔ)上, 將軟件的界面設(shè)計(jì)通過(guò)Web方式實(shí)現(xiàn), 三個(gè)平臺(tái)的應(yīng)用采用一套Web文件進(jìn)行描述, 實(shí)現(xiàn)了軟件界面的集中開發(fā)和集中調(diào)試, 軟件界面如圖4和圖5所示. 當(dāng)用用戶通過(guò)語(yǔ)音通話界面和消息發(fā)送界面與應(yīng)用交互, Web端會(huì)調(diào)用Native的業(yè)務(wù)邏輯, 本地在執(zhí)行業(yè)務(wù)邏輯的過(guò)程中實(shí)時(shí)的將狀態(tài)回調(diào)給WebView, WebView更新界面. 同時(shí)客戶端中將通話記錄進(jìn)行緩存, 每次從本地加載通話記錄, 如圖6所示.

表4 新版本數(shù)據(jù)分塊

圖4 PC端軟件界面

4.2 測(cè)試離線緩存機(jī)制[12]

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

圖5 Android端軟件界面

圖6 通話記錄界面

圖7 數(shù)據(jù)的不同獲取方式的獲取時(shí)間對(duì)比

表5 數(shù)據(jù)的獲取時(shí)間

4.3 測(cè)試差量更新機(jī)制

通過(guò)對(duì)服務(wù)器端test.js進(jìn)行10次修改, 產(chǎn)生了10個(gè)不同的版本. 每次的具體修改信息如表格所示. 全量更新所需的傳輸流量為新文件大小, 差量更新為差量信息包的大小, 服務(wù)器端rsync算法劃分?jǐn)?shù)據(jù)塊的大小為700字節(jié). 則每次傳輸?shù)臄?shù)據(jù)量如圖7所示. 橫軸表示文件的版本, 縱軸標(biāo)識(shí)需要傳輸?shù)臄?shù)據(jù)大小. 如圖8所示,位于上方的折線標(biāo)識(shí)每次全量更新需要傳輸?shù)淖止?jié),位于下方的折線標(biāo)識(shí)差量更新需要傳輸?shù)淖止?jié). 可以通過(guò)分析得出如下趨勢(shì): 增量信息包的大小與修改文件的位置, 修改文件的內(nèi)容, 塊劃分大小有一定的關(guān)系,比如增加已有的內(nèi)容, 增量信息包體積小一些, 因?yàn)樾挛募械臄?shù)據(jù)塊會(huì)在舊文件中的數(shù)據(jù)塊中找到匹配.通過(guò)10次信息對(duì)比, 每次增量包的大小基本都與全量數(shù)據(jù)大小相差100倍. 相對(duì)全量更新節(jié)省99%的流量消耗, 同時(shí)提高傳輸時(shí)間.

圖8 Web文件全量更新和差量更新需要傳輸?shù)臄?shù)據(jù)量對(duì)比

表6 test.js的各個(gè)版本的具體信息

5 結(jié)束語(yǔ)

本文通過(guò)設(shè)計(jì)Hybrid開發(fā)框架, 屏蔽了各終端的差異, 將客戶端中的原生界面設(shè)計(jì)工作轉(zhuǎn)移到Web界面的設(shè)計(jì), 提高了開發(fā)效率. 同時(shí)對(duì)Hybrid開發(fā)框架進(jìn)行優(yōu)化, 提高了Hybrid應(yīng)用的頁(yè)面加載速度, 節(jié)省了帶寬. 綜上, 本文設(shè)計(jì)的Hybrid開發(fā)框架具有實(shí)用性和可行性, 同時(shí)優(yōu)化方案對(duì)其他Hybrid開發(fā)方案具有一定的參考價(jià)值.

1顧學(xué)海, 胡牧, 蔣厚明, 等. 基于HTML5的混合移動(dòng)應(yīng)用開發(fā). 計(jì)算機(jī)系統(tǒng)應(yīng)用, 2016, 25(5): 236–239.

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

3李張永, 陳和平, 顧進(jìn)廣. 跨平臺(tái)移動(dòng)Web開發(fā)框架與數(shù)據(jù)交互方法. 計(jì)算機(jī)工程與設(shè)計(jì), 2014, 35(5): 1827–1832.

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

5施偉, 王碩蘋, 郭鳴, 等. 跨平臺(tái)移動(dòng)應(yīng)用中間適配層設(shè)計(jì)與實(shí)現(xiàn). 計(jì)算機(jī)工程與應(yīng)用, 2014, 50(16): 39–44. [doi: 10.3778/j.issn.1002-8331.1208-0481]

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

7童麗霞, 何加銘, 陳懇, 等. 基于HTML5技術(shù)的Widget引擎內(nèi)容緩存模型及實(shí)現(xiàn). 計(jì)算機(jī)應(yīng)用研究, 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. 北京: 電子工業(yè)出版社, 2014.

12羅圣美, 王蔚, 任文慧. 兩種移動(dòng)應(yīng)用開發(fā)框架的性能測(cè)試比較——基于PhoneGap和Titanium. 中興通訊技術(shù), 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

賈軍營(yíng),張大成,高春.Hybrid App開發(fā)框架的實(shí)現(xiàn)及性能優(yōu)化.計(jì)算機(jī)系統(tǒng)應(yīng)用,2017,26(7):130–136. http://www.c-s-a.org.cn/1003-3254/5839.html

2016-11-01; 收到修改稿時(shí)間: 2017-01-04