Multi Offloading：支持多種資源借調的安卓應用平臺*

張晨曦，武翔宇，許 暢+

1.南京大學 計算機軟件新技術國家重點實驗室，南京 210023

2.南京大學 計算機科學與技術系，南京 210023

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

1 引言

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

本文設想了下面兩個場景。

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

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

為了解決場景1所示的問題，有一種比較成熟的方法是將移動應用內復雜的計算任務卸載，轉移到遠程服務器上運行，并將得到的結果返回至原應用。這種方法被稱為Computation Offloading，可以理解為計算任務的卸載與轉移執行。

這種方法也存在著一些問題，比如使用遠程的服務器提供計算資源需要手機與服務器保持穩定的連接狀態，這一點在復雜的網絡環境中難以做到。

也有研究人員給出不同的解決思路，即將計算任務轉移到其他移動設備而不是遠程服務器以避免Offloading需求出現在不穩定的網絡環境中。

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

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

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

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

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

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

綜合而言，本文有如下兩個創新點：

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

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

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

2 Multi Offloading平臺設計

Multi Offloading是一個面向局域網的Android應用Offloading平臺。現有工作多數使用一個特定的服務器作為計算資源的提供方，這種方法存在一些問題，歸納如下：

問題1服務器往往與移動設備處于不同的系統環境中，這會導致一些在Android環境中可以被運行的代碼被轉移到服務器環境中無法運行。

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

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

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

基于對上述問題的思考，本文將Multi Offloading設計為一個以設備發現為連接主導的Offloading平臺。在這個平臺上，每一個移動設備既可以成為建立互連網絡的發起者，也可以成為建立互連網絡的響應者。

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

Fig.1 Architecture of Multi Offloading圖1 Multi Offloading架構

2.1 Multi Offloading平臺架構

Multi Offloading平臺由四部分構成：客戶端部分（Client Part）、服務器部分（Server Part）、插樁后的移動應用（InstrumentedApp）和連接器（Connector）。

搭載Multi Offloading平臺的移動設備通過連接器互相發現并建立TCP連接，形成一個P2P網絡。而Multi Offloading內部采用客戶端/服務器（Client-Server）架構，客戶端部分承載了顯示圖形界面、開啟應用等功能，服務器部分負責處理客戶端的請求，并反饋給客戶端和需要Offloading的移動應用。

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

這種架構設計解決了之前歸納的3個問題。

對于問題1，在本文的架構中，每個移動設備都可以作為服務器提供資源，設備之間系統環境基本相同，因此不會出現由于系統環境原因導致代碼片段無法執行的情況。

對于問題2，移動設備以互相發現的方式建立連接，這就是說移動設備之間可以隨時連接、隨時斷開，這非常符合移動設備網絡環境易變動的特點，而且每臺移動設備都可以作為服務器，服務器環境不需要靜態配置。

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

對這3個問題的解決說明本文設計的Multi-Offloading平臺可以很好地處理設備互連和計算任務轉移的相關問題。下面將說明Multi Offloading如何讓設備之間互相發現和連接。

2.2 設備發現與設備互連

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

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

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

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

Fig.3 Device finding圖3 設備發現

Fig.4 Device connection and device interconnection圖4 設備連接與設備互連

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

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

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

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

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

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

階段2描述的是兩個設備之間的連接過程，第三階段會建立多設備之間的連接網絡。

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

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

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

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

3 Offloading技術實現

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

插樁（Instrumentation）是分析和處理程序的常用技術，程序員通常可以在程序內部插入一些自己的代碼，這些代碼可以提供程序運行時的信息，比如程序運行時的堆棧信息、代碼覆蓋率信息等。同樣編程人員也可以對移動應用進行插樁，在應用中插入某些代碼，實現特定的程序行為和程序邏輯。

圖5展示了一般應用的插樁流程。

Fig.5 Application instrumentation process圖5 應用插樁流程

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

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

本文設計實現的Computation Offloading、Sensing Offloading和Touch Offloading技術就是基于應用插樁完成的。

3.1 Computation Offloading技術實現

Computation Offloading技術希望可以將應用中部分涉及復雜計算的任務動態轉移到高性能設備上執行，然后返回結果，使應用能夠高效地運行。

這里本文結合Multi Offloading架構對CoseDroid的插樁思想進行了重新實現。

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

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

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

并不是所有的方法都是可轉移的，可轉移的方法要求方法執行前后只對調用對象本身的域（Field）造成影響，不會對系統狀態和其他程序狀態造成影響。對于類C中的方法m（帶有引用對象的參數p）是否可轉移，本文結合Multi Offloading架構將其總結為表1所示的4個條件（判定結果為“是”則不滿足條件）。

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

Table 1 Conditions of Offloadable methods表1 方法可轉移條件

3.2 Sensing Offloading技術實現

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

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

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

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

本文根據上述思想設計了如圖7所示的插樁流程。

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

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

3.3 Touch Offloading技術實現

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

對于Touch Offloading技術的實現，本文設計了圖8所示的插樁流程。

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

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

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

因此，在3種Offloading技術的插樁中本文都加入了關于執行模式的判斷，如果應用不是由Multi-Offloading平臺打開運行的，那么：

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

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

4 實驗評估

4.1 實驗設計與實現

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

在Offloading體驗平臺上，本文選取了兩個移動應用來展示Offloading技術的實現效果。

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

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

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

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

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

結合上述實驗目的，本文提出3個研究問題。

問題1將Android應用的復雜計算轉移給更高性能的設備執行是否可行，相同步驟內應用運行時間是否明顯減少。

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

問題3本文Touch Offloading插樁技術是否能夠實現觸控轉移，即在控制者屏幕上進行點擊是否能在顯示者屏幕上相同位置產生點擊事件（轉移觸控的設備稱為控制者，接受控制的設備稱為顯示者）。

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

4.2 實驗結果

4.2.1 Computation Offloading效果展示

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

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

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

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

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

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

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

4.2.2 Sensing Offloading效果展示

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

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

4.2.3 Touch Offloading效果展示

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

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

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

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

這說明本文給出的Touch Offloading插樁方法可以有效實現觸控轉移。

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

5 相關工作

本文提出的Multi Offloading是一個同時支持Computation Offloading、Sensing Offloading和 Touch Offloading的Android應用Offloading平臺，而對于Offloading技術也已經有許多相關研究。

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

也有一些對非Android平臺的應用Offloading技術的研究工作。Maui[4]就是面向Windows Phone平臺的應用和設備的Offloading工作，工作語言和處理對象是C#語言和.NET程序，其工作核心是遠程過程調用（remote procedure call，RPC），在運行時決定哪些方法應該轉移執行，然后做程序分割；Maui提供了一個編程環境并允許用戶標注哪些方法可以被轉移執行，并在運行時判斷這種方法是否真的可以Offloading。Wang等人[5]的工作面向支持Java的移動設備，這份工作的重點在于面向對象程序中的程序分割，使用靜態分析的方法首先建立一個帶權值的對象關系圖，然后根據這個對象關系圖二次建模將其中的對象劃分成本地執行的部分和服務器執行的部分，并對劃分成服務器部分的對象進行轉移執行。Rim等人[6]的工作同樣面向運行JVM的移動設備，通過對Java應用的插樁實現方法的Offloading。

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

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

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

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

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

6 總結與展望

本文給出了一個Android應用Offloading平臺的設計與實現方案，Multi Offloading。Multi Offloading同時支持Android應用進行Computation Offloading、Sensing Offloading和 Touch Offloading，搭載 Multi-Offloading的移動設備可以互相發現并建立連接，形成一個P2P網絡。

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

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