本發(fā)明涉及計(jì)算機(jī)領(lǐng)域，具體是一種針對(duì)android應(yīng)用的bug修復(fù)和持續(xù)交付方案。

背景技術(shù)：

Android系統(tǒng)版本眾多，機(jī)型眾多，每次發(fā)布一個(gè)版本都是需要較長(zhǎng)的時(shí)間。Android應(yīng)用版本升級(jí)至少需要兩周才能達(dá)到80％的升級(jí)率，嚴(yán)重阻礙了版本迭代速度。也導(dǎo)致市場(chǎng)上App版本分散，處理bug和投訴等也越來越麻煩。

近一兩年采用Android熱補(bǔ)丁框架解決上述問題非常熱門。從開始360公司研發(fā)的動(dòng)態(tài)下發(fā)lua腳本，到后來出現(xiàn)的各種方案。

早期的補(bǔ)丁框架偏向于以代碼修復(fù)為主，主要分為兩大類：nativehook方案和Multidex方案。

native hook方案如阿里巴巴的AndFix和Dexposed。Multidex方案如Qzone。切入點(diǎn)都是替換掉將要執(zhí)行的代碼?；赒zone方案的思路，出現(xiàn)了nuwa這個(gè)比較完善的庫(kù)，工具鏈比較完善。

但是上述兩種方案都存在一定的缺陷，AndFix只能修改方法、不能修改字段、不能新增類等問題，其庫(kù)本身難于維護(hù)(需要依賴外部開源力量進(jìn)行維護(hù))，nuwa僅支持更新Java代碼，不能更新資源和so文件，滿足不了需求。

技術(shù)實(shí)現(xiàn)要素：

本發(fā)明的目的在于提供一種針對(duì)android應(yīng)用的bug修復(fù)和持續(xù)交付方案，以解決上述背景技術(shù)中提出的問題。

為實(shí)現(xiàn)上述目的，本發(fā)明提供如下技術(shù)方案：

一種針對(duì)android應(yīng)用的bug修復(fù)和持續(xù)交付方案，其主要步驟如下：

101：真實(shí)的Application類是MyApplication，在編譯期間自動(dòng)修改AndroidManifest.xml文件，把MyApplication替換為MyNewApplication；

102:App啟動(dòng)后由MyNewApplication加載相應(yīng)的dex文件后，再將控制權(quán)交回給MyApplication。

作為本發(fā)明進(jìn)一步的方案：所述MyNewApplication加載相應(yīng)的dex文件的方法如下：假設(shè)Android安裝包中dex文件包含三個(gè)文件：classes.dex、classes2.dex和classes3.dex；dex文件的classes.dex充當(dāng)?shù)慕巧褪羌虞d器，負(fù)責(zé)啟動(dòng)App，并且從App加載資源加載后面的兩個(gè)dex文件，classes2.dex和classes3.dex；使App啟動(dòng)需要用到的所有類都集中在classes.dex中。

作為本發(fā)明再進(jìn)一步的方案：所述App加載資源是依賴Context#getResources函數(shù)返回的Resources對(duì)象。

與現(xiàn)有技術(shù)相比，本發(fā)明的有益效果是：

本發(fā)明通過把APP應(yīng)用僅僅作為一個(gè)加載器。系統(tǒng)啟動(dòng)App之后，加載器決定將要運(yùn)行的代碼和資源的位置。當(dāng)有新功能或者有bug修復(fù)補(bǔ)丁需要推送給用戶時(shí)，只需要下載對(duì)應(yīng)的文件，通過替換加載器內(nèi)容即可。即將一個(gè)應(yīng)用app的功能分解為多個(gè)部分，核心APP為一個(gè)加載模塊，其他功能均作為加載模塊的內(nèi)容，當(dāng)某一個(gè)模塊出現(xiàn)了問題，或者需要增加刪除某一個(gè)模塊時(shí)，只需要通知加載器處理對(duì)應(yīng)的模塊即可。此方法可以較為簡(jiǎn)單便捷的解決業(yè)務(wù)模塊中的bug，以及版本的快速迭代。

具體實(shí)施方式

下面結(jié)合具體實(shí)施方式對(duì)本發(fā)明的技術(shù)方案作進(jìn)一步詳細(xì)地說明。

一種針對(duì)android應(yīng)用的bug修復(fù)和持續(xù)交付方案，其主要步驟如下：Android應(yīng)用中Application類由于啟動(dòng)就被加載而不能被更新，我們通過代理Application，控制Application從新dex文件中加載。

101：真實(shí)的Application類是MyApplication，在編譯期間自動(dòng)修改AndroidManifest.xml文件，把MyApplication替換為MyNewApplication；所述MyNewApplication是App的入口Application；

102:App啟動(dòng)后由MyNewApplication加載完相應(yīng)的dex文件后，再將控制權(quán)交回給MyApplication；

