安卓移動應用兼容性測試綜述

鄭 煒 唐 輝 陳 翔 張滿青 夏 鑫

1(西北工業大學軟件學院 西安 710072) 2(南通大學信息科學技術學院 江蘇南通 226019) 3(信息安全國家重點實驗室(中國科學院信息工程研究所) 北京 100093) 4(蒙納士大學信息技術學院 澳大利亞墨爾本 3800) 5(空天地海一體化大數據應用技術國家工程實驗室(西北工業大學) 西安 710072) 6(大數據存儲與管理工業和信息化部重點實驗室(西北工業大學) 西安 710072)

安卓(Android)是由Google公司領導的開放手機聯盟(Open Handset Alliance, OHA)開發的一款開放式操作系統.作為全球最受歡迎的移動平臺，目前安卓已經擁有超過80%的市場份額和10億臺活躍設備[1-2].與此同時，安卓應用程序的數量也正在以驚人的速度增長，據統計，每月在Google Play上新發布的應用程序數量已多達35 000個[3].與其他應用領域的軟件一樣，移動應用也面臨著各種質量保障問題，除了常見的與軟件安全性和可靠性相關問題[4-7]之外，頻繁發生的移動應用兼容性問題也越來越受到研究人員的關注.

安卓碎片化(Android fragmentation)是指大量支持安卓的硬件設備、安卓API及安卓操作系統的快速發展，導致了應用程序出現大量可能的運行環境.當前安卓生態系統嚴重的碎片化現象，已成為導致移動應用兼容性問題頻發的罪魁禍首.兼容性問題是軟件故障的一種表現形式，也可稱作兼容性故障，輕度的兼容性問題可能表現為程序中圖片顯示不全、控件錯位、屏幕顯示異常等，而嚴重的兼容性問題可能會導致程序安裝或卸載失敗、應用運行時突然崩潰等，從而為用戶釀成不可挽回的損失.對于普通用戶來說，針對兼容性問題，主要有2種解決方法：1)等待應用程序發行方更新升級程序以適配新的安卓系統；2)將系統回退到程序能夠兼容的舊系統版本.因兼容性問題導致的低可用性，會導致用戶體驗變差，并對程序的使用失去信心.已有實踐表明：開發方經常收到用戶的兼容性問題投訴，并隨后不得不耗費高昂的代價去處理這些問題[8-10].不難看出，生態系統的用戶群體規模越大，因兼容性問題造成的負面影響就越大.

在安卓生態系統碎片化異常嚴重的開發背景下，處理兼容性問題已經成為具有挑戰性的研究問題[11-12].這也給應用程序的開發人員帶來了一定的負擔，他們需要確保開發的應用程序能夠在多種操作系統版本的不同移動設備型號上提供兼容策略，因此依賴于大量的編碼和測試工作.實際上，開發人員充分測試他們的應用程序以涵蓋設備型號和操作系統版本的所有組合并不可行.與此同時，由于安卓操作系統和API的頻繁迭代和更改，使得開發人員必須在短時間內對應用程序進行更新，以確保應用程序在新的API和操作系統版本中正常運行，這也是一個繁瑣耗時且容易出錯的過程.因此，當前亟需一個高效低成本的自動化的檢測、定位和修復工具來解決繁雜的兼容性問題.

為了對該研究問題進行系統的分析、總結和比較，我們首先在 IEEE，ACM，Springer，Elsevier，CNKI 等論文數據庫中進行檢索，檢索時主要采用的英文關鍵字包括“Android fragmentation”“mobile applications”“compatibility”“software failure”“Android API”等，然后通過閱讀論文的標題、摘要和引言對其進行人工審查，排除掉與安卓兼容性問題無關的論文后，再對所篩選的論文的相關工作進行分析和作者已發表論文清單進行分析，并以此來補充與綜述主題相關的遺漏文獻.

重復上述步驟多次，我們選擇出與兼容性問題直接相關的高質量文獻共40篇(截至2021年7月)，圖1以論文發表年份為橫坐標，以年份發表的論文總數為縱坐標，對論文發表的時間分布進行了匯總.

不難看出，該研究問題是當前安卓系統測試領域的一個熱點問題，尤其近6年發表的論文數占到該綜述主題總發表論文數的55%.此外，我們對處在CCF列表中的論文發表源進行了統計，可以看出，相關文獻大部分發表在軟件工程領域的核心期刊與會議上，比如ICSE會議4篇、ISSTA會議3篇、ASE會議3篇、TSE期刊3篇等.

Fig. 1 Statistics of papers published in different publication years圖1 不同年份發表論文統計圖

Fig. 2 The framework of Android mobile application compatibility testing圖2 安卓移動應用兼容性測試的框架圖

圖2展示了本文的綜述過程.在文獻檢索階段，首先選取合適的檢索關鍵詞，以計算機學科相關的論文數據庫為檢索源，同時在標題、摘要、關鍵詞和索引中進行初步檢索，對所得文獻進行人工內容篩查，剔除與本綜述課題無關的文獻，然后得到最終文獻集合.在文獻分類階段，我們從移動應用兼容性分析、移動應用兼容性檢測、移動應用兼容性定位與修復3個大類對所得文獻進行歸類.本文將實證研究和分類方法歸于兼容性分析研究工作中，探究兼容性問題的表現形式、根本原因、分類依據以及當前所面臨的挑戰；以發現程序中潛在的兼容性問題為目標，歸納整理文獻中提出的兼容性故障檢測工具和方法，并根據技術特性作出靜態檢測和動態檢測的進一步分類；以定位程序中兼容性故障的根源以及修復兼容性故障為目標，整理文獻中提出的兼容性故障定位和修復方法，并歸納出定位和修復階段常用的技術框架.最后對不同子類的文獻進行總結、評價和比較，探究安卓移動應用兼容性測試領域未來的研究方向.

1 基本概念及術語

1.1 安卓碎片化

安卓碎片化是指隨著大量支持安卓的硬件設備、安卓API及安卓操作系統的快速發展，以及原始設備制造商在其設備上部署的安卓操作系統的定制版本的存在，導致了應用程序存在大量可能的運行環境.安卓生態系統高度碎片化的特性，使開發者在應用程序開發過程中面臨十分嚴峻的挑戰，也使其成為一個開放性研究問題[13-17].根據2019年6月騰訊移動分析統計顯示，Android 6.0版本以下的市場占比仍然高達26.7%，其中較老的Android 4.4版本竟仍占有5.9%的份額.此統計分析結果表明當前安卓系統版本的碎片化問題已經十分嚴重[18].

