android热修复

移动端APP热更新方案(iOS+Android)

我与影子孤独终老i 提交于 2020-03-30 07:17:53
出自:http://www.cnblogs.com/Creator/p/7007694.html 为什么要做热更新 当一个App发布之后,突然发现了一个严重bug需要进行紧急修复,这时候公司各方就会忙得焦头烂额:重新打包App、测试、向各个应用市场和渠道换包、提示用户升级、用户下载、覆盖安装。 重点是还会有原来的版本遗留,无论你怎么提示都有人放弃治疗,不愿意升级,强制不能使用体验又足够糟糕到让人不能启齿。 如果这是一个影响公司收入或者体验影响极其不好的Bug,那完蛋了,可能公司老板会对整个技术团队的技术能力丧失信心,其对技术人员的伤害是致命的。 最后最致命的是: 有时候仅仅是因为不小心写错了一行代码,就让所有的加班都付之东流,苦不苦,冤不冤,想想都苦。 还有一种剧情是研发总监把锅甩给测试团队,测试不过关,测试摊摊手说我也不是神啊,总会有漏网之鱼. 那能不能神不知鬼不觉再没有产生较大影响前把bug快速修复了呢? 热更新的行业情况 先来说说Android 并不是因为Android更有料就先说他,而是它的用户量级比Iphone大,我们写文章也是讲究大数据分析的不是.. Andoid端在15年热补丁就比较火,先后出现了Dexposed、AndFix,Qzone超级补丁的类Nuwa方式,微信的Tinker, 大众点评的nuwa、百度金融的rocooFix,

Android热修复方案比较

我与影子孤独终老i 提交于 2020-03-30 07:17:38
热修复的特点:无需重新发版,实时高效热修复;用户无感知修复,无需下载新的应用,代价小; 修复成功率高,把损失降到最低。 一、热修复开源方案和使用情况 方案名称 方案开发公司 开发时间 Github星评 Robust 美团 2016年 54 Andfix 阿里 2015年 4994 Nuwa 个人开发者(dex文件补丁) 2015年 2588 Dexposed 不考虑,需要root权限 Amigo 饿了么(apk补丁) 2016年 1031 Tinker 微信(apk补丁) 2016年 7891 RocooFix Nuwa改进版 2016年 1299 Robust方案 1.原理:Robust插件对每个产品代码的每个函数都在编译打包阶段自动的插入了一段代码,插入过程对业务开发是完全透明。 运行过程 在Application中通过DexClassLoader,将补丁class文件事先加载,然后之后会调用新的额 class以替换旧apk中的bug class文件,通过反射进行新代码的调用,以达到热修复目的。 具体过程请参考 Android热更新方案Robust 2.补丁制作 Robust的补丁制作,除了打包dex文件,更需要使用美团的插件将每个class文件插入代码,在编译阶段侵入代码 对运行效率等方面都有影响 优点 1.高兼容和适配性,由于是java代码层面的替换调用,基本不涉及各个版本

Android热修复实践应用--AndFix

社会主义新天地 提交于 2020-02-29 08:50:43
一直关注App的热修复的技术发展,之前做的应用也没用使用到什么热修复开源框架。在App的热修复框架没有流行之前,做的应用上线后发现一个小小的Bug,就要马上发一个新的版本。我亲身经历过一周发两个版本,真的折腾用户的节奏~~所以,要开始考虑引入热修复。下面记录使用开源框架阿里巴巴的AndFix过程。 实现的原理 这里说的不是热修复怎么实现修bug的原理,这里说的是怎么使用AndFix。如果你想了解更多的andFix实现原理,你可以参考下面的文章: https://github.com/alibaba/AndFix (AndFix的官网) http://blog.csdn.net/lmj623565791/article/details/49883661 (Android大神鸿洋的Bolg文章) 应用启动的时候,在 onCreate() 方法中获取友盟的在线参数来判断当前的应用版本是否有补丁需要下载,有则通过ThinDonloadManager来下载到SD下并且通过使用AndFix来加载到应用中。 使用极光推送消息到该应用的版本需要下载补丁,如果应用收到了消息后,应用判断当前的版本是否需要下载补丁。如果应用没有收到消息的通知,则下次启动App的时候,获取友盟在线参数来判断是否需要下载补丁。 步骤 在gradle文件中增加相应的依赖

Android之移动热修复

