内存泄露检测工具（android性能测试工具有哪些）

本文目录

• android性能测试工具有哪些
• android手机测试中如何查看内存泄露
• Windows 下有哪些内存泄露监测工具
• 如何使用工具进行C/C++的内存泄漏检测
• 如何检测C++的内存泄漏，用哪些工具
• sanitizer 内存泄露检查工具的使用
• 如何用VS工具检测内存泄露
• 怎么排查这些内存泄漏
• 如何在Android Studio中使用LeakCanary检测内存泄露
• 如何检查内存泄露问题

android性能测试工具有哪些

有如下几个工具：android针对上面这些会影响到应用性能的情况提供了一些列的工具：1 布局复杂度：hierarchyviewer：检测布局复杂度，各视图的布局耗时情况：Android开发者模式—GPU过渡绘制：2 耗电量：Android开发者模式中的电量统计；3 内存：应用运行时内存使用情况查看：Android Studio—Memory/CPU/GPU；内存泄露检测工具：DDMS—MAT；4 网络：Android Studio—NetWork；5 程序执行效率：静态代码检查工具：Android studio—Analyze—Inspect Code.../Code cleanup... ，用于检测代码中潜在的问题、存在效率问题的代码段并提供改善方案；DDMS—TraceView，用于查找程序运行时具体耗时在哪；StrictMode：用于查找程序运行时具体耗时在哪，需要集成到代码中；Andorid开发者模式—GPU呈现模式分析。6 程序稳定性：monkey，通过monkey对程序在提交测试前做自测，可以检测出明显的导致程序不稳定的问题，执行monkey只需要一行命令，提交测试前跑一次可以避免应用刚提交就被打回的问题。说明：上面提到的这些工具可以进Android开发者官网性能工具介绍查看每个工具的介绍和使用说明；Android开发者选项中有很多测试应用性能的工具，对应用性能的检测非常有帮助，具体可以查看：All about your phone’s developer options和15个必知的Android开发者选项对Android开发者选项中每一项的介绍；针对Android应用性能的优化，Google官方提供了一系列的性能优化视频教程，对应用性能优化具有非常好的指导作用，具体可以查看：优酷Google Developers或者Android Performance Patterns。二 第三方性能优化工具介绍除了android官方提供的一系列性能检测工具，还有很多优秀的第三方性能检测工具使用起来更方便，比如对内存泄露的检测，使用leakcanry比MAT更人性化，能够快速查到具体是哪存在内存泄露。leakcanary：square/leakcanary · GitHub，通过集成到程序中的方式，在程序运行时检测应用中存在的内存泄露，并在页面中显示，在应用中集成leancanry后，程序运行时会存在卡顿的情况，这个是正常的，因为leancanry就是通过gc操作来检测内存泄露的，gc会知道应用卡顿，说明文档：LeakCanary 中文使用说明、LeakCanary: 让内存泄露无所遁形。GT：GT Home，GT是腾讯开发的一款APP的随身调测平台，利用GT，可以对CPU、内存、流量、点亮、帧率/流畅度进行测试，还可以查看开发日志、crash日志、抓取网络数据包、APP内部参数调试、真机代码耗时统计等等，需要说明的是，应用需要集成GT的sdk后，GT这个apk才能在应用运行时对各个性能进行检测。

android手机测试中如何查看内存泄露

如何查看内存泄露

主要有2种方法

1. 借助工具，查看。

2. 借助adb 命令来查看。

【主要原理】

借助工具来查看泄露的原因。

详细实现方式

【工具查看】

常用工具有很多例如：

1.功能强大PC端检测工具，如MemoryAnalyzer运行在PC端抓取Android手机中的dump文件进行深度分析。

2.小而优的Android端检测工具，如LeakCanary随App一起安装会在Android手机桌面安装的内存泄露检测App

详细的介绍百度里面非常多这边不做过多的介绍。

3.还有一种，要求不高的可以通过android studio查看内存变化等

【adb方式】

cmd中  敲入

adb shell dumpsys meminfo 运用包名 -d

查看的结果如下图所示：

详细看到界面，视图等占用的内存情况。

【最后】

2种方法相互使用，验证内存泄露原因。

Windows 下有哪些内存泄露监测工具