所述MyNewApplication加載相應(yīng)的dex文件的方法如下：

dex文件分成兩部分：patch庫(kù)的dex文件(->classes.dex)和業(yè)務(wù)代碼的dex文件(->classes[N].dex)；其中patch庫(kù)的dex文件中僅包含了patch庫(kù)的全部代碼，并不包含任何其他業(yè)務(wù)代碼。

假設(shè)Android安裝包中patch庫(kù)的dex文件包含三個(gè)文件：classes.dex、classes2.dex和classes3.dex；patch庫(kù)的dex文件的classes.dex充當(dāng)?shù)慕巧褪羌虞d器，負(fù)責(zé)啟動(dòng)App，并且加載后面的兩個(gè)dex文件，classes2.dex和classes3.dex；這樣做的目的是，App啟動(dòng)需要用到的所有類都集中在classes.dex中，同理，業(yè)務(wù)代碼的dex文件所有類都集中在classes[N].dex中；

如果某次下發(fā)patch代碼把classes2.dex變更為classes2-1.dex，那么由加載器加載classes2-1.dex和classes3.dex即可實(shí)現(xiàn)更新包含MyApplication類在內(nèi)的所有代碼；

如果dex文件有更新，加載器會(huì)選擇加載更新后的文件。

我們最初采用了Google官方的Multidex方案，擴(kuò)展DexPathList的dexElements字段。單純更新Java代碼的patch框架，實(shí)用性會(huì)受到很大的局限。開發(fā)需要仔細(xì)驗(yàn)證提交內(nèi)容，確保提交中不包含資源文件的變更以及native so的改動(dòng)，會(huì)導(dǎo)致本就復(fù)雜的開發(fā)流程變得更加繁瑣。所以我們?cè)谥С指翵ava代碼的基礎(chǔ)之上，也支持更新資源和native so文件。

App加載資源是依賴Context#getResources函數(shù)返回的Resources對(duì)象。Resources內(nèi)部包裝了AssetManager，最終由AssetManager從Android安裝包文件中加載資源，所以我們反射了替換系統(tǒng)默認(rèn)的Resources，讓AssetManager從我們更新后的apk中加載資源；現(xiàn)階段的實(shí)現(xiàn)支持比如string/anim/drawable/color/layout等資源文件的變更；由于Android系統(tǒng)在安裝apk時(shí)候已經(jīng)把AndroidManifest.xml文件解析并寫入到系統(tǒng)中，目前還不支持修改四大組件，比如增加Activity。

在Android項(xiàng)目中使用native函數(shù)前需要先調(diào)用System.loadLibrary(libName)。

首先想到的是在代碼中把加載so文件的代碼改成System.load(libFilePath)，讓系統(tǒng)加載自己指定的libFilePath文件。

查找lib文件是通過調(diào)用PathClassLoader的findLibrary，最終調(diào)用到DexPathList的findLibrary。DexPathList會(huì)在自己維護(hù)的列表目錄中查找對(duì)應(yīng)的lib文件是否存在。所以我們?cè)诎l(fā)現(xiàn)patch文件中有so文件變更的時(shí)候，會(huì)在PathClassLoader的nativeLibraryDirectories(Android6.0以下)或者nativeLibraryPathElements(Android 6.0及以上)的最前面插入自定義的lib文件目錄。這樣ClassLoader在findLibrary的時(shí)候會(huì)先在自定義的lib目錄中查找，優(yōu)先加載變更過的so文件。

本發(fā)明的工作原理是：本發(fā)明通過把APP應(yīng)用僅僅作為一個(gè)加載器。系統(tǒng)啟動(dòng)App之后，加載器決定將要運(yùn)行的代碼和資源的位置。當(dāng)有新功能或者有bug修復(fù)補(bǔ)丁需要推送給用戶時(shí)，只需要下載對(duì)應(yīng)的文件，通過替換加載器內(nèi)容即可。即將一個(gè)應(yīng)用app的功能分解為多個(gè)部分，核心APP為一個(gè)加載模塊，其他功能均作為加載模塊的內(nèi)容，當(dāng)某一個(gè)模塊出現(xiàn)了問題，或者需要增加刪除某一個(gè)模塊時(shí)，只需要通知加載器處理對(duì)應(yīng)的模塊即可。此方法可以較為簡(jiǎn)單便捷的解決業(yè)務(wù)模塊中的bug，以及版本的快速迭代。

上面對(duì)本發(fā)明的較佳實(shí)施方式作了詳細(xì)說明，但是本發(fā)明并不限于上述實(shí)施方式，在本領(lǐng)域的普通技術(shù)人員所具備的知識(shí)范圍內(nèi)，還可以在不脫離本發(fā)明宗旨的前提下作出各種變化。