張驥先

(云南大學信息學院，云南昆明650092)

移動互聯(lián)網(wǎng)應用已經(jīng)引發(fā)了信息產(chǎn)業(yè)的深度變革，具有分布性廣、移動性強的特點［1－2］.一個移動互聯(lián)網(wǎng)應用完整的業(yè)務流程一般會涉及到終端和服務端交互，例如蘋果手機的智能語音助手Siri，手機終端采集用戶的語音并進行識別，然后將識別后的信息傳輸至服務端，服務端將這類信息進行識別后的得到了用戶意圖，然后根據(jù)此意圖進行知識搜索，并將搜索得到的結(jié)果傳回手機終端展現(xiàn)給客戶.在這個業(yè)務流程當中，手機終端負責采集用戶的語音并進行識別，以及最后結(jié)果的展示.但是同樣是語音助手，基于Android系統(tǒng)的大部分手機都是將語音流傳輸?shù)椒掌?，在服務器上完成語音的識別.其中最主要的原因在于如果在手機終端完成語音識會耗費手機大量的CPU資源及電量;而如果將語音流傳輸至服務器的話可以節(jié)省CPU資源及電量，但另一方面又會耗費網(wǎng)絡通信帶寬［3－4］.

這個例子說明，一個移動互聯(lián)網(wǎng)應用由多個功能模塊組成(如例子中的語音識別模塊，知識搜索模塊)，其中一部分功能模塊既可以在終端運行，也可以在服務端運行.應用部署指的是根據(jù)終端目前狀態(tài)以及應用本身復雜度來決定應用中哪些功能模塊在服務端運行，哪些功能模塊在終端運行可以使應用服務質(zhì)量最好，系統(tǒng)性能最優(yōu)［5］.當前研究工作多是針對單一平臺上簡單應用提出的應用部署算法，且不適用于大型應用.而這些方面正是移動互聯(lián)網(wǎng)應用部署從理論走向?qū)嶋H所需要解決的關鍵問題，主要涉及到以下幾個方面:

1)應用模型:一個應用由若干個功能模塊組成，應用模型反映出應用中所包含各個模塊間的交互關系以及拓撲結(jié)構.當前的研究有幾種主流的觀點，分別是將應用的功能模塊表示成圖的拓撲結(jié)構［6－9］、樹的拓撲結(jié)構［7］和彈性應用模型［8］.但這幾類模型對簡單應用較為適用，一旦應用復雜度增加，應用模塊間相關程度增大，其拓撲結(jié)構復雜度會增大，直接影響了應用部署算法的效率及準確性.

2)應用部署算法:基于應用模型，應用部署算法會根據(jù)終端接入應用時的環(huán)境和狀態(tài)計算出最合適的部署方案，然后將應用中的模塊按照此方案部署到移動端或服務端，以求達到最優(yōu)的用戶體驗和系統(tǒng)性能.部署算法主要分為靜態(tài)算法與動態(tài)算法兩種，靜態(tài)算法具有較高的準確性，但計算量大，一般通過分類或聚類算法先期計算出預測模型，這意味著需要采集大量的用戶數(shù)據(jù)來完成機器學習，從而在新用戶接入應用時服務端可以快速計算出最恰當?shù)牟渴鸱桨?而動態(tài)算法不需要進行前期學習，根據(jù)終端首次接入應用時的狀態(tài)進行實時的計算，性能及準確性不高.應用部署算法一般放在服務端執(zhí)行，文獻［6］屬于動態(tài)算法，其采用線性優(yōu)化進行部署方案的實時計算，而且未考慮模塊節(jié)點的父節(jié)點對當前應用部署的影響，所得到的結(jié)果準確性低，且效率較低;文獻［7－9］屬于靜態(tài)算法，其提出的應用部署方案計算方法雖然考慮到了歷史數(shù)據(jù)因素，但是其基于樸素貝葉斯(naive Bayesian)的分類策略中存在特征屬性不獨立的問題，會降低結(jié)果的準確性，且其分類器訓練較為復雜.

