APP性能优化

App优化

#App性能表现差
1.App启动慢、卡顿、丢帧
2.内存占用高、抖动频繁
3.耗电、网络请求慢
4.崩溃率、异常率高

App启动优化

启动分类

App startup time：

冷启动 ：耗时最多，衡量标准
		Click Event -> IPC -> Process.start -> ActivityThread -> bindApplication -> LifeCycle -> ViewRootImpl
		
热启动 ：最快
		后台 -> 前台
		没有各种Application的创建，没有各种生命周期的调用，所以最快
温启动 ：较快
		LifeCycle
		只会重走ACtivity的生命周期，而不会重走进程的创建、Application的创建和生命周期等。

优化方向

Application和Activity生命周期

	启动时间的测量方式：
	 1.adb命令
	 		adb shell am start -W packagename/首屏Activity
	2. 手动打点
		 启动时埋点，启动结束埋点，二者差值
		 误区：onWindowFocusChanged只是首帧时间
		 正解：真实数据展示，Feed第一条数据
![在这里插入图片描述](https://img-blog.csdnimg.cn/20190604105001507.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mzk1NTIwOQ==,size_16,color_FFFFFF,t_70)

在这里我是用RecuclerView展示数据的，在adapter的回调onBindViewHolder方法中

回到MainAcctivity中，复写onWindowFocusChanged方法

运行程序，时间输出

手动打点比较精确，可带上线上，推荐使用。
一定要避开误区，采用Feed第一条数据展示
addOnDrawListener要求API16

启动优化工具选择(两种方式互相 补充，正确认识工具及不同场景选择合适的工具)

traceview(图形的形式展示执行时间、调用栈等，信息全面，包含所有线程)
使用方式
	Debug.startMethodTracing("");
	Debug.stopMethodTracing("");
	生成文件在sd卡：Android/data/packagename/files	 	
systrace(结合Android内核的数据，生成Html报告；API18以上使用，推荐TraceCompat)
	轻量级，开销小；直观反映cpu利用率

App内存优化

常见内存问题：
内存抖动：锯齿状、GC导致卡顿
内存泄漏：可用内存减少、频繁GC
内存溢出：OOM、程序异常

优化工具选择：
Memory Profiler
Memory Analyzer
LeakCanary

MemoryProfiler：
实时图表展示应用内存使用量
识别内存泄漏、抖动等
提供捕捉堆转储、强制GC以及跟踪内存分配的能力
Memory Analyzer
强大的Java Heap分析工具，查找内存泄漏及内存占用
生成整体报告、分析问题等
线下深入使用
LeakCanary
自动内存泄漏检测
https://github.com/square/leakcanary
线下集成

Java内存管理机制
方法区(java类信息、常量、静态变量等，所有线程共享)、虚拟机栈(局部变量表和操作数栈等，为java方法来服务的)、本地方法栈(为native方法来服务的)、堆(共享，每个对象的实际分配内存都是在堆上分配的)、程序计数器。
Java内存回收算法
标记-清除算法
1.标记出所有需要回收的对象
2.统一回收所有被标记的对象
白色区域表示现在那些内存是可用的；蓝色区域表示这个内存被分配了，但是这些对象需要存活；灰色区域表示这些内存被 分配了，但是这块区域现在可以被回收掉。
这种算法标记和清除效率不高而且会产生大量不连续的内存碎片。

复制算法
1.将内存划分为大小相等的两块
2.一块内存用完之后复制存活对象到另一块
3.清理另一块内存

复制算法实现简单，运行高效。 浪费一半空间，代价大。

标记-整理算法
1.标记过程与“标记-清除”算法一样
2.存活对象往一端进行移动
3.清理其余内存

避免标记-清理导致的内存碎片，避免复制算法的空间浪费。

分代收集算法
1.结合多种收集算法优势
2.新生代对象存活率低，复制
3.老年代对象存活率高，标记-整理

Android内存管理机制
内存弹性分配，分配值与最大值受具体设备影响
OOM场景：内存真正不足、可用内存不足

  Dalvik与ART的区别
  	Dalvik仅固定一种回收算法
  	ART回收算法可运行期选择
  	ART具备内存整理能力，减少内存空间
  Low Memory Killer（针对所有进程，如果设备内存不足的情况下，它会针对所有进程回收）
  	进程分类（前台进程、可见进程、服务进程、后台进程、空进程）优先级从高到底
  	回收收益

内存抖动解决实战
内存抖动介绍
定义:内存频繁分配和回收导致内存不稳定
表现：频繁GC、内存曲线呈锯齿状
危害：导致卡顿、OOM
内存抖动导致OOM
频繁创建对象，导致内存不足及碎片（不连续）
不连续的内存片无法被分配，导致OOM

	  解决内存抖动：
	  		使用Memory Profiler初步排查
	  		使用Memory Profiler或CPU Profiler结合代码排查
	  		模拟内存抖动
			![运行代码](https://img-blog.csdnimg.cn/20190623202511687.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mzk1NTIwOQ==,size_16,color_FFFFFF,t_70)
	  		![运行后的情况](https://img-blog.csdnimg.cn/20190623202612451.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mzk1NTIwOQ==,size_16,color_FFFFFF,t_70)
	  		Recored ->stop后
	  		![](https://img-blog.csdnimg.cn/20190623202717262.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mzk1NTIwOQ==,size_16,color_FFFFFF,t_70)
	  		![点击jump后，跳转到对应的代码，具体到哪一行](https://img-blog.csdnimg.cn/20190623202855975.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mzk1NTIwOQ==,size_16,color_FFFFFF,t_70)
	  内存抖动解决技巧
	  		找循环或者频繁调用的地方。

内存泄漏解决实战
内存泄漏介绍
定义：内存中存在已经没有用的对象
表现：内存抖动、可用内存逐渐变少
危害：内存不足、GC频繁、OOM
Memory Analyzer工具
下载地址：https://www.eclipse.org/mat/downloads.php
转换：hprof-conv原文件路径转换后文件路径



ARTHook优雅检测不合理图片
Bitmap内存模型
API10之前Bitmap自身在Dalvik Heap中，像素在Native
API10之后像素也被放在Dalvik Heap中
API26之后像素在Native
获取Bitmap占用内存
getByteCount
宽高一像素占用内存

常规方式
ARTHook实战