阿里资深工程师分享支付宝热补丁技术—— AndFix原理

  本文由嵌入式企鹅圈原创团队成员、阿里资深工程师Hao分享。

  上次我们介绍了用dexposed方案实施热补丁的原理,它本质上就是hook要修改的函数,这样一来在正式版本发布时就不能直接拿热补丁的代码集成进去了,因为热补丁是按hook的思路,并且按照实现XC_MethodReplacement类的方式写的,正式的补丁还需要重新包装一边。更重要的是dexposed对art的支持并不好,大大限制了它的使用范围。

  今天我们介绍的是AndFix方案:https://github.com/alibaba/AndFix。它按照正常修bug的思路写补丁代码,正式发布时直接集成补丁代码即可,适用范围广,在dalvik和Art上都可以使用。它分为两部分,一是生成补丁的工具,二是客户端加载补丁的SDK。支付宝钱包使用的就是这个方案。

  我们基于线上的最新版本修完bug后,会构建出一个apk,用AndFix提供的diff工具,找出已发布的线上的apk和修复后的apk中classes.dex之间的“差异”,也就是修复bug后发生变化的方法,再用工具生成一个apatch文件,跟apk一样,它也是个压缩包,里面包含CERT.RSA、CERT.SF、MANIFEST.MF、diff.dex和PATCH.MF这几个文件。客户端从服务端拉取该apatch文件后,解析diff.dex,找到要加载的类和要替换的方法methodReplaced,最后用hook的方式替换掉,这样就完成了在线修复的工作。本篇我们只介绍客户端加载补丁的SDK的主要原理,不介绍生成补丁的工具,照例还是先不管ART,只介绍dalvik下是怎样运行的。

一、解析补丁的配置文件PATCH.MF

1.首先PatchManager的addPatch方法可以用来添加一个补丁,并执行替换操作。

  可见,用生成的补丁文件File来构造一个Patch类,然后再执行loadPatch来加载补丁。

  因为补丁文件apatch是一个jar包,所以用JarFile、Manifest等类来解析META-INF/PATCH.MF配置文件,找到要替换的类名,接下来loadPatch调用AndFixManager的fix方法,传入补丁的File对象、当前Context的classLoader和从PATCH.MF解析出的要替换的补丁类名。

  fix方法中用传入的classLoader构造一个自定义的pathClassLoader,它的findClass方法用来找到要替换的类的Class对象。


  这里的dexFile直接由loadDex得到,这样补丁文件中的dex文件就已经加载到应用中了。


2. 接下来依次把要修复的类加载进来,并调用fixClass方法开始替换工作。

二、找到要替换的类的方法,并把类成员的属性改为public

  这里巧用了java的Annotation原理帮助我们在apk中找到要修复的方法。在apatch中补丁方法写了注释annotation,clazz和method表示要修复的类和方法。在AndFixManager的fixClass中会根据这个Annotation找出要修复的Method对象。遍历类的全部Method,如果发现有MethodReplace的注释就开始准备替换工作。method是原apk(有bug)的方法,meth是新修复的方法,接着调用replaceMethod。

replaceMethod里先后调用了initTargetClass和addReplaceMethod,注意这里的classLoader不是上面提到的pathClassLoader而是原apk中要修复的类的classLoader。这样原来有bug的class和补丁中的class都已经被加载进来了。

  initTargetClass中主要调用native的方法setFieldFlag把class中的所有成员都设为public,

  addReplaceMethod同样也是调用native的方法replaceMethod。

三、替换原来的Method

  替换原来方法的处理方式我们看起来会有点熟悉,一般的java hook差不多都是这样的套路,在jni中找到要替换方法的Method对象,修改它的一些属性,让它指向新方法的Method对象。

  这里dvmDecodeIndirectRef_fnPtr和dvmThreadSelf_fnPtr都是在AndFix初始化时赋好值的函数指针,用来调dvm的dvmDecodeIndirectRef和dvmThreadSelf函数。

  这里apilevel > 10的意思是,在apilevel 10以前dvm是用c语言实现的,以后是用C++实现的。

以上所有的过程是在应用MainApplication的onCreate中被调用,所以当应用重启后,原方法和补丁方法都被加载到内存中,并完成了替换,在后面的运行中就会执行补丁中的方法了。

  AndFix的优点是像正常修复bug那样来生成补丁包,但可以看出无论是dexposed还是AndFix,都利用了java hook的技术来替换要修复的方法,这就需要我们理解dalvik虚拟机加载、运行java方法的机制,并要掌握libdvm中一些关键的数据结构和函数的使用。

  百分百原创,每周两篇,阿里、魅族、nvidia、龙芯、炬力、拓尔思等顶级企业资深工程师分享----嵌入式、Linux、物联网、GPU、Android、自动驾驶等技术,欢迎扫码关注微信公众号:嵌入式企鹅圈,实时推送原创文章!

时间: 04-05

阿里资深工程师分享支付宝热补丁技术—— AndFix原理的相关文章

Android热补丁技术—dexposed原理简析(手机淘宝采用方案)

本文由嵌入式企鹅圈原创团队成员.阿里资深工程师Hao分享. 上篇文章<Android无线开发的几种常用技术>我们介绍了几种android移动应用开发中的常用技术,其中的热补丁正在被越来越多的开发团队所使用,它涉及到dalvik虚拟机和android的一些核心技术,现在就来介绍下它的一些原理. 本篇先介绍dexposed方案:https://github.com/alibaba/dexposed,它是手机淘宝团队使用的热补丁方案,后来开源到github上,取的名字dexposed表明了自己是基于

