Android性能优化

优化角度

---

RAM方面

• 内存泄露优化
• 避免OOM
• APP启动优化
• 线程优化

Res方面

• apk瘦身
• 布局优化
• 绘制优化
• ListView和Bitmap优化

其他

• ANR分析
• 电量优化
• 性能优化工具

---

内存泄露优化

• 单例模式的持有;
• 静态对象的持有
• 属性动画不被cancel，其持有view，view又持有activity导致内存泄露。
• 非静态内部类会持有外部类的引用，如果非静态内部类的实例是静态的，或者在执行耗时操作，就会长期的维持着外部类的引用
• 以匿名内部类构建的AsyncTask和新线程会隐式地带有一个对外的引用，如果在activity结束时候没有执行完成，会造成内存泄露，建议使用静态内部类，在Activity销毁时候也应该取消相应的任务AsyncTask::cancel()，避免任务在后台执行浪费资源
• Context导致内存泄漏
  根据场景确定使用Activity的Context还是Application的Context,因为二者生命周期不同，对于不必须使用Activity的Context的场景（Dialog）,一律采用Application的Context,单例模式是最常见的发生此泄漏的场景，比如传入一个Activity的Context被静态类引用，导致无法回收
• 静态View导致泄漏
  使用静态View可以避免每次启动Activity都去读取并渲染View，但是静态View会持有Activity的引用，导致无法回收，解决办法是在Activity销毁的时候将静态View设置为null（View一旦被加载到界面中将会持有一个Context对象的引用，在这个例子中，这个context对象是我们的Activity，声明一个静态变量引用这个View，也就引用了activity）
• BraodcastReceiver，ContentObserver，File，Cursor，Stream，Bitmap、系统服务等资源及时关闭，它们内部往往都使用了缓冲，会造成内存泄漏，一定要确保关闭它并将引用置为null
• WebView导致的内存泄漏
  WebView只要使用一次，内存就不会被释放，所以WebView都存在内存泄漏的问题，通常的解决办法是为WebView单开一个进程，使用AIDL进行通信，根据业务需求在合适的时机释放掉
• 集合中的对象未清理
  集合用于保存对象，如果集合越来越大，不进行合理的清理，尤其是入股集合是静态的
• Bitmap导致内存泄漏
  bitmap是比较占内存的，所以一定要在不使用的时候及时进行清理，避免静态变量持有大的bitmap对象
• 监听器未关闭
  很多需要register和unregister的系统服务要在合适的时候进行unregister,手动添加的listener也需要及时移除

减少OOM

Android系统为每一个应用程序都设置了一个硬性的Dalvik Heap Size最大限制阈值，这个阈值在不同的设备上会因为RAM大小不同而各有差异。ActivityManager.getMemoryClass()可以用来查询当前应用的Heap Size阈值。命令行也可以查看相关的内存信息
减少OOM方面：
其实避免内存泄露也是间接避免了OOM

• 减少内存分配量
• ArrayMap/SparseArray而不是HashMap等传统数据结构，通常的HashMap的实现方式更加消耗内存，因为它需要一个额外的实例对象来记录Mapping操作。另外，SparseArray更加高效在于他们避免了对key与value的autobox自动装箱，并且避免了装箱后的解箱。
• 避免在Android里面使用Enum
• Android内置字符串/颜色/图片/动画/样式以及简单布局的使用，可以在程序中直接饮用系统资源，减少apk体积，但要注意版本差异

APP启动优化

一般情况下我们会利用主题去防止出现白屏
需要尽可能减少Application的onCreate中所要做的事情，比如一些不重要的SDK延迟或者异步加载；
有几个方向：
1、利用开启APP时候提前展示的window，快速展示一个界面，给用户视觉上快速的感觉:onCreate函数开头将activity的theme设置为style中的主题，然后在oncreate函数运行过程中又切换成activity标签下配置的背景。
2、异步初始化三方组件
3、减少IO、网络等密集请求

线程优化

采用线程池，一是减少线程重复创建或销毁带来的性能损耗；
二是控制最大并发线程数，防止大量线程抢CPU造成卡顿

apk瘦身

为什么要瘦身：大体积下载转化率低，同时对服务器增加流量压力，此外会影响手机厂商预置应用
利用ProGuard压缩代码去除无用资源，通过移除不需要的代码，重命名类，域与方法等等对代码进行压缩，优化与混淆。使用ProGuard可以使得你的代码更加紧凑，这样能够减少mapping代码所需要的内存空间。
使用 XZ 或者 7-Zip 压缩Library
第三方开源库的瘦身，仅保留自己需要的部分
so的优化与配置，只保留一类so
动态下发一些资源:字库、so、换肤包等

布局优化

尽量减少布局层级，同层级时候使用功能较低的ViewGroup，比如FrameLayout和LinearLayout，但性能较低的layout拓展性差难以实现较复杂的布局，导致需要嵌套，这时候还是建议使用RelativeLayout毕竟嵌套也会降低性能。
实用策略：

• inlcude标签 便于布局重用
• merge标签 和include配合使用，在被include的布局根元素替换为merge标签，能够减少布局层级
• ViewStub实现需要时加载布局，setVisibility或者inflate之后，被内部引用布局替换掉，提高应用启动性能。