您好，很高兴为您解答。怎样检测内存泄露 ：检测内存泄漏的关键是要能截获住对分配内存和释放内存的函数的调用。截获住这两个函数，我们就能跟踪每一块内存的生命周期，比如，每当成功的分配一块内存后，就把它的指针加入一个全局的list中；每当释放一块内存，再把它的指针从list中删除。这样，当程序结束的时候，list中剩余的指针就是指向那些没有被释放的内存。这里只是简单的描述了检测内存泄漏的基本原理，详细的算法可以参见Steve Maguire的《《Writing Solid Code》》。 如果要检测堆内存的泄漏，那么需要截获住malloc/realloc/free和new/delete就可以了（其实new/delete最终也是用malloc/free的，所以只要截获前面一组即可）。对于其他的泄漏，可以采用类似的方法，截获住相应的分配和释放函数。比如，要检测BSTR的泄漏，就需要截获SysAllocString/SysFreeString；要检测HMENU的泄漏，就需要截获CreateMenu/ DestroyMenu。（有的资源的分配函数有多个，释放函数只有一个，比如，SysAllocStringLen也可以用来分配BSTR，这时就需要截获多个分配函数） 在Windows平台下，检测内存泄漏的工具常用的一般有三种，MS C-Runtime Library内建的检测功能；外挂式的检测工具，诸如，Purify，BoundsChecker等；利用Windows NT自带的Performance Monitor。这三种工具各有优缺点，MS C-Runtime Library虽然功能上较之外挂式的工具要弱，但是它是免费的；Performance Monitor虽然无法标示出发生问题的代码，但是它能检测出隐式的内存泄漏的存在，这是其他两类工具无能为力的地方。

如何使用工具进行C/C++的内存泄漏检测

