点滴积累

1.tinker的demo在什么位置：如图所示，clone下来之后把这个圈出来的工程拷贝出来，单独打开。 2.开始测试之前的准备工作：先推荐一些这个过程之中对我有帮助的资料，然后再总结下我学习所得： http://www.trojx.me/2016/09/28/tinker-sample-introduction/ http://www.jianshu.com/p/19906d3012e

前言上一篇玩了玩Tinker，测试了demo，这一片我们来看实战中的热更新是怎样的。热更新不仅仅是热更新： 如果我们仅仅是去单独的接入tinker，我们打出来的补丁该怎么下发呢？这牵涉到和一个后台的交互（基准包版本和补丁版本的映射，版本上报，下发等等一系列的问题），因此，bugly便应运而生了。它主要提供一套规范的补丁上报，下发流程（降低了我们热更新的工作成本，且同一个厂自研出品，流程更规范，降低

前言上一篇我们将sdk接入了进来，那么这一篇我们来模拟一次真实项目中使用热更新的场景，当然，是结合bugly来做。还记得我们上一篇开始说了准备一个自带bug的项目（目录2,3），这里再来回忆下：流程梳理 1.集成tinker sdk 2.打出基线版本，build内生成一个bakapk的目录 3.bug修复，java代码，so文件，资源文件。 4.修改tinker-support.gradle内的ba