張晨曦，武翔宇，許 暢+

1.南京大學(xué) 計算機軟件新技術(shù)國家重點實驗室，南京 210023

2.南京大學(xué) 計算機科學(xué)與技術(shù)系，南京 210023

3.微軟（中國）有限公司蘇州分公司，江蘇 蘇州 215000

1 引言

信息時代，移動應(yīng)用的數(shù)量呈現(xiàn)爆發(fā)式的增長。截止到2017年5月，在Google Play上發(fā)布的Android應(yīng)用數(shù)量已經(jīng)從2012年的60萬增長到現(xiàn)在的280萬（https://www.statista.com/statistics/266210/numberof-available-applications-in-the-google-play-store）。同時，市場上智能手機的種類和品牌也越來越多，智能手機換代越來越頻繁，智能手機的性能和質(zhì)量也良莠不齊，這就帶來了如下問題：部分移動應(yīng)用在開發(fā)時沒有考慮智能手機本身的性能狀況和傳感器功能的完整性，其中存在大量的復(fù)雜計算，很多智能手機可能無法高效處理這些計算任務(wù)，使得應(yīng)用運行效率低下，手機運行速度緩慢，嚴重的可能會威脅電池壽命。

本文設(shè)想了下面兩個場景。

場景1某用戶正在用智能手機玩一款手機游戲，這個游戲中包含了人工智能（artificial intelligence，AI）相關(guān)的計算，AI計算任務(wù)往往需要很多的計算資源和很強的計算能力，而智能手機可能無法提供充足的計算資源進行運算，導(dǎo)致游戲運行緩慢，影響體驗。這是由于計算任務(wù)的復(fù)雜導(dǎo)致的問題。

場景2移動應(yīng)用開發(fā)過程中，開發(fā)人員往往希望用不同配置和型號的移動設(shè)備對應(yīng)用進行測試，一個有效的方法就是使用模擬器對不同的設(shè)備進行模擬，然而當應(yīng)用涉及傳感器數(shù)據(jù)的使用時，由于模擬器難以搭載傳感器的功能，這樣的測試往往無法實現(xiàn)。這是由于智能手機傳感器功能缺失導(dǎo)致的問題。

為了解決場景1所示的問題，有一種比較成熟的方法是將移動應(yīng)用內(nèi)復(fù)雜的計算任務(wù)卸載，轉(zhuǎn)移到遠程服務(wù)器上運行，并將得到的結(jié)果返回至原應(yīng)用。這種方法被稱為Computation Offloading，可以理解為計算任務(wù)的卸載與轉(zhuǎn)移執(zhí)行。

這種方法也存在著一些問題，比如使用遠程的服務(wù)器提供計算資源需要手機與服務(wù)器保持穩(wěn)定的連接狀態(tài)，這一點在復(fù)雜的網(wǎng)絡(luò)環(huán)境中難以做到。

也有研究人員給出不同的解決思路，即將計算任務(wù)轉(zhuǎn)移到其他移動設(shè)備而不是遠程服務(wù)器以避免Offloading需求出現(xiàn)在不穩(wěn)定的網(wǎng)絡(luò)環(huán)境中。

在場景2所示的傳感器故障或功能缺失這個問題上，現(xiàn)有的工作多數(shù)研究智能手機的遙感或者傳感器數(shù)據(jù)共享，很少有工作直接進行傳感器功能的借用。

CoseDroid[1]是一個面向局域網(wǎng)并同時支持移動應(yīng)用計算任務(wù)轉(zhuǎn)移執(zhí)行和移動設(shè)備傳感器功能借用的框架，其中傳感器功能的借用稱為Sensing Offloading。在CoseDroid框架中，移動設(shè)備成為計算資源和傳感器資源的提供者，同時CoseDroid給出了移動應(yīng)用的插樁方案，解決了移動設(shè)備計算能力不足和傳感器功能故障的問題。

CoseDroid雖然是由移動設(shè)備提供計算資源和傳感器資源，但是設(shè)備之間建立連接的過程和資源借用的調(diào)控仍然需要一個獨立的服務(wù)器協(xié)調(diào)和維護，這使得在不同的局域網(wǎng)中需要維護不同的獨立服務(wù)器，降低了框架的實用性。

一種直觀的想法是，移動設(shè)備之間不通過獨立的服務(wù)器，而是通過互相發(fā)現(xiàn)的方式建立連接，并且通過這種方式，移動設(shè)備間可以建立起一個互連網(wǎng)絡(luò)，網(wǎng)絡(luò)中每一個移動設(shè)備都可以作為資源的提供者，也可以作為資源的請求者；這種移動應(yīng)用計算需求和傳感器需求的Offloading表明，應(yīng)用對于屏幕資源的需求，即觸控，亦可以進行轉(zhuǎn)移，從而滿足遠程觸控和多屏幕同時控制等使用需求，本文將這種Offloading稱為Touch Offloading。

