1.内存优化
方案一:
修改android-studio/bin目录下的studio64.vmoptions和studio.vmoptions文件
Xms，Xmx，-XX:MaxPermSize，-XX:ReservedCodeCacheSize根据电脑内存修改大一些
-Xms1024m
-Xmx1096m
-XX:MaxPermSize=1024m
-XX:ReservedCodeCacheSize=1024m
方案二:
1）降低运行时内存
降低运行时内存可以分为减小APK的体积和Bitmap优化两部分
1> 减小APK体积
去除无用的资源和代码，通过合理使用git，一些由于业务变更而基本不会用到的代码，该删除的绝不能手软。即使以后要用到，通过git也能找回。同时一些图片资源未用到的也应该删除，因为即使gradle配了sharkresource选项，发布的时候这些没有用到的图片依然会被打包到你的apk。
尽量复用资源，其实这是一种比较好的编码习惯。
对应用的启动图引导页图片进行压缩，往往这些图片占据了大部分空间，压缩后可以起到很好的效果。平时开发中对于分辨率大雨100*100的图片基本上都会进行压缩，很多好的压缩算法经常可以减少一半的大小，而感官上基本看不出有任何改变。
2>Bitmap优化
统一的bitmap加载器，选择Glide、Fresco、Picasso中的一个作为图片加载框架。实际开发中加载到view的图片的大小不应该超过view的大小，图片加载框架默认会对图片进行缓存，按view实际大小加载。在开发中为了减少apk的大小，一般只放一套3X图片，但是这些图片在小分辨率的手机上直接加载就会出现内存浪费。统一的bitmap加载器就可以很好的解决该问题。
图片存在像素浪费，对于.9图，美工可能在出图时在拉伸与非拉伸区域都有大量的像素重复。而这些图片是可以缩小，但并不影响显示效果。
inSampleSize:缩放比例，在把图片载入内存之前，我们需要计算一个合适的缩放比例，避免不必要的大图载入。
选择ARGB_8888/RBG_565/ARGB_4444/ALPHA_8，存在很大差异。
inBitmap：这个参数用来实现Bitmap内存的复用，但复用存在一些限制，具体体现在：在Android 4.4之前只能重用相同大小的Bitmap的内存，而Android 4.4及以后版本则只要后来的Bitmap比之前的小即可。使用inBitmap参数前，每创建一个Bitmap对象都会分配一块内存供其使用，而使用了inBitmap参数后，多个Bitmap可以复用一块内存，这样可以提高性能。
Android 官网文档Managing Bitmap Memory、Handling bitmaps
2）代码优化
1>考虑使用ArrayMap/SpareseArray而不是传统的HashMap等数据结构，Android系统为移动系统设计的容器ArrayMap更加高效，占用内存更少，因为HashMap需要一个额外的实例对象来记录Mapping的操作。而SparesArray高效的避免了key和value的自动装箱，而且避免了装箱后的解箱。详细参考Android性能优化典范
2>在onDraw这种频繁调用的方法要避免对象的创建操作，因为他会迅速增加内存的使用，引起频繁的gc，甚至内存抖动。
3>SoftReference(软引用)、WeakReference(弱引用)、PhantomReference(虚引用)
SoftReference：如果一个对象只具有软引用，则内存空间足够，垃圾回收器就不会回收它；如果内存空间不足了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使用。软引用可用来实现内存敏感的高速缓存。
WeakReference：与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程，因此不一定会很快发现那些只具有弱引用的对象。作者：10年Android开发链接：//www.greatytc.com/p/8ee81d5ff770来源：简书简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。
PhantomReference：虚引用”顾名思义，就是形同虚设，与其他几种引用都不同，虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收器回收。虚引用主要用来跟踪对象被垃圾回收器回收的活动。虚引用与软引用和弱引用的一个区别在于：虚引用必须和引用队列 （ReferenceQueue）联合使用。当垃圾回收器准备回收一个对象时，如果发现它还有虚引用，就会在回收对象的内存之前，把这个虚引用加入到与之 关联的引用队列中。作者：10年Android开发链接：//www.greatytc.com/p/8ee81d5ff770来源：简书简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。
4>谨慎使用large heap，android设备由于软硬件的差异，heap阀值不同，特殊情况下可以在manifest中使用largeheap=true声明一个更大的heap空间，使用getLargeMemoryClass()来获取到这个更大的空间。但是要谨慎使用，因为额外的空间会影响到系统整体的用户体验，切换任务时性能大打折扣，对于oom异常是治标不治本的一种做法。
5>谨慎使用多进程，使用多进程可以把应用中的部分组件运行在单独的进程当中，这样可以扩大应用的内存占用范围，但是这个技术必须谨慎使用，绝大多数应用都不应该贸然使用多进程，一方面是因为使用多进程会使得代码逻辑更加复杂，另外如果使用不当，它可能反而会导致显著增加内存。当你的应用需要运行一个常驻后台的任务，而且这个任务并不轻量，可以考虑使用这个技术，一个典型的例子是创建一个可以长时间后台播放的Music Player。如果整个应用都运行在一个进程中，当后台播放的时候，前台的那些UI资源也没有办法得到释放。类似这样的应用可以切分成2个进程：一个用来操作UI，另外一个给后台的Service。
6>考虑第三方库的大小，如果会和现有的代码或其他库的代码重复，考虑不要真个引入而是把库的代码精简之后再引入。
3）内存泄漏优化
内存泄漏的原因有很多，下面介绍一些常见的，我们需要在开发中多注意:
1>Activity调用了finish，但是引用Activity的对象未被释放(生命周期没有结束)，Activity Context被传递到其他实例中，可能导致自身被引用而发生泄露，建议使用weakReferce。
2>除必须使用Activity Context的情况(Dialog的context必须是Activity),我们可以使用Application Context来避免Activity泄露。
3>大多数情况下，我们对Bitmap对象增加缓存机制，但是有时候部分bitmap需要及时回收。比如我们临时创建的摸个相对大的bitmap对象，变换得到新的bitmap对象后，尽快回收原始的bitmap，及时释放原来的空间。
4>webview引起的内存泄漏主要是因为org.chromium.android_webview.AwContents 类中注册了component callbacks，但是未正常反注册而导致的。让onDetachedFromWindow先走，在主动调用destroy()之前，把webview从它的parent上面移除掉(Basewebfragment onDestroy())
5>虽然单例模式简单实用，提供了很多便利性，但是因为单例的生命周期和应用保持一致，使用不合理很容易出现持有对象的泄漏。
6>我们在对数据库进行操作时，使用完cursor没有及时关闭，cursor的泄露，会对内存管理带来负面影响。
7>谨慎使用static对象，因为static的生命周期过长，和应用的进程保持一致，使用不当很可能导致对象泄漏。
总结
在实际的线上环境中发现，大部分内存泄漏是因为被调用的对象生命周期不同步导致，生命周期不同步不仅仅会导致内存泄漏，更会出现异常，崩溃等更严重的问题。