1 國內(nèi)外研究現(xiàn)狀

目前國內(nèi)外對移動互聯(lián)網(wǎng)應用部署的研究多是針對特定平臺上簡單應用進行的研究.

1.1 應用模型的研究

應用模型的一個主要研究內(nèi)容是應用的拓撲結(jié)構，目前有幾種主流的觀點，分別是將應用模塊間調(diào)用關系表示成圖的拓撲結(jié)構［6，9］、樹的拓撲結(jié)構［7］和彈性應用模型［8］.

Giurgiu 等和 Shumao 等［6，9］提倡將應用按模塊(如Java類)之間的調(diào)用關系表示為有向無環(huán)圖，G={B，E}，其中節(jié)點B代表模塊;邊E代表模塊間交互.將應用模型表示為圖拓撲結(jié)構的好處是比較適合于面向?qū)ο蟮膽瞄_發(fā)方式，基本可以涵蓋所有的應用，缺點是當應用結(jié)構變得復雜的時候，圖也會相應變得復雜，直接影響到應用部署及遷移算法的效率.

Intel Labs Berkeley 的 Chun 等［7］提出了克隆云(clone cloud)的概念，為應用模型提出了一種新的思路，通過分析應用中函數(shù)調(diào)用關系，將應用體現(xiàn)為樹的拓撲結(jié)構(profile tree)，樹中每個節(jié)點代表一個函數(shù)，而邊代表調(diào)用關系.樹的拓撲結(jié)構比較適合于面向過程的應用開發(fā)方式，模塊粒度多為函數(shù)級別，優(yōu)點是較易分離出造成性能瓶頸的函數(shù);缺點是此類應用的設計與實現(xiàn)不便，且模塊間相互調(diào)用關系不易處理，樹的拓撲結(jié)構并不適合于描述目前大多數(shù)的應用.

Samsung實驗室的Zhang等［8］提出了彈性應用模型(elasticity patterns)的概念，應用中各模塊叫做Weblet，并且支持在運行時對Weblet進行動態(tài)配置，旨在無縫并且透明地使用服務端來擴展移動設備受限的計算及存儲能力.彈性應用模型會因不同的應用配置體現(xiàn)出不同的運行時行為，比如能量消耗、資費開銷、應用性能，甚至安全與隱私特性，雖體現(xiàn)了應用部署的動態(tài)性但也存在一些缺陷，如Weblet在需要時才計算執(zhí)行的位置，也帶來了額外的開銷，影響應用執(zhí)行的效率.

通過上述研究可以發(fā)現(xiàn)，應用模型的主要工作是將應用描述為相互獨立的功能模塊.模塊的粒度可能是函數(shù)、類、或者對象，采用圖或樹的方式來表現(xiàn)應用拓撲結(jié)構，并抽象出屬性因素，建立應用代價模型.但隨著移動應用的發(fā)展，應用模型會日趨復雜，之前的研究對如何簡化應用拓撲結(jié)構并沒有提出較好的方法，所以，簡化應用拓撲結(jié)構是本文的主要的研究內(nèi)容之一.

1.2 應用部署算法的研究

應用部署算法主要包括靜態(tài)算法與動態(tài)算法2種，靜態(tài)算法具有較高的準確性，但計算量大，一般通過分類或聚類算法先期計算出預測模型，這意味著需要采集大量的用戶數(shù)據(jù)來完成機器學習，從而在新用戶接入應用時給出較優(yōu)的部署方案;而動態(tài)算法不需要進行前期學習，根據(jù)終端首次接入應用時的狀態(tài)進行實時的計算，性能及準確性不高.目前的研究成果主要包括有遍歷法［6］、線性規(guī)劃法［7］、統(tǒng)計分類法［8］、最小生成樹法［9］等幾種方式來實現(xiàn)，其中文獻［6］屬于動態(tài)算法，文獻［7－9］屬于靜態(tài)算法.

