已经在郭霖老师公众号发布，不再投递其他公众号，转载请务必标明来源。
https://mp.weixin.qq.com/s/haV2Bp5MyEw5pXaheBJRhA

防杠

能解决view本身的问题就去解决view本身的问题，这是治根，我这个方案无法解决view本身的问题。
如果你们也有很多上古view是因为业务要求，时间要求，最终导致你们没法治根，
那这个就是帮你们快速解决block主线程卡顿的方案。
当然，这个方案也无法降低cpu开销，你们走投无路的时候可以拿这个方案试试，仅此提供给你们一个思路。

背景及目标

最近在做性能优化工作，代码实际上已经经过几代人的优化，已经做了大量的按需加载（懒加载），布局ViewStub优化，层级优化，代码质量也很高，检查了没有多余的耗时操作（业务上的无法避免的数据请求带来的耗时操作已尽可能减少）。
但是因为涉及的行业特殊，整个业务很复杂，界面里充满大量的自定义view。
现在就是通过工具查到了其中某个方法，该方法会解析某个布局（布局内有n个自定义view），
测试会卡住主线程800+ms，现在就需要对这个方法进行优化。

理论基础

需要至少对以下三点基础理论有了解。
1.切换线程的基础技能；

2.官方提供的AsyncLayoutInflater
源码链接
http://androidxref.com/9.0.0_r3/xref/frameworks/support/asynclayoutinflater/src/main/java/androidx/asynclayoutinflater/view/AsyncLayoutInflater.java

3.ViewStub，merge操作及View初始化操作
https://www.jianshu.com/p/68717519c4a5

流程分析

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

image.png

具体这个mThread是什么时候传入的，这个checkTread方法什么时候调用的，
https://mp.weixin.qq.com/s/tg96p50alrqAtRih8a3AhA

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

『只能在主线程操作UI』这句话你细品，假如我不操作UI，只inflate View行不行？答案当然是可以的，官方提供的AsyncLayoutInflater 就是这样的操作。
（再多比比一句，准确的说，只能在主线程操作UI不太准确，准确的说法见这篇文章分析https://www.jianshu.com/p/3f03a26d247a）
内部实现很简单，把需要加载的 Layout.xml的包装成一个任务，内部线程inflate解析，解析完毕再通过handler通知到主线程。

image.png

换句话说，操作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。

但是这样需要对布局进行更改

image.png

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

在子线程中把目标view解析,解析完毕再替换目标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种

image.png

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

image.png

风险提示

1.原来的ViewStub要替换成一个占位View，这样就会破坏原有的布局优化策略；

2.被inflate的View，根标签不能用merge，原因去看inflate源码；

3.不保证你的功能view里面有奇奇怪怪的操作，这些都会导致子线程解析失败。
这些奇奇怪怪的操作有（包括但不限于）

I.在异步inflated的布局，其 parent 的 generateLayoutParams 函数必须要是线程安全的；

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

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

...

最后

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

以上代码很简单，就不传github。
顺便打个广告，一行代码帮你做安卓防护
https://github.com/lamster2018/EasyProtector

性能优化:异步加载View的一些思路

性能优化:异步加载View的一些思路

目录

防杠

背景及目标

理论基础

流程分析

具体操作

风险提示

最后