本发明涉及计算机领域，具体是一种针对android应用的bug修复和持续交付方案。
背景技术：
Android系统版本众多，机型众多，每次发布一个版本都是需要较长的时间。Android应用版本升级至少需要两周才能达到80％的升级率，严重阻碍了版本迭代速度。也导致市场上App版本分散，处理bug和投诉等也越来越麻烦。
近一两年采用Android热补丁框架解决上述问题非常热门。从开始360公司研发的动态下发lua脚本，到后来出现的各种方案。
早期的补丁框架偏向于以代码修复为主，主要分为两大类：nativehook方案和Multidex方案。
native hook方案如阿里巴巴的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框架，实用性会受到很大的局限。开发需要仔细验证提交内容，确保提交中不包含资源文件的变更以及native so的改动，会导致本就复杂的开发流程变得更加繁琐。所以我们在支持更新Java代码的基础之上，也支持更新资源和native so文件。
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(Android 6.0及以上)的最前面插入自定义的lib文件目录。这样ClassLoader在findLibrary的时候会先在自定义的lib目录中查找，优先加载变更过的so文件。
本发明的工作原理是：本发明通过把APP应用仅仅作为一个加载器。系统启动App之后，加载器决定将要运行的代码和资源的位置。当有新功能或者有bug修复补丁需要推送给用户时，只需要下载对应的文件，通过替换加载器内容即可。即将一个应用app的功能分解为多个部分，核心APP为一个加载模块，其他功能均作为加载模块的内容，当某一个模块出现了问题，或者需要增加删除某一个模块时，只需要通知加载器处理对应的模块即可。此方法可以较为简单便捷的解决业务模块中的bug，以及版本的快速迭代。
上面对本发明的较佳实施方式作了详细说明，但是本发明并不限于上述实施方式，在本领域的普通技术人员所具备的知识范围内，还可以在不脱离本发明宗旨的前提下作出各种变化。