根據Ham等人[19-21]的研究，可以將安卓碎片劃分為操作系統碎片和設備碎片，其中設備碎片又可以進一步細分為硬件碎片和API碎片.具體來說：操作系統碎片表示安卓平臺版本的頻繁更新而導致的碎片.開發商通過降低舊版本終端設備的比例，并對安卓版本進行更新，使得操作系統的碎片化問題已經得到初步緩解[22].而當前比較嚴重的是設備碎片化問題，其中硬件碎片化是指不同終端設備之間具有不同的硬件規格，尤其以分辨率問題最為突出；API碎片化是指由基本安卓API的演化而導致的各類差異化問題，API碎片化主要體現在API級別上，在每個版本的安卓平臺更新時，Google都會為安卓版本設置一個API級別，例如安卓1.0版本所對應的API級別為1，其后每個版本的安卓系統都會對API等級進行升級，即以整數的形式往后累加.截止到2020年6月為止，安卓生態系統中的API級別范圍已經拓展到1～28級[23].

1.2 應用程序兼容性

很多已有研究工作分析了因安卓碎片化導致的各種功能性和非功能性問題[24-26]，而其中最為顯著的就是應用程序的兼容性問題.移動應用程序兼容性(mobile app compatibility)是指應用程序能否在不同的環境或內部系統變化中保持一致的行為[27].安卓應用程序的兼容性可以進一步細分為向前兼容(forward compatibility)和向后兼容(backward compatibility).其中，向前兼容是指在安卓平臺的較低版本環境中實現的應用程序可以在較高版本的環境中運行；而向后兼容，又稱為回溯兼容，是指最新的應用程序仍然能夠訪問和處理舊版本中的數據.其中向后兼容主要體現在對安卓API的持續維護上，開發商應盡量保證安卓API只增不減來維持移動應用的向后兼容性.在后續分析中我們會進一步對兼容性的分類進行闡述.

兼容性問題常常會導致應用程序安裝或運行失敗、運行卡頓或崩潰、功能異常、UI異常等，從而破壞程序正常運行的能力，導致程序實際結果與預期結果不符，因而從本質上屬于一種軟件缺陷.移動應用兼容性問題的產生原因復雜多樣.安卓平臺自身版本更迭的需求以及安卓API的不斷演化，使得應用程序很難保證向后兼容.系統版本的迭代只是兼容性問題的一個線性增長因素，真正導致其復雜性的根源在于不同終端設備型號的“大雜燴”現象，在各大設備廠商激烈的市場競爭下，來自不同制造商甚至來自同一制造商的設備品牌和型號層出不窮，各種智能終端設備與安卓的適配直接導致版本數量呈指數級增長，并使得移動應用的兼容性很難得到保障[28].除此之外，對第三方庫函數的調用也是導致應用程序不兼容的原因之一，開發者通過調用第三方庫的資源對應用程序的功能進行擴充，因此第三方庫在應用程序中的高流行率也為兼容性問題的出現埋下了隱患[29-30].

圖3給出了一個與跨平臺相關的兼容性問題示例[31].DAILY DOZEN[32]是一款用戶下載超過5萬次的移動應用程序，如果將該應用程序分別運行在LG品牌的2個不同型號G3和Optimus L70的手機終端上，由于2個設備的屏幕分辨率不同，在運行同一個DAILY DOZEN應用程序時，在LG Optimus L70設備上可以發現2個易被視覺感知的兼容性問題：

1) 與“Cruciferous Vegetables”標簽相關聯的復選框元素不可見，使得用戶無法勾選此項.這種兼容性故障是由一個與主活動(MainActivity)相關聯的布局文件錯誤引起的.

2) 與“Other Vegetables”標簽關聯的最右邊的復選框元素顯示不全，這是由屏幕分辨率或像素密度不同而導致的兼容性故障.

Fig. 3 Examples of cross-platform related compatibility issues圖3 與跨平臺相關的兼容性問題示例

在該示例中需要注意的是，在LG Optimus L70設備上雖然沒有顯示“Nuts”標簽，但是由于滾動列表的存在，這類現象并不能視為兼容性問題.除此之外，應用程序在開發過程中可供測試的設備數量是有限的，因此可能很難發現這2類兼容性問題，這也從側面反映了兼容性測試面臨的研究挑戰.

1.3 兼容方法

為了預防安卓碎片化帶來的兼容性問題，開發者在程序開發初期就十分注重兼容程序的編寫[33].以參數設置為例，開發者通過使用minSdkVersion和maxSdkVersion參數來設置安卓的最低和最高SDK版本，以此來限制API級別并提升應用程序的兼容能力.如果程序不指定minSdkVersion參數的取值或指定錯誤的minSdkVersion參數取值均可能會導致向后兼容問題，使應用程序代碼中的一些API在較舊版本的安卓中不能被使用，進而導致程序崩潰；如果程序不指定maxSdkVersion參數的取值，則會導致潛在的向前兼容問題，因為程序中使用的API方法可能在最新版本的安卓平臺中不再被支持.

2011年，安卓平臺推出了安卓支持庫(Android support library)[23]，以處理應用程序中日趨嚴重的兼容性問題.安卓支持庫集成了程序開發中特定的框架組件和UI功能元素，這些庫主要分為2組：兼容庫和組件庫.其中兼容庫主要用來緩解版本演化而帶來的兼容性問題，主要包括v4兼容庫和v7兼容庫.庫中提供了新SDK版本的后臺移植功能，它為不同SDK版本上的接口子集提供包裝器，應用程序可以調用支持庫中的包裝器而不是直接調用SDK中定義的API函數，使得在新SDK版本上開發的應用程序可以在舊SDK版本上運行，而無需修改.

此外，Google公司在2014年還進一步推出了安卓兼容性計劃(Android compatibility program)[34]，該計劃旨在讓整個安卓社區(包括用戶、開發者和設備制造商)受益，通過制定完善的兼容性標準以最大限度地降低與兼容性相關的成本和開銷.安卓兼容性計劃包括3個關鍵的組成部分：

1) 安卓開放項目源代碼；

2) 兼容性定義文檔(compatibility definition document, CDD)；

3) 兼容性測試套件(compatibility test suite, CTS).

其中CDD[35]是描述安卓兼容性策略的文檔，提供了安卓源代碼的使用框架，使其可以用作引用其他內容(如SDK API文檔)的綱要，促進兼容性系統的實現.CTS是一個測試安卓API兼容性的自動化測試套件，提供了單元測試和功能測試的測試用例，并使用CTS驗證程序進行補充，以盡早發現兼容性問題，并確保軟件在整個開發過程中保持兼容性.

然而，安卓兼容性計劃并沒有完全解決安卓碎片化和兼容性問題.官方并沒有說明通過CTS測試的標準，同時商業設備也很難達到100%的測試覆蓋率.最重要的是，CTS是一個檢查安卓設備兼容性的程序，在對應用程序進行開發時，無法使用CTS的結構進行測試.

2 移動應用兼容性分析