Giurgiu等［6］提出了適用于離線應用的ALL算法和適用于在線應用的K－step算法.前者通過遍歷應用模型產(chǎn)生所有可用的部署方案，并找出其中執(zhí)行時間最短的一個方案.后者選定一個入口功能模塊作為初始子集，然后計算與當前子集距離為K的所有集合，并在上述集合中再選取執(zhí)行時間最短的一個，將其作為新的子集迭代計算，直至應用模型遍歷結(jié)束或達到移動終端限制.ALL算法的優(yōu)點是可靠性高，缺點是耗時長，計算量大，并不適合實時的進行;K－step算法通過局部最優(yōu)策略計算的應用部署方案，優(yōu)點是計算速度快，計算量可控，缺點是隨著應用功能模塊的增多，算法計算量增大，且準確性下降.Giurgiu等通過測試指出在實際應用中功能模塊之間的調(diào)用次數(shù)會直接影響結(jié)果，但并沒有提出相應的解決方案.2種算法僅在應用運行前進行計算，無法實時、動態(tài)的調(diào)整.基于遍歷法的應用部署方案計算方式需要對應用所有可能的部署方案進行實時計算，計算量相當大，即使對于服務端來說也是不能忽略的.

Chun等［7］在計算應用部署方案時不僅考慮到了應用的執(zhí)行時間也考慮到了移動終端執(zhí)行時的電量消耗，其應用部署方案的計算包括靜態(tài)分析(static analyzer)、動態(tài)分析(dynamic profile)、優(yōu)化配置(optimization Solver)3個部分組成.靜態(tài)分析通過分析應用間函數(shù)調(diào)用關系，在代碼中構建遷移點和還原點，決定哪些函數(shù)可以遷移到服務端執(zhí)行，遷移點和還原點的構建也有一些限制;在動態(tài)分析中通過大量隨機用例的執(zhí)行，搜集應用中各個函數(shù)在移動終端以及在服務端執(zhí)行時的代價情況，最后通過整數(shù)線性規(guī)劃(ILP)算法得到應用最優(yōu)的結(jié)果.但該算法計算量大，而且輸入用例是隨機產(chǎn)生的，并不能保證對應用中各函數(shù)完整的覆蓋度.

由于將一個圖劃分成為K+1個滿足預先設置條件的部分，各部分之間通信量最小這個命題已被證明是一個NP－Complete問題［10］，Shumao等提出的K+1 Coarse partition應用部署算法旨在找到符合限制條件的一種應用部署方案［9］，并不要求此方案是最優(yōu)的.其算法的核心是HELVM(heavy edge light vertex)算法，HELVM 算法改進自RM、HEM 和LEM 算法［11－12］，是一種基于最小生成樹的算法.其優(yōu)點在于不僅考慮了邊的權值(功能模塊間交互)，也考慮了節(jié)點的權值(功能模塊特性如所占空間及運行內(nèi)存等)，使得帶有終端限制的應用部署方案會更加合理.但是HELVM算法不是每次都能將恰好將圖劃分成K+1個部分，每部分恰好滿足預先定義的限制(事實上大部分情況下不能)，一般需要多次執(zhí)行才能得到理想的結(jié)果.此算法的復雜度是，計算量較大.

2 改進方案

應用部署需要客戶端和服務端完成一系列的交互，其流程描述如下圖所示:

2.1 應用模型及服務模型

傳統(tǒng)的觀念將一個應用中的模塊以及模塊之間的聯(lián)系看做應用的拓撲結(jié)構，并稱之為應用模型，但隨著移動應用的發(fā)展，應用模型會日趨復雜，之前的研究對如何簡化應用模型并沒有提出較好的方法，本文提出服務模型的概念，將一個應用表示為若干個服務模型的合集，并針對服務模型進行分析處理，簡化了應用拓撲結(jié)構.例如在一個手機應用當中，可能有網(wǎng)絡通信模塊，圖形渲染模塊，圖片解碼模塊，語音采集模塊，而這些模塊之間會有數(shù)據(jù)通信，例如語音采集模塊會將采集到的語音傳送給網(wǎng)絡通信模塊進行網(wǎng)絡傳輸.將這些模塊和模塊間通信抽象出來表示就形成了應用模型.應用模型指的是應用中功能模塊的拓撲圖結(jié)構，是一種有向無環(huán)圖，其中應用功能模塊代表有向無環(huán)圖中的節(jié)點，功能模塊之間的數(shù)據(jù)交互代表有向無環(huán)圖中的邊.如果兩功能模塊之間有數(shù)據(jù)通信是單向的，則邊的表示具有方向性.

