施偉，王碩蘋，郭鳴，吳明暉，梁鵬

1.浙江大學(xué)計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院，杭州 310027

2.浙江大學(xué)城市學(xué)院計(jì)算機(jī)與計(jì)算科學(xué)學(xué)院，杭州 310015

3.中國(guó)人民解放軍91199部隊(duì)

4.中國(guó)人民解放軍94936部隊(duì)

跨平臺(tái)移動(dòng)應(yīng)用中間適配層設(shè)計(jì)與實(shí)現(xiàn)

施偉1，3，王碩蘋2，郭鳴2，吳明暉2，梁鵬1，4

1.浙江大學(xué)計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院，杭州 310027

2.浙江大學(xué)城市學(xué)院計(jì)算機(jī)與計(jì)算科學(xué)學(xué)院，杭州 310015

3.中國(guó)人民解放軍91199部隊(duì)

4.中國(guó)人民解放軍94936部隊(duì)

由于當(dāng)前主流的移動(dòng)開發(fā)平臺(tái)之間互不兼容，造成應(yīng)用開發(fā)各種資源的浪費(fèi)。為了解決各個(gè)平臺(tái)應(yīng)用開發(fā)的不兼容問(wèn)題，提出在移動(dòng)平臺(tái)操作系統(tǒng)層和應(yīng)用層之間添加中間適配層的方案。中間適配層通過(guò)對(duì)以Webkit為核心的瀏覽器進(jìn)行封裝和擴(kuò)展，支持跨平臺(tái)的移動(dòng)應(yīng)用開發(fā)，對(duì)不同平臺(tái)移動(dòng)終端的本地資源訪問(wèn)也有較好的支持。該中間適配層具有良好的通用性和擴(kuò)展性，并已在多個(gè)平臺(tái)進(jìn)行仿真實(shí)驗(yàn)驗(yàn)證了方案的可行性和實(shí)用性。

跨平臺(tái)；移動(dòng)應(yīng)用；中間層；HTM L5

1 引言

隨著3G網(wǎng)絡(luò)技術(shù)和移動(dòng)互聯(lián)網(wǎng)的快速發(fā)展，移動(dòng)終端已經(jīng)由功能性向智能性轉(zhuǎn)變。Canalys 2012年2月數(shù)據(jù)顯示，全球50.1%的智能終端搭載了Android系統(tǒng)，下面依次是iOS和BlackBerry，分別占據(jù)了較大的市場(chǎng)份額，如表1所示。因此要想獲得更多的用戶，選擇單一平臺(tái)來(lái)開發(fā)和發(fā)布的終端應(yīng)用不再是一個(gè)可行的選擇。

每個(gè)平臺(tái)通常具有其自己的軟件開發(fā)工具包和語(yǔ)言或支持的語(yǔ)言，見表2所示。由于當(dāng)前主流的移動(dòng)平臺(tái)之間互不兼容，針對(duì)不同的移動(dòng)平臺(tái)系統(tǒng)，當(dāng)前并沒(méi)有可以兼容的應(yīng)用開發(fā)接口和語(yǔ)言。一個(gè)平臺(tái)開發(fā)的應(yīng)用程序不會(huì)輕易轉(zhuǎn)化到另一個(gè)平臺(tái)。

表1 2012年2月各平臺(tái)市場(chǎng)份額[1]

表2 平臺(tái)開發(fā)需要的語(yǔ)言[2]

原生應(yīng)用程序通過(guò)訪問(wèn)設(shè)備的API和框架，從而使設(shè)備的功能得到最佳發(fā)揮。但需要使用該設(shè)備的硬件和軟件的開發(fā)人員更加專業(yè)化，以獲得最大的用戶體驗(yàn)，因此為每個(gè)平臺(tái)開發(fā)原生應(yīng)用的代價(jià)更為昂貴。

為了解決各個(gè)平臺(tái)應(yīng)用開發(fā)的不兼容問(wèn)題，一種替代方案就是嘗試在不同設(shè)備的應(yīng)用層之間的抽象共性。例如，所有的智能終端有一個(gè)Web瀏覽器。移動(dòng)Web應(yīng)用程序可以是一種方法。另一種方法是使用一個(gè)框架，可以在應(yīng)用程序中嵌入設(shè)備的瀏覽器，并提供應(yīng)用程序編程接口（API），允許Web代碼和設(shè)備硬件交互的一種混合方法。