鑒于移動應用兼容性問題的嚴重性和復雜性，近年來針對移動應用兼容性分析的研究成果不斷涌現，主要體現在對移動應用兼容性問題的實證研究和分類研究上.兼容性問題的實證研究具有鮮明的直接經驗特征，研究人員通過手工收集數據資料，對提出的理論假設進行實驗驗證，從而對導致兼容性故障的根本原因進行總結.兼容性問題的分類研究是指研究者對各種兼容性故障進行匯總，并按照某項指標進行故障分類，以解決同一類別故障重復報告的問題，從而提高開發人員處理兼容性故障的效率.

當前移動應用兼容性問題所面臨的主要挑戰有3個方面：

1) 安卓碎片化問題嚴重.安卓操作系統版本的快速迭代、安卓API的不斷演化以及不同終端設備型號的更替，加劇了安卓生態系統的碎片化問題，版本數量的爆炸式增長，使得移動應用的兼容性難以得到保障[11-12]，潛在的兼容性故障也很難被開發者發現，從而對故障的檢測、定位和修復提出了嚴峻的挑戰.

2) 手工測試具有局限性.在移動應用開發過程中，開發人員經常需要將程序移植到不同的型號設備上進行兼容性測試，該移植過程費時費力且容易出錯.當發行方經過設備購置、反復測試和問題修復等多個階段完成對應用的測試，并將應用投放到市場，用戶仍會持續反饋應用在開發時遺漏的各種兼容性問題，開發者必須對其快速做出反應，如此繁重的工作量和高昂的代價顯然是難以接受的[36-37].

3) 第三方庫的大量使用所帶來的隱患.大多數安卓應用程序需要依賴第三方庫來實現增值功能，例如廣告、Google Play服務等.然而，隨著時間的推移，這些第三方庫與調用第三方庫的相關應用功能協同演化，當這些第三方庫發布新版本時，開發人員需要對與其相關的應用功能進行相關兼容性測試，以確保能夠與舊版本庫提供一致的用戶體驗[29-30].第三方庫在應用程序中的大量使用為兼容性問題的出現埋下了隱患.

2.1 實證研究

初期研究人員針對安卓應用程序與API演化關系的探索，拉開了兼容性問題研究的序幕.Linaresvasquez等人[38-40]對7 097個安卓應用程序展開了實證分析，他們發現更受歡迎的應用程序通常傾向于使用不易更新的API，經常使用易出錯和易更新的API會對應用程序造成負面影響，并導致應用程序出現故障或崩潰.McDonnell等人[41]對安卓API的穩定性和使用率展開了實證研究，他們的研究結果表明，安卓正在以平均每月115個API更新的速度快速發展，然而與快速演化的API相比，開發人員采用最新API版本的平均時間要比API演化時間滯后很多，其平均滯后時間大約為16個月.

Wei等人[42-43]對在開源安卓應用程序中收集的191個兼容性問題進行了大規模實證研究，將安卓碎片化導致的應用程序兼容性問題稱為FIC(fragmentation-induced compatibility)問題，并總結出了導致FIC問題的5個主要根源，其中最突出的是安卓API的演化和錯誤的硬件驅動實現，并提出了FicFinder工具以檢測應用程序中的兼容性問題.Wei等人的研究表明，在不同的軟硬件環境下，確保不同型號設備上應用程序的兼容性面臨嚴峻挑戰.隨后He等人[44]對11個不同的安卓版本和4 936個安卓應用程序展開了大規模實證研究，他們的研究表明，導致安卓應用程序兼容性問題的主要原因是因安卓版本更新而導致的API劇烈變化，以及安卓支持庫的支持能力有限.這2類問題十分普遍，因此大約92%的應用程序都需要通過編寫特定的代碼來處理兼容性問題，而開發員最常見的做法(大約78.4%)是通過直接將變量android.os.Build.VERSION.SDK_INT與常量值進行比較來檢查底層系統的SDK版本.Wu等人[45]對2.4萬個應用程序進行了研究分析，發現開發人員經常不會對目標SDK版本和最低SDK版本進行預先聲明，為程序的兼容性故障埋下了隱患.上述實證研究工作為深入研究因安卓碎片化導致的兼容性問題提供了有益指導.

Mutchler等人[46]將過時安卓API級別產生的應用程序問題定義為目標碎片問題(target frag-mentation problem).他們提出了“疏忽性過時”(negligent outdatedness)和“過時”(outdatedness)2個度量指標來衡量程序中API級別的滯后程度以及目標碎片問題的嚴重程度.通過對1 232 696個開源安卓應用程序進行量化分析，他們發現目標碎片問題主要是由開發人員的疏忽造成的，且會使程序受到兼容性故障的威脅.這一工作有助于開發者意識到過時API級別可能導致的后果，并且重新檢查和更改這種缺陷設計，從而減少安卓應用程序中出現兼容性問題的概率.

Huang等人[36]對安卓開發者的API參考文檔[47]、安卓API差異報告[48]、安卓開源項目[49]和50個開源安卓應用的100個回調兼容性問題進行了實證研究，他們發現回調API的演化會引起回調API調用協議(callback API invocation protocol)的改變，并將回調API的演化細分為API可達性更改和API行為更改2種方式，前者改變回調API的可達性，而后者改變回調API的調用條件和行為，進而導致程序控制流信息不一致并引發回調兼容性問題.

Xia等人[50]對大約30萬個安卓市場應用程序進行了大規模實證研究，旨在揭示開發人員在處理由API演化導致的兼容性問題的具體修復策略.他們發現只有38.4%的不兼容API提供了官方的替代實現，當谷歌提供API替代推薦時，開發人員很可能會用推薦API來替代不兼容的API調用，但推薦API所包含的過多參數往往使替代操作變得棘手；當谷歌沒有給出替代推薦時，開發人員往往只能根據個人經驗對不兼容API進行修復，但修復效果十分依賴于開發者自身的專業水平.上述研究中對各類API演化進行了深度探索，為解決各類API演化導致的兼容性問題提供了契機.

2.2 分類研究

兼容性問題一般可以按照兼容特性分為向前兼容問題和向后兼容問題，但這種分類方式較為粗略，無法體現出兼容性問題的產生原因和表現程度，同時也使得一些相似的兼容性錯誤報告被反復提交.因此，針對兼容性問題的分類研究就顯得尤為重要.

Wei等人[42-43]將FIC問題劃分為設備無關問題和設備相關問題.如果FIC問題可以在運行特定安卓版本的任何設備模型上均能觸發，那么該問題就屬于設備無關問題；如果FIC問題只能在運行特定API級別的特定設備型號上才能觸發，那么該問題就屬于設備相關問題.與設備無關問題相比，由于增加了設備型號這一維度，針對設備相關問題的搜索空間規模也會大幅度增長，并使得設備相關問題更加難以檢測.