移動應用的發(fā)展使得一個應用可能包含多個服務，例如手機微信應用具有聊天服務，朋友圈服務，掃二維碼服務，(簡單類應用可視為提供單一服務).此類應用有幾個顯著的特點:

1)應用所提供各服務相對獨立;

2)應用功能模塊多、交互復雜，且一個功能模塊可能被多個服務共享;

3)應用即使具有多個服務，用戶同時也只能訪問一個服務.

這種情況下對應用的所有功能模塊進行應用部署方案計算尋找最優(yōu)配置是非常耗時且基本不能完成的，所以，本文擬采用子圖的方式來簡化應用模型.其原理是以應用中的各服務為單位構建服務模型，各服務模型的并集組成完整的應用模型.服務模型是應用模型的一個子集，也是由應用功能模塊代表的節(jié)點以及功能模塊間交互代表的邊組成，體現(xiàn)了部分的應用功能模塊的拓撲圖結(jié)構.

圖2左側(cè)的應用模型是由右側(cè)的兩個服務模型構成的，有些功能模塊被不同的服務共享，如1，3，6，8等功能模塊，而有些功能模塊則只存在于某一服務中，如16，17，18等功能模塊.由此可見，服務模型較為獨立，更容易分析，可以有效降低分析整個應用模型的復雜度，提高應用部署算法效率，而對服務模型中各功能模塊統(tǒng)計數(shù)據(jù)的匯總可以從應用層面清晰的觀察到性能瓶頸或設計問題.

應用部署的最終目的是終端接入應用時根據(jù)終端當前狀態(tài)(所處位置，網(wǎng)絡狀況，電量)決策應用模型或服務模型中哪些功能模塊在服務端執(zhí)行，哪些功能模塊在終端執(zhí)行.所以首先終端需要搜集當前的狀態(tài)信息傳輸至服務器(圖1中的step1)，服務器會根據(jù)這些信息結(jié)合應用模型信息計算出恰當?shù)牟渴鸱桨?圖1中的step2)，服務端在計算部署方案時需要以下幾類信息:

功能模塊基本信息:

1)功能模塊的類型(可移動的還是不可移動的，可移動的功能模塊可以在服務端或終端執(zhí)行);

2)當前模塊所處服務模型;

3)功能模塊的所占用的存儲空間;

4)功能模塊的運行時所占用的內(nèi)存空間;

5)功能模塊在移動終端運行時所耗電量統(tǒng)計;

6)功能模塊的移動終端運行累計時間;

7)功能模塊的數(shù)據(jù)輸入量

8)功能模塊的數(shù)據(jù)輸出量

終端實時狀態(tài)信息進行搜集，主要包括:

1)終端所接入的服務器;

2)終端當前電量;

3)終端當前網(wǎng)絡狀況;

4)終端當前CPU負載;

5)終端當前可用的內(nèi)存及存儲空間.

在終端上，這些信息采集后會被保存為XML格式的描述，然后在應用首次運行時發(fā)送到服務端.

2.2 基于貝葉斯網(wǎng)絡預測模型的應用部署算法

