在Android的实际开发中，可能会出现不再使用的对象无法被系统回收的情况，这种情况会导致内存泄漏，甚至内存溢出，导致程序崩溃。
 
检测方法：使用LeakCanary
 
优化方案：
 
1.检查使用多少内存
 
每个 APP 的堆(heap)内存大小有硬性限制，如果您的 APP 已达到堆内存限制，并尝试分配更多的内存，系统会抛出 OutOfMemoryError 。为了避免 OOM ，您可以查询当前设备有多少堆空间，可以通过调用系统 getMemoryInfo() 查询，返回 一个ActivityManager.MemoryInfo 对象，它提供该设备当前存储器的状态信息，包括可用的存储器，总存储器，和低于该阈值存储器。
 
private void getMemoryInfo() {
 
ActivityManager activityManager = (ActivityManager) this.getSystemService(ACTIVITY_SERVICE);
 
ActivityManager.MemoryInfo memoryInfo = new ActivityManager.MemoryInfo();
 
activityManager.getMemoryInfo(memoryInfo);
 
LogUtil.d("totalMem=" + memoryInfo.totalMem + ",availMem=" + memoryInfo.availMem); if (!memoryInfo.lowMemory) { // 运行在低内存环境 }
 
}123456789123456789
 
2.当界面不可见时释放内存
 
实现 ComponentCallbacks2 API 中 onTrimMemory()) ，当回调参数 level 为 TRIM_MEMORY_UI_HIDDEN ，是用户点击了Home键或者Back键退出应用，所有UI界面被隐藏，这时候应该释放一些不可见的时候非必须的资源。
 
public class MainActivity extends AppCompatActivity implements ComponentCallbacks2 { // Other activity code ... /**
 
* Release memory when the UI becomes hidden or when system resources become low.
 
* @param level the memory-related event that was raised.
 
*/ public void onTrimMemory(int level) { // Determine which lifecycle or system event was raised. switch (level) { case ComponentCallbacks2.TRIM_MEMORY_UI_HIDDEN: /*
 
Release any UI objects that currently hold memory.
 
The user interface has moved to the background.
 
*/ break; case ComponentCallbacks2.TRIM_MEMORY_RUNNING_MODERATE: case ComponentCallbacks2.TRIM_MEMORY_RUNNING_LOW: case ComponentCallbacks2.TRIM_MEMORY_RUNNING_CRITICAL: /*
 
Release any memory that your app doesn't need to run.
 
The device is running low on memory while the app is running.
 
The event raised indicates the severity of the memory-related event.
 
If the event is TRIM_MEMORY_RUNNING_CRITICAL, then the system will
 
begin killing background processes.
 
*/ break; case ComponentCallbacks2.TRIM_MEMORY_BACKGROUND: case ComponentCallbacks2.TRIM_MEMORY_MODERATE: case ComponentCallbacks2.TRIM_MEMORY_COMPLETE: /*
 
Release as much memory as the process can.
 
The app is on the LRU list and the system is running low on memory.
 
The event raised indicates where the app sits within the LRU list.
 
If the event is TRIM_MEMORY_COMPLETE, the process will be one of
 
the first to be terminated.
 
*/ break; default: /*
 
Release any non-critical data structures.
 
The app received an unrecognized memory level value
 
from the system. Treat this as a generic low-memory message.
 
*/ break;
 
}
 
}
 
}123456789101112131415161718192021222324252627282930313233343536373839404142434445464748123456789101112131415161718192021222324252627282930313233343536373839404142434445464748
 
该 onTrimMemory() 回调是在搭载Android 4.0(API级别14)加入。对于早期版本，您可以使用 onLowMemory() 回调作为旧版本的回调，这大致相当于 TRIM_MEMORY_COMPLETE事件。
 
3.谨慎使用服务
 
离开了 APP 还在运行服务是最糟糕的内存管理错误之一，当 APP 处在后台，我们应该停止服务，除非它需要运行的任务。我们可以使用 JobScheduler 替代实现，JobScheduler 把一些不是特别紧急的任务放到更合适的时机批量处理。如果必须使用一个服务，最佳方法是使用 IntentService ，限制服务寿命，所有请求处理完成后，IntentService 会自动停止。
 
4.使用优化的数据容器
 
考虑使用优化过数据的容器 SparseArray / SparseBooleanArray / LongSparseArray 代替 HashMap 等传统数据结构，通用 HashMap 的实现可以说是相当低效的内存，因为它需要为每个映射一个单独的条目对象。
 
5.避免在Android上使用枚举
 
6.使用 nano protobufs 序列化数据
 