結(jié)合上述思考，本文提出了Multi Offloading，一種支持多種資源借調(diào)的安卓應(yīng)用Offloading平臺；Multi Offloading面向局域網(wǎng)中的移動設(shè)備，搭載Multi-Offloading平臺的移動設(shè)備可以自動地發(fā)現(xiàn)和連接其他設(shè)備，形成一個P2P網(wǎng)絡(luò)，平臺上的移動應(yīng)用具有“借用”其他設(shè)備計算資源、傳感器資源以及屏幕資源的能力。同時本文根據(jù)Multi Offloading的架構(gòu)設(shè)計重新實現(xiàn)和完善了CoseDroid架構(gòu)中Computation Offloading和Sensing Offloading的插樁方案并基于程序插樁技術(shù)給出了觸控轉(zhuǎn)移（Touch Offloading）的實現(xiàn)方法。

在實驗部分，本文實現(xiàn)了一個“Android應(yīng)用Offloading體驗平臺”以說明Multi Offloading平臺設(shè)計的可行性，選取了開源五子棋和涂鴉跳躍兩個移動應(yīng)用做插樁并展示Computation、Sensing和Touch Offloading的效果，同時選取了3個棋類游戲展示Computation Offloading對應(yīng)用運行效率的提升。

綜合而言，本文有如下兩個創(chuàng)新點：

（1）Multi Offloading是一個P2P平臺，搭載平臺的每個移動設(shè)備都可以借出自己的計算、傳感器、屏幕資源或者借用其他設(shè)備的資源。

（2）進一步拓展了Offloading的概念，將移動設(shè)備屏幕作為一種資源，提出屏幕資源的Offloading，即Touch Offloading，并結(jié)合已有的Computation Offloading和Sensing Offloading技術(shù)，給出了一個支持多種資源借調(diào)的安卓應(yīng)用Offloading平臺的設(shè)計方案。

本文的組織結(jié)構(gòu)如下：第2章詳細說明Multi-Offloading架構(gòu)設(shè)計和平臺中設(shè)備互連的實現(xiàn)方法；第3章介紹對CoseDroid架構(gòu)Computation Offloading、Sensing Offloading技術(shù)的重新實現(xiàn)與完善，并提出Touch Offloading技術(shù)的實現(xiàn)方法；第4章介紹針對Multi Offloading設(shè)計實現(xiàn)的一個示例，并選取應(yīng)用展示Offloading技術(shù)的實現(xiàn)效果；第5章介紹本文的相關(guān)工作；第6章總結(jié)全文并對未來研究方向進行展望。

2 Multi Offloading平臺設(shè)計

Multi Offloading是一個面向局域網(wǎng)的Android應(yīng)用Offloading平臺?，F(xiàn)有工作多數(shù)使用一個特定的服務(wù)器作為計算資源的提供方，這種方法存在一些問題，歸納如下：

問題1服務(wù)器往往與移動設(shè)備處于不同的系統(tǒng)環(huán)境中，這會導(dǎo)致一些在Android環(huán)境中可以被運行的代碼被轉(zhuǎn)移到服務(wù)器環(huán)境中無法運行。

問題2在局域網(wǎng)環(huán)境中，特定的服務(wù)器需要有固定的IP地址和配置。當局域網(wǎng)環(huán)境變化時（比如遷移到另一個局域網(wǎng)），之前網(wǎng)絡(luò)中的服務(wù)器配置可能難以適配到現(xiàn)在的局域網(wǎng)，使得設(shè)備需要和服務(wù)器重新連接，服務(wù)器也需要重新配置。

問題3移動設(shè)備的Offloading需求常常會發(fā)生變化，比如對于不同的移動應(yīng)用，可能有不同的計算任務(wù)，需要不同的代碼片段來執(zhí)行，預(yù)先在服務(wù)器中準備好這些代碼是極其困難的。

CoseDroid框架解決了問題1和問題3，對于問題2，由于CoseDroid使用了一個獨立的名服務(wù)器（Name Server）以建立和維護設(shè)備之間的連接，當局域網(wǎng)本身發(fā)生變化時，需要重新維護和配置名服務(wù)器，為框架的實用性帶來了問題。

基于對上述問題的思考，本文將Multi Offloading設(shè)計為一個以設(shè)備發(fā)現(xiàn)為連接主導(dǎo)的Offloading平臺。在這個平臺上，每一個移動設(shè)備既可以成為建立互連網(wǎng)絡(luò)的發(fā)起者，也可以成為建立互連網(wǎng)絡(luò)的響應(yīng)者。

圖1展示了Multi Offloading架構(gòu)。下面將詳細描述Multi Offloading的架構(gòu)設(shè)計和平臺上各個設(shè)備之間建立連接的過程。

Fig.1 Architecture of Multi Offloading圖1 Multi Offloading架構(gòu)

2.1 Multi Offloading平臺架構(gòu)

Multi Offloading平臺由四部分構(gòu)成：客戶端部分（Client Part）、服務(wù)器部分（Server Part）、插樁后的移動應(yīng)用（InstrumentedApp）和連接器（Connector）。

搭載Multi Offloading平臺的移動設(shè)備通過連接器互相發(fā)現(xiàn)并建立TCP連接，形成一個P2P網(wǎng)絡(luò)。而Multi Offloading內(nèi)部采用客戶端/服務(wù)器（Client-Server）架構(gòu)，客戶端部分承載了顯示圖形界面、開啟應(yīng)用等功能，服務(wù)器部分負責(zé)處理客戶端的請求，并反饋給客戶端和需要Offloading的移動應(yīng)用。

