本文目录：
一、性能测试
1.内存消耗 2.CPU占用 3.帧率GPU 4.流量消耗 5.电量消耗
二、性能优化
1.卡顿优化 2.耗电优化 3.安装包大小优化 4.内存优化 5.稳定性优化
一、性能测试
1、内存消耗
1.1 使用Android Profiler
1.2 使用adb
输入命令：adb shell dumpsys meminfo PackageName
1.3 使用Lint
Android Studio->Analyze->Inspect Code
1.4 使用MAT
1.5 使用Heap Snapshot
2、CPU占用
2.1 使用Android Profiler
3、帧率GPU
3.1 使用“GPU呈现模式分析”中的“在adb shell dumpsys gfxinfo中”选项。
① 进入Android设备的开发者选项，勾选“GPU呈现模式分析”中的“在adb shell dumpsys gfxinfo中”选项。
② 在电脑的terminal中进入<SDK目录>下的platform-tools文件夹，输入命令adb shell dumpsys gfxinfo 包名，结果如图所示
③ 参数说明
- Graphics info for pid 7821 [com.longsh1z.myapplication]
//表明当前dump的为设置界面的帧信息，pid为7821
- Total frames rendered: 15
//本次dump搜集了105帧的信息
- Janky frames: 15 (100.00%)
//15帧中有15帧的耗时超过了16ms，卡顿概率为100.00%
- Number Missed Vsync: 3
//垂直同步失败的帧
- Number High input latency: 7
//处理input时间超时的帧数
- Number Slow UI thread: 4
//因UI线程上的工作导致超时的帧数
- Number Slow bitmap uploads: 2
//因bitmap的加载耗时的帧数
- Number Slow issue draw commands: 8
//因绘制导致耗时的帧数
- HISTOGRAM: 5ms=0 6ms=0 7ms=0 ...
//直方图数据，表面耗时为0-5ms的帧数为0，耗时为5-6ms的帧数为0，同理类推。
3.2 使用“GPU呈现模式分析”中的“在屏幕上显示为条形图”选项。**
① 进入Android设备的开发者选项，勾选“GPU呈现模式分析”中的“在屏幕上显示为条形图”选项。
② 操作自己的APP，屏幕上即有相关显示。
4、流量消耗
4.1 使用adb（Linux环境下）
获取进程ID指令
adb shell ps|grep packagename
获取进程ID流量
adb shell cat /proc/pid/net/dev
4.2 使用GT（随身调，腾讯MIG内部）
5、电量消耗
5.1 使用adb
输入命令：
①adb shell dumpsys batterystats PackageName（Android 5.0后引入）
//获取单个应用的耗电量信息
②adb shell dumpsys battery
//获取设备的是否充电，电量，电压等信息
（注：后续可以用battery-historian将输出可视化）
二、性能优化
1、卡顿优化
1.1 原因
- Android系统每隔16ms会发出VSync信号，触发对UI的渲染。所以如果每一帧的绘制时间过长或者主线程太忙，导致VSync信号到来时数据还没准备好，那么两帧的时间内还是显示的同一帧的内容，就会给人卡顿的感觉。
- 举个形象一点的例子，在我们上学的时候我们每天都要交作业，那么我们未能按时完成作业的原因有哪些呢？其实无外乎两种：一种是作业太多，我们在一天内完不成；另一种就是其他事情占用太多时间了，要交作业的时候我们还没能完成。
1.2 优化方案
1.2.1 UI优化：
- 尽量避免多层布局嵌套，使用RelativeLayout
- 在布局层级相同的情况下，优先用LinearLayout
- 将可复用的组件抽取出来并通过<include>标签使用
- 使用<merge>标签减少布局的嵌套层次
- 使用<ViewStub>标签加载一些不常用的布局
- 删除控件中没用的属性
- 尽量避免过度绘制，比如背景经常容易造成过度绘制。由于我们布局设置了背景，同时用到的Material Design的主题会默认给一个背景，这时候应该把主题添加的背景去掉。
- 移除XML文件中非必须的背景。
1.2.2 启动优化：
- 以大化小进行分步加载，耗时操作异步加载，非必需的数据延时加载。
1.2.3 刷新机制合理化
- 尽量减少刷新次数
- 尽量避免后台有高CPU线程运行
- 缩小刷新区域。
2、耗电优化
2.1 原因
在 Android 平台上，由于应用程序可以无限制地注册系统事件（BroadcastReceiver），在这些事件中被不停地唤醒，即使应用已经退到后台，做了很多毫无必要的事情，却导致电量消耗。因此，应用开发者在实现需求的同时，需要尽量减少电量的消耗。
2.2 优化方案
- 合理的使用wake_lock锁。
- 使用jobScheduler2集中处理一些网络请求，有些不用很及时的处理可以放在充电的时候处理，比如图片的处理，APP下载更新等。
- 计算优化，避开浮点运算。
- 数据在网络上传输时，尽量压缩数据后再传输。
- 使用效率高的数据格式和解析方法，建议用FlatBuffer序列化技术，这个比json效率高很多倍。
- 使用Wi-Fi传输数据时，应尽可能增大每个包的大小（不超过MTU）并降低发包的频率。
- 尽量在Wi-Fi环境下使用数据传输。
- 在蜂窝移动网络下，最好做到批量执行网络请求，尽量避免频繁的间隔网络请求，尽量多地保持在Radio Standby状态。
3、安装包大小优化
3.1 原因
应用的安装包越大，用户下载的门槛越高，特别是在移动网络情况下，所以减小安装包大小可以让更多的用户愿意下载和体验产品。
3.2 优化方案
3.2.1 代码混淆优化
- 使用ProGuard设置minifyEnabled 为true。
3.2.2 res资源优化
- 使用Android Lint删除冗余资源。
- 尽量使用一套图片资源，遇到一些图片在不同分辨率手机上变化差异过大的情况时，再考虑在响应文件夹下放入这个特定的图片。
- 使用一套图、一套布局、多套dimens.xml文件，在使用最小资源的情况下，解决多分辨率适配。
- 使用轻量级的第三方库。
- 减少项目中的预置图片，预置图片改成有服务器下发，尽可能的将程序与资源分离。
- 使用WebP格式的图片。
3.2.3 代码优化
- 实现功能模块的逻辑简化。
- 移除无用的依赖库。
3.2.4 lib资源优化
- 一些模块的插件化动态添加。
- so文件的剪裁和压缩。
3.2.5 assets资源优化
- 音频文件最好使用有损压缩的格式，比如采用opus、mp3等格式，但是最好不要使用无损压缩的音乐格式。
4、内存优化
4.1 原因
在 Android 系统中有个垃圾内存回收机制，在虚拟机层自动分配和释放内存，因此不需要在代码中分配和释放某一块内存，从应用层面上不容易出现内存泄漏和内存溢出等问题，但是需要内存管理。Android 系统在内存管理上有一个 Generational Heap Memory 模型，内存回收的大部分压力不需要应用层关心， Generational Heap Memory 有自己一套管理机制，当内存达到一个阈值时，系统会根据不同的规则自动释放系统认为可以释放的内存，也正是因为 Android 程序把内存控制的权力交给了 Generational Heap Memory，一旦出现内存泄漏和溢出方面的问题，排查错误将会成为一项异常艰难的工作。除此之外，部分 Android 应用开发人员在开发过程中并没有特别关注内存的合理使用，也没有在内存方面做太多的优化，当应用程序同时运行越来越多的任务，加上越来越复杂的业务需求时，完全依赖 Android 的内存管理机制就会导致一系列性能问题逐渐呈现，对应用的稳定性和性能带来不可忽视的影响，因此，解决内存问题和合理优化内存是非常有必要的。
4.2 优化方案
4.2.1 内存泄漏优化
- 单例模式中传入的this来源于activity所引起的内存泄漏，可以使用context.getApplicationContext代替。
- Handler引起的内存泄漏。message会持有handler的引用，而非静态内部类的handler会持有外部类activity的引用，这样activity被销毁了但是handler中还有message存在，activity的引用未能及时释放从而造成内存泄漏。可以将handler改为静态内部类，同时activity用弱引用。
- AsyncTask或线程引起的内存泄漏，匿名内部类AsyncTask或Thread会持有外部类activity的引用，activity被销毁了，AsyncTask或者线程还未结束从而引起的内存泄漏。可以将AsyncTask和Thread独立出来或者使用静态内部类，同时activity用弱引用。
- 资源未及时关闭引起的内存泄漏，需要及时关闭cursor，广播接收器、网络连接等资源。
4.2.2 其他优化
- 减少不必要的内存开销。注意自动装箱，增加内存复用，比如有效利用系统自带的资源、视图复用、对象池、Bitmap对象的复用。
- 使用最优的数据类型。比如针对数据类容器结构，可以使用ArrayMap数据结构，避免使用枚举类型，使用缓存Lrucache等等。
- 图片内存优化。可以设置位图规格，根据采样因子做压缩，用一些图片缓存方式对图片进行管理等等。
5、稳定性优化
5.1 原因
Android 应用的稳定性定义很宽泛，影响稳定性的原因很多，比如内存使用不合理、代码异常场景考虑不周全、代码逻辑不合理等，都会对应用的稳定性造成影响。其中最常见的两个场景是：Crash 和 ANR，这两个错误将会使得程序无法使用。
5.2 优化方案
- 提高代码质量。比如开发期间的代码审核，看些代码设计逻辑，业务合理性等。
- 代码静态扫描工具。常见工具有Android Lint、Findbugs、Checkstyle、PMD等等。
- Crash监控。把一些崩溃的信息，异常信息及时地记录下来，以便后续分析解决。
- Crash上传机制。在Crash后，尽量先保存日志到本地，然后等下一次网络正常时再上传日志信息。
