booster原理解析
Booster 是一款专门为移动应用设计的易用、轻量级且可扩展的质量优化框架，其目标主要是为了解决随着 APP 复杂度的提升而带来的性能、稳定性、包体积等一系列质量问题。
Booster 提供了性能检测、多线程优化、资源索引内联、资源去冗余、资源压缩、系统 Bug 修复等一系列功能模块，可以使得稳定性能够提升 15% ~ 25%，包体积可以减小 1MB ~ 10MB。
以上是官方简介。最近在学ASM，阅读优秀的开源框架来学习是最吼的，毕竟站在前人的肩膀上，可以学习大佬们的AOP思路以及具体细节实现，看看大佬们是怎么找切入点的。这里就不搞源码了，只做记录和总结，有兴趣的可以自行阅读。
-
多线程优化->booster-transform-thread。booster的做法和大家想到的其实差不多，当然也有可能人家做的最早，这个思路就是他们发现的。其实也是将线程池和一些封装线程的工具 Timer、HanlderThread、AsyncTask等替换成自定义的类，并为其命名，比较细节的是囊括了android中所有的多线程场景。
-
系统bug修复，7.1版本的Toast->booster-transform-toast崩溃问题BadTokenException，将Toast.show()替换成ShadowToast.show()，崩溃的原因是Token失效，8.0版本的修复其实也是加try catch。ShadowToast里面反射将Toast中mHandler回调修改为CaughtCallback，CaughtCallback.handleMessage()方法加了try catch。
-
SharedPreferences->booster-transform-shared-preferencest，将getPreferences()方法调用替换为ShadowSharedPreferences，使用自定义的BoosterSharedPreferences，封装了线程池和锁做成多线程并发，可以对应SharedPreferencesImpl来看。
-
WebView 预加载->booster-transform-webview，在Application.onCreate()插入ShadowWebView.preloadWebView()，这里idle调用startChromiumEngine，反射调用WebViewFactoryProvider.startYourEngines()，应该就是初始化chromium引擎了。此处源码中获取WebViewFactoryProvider方法WebViewFactory.getProviderClass()也是反射获取
com.android.webview.chromium.WebViewChromiumFactoryProviderForR，然后执行其create()方法传入WebViewDelegate()。反射大家都会，但是这个切入点着实难找。搜了一下资料，推荐一篇老罗的WebView加载Chromium动态库的过程分析。 -
处理系统 Crash->booster-transform-activity-thread，反射修改ActivityThread.mH这个handler的callback，handleMessage()方法套了个try catch，内部还是由原mH类分发消息，mH这个类很关键，四大组件等都在此回调。
-
资源索引内联、DataBinding BR索引内联删除生成的R文件等常量字段，调用处修改为对应的数值。说到内联，kotlin的inline关键字也是，其编译期会将高阶函数的内容copy到调用处，优化函数对象的生成以及函数调用入栈出栈的开销，而随之带来的就是代码量的增加，可以想象一个函数体还不算小的inline函数被调用成千上万次。
-
修复 finalizer 导致的 TimeoutException->booster-transform-finalizer-watchdog-daemon，onCreate()方法注入FinalizerWatchdogDaemonKiller.kill()，反射将FinalizerWatchdogDaemon父类Daemon变量thread置空，让其停止工作。简单说下FinalizerWatchdogDaemon，重写了finalize()的对象GC时不会马上清除，而是执行finalize()，finalize()超过限定时间后就会抛出TimeoutException。