Memcheck是一个内存错误检测器。它有助于使你的程序，尤其是那些用C和C++写的程序，更加准确。Cachegrind是一个缓存和分支预测分析器。它有助于使你的程序运行更快。Callgrind是一个调用图缓存生成分析器。它与Cachegrind的功能有重叠，但也收集Cachegrind不收集的一些信息Helgrind是一个线程错误检测器。它有助于使你的多线程程序更加准确。DRD也是一个线程错误检测器。它和Helgrind相似，但使用不同的分析技术，所以可能找到不同的问题。Massif是一个堆分析器。它有助于使你的程序使用更少的内存。DHAT是另一种不同的堆分析器。它有助于理解块的生命期、块的使用和布局的低效等问题。SGcheck是一个实验工具，用来检测堆和全局数组的溢出。它的功能和Memcheck互补：SGcheck找到Memcheck无法找到的问题，反之亦然。BBV是个实验性质的SimPoint基本块矢量生成器。它对于进行计算机架构的研究和开发很有用处。系统编程中一个重要的方面就是有效地处理与内存相关的问题。你的工作越接近系统，你就需要面对越多的内存问题。有时这些问题非常琐碎，而更多时候它会演变成一个调试内存问题的恶梦。所以，在实践中会用到很多工具来调试内存问题。在本文中，我们将讨论最流行的开源内存管理框架 VALGRIND。摘自 Valgrind.org：Valgrind是用于构建动态分析工具的探测框架。它包括一个工具集，每个工具执行某种类型的调试、分析或类似的任务，以帮助完善你的程序。Valgrind的架构是模块化的，所以可以容易地创建新的工具而又不会扰乱现有的结构。许多有用的工具被作为标准而提供。Memcheck是一个内存错误检测器。它有助于使你的程序，尤其是那些用C和C++写的程序，更加准确。Cachegrind是一个缓存和分支预测分析器。它有助于使你的程序运行更快。Callgrind是一个调用图缓存生成分析器。它与Cachegrind的功能有重叠，但也收集Cachegrind不收集的一些信息。Helgrind是一个线程错误检测器。它有助于使你的多线程程序更加准确。DRD也是一个线程错误检测器。它和Helgrind相似，但使用不同的分析技术，所以可能找到不同的问题。Massif是一个堆分析器。它有助于使你的程序使用更少的内存。DHAT是另一种不同的堆分析器。它有助于理解块的生命期、块的使用和布局的低效等问题。SGcheck是一个实验工具，用来检测堆和全局数组的溢出。它的功能和Memcheck互补：SGcheck找到Memcheck无法找到的问题，反之亦然。BBV是个实验性质的SimPoint基本块矢量生成器。它对于进行计算机架构的研究和开发很有用处。也有一些对大多数用户没有用的小工具：Lackey是演示仪器基础的示例工具；Nulgrind是一个最小化的Valgrind工具，不做分析或者操作，仅用于测试目的。在这篇文章我们将关注“memcheck”工具。使用 Valgrind Memcheckmemcheck工具的使用方式如下:valgrind --tool=memcheck ./a.out从上面的命令可以清楚的看到, 主要的命令是valgrind，而我们想使用的工具是通过’-tool’选项来指定的. 上面的‘a.out’指的是我们想使用memcheck运行的可执行文件.该工具可以检测下列与内存相关的问题 :未释放内存的使用对释放后内存的读/写对已分配内存块尾部的读/写内存泄露不匹配的使用malloc/new/new重复释放内存注意: 上面列出的并不很全面，但却包含了能被该工具检测到的很多普遍的问题.让我们一个一个地对上面的场景进行讨论:注意: 下面讨论的所有测试代码都应该使用gcc并且加上-g选项(用来在memcheck的输出中生成行号)进行编译. 就想我们之前讨论过的 C程序被编译成可执行文件, 它需要经历四个不同的阶段.1. 使用未初始化的内存Code :#include 《stdio.h》#include 《stdlib.h》 int main(void){char *p; char c = *p; printf("\n \n",c); return 0;}在上面的代码中，我们尝试使用未初始化的指针 ‘p’.让我们运行Memcheck来看下结果.$ valgrind --tool=memcheck ./val==2862== Memcheck, a memory error detector==2862== Copyright (C) 2002-2009, and GNU GPL’d, by Julian Seward et al.==2862== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info==2862== Command: ./val==2862====2862== Use of uninitialised value of size 8==2862== at 0x400530: main (valgrind.c:8)==2862====2862====2862== HEAP SUMMARY:==2862== in use at exit: 0 bytes in 0 blocks==2862== total heap usage: 0 allocs, 0 frees, 0 bytes allocated==2862====2862== All heap blocks were freed -- no leaks are possible==2862====2862== For counts of detected and suppressed errors, rerun with: -v==2862== Use --track-origins=yes to see where uninitialized values come from==2862== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)从上面的输出可以看到,Valgrind检测到了未初始化的变量，然后给出了警告(上面加粗的几行(译者注：貌似上面没有加粗的)).2. 在内存被释放后进行读/写Code :#include 《stdio.h》#include 《stdlib.h》 int main(void){char *p = malloc(1);*p = ’a’; char c = *p; printf("\n \n",c); free(p);c = *p;return 0;}上面的代码中，我们有一个释放了内存的指针 ‘p’ 然后我们又尝试利用指针获取值.让我们运行memcheck来看一下Valgrind对这种情况是如何反应的.$ valgrind --tool=memcheck ./val==2849== Memcheck, a memory error detector==2849== Copyright (C) 2002-2009, and GNU GPL’d, by Julian Seward et al.==2849== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info==2849== Command: ./val==2849== ==2849== Invalid read of size 1==2849== at 0x400603: main (valgrind.c:30)==2849== Address 0x51b0040 is 0 bytes inside a block of size 1 free’d==2849== at 0x4C270BD: free (vg_replace_malloc.c:366)==2849== by 0x4005FE: main (valgrind.c:29)==2849====2849====2849== HEAP SUMMARY:==2849== in use at exit: 0 bytes in 0 blocks==2849== total heap usage: 1 allocs, 1 frees, 1 bytes allocated==2849====2849== All heap blocks were freed -- no leaks are possible==2849====2849== For counts of detected and suppressed errors, rerun with: -v==2849== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)从上面的输出内容可以看到，Valgrind检测到了无效的读取操作然后输出了警告 ‘Invalid read of size 1′.另注,使用gdb来调试c程序.3. 从已分配内存块的尾部进行读/写Code :#include 《stdio.h》#include 《stdlib.h》 int main(void){char *p = malloc(1);*p = ’a’; char c = *(p+1); printf("\n \n",c); free(p);return 0;}在上面的代码中，我们已经为‘p’分配了一个字节的内存,但我们在将值读取到 ‘c’中的时候使用的是地址p+1.现在我们使用Valgrind运行上面的代码 :$ valgrind --tool=memcheck ./val==2835== Memcheck, a memory error detector==2835== Copyright (C) 2002-2009, and GNU GPL’d, by Julian Seward et al.==2835== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info==2835== Command: ./val==2835====2835== Invalid read of size 1==2835== at 0x4005D9: main (valgrind.c:25)==2835== Address 0x51b0041 is 0 bytes after a block of size 1 alloc’d==2835== at 0x4C274A8: malloc (vg_replace_malloc.c:236)==2835== by 0x4005C5: main (valgrind.c:22)==2835== ==2835====2835== HEAP SUMMARY:==2835== in use at exit: 0 bytes in 0 blocks==2835== total heap usage: 1 allocs, 1 frees, 1 bytes allocated==2835====2835== All heap blocks were freed -- no leaks are possible==2835====2835== For counts of detected and suppressed errors, rerun with: -v==2835== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)同样，该工具在这种情况下也检测到了无效的读取操作.4. 内存泄露Code:#include 《stdio.h》#include 《stdlib.h》 int main(void){char *p = malloc(1);*p = ’a’; char c = *p; printf("\n \n",c); return 0;}在这次的代码中, 我们申请了一个字节但是没有将它释放.现在让我们运行Valgrind看看会发生什么：$ valgrind --tool=memcheck --leak-check=full ./val==2888== Memcheck, a memory error detector==2888== Copyright (C) 2002-2009, and GNU GPL’d, by Julian Seward et al.==2888== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info==2888== Command: ./val==2888== ==2888====2888== HEAP SUMMARY:==2888== in use at exit: 1 bytes in 1 blocks==2888== total heap usage: 1 allocs, 0 frees, 1 bytes allocated==2888====2888== 1 bytes in 1 blocks are definitely lost in loss record 1 of 1==2888== at 0x4C274A8: malloc (vg_replace_malloc.c:236)==2888== by 0x400575: main (valgrind.c:6)==2888====2888== LEAK SUMMARY:==2888== definitely lost: 1 bytes in 1 blocks==2888== indirectly lost: 0 bytes in 0 blocks==2888== possibly lost: 0 bytes in 0 blocks==2888== still reachable: 0 bytes in 0 blocks==2888== suppressed: 0 bytes in 0 blocks==2888====2888== For counts of detected and suppressed errors, rerun with: -v==2888== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)输出行(上面加粗的部分)显示，该工具能够检测到内存的泄露.注意: 在这里我们增加了一个选项‘–leak-check=full’来得到内存泄露的详细细节.5. 不匹配地使用malloc/new/newCode:#include 《stdio.h》#include 《stdlib.h》#include《iostream》 int main(void){char *p = (char*)malloc(1);*p = ’a’; char c = *p; printf("\n \n",c);delete p;return 0;}上面的代码中，我们使用了malloc()来分配内存，但是使用了delete操作符来删除内存.注意 : 使用g++来编译上面的代码，因为delete操作符是在C++中引进的，而要编译C++需要使用g++.让我们运行来看一下 :$ valgrind --tool=memcheck --leak-check=full ./val==2972== Memcheck, a memory error detector==2972== Copyright (C) 2002-2009, and GNU GPL’d, by Julian Seward et al.==2972== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info==2972== Command: ./val==2972== ==2972== Mismatched free() / delete / delete ==2972== at 0x4C26DCF: operator delete(void*) (vg_replace_malloc.c:387)==2972== by 0x40080B: main (valgrind.c:13)==2972== Address 0x595e040 is 0 bytes inside a block of size 1 alloc’d==2972== at 0x4C274A8: malloc (vg_replace_malloc.c:236)==2972== by 0x4007D5: main (valgrind.c:7)==2972====2972====2972== HEAP SUMMARY:==2972== in use at exit: 0 bytes in 0 blocks==2972== total heap usage: 1 allocs, 1 frees, 1 bytes allocated==2972====2972== All heap blocks were freed -- no leaks are possible==2972====2972== For counts of detected and suppressed errors, rerun with: -v==2972== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)从上面的输出可以看到 (加粗的行), Valgrind清楚的说明了‘不匹配的使用了free() / delete / delete ‘你可以尝试在测试代码中使用’new’和’free’进行组合来看看Valgrind给出的结果是什么.6. 两次释放内存Code :#include 《stdio.h》#include 《stdlib.h》 int main(void){char *p = (char*)malloc(1);*p = ’a’; char c = *p;printf("\n \n",c);free(p);free(p);return 0;}在上面的代码中, 我们两次释放了’p’指向的内存. 现在让我们运行memcheck :$ valgrind --tool=memcheck --leak-check=full ./val==3167== Memcheck, a memory error detector==3167== Copyright (C) 2002-2009, and GNU GPL’d, by Julian Seward et al.==3167== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info==3167== Command: ./val==3167== ==3167== Invalid free() / delete / delete==3167== at 0x4C270BD: free (vg_replace_malloc.c:366)==3167== by 0x40060A: main (valgrind.c:12)==3167== Address 0x51b0040 is 0 bytes inside a block of size 1 free’d==3167== at 0x4C270BD: free (vg_replace_malloc.c:366)==3167== by 0x4005FE: main (valgrind.c:11)==3167====3167====3167== HEAP SUMMARY:==3167== in use at exit: 0 bytes in 0 blocks==3167== total heap usage: 1 allocs, 2 frees, 1 bytes allocated==3167====3167== All heap blocks were freed -- no leaks are possible==3167====3167== For counts of detected and suppressed errors, rerun with: -v==3167== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)从上面的输出可以看到(加粗的行), 该功能检测到我们对同一个指针调用了两次释放内存操作.

