服務(wù)作為Android應(yīng)用中經(jīng)常使用的組件,主要負(fù)責(zé)在后臺執(zhí)行耗時(shí)的操作。雖然服務(wù)與應(yīng)用的圖形用戶界面無關(guān),但研究發(fā)現(xiàn)服務(wù)的不恰當(dāng)使用會導(dǎo)致應(yīng)用性能的降低,例如會導(dǎo)致額外的能源消耗和不必要的資源占用。目前相關(guān)研究主要集中在Android應(yīng)用中圖形用戶界面與能源缺陷的測試方面,并沒有對服務(wù)的使用缺陷進(jìn)行研究。為此,本文主要做了以下四個(gè)方面的工作。1.結(jié)合服務(wù)生命周期和三類服務(wù)使用方式,總結(jié)出四類服務(wù)使用反模式,并基于Android應(yīng)用的過程間控制流圖,給出四類反模式對應(yīng)的具體缺陷的靜態(tài)分析方法。2.利用線性時(shí)序邏輯給出服務(wù)使用四類反模式缺陷的形式化定義,并給出根據(jù)應(yīng)用運(yùn)行時(shí)產(chǎn)生的動態(tài)信息對相關(guān)特性進(jìn)行運(yùn)行時(shí)驗(yàn)證的動態(tài)分析方法。3.設(shè)計(jì)并實(shí)現(xiàn)了一個(gè)原型工具ServDroid,可以用于自動化檢測Android應(yīng)用中存在的服務(wù)使用模式及其使用存在的缺陷（反模式的具體實(shí)例）。該工具主要包括三個(gè)模塊:靜態(tài)分析模塊,動態(tài)分析模塊與使用缺陷修復(fù)模塊。靜態(tài)分析模塊通過分析應(yīng)用的代碼和資源,得到服務(wù)使用模式,然后結(jié)合Android SDK提供的關(guān)鍵API進(jìn)一步分析得出每一種服務(wù)使用模式存在的反模式缺陷并且... 

【文章來源】：南京理工大學(xué)江蘇省 211工程院校

【文章頁數(shù)】：70 頁

【學(xué)位級別】：碩士

【部分圖文】：

啟動服務(wù)生命周期

2背景碩士學(xué)位論文6圖2.3啟動服務(wù)生命周期綁定服務(wù)：綁定服務(wù)的生命周期如圖2.4所示，下面對此進(jìn)行說明。由于啟動的服務(wù)無法與啟動它們的組件交互，因此會存在綁定服務(wù)，它可以將數(shù)據(jù)發(fā)送到啟動組件（客戶端）。客戶端組件可以調(diào)用Context.bindService()方法來獲取與服務(wù)的連接。類似地，如果尚未創(chuàng)建服務(wù)實(shí)例，則通過回調(diào)onCreate()方法來創(chuàng)建服務(wù)。對于通過bindService()方法綁定的服務(wù)，其生命周期方法onBind()必須重寫并返回IBinder對象，綁定該服務(wù)的組件便可以通過IBinder對象與服務(wù)進(jìn)行通信。雖然可以多個(gè)客戶端組件綁定到同一服務(wù)，但系統(tǒng)只會回調(diào)一次onCreate()方法。調(diào)用者通過調(diào)用Context.unbindService()方法（系統(tǒng)調(diào)用onUnbind()）終止綁定服務(wù)，因?yàn)榻壎ǚ⻊?wù)的生命周期依賴于調(diào)用者，因此，當(dāng)沒有客戶端組件綁定到服務(wù)時(shí)，該服務(wù)將被銷毀。值得注意地，因?yàn)锽roadcastReceiver組件的生命周期很短暫，因此Android系統(tǒng)不允許BroadcastReceiver綁定服務(wù)�；旌戏⻊�(wù)：既被啟動同時(shí)也被綁定到客戶端組件上的服務(wù)，被稱為啟動和綁定服務(wù)，或簡稱為混合服務(wù)�；旌戏⻊�(wù)可以先啟動然后綁定，反之亦然。啟動和綁定混合服務(wù)的組件可以不同。值得注意的是，當(dāng)一個(gè)服務(wù)正在運(yùn)行的時(shí)候，即使多個(gè)組件再次啟動或者綁定該服務(wù)，但是服務(wù)仍不會再次實(shí)例化。圖2.4綁定服務(wù)生命周期2.1.3Intent與Intent-Filter在Android系統(tǒng)中，同一Android應(yīng)用的組件以及不同Android應(yīng)用的組件之間，都可以進(jìn)行通信�；窘M件間通信的接口為Intent，其作用相當(dāng)于調(diào)用API函數(shù)。例如：

2背景碩士學(xué)位論文8包含Intent的動作，Intent中的每個(gè)類別必須匹配Intent-Filter中的一個(gè)。數(shù)據(jù)匹配相對比較復(fù)雜，主要分為兩部分：Uri匹配和MimeType匹配。Uri需要匹配host，port和path。若Intent-Filter聲明了host、port或path屬性，Intent中則必須包含且匹配這些屬性。若Intent-Filter并未聲明其中的某些屬性，Intent中的該屬性也就不需要匹配。當(dāng)Intent與某個(gè)組件的Intent-Filter匹配時(shí)，該組件就是Intent的一個(gè)目標(biāo)組件。對于Type匹配，Intent所指定的Type類型必須與Intent-Filter指定的MimeType相同，才能完全匹配。在一次匹配過程中，會找出系統(tǒng)上所有匹配該intent的組件。即隱式intent可以一次性啟動多個(gè)組件。例如，當(dāng)我們在使用某讀書軟件進(jìn)行書單分享時(shí)，點(diǎn)擊分享按鈕，可能就會彈出多個(gè)軟件，如微信，微博等，即有多個(gè)應(yīng)用可以分享該書單，用戶可以任選一個(gè)應(yīng)用打開進(jìn)行分享。2.1.4測試輸入如圖2.5所示，向Android應(yīng)用提供輸入主要通過兩種方式：（1）事件（2）調(diào)用AndroidAPI的返回值[26]。事件可以是用戶生成的（例如點(diǎn)擊按鈕）也可以是系統(tǒng)生成（例如廣播電池狀態(tài)的變化）的。本文主要考慮的是用戶給定的測試輸入，通過Android測試框架模擬用戶的輸入，使得Android應(yīng)用可以自動化執(zhí)行到給定的位置。圖2.5Android應(yīng)用與Android框架交互方式2.2相關(guān)工作我們的研究涉及到Android應(yīng)用的GUI測試[27-29]，服務(wù)分析[12-16]和測試以及能耗測試與分析[18-20]三個(gè)方面的工作。在本節(jié)中，我們將介紹這三個(gè)方面的最新技術(shù)。2.2.1GUI測試


本文編號：3438093