android 基于分包方案的修复

# 本demo实现原理来自

https://github.com/dodola/HotFix

https://zhuanlan.zhihu.com/p/20308548

# Anti类功能,及其原理

如上图,A,B,C是三个class,它们在生成apk文件时,被打包入同一个dex文件中,当apk发布出去运行一段时间发现A类有个bug,现在使用上面链接中的修复方案修复bug。如文中所说,如果直接将A类重写,并使用运行时动态地将修复后的A类所在的dex文件加载并插入到加载链前,则A便可以修复。但是因为在优化的过程中,如果dex文件中的class都不依赖外部文件,则dex文件内部的class会被打一个CLASS_ISPREVERIFIED标签,这样当B类再使用修复后的A类时,因它在另一个dex文件中,则会报运行时错误。所以在B类中,添加一行代码使得它依赖另外一个dex中的Anti类,这样B就不会被打标签。值得注意的是,apk运行的真实环境中,因并不确定哪一(哪几)个类将来会出现问题,所以为了将来可以修复它(它们),上面的A,B,C类都应该被加上引用Anti的代码;另外,因为Anti所在的dex是在Application类的onCreate方法中被加载,所以Application类的onCreate方法前不该引用到Anti类。

# anti_dex.jar 和bug_dex.jar的制作

主要过程:java -> class -> dex

java -> class, 可以使用ide如AS,或者直接命令行使用jdk提供的编译工具

javac -source 1.7 -target 1.7 –cp . –d . <MAIN_CLASS>,该命令需要在包的同一级目录下执行,且MAIN_CLASS包含包路径名。

class -> dex, 可以使用dx工具,形如

dx --dex --output=classes_dex.jar  <CLASS_PATH>

# 测试代码编写

@Override
public void onCreate() {
    super.onCreate();
    File dexPath = new File(getDir("dex", Context.MODE_PRIVATE), "anti_dex.jar");
    Utils.prepareDex(this.getApplicationContext(), dexPath, "anti_dex.jar");
    HotFix.patch(this, dexPath.getAbsolutePath(), "hotfix.test.com.example.didi.applicationtesthotfix.Anti");
    dexPath = new File(getDir("dex", Context.MODE_PRIVATE), "bug_dex.jar");
    Utils.prepareDex(getApplicationContext(), dexPath, "bug_dex.jar");
    HotFix.patch(getApplicationContext(), dexPath.getAbsolutePath(), "hotfix.test.com.example.didi.applicationtesthotfix.BugClass");

    try {
        Class<?> clazz = Class.forName("hotfix.test.com.example.didi.applicationtesthotfix.Anti");
        equalLoader(clazz);
        Log.e("Ruby", "Anti ‘s classloader‘ hashCode " + clazz.getClassLoader().hashCode() + "  , " + clazz.getClassLoader().getClass().getName());
        Class<?> cla = Class.forName("hotfix.test.com.example.didi.applicationtesthotfix.BugClass");
        equalLoader(cla);
        Log.e("Ruby", "BugClass ‘s classloader‘ hashCode " + cla.getClassLoader().hashCode() + "  , " + cla.getClassLoader().getClass().getName());
    } catch (Exception e) {
    }
}

# 剔除Anti的编译脚本

因为Anti.class不能被使用AS一起打包入dex文件中,所以,在编译后打包工程的class文件成dex时,需要先将Anti.class删除,然后借助AS已近编译后的class文件和打包后的资源文件包自己命令行打包成apk文件。

# 打包class文件生成dex 文件
dx=/Users/didi/Library/Android/sdk/build-tools/23.0.3/dx classes=build/intermediates/classes/release/
$dx --dex --output=classes.dex   $classes

# 打包res/ assets/ 文件成 resources-release.ap_ 文件 (AS已完成)

# 打包 resources-release.ap_ 和 classes.dex文件成 Hotfix-unsign.apk
sdklib=/Users/didi/Library/Android/sdk/tools/lib/sdklib.jar
apk=com.android.sdklib.build.ApkBuilderMain
app/build/intermediates/res
resources=build/intermediates/res/resources-release.ap_
java -classpath $sdklib $apk  Hotfix-unsign.apk  -u -z  $resources  -f classes.dex

# 签名
keystore=/Users/didi/Documents/DidiChuxing/driver/lulei.keystore
alia=lulei
psw=demodebug
jarsigner=/System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/jarsigner
$jarsigner -digestalg SHA1 -sigalg MD5withRSA -keystore  $keystore  -storepass $psw -keypass $psw -signedjar  Hotfix-sign.apk Hotfix-unsign.apk  $alia

# 运行时,动态热修复不行的原因

protected Class<?> loadClass(String className, boolean resolve) throws ClassNotFoundException {

    Class<?> clazz = findLoadedClass(className);

    if (clazz == null) {
        ClassNotFoundException suppressed = null;
        try {
            clazz = parent.loadClass(className, false);
        } catch (ClassNotFoundException e) {
            suppressed = e;
        }
        if (clazz == null) {
            try {
                clazz = findClass(className);
            } catch (ClassNotFoundException e) {
                e.addSuppressed(suppressed);
                throw e;
            }
        }
    }
    return clazz;
}

从上面的ClassLoader源码中,可以看到,查找一个类时,先查看内存中该类是否加载,所以如果在加载修复后的类文件A前,已经使用了A类,则该方案就失败,所以该方案要在Application的onCreate方法中将A所在的dex预先load。

# “字节码修改”和 “编译依赖”方案的区别

原则上没有任何区别!

# google 分包方案,是什么鬼,分包策略是什么?

I  still don’t  know!