Huang等人[36]和Malinda等人[51]分別研究了回調API兼容性問題和運行時權限兼容性問題，其中回調API兼容性問題是指回調API的演化而導致的回調API調用協議條件和行為的改變，進而引發的回調兼容性故障，而運行時權限兼容性問題是指自安卓6.0引入運行時權限機制以來，不同API級別的系統不能正確執行被調用API的權限檢查，或者用戶手動撤銷了某些API的調用權限，進而因為權限機制不適配而導致程序功能失效或運行崩潰等問題.分別以回調API演化和權限機制不適配的產生原因作為劃分依據，為兼容性問題在故障原因層面的精細劃分提供了參考.

Cai等人[37]以應用程序能否在某個版本的安卓平臺上成功安裝和運行為依據，將兼容性問題分為安裝時不兼容和運行時不兼容兩種情況.如果應用程序能夠成功安裝到至少一個版本的安卓平臺，而在另一個版本的安卓平臺安裝失敗，則將其視為安裝時兼容性問題；如果應用程序可以在至少一個版本的安卓平臺上成功運行指定的時間段且不產生任何錯誤信息，而在另一個版本的安卓平臺無法運行，則將其視為運行時兼容性問題.通過將這2類程序兼容性問題進行區分，可以方便研究人員更加深入地對相應兼容性問題的作用范圍和階段進行分析.

對兼容性故障進行分類管理，總結在應用程序開發過程中不同兼容性問題出現的頻度，有利于開發人員制定合理高效的軟件管理策略，提高軟件質量和軟件組織生產能力.我們總結并拓展了7類不同維度下的兼容性故障分類方法：

1) 兼容特性.兼容特性是指應用程序能否在不同的環境或內部系統變化中保持一致的行為.該分類方法系統地將兼容性問題分為前向兼容問題和后向兼容問題，兩者幾乎囊括了軟件所有的兼容性故障類別，是目前最為常用的宏觀分類方法.

2) 硬件相關.硬件相關是指通過更換不同硬件設備型號或組件，來判斷程序兼容性故障是否與特定設備型號或組件相關的方法.該分類方法可以有效減小與硬件相關兼容性故障的搜索空間，提高故障檢測效率.

3) 產生階段.產生階段是指對應用程序在開發、測試、維護等不同階段產生的兼容性故障進行歸類的方法.該方法有利于開發人員在應用程序開發的不同階段制定不同的故障規避策略.

4) 產生原因.產生原因是指依據兼容性故障產生的根本原因對故障進行分類的方法.該方法是一種精細可靠的分類策略，但分析應用程序兼容性故障根源的過程是復雜且耗時的，時間成本和人力成本相對較高.

5) 故障表現.故障表現是指對故障的不同表現形式進行分類的方法.兼容性故障常常表現為程序安裝失敗、運行崩潰、功能異常、UI異常等，依據該方法有利于找尋各類故障表現之間的內在聯系.

6) 修復難度.修復難度是指在兼容性故障的修復過程中，根據修復的成本和難度的不同，從而對故障進行修復評估并歸類的方法.該方法旨在指導開發人員知悉各類故障的修復難度及其對應的修復成本，盡可能減少多種兼容性故障所帶來的損失.

7) 風險程度.風險程度是指以放棄修復兼容性故障所帶來的不同程度的損失和后果為依據對故障進行分類的方法.根據不同的風險評估方法，對兼容性故障的危險性進行分類，優先修復風險程度大、危險性高的故障.

表1對提及的兼容性故障分類研究所屬的分類方法進行了總結，高效的分類方法有利于開發人員實施多種有效的故障分類方法和管理策略，然而對于不同類型應用程序來說，其兼容性故障產生的原因具有一定的復雜性，并導致開發人員難以篩選出最優的故障分類策略.此外，自動化故障分類工具和分類技術的研究仍處于起步階段，自動化分類工具的嚴重匱乏導致故障分類策略的選取完全依賴于專業人士的手工分析，并造成分類效率比較低下.同時，由于各類兼容性故障報告缺乏行之有效的系統化管理，使得當前故障分類管理工作的規范化程度低且極易出錯.

Table 1 Summary of the Dimensions of the Compatibility Fault Classification Research表1 兼容性故障分類研究所屬維度總結

3 移動應用兼容性檢測

本節以檢測過程中是否需要運行移動應用程序為依據，將程序兼容性檢測技術劃分為靜態檢測和動態檢測2種方法.其中靜態檢測方法是指在不運行程序的情況下，利用控制流分析、數據流分析、符號執行等技術完成對程序開發文檔、源代碼或字節碼的審查和分析，從而檢測出各類軟件缺陷或兼容性問題.動態檢測方法是指通過運行被測程序，比對運行結果與預期結果的差異，并對程序運行效率和健壯性進行分析，通常由構造測試用例、執行程序和分析執行結果3個步驟組成.

3.1 靜態檢測方法

當前已有的靜態檢測方法主要有4種，分別是基于規則的方法、基于控制流分析的方法、基于數據流分析的方法以及基于多技術融合的方法.

1) 基于規則的方法.Scalabrino等人[52]提出了一種自動檢測安卓應用程序中API兼容性問題的工具ACRYL.ACRYL是一種基于數據驅動的方法，它依賴于開發人員在大量應用程序中已經定義的條件API用法(conditional API usages, CAUs).ACRYL以應用程序的APK文件作為輸入，首先使用DEX2JAR將其轉換為jar，并利用WALA庫來分析獲得的Java字節碼，通過分析應用程序中的每個方法，對包含檢查SDK_INT字段值的條件語句的方法以及檢查結果中具有返回值的方法進行標記，提取出對應的CAUs；然后ACRYL便可以使用它們來推斷檢測規則，并根據從中學習規則的應用程序的數量為每個規則分配一個置信級別；最后，這些規則可用于檢測給定應用程序中的可疑API調用.然而，由于研究人員只對開源程序進行規則學習，因此這些規則可能無法適用于一些商業軟件.此外，ACRYL的有效性也會受到規則時效性的影響，從而很容易過時.

2) 基于控制流分析的方法.FIC問題在檢測時需要對設備型號、API級別和被調用API的每個組合進行動態檢索，為了縮小FIC問題的檢索空間，Wei等人[53]在后續研究中對與設備相關的兼容性問題進行了分析，并開發了PIVOT檢測工具.為了學習API調用與設備型號之間的關聯性，PIVOT 通過定義API-Device 標識符來對關聯性進行標識，并定義了一種關系抽取器對應用程序的調用圖和每個方法的控制流圖進行組合，完成過程間控制流圖(inter-procedural control flow graph)的構建，然后對與設備參數識別相關的API函數進行識別并計算API-Device的關聯程度，最后采用Nguyen等人[54]提出的排序組件對API-Device關聯程度進行排序并輸出優先排序結果.他們成功利用PIVOT對開源安卓應用程序進行了檢測，并發現10個未被報告過的兼容性問題.該研究提供了檢測設備相關的兼容性問題的方法，但是無法對與設備無關的問題進行檢測，而且PIVOT需要對API-Device關聯程度的排序結果進行人工驗證，因此需要依賴一定的專業知識.

