版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/weixin_38515203/article/details/83067217
第六章：App 背后的故事——性能检测与分析工具
《Android群英传：神兵利器》个人读书笔记，仅做学习记录之用
[TOC]
6.1 性能优化之前
6.2 Google 的技术指导
6.3 UI 性能分析
- UI 性能的目标：
1、减少绘图的等待时间
2、使帧率更加平稳、连贯
6.3.1 16ms 黄金准则
- Android 设备的屏幕刷新频率为 60 帧每秒，要使画面流畅就需要让每一帧的时间不超过 1/60fps=16.6ms 每帧。
6.3.2 Android 系统对 UI 的提升
- UI 性能的发展：
1、软解时代：Android2.3，所有绘图由 CPU 完成，即通过软件运算画图
2、硬解时代：Android2.3之后，Android 系统增加了 GPU，绘图开始由 GPU 进行渲染
3、黄油时代：Android4.1之后，google 发布了 “Project Butter”——黄油计划。通过 VSYNC 垂直同步机制和多缓冲机制（three frame buffer）进一步提高绘制效率
4、异步绘制时代：Android5.0 之后系统增加了 Render Thead，即使某一帧发生延迟也不会影响下一帧的绘制
6.3.3 布局核心准则
- 布局的绘制通常分为三步：measure、layout、draw
- 核心准则：尽量使布局的 view 树扁平，降低布局的层级
- 提高 View 的使用率也是优化的关键，可以通过 include 标签进行 View 的复用
- 通过 DrawableLeft、DrawableRight 方式来组合控件等
- 最重要的还是尽可能的减少 View 的数量
6.3.4 RelativeLayout VS LinearLayout
- RelativeLayout 可以使布局更加扁平，而 LinearLayout 需要嵌套使用，在布局深度上具有优势。
- RelativeLayout 在进程测量时，需要进行多次绘制，尤其是嵌套使用的时候，耗时更为严重。
- 两者需结合实际来分析，使用 LinearLayout，层级不能太深，使用 RelativeLayout，尽量避免嵌套。
6.3.5 HierarchyViewer
- 主要是用来查看布局层级，减少不必要冗余的 View，还可以发现 Overdraw(重复的绘制)
- 官方建议使用 Android Device Monitor 来代替这个工具
6.3.6 Merge 与 ViewStub
6.3.7 图形重绘 Overdraw
6.3.8 Tracer for OpenGL
6.3.9 GPU Profiler
6.3.10 Profile GPU Rendering
6.3.11 Framestats
6.3.12 Logcat
6.3.13 traces.txt
6.3.14 Android Studio GPU Monitor
- 监测当前运行页面的渲染，并实时显示出来
6.3.15 Systrace
- 系统级的性能检测工具，可以完成一些深层次的性能检测
- Systracede 的初始化的两种方式：In DDMS、In Command Line
6.3.16 CPU 区域
6.3.17 SufaceFlinger
6.3.18 应用区域
6.3.19 Alert
6.4 Traceview
- Android 平台下的数据采集工具，可以得到两种数据：单次执行最耗时的方法、执行次数最多的方法
6.4.1 In Source Code
Debug.startMethodTracing();
···代码···
Debug.stopMethodTracing();
- 数据会自动保存到 SDCard 目录下
6.4.2 In DDMS
6.4.3 Traceview 分析
6.4.4 图形列表
6.4.5 详细列表
6.5 应用启动时间计算
6.5.1 启动时间定义
- 一般认为 setContentView 中的 View 全部显示结束了，才算是应用启动完毕
6.5.2 ADB 计算启动时间
- 1、ThisTime：最后一个启动的 Activity 的启动耗时
2、TotalTime：所有 Activity 的启动耗时
3、WatiTime：ActivityManagerService 启动 App 的 Activity 时的总时间（包括当前 Activity 的 onPause() 和自己 Activity 的启动） - 过程分解：
1、上一个 Activity 的 onPause()
2、系统调用 AMS 耗时
3、第一个 Activity(也许是闪屏页)耗时
4、第一个 Activity 的 onPause() 耗时
5、第二个 Activity 的启动耗时
ThisTime：5、TotalTime：3、4、5的总耗时、WatiTime：1、2、3、4、5的总耗时 - 使用脚本多次重复应用“启动——Kill——启动”，取平均值
6.5.3 使用相机分析
6.6 内存探究
- 开发者管理、优化内存的核心准则：
1、在对象不需要的时候，确保对象能够被销毁
2、如果对象没有被销毁，则该对象一定是作为可复用的对象，而不是存在多个。
6.6.1 内存区分
- 寄存器 Registers：用于存储指令、地址、数据
栈 Stack：存放基本类型的数据、对象的引用和函数地址等，由系统控制
堆 Heap：存放对象本身和数组，由开发者控制
静态域 static field：存储静态变量
常量池 constant pool：存储常量
| 堆/栈 | GC 管理 | 存取速度 |
|---|---|---|
| 堆 | 由 GC 系统控制。变量生命周期结束后，由 GC 系统决定何时回收 | 慢 |
| 栈 | 由虚拟机控制。变量生命周期结束后，由虚拟机释放该变量占用的内存空间 | 快 |
- 常用内存类型：
1、VSS-Virtual Set Size：虚拟耗用内存（包含共享库占用的内存）
2、RSS-Resident Set Size：实际使用物理内存（包含共享库占用的内存）
3、PSS-Porportional Set Size：实际使用物理内存（比例分配共享库占用的内存）
4、USS-Unique Set Size：进程独自占用的物理内存（不包含共享库占用的内存） - 一般来说内存占用大小：VSS ≥ RSS ≥ PSS ≥ USS
6.6.2 系统内存分析工具
6.6.3 获取内存信息
6.6.4 GC 系统
- GC 的同步与非同步：指 Android 2.3 之前的版本，GC 是会打断被 GC 的线程，遍历 Heap，而 Android 2.3 之后的版本，GC 与被 GC 的线程可以同时工作而互不影响。
- Android5.0 之后，系统第二次优化了 GC，加快了清理速度、减少了打断线程的次数。同时除了清理垃圾之外，还可以为大内存对象分配特殊的地址，方便内存碎片的整理，提高了内存使用率，同时也避免了 OOM
6.6.5 ActivityManager.MemoryInfo
- 用于封装系统级别的内存数据，包含：
1、totalMem：系统可用总内存
2、availMem：系统当前剩余内存
3、lowMemory：是否处于低内存状态
4、threshold：内存阈值
6.6.6 Dubug.MemoryInfo
- 获取单个 App 进程的内存使用情况
6.6.7 Runtime
6.6.8 获取更多内存
6.8 onLowMemory
- 是系统低内存管理系统（LMK）发出的系统警告
6.8.1 ComponentCallback
6.8.2 onTimeMemory
6.9 内存泄漏检测
- 所谓的内存泄漏，实际上是指本该被回收的内存由于某种原因，绕开了GC的回收算法，从而导致该内存被无效数据霸占，使得内存总量变小
6.10 Logcat
- 实际上是分析系统、App 性能和运行情况的重要工具
6.11 Dump Heap
6.12 Allocation Tracker
6.12.1 In Android Studio
6.12.2 In DDMS
6.13 Android Studio Memory Monitor
6.14 内存泄漏分析
- 在 Android 中并不存在所谓的内存泄漏，这里的内存泄漏是指内存没有在恰当的时候释放掉。
6.15 Memory Analysis Tool(MAT)
- 检测内存泄漏的利器。原先是 eclipse 中的一个插件，现在则是当做一个独立运行的工具，可直接下载
6.15.1 准备Dump Heap文件
6.15.2 分析
6.16 LeakCanary
- Square 的杰作
6.16.1 引用LeakCanary
debugCompile(name: 'leakcanary-android-1.3', ext: 'aar')
releaseCompile(name: 'leakcanary-android-no-op-1.3', ext: 'aar')
一个 debug 一个 release，由于强大的 Gradle ,使得 LeakCanary 可以在 debug 模式中正常工作。而在 release 版本中完全不开启检测功能，同时整个切换过程不需要修改一行代码。
6.16.2 初始化LeakCanary
- 在应用的 application 的 onCreate() 中
@Override
public void onCreate()
{
super.onCreate();
LeakCanary.install(this);
}
6.16.3 检测
- 在 launcher 中会生成一个图标入口——Leaks，点击进入即可看到对应时间点的 Leaks 信息。
6.17 CPU Performance
- 优化 CPU 有两个直接的提升：1、优化耗电；2、提升 App 的使用体验，特别是动画效果、视屏编解码等
6.18 Top
6.18.1 总览
6.18.2 详细
6.19 Show CPU Usage
6.20 Android Studio CPU Monitor
6.21 Method Tracing
6.22 BatteryPerformance
6.22.1 电量消耗计算
6.22.2 耗电元凶
- 1、Wakelocks——Android 中的耗电大户，一定要保证在何时的时机调用，其他时间必须严格禁止
2、AlarmManager——虽由系统托管，但过多的 Alarm 会造成系统频繁唤醒，从而造成耗电
3、轮询——在有些程序中，为了实现某些监听，经常会在后台执行轮询操作，它会让 CPU 无法正常进入休眠而持续的保持着高耗能
4、频繁的网络请求——一个 App 应该在何时的时间发起网络请求，同时使用缓存等方式，尽量减少网络的消耗
5、长时间的 CPU 占用——CPU 计算会消耗非常多的电量。如果一个 App 的算法缺陷、设计缺陷，导致其 CPU 占用率一直维持着比较高的水平，那么一定会非常耗电
6.22.3 电量分析
- Battery Historian
6.23 综合测试工具
- 网易 Emmagee——主要用于监控单个App的CPU，内存，流量，启动耗时，电量，电流等性能状态的变化
- 腾讯 GT
- Google AnotherMonitor
6.24 Android Device Monitor
6.24.1 Threads
6.24.2 System Information
6.25 高通性能工具
6.25.1 Trepn Profiler
6.25.2 App Tune-up Kit
6.26 云测平台
- 阿里：阿里云测
- 腾讯：腾讯优测
- Testin
- 上述测试平台大体功能相同：
1、兼容性测试：通过大量真机覆盖大部分机型
2、压力测试：通过脚本实现压力测试
3、缺陷分析：通过代码静态扫描和测试中发生的 ANR、Crash 等提供应用的缺陷分析、
4、性能测试：在测试中监控应用性能等数据
5、远程真机租用：用户可以远程访问 DeviceLab 中的真机，并通过远程控制的方式进行使用
这章节主要介绍 App 性能检测相关的内容，主要是一些工具的使用。整理的很是完善，推荐阅读