Android性能优化的浅谈

一、概要：

　　　　本文主要以Android的渲染机制、UI优化、多线程的处理、缓存处理、电量优化以及代码规范等几方面来简述Android的性能优化

二、渲染机制的优化：

　　　　大多数用户感知到的卡顿等性能问题的最主要根源都是因为渲染性能。

　　　　Android系统每隔16ms发出VSYNC信号，触发对UI进行渲染， 如果每次渲染都成功，这样就能够达到流畅的画面所需要的60fps，为了能够实现60fps，这意味着程序的大多数操作都必须在16ms内完成。

　　　　

　　　　如果你的某个操作花费时间是24ms，系统在得到VSYNC信号的时候就无法进行正常渲染，这样就发生了丢帧现象。那么用户在32ms内看到的会是同一帧画面。

　　　　

　　　　Probably：也许是因为你的layout太过复杂，无法在16ms内完成渲染，有可能是因为你的UI上有层叠太多的绘制单元，还有可能是因为动画执行 的次数过多。这些都会导致CPU或者GPU负载过重。

　　　　Resolved：我们可以通过一些工具来定位问题，比如可以使用HierarchyViewer来查找Activity中的布局是否过于复杂，也可以使用手机设置里 面的开发者选项，打开Show GPU Overdraw等选项进行观察。

　　　　　　　　　 你还可以使用TraceView来观察CPU的执行情况，更加快捷的找到性能瓶颈。

　　　　

　　　　浅谈Overdraw（过度绘制）：

　　　　　　Overdraw(过度绘制)描述的是屏幕上的某个像素在同一帧的时间内被绘制了多次。在多层次的UI结构里面，如果不可见的UI也在做绘制的操作，这就会导致某些像素区域被绘制了多次。这就浪费大量的CPU以及GPU资源。

　　　　　　

　　　　　　Tips：我们可以通过手机设置里面的开发者选项，打开Show GPU Overdraw的选项，可以观察UI上的Overdraw情况

　　　　　　

　　　　　　图解：蓝色，淡绿，淡红，深红代表了4种不同程度的Overdraw情况，我们的目标就是尽量减少红色Overdraw，看到更多的蓝色区域。

　　　　　　Tips：Overdraw有时候是因为你的UI布局存在大量重叠的部分，还有的时候是因为非必须的重叠背景。例如某个Activity有一个背景，然后里面 的Layout又有自己的背景，同时子View又分别有自己的背景。

　　　　　　仅仅是通过移除非必须的背景图片，这就能够减少大量的红色Overdraw区域，增加 蓝色区域的占比。这一措施能够显著提升程序性能。

　　　　　　注意：如需获取更多渲染机制的内容，请移步 https://www.oschina.net/news/60157/android-performance-patterns

三、UI方面的优化：

　　　　1）首先简单谈谈view的绘制流程：measure - layout - draw

　　　　

　　　　　　ps:具体的流程网上一搜一大把+_+

　　　　　2）子控件越多，绘制的时间也就越长。

　　　　　　对于Listview或者GridView这种多item的组件来说，复用item可以减少inflate次数，通过setTag，getTag的ViewHolder方式实现复用，这里要注意的是，holder中的控件最好reset后再赋值，避免图片，文字错乱。

　　　　　　*以下简单的例子：（尽量使用注解，有很多注解的开源框架可以使用：butterKnife, AndroidAnnotation, Dragger2）

 static class ViewHolder{
     @InjectView(R.id.imageView1)
     ImageView imageView1;
     @InjectView (R.id.text1)
     TextView textView1;
 }

 @Override
 public View getView(int position, View convertView, ViewGroup parent) {
     ViewHolder holder;

     if(convertView == null){
        holder = new ViewHolder();
        convertView = LayoutInflater.from(mContext).inflate(R.layout.listview_item, null);
        convertView.setTag(holder);
      }else{
          holder = (ViewHolder)convertView.getTag();
      }

          holder.imageView1.setImageResource(R.drawable.ic_launcher);
          holder.textView1.setText(mData.get(position));  

          return convertView;
 }

