跨平臺移動應(yīng)用中間適配層設(shè)計與實現(xiàn)

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

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

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

3.中國人民解放軍91199部隊

4.中國人民解放軍94936部隊

跨平臺移動應(yīng)用中間適配層設(shè)計與實現(xiàn)

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

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

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

3.中國人民解放軍91199部隊

4.中國人民解放軍94936部隊

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

跨平臺；移動應(yīng)用；中間層；HTM L5

1 引言

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

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

表1 2012年2月各平臺市場份額[1]

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

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

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

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

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

2 相關(guān)工作

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

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

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

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

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

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

（2）直接訪問移動智能終端本地資源，通過統(tǒng)一的API可以直接訪問聯(lián)系人、短信、攝像頭、GPS、W IFI、藍牙、多媒體、數(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ā)移動智能終端應(yīng)用，豐富的互聯(lián)網(wǎng)應(yīng)用程序可以稍做修改即可成為移動智能終端應(yīng)用程序。

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

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

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

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

眾所周知，不同的移動平臺已內(nèi)置瀏覽器功能組件。瀏覽器具有一個本地API和移動設(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)點是維護數(shù)據(jù)時在無需更新整個頁面的前提下更新局部數(shù)據(jù)，大大減輕了頁面服務(wù)端的負擔(dān)，使用戶的感覺更加直觀，使瀏覽器的交互能力大大加強。A jax技術(shù)可以用于在后臺，實現(xiàn)與服務(wù)端的Web應(yīng)用程序進行通信（http：//en.w ikipedia.org/w iki/ A jax_（programm ing））。然而A jax是不可以跨域的，也就是說如果Web端的htm l不是本地的文件而是從遠端服務(wù)器下載下來的，那么它就不能向本地的server發(fā)起A jax請求（因為不同域），所以本方案選擇XM LH ttpRequest（http：//www.w3.org/TR/XMLHttpRequest/）和JSONP同用，JSONP是一個標(biāo)準(zhǔn)的解決A jax跨域的方案。

在開發(fā)移動智能終端應(yīng)用過程中各平臺之間最大的不兼容主要表現(xiàn)在各平臺的API上，比如在處理事件、錯誤、請求使用元數(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等。而且要考慮每一個跨平臺的開發(fā)方案都要面臨滿足開發(fā)者需求和滿足用戶體驗的挑戰(zhàn)[9]。本方案采用一個具有基本瀏覽器功能的組件來渲染HTM L，使用一個插件模型來封裝本地API，它涵蓋了瀏覽器原來的基本功能和方法來實現(xiàn)一個Web端口上的移動設(shè)備的本地調(diào)用和移動設(shè)備服務(wù)端端口到本地Web端口返回異步或同步調(diào)用的結(jié)果，并在各個移動平臺上封裝API。這樣通過HTM L5、JavaScript、CSS等Web技術(shù)實現(xiàn)的本地應(yīng)用的表現(xiàn)層，直接由Webkit引擎來渲染呈現(xiàn)，同時也能提供更豐富，且與原生應(yīng)用相同的用戶體驗。圖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)容，移動應(yīng)用（HTM L、JavaScript、CSS）通過JavaScript API調(diào)用基于Plugin模式的封裝Native API，以XHR或JSONP的方式來實現(xiàn)Native端向Web端返回異步調(diào)用的結(jié)果。通過持久性的XHR連接，JavaScript可以不斷輪詢內(nèi)部XHR服務(wù)器存儲的信息，從而實現(xiàn)了從Native端到Web方向的通信。從Native端返回的結(jié)果進而由Brow ser（Webkit）Engine渲染并顯示。

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

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

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

圖3 插件管理類圖

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

AbstractPrototype：聲明一個克隆自身的接口。

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

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

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

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

然后在插件中注冊，方法如下：

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

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

表3 JavaScript API

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

4 仿真實驗

本文提出的移動應(yīng)用中間層已在多個平臺進行了應(yīng)用開發(fā)驗證。

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

圖6 HTM L代碼

圖7 JavaScript代碼

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

圖8 W in Phone7平臺仿真實驗

圖9 Android平臺仿真實驗

圖10 palm webOS平臺仿真實驗

在圖8，圖9和圖10中，分別調(diào)用中間適配層的API函數(shù)，這里是調(diào)用sendm s（phonenum，msg）方法，包含phonenum和msg兩個參數(shù)，phonenum表示要發(fā)送的電話號碼，m sg表示要發(fā)送的短信內(nèi)容。圖8，圖9和圖10分別展示了在w in phone7、Android和webOS平臺上的效果。中間適配層可以很好地支持移動應(yīng)用開發(fā)。安裝并配置相關(guān)平臺的開發(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ā)各種移動應(yīng)用。

5 結(jié)束語

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

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

施偉（1980—），男，碩士研究生，研究方向為移動互聯(lián)網(wǎng)應(yīng)用；王碩蘋（1972—），女，副教授，研究領(lǐng)域為信息系統(tǒng)設(shè)計、軟件架構(gòu)；郭鳴（1972—），男，博士，副教授，研究領(lǐng)域為知識表示、語義Web；吳明暉（1976—），男，通訊作者，博士，教授，研究領(lǐng)域為軟件工程、人工智能；梁鵬（1982—），男，碩士研究生，研究方向為數(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