a284628487
commented
6 years ago Android内存回收原则: 当它确定您的应用不再使用某些对象时，垃圾回收器会将未使用的内存释放回堆中。Android系统在进行垃圾回收时，都必须在某个时间点短暂地暂停您的代码。大多数情况下，这些暂停难以察觉。 不过，如果应用分配内存的速度比系统回收内存的速度快，则当收集器释放足够的内存以满足应用的内存分配需要时，应用可能会延迟。此延迟可能会导致应用跳帧，并使系统明显变慢。
如果存在内存泄漏，则即使应用在后台运行也会保留该内存。此行为会强制执行不必要的垃圾回收Event，因而拖慢系统的内存性能。 最后，系统被迫终止您的应用进程以回收内存。然后当用户返回您的应用时，它必须完全重启。
使用 Memory Profiler 执行以下操作：
- 在时间线中查找可能会导致性能问题的不理想的内存分配模式。
- 转储 Java 堆以查看在任何给定时间哪些对象耗尽了使用内存。长时间进行多个堆转储可帮助识别内存泄漏。
- 记录正常用户交互和极端用户交互期间的内存分配以准确识别您的代码在何处短时间分配了过多对象，或分配了泄漏的对象。
查看内存分配
选中Memory区域点击并拖动一个区域，则该时间线内的内存使用情况，将自动分类显示出来。
- 分配哪些类型的对象以及它们使用多少空间。
- 每个分配的堆叠追踪，包括在哪个线程中。
- 对象在何时被取消分配（仅当使用运行 Android 8.0 或更高版本的设备时）。
按以下步骤操作检查分配记录：
- 浏览列表以查找堆计数异常大且可能存在泄漏的对象。为帮助查找已知类，点击 Class Name 列标题以按字母顺序排序。然后点击一个类名称。此时在右侧将出现 Instance View 窗格，显示该类的每个实例。
- 在 Instance View 窗格中，点击一个实例。 此时下方将出现 Call Stack 标签，显示该实例被分配到何处以及哪个线程中。
- 在 Call Stack 标签中，点击任意行以在编辑器中跳转到该代码。
捕获堆转储
堆转储显示在您捕获堆转储时您的应用中哪些对象正在使用内存。特别是在长时间的用户会话后，堆转储会显示您认为不应再位于内存中却仍在内存中的对象，从而帮助识别内存泄漏。 在捕获堆转储后，您可以查看以下信息：
- 应用已分配哪些类型的对象，以及每个类型分配多少。
- 每个对象正在使用多少内存。
- 在代码中的何处仍在引用每个对象。
- 对象所分配到的调用堆栈。
将堆转储另存为 HPROF
在捕获堆转储后，仅当分析器运行时才能在 Memory Profiler 中查看数据。如果需要保存堆转储以供日后查看，可通过点击时间线下方工具栏中的 Export heap dump as HPROF file，将堆转储导出到一个 HPROF 文件中。然后，通过将此文件拖到一个空的编辑器窗口（或将其拖到文件标签栏中），可以在 Android Studio 中重新打开该文件。
要使用其他 HPROF 分析器（如 jhat），您需要将 HPROF 文件从 Android 格式转换为 Java SE HPROF 格式。 您可以使用 android_sdk/platform-tools/ 目录中提供的 hprof-conv 工具执行此操作。 运行包括以下两个参数的 hprof-conv 命令：原始 HPROF 文件和转换后 HPROF 文件的写入位置。 例如： hprof-conv heap-original.hprof heap-converted.hprof
分析内存的技巧
使用 Memory Profiler 时，应对应用代码施加压力并尝试强制内存泄漏。在应用中引发内存泄漏的一种方式是，先让其运行一段时间，然后再检查堆。 泄漏在堆中可能逐渐汇聚到分配顶部。 不过，泄漏越小，越需要运行更长时间的应用才能看到泄漏。
还可以通过以下方式之一触发内存泄漏：
- 将设备从纵向旋转为横向，然后在不同的 Activity 状态下反复操作多次。 旋转设备经常会导致应用泄漏 Activity、Context 或 View 对象，因为系统会重新创建 Activity，而如果您的应用在其他地方保持对这些对象之一的引用，系统将无法对其进行垃圾回收。
- 处于不同的 Activity 状态时，在您的应用与另一个应用之间切换（导航到主屏幕，然后返回到您的应用）。
Android-Profiler: https://developer.android.com/studio/profile/android-profiler