　　　　3）UI ReView（视图的检查）　

　　　　　　1. 减少视图层级可以有效的减少内存消耗，因为视图是一个树形结构，每次刷新和渲染都会遍历一次。

　　　　　　2. 想要减少视图层级首先就需要知道视图层级，所以下面介绍一个SDK中自带的一个非常好用的工具hierarchyviewer。你可以在下面的地址找到它：your sdk path\sdk\tools

　　　　　　

　　　　　　3. 如上图大家可以看到，hierarchyviewer可以非常清楚的看到当前视图的层级结构，并且可以查看视图的执行效率（视图上的小圆点，绿色表示流畅，黄色和红色次之），所以我们可以很方便的查看哪些view可能会影响我们的性能从而去进一步优化它。

　　　　　　　hierarchyviewer还提供另外一种列表式的查看方式，可以查看详细的屏幕画面，具体到像素级别的问题都可以通过它发现。

　　　　　　

　　　   4）一些标签的使用

　　　　　　<merge> ：它在优化UI结构时起到很重要的作用。目的是通过删减多余或者额外的层级，从而优化整个Android Layout的结构，优化布局层数。

　　　　　　<include > ：可以通过这个标签直接加载外部的xml到当前结构中，是复用UI资源的常用标签，来共享布局。

　　　　　　<ViewStub> : 动态加载view，此标签可以使UI在特殊情况下，直观效果类似于设置View的不可见性，但是其更大的意义在于被这个标签所包裹的Views在默认状态下不会占用任何内存空间。

四、多线程的处理：

　　　1. Android 提供的多种多线程工具类 (AsyncTask, HandlerThread, IntentService, ThreadPool)，许多操作都需要由 主线程（UI 线程）来执行，比如：

　　　　　　

　　　　　　2. Android 系统的屏幕刷新频率为 60 fps, 也就是每隔 16 ms 刷新一次。如果在某次绘制过程中，我们的操作不能在 16 ms 内完成，那它则不能赶上这次的绘制公交车，只能等下一轮。

　　　　　　 这种现象叫做 “掉帧”，用户看到的就是界面绘制不连续、卡顿。

　　　　　　

　　　　　　3. HandlerThread 就是MessageQueue，Looper和 Handler 的组合。每个应用启动时，系统会创建一个该应用的进程以及主线程，这里的主线程就是一个 HandlerThread。

　　　　　　

　　　　　　4. 注意问题：

　　　　　　　1）多线程并发访问资源要遵循重要的原则就是 原子性、可见性、有序性。没有同步机制的情况下，多个线程同时读写内存可能会导致意料之外的问题：

　　　　　　　①线程安全的问题； ② UI 组件的生命周期并不确定；③线程引用导致的内存泄漏问题

　　　　　     2）不要在任何子线程持有 UI 组件或者 Activity 的引用

　　　　　　 3）保持响应不发生ANR:

　　　　　　　　①从UI线程中移除费时操作这个方式还可以防止用户操作出现系统不响应（ANR）对话框。需要做的就是继承AsyncTask来创建一个后台工作线程，并实现doInBackground()方法。

　　　　　　　　②还有一种方式就是自己创建一个Thread类或者HandlerThread类，明确设定线程的优先级。

　　　　　　 4）使用StrictMode来检查UI线程中可能潜在的费时操作，使用一些特殊的工具如Safe.ijiami、Systrace或者Traceview来寻找在你的应用中的瓶颈；用进度条向用户展示操作进度。

五、缓存处理：

　　简单的说说缓存优化的几个方面：

　　　 缓存机制：网络+数据库。为了避免从网络获取重复的数据，可以在activity或者fragment或者每个组件设置一个最大请求间隔。

　　　　　　　　比如一个listview，第一次请求数据时，保存一份到数据库，并记下时间戳，当下次重新初始化时，判断是否超过最大时间间隔(如5分钟)，如果没有，只加载数据库数据，不需要再做网络请求。

　　　　　　　　（当然，还有一些隐式的http请求框架会缓存服务器数据，在一定时间内不再请求网络，或者当服务器返回304时将之前缓存的数据直接返回）

　