Protocol buffers 是一个语言中立，平台中立的，可扩展的机制，由谷歌进行序列化结构化数据，类似于 XML 设计的，但是更小，更快，更简单。如果需要为您的数据序列化与协议化，建议使用 nano protobufs。
 
7.避免内存流失
 
8.使用ProGuard来剔除不需要的代码
 
使用 ProGuard 来剔除不需要的代码，移除任何冗余的，不必要的，或臃肿的组件，资源或库完善 APP 的内存消耗。
 
9.减少apk体积
 
您可以通过减少 APP 的整体规模显著减少 APP 的内存使用情况。文章：Android APK瘦身实践
 
10.优化布局层次
 
通过优化视图层次结构，以减少重叠的 UI 对象的数量来提高性能。文章：Android 渲染优化
 
11.使用 Dagger 2依赖注入
 
依赖注入框架可以简化您写的代码，并提供一个自适应环境测试和便于其他配置的更改。如果打算在您的 APP 使用依赖注入框架，可以考虑用 Dagger 2 ，Dagger 不使用反射扫描 APP 的代码，Dagger 是静态的，意味着它编译时不需要占用运行 Android 应用或内存的使用。
 
12.小心使用外部库
 
13.避免Bitmap浪费
 
Bitmap是内存消耗的大头，当使用时要及时回收。另外配置：
 
inSampleSize：缩放比例，图片按需加载，避免不必要的大图载入。
 
decode format：解码格式，选择ARGB_8888/RBG_565/ARGB_4444/ALPHA_8，存在很大差异。
 
14.Cursor关闭
 
如查询数据库的操作，使用到Cursor，也要对Cursor对象及时关闭。
 
15.监听器的注销
 
Android程序里面存在很多需要register与unregister的监听器，手动add的listener，需要记得及时remove这个listener。

 
1. 内存简析
 
待完善(所学有限，不知如何下笔，怕误导，建议看下面的参考文章，顺便给腾讯系的开发点个赞......)
 
2. 内存检测工具的使用
 
2.1.   内存泄露检测：
 
3. 内存技术优化
 
题一简单解释了Android app中内存的使用，题2说明了内存泄露及其android提供的内存分析工具，针对发现的问题项目做了以下优化点：
 
3.1. 内存泄露的优化
 
代码的开发过程中，某个知识点不熟甚至某个时间点脑短路很正常的，逻辑代码中出现内存泄露也是很正常的，内存泄露不同的泄露点有着不同的处理方法，不再一一赘述，此处将项目中出现几个奇葩的内存泄露备注一下：
 
3.1.1. Android常见内存泄露(handler，内部类，上下文胡乱传递等)参考下面文章参考
 
3.1.2. 在华为手机中常见的输入法内存泄露(甚至没有使用输入框的页面也会出现)，分析文章很多，给出解决方法也很多，下面方法经实测起作用，做一备注：
 

 
华为手机输入法内存泄露处理方案
 
多数网上文章提供的是上面的类似代码，经实测是不起作用的，debug发现反射后的view获取到的context和传进来的并不是同一个context，所以并不会走置空方法，输入法的泄露并不能避免，究其原因是页面decorview在Android高版本中并没有直接持有context而是有封装一层decorcontext，此处通过反射的方式再反射一次即可：
 

 
view反射真正的context
 
3.1.3. rxjava的使用造成内存泄露：当前多数app框架中都使用了rxjava框架，rxjava对于线程及其逻辑优化确实牛逼，但是使用不当也会引起内存泄露：activity的finsh并不能即时停止rxjava放到io线程里面逻辑执行，所以此时如果activity停止的时候没有解除订阅，rxjava待io执行完毕后还会将结果发送到ui县城里面执行，此时会造成内存泄露，解决方法很简单，io不能及时停止，将其所有订阅解除即可，解除方法通过CompositeDisposable添加解除或者参考下面文章参考。
 
3.2. 内存技术优化
 
针对内存可以做下面几种优化(下面优化后多数app的内存会得到很大的提升)：
 
3.2.1. 规范编码，平时编码过程中多加注意内存的问题，在功能提测时，根据Android studio工具进行检测功能模块涉及到页面的内存，检测是否有内存泄露和内存占有量比较大的类，即时修改规范。
 
3.2.2. 取合适大小的服务端图片(内存优化的头等大事)，oom多数都是图片造成的，app的view也都是有大小的，过大的图片除了浪费流量以外也在浪费这用户的内存。对此多数cdn服务都会提供相应的服务(以七牛为例)：
 
图片缩放，旋转，裁剪
 
获取图片格式，大小，色彩模型信息(对此头像有利，不需要再特殊的处理)
 
转换图像文件格式
 
