Android——性能优化

在Android应用优化方面，主要从以下4个方面进行优化：

• 稳定（内存溢出、崩溃）
• 流畅（卡顿）
• 耗损（耗电、流量、网络）
• 安装包（APK瘦身）

内存优化

由于Android应用的沙箱机制，每个应用所分配的内存大小是有限度的，可用内存太低就会触发LMK(Low Memory Killer)机制，进而会出现闪退现象。

分析工具

Memory Monitor

Memory Monitor是Android Studio自带的一个内存监视工具，它可以很好地帮助我们进行内存实时分析。通过点击Android Studio右下角的Memory Monitor标签，打开工具可以看见较浅蓝色代表free的内存，而深色的部分代表使用的内存从内存变换的走势图变换，可以判断关于内存的使用状态，例如当内存持续增高时，可能发生内存泄漏；当内存突然减少时，可能发生GC等。

Memory Analyzer

MAT 是一个快速，功能丰富的 Java Heap 分析工具，通过分析 Java 进程的内存快照 HPROF 分析，从众多的对象中分析，快速计算出在内存中对象占用的大小，查看哪些对象不能被垃圾收集器回收，并可以通过视图直观地查看可能造成这种结果的对象。

LeakCanary

LeakCanary是一个内存监测工具，该工具是Square公司出品的，所谓Square出品必属精品，LeakCanary的官方地址为https://github.com/square/leakcanar，我们可以在Gradle里引用它。

Android Lint

Android Lint 是Android Sutido种集成的一个Android代码提示工具，它可以给布局、代码提供非常强大的帮助。如果在布局文件中写了三层冗余的LinearLayout布局，就会在编辑器右边看到提示。当然这个是一个简单的举例，Lint的功能非常强大，大家应该养成写完代码查看Lint的习惯，这不仅让你及时发现代码种隐藏的一些问题，更能让你养成良好的代码风格。

交互优化

交互是与用户体验最直接的方面，交互场景大概可以分为四个部分：UI 绘制、应用启动、页面跳转、事件响应。对于上面四个方面，大致可以从以下两个方面来进行优化：

• 界面绘制：主要原因是绘制的层级深、页面复杂、刷新不合理，由于这些原因导致卡顿的场景更多出现在 UI 和启动后的初始界面以及跳转到页面的绘制上。
• 数据处理：导致这种卡顿场景的原因是数据处理量太大，一般分为三种情况，一是数据在处理 UI 线程，二是数据处理占用 CPU 高，导致主线程拿不到时间片，三是内存增加导致 GC 频繁，从而引起卡顿。

Android的绘制需要经过onMeasure、onLayout、onDraw等几个步骤，所以布局的层级越深、元素越多、耗时也就越长。还有就是Android 系统每隔 16ms 发出 VSYNC 信号，触发对 UI 进行渲染，如果每次渲染都成功，这样就能够达到流畅的画面所需的 60FPS。如果某个操作花费的时间是 24ms ，系统在得到 VSYNC 信号时就无法正常进行正常渲染，这样就发生了丢帧现象。
之所以出现卡顿现象，是因为有两个原因：

• 绘制任务太重，绘制一帧内容耗时太长
• 主线程太忙，根据系统传递过来的 VSYNC 信号来时还没准备好数据导致丢帧

基于问题产生的原因，我们可以从以下几个方面进行优化：

布局优化

在Android中系统对View进行测量、布局和绘制时，都是通过对View树的遍历来进行操作的。如果一个View树的高度太高就会严重影响测量、布局和绘制的速度。Google也在其API文档中建议View高度不宜超过10层。现在版本中Google使用RelativeLayout替代LineraLayout作为默认根布局，目的就是降低LineraLayout嵌套产生布局树的高度，从而提高UI渲染的效率。
在布局优化方面，我们可以从以下几个方面进行优化：

• 布局复用，使用标签重用layout；
• 提高显示速度，使用延迟View加载；
• 减少层级，使用标签替换父级布局；
• 注意使用wrap_content，会增加measure计算成本；
• 删除控件中无用属性；

渲染优化