在平臺內(nèi)部，客戶端部分、服務(wù)器部分、移動應(yīng)用之間通過廣播（Broadcast）互相傳遞請求和響應(yīng)；在互連的移動設(shè)備之間，客戶端部分、服務(wù)器部分通過TCP連接發(fā)送請求和響應(yīng)。這樣每臺移動設(shè)備都可以提供資源或請求資源。

這種架構(gòu)設(shè)計解決了之前歸納的3個問題。

對于問題1，在本文的架構(gòu)中，每個移動設(shè)備都可以作為服務(wù)器提供資源，設(shè)備之間系統(tǒng)環(huán)境基本相同，因此不會出現(xiàn)由于系統(tǒng)環(huán)境原因?qū)е麓a片段無法執(zhí)行的情況。

對于問題2，移動設(shè)備以互相發(fā)現(xiàn)的方式建立連接，這就是說移動設(shè)備之間可以隨時連接、隨時斷開，這非常符合移動設(shè)備網(wǎng)絡(luò)環(huán)境易變動的特點，而且每臺移動設(shè)備都可以作為服務(wù)器，服務(wù)器環(huán)境不需要靜態(tài)配置。

對于問題3，本文和CoseDroid一樣給平臺客戶端部分增加了文件發(fā)送的功能，請求計算資源的設(shè)備會提前準備好需要執(zhí)行的代碼片段，然后在請求服務(wù)時發(fā)送給服務(wù)設(shè)備，然后由服務(wù)設(shè)備動態(tài)加載執(zhí)行該代碼片段。

對這3個問題的解決說明本文設(shè)計的Multi-Offloading平臺可以很好地處理設(shè)備互連和計算任務(wù)轉(zhuǎn)移的相關(guān)問題。下面將說明Multi Offloading如何讓設(shè)備之間互相發(fā)現(xiàn)和連接。

2.2 設(shè)備發(fā)現(xiàn)與設(shè)備互連

局域網(wǎng)中搭載Multi Offloading平臺的移動設(shè)備之間的發(fā)現(xiàn)和互連是由連接器完成的，如圖2所示，連接器由四部分組成：搜索管理器（Search Manager）、設(shè)備搜索器（Searcher）、連接建立器（Connect Creator）和搜索響應(yīng)器（Responser）。

Fig.2 Connector components圖2 連接器組成

如圖2所示，這四部分賦予了移動設(shè)備兩個可選角色，一個是作為主機的搜索者，另一個是等待主機搜索的響應(yīng)者，圖3和圖4完整地展示了設(shè)備之間建立連接的流程。

為了實現(xiàn)局域網(wǎng)中設(shè)備之間的互相發(fā)現(xiàn)，連接器的實現(xiàn)使用了UDP廣播的方法。由于UDP本身是不可靠的連接協(xié)議，連接器在每次使用UDP廣播進行通訊的時候都模擬了類似于TCP連接的“3次握手”協(xié)議。圖3、圖4所示的連接流程可以分為3個階段，其中前兩個階段都會經(jīng)歷“3次握手”協(xié)議。

Fig.3 Device finding圖3 設(shè)備發(fā)現(xiàn)

Fig.4 Device connection and device interconnection圖4 設(shè)備連接與設(shè)備互連

階段1（設(shè)備發(fā)現(xiàn)）當一個設(shè)備選擇作為主機進行搜索時，搜索管理器會通知設(shè)備搜索器進行搜索，即向局域網(wǎng)內(nèi)發(fā)出UDP廣播，這個廣播附帶自身編號和搜索器預(yù)先設(shè)定的廣播類型（例如類型“搜索廣播”）；此時，選擇作為響應(yīng)者的設(shè)備會開啟搜索響應(yīng)器，搜索響應(yīng)器接收到主機發(fā)出的UDP廣播并對廣播內(nèi)容進行校驗，這是“第一次握手”。

響應(yīng)設(shè)備校驗成功后，搜索響應(yīng)器會發(fā)出一個帶有校驗信息的UDP廣播，主機在接收到這個廣播后會再次進行校驗，這就是“第二次握手”。

主機的設(shè)備搜索器校驗成功后，會再次發(fā)出廣播，并通知搜索管理器發(fā)現(xiàn)了想要連接的設(shè)備，并且獲得該設(shè)備的IP地址等信息，使得搜索管理器開始第二階段的連接部分，這是“第三次握手”。

階段2（設(shè)備連接）在確認可以連接的移動設(shè)備的IP地址后，主機的搜索管理器會通知連接建立器進行第二輪的UDP廣播。此時連接建立器會發(fā)出一個攜帶信息的UDP廣播，信息內(nèi)容即為響應(yīng)者的IP地址。響應(yīng)者在接到UDP廣播后，會首先校驗廣播中要連接的IP地址是否為自身的IP地址，如果不是，就忽略廣播報文；如果是，就發(fā)送回復(fù)的UDP報文，完成“第一次握手”。

主機接到回復(fù)廣播后，校驗其IP地址，完成“第二次握手”，隨后發(fā)送回復(fù)廣播，廣播報文中會攜帶即將打開的新端口的端口號，并打開新的套接字（Socket）端口，等待響應(yīng)者連接。