图片添加水印
 
计算图片的平均色调
 
上面功能实现也很方便，多数都是设置一个参数即可，但是图片如果在不同的cdn服务器上app和服务端之间需要做协议支撑。
 
3.2.3. 图片加载框架的优化：
 
根据不同性能的手机手动设置框架的内存缓存大小，当前以glide为例进行图片框架优化。即：
 
动态设置glide的内存缓存池，多数图片加载框架都是内存，硬盘双缓存，glide在此基础上还有一个bitmap内存缓存提升最近使用图片的加载速度，glide是通过手机系统的内存大小比例值计算设置的，平时不建议修改，但是内存吃紧的时候，可以比glide自己计算所得小的内存设置，减少内存缓存。
 
根据手机内存系统大小动态设置图片的解析字节数，低内存是565，高内存8888，这样低内存可以缩减一半内存。
 
glide框架提供了clearMemory()和trimMemory()两个内存处理api，方便系统api onLowMemory和onTrimMemory()时使用。同样可以在这两个系统api中设置解析字节数565也可以一定程度上解决内存溢出的问题。
 
避免使用圆角图片，可以利用Glide提供的圆角转换，这样可以节省imageview中的圆角转换，减少内存的使用。
 
结合上面的，view并不需要原图，上面是传递宽高交由cdn三方存储对图片进行切割，相反，在view层也可以处理，glide支持设置view宽高进行裁剪图片后存储。相比还是前种更好，节省流量，小图片相对解析也快。
 
3.2.4. webview的优化：
 
webview提供了onpause，onresume，freememery等api，可以在页面生命周期内调用尽可能做内存回收的处理
 
不再使用webview的时候，更深程度的去回收webview所占的内存，即：
 

 
webview的更深程度优化
 
3.2.5. 针对app做一些具体的内存回收的优化：
 
针对首页多tab，及其新闻系app(某个tab又有很多的tab)，此时某个tab不再使用的时候，可以将其页面中的图片回收掉(多数是viewpager，可以在其adapter中处理)
 
针对recyclerview可以做下面几项优化处理：
 
android针对recyclerview提供了RecycledViewPool，对其每一类型的item都可以设置其对应的数量，合适的item数量有两方面的提升，一是减少itemview的创建极可能复用itemview，还有结合下面的操作可以优化内存。
 
recyclerview的adapter提供一个api叫做 onViewRecycler，结合上面，在itemview回收的时候掉用，此时可以将itemview涉及到的图片url置空(外在不再引用图片框架的资源，在下一次加载的时候缓存池才能及时的释放掉资源)
 
对于此还有很大的优化空间，学习有限，欢迎各路大神来吐槽和指教。
 
3.2.6. 内存运营及其设计方面的优化：
 
做开发做的久了，除了问题总是在想自己的问题，对于内存优化，运营和设计方面的优化有时候比某个技术体现的更明显(此处记录下面一些优化的点)：
 
不影响体验的前提下，尽可能的压缩服务端图片的大小
 
结合app的安转终端，对于图片大小指定合适的图片规范，例如bannner图片重点1080情况下提供1080图即可(甚至720图也可以)，没必要为了追求清晰出1440的图
 
产品UI设计：通过Android studio提供的内存分析工具可以很方便的看到每一个页面占有的内存的大小，针对占用内存比较大的页面可以优先看一下UI设计，是不是有优化的空间(通常会有惊喜)
 
参考文章：
 
小伙伴们，若是把你从坑里拉出来，别忘了赞赏一下小弟，加个关注也好奥

 
android开发内存优化之如何有效避免oom
 
时间：2017-02-22     来源：移动互联网学院
 

 
在Android开发中,特别是一些图片数量特别大特别多的项目中，经常会遇到OOM也就是OutOfMemoryError，那么我们在实际的android开发内存优化中如何有效避免oom呢?
 
一.上面说到图片多的应用容易发生oom,这里就要提到一个内存优化必须提到的吃内存的大胖子bitmap,通常我们在开发中通过下面两种方式来优化
 
1.在图片载入内存之前计算合适的缩放比例,避免大图的载入浪费内存
 
2.使用更加节省内存的解码方式,ARGB_8888比RBG_565所需的内存要大一倍
 
3.bitmap要及时回收
 
二.在数据结构上
 
1.减少内存的开销要尽量使用更加轻量型的数据结构,我们要优先考虑android专用的ArrayMap和SparseArray数据结构而不是HashMap等传统型的数据结构,传统型数据结构效率低下更占内存
 
2.在android开发中要避免使用Enum,也就是枚举
 
3.在字符串拼接中尽量使用StringBuilder而不是"+"
 
