什么是内存泄漏？

  简单理解：没有被GC ROOT直接或者间接引用的对象的内存回收掉

性能优化就得考虑使用工具进行检测，Android关于内存工具很多，要能够定位剖析问题。但是会有写场景不会覆盖到，只能发现问题的能力工具。整合下基本使用到的工具。

top/procrank
STRICTMODE(楼主没有使用过)
MAT、Finder
meminfo
LeakCanary
LeakInspector
APT（腾讯开源：https://code.csdn.net/Tencent/apt/tree/master）
Allocation Tracker
Chrome Devtool 
Systrace
Android Architecture Components

 

 

top/procrank

对于此工具来讲，需要知道几个名词含义：

VSS    Virtual Set Size       虚集合大小 
RSS    Resident Set Size      常驻集合大小 
PSS    Proportional Set Size  比例集合大小
USS    Unique Set Size        独占集合大小 

 

  RSS 与 PSS 差不多，包含进程共享内存，RSS没把共享内存大小平分到使用共享的进程上，所以所有进程的RSS相加会超过物理内存。 
  VSS是虚拟地址，它上线与进程的可访问地址有关，和当前进程的内存关系不大。 
  PSS包含进程间共享的内存，而USS不包括，进程USS相加小于物理内存大小的原因。对于PSS而言，如果A进程和B进程同时共享同一个SO库，那就平分到了A和B上，但启动A进程，B没有启动，则B的PSS曲线图会有较大的阶梯状下滑。对于USS而言，它的坑在Dalvik申请内存会有GC延时及其策略，会影响曲线波动。
  
  
  VSS >= RSS >= PSS >= USS

 

 

meminfo

 

  使用dumpsys meminfo 命令 
  用法： dumpsys meminfo options:[-a][–oom][process] 
  -h帮助信息 
  -a打印所有进程的内存信息，以及当前设备的内存概况 
  –oom 按照OOM Adj值进行排序。 
  [Process]进程名，也可以是id 
  比如：dumpsys meminfo | grep -i phone,查 phone相关进程。 
  watch -n 5 dumpsys meminfo com.android.phone 每隔5秒刷新一次

 

 

Procsatats

 

  要提到一个公式：内存负载 = PSS X 运行时长 
  内存负载在Android4.4上提出来（App在手机设备上显示一样），分为：前台，后台，缓冲负载。 
  前台，用户当前使用的，用户不关注的，内存负载不应该默认显示。 
  后台，是app行为，系统无权kill掉并回收，并非用户当前所使用，被默认展示。 
  缓冲，可以回收，内存负载不应该默认展示，没有被杀死是软件的恢复能力，是系统的责任。

 

 

DDMS

 

 

（Dalvik Debug Monitor Server）

 

  各种调试信息集合，有时延，内存，线程，cpu等各种信息展示，经常使用Heap、Allocation Tracker 和 Dump Hprof file(内存快照)。

 

Update Heap获取GC信息，当前已分配内存，当前运行的对象，所剩内存，动态虚拟机heapSize,及其分布柱状图
Allocation Tracker , 展示了500条的内存分配，相关的线程堆栈信息。申请的内存大，GC就多，GC会挂起全部线程，会导致卡顿现象。
Dump Hprof file，选中进程，进行内存快照，Android Studio上有此功能。

 

MAT

  全称：Memory Analyzer（内存分析），需要抓取Hprof文件，最简单使用ddms抓取，其次就是命令

抓取hprof命令如下(在adb shell模式下)： 

am dumpheap pid outfilePath (文件名必须为hprof)

 

 

操作：(DDMS抓取的可以直接忽略转格式问题) 
1. adb shell am dumpheap  com.android.phone   /data/local/tmp/test.hprof 
2. adb pull /data/local/tmp/test.hprof c:\test.hprof 
3. hprof-conv c:\test.hprof c:\testConv.hprof

 

Finder

