基本的优化总结（一）

导言

首先说一下个人的思考，为什么要做优化？
1.差异性：同样的功能，你的更加流畅、易于使用，那么就会有一定的用户粘性，因为更换使用习惯是一个很大成本的事情
2.个人成长性：前期满足于做出这个功能，后期如何继续成长，那么简单说就是做的更好，这也是工程师的自我修养

Systrace

分析自然离不开工具和数据，好在Google默认已经提供了一些强大的工具来帮助开发者进行分析，UI方面常用的就是Systrace，从一个大家都熟悉的例子上面来分析，比方说大家都知道的ListView的基本优化操作

先看一个没优化的情况

override fun getView(position: Int, convertView: View?, parent: ViewGroup?): View? {
        val newView = mInflater?.inflate(R.layout.item_person,parent,false)
        if(newView == null){
            return null
        }
        val mNameView = newView.findViewById(R.id.tv_name) as TextView
        val mAgeView = newView.findViewById(R.id.tv_age) as TextView
        val mSexView = newView.findViewById(R.id.tv_sex) as TextView
        val mStatusView = newView.findViewById(R.id.tv_status) as TextView

        val person = getItem(position) as Person
        mNameView.text = person.name
        mAgeView.text = "" + person.age + "岁"
        if(person.sex == 1) {
            mSexView.text = "男"
        }else{
            mSexView.text = "女"
        }
        mStatusView.text = person.status
        return newView
    }

接着看看Systrace中反馈的数据

Systrace的部分截图
inflate的耗时截图

根据Google的教程，我们知道Android的绘制机制实际上一秒刷新60次，也就是说一帧有16.67ms的时间进行计算，然后再在下一帧的时候显示。如果超出这个时间，那么就是发生了掉帧的情况，掉帧我们知道，其实就是卡顿
那么上面的数据可以看到，这一帧的处理足足花了20ms的时间，也就是说出现掉了一帧的场景，从Systrace中可以看出，inflate占了处理时间的大头，也就是说这一块有一定的优化空间，所以也就出现了后面的改良版

override fun getView(position: Int, convertView: View?, parent: ViewGroup?): View? {
        var newView:View? = convertView
        val viewHolder:ViewHolder
        if(null == newView){
            newView = mInflater?.inflate(R.layout.item_person,parent,false)
            viewHolder = ViewHolder(newView!!)
            newView.tag = viewHolder
        }else{
            viewHolder = newView.tag as ViewHolder
        }
        val person = getItem(position) as Person
        viewHolder.mNameView.text = person.name
        viewHolder.mAgeView.text = "" + person.age + "岁"
        if(person.sex == 1) {
            viewHolder.mSexView.text = "男"
        }else{
            viewHolder.mSexView.text = "女"
        }
        viewHolder.mStatusView.text = person.status
        return newView
    }

class ViewHolder{
        var mNameView:TextView
        var mAgeView:TextView
        var mSexView:TextView
        var mStatusView:TextView

        constructor(view:View){
            mNameView = view.findViewById(R.id.tv_name)
            mAgeView = view.findViewById(R.id.tv_age)
            mSexView = view.findViewById(R.id.tv_sex)
            mStatusView = view.findViewById(R.id.tv_status)
        }

    }

实际上做了两件事情，第一就是尝试复用convertView，这样的好处就是减少inflate的次数，第二就是通过viewholder减少了findViewByID的次数，然后通过Systrace来看看效果

Systrace的部分截图
obtainView的耗时

从结果上来看是非常喜人的，在obtainView没有进行inflate等操作的情况下，整个的执行时间能够降到7ms左右，当然有一点要注意，初始化的inflate肯定是不能节省的，所以说view的复用是非常的重要的事情

常规使用模式

其实Systrace本身已经带了问题分析，它会分析某一帧中出现的问题，并且显示在Alert中，这些地方就是值得我们去关注的，看一个例子

Alert截图

点击Scheduling delay看看

Scheduling delay截图
可以看到，上面有这一帧UI线程的实际运行时间以及沉睡的时间，可以看到实际只执行了14ms的时间，但是大部分时间都让给了其它线程执行，所以说Description中提供的建议就是尽量减低后台线程的优先级，从而避免过多的打断UI线程，从而尝试增加UI线程实际执行的时间
帧实例

看一下这一帧的截图，一共花了26ms，然后看最上面绿色的表示运行中，白色的就是sleeping中，然后查看这一过程中发生了什么

GC截图
图中只是一种情况，但是据我个人观察来说确实在GC的时候会有一些UI线程在sleeping的操作，不过这个正常，因为GC的时候要挂起所有线程，这样才能标记和处理对象

总结

总的来说Systrace主要是用于分析掉帧问题，对于具体的某一些方法的耗时等问题，这个可能要用到TraceView会比较好一点
另外，个人觉得这篇文章很不错，可以借鉴一下http://blog.udinic.com/2015/09/15/speed-up-your-app

文章系列：
基本的优化总结（一）
基本的优化总结（二）
基本的优化总结（三）
基本的优化总结（四）
基本的优化总结（五）
基本的优化总结（六）
基本的优化总结（七）