　　　网络方面：1）需要服务端配合的：json数据格式，WebP代替jpg，支持断点续传，多个请求合并成一个，尽量不做重定向，服务器缓存以及负载均衡等。

　　　　　　　　2）对客户端本身，除了上述的实现，我们还需要合理的缓存，控制最大请求并发量，及时取消已失效的请求，过滤重复请求，timeout时间设置，请求优先级设置等。

　　　　　　　　

　　　　　　　　* WebP：WebP 的优势体现在它具有更优的图像数据压缩算法，能带来更小的图片体积，而且拥有肉眼识别无差异的图像质量；

　　　　　　　　　　　　 同时具备了无损和有损的压缩模式、Alpha 透明以及动画的特性，在 JPEG 和 PNG 上的转化效果都相当优秀、稳定和统一。

　　　　　　　　　　　　 

　　　　　　　　　　　　   转换后的 WebP 支持 Alpha 透明和 24-bit 颜色数，不存在 PNG8 色彩不够丰富和在浏览器中可能会出现毛边的问题。

　　　　　　　　　　　　  * 更多了解请看：http://isux.tencent.com/introduction-of-webp.html

 六、电量优化：

　　　　有下面一些措施能够显著减少电量的消耗：

• • • 我们应该尽量减少唤醒屏幕的次数与持续的时间，使用WakeLock来处理唤醒的问题，能够正确执行唤醒操作并根据设定及时关闭操作进入睡眠状态。

    • 某些非必须马上执行的操作，例如上传歌曲，图片处理等，可以等到设备处于充电状态或者电量充足的时候才进行。

    • 触发网络请求的操作，每次都会保持无线信号持续一段时间，我们可以把零散的网络请求打包进行一次操作，避免过多的无线信号引起的电量消耗。

　　　　　　　　关于网络请求引起无线信号的电量消耗，还可以参考这里http://hukai.me/android-training-course-in-chinese/connectivity/efficient-downloads/efficient-network-access.html

　　　　

　　　　Ask：假设你的手机里面装了大量的社交类应用，即使手机处于待机状态，也会经常被这些应用唤醒用来检查同步新的数据信息。

　　　　Android会不断关闭各种硬 件来延长手机的待机时间，首先屏幕会逐渐变暗直至关闭，然后CPU进入睡眠，这一切操作都是为了节约宝贵的电量资源。但是即使在这种睡眠状态下，大多数应 用还是会尝试进行工作，他们将不断的唤醒手机。

　　　　一个最简单的唤醒手机的方法是使用PowerManager.WakeLock的API来保持CPU工作并 防止屏幕变暗关闭。这使得手机可以被唤醒，执行工作，然后回到睡眠状态。知道如何获取WakeLock是简单的，可是及时释放WakeLock也是非常重 要的。

　　　　不恰当的使用WakeLock会导致严重错误。例如网络请求的数据返回时间不确定，导致本来只需要10s的事情一直等待了1个小时，这样会使得电量 白白浪费了。这也是为何使用带超时参数的wakelock.acquice()方法是很关键的。

　　　　但是仅仅设置超时并不足够解决问题，例如设置多长的超时比 较合适？什么时候进行重试等等？

　　　　Resolved：解决上面的问题，正确的方式可能是使用非精准定时器。通常情况下，我们会设定一个时间进行某个操作，但是动态修改这个时间也许会更好。

　　　　例如，如果有 另外一个程序需要比你设定的时间晚5分钟唤醒，最好能够等到那个时候，两个任务捆绑一起同时进行，这就是非精确定时器的核心工作原理。我们可以定制计划的 任务，可是系统如果检测到一个更好的时间，它可以推迟你的任务，以节省电量消耗。

　　　　

　　　　* 关于JobScheduler的更多知识可以参考 http://hukai.me/android-training-course-in-chinese/background-jobs/scheduling/index.html

 七、代码规范

　　

　　　　1）for loop中不要声明临时变量，不到万不得已不要在里面写try catch。

　　　　2）明白垃圾回收机制，避免频繁GC，内存泄漏，OOM(有机会专门说)

