1.性能优化(一)APP 启动优化- https://juejin.im/post/5cc19374e51d456e781f2036
-- Appcation 中优化方案：
开子线程，线程中没有创建 Handler、没有操作 UI 、对异步要求不高
懒加载，用到的时候在初始化，如网络，数据库，图片库，或一些三方库。
使用 IntentService onHandleIntent () 方法来进行初始化一些比较耗时的操作
优化FlashActivity
2.性能优化(二) UI 绘制优化- https://juejin.im/post/5cc2dfc7e51d456e845b4260
如何减少这 2 件事的耗时，以满足在16ms 渲染完成
CPU 减少 xml 转换成对象的时间。 2.GPU 减少重复绘制的时间。
3.性能优化(三)APP内存异常问题- https://juejin.im/post/5cd82a3ee51d456e781f20ce
分析内存常用工具：top/procrank；meinfo；Procstats；DDMS；MAT；Finder - Activity；LeakCanary；LeakInspector；
内存泄漏，产生的原因: 一个长生命周期的对象持有一个短生命周期对象的引用，通俗点讲就是该回收的对象，因为引用问题没有被回收，最终会产生 OOM。
JAVA GC 如何确定内存回收？
目前虚拟机基本都是采用可达性分析算法，为什么不采用引用计数算法呢？下面就说说引用计数法是如果统计所有对象的引用计数的，再对比可达性分析算法是如何解决引用计数算法的不足。
引用计数算法：每个对象有一个引用计数器，当对象被引用一次则计数器加一，当对象引用一次失效一次则计数器减一，对于计数器为 0 的时候就意味着是垃圾了，可以被 GC 回收。
从 GC Roots 作为起点开始搜索，那么整个连通图中额对象边都是活对象，对于 GC Roots 无法到达的对象便成了垃圾回收的对象，随时可能被 GC 回收。
可以作为 GC Roots 的对象：虚拟机栈正在运行使用的引用；静态属性 常量；JNI 引用的对象。
如果一个对象具有强引用，那垃圾回收器绝不会回收它，当内存空间不足， Java 虚拟机宁愿抛出 OOM 错误，使程序异常 Crash ,也不会靠随意回收具有强引用的对象来解决内存不足的问题.如果强引用对象不再使用时，需要弱化从而使 GC 能够回收，
Java引用类型：强引用；软引用；弱引用；虚引用。
内存抖动：内存频繁的分配与回收,(分配速度大于回收速度时) 最终产生 OOM 。
4.性能优化 (四) ubuntu 完美编译 libjpeg 图像压缩库，媲美微信图片压缩算法- https://juejin.im/post/5ce15d0ce51d45106e5e6dac
相信有一部分使用 iPhone 手机用微信发送图片的时候，明明图片大小只有 1M ，但清晰度比 Android 手机 5 M 图片大小的还要清晰，那么这是为什么呢 ？。
当时谷歌开发 Android 的时候，考虑了大部分手机的配置并没有那么高，所以对图片处理使用的是 Skia。当然这个库的底层还是用的 jpeg 图片压缩处理。但是为了能够适配低端的手机（这里的低端是指以前的硬件配置不高的手机，CPU 和内存在手机上都非常吃紧，性能差），由于哈夫曼算法比较吃 CPU 并且编解码慢，被迫用了其他的算法。所以 Skia 在进行图片处理在低版本中并没有开启哈弗曼算法。
那么，JEPG 到底是什么？JEPG (全称是 Joint Photographic Experts Group) 是一种常见的一种图像格式，为什么我在这里会提到 JEPG 呢？是因为开源了一个 C/C++ 库底层是基于哈夫曼算法对图片的压缩 (libjpeg)
libjpeg-turbo 是一个 JPEG 图像编解码器，它使用 SIMD 指令（MMX，SSE2，AVX2，NEON，AltiVec）来加速 x86，x86-64，ARM 和 PowerPC 系统上的基线 JPEG 压缩和解压缩，以及渐进式JPEG 压缩 x86 和 x86-64 系统。
利用哈夫曼算法对图片压缩。
JEPGLIB 图片压缩，哈夫曼算法图片压缩LIBJPEG_SAMPLE- https://github.com/yangkun19921001/LIBJPEG_SAMPLE
5.性能优化 (五) 长图优化，仿微博加载长图方式- https://juejin.im/post/5ce96da06fb9a07ee4633f50
加载 长图控件，防微博加载方式- https://github.com/yangkun19921001/long_picture_view
6.性能优化 (六) 老板问你咱们 APP 耗电量- https://juejin.im/post/5ce9088f6fb9a07ee4633ef3
电量优化 部分代码- https://github.com/yangkun19921001/battery
Google 开源电量分析工具 battery-historian- https://github.com/google/battery-historian
Battery Historian 是在运行 Android 5.0 Lollipop（API级别21）及更高版本的 Android 设备上检查电池相关信息和事件的工具，而设备未插入。
7.性能优化 (七) APK 加固之 Dex 加解密- https://juejin.im/post/5cf3ee295188256aa76bb1e1
APK 加固 dex 加密，解密- https://github.com/yangkun19921001/DexEncryptionDecryption
ClassLoader 还是很重要的，热修复跟热加载都是这原理。
8.性能优化 (八) APK 加固之动态替换 Application- https://juejin.im/post/5cf69d30f265da1b897abd53
ActivityThread.java
mian() -> thread.attach() -> attachApplication() -> 接收 AMS 发过来的参数之后 sendMessage（H.BIND_APPLICATION）-> 处理 BIND_APPLICATION -> handleBindApplication() 在这里准备好 application - > Application app = data.info.makeApplication() - > mInitialApplication = app;
加固流程原理：从 dex 分包 -> 加密 -> 对齐 > 签名 - > 打包压缩成 APK 。
9.性能优化 (九) APP 稳定性之热修复原理探索- https://juejin.im/post/5cfce989f265da1b6c5f6991
插桩原理：
通过源码得知 findClass 是通过遍历 dexElements 来找到 class, 如果我们反射得到 DexPathList 的私有数组 dexElements，我们外部改变这个数组内部顺序索引，将修复好的 dex 放入 [0] 的位置，那么是不是能够优先使用修复好的 dex 勒？ 很明显，是成立的。
10. 性能优化 (十) APP 持续运行之进程保活实现- https://juejin.im/post/5cffe4d4f265da1b695d55d4
进程保活方案- https://github.com/yangkun19921001/KeepAlive
保活组件- https://github.com/fanqieVip/keeplive
监控手机锁屏解锁事件，在屏幕锁屏时启动 1 个像素透明的 Activity ，在用户解锁时将 Activity 销毁掉，从而达到提高进程优先级的作用。
靠谱的（Activity + Service 提权 + Service 机制拉活 + JobScheduler 定时检测进程是否运行 + 后台播放无声文件 + 双进程守护），然后组成了一个进程保活终极方案。
11. 性能优化 (十一) ProGuard 对代码和资源压缩- https://juejin.im/post/5d05dab06fb9a07ea9446e21
ProGuard 是什么？可以把 ProGuard 理解为是对代码和资源压缩的一个工具，它能够提供对 Java 类文件的压缩、优化、混淆，和预校验。压缩的步骤是检测并移除未使用的类、字段、方法和属性。优化的步骤是分析和优化方法的字节码。混淆的步骤是使用短的毫无意义的名称重命名剩余的类、字段和方法。压缩、优化、混淆使得代码更小，更高效。
12.性能优化 (十二) APK 极限压缩- https://juejin.im/post/5d0627f7f265da1bd4247e76
最新版微信6.5.7（除图片选择器外）- https://github.com/GitLqr/LQRWeChat
AndResGuard 是一个缩小 APK 大小的工具，它的原理类似 Java Proguard ，但是只针对资源。它会将原本冗长的资源路径变短，例如将 res/drawable/wechat 变为 r/d/a。