热修复_热修复原理 - CSDN
  • 性能优化-热修复

    2019-07-10 10:03:18
    Android的新技术在不断更迭,各种bug修复也如火如荼,增量更新,插件化开发,热修复等等,数不胜数,这一节,就来盘点盘点热修复的来龙去脉 热修复说明 目前在热修复发面,国内众多公司都提出了解决方案,比较出名的...

    Android的新技术在不断更迭,各种bug修复也如火如荼,增量更新,插件化开发,热修复等等,数不胜数,这一节,就来盘点盘点热修复的来龙去脉

    热修复说明

    目前在热修复发面,国内众多公司都提出了解决方案,比较出名的例如阿里的Andfix,现在更新到到第三代,新名字叫做Sophix,腾讯的Tinker,饿了么的Amigo,美团的Robust等等,这里先做阿里和腾讯的例子,因为这两个热修复方案比较典型,一个是从底层C出发,一个是从Java层出发,接下来我们就来看看Tinker的方案是怎么实现热修复的

    仿腾讯热修复

    腾讯的热修复是基于Android加载class来实现热修复的,那么知道这个原理以后,我们也来自己做一个热修复工具,要知道怎么实现这个功能的,就需要先了解Android的类加载机制

    实现原理

    众所周知,其实Android的apk就是一个压缩包,在这个安装包里面放了资源文件(res),资源描述文件(rasc),类文件集合(dex),在这些文件里面,代码编译生成的字节码文件被打包到了dex中,那么Android在使用类的时候会去加载这个dex文件,而加载这个类则是通过PathClassLoader这个类去加载的,那么这个类里面做了些什么事情呢?

    我们查看其源代码,由于这是一个系统级的类,Google在SDK中并没有将其提供出来,那么要查看这个类要么通过下载源代码,要么在线查看,这里推荐一个国内的地址,可以在线查看源代码:androidxref还有androidos

    鉴于PathClassLoader的代码并不多,这里贴出源代码,在源代码里面有这样一句话JAR/ZIP/APK files, possibly containing a "classes.dex" file as well as arbitrary resources. Raw ".dex" files (not inside a zip file),也就是说其可以加载JAR,ZIP,APK格式的压缩包,但在里面必须有classes.dex文件,这里仅仅是两个构造方法,那在父类里面又做了什么呢?

    package dalvik.system;
    
    public class PathClassLoader extends BaseDexClassLoader {
    
    	public PathClassLoader(String dexPath, ClassLoader parent) {
    		super(dexPath, null, null, parent);
    	}
    
    	public PathClassLoader(String dexPath, String librarySearchPath, ClassLoader parent) {
    		super(dexPath, null, librarySearchPath, parent);
    	}
    }
    

    查看源代码,我们得知其继承了BaseDexClassLoader,那么在这个父类里面又做了啥,这里就不细细展开来讲了,这里只关注我们需要的东西,我们注意到,DexPathList这个类里面就是一系列的集合,最需要注意的就是private Element[] dexElements;这个属性,这个属性,这里就是dex的集合,我们的类方法就是从这个获取到的,使用DexPathListfindClass()方法查找类,从而获取到类的,这就是Android类的加载过程,那么我们的想法就可以得以实现。也就是说通过反射得到PathClassLoader这个类就可以调用方法去查找我们的类了,当然也可以调用BaseDexClassLoader

    ···
    private final DexPathList pathList;
    
    public BaseDexClassLoader(String dexPath, File optimizedDirectory,
            String librarySearchPath, ClassLoader parent) {
        super(parent);
        this.pathList = new DexPathList(this, dexPath, librarySearchPath, optimizedDirectory);
    }
    
    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        List<Throwable> suppressedExceptions = new ArrayList<Throwable>();
        Class c = pathList.findClass(name, suppressedExceptions);
        if (c == null) {
            ClassNotFoundException cnfe = new ClassNotFoundException("Didn't find class \"" + name + "\" on path: " + pathList);
            for (Throwable t : suppressedExceptions) {
                cnfe.addSuppressed(t);
            }
            throw cnfe;
        }
        return c;
    }
    ···
    

    上面得到的Class这个方法是怎么实现的呢,浏览DexPathList源代码发现,是通过类的名字获取到类的

    public Class findClass(String name, List<Throwable> suppressed) {
        for (Element element : dexElements) {
            DexFile dex = element.dexFile;
    
            if (dex != null) {
                Class clazz = dex.loadClassBinaryName(name, definingContext, suppressed);
                if (clazz != null) {
                    return clazz;
                }
            }
        }
        if (dexElementsSuppressedExceptions != null) {
            suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions));
        }
        return null;
    }
    

    这里的关键地方在于DexFile的loadClassBinaryName()方法,那么这个方法是怎么查找类的,再继续查看DexFile的源代码,这里直接调到Native方法里面去了,为了一探究竟,我们再去Native方法一探究竟

    public Class loadClassBinaryName(String name, ClassLoader loader, List<Throwable> suppressed) {
        return defineClass(name, loader, mCookie, this, suppressed);
    }
    
    private static Class defineClass(String name, ClassLoader loader, Object cookie,
                                     DexFile dexFile, List<Throwable> suppressed) {
        Class result = null;
        try {
            result = defineClassNative(name, loader, cookie, dexFile);
        } catch (NoClassDefFoundError e) {
            if (suppressed != null) {
                suppressed.add(e);
            }
        } catch (ClassNotFoundException e) {
            if (suppressed != null) {
                suppressed.add(e);
            }
        }
        return result;
    }
    ···
    private static native Class defineClassNative(String name, ClassLoader loader, Object cookie, DexFile dexFile)
                throws ClassNotFoundException, NoClassDefFoundError;
    

    defineClassNative()这个方法的实现位于../art/runtime/native/dalvik_system_DexFile.cc,仔细观察,我们在这里的重心在于找到类是怎么被找到的,我们会发现在将jstring做了一系列转化以后,又调用了FindClassDef()方法,在这个方法里面才真实的去查找类

    static jclass DexFile_defineClassNative(JNIEnv* env,
                                            jclass,
                                            jstring javaName,
                                            jobject javaLoader,
                                            jobject cookie,
                                            jobject dexFile) {
      std::vector<const DexFile*> dex_files;
      const OatFile* oat_file;
      if (!ConvertJavaArrayToDexFiles(env, cookie, /*out*/ dex_files, /*out*/ oat_file)) {
        VLOG(class_linker) << "Failed to find dex_file";
        DCHECK(env->ExceptionCheck());
        return nullptr;
      }
    
      ScopedUtfChars class_name(env, javaName);
      if (class_name.c_str() == nullptr) {
        VLOG(class_linker) << "Failed to find class_name";
        return nullptr;
      }
      const std::string descriptor(DotToDescriptor(class_name.c_str()));
      const size_t hash(ComputeModifiedUtf8Hash(descriptor.c_str()));
      for (auto& dex_file : dex_files) {
        const DexFile::ClassDef* dex_class_def = dex_file->FindClassDef(descriptor.c_str(), hash);
        if (dex_class_def != nullptr) {
          ScopedObjectAccess soa(env);
          ClassLinker* class_linker = Runtime::Current()->GetClassLinker();
          StackHandleScope<1> hs(soa.Self());
          Handle<mirror::ClassLoader> class_loader(
              hs.NewHandle(soa.Decode<mirror::ClassLoader*>(javaLoader)));
          class_linker->RegisterDexFile(*dex_file, class_loader.Get());
          mirror::Class* result = class_linker->DefineClass(soa.Self(),
                                                            descriptor.c_str(),
                                                            hash,
                                                            class_loader,
                                                            *dex_file,
                                                            *dex_class_def);
          // Add the used dex file. This only required for the DexFile.loadClass API since normal
          // class loaders already keep their dex files live.
          class_linker->InsertDexFileInToClassLoader(soa.Decode<mirror::Object*>(dexFile),
                                                     class_loader.Get());
          if (result != nullptr) {
            VLOG(class_linker) << "DexFile_defineClassNative returning " << result
                               << " for " << class_name.c_str();
            return soa.AddLocalReference<jclass>(result);
          }
        }
      }
      VLOG(class_linker) << "Failed to find dex_class_def " << class_name.c_str();
      return nullptr;
    }
    

    那么顺理成章的,我们应该去查找这个FindClassDef()是怎么实现的,在../art/runtime/dex_file.cc终于找到了我们想要的答案,在这里,我们看到了在Native层,其处理就是通过遍历dex,查找到符合的类名就返回,这一点对于我们猜想的实现十分重要

    const DexFile::ClassDef* DexFile::FindClassDef(const char* descriptor, size_t hash) const {
      DCHECK_EQ(ComputeModifiedUtf8Hash(descriptor), hash);
      if (LIKELY(lookup_table_ != nullptr)) {
        const uint32_t class_def_idx = lookup_table_->Lookup(descriptor, hash);
        return (class_def_idx != DexFile::kDexNoIndex) ? &GetClassDef(class_def_idx) : nullptr;
      }
    
      // Fast path for rate no class defs case.
      const uint32_t num_class_defs = NumClassDefs();
      if (num_class_defs == 0) {
        return nullptr;
      }
      const TypeId* type_id = FindTypeId(descriptor);
      if (type_id != nullptr) {
        uint16_t type_idx = GetIndexForTypeId(*type_id);
        for (size_t i = 0; i < num_class_defs; ++i) {
          const ClassDef& class_def = GetClassDef(i);
          if (class_def.class_idx_ == type_idx) {
            return &class_def; //通过一系列计算,找到就返回
          }
        }
      }
      return nullptr;
    }
    

    那么我们在回来看看Java层的代码还有啥可以榨取的,通过对同级目录的观察,发现另外一类DexClassLoader,这个类用途在于加载dex文件,这里是不是和PathClassLoader类似,这就对了,这两者的区别就在于继承父类时候初始化的方式不同,PathClassLoader没有传递optimizedDirectory参数,也就是说其默认了路径,这个路径就是/data/data/{应用包名},而DexClassLoader可以加载任意目录的dex文件,而PathClassLoader只可以加载指定目录下的dex文件

    package dalvik.system;
    
    import java.io.File;
    
    public class DexClassLoader extends BaseDexClassLoader {
    
        public DexClassLoader(String dexPath, String optimizedDirectory,
                String librarySearchPath, ClassLoader parent) {
            super(dexPath, new File(optimizedDirectory), librarySearchPath, parent);
        }
    }
    

    经过上述的分析,我们已经知道怎么Android是怎么实现类的加载的,简单来说就是先加载dex,然后遍历dex里面的类,有符合的类名就返回,不在继续向下查找。基于此,我们可以在这里搞点事情,既然他是从头到尾去遍历类名,那么我将有修复好的类搞到dex里面去,并且放在最前面,那是不是要使用有bug那个类的时候,先找到的是我搞上去的类,然后不再向下查找,那基于Java层的修复不就可以搞定了么,至此,Java层修复的原理已经介绍完毕,接下来便是去实现这个想法了

    准备工作

    要实现这个大胆的想法,我们先要有dex的加载器,选择上面提到的三者都可以,这里选择DexClassLoader,因为这个可以从任何目录加载dex,在没有root权限的时候也很方便做实验,由于这里的初始化需要一个参数,那就选择没有过的PathClassLoader好了,思路有了,也规划好了,那么就开始码代码吧,首先模拟出一个bug,这里就编写一个带有除零操作的类好了

    首先我们是要用到一个工具,这个工具就是multidex,这个工具的作用就是每个类生成单独的.class字节码文件
    使用multidex就需要先配置gradle,先是要引入依赖

    dependencies {
    	implementation 'com.android.support:multidex:1.0.3'
    }
    

    并在gradle中激活

    android {
        ···
        defaultConfig {
            ···
            multiDexEnabled true
    		···
        }
    	···
    }
    

    在Application中使用

    public class MyApplition extends Application {
    	···
        @Override
        protected void attachBaseContext(Context base) {
            super.attachBaseContext(base);
    		···
            MultiDex.install(base);
    		···
        }
    	···
    }
    

    记得在AndroidManifest里面的application标签中引入Application

    <application
        ···
        android:name=".MyApplition"
        ··· >
    	···
    </application>
    

    然后还要记得关闭Instant run,因为这个功能会影响我们的实验,这个功能也是类似热修复的
    Settings -> Build,Exection,Deployment -> Instant run,在这里关闭这个功能
    热修复的实验环境搭建完毕,接下来就可以开始做实验

    实现过程

    首先我们来模拟一个bug的出现,就用一个带有除零错误的类为例,这个类里面就一个方法,这个方法除零了,产生了bug

    public class HotFixTest {
        public void div(Context context){
            int a = 10;
            int b = 0;
            Toast.makeText(context, a + " / " + b + " = " + (a / b), Toast.LENGTH_SHORT).show();
        }
    }
    

    首先构建出必要的布局,由于这里是热修复测试,这里就简单的两个按键,一个代表出错方法的调用,一个代表热修复
    布局

    <?xml version="1.0" encoding="utf-8"?>
    <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
        android:layout_width="match_parent"
        android:layout_height="match_parent"
        android:orientation="vertical">
    
        <Button
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:text="有除零bug"
            android:onClick="onTouch"/>
    
        <Button
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            android:text="修复bug"
            android:onClick="onHotFix"/>
    </LinearLayout>
    

    主活动代码,在这里hotFix()方法只是移动了dex文件,其具体实现在热修复工具类里面

    public class MainActivity extends AppCompatActivity {
    
        @Override
        protected void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            setContentView(R.layout.activity_main);
        }
    
        public void onTouch(View view) {
            HotFixTest hotFixTest = new HotFixTest();
            hotFixTest.div(getApplicationContext());
        }
    
        public void onHotFix(View view) {
            hotFix();
        }
    
        private void hotFix() {
            //目标目录:/data/data/packageName/odex
            File fileDir = getDir(Constants.DEX_DIR, Context.MODE_PRIVATE);
            String name = "classes2.dex";
            String filePath = fileDir.getAbsolutePath() + File.separator + name;
            File file = new File(filePath);
            if (file.exists()) {
                file.delete();
            }
            //将修复好的classes2.dex移动到目标目录
            InputStream is = null;
            FileOutputStream os = null;
            try {
                is = new FileInputStream(Environment.getExternalStorageDirectory().getAbsolutePath() + File.separator + name);
                os = new FileOutputStream(filePath);
                int len = 0;
                byte[] buffer = new byte[1024];
                while ((len = is.read(buffer)) != -1) {
                    os.write(buffer, 0, len);
                }
                if (file.exists()) {
                    Toast.makeText(this, "bug修复完成", Toast.LENGTH_SHORT).show();
                }
                //热修复
                HotFixUtils.loadFixedDex(this);
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    }
    

    热修复工具类,在代码中有详细注释,这里就不赘述了

    public class HotFixUtils {
        private static HashSet<File> loadedDex = new HashSet<File>();
    
        public static void loadFixedDex(Context context) {
            if (context == null) {
                return;
            }
            File fileDir = context.getDir(Constants.DEX_DIR, Context.MODE_PRIVATE);
            File[] listFiles = fileDir.listFiles();
            loadedDex.clear();
            //遍历所有的dex,有的应用可能有多个dex,然后存入集合
            for (File file : listFiles) {
                if (file.getName().startsWith("classes") && file.getName().endsWith(".dex")) {
                    loadedDex.add(file);
                }
            }
            doDexInject(context, fileDir, loadedDex);
        }
    
        //将新的dex合并到旧的dex
        private static void doDexInject(final Context context, File filesDir, HashSet<File> loadedDex) {
            String optimizeDir = filesDir.getAbsolutePath() + File.separator + "opt_dex";
            File fopt = new File(optimizeDir);
            if (!fopt.exists()) {
                fopt.mkdirs();
            }
            try {
                //加载当前应用程序的dex,此时加载的是/data/data/{包名}下的dex
                PathClassLoader pathLoader = (PathClassLoader) context.getClassLoader();
                //这里采用的是每个dex都写入新的类,如果知道在哪个dex里面的类有bug,也可以直接加在里面
                for (File dex : loadedDex) {
                    //加载指定的修复的dex文件。
                    DexClassLoader classLoader = new DexClassLoader(dex.getAbsolutePath(),
                            fopt.getAbsolutePath(), null, pathLoader);
                    //通过反射得到ElementsList
                    Object oldDexObj = getPathList(classLoader);
                    Object newDexObj = getPathList(pathLoader);
                    Object oldDexElementsList = getDexElements(oldDexObj);
                    Object newDexElementsList = getDexElements(newDexObj);
                    //合并新旧dex,将class添加至头部
                    Object dexElements = combineArray(oldDexElementsList, newDexElementsList);
                    //重写给dexElements赋值
                    Object pathList = getPathList(pathLoader);
                    setField(pathList, pathList.getClass(), "dexElements", dexElements);
                }
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    
        //获取pathList属性值
        private static Object getPathList(Object baseDexClassLoader) throws Exception {
            return getField(baseDexClassLoader, Class.forName("dalvik.system.BaseDexClassLoader"), "pathList");
        }
    
        //获取dexElements属性值
        private static Object getDexElements(Object obj) throws Exception {
            return getField(obj, obj.getClass(), "dexElements");
        }
    
        //属性获取
        private static Object getField(Object obj, Class<?> clazz, String field)
                throws NoSuchFieldException, IllegalArgumentException, IllegalAccessException {
            Field localField = clazz.getDeclaredField(field);
            localField.setAccessible(true);
            return localField.get(obj);
        }
    
        //属性赋值
        private static void setField(Object obj, Class<?> cl, String field, Object value) throws Exception {
            Field localField = cl.getDeclaredField(field);
            localField.setAccessible(true);
            localField.set(obj, value);
        }
    
        //数组合并,其实就是将新加入的class写到以前的dex最前面
        private static Object combineArray(Object arrayOld, Object arrayNew) {
            Class<?> localClass = arrayOld.getClass().getComponentType();
            int i = Array.getLength(arrayOld);
            int j = Array.getLength(arrayNew);
            int sum = i + j;
            Object result = Array.newInstance(localClass, sum);
            for (int k = 0; k < sum; k++) {
                if (k < i) {
                    Array.set(result, k, Array.get(arrayOld, k));
                } else {
                    Array.set(result, k, Array.get(arrayNew, k - i));
                }
            }
            return result;
        }
    }
    

    上面又到了一个常量类,这个类里面就一个静态属性

    public class Constants {
        public static final String DEX_DIR = "odex";
    }
    

    到这里,我们的测试就搭建完毕了,此时我们执行除法运算的时候,会直接crash掉,修改源代码,编译生成.class文件
    这里我简单地修改一下除法里面的b的值,将其修改为2,在编译项目,记得不要运行,不然就覆盖了原来的apk了

    public class HotFixTest {
        public void div(Context context){
            int a = 10;
            int b = 2;
            Toast.makeText(context, a + " / " + b + " = " + (a / b), Toast.LENGTH_SHORT).show();
        }
    }
    

    编译完成以后,在当前项目的build->intermediates->classes->debug->{包名}下面会有生成的class文件,将有问题的class文件复制出来,记得连同文件夹包名文件夹一起,例如我的包名是com.cj5785.hotfixtest,那么我复制出来的文件夹结构图如下

    └─dex
    	└─com
    	    └─cj5785
    	        └─hotfixtest
    	                HotFixTest.class
    

    使用sdk里面的一个工具将这个文件打包成dex文件,这个文件夹里面可以有多个class文件,也可以有多个目录,但是其相对位置一定要正确
    这个工具在build-tool -> {版本号}下面,dx.bat就是我们要使用的工具
    然后在命令函中输入参数,由于我这里直接把这个工具所在路径加到环境变量中了,这里就直接使用了

    dx --dex --output=E:\temp\classes2.dex E:\temp\dex
    

    --output的参数就是输出目录,后面接的就是我们刚才复制出来的文件根目录
    根据我们上面写的代码,这里我们将生成的classes2.dex文件放入根目录,启动软件进行验证
    以下是我的验证效果,说明这这种方案的可行性还是有的
    修复效果图

    转载于:https://www.cnblogs.com/cj5785/p/10664631.html

    展开全文
  • Android 热修复 Tinker接入及源码浅析

    万次阅读 多人点赞 2017-02-06 10:03:22
    一、概述 放了一个大长假,happy,先祝大家2017年笑口常开。 假期中一行代码没写,但是想着马上要上班了,赶紧写篇...现在热修复的技术基本上有阿里的AndFix、QZone的方案、美团提出的思想方案以及腾讯的Tinker等。

    本文已在我的公众号hongyangAndroid首发。
    转载请标明出处:
    http://blog.csdn.net/lmj623565791/article/details/54882693
    本文出自张鸿洋的博客

    一、概述

    放了一个大长假,happy,先祝大家2017年笑口常开。

    假期中一行代码没写,但是想着马上要上班了,赶紧写篇博客回顾下技能,于是便有了本文。

    热修复这项技术,基本上已经成为项目比较重要的模块了。主要因为项目在上线之后,都难免会有各种问题,而依靠发版去修复问题,成本太高了。

    现在热修复的技术基本上有阿里的AndFix、QZone的方案、美团提出的思想方案以及腾讯的Tinker等。

    其中AndFix可能接入是最简单的一个(和Tinker命令行接入方式差不多),不过兼容性还是是有一定的问题的;QZone方案对性能会有一定的影响,且在Art模式下出现内存错乱的问题(其实这个问题我之前并不清楚,主要是tinker在MDCC上指出的);美团提出的思想方案主要是基于Instant Run的原理,目前尚未开源,不过这个方案我还是蛮喜欢的,主要是兼容性好。

    这么看来,如果选择开源方案,tinker目前是最佳的选择,tinker的介绍有这么一句:

    Tinker已运行在微信的数亿Android设备上,那么为什么你不使用Tinker呢?

    好了,说了这么多,下面来看看tinker如何接入,以及tinker的大致的原理分析。希望通过本文可以实现帮助大家更好的接入tinker,以及去了解tinker的一个大致的原理。

    二、接入Tinker

    接入tinker目前给了两种方式,一种是基于命令行的方式,类似于AndFix的接入方式;一种就是gradle的方式。

    考虑早期使用Andfix的app应该挺多的,以及很多人对gradle的相关配置还是觉得比较繁琐的,下面对两种方式都介绍下。

    (1)命令行接入

    接入之前我们先考虑下,接入的话,正常需要的前提(开启混淆的状态)。

    • 对于API

      一般来说,我们接入热修库,会在Application#onCreate中进行一下初始化操作。然后在某个地方去调用类似loadPatch这样的API去加载patch文件。

    • 对于patch的生成

      简单的方式就是通过两个apk做对比然后生成;需要注意的是:两个apk做对比,需要的前提条件,第二次打包混淆所使用的mapping文件应该和线上apk是一致的。

    最后就是看看这个项目有没有需要配置混淆;

    有了大致的概念,我们就基本了解命令行接入tinker,大致需要哪些步骤了。

    依赖引入

    dependencies {
        // ...
        //可选,用于生成application类
        provided('com.tencent.tinker:tinker-android-anno:1.7.7')
        //tinker的核心库
        compile('com.tencent.tinker:tinker-android-lib:1.7.7')
    }

    顺便加一下签名的配置:

    android{
      //...
        signingConfigs {
            release {
                try {
                    storeFile file("release.keystore")
                    storePassword "testres"
                    keyAlias "testres"
                    keyPassword "testres"
                } catch (ex) {
                    throw new InvalidUserDataException(ex.toString())
                }
            }
        }
    
        buildTypes {
            release {
                minifyEnabled true
                signingConfig signingConfigs.release
                proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
            }
            debug {
                debuggable true
                minifyEnabled true
                signingConfig signingConfigs.release
                proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
            }
        }
    }

    文末会有demo的下载地址,可以直接参考build.gradle文件,不用担心这些签名文件去哪找。

    API引入

    API主要就是初始化和loadPacth。

    正常情况下,我们会考虑在Application的onCreate中去初始化,不过tinker推荐下面的写法:

    @DefaultLifeCycle(application = ".SimpleTinkerInApplication",
            flags = ShareConstants.TINKER_ENABLE_ALL,
            loadVerifyFlag = false)
    public class SimpleTinkerInApplicationLike extends ApplicationLike {
        public SimpleTinkerInApplicationLike(Application application, int tinkerFlags, boolean tinkerLoadVerifyFlag, long applicationStartElapsedTime, long applicationStartMillisTime, Intent tinkerResultIntent) {
            super(application, tinkerFlags, tinkerLoadVerifyFlag, applicationStartElapsedTime, applicationStartMillisTime, tinkerResultIntent);
        }
    
        @Override
        public void onBaseContextAttached(Context base) {
            super.onBaseContextAttached(base);
        }
    
        @Override
        public void onCreate() {
            super.onCreate();
            TinkerInstaller.install(this);
        }
    }

    ApplicationLike通过名字你可能会猜,并非是Application的子类,而是一个类似Application的类。

    tinker建议编写一个ApplicationLike的子类,你可以当成Application去使用,注意顶部的注解:@DefaultLifeCycle,其application属性,会在编译期生成一个SimpleTinkerInApplication类。

    所以,虽然我们这么写了,但是实际上Application会在编译期生成,所以AndroidManifest.xml中是这样的:

     <application
            android:name=".SimpleTinkerInApplication"
            .../>

    编写如果报红,可以build下。

    这样其实也能猜出来,这个注解背后有个Annotation Processor在做处理,如果你没了解过,可以看下:

    通过该文会对一个编译时注解的运行流程和基本API有一定的掌握,文中也会对tinker该部分的源码做解析。

    上述,就完成了tinker的初始化,那么调用loadPatch的时机,我们直接在Activity中添加一个Button设置:

    
    public class MainActivity extends AppCompatActivity {
    
        @Override
        protected void onCreate(Bundle savedInstanceState) {
            super.onCreate(savedInstanceState);
            setContentView(R.layout.activity_main);
        }
    
    
        public void loadPatch(View view) {
            TinkerInstaller.onReceiveUpgradePatch(getApplicationContext(),
                    Environment.getExternalStorageDirectory().getAbsolutePath() + "/patch_signed.apk");
        }
    }
    

    我们会将patch文件直接push到sdcard根目录;

    所以一定要注意:添加SDCard权限,如果你是6.x以上的系统,自己添加上授权代码,或者手动在设置页面打开SDCard读写权限。

    <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />

    除以以外,有个特殊的地方就是tinker需要在AndroidManifest.xml中指定TINKER_ID。

    <application>
      <meta-data
                android:name="TINKER_ID"
                android:value="tinker_id_6235657" />
        //...
    </application>

    到此API相关的就结束了,剩下的就是考虑patch如何生成。

    patch生成

    tinker提供了patch生成的工具,源码见:tinker-patch-cli,打成一个jar就可以使用,并且提供了命令行相关的参数以及文件。

    命令行如下:

    java -jar tinker-patch-cli-1.7.7.jar -old old.apk -new new.apk -config tinker_config.xml -out output

    需要注意的就是tinker_config.xml,里面包含tinker的配置,例如签名文件等。

    这里我们直接使用tinker提供的签名文件,所以不需要做修改,不过里面有个Application的item修改为与本例一致:

    <loader value="com.zhy.tinkersimplein.SimpleTinkerInApplication"/>

    大致的文件结构如下:

    可以在tinker-patch-cli中提取,或者直接下载文末的例子。

    上述介绍了patch生成的命令,最后需要注意的就是,在第一次打出apk的时候,保留下生成的mapping文件,在/build/outputs/mapping/release/mapping.txt

    可以copy到与proguard-rules.pro同目录,同时在第二次打修复包的时候,在proguard-rules.pro中添加上:

    -applymapping mapping.txt

    保证后续的打包与线上包使用的是同一个mapping文件。

    tinker本身的混淆相关配置,可以参考:

    如果,你对该部分描述不了解,可以直接查看源码即可。

    测试

    首先随便生成一个apk(API、混淆相关已经按照上述引入),安装到手机或者模拟器上。

    然后,copy出mapping.txt文件,设置applymapping,修改代码,再次打包,生成new.apk。

    两次的apk,可以通过命令行指令去生成patch文件。

    如果你下载本例,命令需要在[该目录]下执行。

    最终会在output文件夹中生成产物:

    我们直接将patch_signed.apk push到sdcard,点击loadpatch,一定要观察命令行是否成功。

    本例修改了title。

    点击loadPatch,观察log,如果成功,应用默认为重启,然后再次启动即可达到修复效果。

    到这里命令行的方式就介绍完了,和Andfix的接入的方式基本上是一样的。

    值得注意的是:该例仅展示了基本的接入,对于tinker的各种配置信息,还是需要去读tinker的文档(如果你确定要使用)tinker-wiki

    (2)gradle接入

    gradle接入的方式应该算是主流的方式,所以tinker也直接给出了例子,单独将该tinker-sample-android以project方式引入即可。

    引入之后,可以查看其接入API的方式,以及相关配置。

    在你每次build时,会在build/bakApk下生成本地打包的apk,R文件,以及mapping文件。

    如果你需要生成patch文件,可以通过:

    ./gradlew tinkerPatchRelease  // 或者 ./gradlew tinkerPatchDebug

    生成。

    生成目录为:build/outputs/tinkerPatch

    需要注意的是,需要在app/build.gradle中设置相比较的apk(即old.apk,本次为new.apk),

    ext {
        tinkerEnabled = true
        //old apk file to build patch apk
        tinkerOldApkPath = "${bakPath}/old.apk"
        //proguard mapping file to build patch apk
        tinkerApplyMappingPath = "${bakPath}/old-mapping.txt"
    }

    提供的例子,基本上展示了tinker的自定义扩展的方式,具体还可以参考:

    所以,如果你使用命令行方式接入,也不要忘了学习下其支持哪些扩展。

    三、Application是如何编译时生成的

    从注释和命名上看:

    //可选,用于生成application类
    provided('com.tencent.tinker:tinker-android-anno:1.7.7')

    明显是该库,其结构如下:

    典型的编译时注解的项目,源码见tinker-android-anno

    入口为com.tencent.tinker.anno.AnnotationProcessor,可以在该services/javax.annotation.processing.Processor文件中找到处理类全路径。

    再次建议,如果你不了解,简单阅读下Android 如何编写基于编译时注解的项目该文。

    直接看AnnotationProcessor的process方法:

    @Override
    public boolean process(Set<? extends TypeElement> annotations, RoundEnvironment roundEnv) {
        processDefaultLifeCycle(roundEnv.getElementsAnnotatedWith(DefaultLifeCycle.class));
        return true;
    }

    直接调用了processDefaultLifeCycle:

    private void processDefaultLifeCycle(Set<? extends Element> elements) {
            // 被注解DefaultLifeCycle标识的对象
            for (Element e : elements) {
              // 拿到DefaultLifeCycle注解对象
                DefaultLifeCycle ca = e.getAnnotation(DefaultLifeCycle.class);
    
                String lifeCycleClassName = ((TypeElement) e).getQualifiedName().toString();
                String lifeCyclePackageName = lifeCycleClassName.substring(0, lifeCycleClassName.lastIndexOf('.'));
                lifeCycleClassName = lifeCycleClassName.substring(lifeCycleClassName.lastIndexOf('.') + 1);
    
                String applicationClassName = ca.application();
                if (applicationClassName.startsWith(".")) {
                    applicationClassName = lifeCyclePackageName + applicationClassName;
                }
                String applicationPackageName = applicationClassName.substring(0, applicationClassName.lastIndexOf('.'));
                applicationClassName = applicationClassName.substring(applicationClassName.lastIndexOf('.') + 1);
    
                String loaderClassName = ca.loaderClass();
                if (loaderClassName.startsWith(".")) {
                    loaderClassName = lifeCyclePackageName + loaderClassName;
                }
    
                 // /TinkerAnnoApplication.tmpl
                final InputStream is = AnnotationProcessor.class.getResourceAsStream(APPLICATION_TEMPLATE_PATH);
                final Scanner scanner = new Scanner(is);
                final String template = scanner.useDelimiter("\\A").next();
                final String fileContent = template
                    .replaceAll("%PACKAGE%", applicationPackageName)
                    .replaceAll("%APPLICATION%", applicationClassName)
                    .replaceAll("%APPLICATION_LIFE_CYCLE%", lifeCyclePackageName + "." + lifeCycleClassName)
                    .replaceAll("%TINKER_FLAGS%", "" + ca.flags())
                    .replaceAll("%TINKER_LOADER_CLASS%", "" + loaderClassName)
                    .replaceAll("%TINKER_LOAD_VERIFY_FLAG%", "" + ca.loadVerifyFlag());
                    JavaFileObject fileObject = processingEnv.getFiler().createSourceFile(applicationPackageName + "." + applicationClassName);
                    processingEnv.getMessager().printMessage(Diagnostic.Kind.NOTE, "Creating " + fileObject.toUri());
              Writer writer = fileObject.openWriter();
                PrintWriter pw = new PrintWriter(writer);
                pw.print(fileContent);
                pw.flush();
                writer.close();
    
            }
        }

    代码比较简单,可以分三部分理解:

    • 步骤1:首先找到被DefaultLifeCycle标识的Element(为类对象TypeElement),得到该对象的包名,类名等信息,然后通过该对象,拿到@DefaultLifeCycle对象,获取该注解中声明属性的值。
    • 步骤2:读取一个模板文件,读取为字符串,将各个占位符通过步骤1中的值替代。
    • 步骤3:通过JavaFileObject将替换完成的字符串写文件,其实就是本例中的Application对象。

    我们看一眼模板文件:

    package %PACKAGE%;
    
    import com.tencent.tinker.loader.app.TinkerApplication;
    
    /**
     *
     * Generated application for tinker life cycle
     *
     */
    public class %APPLICATION% extends TinkerApplication {
    
        public %APPLICATION%() {
            super(%TINKER_FLAGS%, "%APPLICATION_LIFE_CYCLE%", "%TINKER_LOADER_CLASS%", %TINKER_LOAD_VERIFY_FLAG%);
        }
    
    }

    对应我们的SimpleTinkerInApplicationLike

    @DefaultLifeCycle(application = ".SimpleTinkerInApplication",
            flags = ShareConstants.TINKER_ENABLE_ALL,
            loadVerifyFlag = false)
    public class SimpleTinkerInApplicationLike extends ApplicationLike {}

    主要就几个占位符:

    • 包名,如果application属性值以点开始,则同包;否则则截取
    • 类名,application属性值中的类名
    • %TINKER_FLAGS%对应flags
    • %APPLICATION_LIFE_CYCLE%,编写的ApplicationLike的全路径
    • “%TINKER_LOADER_CLASS%”,这个值我们没有设置,实际上对应@DefaultLifeCycle的loaderClass属性,默认值为com.tencent.tinker.loader.TinkerLoader
    • %TINKER_LOAD_VERIFY_FLAG%对应loadVerifyFlag

    于是最终生成的代码为:

    /**
     *
     * Generated application for tinker life cycle
     *
     */
    public class SimpleTinkerInApplication extends TinkerApplication {
    
        public SimpleTinkerInApplication() {
            super(7, "com.zhy.tinkersimplein.SimpleTinkerInApplicationLike", "com.tencent.tinker.loader.TinkerLoader", false);
        }
    
    }

    tinker这么做的目的,文档上是这么说的:

    为了减少错误的出现,推荐使用Annotation生成Application类。

    这样大致了解了Application是如何生成的。

    接下来我们大致看一下tinker的原理。

    四、原理

    来源于:https://github.com/Tencent/tinker

    tinker贴了一张大致的原理图。

    可以看出:

    tinker将old.apk和new.apk做了diff,拿到patch.dex,然后将patch.dex与本机中apk的classes.dex做了合并,生成新的classes.dex,运行时通过反射将合并后的dex文件放置在加载的dexElements数组的前面。

    运行时替代的原理,其实和Qzone的方案差不多,都是去反射修改dexElements。

    两者的差异是:Qzone是直接将patch.dex插到数组的前面;而tinker是将patch.dex与app中的classes.dex合并后的全量dex插在数组的前面。

    tinker这么做的目的还是因为Qzone方案中提到的CLASS_ISPREVERIFIED的解决方案存在问题;而tinker相当于换个思路解决了该问题。

    接下来我们就从代码中去验证该原理。

    本片文章源码分析的两条线:

    • 应用启动时,从默认目录加载合并后的classes.dex
    • patch下发后,合成classes.dex至目标目录

    五、源码分析

    (1)加载patch

    加载的代码实际上在生成的Application中调用的,其父类为TinkerApplication,在其attachBaseContext中辗转会调用到loadTinker()方法,在该方法内部,反射调用了TinkerLoader的tryLoad方法。

    @Override
    public Intent tryLoad(TinkerApplication app, int tinkerFlag, boolean tinkerLoadVerifyFlag) {
        Intent resultIntent = new Intent();
    
        long begin = SystemClock.elapsedRealtime();
        tryLoadPatchFilesInternal(app, tinkerFlag, tinkerLoadVerifyFlag, resultIntent);
        long cost = SystemClock.elapsedRealtime() - begin;
        ShareIntentUtil.setIntentPatchCostTime(resultIntent, cost);
        return resultIntent;
    }

    tryLoadPatchFilesInternal中会调用到loadTinkerJars方法:

    private void tryLoadPatchFilesInternal(TinkerApplication app, int tinkerFlag, boolean tinkerLoadVerifyFlag, Intent resultIntent) {
        // 省略大量安全性校验代码
    
        if (isEnabledForDex) {
            //tinker/patch.info/patch-641e634c/dex
            boolean dexCheck = TinkerDexLoader.checkComplete(patchVersionDirectory, securityCheck, resultIntent);
            if (!dexCheck) {
                //file not found, do not load patch
                Log.w(TAG, "tryLoadPatchFiles:dex check fail");
                return;
            }
        }
    
        //now we can load patch jar
        if (isEnabledForDex) {
            boolean loadTinkerJars = TinkerDexLoader.loadTinkerJars(app, tinkerLoadVerifyFlag, patchVersionDirectory, resultIntent, isSystemOTA);
            if (!loadTinkerJars) {
                Log.w(TAG, "tryLoadPatchFiles:onPatchLoadDexesFail");
                return;
            }
        }
    }

    TinkerDexLoader.checkComplete主要是用于检查下发的meta文件中记录的dex信息(meta文件,可以查看生成patch的产物,在assets/dex-meta.txt),检查meta文件中记录的dex文件信息对应的dex文件是否存在,并把值存在TinkerDexLoader的静态变量dexList中。

    TinkerDexLoader.loadTinkerJars传入四个参数,分别为application,tinkerLoadVerifyFlag(注解上声明的值,传入为false),patchVersionDirectory当前version的patch文件夹,intent,当前patch是否仅适用于art。

    @TargetApi(Build.VERSION_CODES.ICE_CREAM_SANDWICH)
    public static boolean loadTinkerJars(Application application, boolean tinkerLoadVerifyFlag, 
        String directory, Intent intentResult, boolean isSystemOTA) {
            PathClassLoader classLoader = (PathClassLoader) TinkerDexLoader.class.getClassLoader();
    
            String dexPath = directory + "/" + DEX_PATH + "/";
            File optimizeDir = new File(directory + "/" + DEX_OPTIMIZE_PATH);
    
            ArrayList<File> legalFiles = new ArrayList<>();
    
            final boolean isArtPlatForm = ShareTinkerInternals.isVmArt();
            for (ShareDexDiffPatchInfo info : dexList) {
                //for dalvik, ignore art support dex
                if (isJustArtSupportDex(info)) {
                    continue;
                }
                String path = dexPath + info.realName;
                File file = new File(path);
    
                legalFiles.add(file);
            }
            // just for art
            if (isSystemOTA) {
                parallelOTAResult = true;
                parallelOTAThrowable = null;
                Log.w(TAG, "systemOTA, try parallel oat dexes!!!!!");
    
                TinkerParallelDexOptimizer.optimizeAll(
                    legalFiles, optimizeDir,
                    new TinkerParallelDexOptimizer.ResultCallback() {
                    }
                );
    
            SystemClassLoaderAdder.installDexes(application, classLoader, optimizeDir, legalFiles);
            return true;
        }
    

    找出仅支持art的dex,且当前patch是否仅适用于art时,并行去loadDex。

    关键是最后的installDexes:

    @SuppressLint("NewApi")
    public static void installDexes(Application application, PathClassLoader loader, File dexOptDir, List<File> files)
        throws Throwable {
    
        if (!files.isEmpty()) {
            ClassLoader classLoader = loader;
            if (Build.VERSION.SDK_INT >= 24) {
                classLoader = AndroidNClassLoader.inject(loader, application);
            }
            //because in dalvik, if inner class is not the same classloader with it wrapper class.
            //it won't fail at dex2opt
            if (Build.VERSION.SDK_INT >= 23) {
                V23.install(classLoader, files, dexOptDir);
            } else if (Build.VERSION.SDK_INT >= 19) {
                V19.install(classLoader, files, dexOptDir);
            } else if (Build.VERSION.SDK_INT >= 14) {
                V14.install(classLoader, files, dexOptDir);
            } else {
                V4.install(classLoader, files, dexOptDir);
            }
            //install done
            sPatchDexCount = files.size();
            Log.i(TAG, "after loaded classloader: " + classLoader + ", dex size:" + sPatchDexCount);
    
            if (!checkDexInstall(classLoader)) {
                //reset patch dex
                SystemClassLoaderAdder.uninstallPatchDex(classLoader);
                throw new TinkerRuntimeException(ShareConstants.CHECK_DEX_INSTALL_FAIL);
            }
        }
    }

    这里实际上就是根据不同的系统版本,去反射处理dexElements。

    我们看一下V19的实现(主要我看了下本机只有个22的源码~):

    private static final class V19 {
    
        private static void install(ClassLoader loader, List<File> additionalClassPathEntries,
                                    File optimizedDirectory)
            throws IllegalArgumentException, IllegalAccessException,
            NoSuchFieldException, InvocationTargetException, NoSuchMethodException, IOException {
    
            Field pathListField = ShareReflectUtil.findField(loader, "pathList");
            Object dexPathList = pathListField.get(loader);
            ArrayList<IOException> suppressedExceptions = new ArrayList<IOException>();
            ShareReflectUtil.expandFieldArray(dexPathList, "dexElements", makeDexElements(dexPathList,
                new ArrayList<File>(additionalClassPathEntries), optimizedDirectory,
                suppressedExceptions));
            if (suppressedExceptions.size() > 0) {
                for (IOException e : suppressedExceptions) {
                    Log.w(TAG, "Exception in makeDexElement", e);
                    throw e;
                }
            }
        }
    }        
    1. 找到PathClassLoader(BaseDexClassLoader)对象中的pathList对象
    2. 根据pathList对象找到其中的makeDexElements方法,传入patch相关的对应的实参,返回Element[]对象
    3. 拿到pathList对象中原本的dexElements方法
    4. 步骤2与步骤3中的Element[]数组进行合并,将patch相关的dex放在数组的前面
    5. 最后将合并后的数组,设置给pathList

    这里其实和Qzone的提出的方案基本是一致的。如果你以前未了解过Qzone的方案,可以参考此文:

    (2)合成patch

    这里的入口为:

     TinkerInstaller.onReceiveUpgradePatch(getApplicationContext(),
                    Environment.getExternalStorageDirectory().getAbsolutePath() + "/patch_signed.apk");

    上述代码会调用DefaultPatchListener中的onPatchReceived方法:

    # DefaultPatchListener
    @Override
    public int onPatchReceived(String path) {
    
        int returnCode = patchCheck(path);
    
        if (returnCode == ShareConstants.ERROR_PATCH_OK) {
            TinkerPatchService.runPatchService(context, path);
        } else {
            Tinker.with(context).getLoadReporter().onLoadPatchListenerReceiveFail(new File(path), returnCode);
        }
        return returnCode;
    
    }

    首先对tinker的相关配置(isEnable)以及patch的合法性进行检测,如果合法,则调用TinkerPatchService.runPatchService(context, path);

    public static void runPatchService(Context context, String path) {
        try {
            Intent intent = new Intent(context, TinkerPatchService.class);
            intent.putExtra(PATCH_PATH_EXTRA, path);
            intent.putExtra(RESULT_CLASS_EXTRA, resultServiceClass.getName());
            context.startService(intent);
        } catch (Throwable throwable) {
            TinkerLog.e(TAG, "start patch service fail, exception:" + throwable);
        }
    }

    TinkerPatchService是IntentService的子类,这里通过intent设置了两个参数,一个是patch的路径,一个是resultServiceClass,该值是调用Tinker.install的时候设置的,默认为DefaultTinkerResultService.class。由于是IntentService,直接看onHandleIntent即可,如果你对IntentService陌生,可以查看此文:Android IntentService完全解析 当Service遇到Handler

    @Override
    protected void onHandleIntent(Intent intent) {
        final Context context = getApplicationContext();
        Tinker tinker = Tinker.with(context);
    
    
        String path = getPatchPathExtra(intent);
    
        File patchFile = new File(path);
    
        boolean result;
    
        increasingPriority();
        PatchResult patchResult = new PatchResult();
    
        result = upgradePatchProcessor.tryPatch(context, path, patchResult);
    
        patchResult.isSuccess = result;
        patchResult.rawPatchFilePath = path;
        patchResult.costTime = cost;
        patchResult.e = e;
    
        AbstractResultService.runResultService(context, patchResult, getPatchResultExtra(intent));
    
    }

    比较清晰,主要关注upgradePatchProcessor.tryPatch方法,调用的是UpgradePatch.tryPatch。ps:这里有个有意思的地方increasingPriority(),其内部实现为:

    private void increasingPriority() {
        TinkerLog.i(TAG, "try to increase patch process priority");
        try {
            Notification notification = new Notification();
            if (Build.VERSION.SDK_INT < 18) {
                startForeground(notificationId, notification);
            } else {
                startForeground(notificationId, notification);
                // start InnerService
                startService(new Intent(this, InnerService.class));
            }
        } catch (Throwable e) {
            TinkerLog.i(TAG, "try to increase patch process priority error:" + e);
        }
    }

    如果你对“保活”这个话题比较关注,那么对这段代码一定不陌生,主要是利用系统的一个漏洞来启动一个前台Service。如果有兴趣,可以参考此文:关于 Android 进程保活,你所需要知道的一切

    下面继续回到tryPatch方法:

    # UpgradePatch
    @Override
    public boolean tryPatch(Context context, String tempPatchPath, PatchResult patchResult) {
        Tinker manager = Tinker.with(context);
    
        final File patchFile = new File(tempPatchPath);
    
        //it is a new patch, so we should not find a exist
        SharePatchInfo oldInfo = manager.getTinkerLoadResultIfPresent().patchInfo;
        String patchMd5 = SharePatchFileUtil.getMD5(patchFile);
    
        //use md5 as version
        patchResult.patchVersion = patchMd5;
        SharePatchInfo newInfo;
    
        //already have patch
        if (oldInfo != null) {
            newInfo = new SharePatchInfo(oldInfo.oldVersion, patchMd5, Build.FINGERPRINT);
        } else {
            newInfo = new SharePatchInfo("", patchMd5, Build.FINGERPRINT);
        }
    
        //check ok, we can real recover a new patch
        final String patchDirectory = manager.getPatchDirectory().getAbsolutePath();
        final String patchName = SharePatchFileUtil.getPatchVersionDirectory(patchMd5);
        final String patchVersionDirectory = patchDirectory + "/" + patchName;
    
        //copy file
        File destPatchFile = new File(patchVersionDirectory + "/" + SharePatchFileUtil.getPatchVersionFile(patchMd5));
        // check md5 first
        if (!patchMd5.equals(SharePatchFileUtil.getMD5(destPatchFile))) {
            SharePatchFileUtil.copyFileUsingStream(patchFile, destPatchFile);
        }
    
        //we use destPatchFile instead of patchFile, because patchFile may be deleted during the patch process
        if (!DexDiffPatchInternal.tryRecoverDexFiles(manager, signatureCheck, context, patchVersionDirectory, 
                    destPatchFile)) {
            TinkerLog.e(TAG, "UpgradePatch tryPatch:new patch recover, try patch dex failed");
            return false;
        }
    
        return true;
    }

    拷贝patch文件拷贝至私有目录,然后调用DexDiffPatchInternal.tryRecoverDexFiles

    protected static boolean tryRecoverDexFiles(Tinker manager, ShareSecurityCheck checker, Context context,
                                                    String patchVersionDirectory, File patchFile) {
        String dexMeta = checker.getMetaContentMap().get(DEX_META_FILE);
        boolean result = patchDexExtractViaDexDiff(context, patchVersionDirectory, dexMeta, patchFile);
        return result;
    }

    直接看patchDexExtractViaDexDiff

    private static boolean patchDexExtractViaDexDiff(Context context, String patchVersionDirectory, String meta, final File patchFile) {
        String dir = patchVersionDirectory + "/" + DEX_PATH + "/";
    
        if (!extractDexDiffInternals(context, dir, meta, patchFile, TYPE_DEX)) {
            TinkerLog.w(TAG, "patch recover, extractDiffInternals fail");
            return false;
        }
    
        final Tinker manager = Tinker.with(context);
    
        File dexFiles = new File(dir);
        File[] files = dexFiles.listFiles();
    
        ...files遍历执行:DexFile.loadDex
         return true;
    }

    核心代码主要在extractDexDiffInternals中:

    private static boolean extractDexDiffInternals(Context context, String dir, String meta, File patchFile, int type) {
        //parse meta
        ArrayList<ShareDexDiffPatchInfo> patchList = new ArrayList<>();
        ShareDexDiffPatchInfo.parseDexDiffPatchInfo(meta, patchList);
    
        File directory = new File(dir);
        //I think it is better to extract the raw files from apk
        Tinker manager = Tinker.with(context);
        ZipFile apk = null;
        ZipFile patch = null;
    
        ApplicationInfo applicationInfo = context.getApplicationInfo();
    
        String apkPath = applicationInfo.sourceDir; //base.apk
        apk = new ZipFile(apkPath);
        patch = new ZipFile(patchFile);
    
        for (ShareDexDiffPatchInfo info : patchList) {
    
            final String infoPath = info.path;
            String patchRealPath;
            if (infoPath.equals("")) {
                patchRealPath = info.rawName;
            } else {
                patchRealPath = info.path + "/" + info.rawName;
            }
    
            File extractedFile = new File(dir + info.realName);
    
            ZipEntry patchFileEntry = patch.getEntry(patchRealPath);
            ZipEntry rawApkFileEntry = apk.getEntry(patchRealPath);
    
            patchDexFile(apk, patch, rawApkFileEntry, patchFileEntry, info, extractedFile);
        }
    
        return true;
    }

    这里的代码比较关键了,可以看出首先解析了meta里面的信息,meta中包含了patch中每个dex的相关数据。然后通过Application拿到sourceDir,其实就是本机apk的路径以及patch文件;根据mate中的信息开始遍历,其实就是取出对应的dex文件,最后通过patchDexFile对两个dex文件做合并。

    private static void patchDexFile(
                ZipFile baseApk, ZipFile patchPkg, ZipEntry oldDexEntry, ZipEntry patchFileEntry,
                ShareDexDiffPatchInfo patchInfo,  File patchedDexFile) throws IOException {
        InputStream oldDexStream = null;
        InputStream patchFileStream = null;
    
        oldDexStream = new BufferedInputStream(baseApk.getInputStream(oldDexEntry));
        patchFileStream = (patchFileEntry != null ? new BufferedInputStream(patchPkg.getInputStream(patchFileEntry)) : null);
    
        new DexPatchApplier(oldDexStream, patchFileStream).executeAndSaveTo(patchedDexFile);
    
    }

    通过ZipFile拿到其内部文件的InputStream,其实就是读取本地apk对应的dex文件,以及patch中对应dex文件,对二者的通过executeAndSaveTo方法进行合并至patchedDexFile,即patch的目标私有目录。

    至于合并算法,这里其实才是tinker比较核心的地方,这个算法跟dex文件格式紧密关联,如果有机会,然后我又能看懂的话,后面会单独写篇博客介绍。此外dodola已经有篇博客进行了介绍:

    感兴趣的可以阅读下。

    好了,到此我们就大致了解了tinker热修复的原理~~

    测试demo地址:

    当然这里只分析了代码了热修复,后续考虑分析资源以及So的热修、核心的diff算法、以及gradle插件等相关知识~


    最后欢迎关注我的公众号~

    我的微信公众号:hongyangAndroid
    (可以给我留言你想学习的文章,支持投稿)

    展开全文
  • 热修复原理分析

    千次阅读 2017-05-30 17:53:49
    什么是热修复 热修复是指在用户无感知情况下对已安装的app使用补丁进行紧急修复。优点,效率高,用户体验好。 热修复框架 android热修复技术主要可以分为两类: 一类是利用java hook的技术来替换要修复的方法...

    什么是热修复


    热修复是指在用户无感知情况下对已安装的app使用补丁进行紧急修复。优点,效率高,用户体验好。

    热修复框架


    android热修复技术主要可以分为两类:
    一类是利用java hook的技术来替换要修复的方法。代表有阿里的DeXposedAndfix
    一类是利用java类加载机制优先返回修复的类。代表有TinkerHotFixNuwaRocooFixRobust
    这两类都有着自己的优缺点,事实上从来都没有最好的方案,只有最适合自己的。

    热修复原理

    热修复实现的利用了Java的类加载机制,关键点是dexElments,代码如下:
    /**
         * Finds the named class in one of the dex files pointed at by
         * this instance. This will find the one in the earliest listed
         * path element. If the class is found but has not yet been
         * defined, then this method will define it in the defining
         * context that this instance was constructed with.
         *
         * @param name of class to find
         * @param suppressed exceptions encountered whilst finding the class
         * @return the named class or {@code null} if the class is not
         * found in any of the dex files
         */
        public Class findClass(String name, List<Throwable> suppressed) {
            for (Element element : dexElements) {
                DexFile dex = element.dexFile;
    
                if (dex != null) {
                    Class clazz = dex.loadClassBinaryName(name, definingContext, suppressed);
                    if (clazz != null) {
                        return clazz;
                    }
                }
            }
            if (dexElementsSuppressedExceptions != null) {
                suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions));
            }
            return null;
        }
    寻找大致过程PathClassLoader ->BaseDexClassLoader.findClass(String name)->PathList.findClass(name, suppressedExceptions).
    大致相关的5个类:
    PathClassLoader 用来加载应用程序的dex
    /**
     * Provides a simple {@link ClassLoader} implementation that operates on a list
     * of files and directories in the local file system, but does not attempt to
     * load classes from the network. Android uses this class for its system class
     * loader and for its application class loader(s).
     */
    public class PathClassLoader extends BaseDexClassLoader {

    DexClassLoader  这个类是可以用来从.jar文件和.apk文件中加载classed.dex。(必须要在应用程序的目录下面。最终是加载jar、apk文件里的dex文件)
    /**
     * A class loader that loads classes from {@code .jar} and {@code .apk} files
     * containing a {@code classes.dex} entry. This can be used to execute code not
     * installed as part of an application.
     *
     * <p>This class loader requires an application-private, writable directory to
     * cache optimized classes. Use {@code Context.getCodeCacheDir()} to create
     * such a directory: <pre>   {@code
     *   File dexOutputDir = context.getCodeCacheDir();
     * }</pre>
     *
     * <p><strong>Do not cache optimized classes on external storage.</strong>
     * External storage does not provide access controls necessary to protect your
     * application from code injection attacks.
     */
    public class DexClassLoader extends BaseDexClassLoader {

    BaseDexClassLoader PathClassLoader和DexClassLoader继承这个类。BaseDexClassLoader查找类的方法:
    /**
     * Base class for common functionality between various dex-based
     * {@link ClassLoader} implementations.
     */
    public class BaseDexClassLoader extends ClassLoader {
        private final DexPathList pathList;
        //.... code
        @Override
        protected Class<?> findClass(String name) throws ClassNotFoundException {
            List<Throwable> suppressedExceptions = new ArrayList<Throwable>();
            Class c = pathList.findClass(name, suppressedExceptions);
            if (c == null) {
                ClassNotFoundException cnfe = new ClassNotFoundException("Didn't find class \"" + name + "\" on path: " + pathList);
                for (Throwable t : suppressedExceptions) {
                    cnfe.addSuppressed(t);
                }
                throw cnfe;
            }
            return c;
        }
    findClass()方法中用到了pathList.findClass(name),附DexPathList类代码
    final class DexPathList {
        
        /**
         * List of dex/resource (class path) elements.
         * Should be called pathElements, but the Facebook app uses reflection
         * to modify 'dexElements' (http://b/7726934).
         */
        private Element[] dexElements;
    
       /**
         * Finds the named class in one of the dex files pointed at by
         * this instance. This will find the one in the earliest listed
         * path element. If the class is found but has not yet been
         * defined, then this method will define it in the defining
         * context that this instance was constructed with.
         *
         * @param name of class to find
         * @param suppressed exceptions encountered whilst finding the class
         * @return the named class or {@code null} if the class is not
         * found in any of the dex files
         */
        public Class findClass(String name, List<Throwable> suppressed) {
            for (Element element : dexElements) {
                DexFile dex = element.dexFile;
    
                if (dex != null) {
                    Class clazz = dex.loadClassBinaryName(name, definingContext, suppressed);
                    if (clazz != null) {
                        return clazz;
                    }
                }
            }
            if (dexElementsSuppressedExceptions != null) {
                suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions));
            }
            return null;
    }
    

    DexFile.loadClassBinaryName方法:
    public final class DexFile {
        /**
         * See {@link #loadClass(String, ClassLoader)}.
         *
         * This takes a "binary" class name to better match ClassLoader semantics.
         *
         * @hide
         */
        public Class loadClassBinaryName(String name, ClassLoader loader, List<Throwable> suppressed) {
            return defineClass(name, loader, mCookie, this, suppressed);
        }
    
        private static Class defineClass(String name, ClassLoader loader, Object cookie,
                                         DexFile dexFile, List<Throwable> suppressed) {
            Class result = null;
            try {
                result = defineClassNative(name, loader, cookie, dexFile);
            } catch (NoClassDefFoundError e) {
                if (suppressed != null) {
                    suppressed.add(e);
                }
            } catch (ClassNotFoundException e) {
                if (suppressed != null) {
                    suppressed.add(e);
                }
            }
            return result;
        }
        private static native Class defineClassNative(String name, ClassLoader loader, Object cookie,
                                                      DexFile dexFile)
                throws ClassNotFoundException, NoClassDefFoundError;
    }

    类所在路径:

    总结:一个ClassLoader可以包含多个dex文件,每个dex文件是一个Element,多个dex文件排列成一个有序的数组dexElements,当找类的时候,会按顺序遍历dex文件,然后从当前遍历的dex文件中找类,如果找类则返回,如果找不到从下一个dex文件继续查找。(出自安卓App热补丁动态修复技术介绍)

    热修复原理:
    ClassLoader加载类会遍历dexElments数组,从dex文件中不断寻找你要的class,找到后立即返回class,后面的dex文件不再读取。热修复就是把有问题class打包成fixDex文件,插入dexElements靠前的位置,让修复的class优先被找到。

    手动实现热修复

    1步:通过使用dx.bat将修复的class打包成fix.dex。
    命令 : dx --dex --output=E:\patch\dex\fix.dex  E:\patch\cls
     --output=E:\patch\dex\fix.dex dex输出路径
    E:\patch\cls 打包指定目录下面的class字节文件(注意要包括全路径的文件夹,也可以有多个class)

    2歩:将fix.dex拷贝到SD卡目录下(模拟fix.dex已从服务器上下载到SD卡)

    3歩:将fix.dex文件搬到应用目录下,如/data/data/pkgName/odex/

    4歩:通过反射将fix.dex添加到dexElements比较靠前的位置(要在bug class所在的dex前面)。
    这里借助工具类FixDexUtils.

    5歩:自定义MyApplication,onCreate方法中调用FixDexUtils.loadFixedDex(this);

    FixDexUtils代码:
    public class FixDexUtils {
        private static final String DEX_DIR = "odex";
        private static HashSet<File> loadedDex = new HashSet<File>();
    
        static {
            loadedDex.clear();
        }
    
        public static void loadFixedDex(Context context) {
            if (context == null) {
                return;
            }
            //遍历所有的修复的dex
            File fileDir = context.getDir(DEX_DIR, Context.MODE_PRIVATE);
            File[] listFiles = fileDir.listFiles();
            for (File file : listFiles) {
                if (file.getName().startsWith("classes") && file.getName().endsWith(".dex")) {
                    loadedDex.add(file);
                }
            }
            //合并之前的dex
            doDexInject(context, fileDir, loadedDex);
        }
    
        private static void doDexInject(final Context appContext, File filesDir, HashSet<File> loadedDex) {
            String optimizeDir = filesDir.getAbsolutePath() + File.separator + "opt_dex";
            File fopt = new File(optimizeDir);
            if (!fopt.exists()) {
                fopt.mkdirs();
            }
            //1.加载应用程序的dex
            //2.加载指定的修复的dex文件。
            //3.合并
            try {
                PathClassLoader pathLoader = (PathClassLoader) appContext.getClassLoader();
                for (File dex : loadedDex) {
                    //2.加载指定的修复的dex文件。
                    DexClassLoader classLoader = new DexClassLoader(
                            dex.getAbsolutePath(),
                            fopt.getAbsolutePath(),
                            null,
                            pathLoader
                    );
                    ///通过反射获得classLoader、pathLoader的pathList
                    Object dexObj = getPathList(classLoader);
                    Object pathObj = getPathList(pathLoader);
                    //通过反射获得classLoader、pathLoader的DexElements
                    Object mDexElementsList = getDexElements(dexObj);
                    Object pathDexElementsList = getDexElements(pathObj);
                    //将classLoader、pathLoader的DexElements合并
                    Object dexElements = combineArray(mDexElementsList, pathDexElementsList);
                    //重新给pathLoader的PathList里面的dexElements赋值
                    setField(pathObj, pathObj.getClass(), "dexElements", dexElements);
                }
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    
        private static void setField(Object obj, Class<?> cl, String field, Object value) throws Exception {
            Field localField = cl.getDeclaredField(field);
            localField.setAccessible(true);
            localField.set(obj, value);
        }
    
        private static Object getField(Object obj, Class<?> cl, String field)
                throws Exception {
            Field localField = cl.getDeclaredField(field);
            localField.setAccessible(true);
            return localField.get(obj);
        }
    
        //反射获得BaseDexClassLoader的pathList
        private static Object getPathList(Object baseDexClassLoader) throws Exception {
            return getField(baseDexClassLoader, Class.forName("dalvik.system.BaseDexClassLoader"), "pathList");
        }
    
        //反射DexPathList的dexElements
        private static Object getDexElements(Object obj) throws Exception {
            return getField(obj, obj.getClass(), "dexElements");
        }
    
        /**
         * 两个数组合并
         *
         * @param arrayLhs
         * @param arrayRhs
         * @return
         */
        private static Object combineArray(Object arrayLhs, Object arrayRhs) {
            Class<?> localClass = arrayLhs.getClass().getComponentType();
            int i = Array.getLength(arrayLhs);
            int j = i + Array.getLength(arrayRhs);
            Object result = Array.newInstance(localClass, j);
            for (int k = 0; k < j; ++k) {
                if (k < i) {
                    Array.set(result, k, Array.get(arrayLhs, k));
                } else {
                    Array.set(result, k, Array.get(arrayRhs, k - i));
                }
            }
            return result;
        }
    }



    参考

    Android dex分包方案
    安卓App热补丁动态修复技术介绍

    微信Android热补丁实践演进之路

    Alibaba-AndFix Bug热修复框架原理及源码解析

    Android热补丁之AndFix原理解析

    微信Tinker的一切都在这里,包括源码(一)

    Android 热修复Nuwa的原理及Gradle插件源码解析

    Android中热修复框架Robust原理解析+并将框架代码从"闭源"变成"开源"(下篇)


    展开全文
  • Android:这是一份全面&详细的 热修复 学习指南

    千次阅读 多人点赞 2019-07-02 14:26:28
    补丁修复技术在Android 圈非常火,大量的补丁方案开始大量涌现 本文将为你全面介绍补丁的相关知识(原理、主流库使用),希望您会喜欢 目录 1. 简介 2. 储备知识 补丁的原理主要基于: Android Dex...

    前言

    • 热补丁修复技术在Android 圈非常火,大量的热补丁方案开始大量涌现
    • 本文将为你全面介绍热补丁的相关知识(原理、主流库使用),希望您会喜欢

    目录

    示意图


    1. 简介

    示意图


    2. 储备知识

    • 热补丁的原理主要基于: Android Dex分包方案 & Android的类加载机制(ClassLoader)
    • 所以,在讲热补丁的原理前,先了解上述2个储备知识

    2.1 Android Dex 分包方案

    • 简介

    示意图

    • 示意图

    示意图

    2.2 Android 类加载机制(ClassLoader)

    • 简介
      示意图

    • 加载流程说明
      示意图

    • 示意图

    示意图

    注:若2个Dex文件中有重复的类,当加载时,则优先加载排序较前的Dex文件的类

    若所需加载类 = class3,则最终加载的是排序较前的Dex1文件中的class3

    示意图

    • 源码分析
      由于 具体实现类 PathClassLoaderDexClassLoader都继承自BaseDexClassLoader类,所以此处主要讲解BaseDexClassLoader类中与类加载的相关方法findClass()
     /**
        * 加载流程说明
        **/
    	// 1. 传入需加载类的名字(classname)
    	// 2. 通过Dex文件,寻找到所需类(findClass) 
    		// a. 按顺序遍历ClassLoader的所有Dex文件,即 集合dexElements
    		// b. 每遍历到1个Dex文件,则在该Dex文件中寻找所需加载的类
    		// c. 若在该Dex文件找到该类,则返回;若找不到,则继续遍历下1个Dex文件
    	// 3. 加载所需类
    
      /**
        * BaseDexClassLoader的findClass()源码分析
        **/
        @Override
        protected Class<?> findClass(String name) throws ClassNotFoundException {
    
            // 从pathList对象对象中寻找->>分析1
            Class clazz = pathList.findClass(name);
    
            if (clazz == null) {
                throw new ClassNotFoundException(name);
            }
    
            return clazz;
        }
    
      /**
        * 分析1:DexPathList的findClass()源码分析
        **/
        public Class findClass(String name) {
            // 1. 按顺序遍历ClassLoader的所有Dex文件,即 集合dexElements
            for (Element element : dexElements) {
                DexFile dex = element.dexFile;
                
                // 2. 每遍历到1个Dex文件,则在该Dex文件中寻找所需加载的类 ->>分析2
                if (dex != null) {
                    Class clazz = dex.loadClassBinaryName(name, definingContext);
                    // 3. 若在该Dex文件找到该类,则返回;若找不到,则继续遍历下1个Dex文件
                    if (clazz != null) {
                        return clazz;
                    }
                }
            }
    
            return null;
        }
    
      /**
        * 分析2:DexFile的loadClassBinaryName()源码分析
        **/
        public Class loadClassBinaryName(String name, ClassLoader loader) {
            return defineClass(name, loader, mCookie);
        }
    
      /**
        * 分析3:DexFile的defineClass()源码分析
        **/
        private native static Class defineClass(String name, ClassLoader loader, int cookie);
    
    

    3. 热修复 原理

    3.1 具体描述

    1. 把需修复、含Bug的类 独立打包到1个Dex文件中(记为:patch.dex
    2. 将该 Dex文件 插入到ClassLoader中集合 dexElements的最前面

    3.2 示意图

    示意图

    3.3 特别注意:CLASS_ISPREVERIFIED 标记

    • 具体描述

    示意图

    • 解决方案具体描述
      示意图

    • 示意图

    示意图

    注:需完成上述步骤(防止类被打上 CLASS_ISPREVERIFIED 标记),再实现补丁


    4. 热修复 开源库介绍

    • 约在15年下半年开始,热补丁修复技术在 Android 圈非常火爆,热补丁方案开始大量涌现
    • 下面,我将主要介绍当前主流的热修复开源库

    4.1 主流的热修复 开源库

    库名 作者 Github地址
    Tinker 腾讯 微信团队 https://github.com/Tencent/tinker
    Nuwa 腾讯 QQ空间团队 https://github.com/Tencent/tinker
    Dexposed 阿里 手机淘宝团队 https://github.com/alibaba/dexposed
    AndFix 阿里 支付宝团队 https://github.com/alibaba/AndFix

    4.2 对比

    示意图


    5. 总结

    • 本文主要讲解 Android中的热补丁相关知识

    • 下面我将继续对 Android中的热补丁的主流框架进行 源码分析,感兴趣的同学可以继续关注carson_ho的微信公众号
      示意图
      示意图


    请帮顶 / 评论点赞!因为你的鼓励是我写作的最大动力!

    展开全文
  • 现在说到热修复已经不是一个很火的标题啦,通过查阅资料,各种热修复的框架层出不穷。阿里,微信,QQ,美团,饿了么 都有自己的一套热修复框架,有开源的,有收费的。这篇文章总结的很全面 Android热修复技术原理...
  • 热修复

    2020-03-04 13:13:18
    文章目录一、热更新的流程二、主流热更新框架介绍1、Dexposed2、AndFix3、Nuwa三、热更新原理1、Android类加载机制2、热修复机制 一、热更新的流程 二、主流热更新框架介绍 1、Dexposed 2、AndFix 3、Nuwa 三、热...
  • 手动实现最简单的Android热修复 前言 最近了解到了热修复相关的东西,于是很好奇原理,便一番搜索资料,同时为了加深对热修复的理解,便自己照着网上的例子去实现一个热修复,因为基础相对比较差,而且网上很多...
  • 热修复,热更新

    2020-01-13 18:30:25
    如果碰到某些节日活动,需要更改小功能,并且要短时间内完成版本... 这样就用到了热修复热更新,热修复不需要重新发布版本,用户也不需要下载最新的版本,而且修复的成功率也高,他会偷偷的修改bug并且更新版本。 ...
  • 浅谈Android热修复

    万次阅读 2016-07-28 10:22:05
    于是就有了热修复这个概念的产生!它可以在不发布版本的情况下修复出bug的代码。我们来一探究竟。 目前可能用的相对广泛的热修复框架有如下几个: https://github.com/dodola/HotFix https://github.com/jasonro
  • 在Android应用开发中,热修复技术被越来越多的开发者所使用,也出现了很多热修复框架,比如:AndFix、Tinker、Dexposed和Nuwa等等。如果只是会这些热修复框架的使用那意义并不大,我们还需要了解它们的原理,这样...
  • 热修复——深入浅出原理与实现

    万次阅读 多人点赞 2020-02-21 17:28:11
    一、简述热修复无疑是这2年较火的新技术,是作为安卓工程师必学的技能之一。在热修复出现之前,一个已经上线的app中如果出现了bug,即使是一个非常小的bug,不及时更新的话有可能存在风险,若要及时更新就得将app...
  • Android学习——手把手教你实现Android热修复

    万次阅读 热门讨论 2020-01-03 10:12:21
    最近一段时间看了一些关于Android热修复的知识,比如Andfix,Tinker,Sophix等,看了这些框架的原理,就想着自己能不能手撸一个简单的demo。下面我们就来自己动手实现Android热修复吧。 热修复实现原理 所谓热修复...
  • Android热修复一:热修复的流程 下一篇:Android热修复二(手写热修复代码) 在听了lance老师的热修复理论之后,决定写一篇文章,把我理解的全部记下来 之前也多少了解过热修复,当下的热修复方案应该按技术分为...
  • App想要实现热修复功能 问题: 1,Android管控越来越严格,App有没有必要接入热修复? 2,Android热修复方案那个比较好? 解决方法: 1,App接入热修复,修复一些bug是很有必要的。 2,Android热修复方案建议接入...
  • Android热修复-Robust

    2019-11-01 13:45:30
    什么是热修复 热修复(也称热补丁、热修复补丁,英语:hotfix)是一种包含信息的独立的累积更新包,通常表现为一个或多个文件。这被用来解决软件产品的问题(例如一个程序错误)。通常情况下,热修复是为解决特定...
  • 前言在Android应用开发中,热修复技术被越来越多的开发者所使用,也出现了很多热修复框架,比如:AndFix、Tinker、Dexposed和Nuwa等等。如果只是会这些热修复框架的使用那意义并不大,我们还需要了解它们的原理,...
  • 热修复原理  最近一段时间因为需求变化较大,觉得发版比较麻烦,就了解了一下热修复技术。它更多适用于刚发出去的包有Bug需要紧急修复的时候会用到。即以修复Bug的角度出发,在不需要二次安装下修复已知的Bug。 ...
  • 文章目录1 热修复技术出现的背景2 热修复技术简介3 热修复技术需要掌握的基本知识4 插件化和热修复的区别5 插件化5.1 什么是插件化5.2 插件化例子5.3 新增界面、资源的插件6 热修复技术 1 热修复技术出现的背景 要说...
  • Android 热补丁技术——资源的热修复

    万次阅读 2016-09-15 08:55:25
    今年真是热补丁框架的洪荒之力爆发的一年,短短时间内,已经出现了好几个热修复的框架了,基本上都是大同小异,这里我就不过多的去评论这些框架。只有自己真正的去经历过,你才会发现其中的坑。事实上,现在出现的...
  • Android热修复框架学习及应用

    千次阅读 2018-02-03 16:40:56
    从15年开始各技术大佬们开始研究热修复技术,并陆续开源了许多的热修复框架。如Jasonross 的Nuwa,美团的Robust,阿里的Andfix,腾讯的Tinker 等等…均是Android 前辈们夜以继日的成果。而现在热修复被广泛地应用于...
1 2 3 4 5 ... 20
收藏数 35,390
精华内容 14,156
关键字:

热修复