推荐这篇日记的豆列
······君，已阅读到文档的结尾了呢~~
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
关于怎么检测Android的内存泄漏
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='/DocinViewer-4.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口您所在的位置： &
2.7　秘诀：使用Instruments检测内存泄漏
2.7　秘诀：使用Instruments检测内存泄漏
张彩霞 等译
人民邮电出版社
《iPhone开发秘籍:第2版》第2章构建第一个项目，本章介绍在项目中使用这些工具的基础知识。你将看到如何构建一个简单的Hello World项目，编译它并在模拟器中测试它，然后学习如何针对设备编译它，并将它部署到设备。你还将发现一些基本的调试工具，学习它们的用法，并获得关于方便的编译器指令的一些使用技巧。本节为大家介绍秘诀：使用Instruments检测内存泄漏。
2.7　秘诀：使用Instruments检测内存泄漏
在调优应用程序时，Instruments扮演着重要角色。它提供了一套工具，用于监控性能。通过它的泄漏检测，你可以跟踪、识别和解决程序中的内存泄漏问题。秘诀2-1显示了一个存在两处泄漏问题的应用程序：一处是用malloc()构建了一个字符串，但是没有调用相应的free()，另一处是本章前面展示的NSArray例子。
要看到Instruments的实际应用，首先需要加载秘诀2-1的示例项目。在Xcode中选择Run（运行）→Run with Performance Tool（使用性能工具运行）→Leaks（泄漏）。这将启动Instruments和模拟器。应用程序开始在模拟器中运行，Instruments则观察它的进展。
单击应用程序中的任意一个按钮使内存泄漏。String按钮泄漏一个128B的已分配内存的块。Array按钮泄漏一个32B的NSArray。在Instruments中，内存泄漏以橘色三角形的形式出现。三角形的大小表明泄漏的大小。
为了查看各处泄漏的列表，必须单击Leaks行，如图2-11所示。默认情况下，ObjectAlloc行被选中。每处泄漏显示泄漏的内存量、泄漏开始的地址以及泄漏对象的类型。
（点击查看大图）图2-11　Instruments跟踪由不能回收的内存导致的泄漏
要跟踪关于何处发生泄漏的细节，打开Extended Detail窗格（View→Extended Detail, Command-E)。或者，单击Instruments窗口底部"Leaked Blocks"字样左边的detail按钮。然后单击泄漏列表中的任何一项，这将在Extended Detail视图中打开针对那处泄漏的栈跟踪，如图2-12所示。
在此视图中，可以发现一个栈跟踪，它将泄漏追溯到它的创建处。如屏幕截图所示，当前的内存泄漏是在已经分配内存的leakCString中分配的。发现对象的起源有助于追踪在对象生命周期中的何处会发生泄漏。发现后，就有望堵住泄漏，解决程序中的内存问题。
（点击查看大图）图2-12　Extended Detail视图中的栈跟踪揭示泄漏发生于何处
秘诀2-1　创建程序中的泄漏
获取这一秘诀的代码
要获取这一秘诀的代码，请访问-，如果你已经下载了包含本书所有示例代码的磁盘映像，请打开第2章的文件夹查看关于这一秘诀的项目。
【责任编辑： TEL：（010）】&&&&&&
关于&&的更多文章
现在的天气越来越冷了，感觉跟冬天似的，小编现在在发这篇文章是
本书描述了黑客用默默无闻的行动为数字世界照亮了一条道路的故事。
解释ASP.NET MVC框架与"文件页"Web框架的不同之处
本书以Android 4.X进行开发示范，通过大量图示与step
本书手把手地教读者用C语言制作两种编程语言：crowbar
《程序员密码学》涉及密码学的各个研究方向，分组密码、散列函数、公钥密码以及相关的攻击，同时也讲解了密码学算法实现上常用的
51CTO旗下网站vs2010如何检测内存泄漏
本文分析了Windows环境使用MFC调试内存泄露的技术，介绍了在Windows环境下用VC++查找，定位和消除内存泄露的方法技巧。
关键词：VC++；CRT 调试堆函数；试探法。
检测内存泄漏的主要工具是调试器和 CRT 调试堆函数。若要启用调试堆函数，请在程序中包括以下语句：
#define CRTDBG_MAP_ALLOC
注意 #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 0x bytes long.
Data: &　　　　　　　　& CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.
如果不使用 #define _CRTDBG_MAP_ALLOC 语句，内存泄漏转储如下所示：
Detected memory leaks!
Dumping objects -&
{18} normal block at 0x 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
只需要按F5，在调试状态下运行，程序退出后在"输出窗口"可以看到有无内存泄露。如果出现
Detected memory leaks!
Dumping objects -&
就有内存泄露。&
确定内存泄露的地方&
根据内存泄露的报告，有两种消除的方法：&
第一种比较简单，就是已经把内存泄露映射到源文件的，可以直接在"输出"窗口中双击包含文件名和行号的行。例如
Detected memory leaks!
Dumping objects -&
C:PROGRAM FILESVISUAL STUDIOMyProjectsleaktestleaktest.cpp(20) : {18} normal block at 0x 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)
就是源文件名称和行号。&
第二种比较麻烦，就是不能映射到源文件的，只有内存分配块号。
Detected memory leaks!
Dumping objects -&
{18} normal block at 0x bytes long.
Data: & & CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
Object dump complete.
　　这种情况我采用一种"试探法"。由于内存分配的块号不是固定不变的，而是每次运行都是变化的，所以跟踪起来很麻烦。但是我发现虽然内存分配的块号是变化的，但是变化的块号却总是那几个，也就是说多运行几次，内存分配的块号很可能会重复。因此这就是"试探法"的基础。
先在调试状态下运行几次程序，观察内存分配的块号是哪几个值；
选择出现次数最多的块号来设断点，在代码中设置内存分配断点：添加如下一行（对于第 18 个内存分配）：
_crtBreakAlloc = 18;
或者，可以使用具有同样效果的 _CrtSetBreakAlloc 函数：
_CrtSetBreakAlloc(18);
在调试状态下运行序，在断点停下时，打开"调用堆栈"窗口，找到对应的源代码处；
退出程序，观察"输出窗口"的内存泄露报告，看实际内存分配的块号是不是和预设值相同，如果相同，就找到了；如果不同，就重复步骤3，直到相同。&
最后就是根据具体情况，在适当的位置释放所分配的内存。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。LeakCanary:检测所有的内存泄漏
原文： &ava.lang.OutOfMemoryError
&&&&&&&&at&android.graphics.Bitmap.nativeCreate(Bitmap.java:-2)
&&&&&&&&at&android.graphics.Bitmap.createBitmap(Bitmap.java:689)
&&&&&&&&at&com.squareup.ui.SignView.createSignatureBitmap(SignView.java:121)没人喜欢OutOfMemoryError在Square的注册过程中，我们在bitmap上 。这个bitmap和设备的屏幕大小相当，在创建它的时候，我遇到了相当数量的OOM导致的崩溃。我们试过了几种方法，没有一个解决了我们的问题：
使用Bitmap.Config.ALPHA_8（签名是不需要颜色的）捕获OutOfMemoryError，触发垃圾回收然后重试几次（从 获得的启发）我们没有考虑过将bitmap分配在堆内存之外，那个时候 还没出现。我们看待问题的方式是不对的bitmap的大小本身不是什么问题。当内存快要满了的时候，OOM随时随地都可能发生。尤其是在创建大对象的时候更容易发生，比如bitmap。OOM一般代表着更深层次的问题：内存泄漏。什么是内存泄漏?有些对象只有有限的生命周期。当它们的任务完成之后，它们将被垃圾回收。如果在对象的生命周期本该结束的时候，这个对象还被一系列的引用，这就会导致内存泄漏。随着泄漏的累积，app将消耗完内存。比如，在Activity.onDestroy()被调用之后，view树以及相关的bitmap都应该被垃圾回收。如果一个正在运行的后台线程继续持有这个Activity的引用，那么相关的内存将不会被回收，这最终将导致OutOfMemoryError崩溃。寻找内存泄漏寻找内存泄漏是一个人工操作的过程，在Raizlabs的
系列中描述得很清楚。下面是关键的步骤：通过 , , 或者 了解OOM主动重现问题。你可能需要买或者借或者偷一个遭遇了崩溃的特殊设备（并不是所有的设备上都会发生内存泄漏！）。你还需要找出是什么串在一起导致了内存泄漏。当OOM出现时进行堆转储(dump the heap)().使用MAT或YourKit内存检测工具检测内存的变化，并找出哪个对象应该被垃圾回收;从那个对象到GC roots推断最短的强引用路径;在路径中找出不存在的引用，并修复要是有一个库可以为你做完所有的事情，让你专注于修复内存泄漏的问题，那该有多好。LeakCanary介绍 是一个开源的在debug版本中检测内存泄漏的java库。让我们来看看一个cait的例子：class&Cat&{
class&Box&{
&&Cat&hiddenC
class&Docker&{
&&static&Box&
Box&box&=&new&Box();
Cat&schrodingerCat&=&new&Cat();
box.hiddenCat&=&schrodingerC
Docker.container&=&创建一个RefWatcher实例，然后给它一个对象让它观察：//&We&expect&schrodingerCat&to&be&gone&soon&(or&not),&let's&watch&it.
refWatcher.watch(schrodingerCat);当检测出泄漏的时候，你会自动得到一个漂亮的泄漏线索：*&GC&ROOT&static&Docker.container
*&references&Box.hiddenCat
*&leaks&Cat&instance我们知道你的时间宝贵，因此我们让它非常好设置。只需几行代码，LeakCanary就能自动检测Activity的泄漏：public&class&ExampleApplication&extends&Application&{
&&@Override&public&void&onCreate()&{
&&&&super.onCreate();
&&&&LeakCanary.install(this);
}当内存不足时，会有一个通知和良好的展示界面：结论在启用LeakCanary之后，我们发现和修复了许多内存泄漏的问题。我们甚至发现了一些。结果是非常令人惊奇的，我们现在减少了94%的oom崩溃问题。如果你想终结OOM崩溃，!
上一篇： 这是实现材料设计风格的INSTAGRAM系列文章的总结。如果你已经阅读了前面的文章，可以直接跳过此文。 几个月前我开始了一个实现 设计师Emmanuel Pacamalan发布的一个视频 中绝大多数视觉效果的项目。这个视频演示了谷歌新的设计语言 - 材料设计 。所有的东西
下一篇： 在这个系列中，我将向你解释什么是依赖注入，为什么使用依赖注入以及在Android中如何使用依赖注入框架dagger， dagger是square出品的专门为Android优化设计的依赖注入框架。这篇文章是是我上一篇关于如何在Android项目中使用MVP模式的姊妹篇，读者中一定有人