绘制优化

为了让屏幕的刷新帧率达到60fps，我们需要确保在时间16ms（1000/60Hz）内完成单次刷新的操作（包括measure、layout以及draw）
onDraw方法中不要创造大量临时对象，因为该方法会被频繁调用，大量GC伤不起。此外也不要使用耗时操作你懂的啦
减少overDraw的产生，尽量让一个像素只绘制一次，减少布局重叠。
除了布局精简，还可以去掉每行RelativeLayout的背景色；去掉每行TextView的背景色；必要的话去掉activity使用的Theme的背景色。

ListView优化

ListView只是一个代表，很多复杂的View都可以参考如下建议
使用ViewHolder并减少在getView中的复杂操作
根据滑动速度来变化view的操作，比如快速滑动时候不开启线程
采用硬件加速来优化view的绘制

Bitmap优化

• 采用BitmapFactory来对图片进行采样
  inSampleSize：缩放比例，在把图片载入内存之前，我们需要先计算出一个合适的缩放比例，避免不必要的大图载入。
  decode format：解码格式，选择ARGB_8888/RBG_565/ARGB_4444/ALPHA_8，存在很大差异。
• 使用更小的图片
  尽量使用更小的图片不仅仅可以减少内存的使用，还可以避免出现大量的InflationException。假设有一张很大的图片被XML文件直接引用，很有可能在初始化视图的时候就会因为内存不足而发生InflationException，这个问题的根本原因其实是发生了OOM。
• 实现对象的复用
  LRU缓存

ANR分析

避免ANR的核心西路是不要在主线程做耗时操作，ANR在activity中的规定出现时限是5秒，在广播中是10秒
出现原因有主线程无法响应触摸或者用户输入，线程之间等待死锁等等。

电量优化

为了减少电量的消耗，在蜂窝移动网络下，最好做到批量执行网络请求，尽量避免频繁的间隔网络请求
合理的使用一些传感器、谨慎的使用Wake Lock
检测可以利用battery-historian

其他建议

减少对象
减少枚举
常量使用static final修饰
使用Android特有的数据结构，如SparseArray和pair他们具备更好的性能
适当使用弱引用和软引用
采用内存缓存和磁盘缓存
尽量使用静态内部类

性能优化工具

Android Device Monitor(DDMS) was deprecated in Android Studio 3.1 and removed from Android Studio 3.2,此外，SYSTrace TraceView都被AndroidProfile取代了，不过特定场景上述工具还可用

性能分析工具分两个流派：
第一个流派是 instrument。获取一段时间内所有函数的调用过程，可以通过分析这段时间内的函数调用流程，再进一步分析待优化的点。

第二个流派是 sample。有选择性或者采用抽样的方式观察某些函数调用过程，可以通过这些有限的信息推测出流程中的可疑点，然后再继续细化分析。

• TraceView属于instrument类型，试图收集某个阶段所有函数的运行信息，它希望在你并不知道哪个函数有问题的时候直接定位到关键函数；但可惜的是，收集所有信息 这个是不现实的，它的运行时开销严重干扰了运行环境.

• SYSTrace属于sample类型，它的思想很朴素，在系统的一些关键链路（比如System Service，虚拟机，Binder驱动）插入一些信息（我这里称之为Label），通过Label的开始和结束来确定某个核心过程的执行时间，然后把这些Label信息收集起来得到系统关键路径的运行时间信息，进而得到整个系统的运行性能信息。Android Framework里面一些重要的模块都插入了Label信息（Java层的通过android.os.Trace类完成，native层通过ATrace宏完成），用户App中可以添加自定义的Label，这样就组成了一个完成的性能分析系统。

在 Android Studio 3.2 的 Profiler 中直接集成了几种性能分析工具，其中：Sample Java Methods 的功能类似于 Traceview 的 sample 类型。Trace Java Methods 的功能类似于 Traceview 的 instrument 类型。Trace System Calls 的功能类似于 systrace。SampleNative (API Level 26+) 的功能类似于 Simpleperf。坦白来说，Profiler 界面在某些方面不如这些工具自带的界面，支持配置的参数也不如命令行，不过 Profiler 的确大大降低了开发者的使用门槛。

• CPU profiler 存在于Android profile中，用于分析CUP动态使用率，还可以分析函数调用关系，显示线程任务的CPU使用率，它是TraceView和SYSTrace的替代工具

• Tracer for OpenGL ES，它可以记录和分析app每一帧的绘制过程，以及列出所有用到OpenGL ES的绘制函数和耗时，所以通过Tracer for OpenGL ES我们可以很容易的看出app的每一帧是怎么画出来的。已经被Graphics API Debugger取代

• LayoutInspector 查看运行时的view结构层级，用来取代Hierarchy Viewer，同样取代了Pixel Perfect

• Network Traffic tool If you need to view how and when your app transfers data over a network, use the Network Profiler

https://developer.android.google.cn/studio/profile/monitor.html

此外，优化过程中使用低端手机更易发现瓶颈