如何解决Android内存溢出

模拟器RAM比较小，只有8M内存，当我放入的大量的图片（每个100多K左右），就出现上面的原因。由于每张图片先前是压缩的情况。放入到Bitmap的时候，大小会变大，导致超出RAM内存，具体解决办法如下：//解决加载图片内存溢出的问题

//Options只保存图片尺寸大小，不保存图片到内存

BitmapFactory.Optionsopts=newBitmapFactory.Options()

/*缩放的比例，缩放是很难按准备的比例进行缩放的，其值表明缩放的倍数，SDK中建议其值是2的指数值,值越大会导致图片不清晰*/

opts.inSampleSize=4

//回收bmp.recycle()还可以用到优化Dalvik虚拟机的堆内存分配对于Android平台来说，其托管层使用的DalvikJavaVM从目前的表现来看还有很多地方可以优化处理，比如我们在开发一些大型游戏或耗资源的应用中可能考虑手动干涉GC处理，使用dalvik.system.VMRuntime类提供的setTargetHeapUtilization方法可以增强程序堆内存的处理效率。当然具体原理我们可以参考开源工程，这里我们仅说下使用方法:privatefinalstaticfloatTARGET_HEAP_UTILIZATION=0.75f在程序onCreate时就可以调用VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION)Android堆内存也可自己定义大小对于一些Android项目，影响性能瓶颈的主要是Android自己内存管理机制问题，除了优化Dalvik虚拟机的堆内存分配外，我们还可以强制定义自己软件的对内存大小，我们使用Dalvik提供的dalvik.system.VMRuntime类来设置最小堆内存为例:privatefinalstaticintCWJ_HEAP_SIZE=6*1024*1024VMRuntime.getRuntime().setMinimumHeapSize(CWJ_HEAP_SIZE)//设置最小heap内存为6MB大小。当然对于内存吃紧来说还可以通过手动干涉GC去处理

一、定位内存泄漏：

可以用LeakCanary:检测所有的内存泄漏

http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2015/0509/2854.html

二、解决：

1.对各种流，文件资源这些比如：InputStream/OutputStream，SQLiteOpenHelper，SQLiteDatabase，Cursor，文件，I/O，Bitmap图片等 *** 作等都应该记得显示关闭。

2.尽量避免static成员变量引用资源耗费过多的实例,比如Context。因为Context的引用超过它本身的生命周期，会导致Context泄漏。所以尽量使用Application这种Context类型。

3.使用线程池，不要newthread

4.UI视图检查，减少视图层级（hierarchyviewer）。

5.图片优化

6. 重用系统资源：系统定义id，系统图片，系统布局，系统style，系统字符串，系统颜色定义

android scrollview内存溢出通常是由内存泄露导致。

1、内存泄露导致

由于我们程序的失误，长期保持某些资源（如Context）的引用，垃圾回收器就无法回收它，当然该对象占用的内存就无法被使用，这就造成内存泄露。

Android 中常见就是Activity被引用在调用finish之后却没有释放，第二次打开activity又重新创建，这样的内存泄露不断的发生,则会导致内存的溢出。

Android的每个应用程序都会使用一个专有的Dalvik虚拟机实例来运行，它是由Zygote服务进程孵化出来的，也就是说每个应用程序都是在属于自己的进程中运行的。Android为不同类型的进程分配了不同的内存使用上限，如果程序在运行过程中出现了内存泄漏的而造成应用进程使用的内存超过了这个上限，则会被系统视为内存泄漏，从而被kill掉，这使得仅仅自己的进程被kill掉，而不会影响其他进程.

2、占用内存较多的对象

保存了多个耗用内存过大的对象（如Bitmap）或加载单个超大的图片，造成内存超出限制。

使用方法比较简单：

·选择DDMS视图，并打开Devices视图和Heap视图

·点击选择要监控的进程，比如：上图中我选择的是system_process

·选中Devices视图界面上的"update heap" 图标

·点击Heap视图中的"Cause GC" 按钮（相当于向虚拟机发送了一次GC请求的 *** 作）

在Heap视图中选择想要监控的Type，一般我们会观察dataobject的 total size的变化，正常情况下total size的值会稳定在一个有限的范围内，也就说程序中的代码良好，没有造成程序中的对象不被回收的情况。如果代码中存在没有释放对象引用的情况，那么data object的total size在每次GC之后都不会有明显的回落，随着 *** 作次数的增加而total size也在不断的增加。（说明：选择好data object后，不断的 *** 作应用，这样才可以看出total size的变化）。如果totalsize确实是在不断增加而没有回落，说明程序中有没有被释放的资源引用。那么我们应该怎么来定位呢？

Android中内存泄露定位

通过DDMS工具可以判断应用程序中是否存在内存泄漏的问题，那又如何定位到具体出现问题的代码片段，最终找到问题所在呢？内存分析工具MAT Memory Analyzer Tool解决了这一难题。MAT工具是一个Eclipse 插件，同时也有单独的RCP 客户端，MAT工具的解析文件是.hprof，这个文件存放了某进程的内存快照。MAT工具定位内存泄漏具体位置的方法如下：

① 生成.hprof文件。Eclipse中生成.hprof文件的方法有很多，不同Android版本中生成.hprof的方式也稍有差别，但它们整体思路是一样的。我们在DDMS界面选中想要分析的应用进程，在Devices视图界面上方的一行图标按钮中，同时选中“Update Heap”和“Dump HPROF file”两个按钮，这时DDMS将会自动生成当前选中进程的.hprof文件。

② 将.hprof 文件导入到MAT工具中，MAT工具会自动解析并生成报告，点击“Dominator Tree”按钮，并按包分组，选择已定义的包类点右键，在d出的菜单中选择List objects﹥With incoming references，这时会列出所有可疑的类。右键点击某一项，并选择Path to GC Roots﹥excludeweak/soft references，MAT工具会进一步筛选出跟程序相关的所有内存泄漏的类。这样就可以追踪到某一个产生内存泄漏的类的具体代码中。

使用MAT内存分析工具查找内存泄漏的根本思路是找到哪个类的对象的引用没有被释放，然后分析没有被释放的原因，最终定位到代码中哪些片段存在着内存泄漏。

---