Activity  获取dump的所有Activity对象 
Top Classes  对象数量或对象大小为维度来获取对象降序列表
Compare  对比两个Hprof文件内容的差别
Bitmap 获取dump的所有bitmap对象
Same Bytes 查询dump 中以byte[]类型出现并且内容重复的对象 
Singleton 查询dump中的单例

能够准确定位80%的泄漏问题 

 

LeakCanary

  – 在onDestory 时检查弱引用，使用ReferenceQueue，白名单需要写死在AndroidExcludedRefs.java中。每次得重新编译，区分系统版本。
  
  – 能识别系统泄漏，能够给出一个分析。
  
  – 需要人工修复解决内存泄漏问题 
  
  – 使用开源组件HAHA 分析(参考简书),返回一条GC链。

 

LeakInspector

  – 在onDestory 时检查弱引用，使用WeakReference,提供回调方法，能增加自定义的LOG，TRACE，DUMPSYS信息，需要在白名单以XML配置的形式存放到服务器上，不区分系统版本。
  
  –  可以进行预处理，在ondestroy里，通过反射自动修复系统泄漏。
  
  – 可以对对整个Activity的View遍历一遍，把图片所占用的内存数据释放掉，能够减少对内存的影响
  
  – 采集dump后，自动通过Magnifier上传dump文件，调用MAT命令进行分析，返回GC链。
  
  – 可以跟自动化测试无缝结合，自动化脚本执行过程中发现内存泄漏，收集dump发送到服务器上，分析，生成JSON结果。

 

JHat

  Oracle公司开发的多人协作Hprof分析工具
  
  使用命令：jhat test.prof
  
  解析prof文件，开启httpSrv服务，维护解析后的数据，默认端口7000，直接访问查询。

 

libc_malloc_deBug_leak.so库

  Android系统底层调用libc.so申请内存，而libc_malloc_deBug_leak库就是监视libc.so内部接口的调试库
  
  Native Heap 就是类内存申请部分，NDK编译出来的so文件放到系统的 /data 目录中，size字段的值就是内存大小，每一个都拥有一个申请的调用栈，根据栈后的method字段值能够知道该方法的内存偏移，使用addr2line.exe转化方法名称，注需要编译选项中加入“-Wl,-Map=xxx,map -g”

 

APT

  腾讯开源的测试工具，是DDMS的插件，能够实时监控多个app的cpu及其内存情况，以图表形式展示出来
  
  参考官方

 

GC Log

  Logcat输出的log日志，分为Dalvik Log和ART Log两种

 

Dalvik GC Log

GC 产生原因：

GC_EXPLICIT : 通过Runtime.gc()与VMRuntime.gc(),SIGUSR1触发产生GC，支持并发GC，列表滑动，动画播放，不要有这种Log，高CPU低响应时延不要人工触发GC。
GC_FOR_[M]ALLOC : 没有空闲内存空间给要分配的内存，不是并发GC，会有卡顿，尽量避免。
GC_FOR_CONCURRENT ： 当超过堆占用阀值时会触发，局部的并发GC 。
GC_BEFORE_OOM ： 在出发OOM前触发的GC，不能局部并发，耗时长，会卡顿。
GC_HPROF_DUMP_HEAP ： 在dump内存前触发GC，不能局部并发，耗时长，会卡顿。

 

  查看工具：Dalvik GC Log 绘制成图表的工具

 

ART GC Log

GC 产生原因：

GC_EXPLICIT : 通过Runtime.gc()与VMRuntime.gc(),SIGUSR1触发产生GC，支持并发GC，列表滑动，动画播放，不要有这种Log，高CPU低响应时延不要人工触发GC。
GC_FOR_[M]ALLOC : 没有空闲内存空间给要分配的内存，不是并发GC，会有卡顿，尽量避免。
GC_FOR_CONCURRENT ： 当超过堆占用阀值时会触发，局部的并发GC 。
NativeAlloc : Native内存不足以分配内存时触发。
Background : 后台GC，给后面的内存申请预留空间。

