- 布局
- 绘制
- 启动
- 内存
- apk
布局优化
布局优化的思路就是尽量避免布局文件的层级，避免OverDraw;
Overdraw:
就是过度绘制，是指在一帧的时间内（16.67ms）像素被绘制了多次，理论上一个像素每次只绘制一次是最优的，但是由于重叠的布局导致一些像素会被多次绘制，而每次绘制都会对应到CPU的一组绘图命令和GPU的一些操作，当这个操作耗时超过16.67ms时，就会出现掉帧现象，也就是我们所说的卡顿，所以对重叠不可见元素的重复绘制会产生额外的开销，需要尽量减少Overdraw的发生
检测OverDraw：
- 在开发者选项中，打开
调试GPU过度绘制（Show GPU OverDraw），会出现这个界面：
| 颜色 | 意义 |
|---|---|
| 没有颜色 | 意味着没有OverDraw，像素只绘制了一次 |
| 蓝色 | 意味着overdraw 1倍。像素绘制了两次。大片的蓝色还是可以接受的（若整个窗口是蓝色的，可以摆脱一层） |
| 绿色 | 意味着overdraw 2倍。像素绘制了三次。中等大小的绿色区域是可以接受的但你应该尝试优化、减少它们。 |
| 浅红 | 意味着overdraw 3倍。像素绘制了四次，小范围可以接受。 |
| 暗红 | 意味着overdraw 4倍。像素绘制了五次或者更多。这是错误的，要修复它们。 |
如何优化：
1. 合理布局xml:
- 在编写xml界面时，删除无用的控件和层次；
- 其次如果一个界面LinearLayout和RelativeLayout都可以实现，采用LinearLayout，因为RelativeLayout的内部实现较复杂，布局过程会花费更多的CPU事件；
2. 使用include，merge，ViewStub
- 使用include标签复用布局文件
- 使用merge标签配合include减少布局的层级，如果被复用的布局文件有一层布局是不需要的，可以使用merge去掉多余的一层
- ViewStub继承View，它本身不参与任何的布局和绘制过程，作用于按需加载所需的布局文件；调用
setVisibility（）和inflate（）后ViewStub才会生效；
3. 使用ClipRect & QuickReject
为了解决Overdraw的问题，Android系统会通过避免绘制那些完全不可见的组件来尽量减少消耗。但是不幸的是，对于那些过于复杂的自定义的View(通常重写了onDraw方法)，Android系统无法检测在onDraw里面具体会执行什么操作，系统无法监控并自动优化，也就无法避免Overdraw了。但是我们可以通过canvas.clipRect()来帮助系统识别那些可见的区域。这个方法可以指定一块矩形区域，只有在这个区域内才会被绘制，其他的区域会被忽视。这个API可以很好的帮助那些有多组重叠组件的自定义View来控制显示的区域。同时clipRect方法还可以帮助节约CPU与GPU资源，在clipRect区域之外的绘制指令都不会被执行，那些部分内容在矩形区域内的组件，仍然会得到绘制。除了clipRect方法之外，我们还可以使用canvas.quickreject()来判断是否没和某个矩形相交，从而跳过那些非矩形区域内的绘制操作
Android画布剪裁函数clipRect详解
使用clipRect()优化OverDraw
其实clipRect函数就是通过巧妙的剪裁和拼接画布，将自定义控件中重叠的部分，做优化处理。
绘制优化
绘制优化指View的onDraw（）过程要避免大量操作，主要体现在两个方面：
- 不能创建新的局部对象
- 不能做耗时操作
因为onDraw过程是会被频繁调用的，大量的局部变量会占用过多的内存，并且会引发频繁的GC，GC会影响程序的执行效率（Stop the World）;过多的耗时操作会十分消耗CPU的时间片，导致View绘制的不流畅；官方规定View的绘制率保证在60fps最好，要求每帧的时间不超过16ms（1000/60），尽量降低onDraw方法的复杂度会有效的提高程序的效率；
启动优化
启动的分类
- 冷启动：当启动应用时，后台没有该应用的进程，这时系统会首先会创建一个新的进程分配给该应用，这种启动方式就是冷启动
- 热启动：当启动应用时，后台已有该应用的进程，比如按下home键，这种在已有进程的情况下，这种启动会从已有的进程中来启动应用，这种启动方式叫热启动
- 温启动：当启动应用时，后台已有该应用的进程，但是启动的入口Activity被干掉了，比如按了back键，应用虽然退出了，但是该应用的进程是依然会保留在后台，这种启动方式叫温启动
启动时间的检测：
1.ADB命令： adb shell am start -W packagename/MainActivity
| 参数 | 含义 |
|---|---|
| ThisTime | 最后一个启动的Activity的启动耗时； |
| TotalTime | 新应用启动的耗时，包括新进程的启动和Activity的启动 |
| WaitTime | ActivityManagerService启动App的Activity时的总时间（包括当前Activity的onPause()和自己Activity的启动） |
冷启动白屏出现的原因：
ActivityStack的startActivityLock（）会调用showStartingWindow() 添加一个空白的window；
处理冷启动白屏的方法：
-
通过Theme设置window不显示或者window设置为透明的
为Theme设置背景图
推荐第二种，第一种如果根activity启动耗时的话会出现卡顿现象；
启动时的其他优化
- 多进程Application重复创建，
动态判断包名避免重复初始化 - 大量子线程任务,
设置工作线程的优先级 - 线程池的开销比单一线程大很多，
在启动的时候使用线程更优 - 信息未缓存，重复获取影响性能
内存优化
- 内存抖动：短时间内大量的对象创建和销毁会出现内存抖动
- 内存泄漏：对象内存由于某些原因无法释放和回收
- 内存溢出：大量的内存泄漏会导致内存溢出OOM
-
内存卡顿：安卓的垃圾收集器是CMS，CMS的
Stop the World会造成卡顿
常见的字符串拼接会造成内存的抖动：
因为字符串是final常量，一经赋值就无法改变，但是java语言对
+进行了语法糖设置，实际是将String转化为StringBuffer，每次都要new 一个StringBuffer出来；所以我们如果直接使用StringBuffer的append（）就可以避免重复创建StringBuffer对象；
预防内存抖动：
- 避免在循环中创建对象
- 避免在重复调用的方法中创建局部对象
- 使用对象池：Handler的Message的obtain（）
内存的检测
-
AS自带的Profiler
内存泄漏的原因：长生命周期对象持有短生命周期对象引用，导致短生命周期对象无法回收
常见的内存泄漏：
- 单例持有activity的引用
- 外部类持有内部类的引用（Hnadler，Runnable，Listener）
非静态内部类和匿名内部类会默认持有外部类的引用 - 大量的强引用
内存泄漏的检测：
- leakCanary
避免内存溢出OOM的措施：
- 使用静态内部类
- 使用WeakReference
- 增加JVM启动参数的内存大小
- 注意资源的手动回收（关闭流，停止动画，注销EventBus，删除元素置null）
Bitmap优化
APK瘦身
APK的结构：
目录：
- assets：存放应用的资源，这些资源能够通过AssetManager对象获得
- lib：包含了针对处理器层面的被编译的代码。这个目录针对每个平台类型都有一个子目录，比如armeabi, armeabi-v7a, arm64-v8a, x86, x86_64和mips。
- res：包含了没被编译到resources.arsc的资源。
- META-INF：包含CERT.SF和CERT.RSA签名文件，也包含了MANIFEST.MF文件。（译注：校验这个APK是否被人改动过）
文件：
- classes.dex:包含了能被Dalvik/Art虚拟机理解的 dex 文件格式的类。
- resources.arsc：包含了被编译的资源。该文件包含了res/values目录的所有配置的 xml 内容。打包工具将 xml 内容编译成二进制形式并压缩。这些内容包含了语言字符串和styles，还包含了那些内容虽然不直接存储在resources.arsc文件中，但是给定了该内容的路径，比如布局文件和图片。所以又叫 资源映射表
- AndroidManifest.xml：包含了主要的Android配置文件。这个文件列出了应用名称、版本、访问权限、引用的库文件。该文件使用二进制 xml 格式存储。（译注：该文件还能看到应用的minSdkVersion, targetSdkVersion等信息）
瘦身步骤：
1. 使用Lint检测res目录，删除无用资源
2. 压缩图片，或者使用svg,Webp,tinyPNG
3. 修改lib配置：
安卓系统现在支持7中CPU架构，每种架构都支持一种ABI（二进制接口，Android binary interface），每种ABI都定义了二进制文件（.so文件），我们可以删除其他的CPU架构的适配，只保留armeabi-v7a一种主流架构；
ndk {
//设置支持的so库架构
abiFilters "armeabi-v7a"
}