響應(yīng)者接到回復(fù)的UDP廣播，進行校驗，完成“第三次握手”；獲得主機的IP地址和開放端口號，進而與主機建立TCP連接。由于TCP連接本身是可靠連接，因此不需要進行額外校驗。這樣，通過前兩個階段，主機就可以發(fā)現(xiàn)響應(yīng)主機搜索的設(shè)備并建立起穩(wěn)定連接。

階段2描述的是兩個設(shè)備之間的連接過程，第三階段會建立多設(shè)備之間的連接網(wǎng)絡(luò)。

階段3（設(shè)備互連）主機在與響應(yīng)設(shè)備建立連接后，會將與主機相連的所有設(shè)備的IP信息通過TCP連接發(fā)送給響應(yīng)設(shè)備；同時主機會將響應(yīng)設(shè)備的IP信息發(fā)送給每個與之相連的移動設(shè)備，讓每個設(shè)備都打開新的Socket端口，等待響應(yīng)設(shè)備進行連接。

響應(yīng)設(shè)備接到主機發(fā)來的網(wǎng)絡(luò)中所有設(shè)備的IP信息后，會逐一連接每個設(shè)備，與每個設(shè)備都建立TCP連接。這樣就在原來的互連網(wǎng)絡(luò)中新增了一臺移動設(shè)備，同時在此互連過程中，響應(yīng)者也會獲得一個唯一標號或標識來確定其在網(wǎng)絡(luò)中的身份。

注意到，在響應(yīng)者與其他設(shè)備建立連接后，它們在網(wǎng)絡(luò)中的地位都是一樣的，主機和響應(yīng)者只是不同設(shè)備在建立連接時所采用的不同角色，避免了連接網(wǎng)絡(luò)中單點失效的問題。

在這3個階段中，兩次模擬“3次握手”協(xié)議，避免了使用UDP廣播可能帶來的網(wǎng)絡(luò)不可靠問題。

3 Offloading技術(shù)實現(xiàn)

移動應(yīng)用一般不具有Offloading自身計算任務(wù)和傳感器需求的能力，對移動應(yīng)用進行插樁，使其具備這樣的能力，并配合平臺中的其他組件一起滿足自身Offloading的需求。

插樁（Instrumentation）是分析和處理程序的常用技術(shù)，程序員通?？梢栽诔绦騼?nèi)部插入一些自己的代碼，這些代碼可以提供程序運行時的信息，比如程序運行時的堆棧信息、代碼覆蓋率信息等。同樣編程人員也可以對移動應(yīng)用進行插樁，在應(yīng)用中插入某些代碼，實現(xiàn)特定的程序行為和程序邏輯。

圖5展示了一般應(yīng)用的插樁流程。

Fig.5 Application instrumentation process圖5 應(yīng)用插樁流程

本文針對字節(jié)碼插樁使用的工具是Soot（http://sable.github.io/soot）。Soot是一個程序分析框架，它一開始是用來對Java程序做靜態(tài)分析從而進行代碼優(yōu)化，現(xiàn)在也可以用來進行移動應(yīng)用代碼的插樁。Soot可以接收應(yīng)用的源代碼，也可以接收應(yīng)用的字節(jié)碼，但是由于很多真實應(yīng)用沒有開源，源碼不便獲取，因此編程人員在插樁時一般使用的是Soot對字節(jié)碼的處理能力。

Soot會把Java字節(jié)碼或者是apk文件轉(zhuǎn)換成一種三地址中間代碼，稱為Jimple代碼；同時Soot也封裝了一些使用Java代碼編寫Jimple代碼的接口，從而可以通過編寫Jimple代碼修改程序行為邏輯，屏蔽了直接對字節(jié)碼插樁的復(fù)雜性。

本文設(shè)計實現(xiàn)的Computation Offloading、Sensing Offloading和Touch Offloading技術(shù)就是基于應(yīng)用插樁完成的。

3.1 Computation Offloading技術(shù)實現(xiàn)

Computation Offloading技術(shù)希望可以將應(yīng)用中部分涉及復(fù)雜計算的任務(wù)動態(tài)轉(zhuǎn)移到高性能設(shè)備上執(zhí)行，然后返回結(jié)果，使應(yīng)用能夠高效地運行。

這里本文結(jié)合Multi Offloading架構(gòu)對CoseDroid的插樁思想進行了重新實現(xiàn)。

CoseDroid實現(xiàn)Computation Offloading技術(shù)的核心思想為：對于可轉(zhuǎn)移的方法，記錄其簽名、所屬類名、參數(shù)，序列化調(diào)用對象；將對象傳輸至服務(wù)設(shè)備通過Java反射機制動態(tài)加載字節(jié)碼片段，執(zhí)行該方法，并將執(zhí)行結(jié)束后的結(jié)果和調(diào)用對象一同返回；最后將返回對象的每一個域拷貝給原對象。

基于上述目標，本文設(shè)計了如圖6所示的插樁流程。

Fig.6 Computation Offloading instrumentation process圖6 Computation Offloading插樁流程

并不是所有的方法都是可轉(zhuǎn)移的，可轉(zhuǎn)移的方法要求方法執(zhí)行前后只對調(diào)用對象本身的域（Field）造成影響，不會對系統(tǒng)狀態(tài)和其他程序狀態(tài)造成影響。對于類C中的方法m（帶有引用對象的參數(shù)p）是否可轉(zhuǎn)移，本文結(jié)合Multi Offloading架構(gòu)將其總結(jié)為表1所示的4個條件（判定結(jié)果為“是”則不滿足條件）。