Huang等人[36]提出了基于協議不一致性圖(protocol inconsistency graph)的靜態檢測工具Cider，用來檢測回調API演化引發的兼容性問題.協議不一致性圖借鑒了回調控制流圖(callback control flow graph)[55]的表示方法，回調控制流圖由一個包含回調節點和輔助節點的有向圖表示.其中回調節點表示拒絕回調API的調用，而輔助節點表示拒絕回調API的前后2點，即控制流的分支和連接點.Cider通過捕獲安卓應用程序運行時產生的控制流信息，并以此來構建不同API級別下的協議不一致性圖，通過遍歷和比對協議不一致性圖即可發現程序中的回調兼容性問題.他們基于Soot[56]框架實現了Cider工具，隨后基于GitHub的開源項目評估了Cider工具的可用性.Malinda等人[51]對應用程序運行時權限兼容性問題進行了研究，提出了基于靜態控制流分析的ARPDroid技術來檢測權限兼容性問題.ARPDroid以要分析的應用程序和一個API權限映射作為輸入，其中API權限映射提供了API權限依賴表并收集了每個API所依賴的權限信息，然后利用Soot框架對程序權限使用的關鍵點執行靜態控制流分析.根據控制流分析的結果，ARPDroid先后對targetSdkVersion參數和API權限-負責-調用方(permission-responsible caller, PRC)進行檢查，并給出不兼容錯誤報告.上述研究工作都采用了靜態控制流分析的方法對特定的兼容性問題進行檢測，但也同時存在檢測類型較為單一的問題，且ARPDroid對Soot功能組件具有依賴性.

3) 基于數據流分析的方法.He等人[44]提出了基于過程間上下文敏感數據流分析的IctApiFinder技術，用來檢測由API演化導致的程序兼容性問題.他們首先給出了不兼容API用法的3個必要條件：

① 有一個SDK版本的API級別大于或等于應用程序中聲明的minSdkVersion值；

② 應用程序在該SDK版本上使用API；

③ 使用的API不包含在該特定版本的SDK中.

其中第2個條件的判斷具有一定的挑戰性，IctApiFinder通過在Heros[57]上實現過程間數據流求解器(inter-procedural data flow solver)，并利用Doop[58]框架從安卓SDK中提取API文件并對每個SDK版本的API信息進行加載，從而精確計算出每一個API可訪問的SDK版本，并以此為依據來檢測兼容性問題.通過與安卓Lint[59]性能的比較，證實了IctApiFinder可以有效地減少檢測的誤報率且具有更大的故障檢測范圍.與PIVOT一樣，IctApiFinder的主要不足在于檢測結果必須要經過人工驗證，對領域知識具有一定的依賴性.

Li等人[33]提出了一種自動檢測技術CiD，旨在檢測應用程序中潛在的API兼容性問題.CiD技術由3個模塊組成：

① API生命周期建模(API lifecycle modeling, ALM)模塊.該模塊通過挖掘安卓框架的修訂歷史來構建API生命周期模型.

② API調用提取(API usage extraction, AUE)模塊.該模塊通過構造條件調用圖(conditional call graph, CCG)來對API函數進行反向數據流分析，以驗證程序是否在與API級別相關的條件中調用了API方法.

③ API兼容性分析(API compatibility analysis, ACA)模塊.該模塊將API生命周期模型與目標API級別的信息進行匹配，并與CCG中API的調用條件進行比較，將有問題的API調用進行標記，以發現與API調用相關的潛在兼容性問題.

CiD的檢測精度和自動化程度較高，但它的局限性也很明顯，與IctApiFinder一樣具有檢測故障類型較為單一的特點，使其無法對API調用錯誤以外的兼容性問題進行檢測.

Tarek等人[60]提出了一種自動化檢測工具ACID，該工具旨在利用安卓應用程序源代碼的API差異和反向數據流分析，以檢測由API演化所導致的兼容性問題.具體來說，ACID以谷歌正式發布的安卓API差異報告和目標應用程序代碼作為輸入，并由4個功能組件對輸入進行處理：

① API差異分析器.對輸入的應用程序代碼提取其API級別，并根據API差異報告識別可疑的API調用.

② API調用定位器.利用自研的詞法分析器對應用程序代碼進行解析，獲取所有的API調用情況，并借助反向數據流分析檢查每個API所屬的API級別.此外，該組件還可以分析類層次結構，來查找回調API使用情況.

③ API調用兼容性問題檢測器.該組件通過使用API調用定位器輸出的API調用情況和API差異分析器輸出的可疑API方法，來檢測API調用兼容性問題.

④ 回調API兼容性問題檢測器.該組件首先對API調用定位器中生成的類層次結構進行解析，并檢查每個API類的繼承和方法覆蓋情況.如果其中有任何覆蓋方法被API差異分析器所標識，則將其被標記為回調API兼容性問題.

此外，與Cider相比，ACID具有更高的檢測精度；與CiD相比，ACID具備更少的時間和內存消耗，因而具有更高的檢測效率.ACID因其卓越的檢測性能，從而成為目前基于數據流分析方法的典型代表.

4) 基于多技術融合的方法.Wei等人[42-43]收集并分析了191個兼容性問題案例，他們發現大多數FIC問題都是由于程序在有問題的軟硬件環境中錯誤地使用安卓API而引發的，因此，他們將每個軟硬件環境和對應的安卓API建模為一個特定的API上下文對(API-context pair, acPair)，并提出了自動化檢測工具FicFinder.他們在已有案例中選擇了25個最有可能在應用程序中重復出現的API上下文對作為acPairs列表，在檢測時FicFinder以acPairs和應用程序的Java字節碼或APK文件作為輸入，利用程序依賴圖和調用圖對程序執行后向切片，根據程序語句依賴關系將語句不斷加入到切片中，直到切片收斂為止.最后，遍歷切片并根據acPairs中的每個acPair規則對其軟硬件配置和API調用情況進行檢查，最終輸出應用程序中可能存在的FIC問題.他們在Soot上實現了FicFinder，并成功檢測出14個未被報告過的兼容性缺陷，以此驗證了FicFinder的有效性.然而，FicFinder在構建acPairs的過程中十分依賴于研究人員的手工分析，且覆蓋范圍較小，也極易過時.

根據以上4種方法，我們總結出了移動應用兼容性問題靜態檢測的一般技術框架,如圖4所示：

Fig. 4 The framework of mobile application compatibility issues static detection圖4 移動應用兼容性問題靜態檢測框架圖

3.2 動態檢測方法

Fazzini等人[31]提出了DIFFDROID，這是一種自動化動態檢測技術，旨在通過結合輸入測試用例生成、用戶界面(user interface, UI)行為建模和差異測試來自動識別移動應用程序中的跨平臺不一致行為(cross-platform inconsistencies, CPIs).DIFFDROID將應用程序作為輸入，并執行4個主要步驟：

