Android 之性能优化
1：总体上分为以下几方面
1：布局优化，减少布局间的嵌套，多使用RelativeLayout，避免过度绘制。
以及多使用include，ViewStub 等标签。
一、查看是否存在过度绘制
1. GPU过渡绘制:对于过度绘制的测试主要通过人工进行测试，也是发现应用过渡绘制的首选途径 .通过打开开发者选项中的 显示GPU过度绘制(魅族手机:设置—辅助功能–开发人员工具–硬件加速渲染—调试GPU过渡绘制— 显示过渡绘制区域.）来进行测试（PS：只有android4.2及以上的版本才具备此功能)
1. 颜色标识: 从好到差:蓝-绿-淡红-红
1. 蓝色1x过度绘制
2. 绿色2x过度绘制
3. 淡红色3x过度绘制
4. 红色超过4x过度绘制
2. 验收标准:
1. 控制过度绘制为2x
2. 不允许存在4x过度绘制
3. 不允许存在面积超过屏幕1/4区域的3x过度绘制（淡红色区域）
布局优化重点就是减少布局间的嵌套，以避免过度绘制，如果布局不能在一定的时间内绘制出来的话，我们人眼就会识别到卡顿，也就是丢帧的现象。
2：就是图片的问题，
图片是最容易导致我们程序发生oom,导致内存占用过大，以至于崩溃的现象。
如何解决这个问题呢？ 首先我们在使用图片资源的时候都把它放在，draw-xxxhdpi下面。这样我们就可以用一套切图就都满足了。这样也就节省了内存空间，以及apk包的大小。
在我们APP上肯定会加载很多的图片，图片又分为三种格式 一种是 ARGB-888 这种图片是每个像素占4个字节，加载的是高清图片，是最费资源的，
第二种是 RGB-565 的每个像素占2个字节 加载时高清图片，是比较节省资源的，因为我们加载图片用的是Glide,他默认的就是加载这种格式的图片，图片既不失真又是节省资源。
第三种是 ARGB_4444 这种图片也是占两个字节，但是加载的图片清晰度不高，模糊，所以不推荐使用
还有就是图片的压缩，图片的压缩一般用在上传图片的时候，图片压缩又分为尺寸压缩以及质量压缩。一般用到了 BitmapFactory.Options 这个方法。
3 就是代码问题，关于一些变量的引用，上下文的引用以及一些组件的使用问题了。
http://blog.csdn.net/tuke_tuke/article/details/52316285 这个网址有关于内存优化挺详细的解释。
1、万恶的static
static是个好东西，声明赋值调用就是那么的简单方便，但是伴随而来的还有性能问题。由于static声明变量的生命周期其实是和APP的生命周期一 样的，有点类似与Application。如果大量的使用的话，就会占据内存空间不释放，积少成多也会造成内存的不断开销，直至挂掉。static的合理 使用一般用来修饰基本数据类型或者轻量级对象，尽量避免修复集合或者大对象，常用作修饰全局配置项、工具类方法、内部类。
2、无关引用
很多情况下，我们需求用到传递引用，但是我们无法确保引用传递出去后能否及时的回收。比如比较有代表性的Context泄漏，很多情况下当Activity 结束掉后，由于仍被其他的对象指向导致一直迟迟不能回收，这就造成了内存泄漏。关于Context 如果不好好用的话就会造成内存泄露
1：这里举例说明下this,context,以及ApplicationContext();
this,代表本类，跟随activity的生命周期，随着页面的销毁而销毁，所以尽量的使用this。
2：ApplicationContext() 这个是全局的上下文对象，随着APP的销毁而销毁的。
内存泄露的原因就是系统的gc垃圾回收机制回收不了，因为当activity销毁后，还在持有这个类的引用的话，gc就不会去回收它，所有一点一点的造成了泄露，导致了内存溢出，oom了
垃圾回收机制也要自己了解下，但时候能说出来一点原理就行