999精品在线视频,手机成人午夜在线视频,久久不卡国产精品无码,中日无码在线观看,成人av手机在线观看,日韩精品亚洲一区中文字幕,亚洲av无码人妻,四虎国产在线观看 ?

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

2014-07-07 03:37:54施偉王碩蘋郭鳴吳明暉梁鵬
關(guān)鍵詞:跨平臺(tái)智能

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

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

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

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

4.中國人民解放軍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.中國人民解放軍91199部隊(duì)

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

由于當(dāng)前主流的移動(dòng)開發(fā)平臺(tái)之間互不兼容,造成應(yīng)用開發(fā)各種資源的浪費(fèi)。為了解決各個(gè)平臺(tái)應(yīng)用開發(fā)的不兼容問題,提出在移動(dòng)平臺(tái)操作系統(tǒng)層和應(yīng)用層之間添加中間適配層的方案。中間適配層通過對(duì)以Webkit為核心的瀏覽器進(jìn)行封裝和擴(kuò)展,支持跨平臺(tái)的移動(dòng)應(yīng)用開發(fā),對(duì)不同平臺(tái)移動(dòng)終端的本地資源訪問也有較好的支持。該中間適配層具有良好的通用性和擴(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ù)了較大的市場份額,如表1所示。因此要想獲得更多的用戶,選擇單一平臺(tái)來開發(fā)和發(fā)布的終端應(yīng)用不再是一個(gè)可行的選擇。

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

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

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

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