1) DIFFDROID自動為應用程序生成大量的輸入測試用例；

2) 將測試用例輸入到運行在特定兼容設備的應用程序中，并構建應用程序的UI行為模型；

3) 將相同測試用例分別輸入到一組其他型號的設備上，并構建應用程序的UI行為模型；

4) 將不同設備上構建的UI模型與特定兼容設備上構建的UI模型進行比較，并向程序開發人員報告排序后的差異.

研究人員在5個基準程序和130多個設備平臺上對DIFFDROID進行了評估，結果表明，DIFFDROID能夠有效地識別應用程序上的CPIs，且誤報率較低.DIFFDROID的局限性在于只能檢測因設備型號差異導致的UI兼容性問題，而且檢測報告必須要經過人工驗證，與此同時，由于其測試的應用程序和設備數量有限，很難做到對所有型號設備的全覆蓋.

Fig. 5 The working process of Mimic圖5 Mimic工作流程圖

Ki等人[27]提出了Mimic系統來執行自動化UI兼容性檢測.研究人員定義了一個編程模型來配置具有多個設備型號、安卓版本和應用程序版本的測試環境，并利用運行時(runtime)提供了一個執行Mimic腳本的環境.與DIFFDROID相比，Mimic允許使用隨機測試和順序測試等多種測試策略，并支持多設備平臺的并行測試，從而大幅度降低了軟件測試的時間成本，并減輕了開發人員的開發負擔，在一定程度上彌補了DIFFDROID存在的缺陷，是當前動態兼容性檢測方法中最具代表性的方法，我們總結了Mimic的工作流程，如圖5所示.Mimic系統首先以一組應用程序和一個腳本作為輸入，隨后在運行時上執行腳本，并在連接的設備集上執行UI測試.Mimic使用OpenCV中的直方圖差異[61]、模板匹配[62]和特征匹配[63]3種方法作為圖像處理機制，以此來量化不同UI之間的視覺差異.研究人員在向前兼容性、向后兼容性等4個測試場景下對Mimic進行了性能評估，驗證了Mimic進行UI兼容性問題測試的有效性.然而，由于Mimic不測試傳感器輸入(比如游戲)和系統事件(比如報警彈窗)等觸發的UI界面更改，因此該系統能夠檢測的應用程序類型是有限的.

3.3 不同類型檢測方法的對比

與靜態檢測方法相比，動態檢測方法的優勢在于檢測準確率高、誤報率低，但是隨之而來的是其算法研究難度也會大幅提高，制定測試策略十分復雜且缺少實用性高的算法.表2從2種不同類型的方法中選出具有代表性的檢測方法，并進行了對比.

Table 2 Comparison Among Typical Methods of Mobile Application Compatibility Detection表2 典型的移動應用兼容性檢測方法比較

Fig. 6 The framework of mobile application compatibility issues location and repair圖6 移動應用兼容性問題定位與修復框架圖

4 移動應用兼容性定位與修復

故障的定位與隨后的修復是解決移動應用兼容性問題中2項關鍵性工作, 故障定位旨在發現兼容性故障產生的根源所在, 而故障修復旨在生成正確有效的兼容性補丁.相對于兼容性故障檢測來說，故障的定位和修復由于難度更大，因此更具研究挑戰性，現有文獻對這2方面的研究較少且處于起步階段，基于現有的研究工作，我們對兼容性故障定位與修復的通用技術流程進行了總結，并提出了移動應用兼容性問題定位與修復框架，如圖6所示.現有方法一般以目標應用程序的APK文件和重現故障的測試用例為輸入，在對測試用例執行結果進行計算和分析的基礎上發現可疑交互數據塊，從而完成對兼容性故障的定位，基于位置信息等依據對API調用情況進行排序，利用API遷移編輯、API調用更新等方法獲取故障修復策略集合，最后完成對所有修復策略的正確性驗證，從而生成最終的故障修復補丁.

故障定位技術可以用來定位兼容性故障產生的位置，而不是檢測兼容性故障的癥狀.Wong等人[64]總結了基于頻譜的故障定位(spectrum-based fault localization, SBFL)技術，這種方法搜集測試用例的代碼覆蓋信息和執行結果，并基于可疑值計算公式(suspicious formula)算出每個語句含有缺陷的概率，最后按照概率值從大到小依次審查語句，直至定位到真正缺陷語句為止，從而實現程序故障定位.這種技術的優點是適用范圍較廣，可以定位由不同原因導致的多種兼容性故障，但由于其計算的是整個程序中所有語句的故障可疑值，因此缺乏有效的語句篩選機制，并容易忽略各程序語句之間存在的依賴關系，從而導致故障定位效率和精度受到限制.

研究兼容性問題的最終目的是能夠高效和低成本地解決此類問題，因此對兼容性故障的修復研究是必不可少的.測試工具僅能夠為開發人員提供一些簡單的手工修復建議，亟待研發更為高效的自動化兼容性故障修復方法.當前已有的兼容性故障修復方法主要有2種，分別是基于API調用更新的方法和基于API遷移編輯的方法.

1) 基于API調用更新的方法.Mobilio等人[65-66]提出了針對API演化而導致的兼容性故障的修復方法FILO，旨在自動向開發人員報告兼容性故障的可能修復位置.FILO的輸入包括一個重現故障的測試用例和2個安卓訪問環境，其中2個安卓環境分別使用兼容API和不兼容API來運行應用程序.FILO的工作主要包括3個階段：

① 測試執行階段.運行重現故障的測試用例，并從2個可用的安卓環境中收集應用程序與安卓API之間的交互.

② 異常檢測階段.通過比較收集到的交互差異來識別具有可疑交互的程序塊.

③ 修復位置識別階段.識別可以實施修復的方法位置，并將其對應的支撐證據按照位置信息進行排序.

FILO將輸出的排序結果報告給開發人員，使其可以根據報告對導致兼容性故障的API方法進行更改.FILO的優點在于其不需要執行測試用例，因此修復成本較低，并可以直接對由于系統級交互出錯而導致的故障提出修復建議.FILO的局限性在于無法對不兼容API進行自動替換或更新，仍然依賴開發者的手工修復.

Malinda等人[51]提出的ARPDroid工具可以定位并自動修復應用程序存在的API權限兼容性故障.在定位階段，ARPDroid通過利用靜態控制流分析，構造程序的API調用圖，并從虛擬主方法開始對該調用圖執行前向遍歷，每當遇到與權限相關的API時，對其執行向后遍歷直至到達API的權限負責調用方(PRC).因此只需要對調用圖執行向后的深度優先搜索即可對PRC進行定位，從而找到導致權限兼容性問題的API位置.