如何检测C++的内存泄漏，用哪些工具

本文浅谈一下C++内存泄漏的检测，首先我们需要知道程序有没有内存泄露，然后定位到底是哪行代码出现内存泄露了，这样才能将其修复。最简单的方法当然是借助于专业的检测工具，比较有名如BoundsCheck工具,功能非常强大，相信做C++开发的人都离不开它。此外就是不使用任何工具，而是自己来实现对内存泄露的监控，分如下两种情况：一. 在 MFC 中检测内存泄漏假如是用MFC的程序的话，很简单。默认的就有内存泄露检测的功能。我们用VS2005生成了一个MFC的对话框的程序,发现他可以自动的检测内存泄露.不用我们做任何特殊的操作. 仔细观察,发现在每个CPP文件中,都有下面的代码:#ifdef _DEBUG#define new DEBUG_NEW#endifDEBUG_NEW 这个宏定义在afx.h文件中，就是它帮助我们定位内存泄漏。 在含有以上代码的cpp文件中分配内存后假如没有删除，那么停止程序的时候，VisualStudio的Output窗口就会显示如下的信息了：Detected memory leaks!Dumping objects -》d:\code\mfctest\mfctest.cpp(80) : {157} normal block at 0x003AF170, 4 bytes long.Data: 《 》 00 00 00 00Object dump complete.在Output窗口双击粗体字那一行，那么IDE就会打开该文件，定位到该行，很容易看出是哪出现了内存泄露。二．检测纯C++的程序内存泄露我试了下用VisualStudio建立的Win32 Console Application和Win32 Project项目，结果都不能检测出内存泄露。下面一步一步来把程序的内存泄露检测的机制建立起来。首先，我们需要知道C运行库的Debug版本提供了许多检测功能，使得我们更容易的Debug程序。在MSDN中有专门的章节讲这个，叫做Debug Routines，建议大家先看看里面的内容吧。我们会用到里面很重要的几个函数。