流程中插入了預(yù)備字節(jié)碼檢測環(huán)節(jié)，其意義在于，當計算資源的提供設(shè)備沒有應(yīng)該執(zhí)行的字節(jié)碼片段時，該環(huán)節(jié)會提醒Multi Offloading平臺及時發(fā)送所需字節(jié)碼片段給計算設(shè)備；如果請求設(shè)備也沒有預(yù)備應(yīng)該執(zhí)行的字節(jié)碼片段，該環(huán)節(jié)則會終止Offloading請求，使該方法本地執(zhí)行，以免產(chǎn)生傳輸錯誤，保證了Computation Offloading請求過程的魯棒性。

Table 1 Conditions of Offloadable methods表1 方法可轉(zhuǎn)移條件

3.2 Sensing Offloading技術(shù)實現(xiàn)

Sensing Offloading技術(shù)希望某些因為移動設(shè)備傳感器故障或者功能缺失而不能運行的應(yīng)用，可以借用其他設(shè)備的傳感器功能，通過其他設(shè)備的傳感器獲得數(shù)據(jù)，以維持應(yīng)用的正常運行。

為了說明Sensing Offloading的插樁方法，這里簡介Android應(yīng)用是如何使用傳感器的。Android應(yīng)用的開發(fā)工具Android SDK實現(xiàn)了一個Android傳感器框架（Android sensor framework，ASF，https://developer.android.com/guide/topics/sensors/sensors_overview.html），里面包含著使用設(shè)備傳感器的接口。

Android應(yīng)用可以通過ASF提供的getSystem-Service方法獲得SensorManager類的實例對象，再通過getDefaultSensor獲取希望使用的傳感器實例（如重力傳感器的編號是TYPE_GRAVITY），在獲得傳感器實例后，Android應(yīng)用可以通過registerListener和unregisterListener兩種方法注冊和注銷SensorEvent-Listerner接口實現(xiàn)對傳感器數(shù)據(jù)的獲取、精度變化的感知等。

CoseDroid提出通過監(jiān)控registerListener和unregisterListener兩種方法獲得Android應(yīng)用傳感器的注冊/注銷信息，并使用改寫的SensorEventListener實例替換原應(yīng)用注冊的傳感器事件處理器，從而實現(xiàn)傳感器的借用。

本文根據(jù)上述思想設(shè)計了如圖7所示的插樁流程。

Fig.7 Sensing Offloading instrumentation process圖7 Sensing Offloading插樁流程

經(jīng)過這兩步的插樁，插樁應(yīng)用在運行時會注冊預(yù)先寫好的一個傳感器數(shù)據(jù)處理器，而這個處理器會從提供傳感器服務(wù)的設(shè)備上獲取數(shù)據(jù)，然后返回給應(yīng)用，使得插樁應(yīng)用檢測到運行設(shè)備具有了所需傳感器的功能。

3.3 Touch Offloading技術(shù)實現(xiàn)

移動應(yīng)用對于屏幕資源的需求也可以像其計算需求和傳感器需求一樣被轉(zhuǎn)移，即觸摸控制（Touch）的轉(zhuǎn)移，意義在于實現(xiàn)遠程觸控，例如以一臺設(shè)備作為控制板控制多臺設(shè)備進行同步演示等。本文把這種Offloading稱為Touch Offloading。

對于Touch Offloading技術(shù)的實現(xiàn)，本文設(shè)計了圖8所示的插樁流程。

在移動應(yīng)用中，onTouch方法是其處理觸控指示的方法。插樁工具會定位到這個方法，并將其替換為預(yù)先編寫好的onTouch方法，同時給應(yīng)用插入的廣播接收器會接收觸控設(shè)備發(fā)出的觸控信息，即觸屏的具體坐標，從而使用MoveEvent類（Android架構(gòu)中觸摸事件類）觸發(fā)對Offloading設(shè)備的觸摸操作，完成觸控設(shè)備對Offloading設(shè)備的遠程觸控。

Fig.8 Touch Offloading instrumentation process圖8 Touch Offloading插樁流程

值得關(guān)注的是，本文對移動應(yīng)用的插樁是一種輕量級的插樁，不會影響在沒有Offloading平臺下移動應(yīng)用的運行。

因此，在3種Offloading技術(shù)的插樁中本文都加入了關(guān)于執(zhí)行模式的判斷，如果應(yīng)用不是由Multi-Offloading平臺打開運行的，那么：

被Offloading的方法不會做任何處理，在原設(shè)備上執(zhí)行；應(yīng)用原來的傳感器事件處理器不會被替換，繼續(xù)獲取本機上的傳感器數(shù)據(jù)；管理觸控的onTouch方法不會被修改，依然可以觸摸設(shè)備屏幕對應(yīng)用進行控制。

當用戶正常打開插樁后的Android應(yīng)用時，應(yīng)用會如沒有被修改過一般正常運行。

4 實驗評估

4.1 實驗設(shè)計與實現(xiàn)