GC 类型：

Full : 跟Dalvik 的Full一样
Partial： 跟Dalvik局部GC一样，没有Zygote Heap策略
Sticky 局部中的局部GC ，上次垃圾回收后新分配的对象。

GC 的三种方式：

mark sweep : 记录全部对象，从GC ROOT中找出直接或间接的对象做标注，利用之前记录的全部对象和标注对象做对比，剩余的便是要回收的。
concurrent mark sweep :  使用mark sweep的并发GC
mark compact : 对所有活动的对象压缩到内存的一侧，另外一侧进行回收。
semispace : 把所有引用的对象从一个空间放到另外一个空间，剩余在旧空间的对象就是要直接GC掉的。

 

Allocation Tracker

  Android Studio 里打开Monitor,选择要查看的进程，选择Allocation Tracker,录制出结果按照Size排序，能够直接通过dump to source跳转到对应代码行。  

 

Chrome Devtool

  需要安装Chrome浏览器，移动端和PC端，PC 端访问Chrome://inspect ,点击调试页面下的inspect,出来开发者工具
  
  官方中文文档

 

Systrace

  Android4.1上引入的性能分析工具，能够输出各个线程的当前函数调用状态，并且可以跟当前CPU的线程运行状态、VSYNC、SurfaceFlinger等系统信息在同一时间轴上进行对比。但不是所有手机机型都能支持。
  
  SurfaceFlinger服务在每个VSYNC信号中断时调用一次，那APP显示非常流畅。
  
  如果VSYNC的上升沿SurfaceFlinger服务没有调用，那会导致丢帧。 
  （1） CPU负载过大，低端机型的单核机型上会有发生。在VSNYC中断信号处，CPU闲暇，没有执行其他进程任务时，那我们需要做进一步分析 
  （2） 应用侧没有完成绘制，应用内部处于繁忙时，查看performTraversals信息，忙于其他业务逻辑没有绘制，那看是否忙于分发响应事件。如果当前窗口视图太多，布局嵌套太深，会导致查找响应输入事件的控件耗时长，没法绘制UI。
  
  对于绘制等问题，Google添加了一些警告； 
  （1） Inefficient View alpha usage(5.1+以上才有)
  
  （2） Expensive rendering with Canvas.saveLayer()
  
  
    Canvas.saveLayer()会打断绘制过程中的渲染管道，替换使用View.LAYER_TYPE_HEARDWARE或者static Bitmaps,会让离屏缓存服用相邻两帧间的数据，避免渲染目标被切换而打断。
  
  
  （3） Path Texture Churn
  
  （4） Expensive Bitmap uploads
  
  
    Bitmaps 在硬件加速下，修改和图像的变化都会上传给GPU，如果像素总量大，会消耗GPU的较大资源，所以建议减少每帧中对图片的修改，出现调用setLayerType为LAYER_TYPE_SOFTWARE之后，此时整个屏幕变成一张图。
  
  
  （5） Inflation during ListView recycling
  
  
    没用ListView复用，造成inflate的单个Item的getView成本比较高
  
  
  （6） Inefficient ListView recycling/rebinding
  
  
    每帧的ListView recycling 耗时较长，那得看下Adapter.getView()绑定数据的时候是否存在问题
  
  
  （7） Expensive Measure/Layout pass
  
  
    Measure / Layout 耗时导致卡顿，动画时，不要触发Layout
  
  
  （8） Long View.draw()
  
  
    Draw 本身耗时比较长，避免在View 或 Drawable 的onDraw里面执行任务频繁自定义操作，特别时申请内存和绘制Bitmap.
  
  
  （9） Blocking Garbage Collection
  
  
    GC导致卡顿，就是GC for Alloc的stop the world，避免在动画的时候生成对象，尽量重用Bitmap能够避免触发GC。
  
  
  （10） Lock contention
  
  
    UI 线程锁，UI线程去使用其他线程持有的锁，检查现有UI线程锁并确认它锁住的时间长短。
  
  
  (11)  Scheduling delay
  
  
    网络I/O、磁盘I/O 等线程资源争抢，导致有一定时间的UI线程实际耗时长，而卡顿，检查后台线程是否都云溪nag在低优先级的线程上（是否比Thread_Priority_background还低）。
  

 