三.在向res里添加图片资源时,尺寸,大小,清晰度都要考虑,力争适合的尺寸,小的占存好的清晰度
 
四.直接引用android本身内置的资源
 
Android系统本身内置了很多的资源，例如字符串/颜色/图片/动画/样式以及简单布局等等，这些资源都可以在应用程序中直接引用。这样做不仅仅可以减少应用程序的自身负重，减小APK的大小，另外还可以一定程度上减少内存的开销，复用性更好。但是也有必要留意Android系统的版本差异性，对那些不同系统版本上表现存在很大差异，不符合需求的情况，还是需要应用程序自身内置进去。
 
五.列表控件的使用
 
列表控件的使用优化listview,gridview,recyclerview等 使用viewholder对convertview的复用等
 
六.避免对象的内存泄漏
 
使用leakcanary等第三方开源控件对APP内存泄漏的检测
 
1.能使用application的context就不要使用activity的context,可以避免activity不能释放而导致的泄漏
 
2.webview的泄漏问题在android比较严重,因为碎片化严重,不同版本不同厂家的webview都有差别,这里提供一个解决webview泄漏的方案http://www.jianshu.com/p/bb778d5959e2
 
3.操作数据库时会用到cursor对象,cursor对象一定要及时关闭否则会泄露
 
七.优化布局层次
 
优化布局层次,减少内存消耗,越扁平化的视图布局，占用的内存就越少，效率越高。我们需要尽量保证布局足够扁平化，当使用系统提供的View无法实现足够扁平的时候考虑使用自定义View来达到目的。
 
八.谨慎使用依赖注入框架和第三方library,这些都会增大内存的消耗

 
 
1）OOM解析
 
首先你要明白Android系统会为每一个应用程序创建一个Dalvik虚拟机实例然后创建一个进程接着创建主线程，这样就组成了一个应用。那么创建一个虚拟机就会考虑到为每一个虚拟机分配内存DalvikHeap size，不同性能手机内存大小分配不同，早期有些机器分配16M也有些是24M，当然DalvikHeap size是一个区间有它最大阈值（可使用adb命令进行查看最大分配内存：adbshell getprop dalvik.vm.heapsize），当应用程序占用内存超过这个阈值就好引发OutOfMemoryError（俗称OOM）。出现OOM主要是应用内存申请越积越多，gc未来及回收从而超过Heapsize最大阈值。
 
主要有以下情况：
 
1、加载图片对象过大；
 
2、资源过多，来不及加载；
 
3、大量内存泄漏未释放。
 
常见避免OOM方案：
 
1、加载图片时如果图片过大适当调整图像大小做压缩处理；
 
2、图像采用低内存占用量的编码方式：Bitmap.Config.ARGB_4444；
 
3、加载网络图像采用2级缓存一般第三方都已经封装好了；
 
4、大量本地图片内存引用采用软引用；
 
5、Listview的Adapter重用缓存convertView传递给getView()避免重复inflate，使用ViewHolder模式来避免没有必要的调用findViewById从而减少内存消耗；
 
6、尽量避免内存泄漏（内存泄漏比较多放在下面在做详细介绍）；
 
7、自定义堆内存分配大小，优化Dalvik虚拟机的堆内存分配；
 
2）内存泄漏解析
 
JAVA垃圾回收(garbagecollection，简称GC)去处理堆内存的回收，但如果对象一直被引用无法被回收，造成内存的浪费，无法再被使用，就造成了内存泄漏。
 
常见内存泄漏：
 
1、单例导致内存泄露主要是传入了Activity、Service的Context作为成员变量导致内存泄漏，可使用context.getApplicationContext()解决内存泄漏；
 
2、Activity的非静态内部了和匿名类，他们都持有Activity的引用容易导致内存泄漏，典型的Handler内部类持有Activity的引用，可以使用静态内部类软引用解除内部类对Activity的引用，从而解决内存泄漏；
 
3、Bitmap使用完未调用recycle()，导致内存泄漏，可在结束加上recycle()解决；
 
4、.数据库的cursor没有关闭，在结束关闭可解决；
 
5、调用register注册没有解绑，在结束后调用unregister解绑可解决；
 
6、Socket及IO没有关闭，在结束后关闭可解决；
 
7、Webview结束未销毁，在结束后销毁可解决。
 
mWebViewContainer.removeView(mWebView);
mWebView.stopLoading(); 
mWebView.getSettings().setJavaScriptEnabled(false);
mWebView.clearHistory();
mWebView.removeAllViews(); 
mWebView.destroy();
 
欢迎关注微信公众号！你的每个赞和在看，都是对我的支持！👍