文献综述（或调研报告）：
智能手机的普及和移动互联网的快速发展使得人们对移动应用的需求越来越大。为了应对市场不断变化的需求，服务提供商必须快速迭代更新产品。当一个应用发布之后，发现了一个严重问题需要进行紧急修复或是要更新一小块功能，通常的做法是:重新打包、进行测试、向各种渠道换包、提示用户升级、下载、重新安装。有时候仅仅是为了修改了一行代码，也要付出巨大的成本进行重新发布并且用户体验太差。为了解决这个问题，业界提出了热修复技术。其具体流程为:应用上线、用户安装、发现问题/更新部分代码、紧急修复、打出补丁并推送给用户、客服端拉取补丁进行修复。热修复开发流程先的更加灵活，无需重新发布，修复成功率高，用户无感知修复，无需下载新的应用，代价小。
当Android系统安装应用的时候会对Dex文件进行优化，这个过程有一个专门的处理工具叫做DexOpt。DexOpt会在第一次加载Dex文件的时候执行。执行后会生成一个ODex文件，即OptimisedDex。ODex的执行效率会比直接执行Dex文件的效率要高很多。但是在Android的早期系统中，DexOpt会检索每一个类的方法id，存在一个链表实现的数据结构里。由于这个链表的长度是short类型的，导致了方法id的数目必须小于65536个。当实现一个比较大的项目的时候，这个方法数的上限是不能满足需求的。尽管在当前Android系统中，DexOpt修复了这个方法限制问题，但是应用仍然需要对低版本的Android系统做兼容。为了解决方法数超限的问题，我们需要将该dex文件拆成多个。为此谷歌官方推出了multidex兼容包实现了一个APK包含多个dex的功能。
假设我们有个APK包含两个dex文件:classes.dex、classes2.dex。在Applicaion实例化之后，兼容包会检查当前系统是否支持multidex，再判断classes2.dex是否需要安装。如果需要安装就从APK压缩包中解压出classes2.dex并拷贝到应用沙盒目录。最后通过反射机制将classes2.dex注入到当前应用的classloader中。
我们知道Java在运行时是通过ClassLoader来加载对应的类。在Android中ClassLoader是一个抽象，一般通过默认的加载器PathClassLoader来加载类。PathClassLoader类被用来加载本地文件中的类，也就是系统类和应用程序中的类。还有一个重要的DexClassLoader加载器，它用来执行未安装或者未被应用程序执行过得代码，一般用来加载jar、apk、zip、dex文件。
Dex加载过程:
(1)首先通过newDexClassLoader传入四个参数dexPath(需要被加载的文件地址)、optimizedDirectory:dex(文件被加载优化后的dex存放路径)、libraryPath(包含libraries的目录列表)、parent(父类构造器)。
(2)在DexClassLoader构造器中会直接调用父类的构造器，将dex文件路径传值给originalPath同时构造一个DexPathList对象。
(3)在DexPathList构造器中:把父类构造器赋值给definingContext、把dexPath分割后对应的file数组赋值给dexElements、把libraryPath分割成数组加上系统so库的目录赋值给nativeLibraryDirectories。
以上是毕业论文文献综述，课题毕业论文、任务书、外文翻译、程序设计、图纸设计等资料可联系客服协助查找。