為了說明Multi Offloading平臺設(shè)計的可行性，開發(fā)了一個“Android應(yīng)用Offloading體驗平臺”（簡稱為Offloading體驗平臺）。圖9展示了Offloading體驗平臺的主界面，可以看到，主界面除了啟動應(yīng)用、建立連接、打開說明和改變計算任務(wù)轉(zhuǎn)移目標外，還可以顯示設(shè)備是否已經(jīng)互連形成Offloading網(wǎng)絡(luò)，如果已互連，那么頂端會顯示當前設(shè)備的編號。

在Offloading體驗平臺上，本文選取了兩個移動應(yīng)用來展示Offloading技術(shù)的實現(xiàn)效果。

對于Computation Offloading的展示，本文選取開源五子棋游戲作為展示應(yīng)用。在這個五子棋應(yīng)用中存在一個基于人工智能算法的方法，這個方法用于計算電腦下一步的最佳落子點，這個方法的執(zhí)行效率影響著整個應(yīng)用的運行效果，非常適合展示計算任務(wù)的轉(zhuǎn)移執(zhí)行對程序運行效率的影響。

Fig.9 Home screen of Offloading experience platform圖9 Offloading體驗平臺主界面

對于Sensing Offloading和Touch Offloading的展示，本文選擇涂鴉跳躍（doodle jump）作為展示應(yīng)用。涂鴉跳躍是一款利用加速度傳感器控制人物保持跳躍并躲避障礙的游戲，這款游戲只使用了加速度傳感器，用來展示傳感器資源的借用非常合適，它本身還有比較簡潔的操作界面，也適合于展示觸控轉(zhuǎn)移。

除了驗證Multi Offloading平臺設(shè)計和Computation、Sensing、Touch Offloading插樁技術(shù)的可行性，本文還希望探究Computation Offloading后Android應(yīng)用的運行效率提高的程度，即應(yīng)用運行時間的減少程度。

本文在開源五子棋應(yīng)用之外又挑選了Github上兩個棋類游戲GoBang（五子棋）和Othello（黑白棋），通過比較這3個游戲Offloading前后連續(xù)10步棋的平均時間，觀察應(yīng)用運行時間是否減少和減少的程度。

結(jié)合上述實驗?zāi)康?，本文提?個研究問題。

問題1將Android應(yīng)用的復(fù)雜計算轉(zhuǎn)移給更高性能的設(shè)備執(zhí)行是否可行，相同步驟內(nèi)應(yīng)用運行時間是否明顯減少。

問題2本文Sensing Offloading的插樁方法是否可以使Android應(yīng)用正確接收其他設(shè)備的傳感器數(shù)據(jù)進而正常運行。

問題3本文Touch Offloading插樁技術(shù)是否能夠?qū)崿F(xiàn)觸控轉(zhuǎn)移，即在控制者屏幕上進行點擊是否能在顯示者屏幕上相同位置產(chǎn)生點擊事件（轉(zhuǎn)移觸控的設(shè)備稱為控制者，接受控制的設(shè)備稱為顯示者）。

在展示實驗結(jié)果之前，先說明本文的實驗環(huán)境，本文使用兩臺三星Galaxy S5、1臺華為P6、1臺華為Mate7在1 167 Mb/s的Wifi局域網(wǎng)下進行實驗。

4.2 實驗結(jié)果

4.2.1 Computation Offloading效果展示

對于問題1，本文選用華為P6和華為Mate7兩臺設(shè)備進行實驗，根據(jù)配置說明，Mate7性能明顯高于P6。圖10和圖11分別展示了在P6設(shè)備上運行開源五子棋在Offloading前后1步棋的所需時間。為了更直觀地展示實驗效果，在插樁時重復(fù)多次運行Offloading的方法，在開源五子棋應(yīng)用的展示中，Offloading的方法被執(zhí)行了500次，在后面的實驗中也會對其他應(yīng)用Offloading的方法重復(fù)執(zhí)行合適的倍數(shù)。

Fig.10 One step time consumption on P6 before Offloading圖10 Offloading前P6運行五子棋的1步耗時

實驗中五子棋游戲運行正常，未出現(xiàn)游戲崩潰的情況。

Fig.11 One step time consumption on P6 after Offloading圖11 Offloading后P6運行五子棋的1步耗時

為了探究應(yīng)用運行時間的減少，本文對GoBang和Othello做了類似的插樁，比較Offloading前后連續(xù)10步棋的平均時間，得到表2。

Table 2 Time consumption of three chess games before and after Offloading表2 3個棋類游戲Offloading前后耗時比較

從表2可以看出，Computation Offloading對Android應(yīng)用運行時間的減少具有可觀的效果。

4.2.2 Sensing Offloading效果展示

對于問題2，本文使用兩臺三星設(shè)備進行實驗，其中提供傳感器數(shù)據(jù)的設(shè)備稱為控制者，接收傳感器數(shù)據(jù)的設(shè)備稱為顯示者。左右搖晃控制者，顯示者中由加速度傳感器控制的人物跟隨控制者進行基本無延遲的左右跳躍；而左右搖晃顯示者未對游戲造成任何影響。

圖12展示了控制者（左）向左搖，游戲中人物（右）跟隨著向左跳躍的情景。說明文中Sensing Offloading的插樁方法能夠使Android應(yīng)用成功借用其他設(shè)備的傳感器功能。

4.2.3 Touch Offloading效果展示

Fig.12 Sensing Offloading effect圖12 Sensing Offloading效果展示