sanitizer 内存泄露检查工具的使用

Address sanitizer是google开发的用于检测内存泄露的工具。主要检测use-after-free, 和 memory leaks。sanitizer需要在编译的时候对可能泄露的内存进行标记，所有编译的时候需要带着sanitizer一起编译，高版本的gcc已经集成了sanitizer(gcc大于4.8)。 sanitizer的官网位置可以在github中检索到。 -g 是告诉编译器编译时把符号表等调试信息编译进来 -fsanitize=address 编译标志是告诉编译器编译时调用address sanitizer -static-libasan 标志是告诉连接器，把address sanitizer库链接进来。 所以使用的时候，如果你的编译分两个命令，注意编译的时候要加 -g -fsanitize 标志。 然后链接的时候要加 -fsanitize -static-libasan 标志。举例如下: 当然编译命令也可以一步到位如下 gcc main.c -o main -fsanitize=address -static-libasan -g

如何用VS工具检测内存泄露

技术原理检测内存泄漏的主要工具是调试器和 CRT 调试堆函数。若要启用调试堆函数，请在程序中包括以下语句：#define CRTDBG_MAP_ALLOC#include #include 注意 #include 语句必须采用上文所示顺序。如果更改了顺序，所使用的函数可能无法正确工作。 通过包括 crtdbg.h，将 malloc 和 free 函数映射到其“Debug”版本_malloc_dbg 和_free_dbg，这些函数将跟踪内存分配和释放。此映射只在调试版本（在其中定义了 _DEBUG）中发生。发布版本使用普通的 malloc 和 free 函数。#define 语句将 CRT 堆函数的基版本映射到对应的“Debug”版本。并非绝对需要该语句，但如果没有该语句，内存泄漏转储包含的有用信息将较少。在添加了上面所示语句之后，可以通过在程序中包括以下语句来转储内存泄漏信息：_CrtDumpMemoryLeaks();当在调试器下运行程序时，_CrtDumpMemoryLeaks 将在“输出”窗口中显示内存泄漏信息。内存泄漏信息如下所示：Detected memory leaks!Dumping objects -》C:PROGRAM FILESVISUAL STUDIOMyProjectsleaktestleaktest.cpp(20) : {18} normal block at 0x00780E80, 64 bytes long.Data: 《　　　　　　　　》 CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CDObject dump complete. 如果不使用 #define _CRTDBG_MAP_ALLOC 语句，内存泄漏转储如下所示：Detected memory leaks! Dumping objects -》 {18} normal block at 0x00780E80, 64 bytes long. Data: 《 》 CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD Object dump complete. 未定义 _CRTDBG_MAP_ALLOC 时，所显示的会是： 内存分配编号（在大括号内）。 块类型（普通、客户端或 CRT）。 十六进制形式的内存位置。 以字节为单位的块大小。 前 16 字节的内容（亦为十六进制）。 定义了 _CRTDBG_MAP_ALLOC 时，还会显示在其中分配泄漏的内存的文件。文件名后括号中的数字（本示例中为 20）是该文件内的行号。 转到源文件中分配内存的行 在"输出"窗口中双击包含文件名和行号的行。 -或- 在"输出"窗口中选择包含文件名和行号的行，然后按 F4 键。_CrtSetDbgFlag 如果程序总在同一位置退出，则调用 _CrtDumpMemoryLeaks 足够方便，但如果程序可以从多个位置退出该怎么办呢？不要在每个可能的出口放置一个对 _CrtDumpMemoryLeaks 的调用，可以在程序开始包括以下调用：_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF ); 该语句在程序退出时自动调用 _CrtDumpMemoryLeaks。必须同时设置 _CRTDBG_ALLOC_MEM_DF 和 _CRTDBG_LEAK_CHECK_DF 两个位域，如上所示。 说明 在VC++6.0的环境下，不再需要额外的添加#define CRTDBG_MAP_ALLOC #include #include 只需要按F5，在调试状态下运行，程序退出后在"输出窗口"可以看到有无内存泄露。如果出现Detected memory leaks! Dumping objects -》 就有内存泄露。 确定内存泄露的地方 根据内存泄露的报告，有两种消除的方法： 第一种比较简单，就是已经把内存泄露映射到源文件的，可以直接在"输出"窗口中双击包含文件名和行号的行。例如Detected memory leaks! Dumping objects -》 C:PROGRAM FILESVISUAL STUDIOMyProjectsleaktestleaktest.cpp(20) : {18} normal block at 0x00780E80, 64 bytes long. Data: 《 》 CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD Object dump complete.C:PROGRAM FILESVISUAL STUDIOMyProjectsleaktestleaktest.cpp(20)就是源文件名称和行号。