在修復階段，ARPDroid首先由檢測算法產生使用不兼容PRC的列表和每個不兼容PRC中不兼容API的調用點，然后利用其定義的2個修復驗證規則對調用點進行驗證，當驗證失敗時，分2種情況進行修復：如果之前沒有插入API所依賴的權限調用，則使用修復算法自動插入；如果該類是內部類，則替換為更高級的祖先類，從而有效解決了程序中API權限不兼容的問題，同時，由于ARPDroid可以實現修復結果的自動化驗證，因此其很好地節省了故障修復的時間成本.

Fazzini等人[67]提出了一種修復技術AppEvolve，用來修復API演化導致的兼容性問題.在定位階段，AppEvolve可以通過程序間數據流求解器計算目標應用程序可以執行的API版本集，然后通過程序內分析以識別舊的API用法，并檢查其中的方法調用是否可以在新版本的API上執行.如果是這種情況，則說明此類API調用需要更新，并將它們與相應API調用的位置一起存儲在API調用報告中.在修復階段，AppEvolve的輸入包括要更新的目標應用程序和有關API更改的信息，然后執行4個步驟：

① 分析目標應用程序以識別由API更改引起的代碼；

② 搜索現有的代碼庫以獲取對新版本API的更新示例；

③ 分析、排序并將上一步中的更新示例轉換為通用補丁；

④ 將生成的補丁按排名順序應用到目標應用程序，同時執行差異測試以驗證更新.

AppEvolve是在提取其他應用程序現有的更新示例的基礎上提出的，其運行效率主要取決于AppEvolve對更新示例的搜索速度，研究人員在15個應用程序上對AppEvolve進行了評估，其能夠更新85%的API更改，并自動驗證68%的更新，用戶研究證實了該修復方法的有效性.AppEvolve的缺點在于其只能修復特定函數內API的更新，不能處理跨越多個函數的更新.此外，與SBFL技術相比，ARPDroid與AppEvolve在定位階段所采用的故障定位方法都在一定程度上提高了定位精度，然而，兩者也同時受限于特定故障類型，無法對不同原因導致的多類型兼容性故障進行有效定位.

2) 基于API遷移編輯的方法.Xu等人[68]提出了Meditor工具，旨在使用自動API代碼遷移方法來修復API/庫演化導致的向后兼容性問題.Meditor分2個階段執行代碼遷移過程：在第1階段，Meditor對給定庫L的版本標識出使用庫L的開源項目，并在項目的版本歷史記錄中查找所有與遷移相關的(migration-related, MR)提交，對于每個MR提交，Meditor通過語法程序差異(syntactic program diff-erencing)[69]和程序依賴性分析來識別MR代碼更改并對其進行分組，在通過抽象具體的標識符用法來概括每組MR更改之后，Meditor派生出API遷移更改方法并將它們保存到數據庫中.在第2階段，Meditor定義了一個使用L的應用程序P，用來枚舉數據庫中的所有更改方法以決定哪個方法更適用于P，如果更改方法和P之間的上下文信息匹配成功，那么Meditor將應用這些更改并生成遷移版本程序P′.Meditor便可以幫助缺乏經驗的開發人員找到其他開發人員曾應用的API遷移更改，并以此來更改應用程序中的代碼，從而修復API演化帶來的兼容性問題.Meditor具有很好的故障修復效果，但由于其算法實現難度大且修復結果依賴于人工驗證，因此修復成本較高.

我們根據文獻中所提及的FILO，ARPDroid，AppEvolve和Meditor等4種兼容性故障修復方法，在表3中對這些方法進行了對比.

Table 3 Comparison Among Typical Methods of Mobile Application Compatibility Fault Repair表3 典型的移動應用兼容性故障修復方法比較

5 未來展望

針對我們提到的移動應用兼容性問題各階段的研究工作，本節圍繞數據集構建、故障分類方法、故障檢測、故障定位與修復、其他技術拓展5個方面，對移動應用兼容性問題的未來研究方向進行了展望.

5.1 數據集構建

移動應用兼容性故障數據集的構建是開展該領域研究的基礎，如何構建大規模高質量的數據集，并建立數據集的自適應機制，是該領域未來很有價值的研究方向之一.

1) 構建大規模、高質量的數據集.在移動應用兼容性問題的檢測、定位和修復各環節開發過程中，評測數據集對過程所研發的工具或技術的性能評測至關重要，評測數據集可以給出工具性能的直觀評估結果，方便開發人員對工具進行指定功能的改進.當前研究人員大多從Google Play的免費開源移動應用項目中獲取評測數據，獲取的程序文件數量少且覆蓋功能類型不全，使得數據集的規模小且無法對工具進行全面的評估.此外，一些研究者由于擔心數據集的隱私問題被攻擊者利用，從而不愿公開自己的數據集，造成很多實證研究難以重現，是阻礙其他研究人員開展后續工作的關鍵.因此，構建一個大規模、高質量的兼容性評測數據集就顯得尤為重要，研究人員可以在一些開源項目的托管網站(例如GitHub，SourceForge等)中拓展數據來源渠道，同時嘗試與商業企業合作，擴充商業軟件與付費程序，對各類硬件設備信息和第三方庫版本數據進行采集，通過制定合理的數據管理機制和隱私保護機制來構建一個開放、安全、可維護的移動應用兼容性評測數據集.

2) 建立數據集自適應機制.安卓碎片化現象使得所構建的兼容性評測數據集具有明顯的時效性，硬件設備和安卓平臺迭代速度極快，各種移動應用程序版本數量的爆炸式增長對數據集提出了迫切的更新需求.在對數據集進行橫向信息擴充的同時，還要針對同一應用程序和操作系統按照演化時間進行縱向的版本擴充，自適應機制的研發可以有效緩解數據集易過時的問題，在兼容性技術發展的過程中實現數據集各版本數據的動態更新.

5.2 故障分類方法

在移動應用兼容性故障的分類方法研究中，如何探索可靠的分類依據，并研發高效的分類工具，也是該領域未來需要拓展的重要研究方向.

1) 探索可靠的分類依據.在已有的移動應用兼容性問題的分類研究中，一般只按照兼容特性分為向前兼容問題和向后兼容問題，而這種粗略的分類方式無法體現兼容性問題的產生原因和表現程度，因此亟需更加精細的分類依據.在后續研究中，可以嘗試將兼容性問題按照其產生的根本原因進行分類，然后根據特定原因的產生機制進行更精細的子類劃分，或者嘗試以兼容性問題的表現形式進行劃分，總結出不同表現形式所對應的故障產生類型，以此來獲得更加準確的分類依據.

2) 研發高效的分類技術和工具.當前兼容性故障報告大多依靠人工分類，效率低下且容易出錯，亟需研發一個高效的自動化分類工具或分類技術，使其能夠自動對兼容性故障報告進行合理歸類，并給出自動分類依據，或者針對研究人員給出的不同分類依據，完成兼容性故障報告的定向分類和匯總.此外，嘗試對兼容性故障報告進行系統化管理，利用自動化管理系統完成對故障報告的格式統一和有序管理.