零代价修复海量服务器的内核缺陷——UCloud内核热补丁技术揭秘

下述为UCloud资深工程师邱模炯在InfoQ架构师峰会上的演讲——<UCloud云平台的内核实践>中非常受关注的内核热补丁技术的一部分.给大家揭开了UCloud云平台内核技术的神秘面纱. 如何零代价修复海量服务器的Linux内核缺陷? 对于一个拥有成千上万台服务器的公司,Linux内核缺陷导致的死机屡见不鲜.让工程师们纠结的是,到底要不要通过给服务器升级内核来修复缺陷?升级意味者服务器重启.业务中断以及繁重的准备工作:不升级则担心服务器死机,同样造成业务中断和繁重的善后工作. 而在今天的云计

会展工程师分享展示设计灯光效果技术

展示设计中可谓是最重要的环节,展示设计如果缺少了灯光效果,那就相当于一个人丢失了灵魂,所以,展示设计中最不可少的就是灯光效果.人的眼球,对光有很强敏感度,灯光可以引起消费者对整个展示设计的共鸣,提高人气.当然,灯光效果有利肯定有弊,如果利用的不好可能会引起消费者眼球的不适,造成展台无人光顾.通常灯光照明的方式有:点式照明.线式照明和面式照明三种方式.点式照明具有特殊的格调,气氛较宁静而不喧闹:线式照明擅长表现照明空间中的运动感,给人轻松.柔和的感觉,是视觉的引导者:面式照明的特点既宽容,为何又充

移动智能设备功耗优化系列--前言(NVIDIA资深工程师分享)

本文是嵌入式企鹅圈原创团队成员.NVIDIA资深开发工程师Terry发表的第一篇文章,其将对"移动智能设备功耗优化"这个专题展开一个系列的总结分享.Terry毫无保留地总结分享其在主导NVIDIA多个项目开发中的移动设备功耗优化经验,极具价值! 随着智能移动设备的功能越来越多,CPU/Memory频率也越来越高,随之带来的功耗问题也越来越严重,如何延长手机的待机以及使用时间一直以来都是各个手机厂商不得不面对的问题.本专题将逐一为各位读者讲解一下当前主流的功耗优化策略以及一些实用的优化调

Android 热补丁技术——资源的热修复

前言 今年真是热补丁框架的洪荒之力爆发的一年,短短几个月内,已经出现了好几个热修复的框架了,基本上都是大同小异,这里我就不过多的去评论这些框架.只有自己真正的去经历过,你才会发现其中的 大写的坑 事实上,现在出现的大多数热修复的框架,稳定性和兼容性都还达不到要求,包括阿里的Andfix,据同事说,我们自己的app原本没有多少crash,接入了andfix倒引起了一部分的crash,这不是一个热修复框架所应该具有的"变态功能".虽然阿里百川现在在大力推广这套框架,我依旧不看好,只是其思路

Android热修复框架AndFix原理解析及使用

一.前言 最近腾讯弄出一个Tinker热修复框架,那么本文先不介绍这个框架,先来介绍一下阿里的一个热修复框架AndFix,这个框架出来已经很长时间了,但是看网上没有太多非常详细的讲解,这里就来做一次分析.正好项目中要使用到.首先这个框架是开源的:https://github.com/alibaba/AndFix 其实在最早的时候我已经分析了阿里的另外一个热修复框架:Dexposed框架,还不了解的同学可以点击这里查看:Dexposed框架原理解析以及使用 当时介绍这个框架的时候发现他的实现原理很

Android 热补丁实践之路

大约在15年下半年开始,热补丁方案开始大量涌现,一时间热补丁修复技术在 Android 圈非常火爆,比较有代表性的开源实现有 Dexposed.AndFix.Nuwa 以及前段时间微信开源的 Tinker,至于他们的原理以及优缺点比较并不是本文要讲的,网上已经有一大堆资料进行介绍了,感兴趣的可以看下这几篇文章: 安卓App热补丁动态修复技术介绍 Android热补丁之AndFix原理解析 Instant Run工作原理及用法中文翻译稿 从Instant run谈Android替换Applicat

【腾讯bugly干货分享】微信Android热补丁实践演进之路

本文来自于腾讯bugly开发者社区,非经作者同意,请勿转载,原文地址:http://bugly.qq.com/bbs/forum.php?mod=viewthread&tid=1264&extra=page%3D1 继插件化后,热补丁技术在2015年开始爆发,目前已经是非常热门的Android开发技术.其中比较著名的有淘宝的Dexposed.支付宝的AndFix以及QZone的超级热补丁方案.微信对热补丁技术的研究并不算早,大约开始于2015年6月.经过研究与尝试现有的各个方案,我们发现它

Android热修复技术专题:来自微信、淘宝、支付宝、QQ空间的热修复方案

最近好多人都讨论关于热更新的话题,所以查询了一些资料看看 当一个App发布之后,突然发现了一个严重bug需要进行紧急修复,这时候公司各方就会忙得焦头烂额:重新打包App.测试.向各个应用市场和渠道换包.提示用户升级.用户下载.覆盖安装.有时候仅仅是为了修改了一行代码,也要付出巨大的成本进行换包和重新发布. 这时候就提出一个问题:有没有办法以补丁的方式动态修复紧急Bug,不再需要重新发布App,不再需要用户重新下载,覆盖安装?答案当然是有的,那就是最近涌现出来得热补丁方案,主要包括淘宝的Dexpo