移動(dòng)Web應(yīng)用程序，特別是那些利用HTM L5的特性來(lái)編寫移動(dòng)應(yīng)用程序是很有潛力的。例如，移動(dòng)Web應(yīng)用程序易安裝、分布性良好，開發(fā)人員的支持[3]。HTM L5 API包括聯(lián)機(jī)和脫機(jī)模式下與應(yīng)用程序進(jìn)行交互的能力，開發(fā)人員可以使用智能終端上的音頻、視頻和有限的設(shè)備傳感器比如GPS等數(shù)據(jù)。但是，移動(dòng)Web應(yīng)用也存在劣勢(shì)。比如對(duì)沒(méi)有定位傳感器裝置終端的支持非常有限。對(duì)內(nèi)容捕獲的攝像頭和麥克風(fēng)的支持也是很有限的。在一些本地資源的使用方面，Web應(yīng)用的用戶體驗(yàn)不及原生應(yīng)用程序那么良好。

本文結(jié)合國(guó)家科技重大專項(xiàng)課題（移動(dòng)互聯(lián)網(wǎng)智能終端應(yīng)用中間件開發(fā)）的研究，將原生應(yīng)用和Web應(yīng)用開發(fā)的優(yōu)勢(shì)結(jié)合起來(lái)，提出了基于瀏覽器作為中間層的跨平臺(tái)智能終端應(yīng)用設(shè)計(jì)方案。本文分析其設(shè)計(jì)原理和實(shí)現(xiàn)技術(shù)，給出符合W 3C標(biāo)準(zhǔn)的、統(tǒng)一的API。然后使用HTM L5、CSS和JavaScript開發(fā)應(yīng)用程序并在不同平臺(tái)進(jìn)行仿真實(shí)驗(yàn)來(lái)驗(yàn)證方案的可行性和實(shí)際效果。

2 相關(guān)工作

隨著人們對(duì)跨平臺(tái)應(yīng)用開發(fā)研究的不斷深入，目前主要有以下相關(guān)研究。文獻(xiàn)[4]指出對(duì)于移動(dòng)開發(fā)者來(lái)說(shuō)很難找到最合適的開發(fā)平臺(tái)，分析Android、iPhone、Qt的關(guān)鍵開發(fā)技術(shù)，重要的共同點(diǎn)和差異，但沒(méi)有解決跨平臺(tái)的問(wèn)題。解決跨平臺(tái)的一種方案就是嘗試在不同設(shè)備的應(yīng)用層之間的抽象共性。比如文獻(xiàn)[5]提出了一種通用的平臺(tái)，此平臺(tái)需要一臺(tái)互聯(lián)網(wǎng)服務(wù)器通過(guò)一個(gè)特定的XM L文檔保持與智能手機(jī)的連接。每個(gè)智能手機(jī)的用戶所做的更改會(huì)影響服務(wù)器，也會(huì)影響用戶各自的操作系統(tǒng)中的XM L文件中的數(shù)據(jù)，這樣使所有其他用戶得到最新的狀態(tài)和數(shù)據(jù)連續(xù)更新。但是目前只是在Android和Blackberry平臺(tái)上實(shí)驗(yàn)成功，而且特定的XM L文件的傳輸問(wèn)題很大程度上決定方案的可行性。另一種方法是使用一個(gè)框架，文獻(xiàn)[6]提出了HTM L5開發(fā)移動(dòng)應(yīng)用實(shí)現(xiàn)跨平臺(tái)，介紹了一些可用框架和移動(dòng)開發(fā)工具。國(guó)內(nèi)的主要有AppCan和ExM obi。AppCan免費(fèi)但不是開源的，ExM obi是商業(yè)性質(zhì)的。國(guó)外的比如PhoneGap、jQuery M obile、Sencha和Titanium，但是PhoneGap不支持UI設(shè)計(jì)，jQuery M obile不支持訪問(wèn)本地資源，Sencha和Titanium性能和用戶體驗(yàn)沒(méi)有原生應(yīng)用的好。相對(duì)于以上相關(guān)工作，本方案與之相同之處是由HTM L、JavaScript編寫的應(yīng)用，易發(fā)生代碼篡改的問(wèn)題，存在一定的安全問(wèn)題。本方案與之不同的是提供符合W 3C標(biāo)準(zhǔn)的統(tǒng)一的API，并且具有較高的靈活性和良好的可擴(kuò)展性。