5.3 故障檢測

在移動應用兼容性故障的檢測方法研究中，如何研發多類型故障檢測工具，實現基于二進制代碼的檢測方法，能夠對測試設備進行高效篩選，并對檢測結果進行自動化驗證，是該領域未來的重點研究方向之一.

1) 研發多類型故障檢測工具.已有研究中所提出的兼容性故障檢測工具都具有檢測故障類型單一的問題，安卓碎片化和第三方庫的頻繁更新使得現有工具很難對兼容性故障類型進行全面覆蓋.其中靜態檢測方法的誤報率高，而動態檢測中測試策略的制定十分復雜，且缺少實用性高的檢測算法.因此，可以考慮將靜態檢測方法和動態檢測方法進行融合，在拓展工具檢測范圍的同時，綜合考慮運行時間等因素，嘗試以最小代價實現多技術的并行化故障檢測.

2) 基于二進制代碼的檢測.當前兼容性故障檢測工具多數都是基于免費開源應用開發的，利用控制流圖、數據流圖等方法對應用程序的源代碼進行分析，以此完成對兼容性故障的靜態檢測.然而，由于很多商業軟件不會將源代碼對外界公開，因此只將安卓開源應用程序作為研究對象，可能會使工具無法推廣到商業閉源應用程序中.當前研究人員在二進制代碼級別上開展的兼容性研究十分匱乏，對于商業閉源應用程序，利用其二進制代碼執行兼容性故障檢測，是未來很有價值的研究方向之一.

3) 兼容性測試設備高效篩選方法.安卓設備的嚴重碎片化直接導致各類智能終端設備與安卓適配的組合呈指數級增長，在各大設備廠商激烈的市場競爭下，來自不同制造商甚至來自同一制造商的設備品牌和型號層出不窮，提高了企業中兼容性測試的時間成本、財力成本和人力成本，同時也加重了測試人員的負擔.如何研發出更為高效的設備終端篩選方法，優化設備相關兼容性測試的覆蓋范圍，是未來移動應用兼容性測試領域亟待研究的重要課題.

4) 自動驗證故障檢測結果.現有工具執行兼容性故障檢測后的結果一般要經過人工交叉驗證，對領域知識具有一定依賴性，且很難保證驗證結果的準確率，缺乏高效可行的自動化驗證方法.如何利用現有的測試驗證技術開發一款自動化驗證工具，并完成兼容性故障檢測結果的自動驗證，同樣是未來十分有意義的研究課題.

5.4 故障定位與修復

在移動應用兼容性故障的定位與修復方法研究中，如何研發更為精確的故障定位方法和多類型故障修復工具，并探索跨文件/跨函數的修復方法，也是該領域未來的重要研究方向之一.

1) 研發更精確的故障定位方法.兼容性故障定位是一種高效自動的應用程序兼容調試技術，也是兼容性修復工作能夠順利實施的前提.移動應用兼容性故障產生原因的復雜性，使得故障定位的搜索空間十分龐大，導致定位的時間成本過高，且定位結果可能不準確.未來可以嘗試減小故障定位的搜索空間，研發更為精確的定位方法，并對比不同故障定位方法對兼容性問題修復的影響效果.

2) 研發多類型故障修復工具.與兼容性故障檢測的局限性類似，當前研究人員提出的兼容性故障修復工具覆蓋的故障類型不全，且無法保證修復補丁的有效性，修復后也必須要經過人工檢驗.當前修復的主要方法是將定位到的過時安卓API進行更新，旨在解決安卓API演化導致的兼容性故障，而對于第三方庫中API的演化、硬件型號不匹配、分辨率不統一等導致的兼容性故障，目前還沒有有效的修復方法.因此，如何研發一個可以修復多類型兼容性故障的工具，對所定位的故障進行統一修復，是未來研究中亟待解決的難題.

3) 探究跨文件/跨函數的修復方法.當前兼容性故障的修復方法局限于同一個文件內部或函數內部的API更改，無法跨越多個文件或多個函數進行故障修復，導致同一修復方式在多個文件重復進行，嚴重影響兼容性故障的修復效率.探索跨文件/跨函數的兼容性故障修復技術，可以提高故障修復速度，有效緩解修復效率低下的問題.

5.5 其他技術拓展

近年來深度學習算法和人工智能領域的蓬勃發展，為軟件測試與安全領域的研究帶來了契機，深度學習算法在漏洞檢測、應用程序分類、故障修復等諸多研究[70-74]中都有著十分出色的表現.將深度學習技術拓展到安卓移動應用兼容性測試領域中，可能會為當前面臨的很多棘手問題找到最適合的解決方案.

在兼容性故障的分類研究中，可以利用機器學習算法完成兼容性故障的分類，從而獲得一個有效的故障分類工具；在兼容性故障的檢測中，結合自然語言處理算法，利用程序數據流和控制流分析得到程序的上下文信息，將程序中有無兼容性故障轉化為深度學習算法中的二分類問題，從而獲得兼容性故障檢測模型，過濾掉檢測結果中的誤報和漏報，進而提高故障檢測的自動化程度和精度；在兼容性故障的定位與修復中，可以利用深度學習算法獲得更細粒度的故障定位，并對兼容性故障修復方法作為網絡模型輸入，以期獲得一個自動化補丁生成工具.總體來說，深度學習和自然語言處理算法的應用，在安卓移動應用兼容性測試領域的未來研究中具有十分廣闊的前景.

6 總 結

在安卓碎片化現象嚴重的今天，移動應用兼容性問題越來越受到研究人員的關注，本文從安卓移動應用兼容性故障的分析、檢測、定位和修復等方面出發，簡要回顧和總結了近年來相關課題的實踐探索和理論成果.在移動應用兼容性分析中，本文指出了兼容性故障分析面臨的三大挑戰，總結了研究人員在兼容性問題的實證研究和分類研究中所探索到的故障原因及其發展規律.在移動應用兼容性檢測中，我們以檢測過程中是否運行移動應用程序為依據，將程序兼容性檢測技術劃分為靜態檢測和動態檢測2種方法，并對靜態檢測方法進一步劃分為基于規則的、基于控制流分析的、基于數據流分析的和基于多技術融合的方法，并對現有檢測工具進行了評價和比較.在移動應用兼容性定位和修復中，我們對現有的兼容性故障定位和修復技術進行了總結，并歸納出定位和修復階段常用的技術框架.最后從5個方面展望了安卓移動應用兼容性測試領域的未來研究趨勢.

作者貢獻聲明：鄭煒負責提出論文整體研究思路、全文框架設計和最終審核；唐輝負責文獻調研、內容設計、論文撰寫和最后版本修訂；陳翔負責部分文獻調研和全文修訂；張滿青負責論文插圖設計；夏鑫負責調研分析和全文修訂.