#  华为i7-ATH-AL00 android版本5.1.1 为什么不插入Anti代码也可以?

What? Fuck!!!

#  反思

虽然使用了自定义的DexClassLoader将修复后的class文件从文件中重新加载到内存中了,但是因为方案中是将DexClassLoader(的父类)的DexFile通过反射赋值给了PathClassLoader(的父类BaseClassLoader 的pathLists成员),所以查看修复后类的classLoader,仍然显示为系统的pathClassLoader。

demo 代码请参考 github地址

时间: 2024-09-29 22:07:49

android 基于分包方案的修复的相关文章

Android dex分包方案

当一个app的功能越来越复杂,代码量越来越多,也许有一天便会突然遇到下列现象: 1. 生成的apk在2.3以前的机器无法安装,提示INSTALL_FAILED_DEXOPT 2. 方法数量过多,编译时出错,提示: Conversion to Dalvik format failed:Unable to execute dex: method ID not in [0, 0xffff]: 65536 出现这种问题的原因是: 1. Android2.3及以前版本用来执行dexopt(用于优化dex文

[转]Android dex分包方案

转载自:https://m.oschina.net/blog/308583 当一个app的功能越来越复杂,代码量越来越多,也许有一天便会突然遇到下列现象: 1. 生成的apk在2.3以前的机器无法安装,提示INSTALL_FAILED_DEXOPT 2. 方法数量过多,编译时出错,提示: Conversion to Dalvik format failed:Unable to execute dex: method ID not in [0, 0xffff]: 65536 出现这种问题的原因是:

《android基于andFix的热修复方案》实战篇

有篇文章说的比较简洁,大家可以参考下:AndFix使用说明 下面说说实际使用中遇到的问题 1:如何继承到gradle项目中 dependencies { compile 'com.alipay.euler:andfix:[email protected]' } 截止目前2016-5-3 这种引用方式,是不会再armeabi-v7下面引入so库的,我们要手动添加进去 地址:https://github.com/alibaba/AndFix/blob/master/libs/armeabi-v7a/

给你一个全自动的屏幕适配方案(基于SW方案)!—— 解放你和UI的双手

Calces系列相关文章:Calces自动实现Android组件化模块构建 前言 屏幕适配一直是移动端开发热议的问题,但是适配方案往往在实际开发的时候会和UI提供的设计稿冲突.本文主要是基于官方推荐的配置限定符方案(Smallest Width目前Android屏幕适配的最优方案)来实现一个接近完美的屏幕适配方案. 对于完美的适配方案笔者是这样定义的: 能完美适配UI稿. 适配完毕后,在高清设备上不会出现模糊的现象. 尽量减少对项目的侵入性. 下面我会从屏幕适配的一些基础知识入手,向你慢慢展现一

Android 基于Netty的消息推送方案之概念和工作原理(二)

上一篇文章中我讲述了关于消息推送的方案以及一个基于Netty实现的一个简单的Hello World.为了更好的理解Hello World中的代码,今天我来解说一下关于Netty中一些概念和工作原理的内容,假设你认为本篇文章有些枯燥.请先去阅读<Android 基于Netty的消息推送方案之Hello World(一)> ChannelEvent Netty是基于事件驱动的,就是我们上文提到的.发生什么事.就通知"有关部门". 所以.不难理解.我们自己的业务代码中,一定有跟这

Android 基于Netty的消息推送方案之对象的传递(四)

在上一篇文章中<Android 基于Netty的消息推送方案之字符串的接收和发送(三)>我们介绍了Netty的字符串传递,我们知道了Netty的消息传递都是基于流,通过ChannelBuffer传递的,那么自然,Object也需要转换成ChannelBuffer来传递.好在Netty本身已经给我们写好了这样的转换工具.ObjectEncoder和ObjectDecoder,下面我们介绍一个案例. 1. 我们构造一个用来传输的对象(JavaBean) [java] view plaincopy

Android 基于Netty的消息推送方案之字符串的接收和发送(三)

在上一篇文章中<Android 基于Netty的消息推送方案之概念和工作原理(二)> ,我们介绍过一些关于Netty的概念和工作原理的内容,今天我们先来介绍一个叫做ChannelBuffer的东东. ChannelBuffer Netty中的消息传递,都必须以字节的形式,以ChannelBuffer为载体传递.简单的说,就是你想直接写个字符串过去,对不起,抛异常.虽然,Netty定义的writer的接口参数是Object的,这可能也是会给新上手的朋友容易造成误会的地方.Netty源码中,是这样

【转】Android 基于google Zxing实现二维码、条形码扫描,仿微信二维码扫描效果--不错

原文网址:http://blog.csdn.net/xiaanming/article/details/10163203 转载请注明出处:http://blog.csdn.net/xiaanming/article/details/10163203 了解二维码这个东西还是从微信中,当时微信推出二维码扫描功能,自己感觉挺新颖的,从一张图片中扫一下竟然能直接加好友,不可思议啊,那时候还不了解二维码,呵呵,然后做项目的时候,老板说要加上二维码扫描功能,然后自己的屁颠屁颠的去百度,google啥的,发现

一个兼容性强的android摄像头调用方案

兼容性强的定义 摄像头像素无关 分辨率无关 屏幕方向无关 摄像头像素无关 像素无关体现在,无论摄像头的像素几何,我都能获取到相对合适的照片. 假设这里的合适是指:需要的照片尺寸和摄像头获取到的数据尺寸是相吻合的. float scale = expectedHeight / expectedWidth; List<Camera.Size> pictureSize = params.getSupportedPictureSizes(); for (Camera.Size size:picture