3 智能終端應(yīng)用中間層設(shè)計(jì)與實(shí)現(xiàn)

本文將原生應(yīng)用和Web應(yīng)用開發(fā)的優(yōu)勢(shì)結(jié)合起來(lái)，提出一種基于瀏覽器作為中間層的跨平臺(tái)智能終端應(yīng)用設(shè)計(jì)方案。

3.1 跨平臺(tái)智能終端應(yīng)用設(shè)計(jì)方案原理

Webkit是當(dāng)前最新的、速度最快的開源瀏覽器引擎。Webkit支持多種移動(dòng)應(yīng)用所需要的HTM L5特性。目前在Android和iOS等主流瀏覽器中，都對(duì)這些特性提供了本地支持。本方案主要設(shè)計(jì)原理是針對(duì)不同移動(dòng)平臺(tái)的操作系統(tǒng)層之上添加一層中間適配層，此中間適配層對(duì)上層（M obile Application）提供統(tǒng)一的服務(wù)和接口，對(duì)下屏蔽各移動(dòng)智能終端操作系統(tǒng)的差異。其在移動(dòng)應(yīng)用和設(shè)備之間搭建一個(gè)通信的橋梁（M iddleware Layer），封裝移動(dòng)設(shè)備的平臺(tái)差異，統(tǒng)一使用JavaScript接口實(shí)現(xiàn)JavaScript和本地API之間的調(diào)用和通信，從而提供跨平臺(tái)解決方案。中間適配層利用基于Webkit為核心的瀏覽器的插件擴(kuò)展機(jī)制可以提供對(duì)智能終端設(shè)備的本地資源的訪問(wèn)和支持。本設(shè)計(jì)方案主要有以下優(yōu)點(diǎn)：

（1）跨平臺(tái)，屏蔽移動(dòng)智能終端操作系統(tǒng)的差異，從而實(shí)現(xiàn)“一次編碼，多處運(yùn)行”。

（2）直接訪問(wèn)移動(dòng)智能終端本地資源，通過(guò)統(tǒng)一的API可以直接訪問(wèn)聯(lián)系人、短信、攝像頭、GPS、W IFI、藍(lán)牙、多媒體、數(shù)據(jù)庫(kù)和文件系統(tǒng)等本地資源。

（3）本方案提供的API完全兼容W 3C標(biāo)準(zhǔn)，而且提供統(tǒng)一標(biāo)準(zhǔn)和豐富的API。

（4）易于使用，本方案完全采用HTM L5+CSS+ JavaScript技術(shù)開發(fā)移動(dòng)智能終端應(yīng)用，豐富的互聯(lián)網(wǎng)應(yīng)用程序可以稍做修改即可成為移動(dòng)智能終端應(yīng)用程序。

（5）具有較強(qiáng)的靈活性和擴(kuò)展性，開發(fā)者可以利用現(xiàn)有成熟的JavaScript庫(kù)和UI框架開發(fā)跨平臺(tái)的移動(dòng)應(yīng)用。

跨平臺(tái)移動(dòng)應(yīng)用中間層設(shè)計(jì)架構(gòu)如圖1。

圖1 跨平臺(tái)移動(dòng)應(yīng)用中間層設(shè)計(jì)架構(gòu)圖

3.2 跨平臺(tái)智能終端應(yīng)用設(shè)計(jì)方案的實(shí)現(xiàn)

眾所周知，不同的移動(dòng)平臺(tái)已內(nèi)置瀏覽器功能組件。瀏覽器具有一個(gè)本地API和移動(dòng)設(shè)備雙向通信的基本能力，可以通過(guò)調(diào)用本地JavaScript訪問(wèn)設(shè)備的API[7]。JavaScript在瀏覽器組件中的通信有兩種方式，即異步通信（A jax）和同步通信。A jax稱為"異步JavaScript和XM L"，是一種創(chuàng)建交互式Web應(yīng)用程序的通信技術(shù)。使用A jax的最大優(yōu)點(diǎn)是維護(hù)數(shù)據(jù)時(shí)在無(wú)需更新整個(gè)頁(yè)面的前提下更新局部數(shù)據(jù)，大大減輕了頁(yè)面服務(wù)端的負(fù)擔(dān)，使用戶的感覺更加直觀，使瀏覽器的交互能力大大加強(qiáng)。A jax技術(shù)可以用于在后臺(tái)，實(shí)現(xiàn)與服務(wù)端的Web應(yīng)用程序進(jìn)行通信（http：//en.w ikipedia.org/w iki/ A jax_（programm ing））。然而A jax是不可以跨域的，也就是說(shuō)如果Web端的htm l不是本地的文件而是從遠(yuǎn)端服務(wù)器下載下來(lái)的，那么它就不能向本地的server發(fā)起A jax請(qǐng)求（因?yàn)椴煌颍?，所以本方案選擇XM LH ttpRequest（http：//www.w3.org/TR/XMLHttpRequest/）和JSONP同用，JSONP是一個(gè)標(biāo)準(zhǔn)的解決A jax跨域的方案。