移動終端接入應用后，會從服務端獲得適用于當前情況的應用部署方案(圖1中step3)，部署方案是服務端根據(jù)終端當前的狀況通過一定算法運算得到的結(jié)果.本文中使用貝葉斯網(wǎng)絡預測模型來獲得應用的部署方案，基于貝葉斯網(wǎng)絡預測模型獲取應用部署方案是一種靜態(tài)算法，需要預先通過大量的數(shù)據(jù)采用機器學習過程形成預測模型，當新終端接入的時候可以根據(jù)終端當前狀態(tài)結(jié)合預測模型來確定每個功能模塊的運行位置.貝葉斯網(wǎng)絡依賴于穩(wěn)定的網(wǎng)絡拓撲結(jié)構，本文使用2.1中描述的應用模型或服務模型來做為穩(wěn)定的拓撲結(jié)構;之后貝葉斯網(wǎng)絡采集大量的數(shù)據(jù)進行機器學習，通過這些數(shù)據(jù)，可以更新每個功能模塊在在不同位置運行的概率(后稱之為預測模型).當有新的終端接入應用時，服務端會根據(jù)此終端當前的狀態(tài)以及最新的預測模型計算出每個應用功能模塊最適合的執(zhí)行位置，以求達到最好的用戶體驗.這里需要指出的是服務端在首次運行時需要事先定義初始的預測模型.

服務端運行的貝葉斯網(wǎng)絡預測模型算法實現(xiàn)如下，首先，我們假定每個可移動的功能模塊的執(zhí)行位置C依賴于此功能模塊的基本信息r、終端狀態(tài)信息s，圖3說明了一個可移動的功能模塊執(zhí)行位置的決策依據(jù)，在此功能模塊的基本信息r1以及終端當前狀態(tài)信息s1的條件下，通過概率表可得出該功能模塊在終端執(zhí)行的概率是0.8，在服務端執(zhí)行的概率是0.2，所以此功能模塊適合在終端執(zhí)行.

根據(jù)圖4以及貝葉斯網(wǎng)絡基本算法，我們可以得到任意一個功能模塊在服務端或終端執(zhí)行的概率如公式1.其中，OC代表具有r，s條件的功能模塊在服務端或者終端執(zhí)行的概率，cl代表功能模塊所有可能的執(zhí)行位置，在這里只用考慮在終端或服務端執(zhí)行2種情況;ri代表功能模塊的基本信息;sj代表終端狀態(tài)信息s;而L、M分別表示，L個功能模塊的基本信息及M個終端狀態(tài)信息.終端首次接入應用時，服務端會根據(jù)終端此時的狀態(tài)計算出適合于此終端的應用功能模塊部署方案，并將此方案傳輸?shù)浇K端，終端會根據(jù)此部署方案來對應用功能模塊進行部署.

預測模型的更新是一個機器學習的過程，預測模型包括每個功能模塊在在不同位置運行的概率數(shù)據(jù)，服務端在首次運行時需要事先定義初始的預測模型，初始的預測模型通過人為設置每個應用模塊在客戶端和服務端運行的概率表，然后通過應用上傳的數(shù)據(jù)進行更新，應用運營開始的一段時間，預測模型可能會更新的比較頻繁，但隨著應用運營的時間增長，預測模型會逐步穩(wěn)定下來.預測模型是提供給所有終端進行部署方案的依據(jù).少量終端運行時上傳的信息并不會對預測模型造成很大影響，只有大量終端運行時數(shù)據(jù)呈現(xiàn)出同樣變化趨勢(如大量終端上傳的數(shù)據(jù)表明某應用模塊在移動設備上運行時間過長)時才會對預測模型造成影響，例如有超過30%的終端上傳的數(shù)據(jù)表明某應用模塊在移動設備上運行時間長于一定值時，就會更新預測模型中概率表的數(shù)據(jù).

3 應用原型及測試

我們搭建了一個移動應用框架來模擬現(xiàn)有移動互聯(lián)網(wǎng)應用場景以及實現(xiàn)應用模塊的跨平臺運行，框架分為前后端2部分.前端基于Android平臺實現(xiàn)，后臺使用J2EE框架搭建服務器，應用模塊跨平臺運行方案例如 Rellermeyer 等的 R － OSGi［13－14］，Houacine等［15］的 MCC － OSGi，我們最后采用了改進的R－OSGi實現(xiàn)，一方面R－OSGi較為成熟穩(wěn)定，開源支持也比較好.在應用中每個模塊均由一個R－OSGi Bundle構成，不同的Bundle可以在手機中運行也可以在服務器上運行，對應用模型提供了良好的支撐.圖4是實驗終端和服務端系統(tǒng)框架圖.

