booster总体解析

1、简介

Booster 是一款专门为移动应用设计的易用、轻量级且可扩展的质量优化框架，其目标主要是为了解决APP复杂度的提高而带来的性能、稳定性、包体积等问题。Booster 主要由 Transformer 和 Task 组成，Transformer 主要用于对字节码进行扫描或修改（取决于 Transformer 的功能），Task 主要用于构建过程当中的资源处理，为了知足特异的优化需求，Booster 提供了 Transformer SPI and VariantProcessorSPI容许开发者进行定制，如下是 Booster 的总体框架：

开发中面临的问题

一、如何持续保证 APP 的质量？

二、当 APP 崩溃后，如何快速定位问题所属的业务线？

三、能不能在上线以前提早发现潜在的质量问题？

四、能不能对 APP 进行无侵入的全局质量优化而不须要推进各个业务线？

2、功能特性

动态加载模块

为了支持差别化的优化需求，Booster 实现了模块的动态加载，以便于开发者能在不使用配置的状况下选择使用指定的模块，详见：booster-task-all、booster-transform-all。

第三方注入模块

Booster 在进行优化的过程当中，可能须要注入一些特定的类或者类库，为了解决注入类的依赖管理问题，Booster 提供了VariantProcessor SPI 让开发者能够轻松的扩展

性能检测

APP 的卡顿率是衡量应用运行时性能的一个重要指标，为了能提早发现潜在的卡顿问题，Booster 经过静态分析实现了性能检测，并生成可视化的报告帮助开发者定位问题所在。 其实现原理是经过分析全部的 class 文件，构建一个全局的 Call Graph, 而后从 Call Graph中找出在主线程中调用的链路（Application、四大组件、View、Widget等相关的方法），而后再将这些链路以类为单位分别输出报告。 详见：booster-transform-lint。

多线程优化

业务线众多的 APP 广泛存在线程过载的问题，而线程管理一直是开发者最头疼的问题之一，虽然能够经过制定严格的代码规范来归避此类问题发生，可是对于组织结构复杂的大厂来讲，实施起来成本巨大，而对于第三方 SDK 来讲，代码规范则有些力不从心。为了完全的解决这一问题，Booster 经过在编译期间修改字节码实现了全局线程池优化，并对线程进行重命名。

sharepreference优化

对于 Android 开发者来讲，SharedPreferences几乎无处不在，而在主线程中修改 SharedPreferences会致使卡顿甚至ANR，为了完全的解决这一问题，Booster 对 APP 中的指令进行了全局的替换。 详见：booster-transform-shared-preferences。

常量字段删除

不管是资源索引，仍是其它常量字段，在编译完成后，就没有存在的价值了（反射除外），所以，Booster将对资源索引字段访问的指令替换为常量指令，将其它常量字段从类中删除，一方面能够提高运行时性能，另外一方面，还能减少包体积，资源索引（R）表面上看起来微不足道，实际上占用很多空间，以滴滴车主为例，资源索引相关的类就有上千个，进行常量字段删除后，减少了1MB左右。 详见：booster-transform-shrink。

Toast Bug修复

为了完全解决在 Android 7.1 中存在的bug，Booster 对 APP 中的 Toast.show() 方法调用指令进行全局替换。 详见：booster-transform-toast。

资源压缩

APP 的包体积也是一个很是重要的指标，在APP安装中，图片资源占了至关大的比例，一般状况下，图片质量下降10%-20%并不会影响视觉效果，所以，Booster 采用有损压缩来下降图片的大小，并且，图像尺寸越小，加载速度越快，占用内存越少。

Booster 提供了两种压缩方案：

pngquant 有损压缩（须要自行安装 pngquant 命令行工具）

cwebp 有损压缩（已内置）

两种方案各有优缺点，pngquant的方案不存在兼容性问题，可是压缩率略逊于 WebP，而 WebP 存在系统版本兼容性问题，总的来看，有损压缩的效果很是显著，以滴滴车主为例，APP 包体积减少了10 MB左右。

另外，像 Android SupportLibrary中包含有大量的图片资源，并且支持多种屏幕尺寸，对于 APP而言，相同的图片资源，保留最大尺寸的便可。以Android Support Library 为例，去冗余后，APP 包体积减少了1MB左右。 详见：booster-task-compression。

webview预加载

为了解决 WebView 初始化致使的卡顿问题，Booster 经过注入指令的方式，在主线程空闲时提早加载 WebView。 除上以上特性外，Booster还提供了一些辅助开发的功能，如：检查依赖项中是否包含 SNAPSHOT 版本等等。

3、源码解析

Booster以gradle插件形式实现，Transform，Task分别抽象为Transformer ，VariantProcessor，支持Transformer SPI化 和VariantProcessor SPI化，供外部定制使用，插件实现代码以下：

观察源码能够了解到，不管是application仍是library都会注册一个booster***Transform(),先来看下BoosterAppTransform()

它继承于boosterTransform()，看下他的源码：

代码中isIncremental是判断是不是增量更新仍是全量更新的，不管是全量仍是增量，都有调用onPreTransform(this)这个方法，咱们能够看到这个方法是定义在BoosterTransformInvocation之中。

查看了下他的源码，只有AsmTransfrom继承了Transform，在这里面进行spi化

能够注意到这里经过注解，注册了asm这个transform。

这里定制Transformer，能够两种方式：

1.自定义Transformer ，使用AutoService注解该类

2.自定义ClassTransformer，由AsmTransformer加载这些定制的Transformer，而后循环递归回调ClassTransformer的onPostTransform，使用AutoService注解该类