為了解決各個(gè)平臺(tái)應(yīng)用開發(fā)的不兼容問題,一種替代方案就是嘗試在不同設(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的特性來編寫移動(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)用也存在劣勢。比如對(duì)沒有定位傳感器裝置終端的支持非常有限。對(duì)內(nèi)容捕獲的攝像頭和麥克風(fēng)的支持也是很有限的。在一些本地資源的使用方面,Web應(yīng)用的用戶體驗(yàn)不及原生應(yīng)用程序那么良好。

本文結(jié)合國家科技重大專項(xiàng)課題(移動(dòng)互聯(lián)網(wǎng)智能終端應(yīng)用中間件開發(fā))的研究,將原生應(yīng)用和Web應(yīng)用開發(fā)的優(yōu)勢結(jié)合起來,提出了基于瀏覽器作為中間層的跨平臺(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)來驗(yàn)證方案的可行性和實(shí)際效果。

2 相關(guān)工作

隨著人們對(duì)跨平臺(tái)應(yīng)用開發(fā)研究的不斷深入,目前主要有以下相關(guān)研究。文獻(xiàn)[4]指出對(duì)于移動(dòng)開發(fā)者來說很難找到最合適的開發(fā)平臺(tái),分析Android、iPhone、Qt的關(guān)鍵開發(fā)技術(shù),重要的共同點(diǎn)和差異,但沒有解決跨平臺(tái)的問題。解決跨平臺(tái)的一種方案就是嘗試在不同設(shè)備的應(yīng)用層之間的抽象共性。比如文獻(xiàn)[5]提出了一種通用的平臺(tái),此平臺(tái)需要一臺(tái)互聯(lián)網(wǎng)服務(wù)器通過一個(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文件的傳輸問題很大程度上決定方案的可行性。另一種方法是使用一個(gè)框架,文獻(xiàn)[6]提出了HTM L5開發(fā)移動(dòng)應(yīng)用實(shí)現(xiàn)跨平臺(tái),介紹了一些可用框架和移動(dòng)開發(fā)工具。國內(nèi)的主要有AppCan和ExM obi。AppCan免費(fèi)但不是開源的,ExM obi是商業(yè)性質(zhì)的。國外的比如PhoneGap、jQuery M obile、Sencha和Titanium,但是PhoneGap不支持UI設(shè)計(jì),jQuery M obile不支持訪問本地資源,Sencha和Titanium性能和用戶體驗(yàn)沒有原生應(yīng)用的好。相對(duì)于以上相關(guān)工作,本方案與之相同之處是由HTM L、JavaScript編寫的應(yīng)用,易發(fā)生代碼篡改的問題,存在一定的安全問題。本方案與之不同的是提供符合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)勢結(jié)合起來,提出一種基于瀏覽器作為中間層的跨平臺(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è)備的本地資源的訪問和支持。本設(shè)計(jì)方案主要有以下優(yōu)點(diǎn):

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

(2)直接訪問移動(dòng)智能終端本地資源,通過統(tǒng)一的API可以直接訪問聯(lián)系人、短信、攝像頭、GPS、W IFI、藍(lán)牙、多媒體、數(shù)據(jù)庫和文件系統(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庫和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è)備雙向通信的基本能力,可以通過調(diào)用本地JavaScript訪問設(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í)在無需更新整個(gè)頁面的前提下更新局部數(shù)據(jù),大大減輕了頁面服務(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是不可以跨域的,也就是說如果Web端的htm l不是本地的文件而是從遠(yuǎn)端服務(wù)器下載下來的,那么它就不能向本地的server發(fā)起A jax請(qǐng)求(因?yàn)椴煌颍员痉桨高x擇XM LH ttpRequest(http://www.w3.org/TR/XMLHttpRequest/)和JSONP同用,JSONP是一個(gè)標(biāo)準(zhǔn)的解決A jax跨域的方案。

在開發(fā)移動(dòng)智能終端應(yīng)用過程中各平臺(tái)之間最大的不兼容主要表現(xiàn)在各平臺(tái)的API上,比如在處理事件、錯(cuò)誤、請(qǐng)求使用元數(shù)據(jù)和訪問本地系統(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è)具有基本瀏覽器功能的組件來渲染HTM L,使用一個(gè)插件模型來封裝本地API,它涵蓋了瀏覽器原來的基本功能和方法來實(shí)現(xiàn)一個(gè)Web端口上的移動(dòng)設(shè)備的本地調(diào)用和移動(dòng)設(shè)備服務(wù)端端口到本地Web端口返回異步或同步調(diào)用的結(jié)果,并在各個(gè)移動(dòng)平臺(tái)上封裝API。這樣通過HTM L5、JavaScript、CSS等Web技術(shù)實(shí)現(xiàn)的本地應(yīng)用的表現(xiàn)層,直接由Webkit引擎來渲染呈現(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來呈現(xiàn)Web內(nèi)容,移動(dòng)應(yīng)用(HTM L、JavaScript、CSS)通過JavaScript API調(diào)用基于Plugin模式的封裝Native API,以XHR或JSONP的方式來實(shí)現(xiàn)Native端向Web端返回異步調(diào)用的結(jié)果。通過持久性的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ù)接口類來實(shí)現(xiàn),負(fù)責(zé)處理實(shí)際的口調(diào)用請(qǐng)求。以下是Web客戶端通過JavaScript調(diào)用移動(dòng)智能終端的Native API的流程,見圖4。

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

如圖4所示,中間層將Web客戶端調(diào)用Native API請(qǐng)求包裝為prompt()事件,因此,中間層通過監(jiān)聽JSPrompt()事件,獲取適配層的接口調(diào)用請(qǐng)求。以Android平臺(tái)為例,平臺(tái)本身提供了監(jiān)聽?wèi)?yīng)用層事件的機(jī)制,通過繼承Activity類,并重載其onJsProm pt()方法,可以將應(yīng)用程序?qū)拥慕涌谡{(diào)用請(qǐng)求事件捕獲,onJsPrompt()方法通過調(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)新的線程來處理,處理完后,將結(jié)果通過服務(wù)器端寫到客戶端。服務(wù)器端相當(dāng)于XM LHttpResponse,負(fù)責(zé)將數(shù)據(jù)異步寫到客戶端。它在內(nèi)部會(huì)有一個(gè)socket監(jiān)聽,不停的接收來自于客戶端的請(qǐng)求,如果發(fā)現(xiàn)變量(JavaScript)中有數(shù)據(jù),就寫到客戶端,如果沒有,則休眠片刻,休眠后,如果有數(shù)據(jù),則寫到客戶端,否則寫一個(gè)404異常到客戶端,然后此次連接中斷,重新接收新的客戶端請(qǐng)求。

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

上面已經(jīng)提到服務(wù)接口子類,Native Plugin必須由各個(gè)繼承Plugin的服務(wù)接口類來實(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í)行來自Web客戶端的調(diào)用請(qǐng)求之后,返回的對(duì)象為PluginResult。PluginResult根據(jù)調(diào)用請(qǐng)求的callback ID,返回onSuccess與onError結(jié)果,其實(shí)現(xiàn)原型如下:

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

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

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

Prototype模式是一種對(duì)象創(chuàng)建型模式,它跟工廠模式,Builder模式等一樣,都用來創(chuàng)建類的實(shí)例對(duì)象。它通過拷貝這些原型創(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來說,每個(gè)具體的JavaScript類型有且僅有一個(gè)原型(Prototype),即原型繼承不能用于多繼承。每個(gè)類型的實(shí)例的所有類型,必須是滿足原型關(guān)系的類型鏈。以SMS為例,SMS接口有send方法的訪問。SMS接口下,send方法的構(gòu)造實(shí)現(xiàn)如下:

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

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

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

表3 JavaScript API

限于篇幅有限,API沒有完全列出。

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庫,比如<script type="text/javascript"charset= "gb2312"src="main.js"></script>,其中main.js是中間適配層API庫。開發(fā)者根據(jù)需要可以調(diào)用中間適配層提供的各種函數(shù)訪問本地資源和網(wǎng)絡(luò)資源,以開發(fā)各種移動(dòng)應(yīng)用。

5 結(jié)束語

本文提出了基于中間層的跨平臺(tái)移動(dòng)智能終端應(yīng)用方案設(shè)計(jì)并實(shí)現(xiàn)。通過理論設(shè)計(jì)和在不同平臺(tái)的仿真實(shí)驗(yàn),可以肯定本方案有很多優(yōu)勢:(1)是跨平臺(tái)。(2)是可直接訪問智能終端的本地資源。(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ā)生代碼篡改的問題,存在一定的安全問題。(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.

國家科技重大專項(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í)表示、語義Web;吳明暉(1976—),男,通訊作者,博士,教授,研究領(lǐng)域?yàn)檐浖こ獭⑷斯ぶ悄埽涣葫i(1982—),男,碩士研究生,研究方向?yàn)閿?shù)據(jù)庫安全。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