位于終端的Monitor負責監(jiān)控終端狀態(tài)以及外界情況變化;客戶端的R－OSGi框架負責運行本地Bundle或通過Bundleproxy接口調(diào)用服務端的Bundle.應用服務器采用J2EE架構，并包含了核心模塊Static Partitioner、Statistic、Application Manager 及Service Manager模塊;Static Partitioner模塊負責使用貝葉斯算法計算出符合終端當前時刻狀態(tài)的應用部署方案;Statistic模塊搜集每個終端接入應用的狀態(tài)用于更新貝葉斯網(wǎng)絡;Application Manager負責對不同的應用進行管理;Service Manager負責對應用中的不同服務進行管理.

為了驗證應用部署策略中的各項理論，我們開發(fā)了一套全景人臉識別應用進行測試.該應用包含多個方便移植的功能模塊，分別是:圖片拼接、圖片預處理以及人臉識別模塊，每個既可以在手機端運行，也可以在服務端運行.應用需要在手機上通過水平方向旋轉(zhuǎn)拍攝3張照片，然后使將3張照片拼接成為一個全景照片，之后進行圖像預處理如色彩均衡和膚色分隔，最后進行人臉識別.這3個功能模塊的實現(xiàn)都來自于與OpenCV庫，OpenCV的開源性質(zhì)使得不同的功能模塊可以方便移植到不同的平臺上，是應用模塊可以部署在客戶端和服務器的前提條件，應用在運行的時候會根據(jù)不同的狀況選擇每個應用模塊執(zhí)行的位置，從而對應用的執(zhí)行時間以及效率帶來不同的影響.為了使測試結(jié)果更具有說服力，我們對后臺的部署算法進行了改進，調(diào)整了客戶端不同狀態(tài)在貝葉斯網(wǎng)絡進行概率計算時的權重，這會影響到最終的預測模型.我們分為2組共5種情況對應用進行了測試，表1是測試結(jié)果，我們將所有模塊都在終端運行的狀態(tài)作為對比參考，在這種情況下，整個應用完整運行下來大概需要30 s左右.

我們首先對Wifi/4G網(wǎng)絡狀況下的應用進行了2種不同傾向性的測試，一種是性能優(yōu)先，即應用運行時間最少，在這種情況下，預測模型將全部模塊部署到服務端運行，耗時約17 s左右，各個模塊在服務短端運行的時間很快，時間主要消耗在將初始圖片傳輸至服務端以及服務端將識別的結(jié)果傳回終端這個過程;而在能耗優(yōu)先測試中，部署算法將圖片拼接和圖片預處理置于終端運行，將人臉識別模塊置于服務端運行，因為4G網(wǎng)絡傳輸帶來的電量消耗較大，而預處理后的圖片體積較小，利于傳輸，這種情況下程序運行時間約28 s.

在2G網(wǎng)絡下，由于網(wǎng)絡傳輸速度很慢，所以在性能優(yōu)先的前提下，部署算法直接將所有模塊都部署到終端運行;在節(jié)約能耗優(yōu)先的測試中，部署算法傾向于將所有的模塊都部署到服務端運行，因為2G環(huán)境下，網(wǎng)絡傳輸?shù)哪芎妮^低，但是帶來的問題就是大量是時間被消耗在網(wǎng)絡數(shù)據(jù)傳輸?shù)倪^程中，這種情況下程序的運行時間將近60 s.不同應用部署方案測試結(jié)果如表1所示.

表1 不同應用部署方案測試結(jié)果 s

可以看出，對應用進行恰當?shù)哪K劃分并進行合理的部署可以有效提高應用運行的效率，另一方面測試的結(jié)果也驗證了部署算法在不同傾向性的前提下對應用的確起到了優(yōu)化作用.

4 結(jié)語

