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，此处通过反射的方式再反射一次即可：
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所占的内存，即：
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 开发绕不过的坑：你的 Bitmap 究竟占多大内存？
小伙伴们，若是把你从坑里拉出来，别忘了赞赏一下小弟，加个关注也好奥
