查看原文
其他

复杂UI卡顿问题没想到还能这么优化?

普通的程序员 郭霖 2020-10-29


/   今日科技快讯   /


昨天晚上,两年一度的在线写代码圆满收官。一共直播了近两个半小时(原预计一小时 ),最高在线人数5200人。聊了聊新书,讲了讲技术,回答了一些大家的问题,感觉还是挺开心的。至于很多人关心的录播问题,如果是现在就想看录播的话,可以直接去昨天直播间的地址去看,已经有录播回放了。但是直播间的录播视频比较模糊,过几天图灵会将高清录播视频上传到bilibili,到时我也会将视频地址在公众号里放出。


/   作者简介   /



今天是周五,要祝大家单休愉快了,因为本周日记得是要上班的!

本篇文章来自普通的程序员的投稿,分享了他对异步加载View的一些思路,相信会对大家有所帮助!同时也感谢作者贡献的精彩文章。


普通的程序员的博客地址:

https://www.jianshu.com/u/38b409cda5af


/   背景及目标   /


最近在做性能优化工作,代码实际上已经经过几代人的优化,已经做了大量的 按需加载(懒加载),布局ViewStub优化,层级优化,代码质量也很高,检查了没有多余的耗时操作(业务上的无法避免的数据请求带来的耗时操作已尽可能减少)。


但是因为涉及的行业特殊,整个业务很复杂,界面里充满大量的自定义view。现在就是通过工具查到了其中某个方法,该方法会解析某个布局(布局内有n个自定义view),测试会卡住主线程800+ms,现在就需要对这个方法进行优化。


/   理论基础   /


需要至少对以下三点基础理论有了解。


  1. 切换线程的基础技能;

  2. 官方提供的AsyncLayoutInflater

  3. ViewStub,merge操作及View初始化操作


/   流程分析   /


大家都知道在Android中,只能在主线程操作UI原因是:



具体这个mThread是什么时候传入的,这个checkTread方法什么时候调用的,大家去看ViewRootImpl的源码,一步一步跟,这里不赘述。


那博主今天在这里吹什么牛比呢?


『只能在主线程操作UI』 这句话你细品,假如我不操作UI,只inflate View行不行?答案当然是可以的,官方提供的AsyncLayoutInflater 就是这样的操作。内部实现很简单,把需要加载的 Layout.xml的包装成一个任务,内部线程inflate解析,解析完毕再通过handler通知到主线程。



换句话说,操作UI的行为,是指要内部调用到checkThread的行为。由于AsyncLayoutInflater只在高于API 24的版本有用,那么我们就借助这个思路,仿照它来完成性能优化工作。


/  具体操作  /


我们以一个简单的demo来模拟这个需求,顺便看看源码。


就一个MainActivty, 主界面布局一个button,按一下把功能view加载到主界面。


<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical"
    tools:context=".MainActivity">

    <Button
        android:id="@+id/btn"
        android:layout_width="100dp"
        android:layout_height="50dp"
        android:gravity="center"
        android:text="Hello World!" />

    <ViewStub
        android:id="@+id/viewStub"
        android:layout="@layout/realview"
        android:layout_width="match_parent"
        android:layout_height="200dp" />
</LinearLayout>


我们假设这个realview是一个巨复杂的view(或者里面的自定义view初始化里有耗时方法)。


<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <View
        android:layout_width="200dp"
        android:layout_height="200dp"
        android:background="#fcc" />
</RelativeLayout>


就这么一个例子,点击按钮加载viewStub。


public class MainActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        findViewById(R.id.btn).setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                addViewInNormalWay();
            }
        });
    }

    public void addViewInNormalWay(){
        ViewStub viewStub = findViewById(R.id.viewStub);
        viewStub.inflate();
    }
}


假如我们直接开子线程把这个viewStub,100%抛出异常。


Schedulers.io().scheduleDirect(new Runnable() {
                    @Override
                    public void run() {
                        addViewInNormalWay();
                    }
                });


原因是ViewStub的inflate()方法内部,replaceSelfWithView()调用了requestLayout,这部分checkThread。



我们借助AsyncLayoutInflater的思想,把ViewStub.inflate()内部拆开,inflateViewNoAdd()放到子线程解析,解析完毕再回到主线程替换目标view。但是这样需要对布局进行更改:



原始的ViewStub占位需要替换成View。


public class MainActivity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        findViewById(R.id.btn).setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                addView();
            }
        });
    }

    private void addView() {
        Disposable d = Single
                .create(new SingleOnSubscribe<View>() {
                    @Override
                    public void subscribe(SingleEmitter<View> emitter) throws Exception {
                        View view = getLayoutInflater().inflate(R.layout.realview, null);
                        emitter.onSuccess(view);//只做inflated 解析xml的操作
                    }
                })
                .subscribeOn(Schedulers.io())
                .observeOn(AndroidSchedulers.mainThread())
                .subscribe(new Consumer<View>() {
                    @Override
                    public void accept(View view) throws Exception {
                        View stub = findViewById(R.id.viewStub);
                        if (stub == null) return;
                        ViewGroup parent = (ViewGroup) stub.getParent();
                        int index = parent.indexOfChild(stub);//找到原始占位view
                        ViewGroup.LayoutParams vlp = stub.getLayoutParams();//拿到lp
                        view.setLayoutParams(vlp);//把lp给到新view
                        parent.removeViewAt(index);//从树里删除
                        parent.addView(view, index);//替换上去
                    }
                });

    }
}


这里有个细节,LayoutInflater.inflate()一共有4种。



建议root传null,不传null的话,attach一定要传false。因为realview的顶层layout 宽高属性会丢失,补救策略就是再套一层layout,或者在外部view就指定宽高属性。




/   风险提示   /


原来的ViewStub要替换成一个占位View,这样就会破坏原有的布局优化策略;被inflate的View,根标签不能用merge,原因去看inflate源码;不保证你的功能view里面有奇奇怪怪的操作,这些都会导致子线程解析失败。


这些奇奇怪怪的操作有(包括但不限于):


  1. 在异步inflated的布局,其 parent 的 generateLayoutParams 函数必须要是线程安全的;

  2. 所有构建的 View 中必须不能创建 Handler 或者是调用 Looper.loop, 因为子线程默认没有 Looper.prepare()。补救措施,找到出错的自定义view,初始化handler请加上 Looper.getMainLooper() 参数;

  3. 实现了诸如GestureDetector组件,这些组件内部会初始化handler,报错原因见第二条,补救措施,在自定义view里,对这些组件的初始化请切换到主线程。


/   最后   /


谷歌不推荐在子线程操作UI的原因有很多,比如多线程多次inflate ,风险还是有的。现在找到卡顿的原因就是 inflate自定义view耗时,采用这套方案后该方法耗时120ms。风险跟收益,各位自己评估。


推荐阅读:

这本《第三行代码》,让大家久等了!

什么?这个天天使用的API竟然被废弃了?

事件分发机制,我们从细节中学习!


欢迎关注我的公众号

学习技术或投稿



长按上图,识别图中二维码即可关注


    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存