對于問題3，本文同樣使用兩個三星設(shè)備進行實驗。為了能夠確認控制者上的點擊信息輸?shù)搅孙@示者，在插入廣播接收器時注冊了額外的廣播信號，使得顯示者在接收到控制者的點擊信息時，以點擊點為中心繪制圓環(huán)。這樣既可以看到控制者上的點擊是否傳遞給了顯示者，又可以判斷顯示設(shè)備接收到的數(shù)據(jù)是否正確。

實驗時，在控制者的控制板上進行隨意點擊，同時觀察顯示者屏幕上的圓環(huán)位置，結(jié)果圓環(huán)中心與顯示者屏幕的相對位置，與點擊點與觸控設(shè)備屏幕的相對位置基本一致；在控制板上點擊顯示者涂鴉跳躍游戲界面上的按鈕的相對位置，顯示者的游戲界面做出和直接點擊按鈕一樣的跳轉(zhuǎn)。圖13展示了點擊觸控設(shè)備控制板后，顯示設(shè)備在同樣的相對位置出現(xiàn)圓環(huán)的情景。

Fig.13 Touch Offloading effect圖13 Touch Offloading效果展示

這說明本文給出的Touch Offloading插樁方法可以有效實現(xiàn)觸控轉(zhuǎn)移。

綜合上述3個實驗結(jié)果，可以得出結(jié)論，本文設(shè)計的Multi Offloading平臺架構(gòu)具有可行性，本文重新實現(xiàn)并完善的Computation Offloading和Sensing Offloading插樁技術(shù)，提出的Touch Offloading插樁技術(shù)可以使Android應(yīng)用具有借用其他設(shè)備資源的能力，并且Computation Offloading對Android應(yīng)用的運行時間有可觀的減少。

5 相關(guān)工作

本文提出的Multi Offloading是一個同時支持Computation Offloading、Sensing Offloading和 Touch Offloading的Android應(yīng)用Offloading平臺，而對于Offloading技術(shù)也已經(jīng)有許多相關(guān)研究。

起初關(guān)于Offloading的研究主要針對于個人電腦（personal computer，PC）應(yīng)用，由于服務(wù)器的性能明顯優(yōu)于PC的性能，并且部分PC程序邏輯復(fù)雜，計算任務(wù)重，因此將PC應(yīng)用繁雜的計算轉(zhuǎn)移到服務(wù)器上運行可以明顯提升性能。Javaparty[2]和J-Orchestra[3]關(guān)注PC上Java應(yīng)用的遠程執(zhí)行，使用用戶標注和程序分析的方法，基于Java的遠程方法調(diào)用（remote method invocation，RMI）技術(shù)，將需要計算的方法所屬對象傳輸至服務(wù)器上執(zhí)行，但因為Android平臺不支持RMI技術(shù)，所以這兩份工作難以直接移植到Android平臺。

也有一些對非Android平臺的應(yīng)用Offloading技術(shù)的研究工作。Maui[4]就是面向Windows Phone平臺的應(yīng)用和設(shè)備的Offloading工作，工作語言和處理對象是C#語言和.NET程序，其工作核心是遠程過程調(diào)用（remote procedure call，RPC），在運行時決定哪些方法應(yīng)該轉(zhuǎn)移執(zhí)行，然后做程序分割；Maui提供了一個編程環(huán)境并允許用戶標注哪些方法可以被轉(zhuǎn)移執(zhí)行，并在運行時判斷這種方法是否真的可以O(shè)ffloading。Wang等人[5]的工作面向支持Java的移動設(shè)備，這份工作的重點在于面向?qū)ο蟪绦蛑械某绦蚍指?，使用靜態(tài)分析的方法首先建立一個帶權(quán)值的對象關(guān)系圖，然后根據(jù)這個對象關(guān)系圖二次建模將其中的對象劃分成本地執(zhí)行的部分和服務(wù)器執(zhí)行的部分，并對劃分成服務(wù)器部分的對象進行轉(zhuǎn)移執(zhí)行。Rim等人[6]的工作同樣面向運行JVM的移動設(shè)備，通過對Java應(yīng)用的插樁實現(xiàn)方法的Offloading。

在這些針對非Android平臺的工作出現(xiàn)的年代，Android平臺還沒有成熟?，F(xiàn)在流行的移動平臺是Android平臺和iOS平臺，由于iOS系統(tǒng)閉源等特點，iOS應(yīng)用難以分析和處理；相比之下，Android是一個開源系統(tǒng)，存在許多Android應(yīng)用的分析工具，比如Soot，因此現(xiàn)在大部分工作都集中在Android平臺上，尤其是Android應(yīng)用的Computation Offloading。