过度绘制是指在屏幕上的某个像素在同一帧的时间内被绘制了多次。在多层次重叠的 UI 结构中，如果不可见的 UI 也在做绘制的操作，就会导致某些像素区域被绘制了多次，从而浪费了多余的 CPU 以及 GPU 资源。我们可以通过开启手机的过渡绘制功能来检测页面是否被过度绘制。
为了避免过度绘制，我们可以从以下几个方面进行优化：

• 布局上的优化，移除 XML 中非必须的背景，移除 Window 默认的背景、按需显示占位背景图片。
• 自定义View优化，使用 canvas.clipRect()来帮助系统识别那些可见的区域，只有在这个区域内才会被绘制。

启动优化

应用一般都有闪屏页，优化闪屏页的 UI 布局，可以通过 Profile GPU Rendering 检测丢帧情况。
也可以通过启动加载逻辑优化。可以采用分布加载、异步加载、延期加载策略来提高应用启动速度。
数据准备。数据初始化分析，加载数据可以考虑用线程初始化等策略。

刷新优化

Android开发中，通常是异步操作页面的，因此需要可以从刷新优化上来优化应用，主要有两个原则：

• 减少刷新次数；
• 缩小刷新区域；

动画优化

在实现动画效果时，需要根据不同场景选择合适的动画框架来实现。有些情况下，可以用硬件加速方式来提供流畅度。

耗电优化

在 Android5.0 以前，在应用中测试电量消耗比较麻烦，也不准确，5.0 之后专门引入了一个获取设备上电量消耗信息的 API，即Battery Historian。Battery Historian 是一款由 Google 提供的 Android 系统电量分析工具，和Systrace 一样，是一款图形化数据分析工具，直观地展示出手机的电量消耗过程，通过输入电量分析文件，显示消耗情况，最后提供一些可供参考电量优化的方法。

网络优化

对于网络的优化，可以从以下几个方面着手进行：

图片网络优化

例如，针对网络情况，返回不同的图片数据，一种是高清大图，一种是正常图片，一种是缩略小图。当用户处于wifi下给控件设置高清大图，当4g或者3g模式下加载正常图片，当弱网条件下加载缩略图。

网络数据优化

• 连接复用：节省连接建立时间，如开启 keep-alive。
  对于Android来说默认情况下HttpURLConnection和HttpClient都开启了keep-alive。只是2.2之前HttpURLConnection存在影响连接池的Bug，具体可见：Android HttpURLConnection及HttpClient选择
• 请求合并：即将多个请求合并为一个进行请求，比较常见的就是网页中的CSS Image Sprites。如果某个页面内请求过多，也可以考虑做一定的请求合并。
• 减少请求数据的大小：对于post请求，body可以做gzip压缩的，header也可以做数据压缩。返回数据的body也可以做gzip压缩，body数据体积可以缩小到原来的30%左右。

异常拦截优化

在获取数据的流程中，访问接口和解析数据时都有可能会出错，我们可以通过拦截器在这两层拦截错误。

• 在访问接口时，我们不用设置拦截器，因为一旦出现错误，Retrofit会自动抛出异常。比如，常见请求异常404，500，503等等。
• 在解析数据时，我们设置一个拦截器，判断Result里面的code是否为成功，如果不成功，则要根据与服务器约定好的错误码来抛出对应的异常。比如，token失效，禁用同账号登陆多台设备，缺少参数，参数传递异常等等。

APK瘦身

Android的apk主要有以下信息构成：

• assets文件夹。存放一些配置文件、资源文件，assets不会自动生成对应的 ID，而是通过 AssetManager 类的接口获取。
• res。res 是 resource 的缩写，这个目录存放资源文件，会自动生成对应的 ID 并映射到 .R 文件中，访问直接使用资源ID。
• META-INF。保存应用的签名信息，签名信息可以验证 APK 文件的完整性。
• AndroidManifest.xml。这个文件用来描述 Android 应用的配置信息，一些组件的注册信息、可使用权限等。
• classes.dex。Dalvik 字节码程序，让 Dalvik 虚拟机可执行，一般情况下，Android 应用在打包时通过Android SDK 中的 dx 工具将 Java 字节码转换为 Dalvik 字节码。
• resources.arsc。记录着资源文件和资源 ID 之间的映射关系，用来根据资源 ID 寻找资源。