泪湿孤枕 提交于 2019-12-19 00:35:25
阿里云最近推出了移动热修复服务,听说这个服务傻瓜式接入,性能相对较好,对新技术比较好奇的我决定尝试一下。 移动热修复.png 首先,需要开通这个服务,创建应用 创建应用.png 然后,在项目中接入服务。按照文档所述, 第一步:gradle远程仓库依赖, 打开项目找到app的build.gradle文件,添加如下配置: 添加maven仓库地址: repositories { maven { url "http://maven.aliyun.com/nexus/content/repositories/releases" } } 第二步:添加gradle坐标版本依赖: compile 'com.aliyun.ams:alicloud-android-hotfix:3.0.6' 第三步:在AndroidManifest.xml中添加权限: <!-- 网络权限 --> <uses-permission android:name="android.permission.INTERNET" /> <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" /> <uses-permission android:name="android.permission.ACCESS_WIFI_STATE" /> <!--

ASM字节码插桩:QQ空间的热修复解决方案核心技术,安卓程序员的硬通货

[亡魂溺海] 提交于 2019-12-17 11:14:27
一、什么是插桩 QQ空间曾经发布的《热修复解决方案》中利用 Javaassist库实现向类的构造函数中插入一段代码解决 CLASS_ISPREVERIFIED 问题。包括了 Instant Run 的实现以及参照 Instant Run 实现的热修复美团Robus等都利用到了插桩技术。 插桩就是将一段代码插入或者替换原本的代码。字节码插桩顾名思义就是在我们编写的源码编译成字节码(Class)后,在Android下生成dex之前修改Class文件,修改或者增强原有代码逻辑的操作。 我们需要查看方法执行耗时,如果每一个方法都需要自己手动去加入这些内容,当不需要时也需要一个个删去相应的代码。 一个、两个方法还好,如果有10个、20个得多麻烦!所以可以利用注解来标记需要插桩的方法,结合编译后操作字节码来帮助我们自动插入,当不需要时关掉插桩即可。 这种AOP思想让我们只需要关注插桩代码本身。 二、字节码操作框架 上面我们提到QQ空间使用了 Javaassist来进行字节码插桩,除了 Javaassist之外还有一个应用更为广泛的 ASM框架同样也是字节码操作框架,Instant Run包括 AspectJ就是借助 ASM来实现各自的功能。 我们非常熟悉的JSON格式数据是基于文本的,我们只需要知道它的规则就能够轻松的生成、修改JSON数据。 同样的Class字节码也有其自己的规则(格式)。

Android热更新

爷,独闯天下 提交于 2019-12-09 11:29:33
Android热更新 一.什么是热更新 二.工作原理 1.Android中如何动态修复bug 2.Android中的类加载器 3.热修复的实现原理 三.热更新优点 为什么要做热更新 四.热更新使用 1.添加插件依赖 2.集成SDK 3.初始化SDK 4.Androidmanifest.xml配置 5.混淆配置 6.常见错误 一.什么是热更新 热更新是一种各大手游等众多App常用的更新方式。简单来说,就是在用户通下载安装APP之后,打开App时遇到的即时更新。 二.工作原理 热更新就是动态下发代码,它可以使开发者在不发布新版本的情况下,修复 BUG 和发布功能,让开发者得以绕开苹果的审核机制,避免长时间的审核等待以及多次被拒造成的成本。 1.Android中如何动态修复bug bug一般是一个或多个class出现了问题,在一个理想的状态下,我们只需将修复好的这些个class更新到用户手机上的app中就可以修复这些bug了。但说着简单,要怎么才能动态更新这些class呢?其实,不管是哪种热修复方案,肯定是如下几个步骤: 下发补丁(内含修复好的class)到用户手机,即让app从服务器上下载(网络传输) app通过"某种方式",使补丁中的class被app调用(本地更新) 这里的"某种方式",对本篇而言,就是使用Android的类加载器,通过类加载器加载这些修复好的class

Android热修复原理

女生的网名这么多〃 提交于 2019-12-06 18:37:15
一. AndFix AndFix的原理就是方法的替换,把有bug的方法替换成补丁文件中的方法。 注:在Native层使用指针替换的方式替换bug方法,已达到修复bug的目的。 AndFix采用native hook的方式,这套方案直接使用dalvik_replaceMethod替换class中方法的实现。由于它并没有整体替换class, 而field在class中的相对地址在class加载时已确定,所以AndFix无法支持新增或者删除filed的情况(通过替换init与clinit只可以修改field的数值)。Andfix可以支持的补丁场景相对有限,仅仅可以使用它来修复特定问题。 二. QZone(插桩方式) 该方案基于的是android dex分包方案的, 简单的概括一下,就是把多个dex文件塞入到app的classloader之中,但是android dex拆包方案中的类是没有重复的,如果classes.dex和classes1.dex中有重复的类,当用到这个重复的类的时候,系统会选择哪个类进行加载呢? 让我们来看看类加载的代码: 一个ClassLoader可以包含多个dex文件,每个dex文件是一个Element,多个dex文件排列成一个有序的数组dexElements,当找类的时候,会按顺序遍历dex文件,然后从当前遍历的dex文件中找类,如果找类则返回