在開發(fā)移動(dòng)智能終端應(yīng)用過(guò)程中各平臺(tái)之間最大的不兼容主要表現(xiàn)在各平臺(tái)的API上，比如在處理事件、錯(cuò)誤、請(qǐng)求使用元數(shù)據(jù)和訪問(wèn)本地系統(tǒng)資源上API表現(xiàn)各不相同[8]。為此，需要開發(fā)符合W 3C標(biāo)準(zhǔn)的統(tǒng)一的API （http：//www.w3.org/2012/05/mobile-web-app-state/），包括Geolocation、WebGL、Device、M edia、Connection、Notification、Storage、Contacts、Sensors和File API等。而且要考慮每一個(gè)跨平臺(tái)的開發(fā)方案都要面臨滿足開發(fā)者需求和滿足用戶體驗(yàn)的挑戰(zhàn)[9]。本方案采用一個(gè)具有基本瀏覽器功能的組件來(lái)渲染HTM L，使用一個(gè)插件模型來(lái)封裝本地API，它涵蓋了瀏覽器原來(lái)的基本功能和方法來(lái)實(shí)現(xiàn)一個(gè)Web端口上的移動(dòng)設(shè)備的本地調(diào)用和移動(dòng)設(shè)備服務(wù)端端口到本地Web端口返回異步或同步調(diào)用的結(jié)果，并在各個(gè)移動(dòng)平臺(tái)上封裝API。這樣通過(guò)HTM L5、JavaScript、CSS等Web技術(shù)實(shí)現(xiàn)的本地應(yīng)用的表現(xiàn)層，直接由Webkit引擎來(lái)渲染呈現(xiàn)，同時(shí)也能提供更豐富，且與原生應(yīng)用相同的用戶體驗(yàn)。圖2是插件模型的架構(gòu)圖。中間適配層包括Brow ser（Webkit）Engine、JavaScript Plugin、Plugin M anager和Native Plugin。具體流程是由Brow ser（Webkit）Engine渲染HTM L來(lái)呈現(xiàn)Web內(nèi)容，移動(dòng)應(yīng)用（HTM L、JavaScript、CSS）通過(guò)JavaScript API調(diào)用基于Plugin模式的封裝Native API，以XHR或JSONP的方式來(lái)實(shí)現(xiàn)Native端向Web端返回異步調(diào)用的結(jié)果。通過(guò)持久性的XHR連接，JavaScript可以不斷輪詢內(nèi)部XHR服務(wù)器存儲(chǔ)的信息，從而實(shí)現(xiàn)了從Native端到Web方向的通信。從Native端返回的結(jié)果進(jìn)而由Brow ser（Webkit）Engine渲染并顯示。

圖2 插件模型架構(gòu)圖

3.2.1 插件管理模塊的設(shè)計(jì)與實(shí)現(xiàn)

插件的核心方法為execute方法，將負(fù)責(zé)實(shí)際處理接口調(diào)用請(qǐng)求。插件管理模塊分為接口，接口父類，服務(wù)（例：Contacts）接口子類，三者關(guān)系如圖3所示。

圖3 插件管理類圖

IPlugin接口為模塊的接口，由Plugin抽象類實(shí)現(xiàn)。在Plugin中，execute方法為抽象方法，必須由各個(gè)繼承Plugin的服務(wù)接口類來(lái)實(shí)現(xiàn)，負(fù)責(zé)處理實(shí)際的口調(diào)用請(qǐng)求。以下是Web客戶端通過(guò)JavaScript調(diào)用移動(dòng)智能終端的Native API的流程，見圖4。

圖4 中間層執(zhí)行流程圖