猜你喜歡
跨平臺(tái)智能
跨層級(jí)網(wǎng)絡(luò)、跨架構(gòu)、跨平臺(tái)的數(shù)據(jù)共享交換關(guān)鍵技術(shù)研究與系統(tǒng)建設(shè)
一款游戲怎么掙到全平臺(tái)的錢?
智能制造 反思與期望
智能前沿
文苑(2018年23期)2018-12-14 01:06:06
跨平臺(tái)APEX接口組件的設(shè)計(jì)與實(shí)現(xiàn)
智能前沿
文苑(2018年19期)2018-11-09 01:30:14
智能前沿
文苑(2018年17期)2018-11-09 01:29:26
智能前沿
文苑(2018年21期)2018-11-09 01:22:32
智能制造·AI未來
商周刊(2018年18期)2018-09-21 09:14:46
基于QT的跨平臺(tái)輸電鐵塔監(jiān)控終端軟件設(shè)計(jì)與實(shí)現(xiàn)
主站蜘蛛池模板: 久久精品国产国语对白| 九色在线观看视频| 亚洲乱码在线视频| 亚洲AV无码久久精品色欲| 午夜爽爽视频| 久久特级毛片| 亚洲日韩日本中文在线| 91精品啪在线观看国产60岁| 香蕉久久国产超碰青草| 热久久综合这里只有精品电影| 久久久精品无码一二三区| 日本尹人综合香蕉在线观看| 免费观看精品视频999| 不卡无码网| 成人午夜免费观看| 色婷婷色丁香| 无码区日韩专区免费系列| 国产精品 欧美激情 在线播放| 秋霞午夜国产精品成人片| 亚洲av无码成人专区| 欧美黄网在线| 欧美a级在线| 亚洲AV无码一二区三区在线播放| 啦啦啦网站在线观看a毛片| 中文字幕欧美日韩| 色吊丝av中文字幕| 国产99在线| 91久草视频| 在线观看欧美国产| 99ri国产在线| 亚洲欧美另类色图| 全部毛片免费看| 国产成本人片免费a∨短片| 亚洲国产日韩欧美在线| 婷婷综合在线观看丁香| 国产91丝袜| 香蕉99国内自产自拍视频| 天天色综合4| 福利视频99| 久久9966精品国产免费| 天天综合网亚洲网站| 欧美午夜一区| 国产欧美视频在线观看| 欧美日韩国产高清一区二区三区| 精品一区二区三区四区五区| 精品视频一区二区观看| 国产日韩av在线播放| 国产69精品久久久久妇女| 国产主播福利在线观看| 欧美在线中文字幕| h网址在线观看| 日本一区二区不卡视频| 午夜小视频在线| 亚欧成人无码AV在线播放| 欧美成人免费一区在线播放| 亚洲精品天堂自在久久77| 亚洲欧美一区二区三区麻豆| 99久久精品免费看国产电影| 婷婷午夜天| 婷婷开心中文字幕| 亚洲区一区| 亚洲欧洲天堂色AV| 国产日韩丝袜一二三区| AV天堂资源福利在线观看| 免费无码又爽又刺激高| 日韩无码白| 国产精品区视频中文字幕| 99热这里只有精品国产99| 午夜a级毛片| 国产18在线播放| 午夜啪啪福利| 精品自窥自偷在线看| 免费高清自慰一区二区三区| 99这里只有精品在线| 国产真实乱子伦视频播放| 国产sm重味一区二区三区| 99在线小视频| 亚洲精品无码久久毛片波多野吉| 亚洲第一精品福利| 久久久久久久久亚洲精品| 国产a v无码专区亚洲av| 久无码久无码av无码|