基于上面的组成部分，那么优化也可以从以下几个方面着手：

• 代码混淆。使用proGuard 代码混淆器工具，它包括压缩、优化、混淆等功能。
• 资源优化。比如使用 Android Lint 删除冗余资源，资源文件最少化等。
• 图片优化。比如利用 AAPT 工具对 PNG 格式的图片做压缩处理，降低图片色彩位数等。
• 避免重复功能的库，使用 WebP图片格式等。
• 插件化，比如功能模块放在服务器上，按需下载，可以减少安装包大小。

针对Android的性能优化，主要有以下几个有效的优化方法：

1. 布局优化
2. 绘制优化
3. 内存泄漏优化
4. 响应速度优化
5. ListView/RecycleView及Bitmap优化
6. 线程优化
7. 其他性能优化的建议

布局优化

关于布局优化的思想很简单，就是尽量减少布局文件的层级。这个道理很浅显，布局中的层级少了，就意味着Android绘制时的工作量少了，那么程序的性能自然就提高了。
1. 删除布局中无用的控件和层次，其次有选择地使用性能比较低的ViewGroup。
关于有选择地使用性能比较低的ViewGroup,这就需要我们开发就实际灵活选择了。
例如：如果布局中既可以使用LinearLayout也可以使用RelativeLayout，那么就采用LinearLayout，这是因为RelativeLayout的功能比较复杂，它的布局过程需要花费更多的CPU时间。FrameLayout和LinearLayout一样都是一种简单高效的ViewGroup，因此可以考虑使用它们，但是很多时候单纯通过一个LinearLayout或者FrameLayout无法实现产品效果，需要通过嵌套的方式来完成。这种情况下还是建议采用RelativeLayout,因为ViewGroup的嵌套就相当于增加了布局的层级，同样会降低程序的性能。
2. ViewStub
ViewStub提供了按需加载的功能，当需要时才会将ViewStub中的布局加载到内存，提高了程序初始化效率。
3. 避免过度绘制
过度绘制（Overdraw）描述的是屏幕上的某个像素在同一帧的时间内被绘制了多次。在多层次重叠的 UI 结构里面，如果不可见的 UI 也在做绘制的操作，会导致某些像素区域被绘制了多次，同时也会浪费大量的 CPU 以及 GPU 资源。
如下所示，有些部分在布局时，会被重复绘制：

过度绘制.png

过度绘制优化可以参考：Android 过度绘制优化

绘制优化

绘制优化是指View的onDraw方法要避免执行大量的操作，这主要体现在两个方面：
1. onDraw中不要创建新的局部对象。
因为onDraw方法可能会被频繁调用，这样就会在一瞬间产生大量的临时对象，这不仅占用了过多的内存而且还会导致系统更加频繁gc，降低了程序的执行效率。
2. onDraw方法中不要做耗时的任务，也不能执行成千上万次的循环操作，尽管每次循环都很轻量级，但是大量的循环仍然十分抢占CPU的时间片，这会造成View的绘制过程不流畅。
按照Google官方给出的性能优化典范中的标准，View的绘制频率保证60fps是最佳的，这就要求每帧绘制时间不超过16ms(16ms = 1000/60)，虽然程序很难保证16ms这个时间，但是尽量降低onDraw方法中的复杂度总是切实有效的。

内存泄漏优化

内存泄漏是开发过程中的一个需要重视的问题，但是由于内存泄露问题对开发人员的经验和开发意识有较高的要求，因此也是开发人员最容易犯的错误之一。
内存泄露的优化分为两个方面：
1. 在开发过程中避免写出有内存泄漏的代码
2. 通过一些分析工具比如MAT来找出潜在的内存泄露，然后解决。

什么是内存泄漏?
java是有垃圾回收机制的。java虚拟机会派出一些回收线程不定时地回收那些不再被需要的内存空间（注意回收的不是对象本身，而是对象占据的内存空间）。
Q：什么是不再被需要的内存空间？
Java没有指针，全凭引用来和对象进行关联，通过引用来操作对象。如果一个对象没有与任何引用关联，那么这个对象也就不太可能被使用到了，回收器便是把这些“无任何引用的对象”作为目标，回收了它们占据的内存空间。
Q：如何分辨为对象无引用？