如圖4所示，中間層將Web客戶端調(diào)用Native API請(qǐng)求包裝為prompt（）事件，因此，中間層通過(guò)監(jiān)聽JSPrompt（）事件，獲取適配層的接口調(diào)用請(qǐng)求。以Android平臺(tái)為例，平臺(tái)本身提供了監(jiān)聽?wèi)?yīng)用層事件的機(jī)制，通過(guò)繼承Activity類，并重載其onJsProm pt（）方法，可以將應(yīng)用程序?qū)拥慕涌谡{(diào)用請(qǐng)求事件捕獲，onJsPrompt（）方法通過(guò)調(diào)用PluginM anager.exec（）方法，將所接收的調(diào)用請(qǐng)求進(jìn)行分發(fā)并處理。如果是同步請(qǐng)求，則直接由主線程的插件的Plugin.execute（）方法執(zhí)行，然后就執(zhí)行結(jié)果PluginResult返回給Web客戶端即移動(dòng)應(yīng)用程序；如果是異步請(qǐng)求，則將啟動(dòng)新的線程來(lái)處理，處理完后，將結(jié)果通過(guò)服務(wù)器端寫到客戶端。服務(wù)器端相當(dāng)于XM LHttpResponse，負(fù)責(zé)將數(shù)據(jù)異步寫到客戶端。它在內(nèi)部會(huì)有一個(gè)socket監(jiān)聽，不停的接收來(lái)自于客戶端的請(qǐng)求，如果發(fā)現(xiàn)變量（JavaScript）中有數(shù)據(jù)，就寫到客戶端，如果沒(méi)有，則休眠片刻，休眠后，如果有數(shù)據(jù)，則寫到客戶端，否則寫一個(gè)404異常到客戶端，然后此次連接中斷，重新接收新的客戶端請(qǐng)求。

3.2.2 Native API模塊的設(shè)計(jì)與實(shí)現(xiàn)

上面已經(jīng)提到服務(wù)接口子類，Native Plugin必須由各個(gè)繼承Plugin的服務(wù)接口類來(lái)實(shí)現(xiàn)。以SMS為例給出服務(wù)子類的Java[10]實(shí)現(xiàn)原型。所有服務(wù)子類的實(shí)現(xiàn)嚴(yán)格按照W 3C標(biāo)準(zhǔn)執(zhí)行。按照相應(yīng)需求設(shè)計(jì)服務(wù)子類的屬性和方法。

Native Plugin類在執(zhí)行來(lái)自Web客戶端的調(diào)用請(qǐng)求之后，返回的對(duì)象為PluginResult。PluginResult根據(jù)調(diào)用請(qǐng)求的callback ID，返回onSuccess與onError結(jié)果，其實(shí)現(xiàn)原型如下：

這樣通過(guò)返回PluginResult給Web客戶端完成對(duì)Native API的調(diào)用。

3.2.3 JavaScript插件庫(kù)的設(shè)計(jì)與實(shí)現(xiàn)

JavaScript面向?qū)ο笈c傳統(tǒng)的基于類的面向?qū)ο蟛煌桨富赑rototype模式的接口構(gòu)造，通過(guò)對(duì)象中的Prototype屬性，返回對(duì)象的原型引用。

Prototype模式是一種對(duì)象創(chuàng)建型模式，它跟工廠模式，Builder模式等一樣，都用來(lái)創(chuàng)建類的實(shí)例對(duì)象。它通過(guò)拷貝這些原型創(chuàng)建新的對(duì)象，其UM L類圖結(jié)構(gòu)如圖5所示。它適用于以下幾種情況[11]。

圖5 Prototype模式UM L類結(jié)構(gòu)圖

（1）當(dāng)一個(gè)系統(tǒng)應(yīng)該獨(dú)立于它的產(chǎn)品創(chuàng)建、構(gòu)成和表示時(shí)；

（2）當(dāng)要實(shí)例化的類是在運(yùn)行時(shí)刻指定時(shí)；

（3）為了避免創(chuàng)建一個(gè)與產(chǎn)品類層次平行的工廠類層次時(shí)；

（4）當(dāng)一個(gè)類的實(shí)例只能有幾個(gè)不同狀態(tài)組合中的一種時(shí)。

AbstractPrototype：聲明一個(gè)克隆自身的接口。

ConcretePrototype：實(shí)現(xiàn)一個(gè)克隆自身的操作。

Client：原型克隆自身從而創(chuàng)建一個(gè)新的對(duì)象。