怎么排查这些内存泄漏

最原始的内存泄露测试重复多次操作关键的可疑的路径，从内存监控工具中观察内存曲线，是否存在不断上升的趋势且不会在程序返回时明显回落。这种方式可以发现最基本，也是最明显的内存泄露问题，对用户价值最大，操作难度小，性价比极高。MAT内存分析工具2.1 MAT分析heap的总内存占用大小来初步判断是否存在泄露在Devices 中，点击要监控的程序。点击Devices视图界面中最上方一排图标中的“Update Heap”点击Heap视图点击Heap视图中的“Cause GC”按钮到此为止需检测的进程就可以被监视。Heap视图中部有一个Type叫做data object，即数据对象，也就是我们的程序中大量存在的类类型的对象。在data object一行中有一列是“Total Size”，其值就是当前进程中所有Java数据对象的内存总量，一般情况下，这个值的大小决定了是否会有内存泄漏。可以这样判断：进入某应用，不断的操作该应用，同时注意观察data object的Total Size值，正常情况下Total Size值都会稳定在一个有限的范围内，也就是说由于程序中的的代码良好，没有造成对象不被垃圾回收的情况。所以说虽然我们不断的操作会不断的生成很多对象，而在虚拟机不断的进行GC的过程中，这些对象都被回收了，内存占用量会会落到一个稳定的水平；反之如果代码中存在没有释放对象引用的情况，则data object的Total Size值在每次GC后不会有明显的回落。随着操作次数的增多Total Size的值会越来越大，直到到达一个上限后导致进程被杀掉。2.2 MAT分析hprof来定位内存泄露的原因所在。这是出现内存泄露后使用MAT进行问题定位的有效手段。A)Dump出内存泄露当时的内存镜像hprof，分析怀疑泄露的类：B)分析持有此类对象引用的外部对象C)分析这些持有引用的对象的GC路径D)逐个分析每个对象的GC路径是否正常从这个路径可以看出是一个antiRadiationUtil工具类对象持有了MainActivity的引用导致MainActivity无法释放。此时就要进入代码分析此时antiRadiationUtil的引用持有是否合理（如果antiRadiationUtil持有了MainActivity的context导致节目退出后MainActivity无法销毁，那一般都属于内存泄露了）。2.3 MAT对比操作前后的hprof来定位内存泄露的根因所在。为查找内存泄漏，通常需要两个 Dump结果作对比，打开 Navigator History面板，将两个表的 Histogram结果都添加到 Compare Basket中去A） 第一个HPROF 文件(usingFile 》 Open Heap Dump ).B）打开Histogram view.C）在NavigationHistory view里 (如果看不到就从Window 》show view》MAT- Navigation History ), 右击histogram然后选择Add to Compare Basket .D）打开第二个HPROF 文件然后重做步骤2和3.E）切换到Compare Basket view, 然后点击Compare the Results (视图右上角的红色”!”图标)。F）分析对比结果可以看出两个hprof的数据对象对比结果。通过这种方式可以快速定位到操作前后所持有的对象增量，从而进一步定位出当前操作导致内存泄露的具体原因是泄露了什么数据对象。注意：如果是用 MAT Eclipse 插件获取的 Dump文件，不需要经过转换则可在MAT中打开，Adt会自动进行转换。而手机SDk Dump 出的文件要经过转换才能被 MAT识别，Android SDK提供了这个工具 hprof-conv (位于 sdk/tools下)首先，要通过控制台进入到你的 android sdk tools 目录下执行以下命令：./hprof-conv xxx-a.hprof xxx-b.hprof例如 hprof-conv input.hprof out.hprof此时才能将out.hprof放在eclipse的MAT中打开。手机管家内存泄露每日监控方案目前手机管家的内存泄露每日监控会自动运行并输出是否存在疑似泄露的报告邮件，不论泄露对象的大小。这其中涉及的核心技术主要是AspectJ，MLD自研工具（原理是虚引用）和UIAutomator。3.1 AspectJ插桩监控代码手机管家目前使用一个ant脚本加入MLD的监控代码，并通过AspectJ的语法实现插桩。使用AspectJ的原因是可以灵活分离出项目源码与监控代码，通过不同的编译脚本打包出不同用途的安装测试包：如果测试包是经过Aspect插桩了MLD监控代码的话，那么运行完毕后会输出指定格式的日志文件，作为后续分析工作的数据基础。3.2 MLD实现监控核心逻辑这是手机管家内的一个工具工程，正式打包不会打入，BVT等每日监控测试包可以打入。打入后可以通过诸如addObject接口（通过反射去检查是否含有该工具并调用）来加入需要监控的检测对象，这个工具会自动在指定时机（如退出管家）去检测该对象是否发生泄漏。这个内存泄露检测的基本原理是：虚引用主要用来跟踪对象被垃圾回收器回收的活动。虚引用必须和引用队列（ReferenceQueue）联合使用（在虚引用函数就必须关联指定）。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，自动把这个虚引用加入到与之关联的引用队列中。程序可以通过判断引用队列中是否已经加入了虚引用，来了解被引用的对象是否将要被垃圾回收。基于以上原理，MLD工具在调用接口addObject加入监控类型时，会为该类型对象增加一个虚引用，注意虚引用并不会影响该对象被正常回收。因此可以在ReferenceQueue引用队列中统计未被回收的监控对象是否超过指定阀值。利用PhantomReferences(虚引用)和ReferenceQueue(引用队列)，当PhantomReferences被加入到相关联的ReferenceQueue时，则视该对象已经或处于垃圾回收器回收阶段了。MLD监控原理核心目前手机管家已对大部分类完成内存泄露的监控，包括各种activity，service和view页面等，务求在技术上能带给用户最顺滑的产品体验。接下来简单介绍下这个工具的判断核心。根据虚引用监控到的内存状态，需要通过多种策略来判断是否存在内存泄露。（1）最简单的方式就是直接在加入监控时就为该类型设定最大存在个数，举个例子，各个DAO对象理论上只能存在最多一个，因此一旦出现两个相同的DAO，那一般都是泄露了；（2）第二种情况是在页面退出程序退出时，检索gc后无法释放的对象列表，这些对象类型也会成为内存泄露的怀疑对象；（3）最后一种情况比较复杂，基本原理是根据历史操作判断对象数量的增长幅度。根据对象的增长通过最小二乘法拟合出该对象类型的增长速度，如果超过经验值则会列入疑似泄露的对象列表。3.3 UIAutomator完成重复操作的自动化最后一步就很简单了。这么多反复的UI操作，让人工来点就太浪费人力了。我们使用UIAutomator来进行自动化操作测试。目前手机管家的每日自动化测试已覆盖各个功能的主路径，并通过配置文件的方式来灵活驱动用例的增删改查，最大限度保证了随着版本推移用例的复用价值。至此手机管家的内存泄露测试方案介绍完毕，也欢迎各路牛人交流沟通更多更强的内存泄露工具盒方案！腾讯Bugly简介Bugly是腾讯内部产品质量监控平台的外发版本，其主要功能是App发布以后，对用户侧发生的Crash以及卡顿现象进行监控并上报，让开发同学可以第一时间了解到App的质量情况，及时机型修改。目前腾讯内部所有的产品，均在使用其进行线上产品的崩溃监控。