Cuckoo[7]提供了一個Android應(yīng)用Computation Offloading的編程模型，它要求開發(fā)者在這個編程模型下開發(fā)應(yīng)用。在Cuckoo的編程模型中，開發(fā)人員需要在本地的“服務(wù)（Service）”部分定義需要Offloading的方法接口，這個Service是支持RPC的，同時Cuckoo框架會自動在遠程服務(wù)器生成本地Service中接口的拷貝；在應(yīng)用開發(fā)時，開發(fā)人員在本地Service中實現(xiàn)之前定義的方法接口，覆蓋遠程Service中的接口；進而在應(yīng)用運行調(diào)用這些方法時，會主動請求服務(wù)器執(zhí)行這些方法，完成計算的Offloading。與Cuckoo相似的工作還有Chen等人[8]，但是它不需要開發(fā)者在特定的編程模型下開發(fā)，而是處理以特定開發(fā)模式開發(fā)的Android應(yīng)用，對于每個用戶，Chen等人[8]都在云端服務(wù)器上部署一個虛擬移動設(shè)備，并將計算任務(wù)轉(zhuǎn)移到虛擬設(shè)備上運行。上述兩份工作對Offloading技術(shù)的實現(xiàn)主要依靠Android應(yīng)用的開發(fā)模式，而DPartner[9]是通過字節(jié)碼重寫的方式重構(gòu)一個Android應(yīng)用，支持不同粒度的計算轉(zhuǎn)移。

在Computation Offloading研究中，也有工作不是進行方法上的Offloading，而是從應(yīng)用內(nèi)部線程、服務(wù)器資源、能耗等多方面考察Offloading的可行性。CloneCloud[10]和COMET[11]關(guān)注于多線程Android應(yīng)用中線程的Offloading。它們不是方法驅(qū)動的Offloading策略，而是線程驅(qū)動的策略；COMET沒有對應(yīng)用字節(jié)碼進行修改，而是修改Dalvik虛擬機，其所有操作都建立在Java內(nèi)存模型上，并使用分布式共享內(nèi)存模型，提高了Offloading效率。COSMOS[12]關(guān)注云服務(wù)器資源的調(diào)度和網(wǎng)絡(luò)連接情況的權(quán)衡，ECOS[13]關(guān)注Offloading中的隱私安全問題，而Mukherjee等人[14]則先對應(yīng)用本身Offloading的能耗進行評估，以應(yīng)用Offloading后的能耗是否減小為基準判斷應(yīng)用是否值得Offloading。

在Sensing Offloading的研究上，文獻[15]可以理解為一種Crowd Sensing，它是讓中央節(jié)點分發(fā)若干傳感器相關(guān)的任務(wù)給不同的移動設(shè)備，移動設(shè)備可以接受任務(wù)并完成，也就實現(xiàn)了傳感器的合作。Yang等人[15]的關(guān)注點在于設(shè)備之間的利益問題，而本文的工作側(cè)重于一對一的傳感器服務(wù)，重點在于如何使得Android應(yīng)用獲得使用其他設(shè)備傳感器的能力。Rachuri等人[16]考慮的是社交行為中傳感器的Offloading，他們認為一直使用本機的傳感器記錄人的社交行為有很大的開銷，于是他們考慮在環(huán)境中部署相應(yīng)的傳感器，進而可以使用這些環(huán)境中的傳感器替代本機的傳感器，達到節(jié)省開銷的目的。Rachuri等人通過實驗歸納出一些適宜在環(huán)境中部署的傳感器，并根據(jù)歸納結(jié)果提出了一個Sensing Offloading框架，提供了一種編程模式，用于與社交行為有關(guān)的Android應(yīng)用的開發(fā)。與本文工作不同的是，本文通過對Android應(yīng)用進行輕量級的插樁，就可以使應(yīng)用具有Offloading傳感器需求的能力，但是如果希望得到一個可以和環(huán)境傳感器交互的Android應(yīng)用，往往需要開發(fā)人員依照Metis框架重新開發(fā)，很難通過修改應(yīng)用得到。

在多種Offloading同時支持的研究問題上，Cose-Droid[1]是一個同時支持Computation和Sensing的Android應(yīng)用Offloading框架，關(guān)注計算任務(wù)和傳感器Offloading后的能耗降低問題；與本文不同的是，CoseDroid在移動設(shè)備建立互連時仍然使用了一個名服務(wù)器為媒介，設(shè)備之間依靠獨立的服務(wù)器建立連接，同時本文對CoseDroid的Offloading技術(shù)做了拓展，提出了Touch Offloading技術(shù)。

6 總結(jié)與展望

本文給出了一個Android應(yīng)用Offloading平臺的設(shè)計與實現(xiàn)方案，Multi Offloading。Multi Offloading同時支持Android應(yīng)用進行Computation Offloading、Sensing Offloading和 Touch Offloading，搭載 Multi-Offloading的移動設(shè)備可以互相發(fā)現(xiàn)并建立連接，形成一個P2P網(wǎng)絡(luò)。

本文重新實現(xiàn)和完善了已有工作的Computation Offloading和Sensing Offloading插樁技術(shù)，并提出Touch Offloading的輕量級程序插樁實現(xiàn)方案；使得插裝后的Android應(yīng)用具有觸控轉(zhuǎn)移的能力和借用P2P網(wǎng)絡(luò)中移動設(shè)備計算資源、傳感器資源的能力。

本文的工作還有繼續(xù)完善的空間，觸控是Android應(yīng)用進行響應(yīng)的最基本的輸入。除此以外，有些Android應(yīng)用還會響應(yīng)手勢、攝像機和指紋等輸入，實現(xiàn)指紋輸入的Offloading有利于實現(xiàn)遠程解鎖等功能。未來會逐步實現(xiàn)手勢、攝像機、指紋的Offloading，擴展Offloading的概念，實現(xiàn)Android應(yīng)用控制的轉(zhuǎn)移。