　　　　3）合理使用数据类型，StringBuilder代替String，少用枚举enum，少用父类声明(List,Map)

　　　　4）如果你有频繁的new线程，那最好通过线程池去execute它们，减少线程创建开销。

　　　　5）你要知道单例的好处，并正确的使用它。

　　　　6）多用常量，少用显式的"action_key"，并维护一个常量类，别重复声明这些常量。

　　　　7）如果可以，至少要弄懂设计模式中的策略模式，组合模式，装饰模式，工厂模式，观察者模式，这些能帮助你合理的解耦，即使需求频繁变更，你也不用害怕牵一发而动全身。需求变更不可怕，可怕的是没有在写代码之前做合理的设计。

　　　　8）View中设置缓存属性.setDrawingCache为true.

　　　　9）cursor 的使用。不过要注意管理好cursor,不要每次打开关闭cursor.因为打开关闭Cursor非常耗时。 Cursor.require用于刷cursor.

　　　　10）采用SurfaceView在子线程刷新UI, 避免手势的处理和绘制在同一UI线程（普通View都这样做）

　　　　11）采用JNI，将耗时间的处理放到c/c++层来处理

　　　　12）有些能用文件操作的，尽量采用文件操作，文件操作的速度比数据库的操作要快10倍左右

　　　　13）懒加载和缓存机制。访问网络的耗时操作启动一个新线程来做，而不要再UI线程来做

　　　　14）如果方法用不到成员变量，可以把方法申明为static，性能会提高到15%到20%

　　　　15）避免使用getter/setter存取field，可以把field申明为public，直接访问

　　　　16）私有内部类要访问外部类的field或方法时,其成员变量不要用private，因为在编译时会生成setter/getter,影响性能。可以把外部类的field或方法声明为包访问权限

　　　　17）合理利用浮点数，浮点数比整型慢两倍

　　　　18）针对ListView的性能优化，ListView的背景色与cacheColorHint设置相同颜色，可以提高滑动时的渲染性能。ListView中getView是性能是关键，这里要尽可能的优化。

　　　　　　 getView方法中要重用view；getView方法中不能做复杂的逻辑计算，特别是数据库操作，否则会严重影响滑动时的性能

　　　　19）不用new关键词创建类的实例，用new关键词创建类的实例时，构造函数链中的所有构造函数都会被自动调用。但如果一个对象实现了Cloneable接口，我们可以调用它的clone()方法。

　　　　　　clone()方法不会调用任何类构造函数。在使用设计模式（Design Pattern）的场合，如果用Factory模式创建对象，则改用clone()方法创建新的对象实例非常简单。例如，下面是Factory模式的一个典型实现：

　　　　20）public static Credit getNewCredit() {
      　　　　　　return new Credit();
　　　　　　}
　　　　　　改进后的代码使用clone()方法，如下所示：
　　　　　　private static Credit BaseCredit = new Credit();
     　　　　　　 public static Credit getNewCredit() {
          　　　　　　  return (Credit) BaseCredit.clone();
      　　　　　　}
　　　　上面的思路对于数组处理同样很有用。

　　　　21）乘法和除法

　　　　　　考虑下面的代码：

1. 1. for (val = 0; val < 100000; val +=5) { alterX = val * 8; myResult = val * 2; }
      用移位操作替代乘法操作可以极大地提高性能。下面是修改后的代码：
      for (val = 0; val < 100000; val += 5) { alterX = val << 3; myResult = val << 1; }

　　　　22）ViewPager同时缓存page数最好为最小值3，如果过多，那么第一次显示时，ViewPager所初始化的pager就会很多，这样pager累积渲染耗时就会增多，看起来就卡。

　　　　23）每个pager应该只在显示时才加载网络或数据库(UserVisibleHint=true)，最好不要预加载数据，以免造成浪费

     24）提高下载速度：要控制好同时下载的最大任务数，同时给InputStream再包一层缓冲流会更快(如BufferedInputStream)

　　　　25）提供加载速度：让服务端提供不同分辨率的图片才是最好的解决方案。还有合理使用内存缓存，使用开源的框架