如何在Android Studio中使用LeakCanary检测内存泄露

内存泄露检测是项目性能优化不可避免的问题，只有解决内存泄露问题才能从根本上解决OOM。在Eclipse中提供Mat工具来检测内存泄露，但是使用较为麻烦，界面也不是很直观。对于有耐心，有想法的，也是可以尝试了解一下。知道Leak的出现，为内存泄露检测带来了福音。

1.什么是LeakCanary

LeakCanaryA memory leak detection library for Android and Java. 

LeakCanary是一个Android和Java的内存检测库。

2.LeakCanary如何展示内存泄露信息

如果项目存在内存泄露，就会在状态栏或是一个单独的Leaks程序中显示内存泄露信息，提供一个造成内存泄露对象的引用路径 这个项目是在应用相应的回退之后分析是否存在内存泄漏，如果存在内存泄漏，将进行相应的分析并处理，若没有则不会，不能做到MAT或者studio中相应的实时查看内存状态的，并且检测具有很大的延时，最少10s。

3.LeakCanary的Github地址：

***隐藏网址***

4.在Android Studio中使用LeakCanary

引入LeakCanary有多种方法，我们直接远程依赖 *   *Step 1:   配置bundle.gradle**

debugCompile ’com.squareup.leakcanary:leakcanary-android:1.5’//    releaseCompile ’com.squareup.leakcanary:leakcanary-android-no-op:1.5’releaseCompile ’com.squareup.leakcanary:leakcanary-android:1.5’testCompile ’com.squareup.leakcanary:leakcanary-android-no-op:1.5’

