1. Android 内存空间不足会引发的问题
- PSS : Proportional Set Size 实际使用的物理内存（比例分配共享库占用的内存）PSS相对于RSS计算共享库内存大小是按比例的。N个进程共享，该库对PSS大小的贡献只有1/N
- VSS : Virtual Set Size 虚拟耗用内存（包含共享库占用的内存）,即单个进程全部可访问的地址空间，其大小可能包括还尚未在内存中驻留的部分。对于确定单个进程实际内存使用大小，VSS用处不大。
- RSS : Resident Set Size 实际使用物理内存（包含共享库占用的内存）,即单个进程实际占用的内存大小，RSS不太准确的地方在于它包括该进程所使用共享库全部内存大小。对于一个共享库，可能被多个进程使用，实际该共享库只会被装入内存一次。
- USS : Unique Set Size 进程独自占用的物理内存（不包含共享库占用的内存）即单个进程私有的内存大小，即该进程独占的内存部分。USS揭示了运行一个特定进程在的真实内存增量大小。如果进程终止，USS就是实际被返还给系统的内存大小。
- 一般情况下有：VSS >= RSS >= PSS >= USS。
1.1 异常
内存造成的第一个问题是异常。异常包括 OOM、内存分配失败这些崩溃，也包括因为整体内存不足导致应用被杀死、设备重启等问题。
1.2 卡顿
APP: 内存造成的第二个问题是卡顿。Java 内存不足会导致频繁 GC，GC 会 stop the world, 严重的会导致掉帧，卡顿。
系统层面：除了频繁 GC 造成卡顿之外，物理内存不足时系统会触发 low memory killer 机制，系统负载过高是造成卡顿的另外一个原因。
android 60ps, 16ms 绘制一帧画面，卡顿会延长这个时间
这个问题在 Dalvik 虚拟机会更加明显。而 ART 虚拟机在内存管理跟回收策略上都做大量优化，内存分配和 GC 效率相比提升了 5～10 倍。如果想具体测试 GC 的性能，例如暂停挂起时间、总耗时、GC 吞吐量，我们可以通过发送 SIGQUIT 信号获得 ANR 日志。
- adb shell kill -S QUIT PID
- adb pull /data/anr/traces.txt
它包含一些 ANR 转储信息以及 GC 的详细性能信息。
- sticky concurrent mark sweep paused: Sum: 5.491ms 99% C.I. 1.464ms-2.133ms Avg: 1.830ms Max: 2.133ms // GC 暂停时间
Total time spent in GC: 502.251ms // GC 总耗时
Mean GC size throughput: 92MB/s // GC 吞吐量
Mean GC object throughput: 1.54702e+06 objects/s
1.3 从 Java 堆内存超限这个问题开始
主要有两类问题：
-
堆内存单次分配过大多次分配累计过大。
- 触发这类问题的原因有数据异常导致单次内存分配过大超限，也有一些是 StringBuilder 拼接累计大小过大导致等等。这类问题的解决思路比较简单，问题就在当前的堆栈。
-
堆内存累积分配触顶。
- 这类问题的问题堆栈会比较分散，在任何内存分配的场景上都有可能会被触发，那些高频的内存分配节点发生的概率会更高，比如 Bitmap 分配内存。这类 OOM 的根本原因是内存累积占用过多，而当前的堆栈只是压死骆驼的最后一根稻草，并不是问题的根本所在。所以这类问题我们需要分析整体的内存分配情况，从中找到不合理的内存使用（比如内存泄露、大对象、过多小对象、大图等）。
- Facebook 有一个叫 device-year-class 的开源库，它会用年份来区分设备的性能
2. 内存优化着手点
一个原则： 用时分配，及时释放
adb shell dumpsys meminfo <package_name|pid> [-d]
2.1 检测 RAM usage
2.2 进程
- 减少应用启动的进程数、减少常驻进程、有节操的保活，对低端机内存优化非常重要
不适用于我们 app
2.3 安装包大小
- 安装包中的代码、资源、图片以及 so 库的体积，跟它们占用的内存有很大的关系。一个 80MB 的应用很难在 512MB 内存的手机上流畅运行。这种情况我们需要考虑针对低端机用户推出 4MB 的轻量版本，例如 今日头条极速版都是这个思路
2.4 Bitmap 优化
统一的图片库
2.5 内存泄漏
内存泄漏简单来说就是没有回收不再使用的内存
内存泄漏主要分两种情况，一种是同一个对象泄漏，还有一种情况更加糟糕，就是每次都会泄漏新的对象，可能会出现几百上千个无用的对象。
很多内存泄漏都是框架设计不合理所导致，各种各样的单例满天飞，View、Activity 被生命周期远远大于它的对象引用（eg: handler）。
优秀的框架设计可以减少甚至避免程序员犯错，当然这不是一件容易的事情，所以我们还需要对内存泄漏建立持续的监控
2.5.1 Java 内存泄漏
eg: LeakCanary 自动化检测方案，可以做到 Activity、Fragment、View、ViewModel 和 Service 的泄漏检测。在开发过程，我们希望出现泄漏时可以弹出对话框，让开发者更加容易去发现和解决问题。
我们首先要问清楚自己几个问题，比如我们要优化到什么目标、内存对我们造成了多少异常和卡顿。只有在明确了应用的现状和优化目标后，我们才能去进行下一步的操作。
-
造成了多少异常和卡顿：应用性能接入框架: Tencent/matrix
-
Android 内存泄漏检测框架：LeakCanary
-
Android 线上内存检测：KOOM
3. Android 内存监控相关的开源库
3.1 开源库简介
- bytedance Rhea – 全能型性能分析工具
- 优点：
- 1、使用灵活，不依赖 PC 抓取脚本，同时支持线上线下多种模式和配置开关；
- 2、支持采集和追踪包括不限层级 ATrace 函数耗时插桩、等锁信息、I/O 信息以及 Binder 耗时等在内的多种信息；
- 3、兼容性高，支持 API 16~30 全机型的 trace 抓取；
- 4、零侵入代码，通过 gradle 完成插件全部配置，无任何代码直接调用。
- 缺点：native 支持不足, 计划开源但暂未开源
- 优点：
- bytedance MemoryLeakDetector – native 内存泄漏监控工具
- 接入简单、监控范围广、性能优良、 稳定性好的特点
- bytedance Tailor – 通用内存快照裁剪压缩工具
- 通过它可以在异常时直接dump出一个迷你内存快照。快照中没 有任何敏感信息，更重要的是文件非常小的同时数据也相对完整，非常适合离线分析OOM及其他类型异常的调查定位
- KOOM——高性能线上内存监控方案
- 利用Copy-on-write机制fork子进程dump
- 优点：速度快，不会阻塞主线程；文件极小，只是个json文件
- 内存监控组件 定时采集内存资源占用情况，超过阈值触发内存镜像采集，决定镜像dump与分析时机，关键代码参考Monitor.java，主要针对 OOM 问题
- 内存镜像采集组件 高性能内存镜像采集组件，包含fork dump和strip dump两个部分，关键代码参考HeapDumper.java，
Java内存部分在LeakCanary的基础上进行了大量优化，解决了线上内存监控的性能问题，在不影响用户体验的前提下线上采集内存镜像并解析 - 内存镜像解析组件 高性能内存镜像解析组件，基于shark解析器定制优化，泄露判定关键代码参考LeakDetector.java ，解决的是 解决dump过程中app长时间冻结的问题
3.2 内存泄漏检测方案对比
616
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