Android Architecture Components

  Android 架构组件
  
  存储数据，管理生命周期，模块化，避免常见错误，减少样板文件
  
  
    Lifecycles
  
  
  每个 Android 开发者都应该面对过生命周期问题，即操作系统启动、停止和销毁 Activity。这意味着开发者需要根据生命周期的不同阶段，有针对性地管理组件状态，比如用于更新用户界面的可观察对象。生命周期管理（Lifecycles）帮助开发者创建 “可感知生命周期的” 组件，让其自己管理自己的生命周期，从而 减少内存泄露 和崩溃的可能性。生命周期库是其他架构组件（如 LiveData）的基础。
  
  
    LiveData     
  
  
  LiveData 是一款基于观察者模式的可感知生命周期的核心组件。一种可观测数据容器，它会在数据变化时通知观测器，以便更新界面。
  
  LiveData 为界面代码 （Observer）的监视对象 （Observable），当 LiveData 所持有的数据改变时，它会通知相应的界面代码进行更新。同时，LiveData 持有界面代码 Lifecycle 的引用，这意味着它会在界面代码（LifecycleOwner）的生命周期处于 started 或 resumed 时作出相应更新，而在 LifecycleOwner 被销毁时停止更新。通过 LiveData，开发者可以方便地构建安全性更高、性能更好的高响应度用户界面。
  
  有两个对应接口，LifecycleOwner和LifecycleObserver; 
  LifecycleOwner是具有生命周期的对象，比如Activity和Fragment. 
  LifecycleObserver观测LifecycleOwner,并在生命周期变化时收到通知。
  
  
    ViewModel     
  
  
  ViewModel 将视图的数据和逻辑从具有生命周期特性的实体（如 Activity 和 Fragment）中剥离开来。直到关联的 Activity 或 Fragment 完全销毁时，ViewModel 才会随之消失，也就是说，即使在旋转屏幕导致 Fragment 被重新创建等事件中，视图数据依旧会被保留。ViewModels 不仅消除了常见的生命周期问题，而且可以帮助构建更为模块化、更方便测试的用户界面。
  
  
    Room
  
  
  一款简单好用的SQL对象映射库。它和 SQLite 有一样强大的功能，但是节省了很多重复编码的麻烦事儿。它的一些功能，如编译时的数据查询验证、内置迁移支持等，更简单地构建健壮的持久层。而且 Room 可以和 LiveData 集成在一起，提供可观测数据库并感知生命周期的对象。Room 集简洁、强大和可靠性为一身，在管理本地储存上表现卓越。
  
  
    PagedList
  
  
  解决用 RecyclerView 处理大数据集的困难。
  
  App 架构指南 
  Android 架构组件官网

 

 

参考博客地址：

开源项目之LeakCanary源码分析： http://www.jianshu.com/p/5032c52c6b0a

查找并修复Android中的内存泄露—OutOfMemoryError： 
https://yq.aliyun.com/articles/40294

内存分析工具 MAT 的使用 ：  
http://blog.csdn.net/aaa2832/article/details/19419679

Android 查看内存使用工具 (procstats)： 
http://blog.csdn.net/vshuang/article/details/51755756

Android进程内存统计工具procstats： 
https://wenku.baidu.com/view/c8d49549b90d6c85ed3ac63b.html
--------------------- 
作者：jink_l 
来源：CSDN 
原文：https://blog.csdn.net/superloveboy/article/details/78536750 
版权声明：本文为博主原创文章，转载请附上博文链接！