JavaScript為每一個(gè)類型都提供了一個(gè)Prototype屬性[12]，將這個(gè)屬性指向一個(gè)對(duì)象，這個(gè)對(duì)象就成為了這個(gè)類型的“原型”，這意味著由這個(gè)類型所創(chuàng)建的所有對(duì)象都具有這個(gè)原型的特性。

對(duì)于JavaScript來(lái)說(shuō)，每個(gè)具體的JavaScript類型有且僅有一個(gè)原型（Prototype），即原型繼承不能用于多繼承。每個(gè)類型的實(shí)例的所有類型，必須是滿足原型關(guān)系的類型鏈。以SMS為例，SMS接口有send方法的訪問(wèn)。SMS接口下，send方法的構(gòu)造實(shí)現(xiàn)如下：

然后在插件中注冊(cè)，方法如下：

注冊(cè)后就可以在應(yīng)用中通過(guò)JavaScript調(diào)用SMS 的send方法發(fā)送短信了。

各平臺(tái)封裝對(duì)應(yīng)的API，具體如表3。

表3 JavaScript API

限于篇幅有限，API沒(méi)有完全列出。

4 仿真實(shí)驗(yàn)

本文提出的移動(dòng)應(yīng)用中間層已在多個(gè)平臺(tái)進(jìn)行了應(yīng)用開發(fā)驗(yàn)證。

此處以發(fā)送短信為例，以相同的應(yīng)用程序（含HTM L、JavaScript和CSS文件）分別在W in Phone7平臺(tái)、Android平臺(tái)和palm webOS平臺(tái)上進(jìn)行仿真實(shí)驗(yàn)。

圖6 HTM L代碼

圖7 JavaScript代碼

仿真結(jié)果如圖8～10所示。

圖8 W in Phone7平臺(tái)仿真實(shí)驗(yàn)

圖9 Android平臺(tái)仿真實(shí)驗(yàn)

圖10 palm webOS平臺(tái)仿真實(shí)驗(yàn)

在圖8，圖9和圖10中，分別調(diào)用中間適配層的API函數(shù)，這里是調(diào)用sendm s（phonenum，msg）方法，包含phonenum和msg兩個(gè)參數(shù)，phonenum表示要發(fā)送的電話號(hào)碼，m sg表示要發(fā)送的短信內(nèi)容。圖8，圖9和圖10分別展示了在w in phone7、Android和webOS平臺(tái)上的效果。中間適配層可以很好地支持移動(dòng)應(yīng)用開發(fā)。安裝并配置相關(guān)平臺(tái)的開發(fā)環(huán)境，在HTM L中調(diào)用中間適配層的API庫(kù)，比如＜script type="text/javascript"charset= "gb2312"src="main.js">＜/script>，其中main.js是中間適配層API庫(kù)。開發(fā)者根據(jù)需要可以調(diào)用中間適配層提供的各種函數(shù)訪問(wèn)本地資源和網(wǎng)絡(luò)資源，以開發(fā)各種移動(dòng)應(yīng)用。

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

本文提出了基于中間層的跨平臺(tái)移動(dòng)智能終端應(yīng)用方案設(shè)計(jì)并實(shí)現(xiàn)。通過(guò)理論設(shè)計(jì)和在不同平臺(tái)的仿真實(shí)驗(yàn)，可以肯定本方案有很多優(yōu)勢(shì)：（1）是跨平臺(tái)。（2）是可直接訪問(wèn)智能終端的本地資源。（3）是提供符合W 3C標(biāo)準(zhǔn)的統(tǒng)一的API。（4）是降低移動(dòng)智能終端應(yīng)用開發(fā)的難度。（5）是具有較高的靈活性和良好的可擴(kuò)展性。但本方案也有一些不足之處：（1）是開發(fā)的移動(dòng)應(yīng)用對(duì)HTM L5的支持程度受制于Webkit瀏覽器內(nèi)核。（2）是由HTM L、JavaScript編寫的應(yīng)用，易發(fā)生代碼篡改的問(wèn)題，存在一定的安全問(wèn)題。（3）是它不支持所有的平臺(tái)，因?yàn)橛幸恍┨厥獾腁PI，例如日志記錄的API和WRT平臺(tái)的傳感器API。