1. 引用计数法。直接计数，简单高效，Python便是采用该方法。但是如果出现 两个对象相互引用，即使它们都无法被外界访问到，计数器不为0它们也始终不会被回收。为了解决该问题，java采用的是方法2。
2. 可达性分析法。这个方法设置了一系列的“GC Roots”对象作为索引起点，如果一个对象 与起点对象之间均无可达路径，那么这个不可达的对象就会成为回收对象。这种方法处理 两个对象相互引用的问题，如果两个对象均没有外部引用，会被判断为不可达对象进而被回收（如下图）。

Q：有了回收机制，为什么还会发生内存泄漏？
虽然垃圾回收器会帮我们回收大部分无用的内存空间，但是对于还保持着引用，但逻辑上已经不会再用到的对象，垃圾回收器不会回收它们。这些对象积累在内存中，直到程序结束，这就是所说的“内存泄漏”。 当然了，用户对单次的内存泄漏并没有什么感知，但当泄漏积累到内存都被消耗完，就会导致卡顿，崩溃。
下面这张图可以帮助我们更好地理解对象的状态，以及内存泄漏的情况

内存泄漏.jpg

左边未引用的对象是会被GC回收的，右边被引用的对象不会被GC回收，但是未使用的对象中除了未引用的对象，还包括已被引用的一部分对象，那么内存泄漏久发生这部分已被引用但未使用的对象。

Android一般在什么情况下会出现内存泄漏？
①集合类泄漏
②单例/静态变量造成的内存泄漏
③匿名内部类/非静态内部类
④资源未关闭造成的内存泄漏
大概可以分为以上几类，还有一些经常会听到的Hanlder, AsyncTask引起内存泄漏，都属于上述③中的情况。

Android怎么分析内存泄漏？
可以通过 MAT(Memory Analyzer Tool)，或者 LeakCanary 来检测 Android 中的内存泄漏。

内存泄漏可参考：Android应用内存泄漏的定位、分析与解决策略

响应速度优化

响应速度优化的核心思想就是避免在主线程中做耗时操作。
如果有耗时操作，可以开启子线程执行，即采用异步的方式来执行耗时操作。
如果在主线程中做太多事情，会导致Activity启动时出现黑屏现象，甚至ANR。
Android规定，Activity如果5秒钟之内无法响应屏幕触摸事件或者键盘输入事件就会出现ANR，而BroadcastReceiver如果10秒钟之内还未执行完操作也会出现ANR。

为了避免ANR，可以开启子线程执行耗时操作，但是子线程不能更新UI，所以需要子线程与主线程进行通信来解决子线程执行耗时任务后，通知主线程更新UI的场景。关于这部分，需要掌握Handler消息机制，AsyncTask，IntentService等内容。
然而，在实际开发中，ANR仍然不可避免的发生了，而且很难从代码上发现，这时候就要用到ANR日志分析。当一个进程发生了ANR之后，系统会在/data/anr目录下创建一个文件traces.txt，通过分析这个文件就能定位出ANR的原因。

ListView/RecycleView及Bitmap优化

ListView/RecycleView的优化思想主要从以下几个方面入手：
① 使用ViewHolder模式来提高效率
② 异步加载：耗时的操作放在异步线程中
③ ListView/RecycleView的滑动时停止加载和分页加载
Bitmap优化
对加载图片进行压缩，避免加载图片多大导致OOM出现。

线程优化

线程优化的思想就是采用线程池，避免程序中存在大量的Thread。线程池可以重用内部的线程，从而避免了线程的创建和销毁所带来的性能开销，同时线程池还能有效地控制线程池的最大并发数，避免大量的线程因互相抢占系统资源从而导致阻塞现象的发生。因此在实际开发中，尽量采用线程池，而不是每次都要创建一个Thread对象。

其他性能优化

①避免过度的创建对象
②不要过度使用枚举，枚举占用的内存空间要比整型大
③常量请使用static final来修饰
④使用一些Android特有的数据结构，比如SparseArray和Pair等
⑤适当采用软引用和弱引用
⑥采用内存缓存和磁盘缓存
⑦尽量采用静态内部类，这样可以避免潜在的由于内部类而导致的内存泄漏。