在以往移動互聯(lián)網(wǎng)應用部署研究的基礎上，基于目前移動應用復雜性、實時性、多樣性的發(fā)展趨勢針對應用模型及應用部署算法幾個方面進行了研究:首先通過抽象服務模型的概念，簡化了應用拓撲結(jié)構，降低應用復雜度，解決了以往應用模型用于復雜應用時導致應用部署方案計算執(zhí)行效率低的問題;其次基于應用模型或服務模型結(jié)合貝葉斯網(wǎng)的分類算法使得在服務端執(zhí)行的應用部署方案計算較以往的算法更加高效.

應用模塊的部署是一個復雜的問題，在本文測試中的應用比較簡單，模塊數(shù)量少，且是順序執(zhí)行的流程，不存在復用的問題，也不存在終端和服務器多次數(shù)據(jù)交互問題，所以測試結(jié)果較為理想;但是很多應用的功能模塊數(shù)量多，應用模型拓撲結(jié)構復雜，在這種情況下算法是否能夠取得很好的效果是我們將來的研究方向.

［1］工業(yè)和信息化部電信研究院.云計算白皮書［EB/OL］.(2014 －5 －12)［http://www.catr.cn/xwdt/kydt/201405/t20140512_1017555.htm］

［2］SATYANARAYANAN M.Mobile computing:the next decade［J］.ACM SIGMOBILE Mobile Computing and Communications Review，2011，15(2):2－10.

［3］ARMBRUST M，F(xiàn)OX A，GRIFFITH R，et al.A view of cloud computing［J］.Communications of the ACM，2010，53(4):50－58.

［4］KUMAR K，LU Y H.Cloud computing for mobile users:Can off loading computation save energy［J］.Computer，2010，43(4):51－56.

［5］徐光俠，陳蜀宇.面向移動云計算彈性應用的安全模型［J］.計算機應用，2011，31(4):952－955.

［6］GIURGIU I，RIVA O，JURIC D，et al.Calling the cloud:enabling mobile phones as interfaces to cloud applications［M］//Middleware 2009.Springer Berlin Heidelberg，2009:83－102.

［7］CHUN B G，IHM S，MANIATIS P，et al.Clonecloud:elastic execution between mobile device and cloud［C］//Proceedings of the sixth conference on computer systems.ACM，2011:301－314.

［8］ZHANG X，JEONG S，KUNJITHAPATHAM A，et al.Towards an elastic application model for augmenting computing capabilities of mobile platforms［M］//Mobile wireless middleware，operating systems，and applications.Springer Berlin Heidelberg，2010:161－174.

［9］OU S，YANG K，ZHANG J.An effective offloading middleware for pervasive services on mobile devices［J］.Pervasive and Mobile Computing，2007，3(4):362－385.

［10］MICHAEL R G，DAVID S J.Computers and intractability:a guide to the theory of NP － completeness［J］.WH Freeman ＆ Co，San Francisco，1979.

［11］KARYPIS G，KUMAR V.A fast and high quality multilevel scheme for partitioning irregular graphs［J］.SIAM Journal on scientific Computing，1998，20(1):359－392.

［12］KARYPIS G，KUMAR V.Parallel multilevel series k－way partitioning scheme for irregular graphs［J］.Siam Review，1999，41(2):278－300.

［13］RELLERMEYER J S，ALONSO G，ROSCOE T.R －OSGi:distributed applications through software modularization［C］//Proceedings of the ACM/IFIP/USENIX 2007 International Conference on Middleware.New York:Springer－Verlag，2007:1 －20.

［14］RELLERMEYER J S，RIVA O，ALONSO G.AlfredO:an architecture for flexible interaction with electronic devices［C］//Proceedings of the 9th ACM/IFIP/USENIX International Conference on Middleware.New York:Springer－Verlag，2008:22 －41.

［15］HOUACINE F，BOUZEFRANE S，LI L，et al.Mcc － osgi:An osgi－ based mobile cloud service model［C］//Autonomous Decentralized Systems(ISADS)，2013 IEEE Eleventh International Symposium on.IEEE，2013:1－8.