[1]com Score.com Score Reports February 2012 U.S.M obile Subscriber Market Share[EB/OL]（2012-04-07）.http：//www. comscore.com/Press_Events/Press_Releases/2012/4/comScore_ Reports_February_2012_U.S._Mobile_Subscriber_Market_ Share.

[2]Charland A，Leroux B.Mobile application development：web vs.native[J].Communications，2011，54（5）：49-53.

[3]Melamed T，Clayton B.A comparative evaluation of HTML5 as a pervasive Media platform[J].Social-Informatics and Telecommunications Engineering，2010：307-325.

[4]Lettner M，Tschernuth M，M ayrhofe R.M obile platform architecture review：Android，iPhone，Qt[R].Lecture Notes in Computer Science，2012.

[5]Iyer A，Jadhav A，Dhangare N.Common platform for mobile application[J].Advances in Computer Science and its Applications，2012，1（2）：174-184.

[6]Pavel S.Mobile development tools and cross-platform solutions[C]//2012 13th International Carpathian Control Conference（ICCC），2012：653-656.

[7]Shi Wei，Wu Minghui.Local resource accessing mechanism on multiple mobile platform[C]//High Performance Computing and Communications，2012：1716-1721.

[8]Mendes P，Caceres M，Dwolatzky B.A review of the widget landscape and incompatibilities between widget engines[C]// IEEEAFRICON，2009：23-25.

[9]Ohrt J，Turau V.Cross-platform development tools for smartphone applications[J].IEEE Computer Society，10.1109/ MC.2012.121.

[10]Skrien D.Object-oriented design using Java[M].騰靈靈，仲婷，譯.北京：清華大學(xué)出版社，2009：173-192.

[11]Taivalsaari A.Kevo-a prototype-based object-oriented language based onconcatenation and module operations[R]. Canada，University of Victoria，B C，1992.

[12]閻宏.Java與模式[M].北京：電子工業(yè)出版社，2002：317-343.

SHI Wei1，3,WANG Shuoping2,GUO M ing2,WU M inghui2,LIANG Peng1，4

1.College of Computer Science and Technology,Zhejiang University,Hangzhou 310027,China
2.College of Computer and Computation Science,Zhejiang University City College,Hangzhou 310015,China
3.Unit 91199 of PLA,China
4.Unit 94936 of PLA,China

Due to the incompatibility between the current popular mobile developments platforms,cause all kinds of waste of application development resources.In order to resolve the incompatibilities of the various platform application development,this paper proposes a solution that is to add a middle adaptation layer between mobile platform operating system layer and application layer.Adaptation layer encapsulates through a browser with Webkit as the core and extensions, support cross-platform mobile application development,mobile terminal access to local resources on a different platform and has a good support.The middle adaptation layer has good versatility and scalability,and has carried out simulation experiments on multiple platform s to verify the feasibility and practicability of the solution.

cross-platform；mobile application；middle layer；HTM L5

A

TP311.52

10.3778/j.issn.1002-8331.1208-0481

SHI Wei, WANG Shuoping, GUO Ming, et al. Design and implementation of cross-platform mobile application middle adaptation layer. Computer Engineering and Applications, 2014, 50（16）：39-44.

國(guó)家科技重大專項(xiàng)（No.2011ZX 0302-004-002）；浙江省重點(diǎn)科技創(chuàng)新團(tuán)隊(duì)項(xiàng)目（No.2010R50009）；浙江省科技廳公益技術(shù)研究項(xiàng)目（No.2011C33015）。

施偉（1980—），男，碩士研究生，研究方向?yàn)橐苿?dòng)互聯(lián)網(wǎng)應(yīng)用；王碩蘋（1972—），女，副教授，研究領(lǐng)域?yàn)樾畔⑾到y(tǒng)設(shè)計(jì)、軟件架構(gòu)；郭鳴（1972—），男，博士，副教授，研究領(lǐng)域?yàn)橹R(shí)表示、語(yǔ)義Web；吳明暉（1976—），男，通訊作者，博士，教授，研究領(lǐng)域?yàn)檐浖こ?、人工智能；梁鵬（1982—），男，碩士研究生，研究方向?yàn)閿?shù)據(jù)庫(kù)安全。E-mail：mhwu@zucc.edu.cn

2012-09-05

2012-11-20

1002-8331（2014）16-0039-06

CNKI網(wǎng)絡(luò)優(yōu)先出版：2012-12-03,http://www.cnki.net/kcms/detail/11.2127.TP.20121203.1559.005.htm l