热修复设计之热修复原理(三)

你。 提交于 2019-12-06 04:59:11
阿里P7移动互联网架构师进阶视频(每日更新中)免费学习请点击: https://space.bilibili.com/474380680 本篇文章将先从热修复原理来介绍热修复设计: Android 热修复 在Android的热修复中主要用来替换类,资源,so的过程; Java 虚拟机 栈架构指令集的主要缺点是执行速度相对来说稍微慢一些;基于堆栈的机器需要更多指令,(内存) Android 虚拟机 而基于寄存器(硬件在CPU内部)的机器指令更长 速度: CPU - > 寄存器 -> 内存 -> 外存 http://blog.csdn.net/ljtyzhr/article/details/39859659 Android 目前有2中虚拟机, Dalvik 和 ART 虚拟机; Android 虚拟机和编译加载顺序 Android 热修复其实主要是针对 Android 虚拟机加载类的一个过程,所以首先先我们应该知道 Android 常用的虚拟机是 Dalvik 虚拟和 ART 虚拟机; Android 4.0 之前是主要是的 Dalvik 虚拟机。 Android 4.4 之后开始支持 ART 虚拟机(可选), Android 5.0 之后就是 ART 虚拟机; Android 4.0 --> Android 4.4 --> Android 5.0 ---> Android 7.0

Android为TV端助力之热修复原理

我们两清 提交于 2019-12-06 02:27:57
通过源码我们知道Android加载类是通过ClassLoad类里面的findClass先去查找的,如下图所示 通过看源码我们知道,ClassLoad是一个抽象类,它本身并没有实现findclass()方法,而是通过Android双亲委托机制交给它的子类去实现的,如果子类没有找到,那最终就会调用自己的findclass方法 抛出ClassNotFoundException异常,接下来我们去看它的子类是如何实现findclass方法的,通过源码我们知道ClassLoad有两个子类SecureClassLoader跟BaseDexClassLoader, 我们在BaseDexClassLoader里面找到的findclass类的实现方法 通过此方法我们看到它是调用了pathList.findClass方法去查找类,而pathList是属于DexPathList的对象,那么我们点进去看看此方法是如何查找的 我们看到它首先遍历的一个叫dexElements的数组,得到一个DexFile对象,接着往下看,它接着又调用的dex.loadClassBinaryName方法的,我们在点进去看看 发现它最终走到的native方法里面了,那么我们就不深究的,回来上一步来看看 dexElements 是个什么东西??? dexFile是什么东西? 为什么要遍历它??? 通过DexPahtList的构造方法

Android热修复——深入剖析AndFix热修复及自己动手实现

蓝咒 提交于 2019-12-03 11:29:35
前言 去年写过一篇热修复的文章,那时候刚开始接触,照猫画虎画的还算比较成功。但是那种修复需要重新启动APP,也就是在JAVA层实现的热修复。我们知道目前Android主流的修复还有在Native层实现修复的,就是在Native层替换方法,不用重新启动APP。今天写了个Demo,下面主要分享一下它的主要原理。 1、热修复 目前,热修复的原理主要有两种技术,一是不需要启动APP就能实现修复,在Native层实现的。一种时需要启动APP,在JAVA层实现的。 Native层 :andfix sophix (即时修复 不重启APP) JAVA层 :Tinker robust等(需要启动APP) 出现异常的根源在于方法 我们的程序出现异常(BUG)的根源是什么?为什么会出现异常呢,要出现异常肯定是我们程序中的 某个方法 抛出了异常,所以异常的根源是 方法 。那么我们修复包的目的就是去替换异常的方法所在的包名类名下的方法。我们需要准确的找到这个方法,那么我们怎么去找这个方法呢? 如何替换已经运行的APK ? 是直接替换运行时的APK加载的有bug的类吗?显然不行,因为 Java的懒加载机制,在不启动APP时新类不能替换老的类 。class类只被ClassLoader加载一次,所以已经有bug的类,再不启动APP的情况下我们不能直接再虚拟机中替换。那我们要怎么去做呢