• 
    <ul id="o6k0g"></ul>
    <ul id="o6k0g"></ul>

    一種針對android應用的bug修復和持續交付方案制造技術

    技術編號:15690788 閱讀:74 留言:0更新日期:2017-06-24 03:27
    本發明專利技術公開了一種針對android應用的bug修復和持續交付方案,其主要步驟如下:101:真實的Application類是MyApplication,在編譯期間自動修改AndroidManifest.xml文件,把MyApplication替換為MyNewApplication;102:App啟動后由MyNewApplication加載相應的dex文件后,再將控制權交回給MyApplication。本發明專利技術通過把APP應用僅僅作為一個加載器。系統啟動App之后,加載器決定將要運行的代碼和資源的位置。當有新功能或者有bug修復補丁需要推送給用戶時,只需要下載對應的文件,通過替換加載器內容即可。從而可以較為簡單便捷的解決業務模塊中的bug,以及版本的快速迭代。

    A bug repair and continuous delivery solution for Android Applications

    The invention discloses a method for Android applications in bug repair and continuous delivery plan, its main steps are as follows: 101: the real Application is MyApplication, automatically modify AndroidManifest.xml files during compilation, replace MyApplication with MyNewApplication; 102: App started by MyNewApplication load the corresponding DEX file, and then return control to MyApplication. The invention applies the APP application solely as a loader. After the system starts App, the loader determines the location of the code and resources to be run. When new features or bug fixes need to be pushed to the user, you simply download the corresponding files by replacing the loader contents. Thus, the bug in the business module and the quick iteration of the version can be simply and conveniently solved.

    【技術實現步驟摘要】
    一種針對android應用的bug修復和持續交付方案
    本專利技術涉及計算機領域,具體是一種針對android應用的bug修復和持續交付方案。
    技術介紹
    Android系統版本眾多,機型眾多,每次發布一個版本都是需要較長的時間。Android應用版本升級至少需要兩周才能達到80%的升級率,嚴重阻礙了版本迭代速度。也導致市場上App版本分散,處理bug和投訴等也越來越麻煩。近一兩年采用Android熱補丁框架解決上述問題非常熱門。從開始360公司研發的動態下發lua腳本,到后來出現的各種方案。早期的補丁框架偏向于以代碼修復為主,主要分為兩大類:nativehook方案和Multidex方案。nativehook方案如阿里巴巴的AndFix和Dexposed。Multidex方案如Qzone。切入點都是替換掉將要執行的代碼。基于Qzone方案的思路,出現了nuwa這個比較完善的庫,工具鏈比較完善。但是上述兩種方案都存在一定的缺陷,AndFix只能修改方法、不能修改字段、不能新增類等問題,其庫本身難于維護(需要依賴外部開源力量進行維護),nuwa僅支持更新Java代碼,不能更新資源和so文件,滿足不了需求。
    技術實現思路
    本專利技術的目的在于提供一種針對android應用的bug修復和持續交付方案,以解決上述
    技術介紹
    中提出的問題。為實現上述目的,本專利技術提供如下技術方案:一種針對android應用的bug修復和持續交付方案,其主要步驟如下:101:真實的Application類是MyApplication,在編譯期間自動修改AndroidManifest.xml文件,把MyApplication替換為MyNewApplication;102:App啟動后由MyNewApplication加載相應的dex文件后,再將控制權交回給MyApplication。作為本專利技術進一步的方案:所述MyNewApplication加載相應的dex文件的方法如下:假設Android安裝包中dex文件包含三個文件:classes.dex、classes2.dex和classes3.dex;dex文件的classes.dex充當的角色就是加載器,負責啟動App,并且從App加載資源加載后面的兩個dex文件,classes2.dex和classes3.dex;使App啟動需要用到的所有類都集中在classes.dex中。作為本專利技術再進一步的方案:所述App加載資源是依賴Context#getResources函數返回的Resources對象。與現有技術相比,本專利技術的有益效果是:本專利技術通過把APP應用僅僅作為一個加載器。系統啟動App之后,加載器決定將要運行的代碼和資源的位置。當有新功能或者有bug修復補丁需要推送給用戶時,只需要下載對應的文件,通過替換加載器內容即可。即將一個應用app的功能分解為多個部分,核心APP為一個加載模塊,其他功能均作為加載模塊的內容,當某一個模塊出現了問題,或者需要增加刪除某一個模塊時,只需要通知加載器處理對應的模塊即可。此方法可以較為簡單便捷的解決業務模塊中的bug,以及版本的快速迭代。具體實施方式下面結合具體實施方式對本專利技術的技術方案作進一步詳細地說明。一種針對android應用的bug修復和持續交付方案,其主要步驟如下:Android應用中Application類由于啟動就被加載而不能被更新,我們通過代理Application,控制Application從新dex文件中加載。101:真實的Application類是MyApplication,在編譯期間自動修改AndroidManifest.xml文件,把MyApplication替換為MyNewApplication;所述MyNewApplication是App的入口Application;102:App啟動后由MyNewApplication加載完相應的dex文件后,再將控制權交回給MyApplication;所述MyNewApplication加載相應的dex文件的方法如下:dex文件分成兩部分:patch庫的dex文件(->classes.dex)和業務代碼的dex文件(->classes[N].dex);其中patch庫的dex文件中僅包含了patch庫的全部代碼,并不包含任何其他業務代碼。假設Android安裝包中patch庫的dex文件包含三個文件:classes.dex、classes2.dex和classes3.dex;patch庫的dex文件的classes.dex充當的角色就是加載器,負責啟動App,并且加載后面的兩個dex文件,classes2.dex和classes3.dex;這樣做的目的是,App啟動需要用到的所有類都集中在classes.dex中,同理,業務代碼的dex文件所有類都集中在classes[N].dex中;如果某次下發patch代碼把classes2.dex變更為classes2-1.dex,那么由加載器加載classes2-1.dex和classes3.dex即可實現更新包含MyApplication類在內的所有代碼;如果dex文件有更新,加載器會選擇加載更新后的文件。我們最初采用了Google官方的Multidex方案,擴展DexPathList的dexElements字段。單純更新Java代碼的patch框架,實用性會受到很大的局限。開發需要仔細驗證提交內容,確保提交中不包含資源文件的變更以及nativeso的改動,會導致本就復雜的開發流程變得更加繁瑣。所以我們在支持更新Java代碼的基礎之上,也支持更新資源和nativeso文件。App加載資源是依賴Context#getResources函數返回的Resources對象。Resources內部包裝了AssetManager,最終由AssetManager從Android安裝包文件中加載資源,所以我們反射了替換系統默認的Resources,讓AssetManager從我們更新后的apk中加載資源;現階段的實現支持比如string/anim/drawable/color/layout等資源文件的變更;由于Android系統在安裝apk時候已經把AndroidManifest.xml文件解析并寫入到系統中,目前還不支持修改四大組件,比如增加Activity。在Android項目中使用native函數前需要先調用System.loadLibrary(libName)。首先想到的是在代碼中把加載so文件的代碼改成System.load(libFilePath),讓系統加載自己指定的libFilePath文件。查找lib文件是通過調用PathClassLoader的findLibrary,最終調用到DexPathList的findLibrary。DexPathList會在自己維護的列表目錄中查找對應的lib文件是否存在。所以我們在發現patch文件中有so文件變更的時候,會在PathClassLoader的nativeLibraryDirectories(Android6.0以下)或者nativeLibraryPathElements(Android6本文檔來自技高網...

    【技術保護點】
    一種針對android應用的bug修復和持續交付方案,其特征在于,其主要步驟如下:101:真實的Application類是MyApplication,在編譯期間自動修改AndroidManifest.xml文件,把MyApplication替換為MyNewApplication;102:App啟動后由MyNewApplication加載相應的dex文件后,再將控制權交回給MyApplication。

    【技術特征摘要】
    1.一種針對android應用的bug修復和持續交付方案,其特征在于,其主要步驟如下:101:真實的Application類是MyApplication,在編譯期間自動修改AndroidManifest.xml文件,把MyApplication替換為MyNewApplication;102:App啟動后由MyNewApplication加載相應的dex文件后,再將控制權交回給MyApplication。2.根據權利要求1所述的針對android應用的bug修復和持續交付方案,其特征在于,所述MyNewApplication加載相應的dex文件的...

    【專利技術屬性】
    技術研發人員:朱洪龍
    申請(專利權)人:環球智達科技北京有限公司
    類型:發明
    國別省市:北京,11

    網友詢問留言 已有0條評論
    • 還沒有人留言評論。發表了對其他瀏覽者有用的留言會獲得科技券。

    1
    主站蜘蛛池模板: 无码AⅤ精品一区二区三区| 无码人妻精品一区二区三区66| 日韩精品久久无码中文字幕| 久久久久亚洲AV无码专区桃色 | 无码人妻精品中文字幕免费东京热 | 曰批全过程免费视频在线观看无码| 精品无码综合一区| 麻豆亚洲AV永久无码精品久久| 无码中文字幕人妻在线一区二区三区| 伊人久久综合无码成人网 | 亚洲一区二区三区国产精品无码| 精品人妻无码区在线视频 | 无码伊人66久久大杳蕉网站谷歌| 亚洲大尺度无码无码专线一区 | 精品无码久久久久国产动漫3d| 亚洲人成无码久久电影网站| 2024你懂的网站无码内射| 国产羞羞的视频在线观看 国产一级无码视频在线 | 无码精品人妻一区二区三区漫画 | 国产精品无码一区二区三区电影| 无码中文2020字幕二区| 日韩精品人妻系列无码专区免费| 熟妇人妻中文av无码| 国产精品va无码免费麻豆| 无码丰满熟妇juliaann与黑人| 亚洲中文字幕久久精品无码APP | 人妻少妇乱子伦无码专区| 亚洲AV无码专区在线观看成人| 亚洲成av人片不卡无码| 亚洲VA中文字幕无码一二三区| 亚洲无码日韩精品第一页| 国产精品无码aⅴ嫩草| 无码成人AAAAA毛片| 亚洲精品无码你懂的网站| 国产精品爽爽va在线观看无码| 精品无码国产AV一区二区三区| 亚洲Av无码国产一区二区| 无码中文2020字幕二区| 免费看无码自慰一区二区| 天堂无码在线观看| 中文有码vs无码人妻|