Java 类源码文件编译成 class 字节码文件 , 然后转为 dex 文件 , 打包到 apk 中 , 然后在 Android 平台的 Dalvik虚拟机 或 Art 虚拟机中执行 ;
一般情况下 管理操作界面 和 后端服务器 是一个 Java / .NET / PHP 开发的 Web 应用 ;
Java 代码运行时 , 使用 ClassLoader 加载 Class 字节码文件 , Class 字节码文件 , Jar 文件 , Dex 文件 , 都必须加载到内存中 ;
随着公司的快速发展，需求的快速增加，App迭代也越来越频繁，如果移动应用出现问题，不仅仅影响用户体验，还会影响公司口碑，甚至可能造成资损。需要快速修复线上问题，对比常规的开发流程而言，热修复更加灵活方便，优势很多：
类加载方案需要重启App后让ClassLoader重新加载新的类，为什么需要重启，因为类是无法卸载的，要想重新加载类就需要重启App，因此采用类加载方案的热修复框架无法及时生效。
https://github.com/5A59/android-training/tree/master/common-tec/CommonTec
热修复技术在近年来飞速发展，尤其是在InstantRun方案推出之后，各种热修复技术竞相涌现。国内大部分成熟的主流APP都拥有自己的热修复技术，像手淘、支付宝、QQ、饿了么、美团等等。
参考 【Android 热修复】热修复原理 ( 热修复框架简介 | 将 Java 字节码文件打包到 Dex 文件 ) 二、 将 Java 字节码文件打包到 Dex 文件 章节流程 , 将更新后的 kim.hsl.hotfix.HotFixTest 类打包成 dex 文件 ;
本来想写资源的热修复的，虽然方案差不多已经完成了，但是考虑到一些敏感问题，资源修复就不写了。那就来写写so的热修复，其原理和class的修复是一样的，但是so的热修复的需求并不高，就当做学习吧。
Unity 下 Bug 修复神器 InjectFix 开源啦！ InjectFix 使用简单，小巧，合规且安全，经过多个项目应用反馈十分良好，即使你不打算用它来更新线上版本，只要你程序有原生部分，接入也能一定程度上提高开发效率。 InjectFix 亮点： 1. 直接在Unity工程上修改C#即可更新；老项目无需修改原有代码即可使用； 2. 更符合苹果热更新条款； 3. 每个游戏一份私有补丁格式，安全更有保障。 InjectFix的那些事儿 热更方案大乱斗 所有支持ios的热更方案都有个共同点：更新
说到这个就躲不过一个关键点 ClassLoader(类加载器) ,所以我们先从Java开始。
题外话 今天听到了著名物理学家史蒂夫霍金去世消息，潸然泪下。作为一个天文迷，感谢霍金带给我的那些天文知识。十分敬佩霍金的身残志坚，他在全身瘫痪无法言语情况下仍旧热爱生活，在现代物理界达到了无人企及的高度。时间旅行者霍金，愿你一路自由奔跑。 前言 在Android应用开发中，热修复技术被越来越多的开发者所使用，也出现了很多热修复框架，比如：AndFix、Tinker、Dexposed和Nuwa等等。如果只是会这些热修复框架的使用那意义并不大，我们还需要了解它们的原理，这样不管热修复框架如何变化，只要基本原理不
Android Studio2.0时，新增了一个 Instant Run的功能，而各大厂的热修复方案，在代码，资源等方面的实现都是很大程度上参考了Instant Run的代码。所以可以说 Instant Run 是推进Android 热修复的主因。
Android热修复技术无疑是Android领域近年来最火热的技术之一，同时也涌现了各种层出不穷的实现方案，如QQ空间补丁方案、阿里AndFix以及微信Tinker等等，从本篇博客开始，计划写一个系列博客专门介绍热修复的相关内容，本系列博客将一一介绍这些框架的原理和源码分析，作为本系列的开篇，本篇博客将对热修复技术进行一个概述，并对以上几种方案进行对比。
基本原理:加载类的时候是找element，每个element对于一个dex。我要把我修复的那个类单独放到dex插入dexlist前面，在你做类加载从前往后找优先从你的dex加载加载的就是你修复后的class.这就是
在Android早期的版本中，应用程序的运行环境是需要依赖Dalvik虚拟机的。不过，在后来的版本（大概是4.x版本），Android的运行环境却换到了 Android Runtime，其处理应用程序执行的方式完全不同于 Dalvik，Dalvik 是依靠一个 Just-In-Time (JIT) 编译器去解释字节码。
插件化和热修复技术是Android开发中比较高级的知识点，是中级开发人员通向高级开发中必须掌握的技能，插件化的知识可以查我我之前的介绍：Android插件化。本篇重点讲解热修复，并对当前流行的热修复技
周一发布了新版本，当天晚上用户就为app未测试到的bug发飙了，恩，很快就找到了问题所在，一个容易疏忽的空指针。虽然只是一个小小的bug但是不修复是很影响用户体验的啊，如果要重新修复上线，波及范围太广了，所有用户又要重新下载。 我们可以让这个bug“偷偷”的修复
ClassLoader 是抽象类 , 是所有 类加载器 ClassLoader 的父类 ;
之前写过一篇热修复的文章，那时候刚开始接触，照猫画虎画的还算比较成功。但是那种修复需要重新启动APP，也就是在JAVA层实现的热修复。我们知道目前Android主流的修复还有在Native层实现修复的，就是在Native层替换方法，不用重新启动APP。今天写了个Demo，下面主要分享一下它的主要原理。
两周前 HG 分享了 QQ 空间的热修复框架，今天我来简单讲一下微信开源的热修复框架，Tinker。
当公司的项目出现问题了，早期的老套路子是解决bug，重新发新版本apk，但是随着技术不断的更新，线上项目出现严重问题，可以通过进行热修复，在不需要发布新版本的情形下进行问题处理。常见的热修复：阿里家的andfix和sophix， 腾讯家的tinker和QQ空间补丁技术...等等。
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
注：需完成上述步骤（防止类被打上 CLASS_ISPREVERIFIED 标记），再实现补丁
【Android 插件化】插件化简介 ( 组件化与插件化 ) 【Android 插件化】插件化原理 ( JVM 内存数据 | 类加载流程 ) 【Android 插件化】插件化原理 ( 类加载器 ) 【Android 插件化】“ 插桩式 “ 插件化框架 ( 原理与实现思路 ) 【Android 插件化】“ 插桩式 “ 插件化框架 ( 类加载器创建 | 资源加载 ) 【Android 插件化】“ 插桩式 “ 插件化框架 ( 注入上下文的使用 ) 【Android 插件化】“ 插桩式 “ 插件化框架 ( 获取插件入口 Activity 组件 | 加载插件 Resources 资源 ) 【Android 插件化】“ 插桩式 “ 插件化框架 ( 运行应用 | 代码整理 )
2.2 热修复有效解决问题 传统的方案存在上述的问题通过热修复技术方案可以有效解决：
热补丁修复技术在Android 圈非常火，大量的热补丁方案开始大量涌现 本文将为你全面介绍热补丁的相关知识（原理、主流库使用），希望您会喜欢
在进行apk热修复、插件化、动态加载的时候，会经常多个jar/dex包含相同的class，如果class结构因为需要升级出现了变化，会隐藏一些很难解释的坑在里面，务必谨慎。
NotDoVerifyClasses和AntiLazyLoad在dex中居然找不到，这勾起我的兴趣。先来debug看看，到底是从哪里加载的这两个类：
市场上热修复有两种一种是基于multidex的更新修复（比如tinker），另外一种是native hook（比如dexposed），tinker这种是反射获取dexelements数组，修改dex加载顺序。今天我们主要介绍dex这种。 热修复包括两个部分
django-simpleui 是一个基于vue+element-ui开发的 django admin主题包，在使用上与原生admin无任何区别。不用修改任何代码，就可以直接使用该主题。本次更新带来了一个新功能，智能匹配菜单并分配一个图标。
要热更新flutter页面，我们首先要搞明白我们到底需要动态替换一些什么？因此这里需要对flutter构建的产物有一定的了解了，怕有些小伙伴不太明白，这里也简单的带一下；如上图所示，实际上，我们只需要copy一些aar文件，so文件到native工程lib目录，就可以已aar的方式来跑Flutter的页面了,这也是典型的已aar方式接入Flutter的模式。其中，libapp.so，注意在armeabi中没有，如果你的gralde配置这么写的，abiFilters "armeabi" 那么，copy armeabi-v7a下面的so到armeabi中，也是没有任何问题的，关于构建产物提取到原生工程就介绍到这里。
前言：这个是个人观点，技术要用在合适的业务场景中才能体现出它的优势，而不是盲目的去学，去看
团队协作是职业生涯中必须面对的问题，Git为我们代码的协作管理提供了强大的工具。熟悉Git操作，拥抱团队协作。
了解了 Dex 文件以后，对日常开发中遇到一些问题能有更深的理解。如：APK 的瘦身、热修复、插件化、应用加固、Android 逆向工程、64K 方法数限制。
最近发现热修复比较火，很多文章也做了介绍。所以自己也简单的学习下。因为自己在实际项目中并没有用到。所以为了防止忘记，写成博客做成笔记，同时也帮助一些没有接触过的小伙伴能快速使用与入门。废话少说。进入主题。
在运行时替换掉底层有Bug的方法的地址，将他们的指针指向修复之后的方法的内存地址，从而实现热修复的功能。
本文介绍了在美团客户端单周发版快速迭代的背景下，美团交通业务线多个仓库的多个发版分支的自动化管理方法。
目前，互联网产品呈现出高频优化迭代的趋势，需求方希望尽早地看到结果，并给予及时反馈，所以技术团队需要用“小步快跑”的姿势来做产品，尽早地交付新版本。基于以上背景，美团客户端研发平台适时地推行了单周发版的迭代策略。单周版本迭代的优点可以概括为三个方面：更快地验证产品创意是否符合预期，更灵活地上线节奏，更早地修复线上Bug。
想进大厂，就关注「 程序亦非猿 」 时不时 8:38 推送优质文章，觉得有用，置顶加星标
通过上面几个类的关系，和类的查找过程，我们可以发现最终是通过遍历 DexPathList的 dexElements数组进行类的查找加载，当找到类就返回；
2016年3月10日，Tinker项目正式启动，并在同年9月23日举行的MDCC会议上开源。一年过去了，两个人，50%的工作时间。总的来说，填了一些坑，获得少许成绩，也遭受不少批评。 究竟Tinker是否将已经很糟糕的Android的生态变得更差，会不会对用户的安全造成更大的挑战？ 回想Tinker的初心，我们希望开发者可以用很小代价进行快速升级，它是国内追求快速迭代诉求。立项至今，Tinker踩了很多坑也填了很多坑。今天，我希望跟大家分享这一年来我们遇到的一些问题，以及解决它们的思路与过程。 Tinke
大家都是开发，所以应该都知道有一个东西我们永远也避免不了。不错，Bug！我们在开发阶段碰到bug那还好，直接解决就是了，大不了让测试多测一轮。可是，如果我们发出去的版本出现线上Bug，那可怎么办？大多数小的公司可能会选择，重新发新的版本去覆盖安装。这种方式成本较高，而且用户一般都比较讨厌经常需要更新版本的APP。对于小公司来说，出现线上问题影响范围还是比较小的，毕竟用户量较少。可是对于一些巨头公司，有些问题不能及时修复那是致命的。所以呢，有这么一些技术储备和能力比较高的公司为我们开了先河。
theme: channing-cyan highlight: a11y-dark
最近关于热修复崩溃在Android P 版本的内容持续增高,也许这个commit可以帮到你.
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
即时通信 IM
实时音视频