【错误1：】截图如下： Failed to resolve: com.squareup.leakcanary:leakcanary-android 这是因为我们是远程依赖leakcanary,而leakcanary项目放在jcenter() 和mavenCentral()架包库中 所以需要在在build中再加入如下代码，并 clean Build。

allprojects {repositories {jcenter()}}    

如果仍不成功，需要添加

allprojects {repositories {jcenter()mavenCentral()}}   

Step2:在Application文件中配置

public class ExampleApplication extends Application {@Override public void onCreate() {    super.onCreate();    if (LeakCanary.isInAnalyzerProcess(this)) {      // This process is dedicated to LeakCanary for heap analysis.// You should not init your app in this process.return;}LeakCanary.install(this);    // Normal app init code...}} 

step3、应用安装安装应用，在debug版本的apk安装后，会出现如下两个图标：左边的是自己应用的图标，右边是启动应用后退出，自动安装的leakCancayDe图标。 【错误2】：但是有的人没有相应的图标，怎么办？

因为gradle设置错误的原因，上述build分别设置了debugCompile 和 releaseCompile，具体的区别这里不细说了，需要有一定的gradle功底，才能改修完成。这里给出的最简易的方案，适用于该产品在加入的leakCancy仅仅在测试的时候使用，而在release包中手动去除相应的代码：【解决当前问题，但是不提倡】1、debug 和 release 引用相同的lib

dependencies {debugCompile ’com.squareup.leakcanary:leakcanary-android:1.5’releaseCompile ’com.squareup.leakcanary:leakcanary-android:1.5’}2、使用compile 不再1区分debug 和 release12dependencies {compile ’com.squareup.leakcanary:leakcanary-android:1.5’} 

如果存在内存泄露，将会显示内存泄露的对象的引用路径。 

如何检查内存泄露问题

　　一、内存泄漏的检查方法：　　1.ccmalloc－Linux和Solaris下对C和C++程序的简单的使用内存泄漏和malloc调试库。　　2.Dmalloc－Debug Malloc Library.　　3.Electric Fence－Linux分发版中由Bruce Perens编写的malloc（）调试库。　　4.Leaky－Linux下检测内存泄漏的程序。　　5.LeakTracer－Linux、Solaris和HP-UX下跟踪和分析C++程序中的内存泄漏。　　6.MEMWATCH－由Johan Lindh编写，是一个开放源代码C语言内存错误检测工具，主要是通过gcc的precessor来进行。　　7.Valgrind－Debugging and profiling Linux programs, aiming at programs written in C and C++.　　8.KCachegrind－A visualization tool for the profiling data generated by Cachegrind and Calltree.　　9.IBM Rational PurifyPlus－帮助开发人员查明C/C++、托管。NET、Java和VB6代码中的性能和可靠性错误。PurifyPlus 将内存错误和泄漏检测、应用程序性能描述、代码覆盖分析等功能组合在一个单一、完整的工具包中。　　二、内存泄漏的简单介绍：　　内存泄漏也称作“存储渗漏”，用动态存储分配函数动态开辟的空间，在使用完毕后未释放，结果导致一直占据该内存单元。直到程序结束。（其实说白了就是该内存空间使用完毕之后未回收）即所谓内存泄漏。　　内存泄漏形象的比喻是“操作系统可提供给所有进程的存储空间正在被某个进程榨干”，最终结果是程序运行时间越长，占用存储空间越来越多，最终用尽全部存储空间，整个系统崩溃。所以“内存泄漏”是从操作系统的角度来看的。这里的存储空间并不是指物理内存，而是指虚拟内存大小，这个虚拟内存大小取决于磁盘交换区设定的大小。由程序申请的一块内存，如果没有任何一个指针指向它，那么这块内存就泄漏了。