13518219792
导致Android内存溢出有多种情况，像使用static修饰Context变量，Context被Hold住了导致Activity无法销毁；Bitmap没有及时回收，调用recycle()函数并不能立即释放Bitmap，读取Bitmap到内存的时候没有做采样率的设置等等；可以看下Android OOM问题分析及文章引用的参考资源。
创新互联建站专注于牧野企业网站建设,响应式网站设计,商城建设。牧野网站建设公司,为牧野等地区提供建站服务。全流程按需网站开发，专业设计，全程项目跟踪，创新互联建站专业和态度为您提供的服务
[img]一、内存溢出 现在的智能手机内存已经足够大，但是对于一个应用程序来说智能手机当中稀缺的内存，仍然是应用程序的一大限制。在Android应用程序开发当中，最常见的内存溢出问题（OOM）是在加载图片时出现的，尤其是在不知道图片大小的情况下。 潜在的内存溢出操作主要包括以下几点： 1、从网络当中加载用户特定的图片。因为直到我们在下载图片的时候我们才知道图片的大小。 2、向Gallery加载图片。因为现在智能手机的摄像头有很高的分辨率，在加载图片的时候需要最图片进行处理，然后才能正常的使用。 请注意一点，Android系统是从系统全局的观念来分配内存以加载图片的，这就意味着，即使你的应用有足够大的内存可用，内存溢出问题（out of memroy，OOM）仍然可能出现，因为所有的应用共享一个加载图片的内存池（我们使用BitmapFactory进行解析）。 二、解决内存溢出问题 原文（Downsampling为了好理解，解释为，程序A）。程序A通过调整像素，同时使其均衡化来降低图片的分辨率。因为不管问题图片是因为太大而不能再手机上正常显现，这个图片都会缩短其宽度以在ImageView当中显示，当图片在ImageView当中显示时，我们会因为加载一些没有必要的原始图片而浪费掉内存。 因此，更加有效的加载图片的时机是在其初始化处理的时候。 以下是处理代码： 1: private static Bitmap getResizedImage(String path, byte[] data, int targetWidth){2:3: BitmapFactory.Options options = new BitmapFactory.Options(); 14: options.inSampleSize = ssize;15:16: Bitmap bm = null;17: try{18: bm = decode(path, data, options); 19: }catch(OutOfMemoryError e){ 39: result = result * 2;40:41: }42:43: return result;44: }三、AQuery当在Android应用程序开发当中使用AQuery组件时，处理这个问题会变的更加的简单。
一、Android中内存溢出泄露监测
1、内存监测工具 DDMS -- Heap
2、使用方法比较简单：
· 选择DDMS视图，并打开Devices视图和Heap视图
· 点击选择要监控的进程，比如：上图中我选择的是system_process
· 选中Devices视图界面上的"update heap" 图标
· 点击Heap视图中的"Cause GC" 按钮（相当于向虚拟机发送了一次GC请求的操作）
3、在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”按钮，并按包分组，选择已定义的包类点右键，在弹出的菜单中选择List objects﹥With incoming references，这时会列出所有可疑的类。右键点击某一项，并选择Path to GC Roots﹥excludeweak/soft references，MAT工具会进一步筛选出跟程序相关的所有内存泄漏的类。这样就可以追踪到某一个产生内存溢出泄漏的类的具体代码中。
内存泄漏是指分配出去的内存无法回收了
内存泄漏指由于疏忽或错误造成程序未能释放已经不再使用的内存的情况,是应用程序分配某段内存后，由于设计错误，失去了对该段内存的控制，因而造成了内存的浪费。
一般我们常说的内存泄漏是指堆内存的泄漏。堆内存是指程序从堆中分配的，大小任意的（内存块的大小可以在程序运行期决定），使用完后必须显示释放的内存。应用程序一般使用malloc，realloc，new等函数从堆中分配到一块内存，使用完后，程序必须负责相应的调用free或delete释放该内存块，否则，这块内存就不能被再次使用，我们就说这块内存泄漏了。
内存溢出是指程序要求的内存，超出了系统所能分配的范围，从而发生溢出。
内存溢是指在一个域中输入的数据超过它的要求而且没有对此作出处理引发的数据溢出问题，多余的数据就可以作为指令在计算机上运行。
主要要遵循以下几点：
不要为Context长期保存引用（要引用Context就要使得引用对象和它本身的生命周期保持一致）。
如果要使用到Context，尽量使用ApplicationContext去代替Context，因为ApplicationContext的生命周期较长，引用情况下不会造成内存泄露问题
在你不控制对象的生命周期的情况下避免在你的Activity中使用static变量。尽量使用WeakReference去代替一个static。
垃圾回收器并不保证能准确回收内存，这样在使用自己需要的内容时，主要生命周期和及时释放掉不需要的对象。尽量在Activity的生命周期结束时，在onDestroy中把我们做引用的其他对象做释放，比如：cursor.close()。
一、定位内存泄漏：
可以用LeakCanary:检测所有的内存泄漏
二、解决：
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，系统字符串，系统颜色定义
