前言

在前面的学习中，我们基本了解了一些 Canvas 的绘制，那么这一章我们一起复习一下图片的绘制几种方式，和事件的简单交互方式。

我们从易到难，作为基础的进阶控件，我们从最简单的交互开始，那就自定义一个星星评分的控件吧。

一个 App 必不可少的评论系统打分的控件，可以展示评分，可以点击评分，可以滑动评分。它的实现总体上可以分为以下的步骤：

1. 强制测量大小为我们指定的大小


2. 先绘制Drawable未评分的图片


3. 在绘制Bitmap已评分的图片


4. 在onTouch中点击和移动的事件中动态计算当前的评分，进而刷新布局


5. 回调的处理与属性的抽取

思路我们已经有了，下面一步一步的来实现吧。

话不多说，Let's go

1、测量与图片的绘制

我们需要绘制几个星星，那么我们必须要设置的几个属性：

当前的评分值，总共有几个星星，每一个星星的间距和大小，选中和未选中的Drawable图片：

    private int mStarDistance = 0;

    private int mStarCount = 5;

    private int mStarSize = 20;    //每一个星星的宽度和高度是一致的

    private float mScoreNum = 0.0F;  //当前的评分值

    private Drawable mStarScoredDrawable;  //已经评分的星星图片

    private Drawable mStarUnscoredDrawable;  //还未评分的星星图片



    private void init(Context context, AttributeSet attrs) {



        mScoreNum = 2.1f;

        mStarSize = context.getResources().getDimensionPixelSize(R.dimen.d_20dp);

        mStarDistance = context.getResources().getDimensionPixelSize(R.dimen.d_5dp);

        mStarScoredDrawable = context.getResources().getDrawable(R.drawable.iv_normal_star_yellow);

        mStarUnscoredDrawable = context.getResources().getDrawable(R.drawable.iv_normal_star_gray);

    }

测量布局的时候，我们就不能根据xml设置的 match_parent 或 wrap_content 来设置宽高，我们需要根据星星的大小与间距来动态的计算，所以不管xml中如何设置，我们都强制性的使用我们自己的测量。

星星的数量 * 星星的宽度再加上中间的间距 * 数量-1，就是我们的控件宽度，控件高度则是星星的高度。

具体的确定测量我们再上一篇已经详细的复习过了，这里直接贴代码：

    @Override

    protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {

        setMeasuredDimension(mStarSize * mStarCount + mStarDistance * (mStarCount - 1), mStarSize);

    }

这样就可以得到对应的测量宽高 （加一个背景方便看效果）：

如何绘制星星？直接绘制Drawable即可，默认的Drawable的绘制为:

    @Override

    protected void onDraw(Canvas canvas) {

        super.onDraw(canvas);



        for (int i = 0; i < mStarCount; i++) {

            mStarUnscoredDrawable.setBounds((mStarDistance + mStarSize) * i, 0, (mStarDistance + mStarSize) * i + mStarSize, mStarSize);

            mStarUnscoredDrawable.draw(canvas);

        }



    }

如果有5个星星图片，那么就为每一个星星定好位置：

那么已经选中的图片也需要使用这种方法绘制吗？

计算当前的评分，然后计算计算需要绘制多少星星，那么就是这样做：

    int score = (int) Math.ceil(mScoreNum);

    for (int i = 0; i < score; i++) {

        mStarScoredDrawable.setBounds((mStarDistance + mStarSize) * i, 0, (mStarDistance + mStarSize) * i + mStarSize, mStarSize);

        mStarScoredDrawable.draw(canvas);

    }

可是这么做不符合我们的要求啊 ，我们是需要是可以显示评分为2.5之类值，那么我们怎么能绘制半颗星呢？Drawable.draw(canvas) 的方式满足不了，那我们可以使用 BitmapShader 的方式来绘制。

初始化一个 BitmapShader 设置给 Paint 画笔，通过画笔就可以画出对应的形状。

比如此时的场景，我们如果想只画0.5个星星，那么我们就可以

     paint = new Paint();

    paint.setAntiAlias(true);

    paint.setShader(new BitmapShader(drawableToBitmap(mStarScoredDrawable), BitmapShader.TileMode.CLAMP, BitmapShader.TileMode.CLAMP));



    @Override

    protected void onDraw(Canvas canvas) {

        for (int i = 0; i < mStarCount; i++) {

            mStarUnscoredDrawable.setBounds((mStarDistance + mStarSize) * i, 0, (mStarDistance + mStarSize) * i + mStarSize, mStarSize);

            mStarUnscoredDrawable.draw(canvas);

        }



         canvas.drawRect(0, 0, mStarSize * mScoreNum, mStarSize, paint);

    }

那么如果是大于一个星星之后的小数点就可以用公式计算

    if (mScoreNum > 1) {

        canvas.drawRect(0, 0, mStarSize, mStarSize, paint);



        if (mScoreNum - (int) (mScoreNum) == 0) {

            //如果评分是3.0之类的整数，那么直接按正常的rect绘制

            for (int i = 1; i < mScoreNum; i++) {

                canvas.translate(mStarDistance + mStarSize, 0);

                canvas.drawRect(0, 0, mStarSize, mStarSize, paint);

            }

        } else {

            //如果是小数例如3.5，先绘制之前的3个，再绘制后面的0.5

            for (int i = 1; i < mScoreNum - 1; i++) {

                canvas.translate(mStarDistance + mStarSize, 0);

                canvas.drawRect(0, 0, mStarSize, mStarSize, paint);

            }

            canvas.translate(mStarDistance + mStarSize, 0);

            canvas.drawRect(0, 0, mStarSize * (Math.round((mScoreNum - (int) (mScoreNum)) * 10) * 1.0f / 10), mStarSize, paint);

        }



    } else {

        canvas.drawRect(0, 0, mStarSize * mScoreNum, mStarSize, paint);

    }

效果：

关于 BitmapShader 的其他用法，可以翻看我之前的自定义圆角圆形View，和自定义圆角容器的文章，里面都有用到过，主要是方便一些图片的裁剪和缩放等。

2、事件的交互与计算

这里并没有涉及到什么事件嵌套，拦截之类的复杂处理，只需要处理自身的 onTouch 即可。而我们需要处理的就是按下的时候和移动的时候评分值的变化。

在onDraw方法中，我们使用 mScoreNum 变量来绘制的已评分的 Bitmap 绘制。所以这里我们只需要在 onTouch 中计算出对应的 mScoreNum 值，让其重绘即可。

    @Override

    public boolean onTouchEvent(MotionEvent event) {



        //x轴的宽度做一下最大最小的限制

        int x = (int) event.getX();

        if (x < 0) {

            x = 0;

        }

        if (x > mMeasuredWidth) {

            x = mMeasuredWidth;

        }



        switch (event.getAction()) {

            case MotionEvent.ACTION_DOWN:

            case MotionEvent.ACTION_MOVE: {

                mScoreNum = x * 1.0f / (mMeasuredWidth * 1.0f / mStarCount);

                invalidate();

                break;

            }

            case MotionEvent.ACTION_UP: {

                break;

            }

        }



        return super.onTouchEvent(event);



    }

计算出一颗星的长度，然后计算当前x轴的长度，就可以计算出当前有几颗星，我们默认处理的是 float 类型。就可以根据计算出的 mScoreNum 值来得到对应的动画效果：

3. 回调处理与自定义属性抽取

到此效果的实现算是结束了，但是我们还有一些收尾工作没做，如何监听进度的回调，如何控制整数与浮点数的显示，是否支持触摸等等。然后对其做一些自定义属性的抽取，就可以在应用中比较广泛的使用了。

自定义属性：

    private int mStarDistance = 5;

    private int mStarCount = 5;

    private int mStarSize = 20;    //每一个星星的宽度和高度是一致的

    private float mScoreNum = 0.0F;  //当前的评分值

    private Drawable mStarScoredDrawable;  //已经评分的星星图片

    private Drawable mStarUnscoredDrawable;  //还未评分的星星图片

    private boolean isOnlyIntegerScore = false;  //默认显示小数类型

    private boolean isCanTouch = true; //默认支持控件的点击

    private OnStarChangeListener onStarChangeListener;

自定义属性的赋值与初始化操作：

    private void init(Context context, AttributeSet attrs) {

        setClickable(true);

        TypedArray mTypedArray = context.obtainStyledAttributes(attrs, R.styleable.StarScoreView);

        this.mStarDistance = mTypedArray.getDimensionPixelSize(R.styleable.StarScoreView_starDistance, 0);

        this.mStarSize = mTypedArray.getDimensionPixelSize(R.styleable.StarScoreView_starSize, 20);

        this.mStarCount = mTypedArray.getInteger(R.styleable.StarScoreView_starCount, 5);

        this.mStarUnscoredDrawable = mTypedArray.getDrawable(R.styleable.StarScoreView_starUnscoredDrawable);

        this.mStarScoredDrawable = mTypedArray.getDrawable(R.styleable.StarScoreView_starScoredDrawable);

        this.isOnlyIntegerScore = mTypedArray.getBoolean(R.styleable.StarScoreView_starIsTouchEnable, true);

        this.isOnlyIntegerScore = mTypedArray.getBoolean(R.styleable.StarScoreView_starIsOnlyIntegerScore, false);

        mTypedArray.recycle();



        paint = new Paint();

        paint.setAntiAlias(true);

        paint.setShader(new BitmapShader(drawableToBitmap(mStarScoredDrawable), BitmapShader.TileMode.CLAMP, BitmapShader.TileMode.CLAMP));

    }

自定义属性的定义xml文件：

    <!--  评分星星控件  -->

    <declare-styleable name="StarScoreView">

        <!--星星间距-->

        <attr name="starDistance" format="dimension" />

        <!--星星大小-->

        <attr name="starSize" format="dimension" />

        <!--星星个数-->

        <attr name="starCount" format="integer" />

        <!--星星已评分图片-->

        <attr name="starScoredDrawable" format="reference" />

        <!--星星未评分图片-->

        <attr name="starUnscoredDrawable" format="reference" />

        <!--是否可以点击-->

        <attr name="starIsTouchEnable" format="boolean" />

        <!--是否显示整数-->

        <attr name="starIsOnlyIntegerScore" format="boolean" />

    </declare-styleable>

在OnTouch的时候就可以判断是否能触摸

    @Override

    public boolean onTouchEvent(MotionEvent event) {

        if (isCanTouch) {



            //x轴的宽度做一下最大最小的限制

            int x = (int) event.getX();

            if (x < 0) {

                x = 0;

            }

            if (x > mMeasuredWidth) {

                x = mMeasuredWidth;

            }



            switch (event.getAction()) {

                case MotionEvent.ACTION_DOWN:

                case MotionEvent.ACTION_MOVE: {

                    setStarMark(x * 1.0f / (getMeasuredWidth() * 1.0f / mStarCount));

                    break;

                }

                case MotionEvent.ACTION_UP: {

                    break;

                }

            }

            

            return super.onTouchEvent(event);



        } else {

            //如果设置不能点击，直接不触发事件

            return false;

        }



    }

而 setStarMark 则是设置入口的方法，内部判断是否支持小数点和设置对于的监听，并调用重绘。

   public void setStarMark(float mark) {

        if (isOnlyIntegerScore) {

            mScoreNum = (int) Math.ceil(mark);

        } else {

            mScoreNum = Math.round(mark * 10) * 1.0f / 10;

        }

        if (this.onStarChangeListener != null) {

            this.onStarChangeListener.onStarChange(mScoreNum);  //调用监听接口

        }

        invalidate();

    }

一个简单的图片绘制和事件触摸的控件就完成啦，使用起来也是超级方便。

    <com.guadou.kt_demo.demo.demo18_customview.star.StarScoreView

        android:id="@+id/star_view"

        android:layout_width="wrap_content"

        android:layout_height="wrap_content"

        android:layout_gravity="center_horizontal"

        android:layout_marginTop="@dimen/d_40dp"

        android:background="#f1f1f1"

        app:starCount="5"

        app:starDistance="@dimen/d_5dp"

        app:starIsOnlyIntegerScore="false"

        app:starIsTouchEnable="true"

        app:starScoredDrawable="@drawable/iv_normal_star_yellow"

        app:starSize="@dimen/d_35dp"

        app:starUnscoredDrawable="@drawable/iv_normal_star_gray" />

Activity中可以设置评分和设置监听：

    override fun init() {



        val starView = findViewById<StarScoreView>(R.id.star_view)



        starView.setOnStarChangeListener {

            YYLogUtils.w("当前选中的Star:$it")

        }



        findViewById<View>(R.id.set_progress).click {

            starView.setStarMark(3.5f)

        }

    }

效果：

后记

整个流程走下来是不是很简单呢，此控件不止用于星星类型的评分，任何图片资源都可以使用，现在我们思路打开扩展一下，相似的场景和效果我们可以实现一些图片进度，触摸进度条，圆环的SeekBar，等等类似的控制都是相似的思路。

这一期的比较简单，我并没有上传到 Maven ，如果有需求可以去我的项目里面拿，如果有需求的话也可以自行修改，如果大家有兴趣可以查看源码点击【传送门】。你也可以关注我的这个Kotlin项目，我有时间都会持续更新。

关于事件交互的自定义View后面有时间会再出稍微复杂一点的，帮助大家巩固与复习。我心里的路线是先学绘制再学交互（因为交互的基础就是绘制），然后再学ViewGroup的嵌套、拦截、分发、排版等等，从易到难争取让大家复习个通透，当然如果有人看的话，我会继续更新。

惯例，我如有讲解不到位或错漏的地方，希望同学们可以指出交流。

如果感觉本文对你有一点点的启发，还望你能点赞支持一下,你的支持是我最大的动力。

Ok,这一期就此完结。

期望实现的效果

这个效果看上去很简单，但是等到要实现的时候，发现用常规的布局在左侧文字较长的时候，右侧文字标签的控件会控件被左侧文字挤压导致标签控件显示不了（LinearLayout、RelativeLayout都存在一样的问题）
（修改：评论给出了一种用LinearLayout实现的一种方式更便捷，那么这篇文章就当做提供另外一种方案吧- -）

使用ConstraintLayout就能解决这个问题，先贴个代码：

<androidx.constraintlayout.widget.ConstraintLayout

    android:layout_width="match_parent"

    android:layout_height="wrap_content">

    

    <TextView

        android:layout_width="0dp"

        android:layout_height="wrap_content"

        app:layout_constraintLeft_toLeftOf="parent"

        app:layout_constraintTop_toTopOf="parent"

        app:layout_constraintBottom_toBottomOf="parent"

        app:layout_constraintRight_toLeftOf="@+id/tv2"

        android:ellipsize="end"

        android:maxLines="1"

        android:id="@+id/tv1"

        android:textSize="20dp"

        app:layout_constraintHorizontal_chainStyle="packed"

        app:layout_constraintHorizontal_bias="0"

        app:layout_constraintWidth_default="wrap"

        android:text="王小明"

        />

    

    <TextView

        app:layout_constraintBottom_toBottomOf="@+id/tv1"

        app:layout_constraintRight_toRightOf="parent"

        android:background="@drawable/co_border_blue"

        app:layout_constraintLeft_toRightOf="@+id/tv1"

        app:layout_constraintTop_toTopOf="@id/tv1"

        android:id="@+id/tv2"

        android:text="父亲"

        android:paddingLeft="5dp"

        android:paddingRight="5dp"

        android:visibility="visible"

        android:textSize="15dp"

        android:textColor="#59baf5"

        android:layout_width="wrap_content"

        android:layout_height="wrap_content" />







</androidx.constraintlayout.widget.ConstraintLayout>

核心思路

第一步先把两个文本的对齐方式约束起来

左侧文本需要在右侧文本右侧，右侧文本需要在左侧文本左侧，右侧文本还需要和父布局右对齐

关键代码

    <TextView

        android:layout_width="0dp"

        android:layout_height="wrap_content"

        app:layout_constraintRight_toLeftOf="@+id/tv2"

        android:id="@+id/tv1"

        ...

        />

        

    这里tv1设置layout_width="0dp"，即match_constraint，如果自适应则按照目前的约束方式两个文本整体会居中  

        

    

   

       

       



    <TextView

        app:layout_constraintRight_toRightOf="parent"

        app:layout_constraintLeft_toRightOf="@+id/tv1"

        android:id="@+id/tv2"

        android:text="父亲"

        android:layout_width="wrap_content"

        android:layout_height="wrap_content" 

        ...

        />

这个时候的效果：

虽然第二种场景下满足了，但是第一种场景下是不符合期望的，这个时候需要考虑再进一步约束：

1）左侧文字需要做到自适应

2）左侧文字自适应后需要对齐到最左侧

3）自适应后左右侧文字需要连接在一起
所以进一步引入了【链条样式】

关键代码：

<TextView

    android:id="@+id/tv1"

    app:layout_constraintHorizontal_chainStyle="packed"

    app:layout_constraintHorizontal_bias="0"

    app:layout_constraintWidth_default="wrap"

    android:text="王小明"

    />

app:layout_constraintHorizontal_chainStyle="packed" 使链条上的元素都打包到一起
app:layout_constraintHorizontal_bias="0" 使左侧控件最左侧对齐
app:layout_constraintWidth_default="wrap" 使左侧文字自适应大小并且不超过约束限制，默认是“spread”，会占用所有符合约束的控件

这样就完成了目标的效果

在清明节时各大APP都会进行黑白化处理，当时在接到这个需求的时候感觉好麻烦，是不是又要搞一套皮肤？

然而在一系列搜索之后，找到了两位大神（鸿洋、U2tzJTNE）的实现方案，其实相当的简单！

让我们一起站在巨人的肩膀上来分析一下原理，并思考会不会有更简便的实现？

一、原理

两位大神的置灰方案是相同的，都能看到一段同样的代码：

Paint mPaint = new Paint();

ColorMatrix mColorMatrix = new ColorMatrix();

// 设置饱和度为0

mColorMatrix.setSaturation(0);

mPaint.setColorFilter(new ColorMatrixColorFilter(mColorMatrix));

他们都用了Android提供的ColorMatrix（颜色矩阵），将其饱和度设置为0，这样使用Paint绘制出来的都是没有饱和度的灰白样式！

然而两位在何时使用Paint绘制时选择了不同方案。

1.1 鸿洋：重写draw方法

鸿洋老师分析，如果我们把每个Activity的根布局饱和度设置为0是不是就可以了？

那根布局是谁？

鸿洋老师分析我们的布局最后setContentView最后都会设置到一个R.id.content的FrameLayout当中。

我们去自定义一个GrayFrameLayout，在draw的时候使用这个饱和度为0的画笔，被这个FrameLayout包裹的布局都会变成黑白。

// 转载自鸿洋

// https://blog.csdn.net/lmj623565791/article/details/105319752

public class GrayFrameLayout extends FrameLayout {

    private Paint mPaint = new Paint();



    public GrayFrameLayout(Context context, AttributeSet attrs) {

        super(context, attrs);



        ColorMatrix cm = new ColorMatrix();

        cm.setSaturation(0);

        mPaint.setColorFilter(new ColorMatrixColorFilter(cm));

    }



    @Override

    protected void dispatchDraw(Canvas canvas) {

        canvas.saveLayer(null, mPaint, Canvas.ALL_SAVE_FLAG);

        super.dispatchDraw(canvas);

        canvas.restore();

    }



    @Override

    public void draw(Canvas canvas) {

        canvas.saveLayer(null, mPaint, Canvas.ALL_SAVE_FLAG);

        super.draw(canvas);

        canvas.restore();

    }

}

然后我们用GrayFrameLayout去替换这个R.id.content的FrameLayout，是不是就可以做到将页面黑白化了？

替换FrameLayout的方法可以去【鸿洋】这篇文章下查看。

1.2 U2tzJTNE：监听DecorView的添加

U2tzJTNE大佬使用了另一种巧妙的方案。

他先创建了一个具有数据变化感知能力的ObservableArrayList（当内容发生变化有回调）。

之后使用反射将WindowManagerGlobal内的mViews容器（ArrayList，该容器会存放所有的DecorView），替换为ObservableArrayList，这样就可以监听到每个DecorView的创建，并且拿到View本身。

拿到DecorView，那就可以为所欲为了！

大佬使用了setLayerType(View.LAYER_TYPE_HARDWARE, mPaint)，对布局进行了重绘。至于为什么要用LAYER_TYPE_HARDWARE？因为默认的View.LAYER_TYPE_NONE会把Paint强制设置为null。

// 转载自U2tzJTNE

// https://juejin.cn/post/6892277675012915207

public static void enable(boolean enable) {

    try {

        //灰色调Paint

        final Paint mPaint = new Paint();

        ColorMatrix mColorMatrix = new ColorMatrix();

        mColorMatrix.setSaturation(enable ? 0 : 1);

        mPaint.setColorFilter(new ColorMatrixColorFilter(mColorMatrix));



        //反射获取windowManagerGlobal

        @SuppressLint("PrivateApi")

        Class<?> windowManagerGlobal = Class.forName("android.view.WindowManagerGlobal");

        @SuppressLint("DiscouragedPrivateApi")

        java.lang.reflect.Method getInstanceMethod = windowManagerGlobal.getDeclaredMethod("getInstance");

        getInstanceMethod.setAccessible(true);

        Object windowManagerGlobalInstance = getInstanceMethod.invoke(windowManagerGlobal);



        //反射获取mViews

        Field mViewsField = windowManagerGlobal.getDeclaredField("mViews");

        mViewsField.setAccessible(true);

        Object mViewsObject = mViewsField.get(windowManagerGlobalInstance);



        //创建具有数据感知能力的ObservableArrayList

        ObservableArrayList<View> observerArrayList = new ObservableArrayList<>();

        observerArrayList.addOnListChangedListener(new ObservableArrayList.OnListChangeListener() {

            @Override

            public void onChange(ArrayList list, int index, int count) {

            }



            @Override

            public void onAdd(ArrayList list, int start, int count) {

            	// 拿到DecorView触发重绘

                View view = (View) list.get(start);

                if (view != null) {

                    view.setLayerType(View.LAYER_TYPE_HARDWARE, mPaint);

                }

            }



            @Override

            public void onRemove(ArrayList list, int start, int count) {

            }

        });

        //将原有的数据添加到新创建的list

        observerArrayList.addAll((ArrayList<View>) mViewsObject);

        //替换掉原有的mViews

        mViewsField.set(windowManagerGlobalInstance, observerArrayList);

    } catch (Exception e) {

        e.printStackTrace();

    }

}

只需要在Application里面调用该方法即可。

1.3 方案分析

两位大佬的方案都非常的棒，咱们理性的来对比一下。

• 
  

  鸿洋老师： 使用自定义FrameLayout的方案需要一个BaseActivity统一设置，稍显麻烦，代码侵入性较强。

  
  


• 
  

  U2tzJTNE大佬： 方案更加简单、动态，一行代码设置甚至可以做到在当前页从彩色变黑白，但是使用了反射，有一点点性能消耗。

  
  

二、简易方案（直接复制）

既然研究明白了大佬的方案，那有没有又不需要反射，设置又简单的方法呢？

能不能使用原生方式获取DecorView的实例呢？

突然灵光一闪，Application里面不是有registerActivityLifecycleCallbacks这个注册监听方法吗？监听里面的onActivityCreated不是可以获取到当前的Activity吗？那DecorView不就拿到了！

搞起！上代码！

public class StudyApp extends Application {



    @Override

    public void onCreate() {

        super.onCreate();

        

        Paint mPaint = new Paint();

        ColorMatrix mColorMatrix = new ColorMatrix();

        mColorMatrix.setSaturation(0);

        mPaint.setColorFilter(new ColorMatrixColorFilter(mColorMatrix));



        registerActivityLifecycleCallbacks(new ActivityLifecycleCallbacks() {

        

            @Override

            public void onActivityCreated(@NonNull Activity activity, @Nullable Bundle savedInstanceState) {

            	// 当Activity创建，我们拿到DecorView，使用Paint进行重绘

                View decorView = activity.getWindow().getDecorView();

                decorView.setLayerType(View.LAYER_TYPE_HARDWARE, mPaint);

            }

           

			....

        });

    }

}

这样看起来是不是更简单了！使用了APP原生的方法实现了黑白化！当然也有缺点，因为在Activity级别设置，无法做到在当前页面即时变为黑白。

三、注意事项

这三种方案因为都使用了颜色矩阵，所以坑都是一样的，请注意。

3.1 启动图windowBackground无法变色

在我们可以设置渲染的时候windowBackground已经展示完毕了。

解决方案：只能在当前的包里修改，或者不去理会。

3.2 SurfaceView无法变色

因为我们使用了setLayerType进行重绘，而SurfaceView是有独立的Window，脱离布局内的Window，运行在其他线程，不影响主线程的绘制，所以当前方案无法使SurfaceView变色。

解决方案：
1、使用TextureView。
2、看下这个SurfaceView是否可以设置滤镜，正常都是一些三方或者自制的播放器。

3.3 多进程变色

我们可能会在APP内置小程序，小程序基本是运行在单独的进程中，但是如果我们的黑白配置在运行过程中发生变化，其他进程是无法感知的。

解决方案：使用MMKV存储黑白配置，并设置多进程共享，在开启小程序之前都判断一下黑白展示。

总结

最后咱们再总结一下黑白化方案。

使用了ColorMatrix设置饱和度为0，设置到Paint中，让根布局拿着这个Paint去进行重绘。

这样APP全局黑白化的介绍就结束了，希望大家读完这篇文章，会对APP黑白化有一个更深入的了解。如果我的文章能给大家带来一点点的福利，那在下就足够开心了。

下次再见！

背景

开发中会存在多个任务之间互相依赖，运行非常慢的情况，譬如Android在主线程中初始化多个SDK导致App启动慢的情况，搜索一下发现业界的通用做法是构造任务的有向无环图，拓扑排序生成有序的任务列表，然后用线程池执行任务列表(通俗的说就是先找到没有依赖的任务执行，执行完了以后再找到剩下的没有依赖的任务执行，如此反复直到执行完所有任务)，但是这个做法无法解决有的任务需要点击对话框授权的情况,基于这个情况打算再造一个轮子出来。

问题

造轮子之前先梳理了一下对这个轮子的要求，发现除了有向无环图外还是有很多细节要解决的。

-依赖任务多线程启动

-支持交互性任务，先拦截任务，交互完成以后再继续执行

-可视化有向无环图

-可视化任务执行情况

-支持多线程、主线程、主进程、第一个任务、最后一个任务等配置属性

方案

开源

TaskGraph: github.com/JonaNorman/…

线程池只能执行没有依赖关系的任务，TaskGraph开源库用有向无环图实现多线程依赖线程池，用拦截器实现交互式任务

图中添加了A任务，B任务依赖A任务执行完再执行，其中A任务需要点击对话框才能执行。

TaskGraph taskGraph = new TaskGraph();

taskGraph.addTask(new Task("A",new Runnable() {//添加A任务

   @Override

   public void run() {

   }

}).addTaskInterceptor(new Task.TaskInterceptor() {

   @Override

   public void onIntercept(Task.TaskInterceptorChain interceptorChain) {//拦截A任务，在A任务之前可以插入对话框

       AlertDialog.Builder builder = new AlertDialog.Builder(TaskGraphModule.getTopActivity());

       builder.setPositiveButton("ok", new DialogInterface.OnClickListener() {

           @Override

           public void onClick(DialogInterface dialog, int which) {

               interceptorChain.proceed();//继续

           }

       });

       builder.setNegativeButton("cancel", new DialogInterface.OnClickListener() {

           @Override

           public void onClick(DialogInterface dialog, int which) {

               interceptorChain.cancel();//取消

           }

       });

       builder.show();

   }

}));

taskGraph.addTask(new Task("B",new Runnable() {

   @Override

   public void run() {//添加B任务,B任务依赖A任务先完成

   }

}).dependsOn("A").setMainThread(true));

taskGraph.execute();

可视化有向图

搜索TASK_GRAPH_LOG: graphviz:会输出有向图日志，复制到 graphviz-visual-editor 可视化查看

可视化任务执行情况

python systrace.py -o trace.html  -a packagename sched

复制代码

packagename要替换成运行的app的包名 chrome浏览器打开chrome://tracing/,load 按钮加载trace.html

原理

依赖任务多线程启动

正常的线程池只能执行没有依赖关系的任务，怎么才能让线程池支持运行相互依赖的任务呢？
先找到所有没有进来箭头的节点执行，在该图中也就是A，执行完后删除这个节点和边，
变成了下图

继续以上步骤，找到B运行后删除B,变成下图这样

继续以上步骤，找到C D E同时运行，最终所有任务执行完毕。

把上面的步骤翻译成术语

• 有箭头的图叫有向图


• 节点有多少个进来的箭头叫入度


• 没有进来箭头的节点叫入度为0的节点


• 箭头没有形成环的图叫有向无环图


• 依次找到所有入度为0的节点叫拓扑排序

这里有个问题，多线程怎么执行拓扑排序的节点，有两种做法

1. 拓扑排序的节点列表作为runnable提交到线程池，依赖的任务线程等待其他任务完成在执行


2. 先把入度为0的所有节点提交到线程池，有一个执行完，就触发寻找剩下入度为0的节点继续执行
   两种方案我选了方案2，个人感觉方案2找到的节点执行顺序是最优的，并且不需要线程等待，代码简单而且不需要空占有线程池的线程数量

主要思想：

Grpah图有多个node节点，每个Node节点有一个Vertex顶点，多个入边edge，多个出边edge，
拓扑排序就是找所有node节点入度为0的边移除然后继续找直到找完所有节点，核心代码地址

支持交互性任务

有些任务需要交互输入，完成以后再继续执行，为了实现该功能，可以用拦截器的方式来实现。

拦截器的原理就是调用到拦截器时候会用锁等待，如果执行了proceed方法会唤醒锁然后执行下个拦截器，如果执行了cancel会唤醒锁终止所有任务标记cancel状态，每个拦截器必须调用其中一个方法，要不然会一直等待
核心代码如下：代码地址

private void nextIntercept() {

    synchronized (sync) {

        currentInterceptor = taskInterceptorQueue.poll();//获取下一个拦截器

        if (currentInterceptor == null) {

            return;

        }

        currentInterceptor.onIntercept(this);//处罚拦截器

    }

    while (!graphController.isFinished()) {

        synchronized (sync) {

            if (cancel) {//调用cancel方法会把cancel赋值为true

                throw new TaskCancelException();

            } else if (currentInterceptor == proceedInterceptor) {//如果调用了proceed会proceedInterceptor赋值为currentInterceptor

                nextIntercept();//执行下一个拦截器

                break;

            } else {

                try {

                    sync.wait();//等待执行proceed或者cancel方法

                } catch (InterruptedException e) {

                }

            }

        }

    }

}

可视化有向无环图

多个依赖任务添加进去以后如果不能可视化成图就会对影响对任务的把控程度，graphviz是一个图的可视化项目，只要把图的情况写成文本输入就会生成对应图。

  digraph pic {

    A->B;

    B->C;

    }

可视化任务执行情况

多个任务执行实时运行情况，有助于我们优化任务依赖，主要就是在每个任务执行开始调用Trace.beginSection(name),执行完调用Trace.endSection(),然后用命令

python systrace.py -o trace.html  -a packagename sched

生成trace.html,然后用chrome浏览器打开chrome://tracing/点击load按钮加载trace.html就可以查看每个任务的执行情况

支持多线程、主线程、主进程、第一个任务、最后一个任务等配置属性

任务具有多个属性，多线程、主线程、主进程等属性，该实现只要加对应判断就行，第一个任务和最后一个任务则需要遍历所有任务，添加对应依赖关系。

收获

依赖任务多线程调度本身不是很难，在该开源项目中我收获了很多，包括如何实现有向无环图，如何在多线程中实现任务拦截继发，如何使用graphviz实现可视化图，如何用systemtrace可视化任务执行，希望看完文章的同学也可以从中学到什么，谢谢大家的浏览，如果觉得可以，欢迎大家多多star这个开源项目。

背景

Lucene中根据term字典和倒排可以快速查找到相关文档的id，那怎么获取文档中的字段内容呢，这就是我们今天要讲的正排数据。

Lucene中对于某个文档的各个字段，可以通过配置来控制是否要存储进正排索引文件中，只有存储到正排索引文件中，查询的时候，有需要才能返回相应的字段。

如果理解了之前介绍过的词向量的索引文件构建，可以发现其实正排索引文件和词向量索引文件构建非常类似。

最终生成的正排索引文件有3个：

• fdt：按chunk存储doc的开启了store的字段


• fdx：chunk的索引文件，记录的是每个chunk的起始docID，以及每个chunk的起始位置，方便根据docID快速定位到chunk。


• fdm：正排索引文件的元信息，用来读取正排索引文件使用的。

前置知识

• 在对字段数据的存储时，对不同的数据类型，有不同的压缩算法，详见《单值编码压缩算法》。


• 构建chunk索引文件的时候会用到工具类FieldsIndexWriter，具体我们已经在《词向量索引文件构建》中详细介绍过了。

索引文件格式

fdm

fdm是正排索引文件的元信息，用来读取的时候使用。

字段详解

Header

文件头部信息，主要是包括：

• 文件头魔数（同一lucene版本所有文件相同）


• 该文件使用的codec名称：Lucene90FieldsIndexMeta


• codec版本


• segment id（也是Segment_N文件中的N）


• segment后缀名（一般为空）

ChunkSize

用来判断是否满足一个chunk的一种条件，如果chunk的大小超过了ChunkSize的限制，则可以构建一个chunk

NumDocs

doc总数

BlockShift

DirectMonotonicWriter需要的参数，DirectMonotonicWriter压缩存储会生成多个block，BlockShift决定了block的大小。

TotalChunks + 1

chunk总数 + 1，在生成fdx索引文件中ChunkStartDocIDs和ChunkOffsets两个字段时，使用DirectMonotonicWriter写入的值的总数。

fdxDocStartFP

fdx索引文件中ChunkStartDocIDs的起始位置

DocBlockMetas

fdx索引文件中ChunkStartDocIDs使用DirectMonotonicWriter编码存储，会生成多个block，这些block的元信息。

tvxOffsetStartFP

fdx中ChunkOffsets的起始位置

OffsetBlockMetas

fdx索引文件中ChunkOffsets使用DirectMonotonicWriter编码存储，会生成多个block，这些block的元信息。

SPEndPoint

fdx文件的结束位置，后面是fdx的footer信息。

MaxPointer

fdt文件的结束位置，后面fdt的footer信息。

NumChunks

chunk总数

NumDirtyChunks

dirtyChunk总数

NumDirtyDocs

dirtyChunk中的doc总数

Footer

文件尾，主要包括

• 文件尾魔数（同一个lucene版本所有文件一样）


• 0


• 校验码

fdt

fdt中按chunk存储各个doc所有的字段数据。

字段详解

Header

文件头部信息，主要是包括：

• 
  

  文件头魔数（同一lucene版本所有文件相同）

  
  


• 
  

  该文件使用的codec名称

  
  

  根据压缩模式的不同有两种：

  
  
  
  
  • Lucene90StoredFieldsFastData
  
  
  • Lucene90StoredFieldsHighData
  
  
  
  


• 
  

  codec版本

  
  


• 
  

  segment id（也是Segment_N文件中的N）

  
  


• 
  

  segment后缀名（一般为空）

  
  

chunk

• DocBase：Chunk中Doc的起始编号，Chunk中所有doc的真实编号需要加上这个DocBase


• NumDocsCode：是NumDocs和IsDirty，IsSlice的int组合体
  
  
  
  • NumDocs：chunk中的doc总数
  
  
  • IsDirty：chunk是否是dirtyChunk
  
  
  • IsSlice：chunk是否被分成多个slice
  
  
  
  


• DocNumFields：chunk中每个文档的字段个数。


• DocDataLengths：chunk中每个doc占用的存储空间大小。


• Doc：doc中每个store字段的信息
  
  
  
  • Field：store的字段
    
    
    
    • FieldNumAndTypeCode：FieldNumber和type的long组合体
      
      
      
      • FieldNumber：字段的编号
      
      
      • type：字段的类型
      
      
      
      
    
    
    • FieldValue：根据不同的数值类型，有不同的存储方式
      
      
      
      • 二进制/string：先存length，再存数据
      
      
      • byte/short/int：zint存储
      
      
      • long：tlong存储
      
      
      • float：zfloat存储
      
      
      • double：zdouble存储
      
      
      
      
    
    
    
    
  
  
  
  

Footer

文件尾，主要包括

• 文件尾魔数（同一个lucene版本所有文件一样）


• 0


• 校验码

fdx

fdt中所有chunk的索引信息，可以快速根据docID定位到chunk的位置。

字段详解

Header

文件头部信息，主要是包括：

• 文件头魔数（同一lucene版本所有文件相同）


• 该文件使用的codec名称：Lucene90FieldsIndexIdx


• codec版本


• segment id（也是Segment_N文件中的N）


• segment后缀名（一般为空）

ChunkStartDocIDs

所有chunk的起始docID，使用DirectMonotonicWriter编码存储，会生成多个block。

ChunkOffsets

所有chunk在fdt索引文件中的起始位置，使用DirectMonotonicWriter编码存储，会生成多个block。

Footer

文件尾，主要包括

• 文件尾魔数（同一个lucene版本所有文件一样）


• 0


• 校验码

构建源码

本文源码解析基于lucene-core-9.1.0。

• StoredFieldsConsumer负责调度正排索引文件的构建主要有：启动一个doc的处理，处理doc中的field，结束一个doc的处理，结束正排索引的构建。


• Lucene90CompressingStoredFieldsWriter负责持久化生成正排索引文件

构建涉及到的StoredFieldsConsumer和Lucene90CompressingStoredFieldsWriter逻辑其实非常简单，下面我们一起来看下。

StoredFieldsConsumer

class StoredFieldsConsumer {

  final Codec codec;

  // 索引文件的目录  

  final Directory directory;

  final SegmentInfo info;

  // 实现类是  Lucene90CompressingStoredFieldsWriter，负责正排索引文件的持久化

  StoredFieldsWriter writer;

  Accountable accountable = Accountable.NULL_ACCOUNTABLE;

  // 前一个处理的docID  

  private int lastDoc;



  StoredFieldsConsumer(Codec codec, Directory directory, SegmentInfo info) {

    this.codec = codec;

    this.directory = directory;

    this.info = info;

    this.lastDoc = -1;

  }



  // 创建 Lucene90CompressingStoredFieldsWriter  

  protected void initStoredFieldsWriter() throws IOException {

    if (writer == null) { 

      this.writer = codec.storedFieldsFormat().fieldsWriter(directory, info, IOContext.DEFAULT);

      accountable = writer;

    }

  }



  // 开始处理一个doc

  void startDocument(int docID) throws IOException {

    assert lastDoc < docID;

    initStoredFieldsWriter();

    while (++lastDoc < docID) { // 确保doc是连续的

      writer.startDocument();

      writer.finishDocument();

    }

    //  Lucene90CompressingStoredFieldsWriter中开始处理doc 

    writer.startDocument();

  }

    

  // 每个需要构建的正排字段都会被处理

  void writeField(FieldInfo info, IndexableField field) throws IOException {

    writer.writeField(info, field);

  }



  // 结束doc的处理  

  void finishDocument() throws IOException {

    writer.finishDocument();

  }



  // 结束正排的构建  

  void finish(int maxDoc) throws IOException {

    while (lastDoc < maxDoc - 1) {

      startDocument(lastDoc);

      finishDocument();

      ++lastDoc;

    }

  }



  // 持久化正排索引文件  

  void flush(SegmentWriteState state, Sorter.DocMap sortMap) throws IOException {

    try {

      writer.finish(state.segmentInfo.maxDoc());

    } finally {

      IOUtils.close(writer);

    }

  }



  void abort() {

    IOUtils.closeWhileHandlingException(writer);

  }

}

Lucene90CompressingStoredFieldsWriter

成员变量

  // 数据文件

  public static final String FIELDS_EXTENSION = "fdt";

  // 索引文件

  public static final String INDEX_EXTENSION = "fdx";

  // 元信息文件

  public static final String META_EXTENSION = "fdm";

  /** Codec name for the index. */

  public static final String INDEX_CODEC_NAME = "Lucene90FieldsIndex";



  // 不同数据类型编码  

  static final int STRING = 0x00;

  static final int BYTE_ARR = 0x01;

  static final int NUMERIC_INT = 0x02;

  static final int NUMERIC_FLOAT = 0x03;

  static final int NUMERIC_LONG = 0x04;

  static final int NUMERIC_DOUBLE = 0x05;

  // 数据类型编码的bit数量

  static final int TYPE_BITS = PackedInts.bitsRequired(NUMERIC_DOUBLE);

  // 提取类型的掩码  

  static final int TYPE_MASK = (int) PackedInts.maxValue(TYPE_BITS);



  static final int VERSION_START = 1;

  static final int VERSION_CURRENT = VERSION_START;

  static final int META_VERSION_START = 0;



  private final String segment;

  // 索引生成工具  

  private FieldsIndexWriter indexWriter;

  private IndexOutput metaStream, fieldsStream;



  private Compressor compressor;

  private final CompressionMode compressionMode;

  // chunk的大小  

  private final int chunkSize;

  // 每个chunk最多可以存储多少个doc  

  private final int maxDocsPerChunk;

 

  // 缓存所有的字段的值

  private final ByteBuffersDataOutput bufferedDocs;

  // 下标是当前chunk中的docID的偏移量，值是对应doc的字段个数

  private int[] numStoredFields; 

  // 下标是当前chunk中的docID的偏移量，值是对应doc的所有需要store的数据在bufferedDocs中的结束位置

  private int[] endOffsets; 

  // chunk中的起始docID

  private int docBase;

  // chunk中的doc个数

  private int numBufferedDocs; 

  // chunk总数

  private long numChunks;

  // dirtyChunk总数，未满足生成chunk的条件时，强制生成的chunk是dirtyChunk

  private long numDirtyChunks; 

  // dirtyDoc总数，dirtyChunk中的doc是dirtyDoc

  private long numDirtyDocs; 

  

  // 在处理一个doc的时候，统计已经处理的field个数

  private int numStoredFieldsInDoc;

核心方法

开始处理一个doc

当前实现中是空操作。

  @Override

  public void startDocument() throws IOException {}

处理一个field

处理一个field，就是读取field的值，根据值的类型按对应的值的存储方式存入bufferedDocs缓存中。

  public void writeField(FieldInfo info, IndexableField field) throws IOException {



    ++numStoredFieldsInDoc;



    int bits = 0;

    final BytesRef bytes;

    final String string;



    Number number = field.numericValue();

    if (number != null) { // 如果是数值类型

      if (number instanceof Byte || number instanceof Short || number instanceof Integer) {

        // byte，short，int都标记为int  

        bits = NUMERIC_INT;

      } else if (number instanceof Long) {

        // long  

        bits = NUMERIC_LONG;

      } else if (number instanceof Float) {

        // float  

        bits = NUMERIC_FLOAT;

      } else if (number instanceof Double) {

        // double  

        bits = NUMERIC_DOUBLE;

      } else {

        throw new IllegalArgumentException("cannot store numeric type " + number.getClass());

      }

      string = null;

      bytes = null;

    } else {

      bytes = field.binaryValue();

      if (bytes != null) { // 是二进制

        bits = BYTE_ARR;

        string = null;

      } else { // 是字符串

        bits = STRING;

        string = field.stringValue();

        if (string == null) {

          throw new IllegalArgumentException(

              "field "

                  + field.name()

                  + " is stored but does not have binaryValue, stringValue nor numericValue");

        }

      }

    }

    // 字段的编号和类型组合体

    final long infoAndBits = (((long) info.number) << TYPE_BITS) | bits;

    bufferedDocs.writeVLong(infoAndBits);



    if (bytes != null) {

      bufferedDocs.writeVInt(bytes.length);

      bufferedDocs.writeBytes(bytes.bytes, bytes.offset, bytes.length);

    } else if (string != null) {

      bufferedDocs.writeString(string);

    } else {

      if (number instanceof Byte || number instanceof Short || number instanceof Integer) {

        bufferedDocs.writeZInt(number.intValue());

      } else if (number instanceof Long) {

        writeTLong(bufferedDocs, number.longValue());

      } else if (number instanceof Float) {

        writeZFloat(bufferedDocs, number.floatValue());

      } else if (number instanceof Double) {

        writeZDouble(bufferedDocs, number.doubleValue());

      } else {

        throw new AssertionError("Cannot get here");

      }

    }

  }

结束处理一个doc

结束doc的处理，需要做4件事：

• 如果numBufferedDocs空间不足了，需要扩容


• 记录doc对应的field个数


• 记录doc数据在bufferedDocs中的结束位置


• 判断如果满足一个chunk的生成，则生成chunk

  public void finishDocument() throws IOException {

    if (numBufferedDocs == this.numStoredFields.length) {

      final int newLength = ArrayUtil.oversize(numBufferedDocs + 1, 4);

      this.numStoredFields = ArrayUtil.growExact(this.numStoredFields, newLength);

      endOffsets = ArrayUtil.growExact(endOffsets, newLength);

    }

    // 记录doc对应的field个数  

    this.numStoredFields[numBufferedDocs] = numStoredFieldsInDoc;

    numStoredFieldsInDoc = 0;

    // 记录当前doc在bufferedDocs中的结束位置

    endOffsets[numBufferedDocs] = Math.toIntExact(bufferedDocs.size());

    ++numBufferedDocs;

    if (triggerFlush()) {

      flush(false);

    }

  }

生成一个chunk

生成一个chunk的条件：

• bufferDocs缓存超出了chunkSize


• chunk中收集的doc数量超出了maxDocsPerChunk


• 强制生成

  // 生成一个chunk的条件

  // 1.bufferDocs缓存超出了chunkSize

  // 2.chunk中收集的doc数量超出了maxDocsPerChunk

  private boolean triggerFlush() {

    return bufferedDocs.size() >= chunkSize || numBufferedDocs >= maxDocsPerChunk;

  } 



  private void flush(boolean force) throws IOException {

    // chunk数+1  

    numChunks++;

    if (force) { // 如果是强制构建chunk，可能是不满足chunk条件的，这种chunk被定义为dirtyChunk

      numDirtyChunks++;

      numDirtyDocs += numBufferedDocs;

    }

    // 生成chunk的索引  

    indexWriter.writeIndex(numBufferedDocs, fieldsStream.getFilePointer());



    // 把各个doc在bufferedDocs中的endOffsets转成length

    final int[] lengths = endOffsets;

    for (int i = numBufferedDocs - 1; i > 0; --i) {

      lengths[i] = endOffsets[i] - endOffsets[i - 1];

    }

    // 如果当前chunk的大小超出了2倍chunkSize，则需要分片  

    final boolean sliced = bufferedDocs.size() >= 2 * chunkSize;

    final boolean dirtyChunk = force;

    writeHeader(docBase, numBufferedDocs, numStoredFields, lengths, sliced, dirtyChunk);



    // 下面是压缩处理

    byte[] content = bufferedDocs.toArrayCopy();

    bufferedDocs.reset();



    if (sliced) {

      // big chunk, slice it

      for (int compressed = 0; compressed < content.length; compressed += chunkSize) {

        compressor.compress(

            content, compressed, Math.min(chunkSize, content.length - compressed), fieldsStream);

      }

    } else {

      compressor.compress(content, 0, content.length, fieldsStream);

    }



    // 更新下一个chunk的起始docID

    docBase += numBufferedDocs;

    // 重置doc数统计  

    numBufferedDocs = 0;

    bufferedDocs.reset();

  }



  private static void saveInts(int[] values, int length, DataOutput out) throws IOException {

    if (length == 1) {

      out.writeVInt(values[0]);

    } else {

      StoredFieldsInts.writeInts(values, 0, length, out);

    }

  }



  private void writeHeader(

      int docBase,

      int numBufferedDocs,

      int[] numStoredFields,

      int[] lengths,

      boolean sliced,

      boolean dirtyChunk)

      throws IOException {

    final int slicedBit = sliced ? 1 : 0;

    final int dirtyBit = dirtyChunk ? 2 : 0;

    // save docBase and numBufferedDocs

    fieldsStream.writeVInt(docBase);

    fieldsStream.writeVInt((numBufferedDocs << 2) | dirtyBit | slicedBit);



    // save numStoredFields

    saveInts(numStoredFields, numBufferedDocs, fieldsStream);



    // save lengths

    saveInts(lengths, numBufferedDocs, fieldsStream);

  }

结束构建

结束构建的时候最重要的就是生成fdx索引文件。

  public void finish(int numDocs) throws IOException {

    if (numBufferedDocs > 0) { // 如果还有未处理的doc，强制生成一个chunk

      flush(true);

    } else {

      assert bufferedDocs.size() == 0;

    }

    if (docBase != numDocs) {

      throw new RuntimeException(

          "Wrote " + docBase + " docs, finish called with numDocs=" + numDocs);

    }

    // 构建fdx文件  

    indexWriter.finish(numDocs, fieldsStream.getFilePointer(), metaStream);

    // 记录一些元信息  

    metaStream.writeVLong(numChunks);

    metaStream.writeVLong(numDirtyChunks);

    metaStream.writeVLong(numDirtyDocs);

    CodecUtil.writeFooter(metaStream);

    CodecUtil.writeFooter(fieldsStream);

    assert bufferedDocs.size() == 0;

  }

}

浅谈

前几天有个朋友问我：Android中硬件加速那么好用，为啥没被普及？，嗯？其实我也想知道。。。

手机开发中最重要的两个点：

• 1.用户点击的流畅性


• 2.界面效果的展示

早期的Android系统这两个事件都是在主线程上执行，导致用户点击的时候，界面绘制停滞或者界面绘制的时候，用户点击半天不响应，体验性很差。

于是在4.0以后，以 “run fast, smooth, and responsively” 为核心目标对 UI 进行了优化，应用开启了硬件加速对UI进行绘制。

1.硬件加速

在之前文章中我们分析过，Android 屏幕的绘制流程分为两部分：

• 1.生产者:app侧将View渲染到一个buffer中，供SurfaceFlinger消费


• 2.消费者:SurfaceFlinger测将多个buffer合并后放入buffer中，供屏幕显示

其中 第二步一直都是在GPU中实现的，而我们所说的硬件加速就是第一步中的view渲染流程。

早期view的渲染是在主线程中进行的，而硬件加速则使用一个新的线程RenderThread以及硬件GPU进行渲染，

2.CPU / GPU结构对比

• CPU （Central Processing Unit）: 中央处理器，计算机设备核心器件，适用于一些复杂的计算。


• GPU （Graphic Processing Unit）: 图形处理器，通常所说“显卡”的核心部件就是GPU，主要用于处理图形运算。

CPU和GPU结构对比：

• 黄色代表控制器（Control）：用于协调控制整个CPU的运行，包括取指令等操作。


• 绿色的ALU（Arithmetic Logic Unit）：算数逻辑单元，主要用于进行数学，逻辑计算。


• 橙色的Cache和DRAM分别为缓存和RAM，用于存储信息。

1.结构上看：CPU的ALU较少，而了解过OpenGl的同学应该知道View的渲染过程中是有大量的浮点数计算的，而浮点数转换为整数计算，可能会消耗大量的ALU单元，这对于CPU是比较难接受的。

2.CPU是串行的，一个CPU同一时间只能做一件事情，（多线程其实也是将CPU时间片分割而已），而GPU内部使用的是几千个小的GPU内核，每个GPU内核处理单元都是并行的，
这就非常符合图形的渲染过程。

GPU是显卡的核心部分，在破解密码方面也非常出色，再知道为啥哪些挖矿的使用的是显卡而不是CPU了吧，一个道理。

硬件加速底层原理：

通过将计算机不擅长的图形计算指令使用特殊的api转换为GPU的专用指令，由GPU完成。这里可能是传统的OpenGL或其他开放语言。

3.OpenGL

Android端一般使用OpenGL ES来实现硬件加速。
这里简单介绍下OpenGL和OpenGL ES。

• OpenGL（Open Graphics Library）：开放式图形库，是用于渲染2D、3D矢量图形的跨语言、跨平台的应用程序编程接口（API）。这个接口由近350个不同的函数调用组成，
  用来绘制从简单的图形比特到复杂的三维景象。


• OpenGL ES(OpenGL for Embedded Systems):是 OpenGL 三维图形 API 的子集，针对手机、PDA和游戏主机等嵌入式设备而设计

如果一个设备支持GPU硬件加速渲染（有可能不支持，看GPU厂商是不是适配了OpenGL 等接口），
那么当Android应用程序调用Open GL接口来绘制UI时，Android应用程序的 UI 就是通过GPU进行渲染的。

4.Android图形系统整体架构

在介绍Android图像系统架构前，我们先来了解几个概念：如果把UI的绘制过程当成一幅画的制作过程：
那么：

• 
  

  1.画笔：

  
  
  
  
  • Skia：CPU用来绘制2D图形
  
  
  • Open GL /ES:GPU绘制2D和3D图形。
  
  
  
  


• 
  

  2.画纸：
  Surface：所有的绘制和渲染都是在这张画纸上进行，每个窗口都是一个DecorView的容器，同时每个窗口都关联一个Surface

  
  


• 
  

  3.画板：
  Graphic Buffer ：Graphic Buffer是谷歌在4.1以后针对双缓冲的jank问题提出的第三个缓冲，CPU/GPU渲染的内容都将写到这个buffer上。

  
  


• 
  

  4.合成
  SurfaceFlinger：将所有的Surface合并叠加后显示到一个buffer里面。

  
  

简单理解过程：我们使用画笔（Skia、Open GL ES）将内容画到画纸（Surface）中，这个过程可能使用OpenGl ES也可能使用Skia，
使用OpenGl ES表示使用了硬件加速绘制，使用Skia，表示使用的是纯软件绘制。

下面是Android 图形系统的整体架构：

• 
  

  Image Stream Producers：图像数据流生产者，图像或视频数据最终绘制到Surface中。

  
  


• 
  

  WindowManager ：前面一篇文章《WindowManager体系（上）》笔者说过,每个Surface都有一个Window和他一一对应，而WindowManager则用来管理窗口的各个方面：
  动画，位置，旋转，层序，生命周期等。

  
  


• 
  

  SurfaceFlinger：用来对渲染后的Surface进行合并，并传递给硬件抽象层处理。

  
  


• 
  

  HWC ： Hardware Composer，SurfaceFlinger 会委派一些合成的工作给 Hardware Composer 以此减轻 GPU 的负载。这样会比单纯通过 GPU 来合成消耗更少的电量。

  
  


• 
  

  Gralloc（Graphics memory allocator）：前面讲解的Graphic Buffer分配的内存。

  
  

5.软硬件绘制过程源码解析

前面讲解了那么多理论知识，下面从源码角度来分析下硬件加速和软件绘制过程。
“read the fking source”

在前面文章《》中分析过。View最终是在ViewRootImpl的performDraw方法最新渲染的，
而performDraw内部调用的是draw方法。
定位到draw方法：

private void draw(boolean fullRedrawNeeded) {

    ...

    if (!dirty.isEmpty() || mIsAnimating || accessibilityFocusDirty) {

        if (mAttachInfo.mThreadedRenderer != null && mAttachInfo.mThreadedRenderer.isEnabled()) {//1

            ...

            mAttachInfo.mThreadedRenderer.draw(mView, mAttachInfo, this);//2

    }else {

            if (!drawSoftware(surface, mAttachInfo, xOffset, yOffset, scalingRequired, dirty)) {//3

                    return;

            }

        }

    }



}

注释1：如果mThreadedRenderer不为null且isEnabled为true，则调用注释2处的mThreadedRenderer.draw，这个就是硬件绘制的入口

如果其他情况，则调用注释3处的drawSoftware，这里就是软件绘制的入口，再正式对软硬件绘制进行深入之前我们看下mAttachInfo.mThreadedRenderer是在哪里赋值的?

源码全局搜索下：我们发现ViewRootImpl的enableHardwareAcceleration方法中有创建mThreadedRenderer的操作。

private void enableHardwareAcceleration(WindowManager.LayoutParams attrs) {

            // Try to enable hardware acceleration if requested

    ...

    final boolean hardwareAccelerated =

                    (attrs.flags & WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED) != 0;

    //这里如果attrs.flags设置了WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED，则表示该Window支持硬件加速绘制

    if (hardwareAccelerated) {



            // Persistent processes (including the system) should not do

            // accelerated rendering on low-end devices.  In that case,

            // sRendererDisabled will be set.  In addition, the system process

            // itself should never do accelerated rendering.  In that case, both

            // sRendererDisabled and sSystemRendererDisabled are set.  When

            // sSystemRendererDisabled is set, PRIVATE_FLAG_FORCE_HARDWARE_ACCELERATED

            // can be used by code on the system process to escape that and enable

            // HW accelerated drawing.  (This is basically for the lock screen.)



            //Persistent的应用进程以及系统进程不能使用硬件加速

            final boolean fakeHwAccelerated = (attrs.privateFlags &

                            WindowManager.LayoutParams.PRIVATE_FLAG_FAKE_HARDWARE_ACCELERATED) != 0;

            final boolean forceHwAccelerated = (attrs.privateFlags &

                            WindowManager.LayoutParams.PRIVATE_FLAG_FORCE_HARDWARE_ACCELERATED) != 0;



            if (fakeHwAccelerated) {



                    mAttachInfo.mHardwareAccelerationRequested = true;

            } else if (!ThreadedRenderer.sRendererDisabled

                            || (ThreadedRenderer.sSystemRendererDisabled && forceHwAccelerated)) {

                    if (mAttachInfo.mThreadedRenderer != null) {

                            mAttachInfo.mThreadedRenderer.destroy();

                    }

                    ...

                    //这里创建了mAttachInfo.mThreadedRenderer

                    mAttachInfo.mThreadedRenderer = ThreadedRenderer.create(mContext, translucent,

                                    attrs.getTitle().toString());

                    if (mAttachInfo.mThreadedRenderer != null) {

                            mAttachInfo.mHardwareAccelerated =

                                            mAttachInfo.mHardwareAccelerationRequested = true;

                    }

            }

    }

}

这里源码告诉我们：

• 1.硬件加速是通过attrs.flags 设置WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED标识来启动的、


• 2、因为硬件加速是一个耗内存的操作，只是硬件加速渲染环境初始化这一操作，就要花掉8M的内存，
  所以一般永久性的进程或者系统进程不要使用硬件加速标志，防止出现内存泄露。

再看哪里调用enableHardwareAcceleration方法?
通过源码查找我们注意到ViewRootImpl的setView方法中：

public void setView(View view, WindowManager.LayoutParams attrs, View panelParentView) {

	//注释1

	if (view instanceof RootViewSurfaceTaker) {

		mSurfaceHolderCallback =

				((RootViewSurfaceTaker)view).willYouTakeTheSurface();

		if (mSurfaceHolderCallback != null) {

			mSurfaceHolder = new TakenSurfaceHolder();

			mSurfaceHolder.setFormat(PixelFormat.UNKNOWN);

			mSurfaceHolder.addCallback(mSurfaceHolderCallback);

		}

	}



	...



	// If the application owns the surface, don't enable hardware acceleration

	if (mSurfaceHolder == null) {//注释2

		enableHardwareAcceleration(attrs);

	}



}

注释1处：表示当前view实现了RootViewSurfaceTaker接口，且view的willYouTakeTheSurface返回的mSurfaceHolderCallback不为null，
则表示应用想自己接管所有的渲染操作，这样创建出来的Activity窗口就类似于一个SurfaceView一样，完全由应用程序自己来控制它的渲染

基本上我们是不会将一个Activity窗口当作一个SurfaceView来使用的，
因此在ViewRootImpl类的成员变量mSurfaceHolder将保持为null值，
这样就会导致ViewRootImpl类的成员函数enableHardwareAcceleration被调用为判断是否需要为当前创建的Activity窗口启用硬件加速渲染。

好了我们回到ViewRootImpl的draw方法：

1.先来看软件绘制

软件绘制调用的是drawSoftware方法。
进入

private boolean drawSoftware(Surface surface, AttachInfo attachInfo, int xoff, int yoff,

            boolean scalingRequired, Rect dirty) {

	...

	canvas = mSurface.lockCanvas(dirty);//1

	

	mView.draw(canvas);//2

	

	surface.unlockCanvasAndPost(canvas);//3



}

软件绘制基本就分三步走：

• 步骤1：lockCanvas：每个Window都关联了一个Surface，当有需要绘制UI时，就调用lockCanvas获取一个Canvas对象，这个Canvas封装了Skia提供的2D图形绘制api、

并且向SurfaceFlinger Dequeue了一块Graphic buffer，绘制的内容都会输出到这个buffer中，供SurfaceFlinger合成使用。

• 
  

  步骤2：draw：调用了View的draw方法，这个就会调用到我们自定义组件中View的onDraw方法，传入1中创建的Canvas对象，使用Skia api对图像进行绘制。

  
  


• 
  

  步骤3：unlockCanvasAndPost：绘制完成后，通知SurfaceFlinger绘制完成，可以进行buffer的交换，显示到屏幕上了，本质是给SurfaceFlinger queue 一个Graphic buffer、
  关于什么是Queue和Dequeue看下图：

  
  

软件绘制条形简图：

2.硬件加速分析：

硬件加速分为两个步骤：

• 1.构建阶段


• 2.绘制阶段

构建阶段：

这个阶段用于遍历所有的视图，将需要绘制的Canvas API调用及其参数记录下来，保存在一个Display List，这个阶段发生在CPU主线程上。

Display List本质上是一个缓存区，它里面记录了即将要执行的绘制命令序列，这些命令最终会在绘制阶段被OpenGL转换为GPU渲染指令。

视图构建阶段会将每个View抽象为一个RenderNode，每个View的绘制操作抽象为一系列的DrawOp，
比如：
View的drawLine操作会被抽象为一个DrawLineOp，drawBitmap操作会被抽象成DrawBitmapOp，每个子View的绘制被抽象成DrawRenderNodeOp，每个DrawOp都有对应的OpenGL绘制指令，同时内部也握有需要绘制的数据元。

使用Display List的好处：

• 1、在绘制窗口的下一帧时，如果某个视图UI没有发生变化，则不需要执行与他相关的Canvas API操作，即不用重复执行View的onDraw操作，
  而是直接使用上一帧的Display List即可


• 2.如果绘制窗口下一帧时，视图发生了变化，但是只是一些简单属性变化，如位置和透明度等，则只需要修改上次构建的Display List的相关属性即可，也不必重复构建

Display List模型图：

接下来我们从源码角度来看下：

前面我们分析了硬件加速入口是在ThreadedRenderer的draw方法：

mAttachInfo.mThreadedRenderer.draw(mView, mAttachInfo, this)

进入这个方法看看：
ThreadedRenderer.java

void draw(View view, AttachInfo attachInfo, DrawCallbacks callbacks) {

	...

	updateRootDisplayList(view, callbacks);//1

	...

	int syncResult = nSyncAndDrawFrame(mNativeProxy, frameInfo, frameInfo.length);//2通知RenderThread线程绘制

}

ThreadedRenderer主要作用就是在主线程CPU中视图的构建，然后通知RenderThread使用OpenGL进行视图的渲染（注释2处）。

注释1处：updateRootDisplayList看名称应该就是用于视图构建，进去看看

private void updateRootDisplayList(View view, HardwareDrawCallbacks callbacks) {

	//1.构建参数view(DecorView)视图的Display List

	updateViewTreeDisplayList(view);

	

	//2

	//mRootNodeNeedsUpdate true表示需要更新视图

	//mRootNode.isValid()  表示已经构建了Display List

	if (mRootNodeNeedsUpdate || !mRootNode.isValid()) {

		//获取DisplayListCanvas

		DisplayListCanvas canvas = mRootNode.start(mSurfaceWidth, mSurfaceHeight);//3

		try {

			//ReorderBarrie表示会按照Z轴坐标值重新排列子View的渲染顺序

			canvas.insertReorderBarrier();

			//构建并缓存所有的DrawOp

			canvas.drawRenderNode(view.updateDisplayListIfDirty());

			canvas.insertInorderBarrier();



			canvas.restoreToCount(saveCount);

		} finally {

			//将所有的DrawOp填充到根RootNode中，作为新的Display List

			mRootNode.end(canvas);

		}

	}

}

注释1：updateViewTreeDisplayList对View树Display List进行构建

private void updateViewTreeDisplayList(View view) {

	view.mPrivateFlags |= View.PFLAG_DRAWN;

	view.mRecreateDisplayList = (view.mPrivateFlags & View.PFLAG_INVALIDATED)

			== View.PFLAG_INVALIDATED;

	view.mPrivateFlags &= ~View.PFLAG_INVALIDATED;

	view.updateDisplayListIfDirty();

	view.mRecreateDisplayList = false;

}

看View的updateDisplayListIfDirty方法。

/**

 * Gets the RenderNode for the view, and updates its DisplayList (if needed and supported)

 * @hide

 */

@NonNull

public RenderNode updateDisplayListIfDirty() {

	//获取当前mRenderNode

	final RenderNode renderNode = mRenderNode;

	//2.判断是否需要进行重新构建

	if ((mPrivateFlags & PFLAG_DRAWING_CACHE_VALID) == 0

                || !renderNode.isValid()

                || (mRecreateDisplayList)) {

				

		if (renderNode.isValid()

                    && !mRecreateDisplayList) {

			mPrivateFlags |= PFLAG_DRAWN | PFLAG_DRAWING_CACHE_VALID;

			mPrivateFlags &= ~PFLAG_DIRTY_MASK;

			//这里用于当前View是ViewGroup，且自身不需要重构，对其子View的DisplayList进行构建

			dispatchGetDisplayList();



			return renderNode; // no work needed

        }

		...

		final DisplayListCanvas canvas = renderNode.start(width, height);

		try {

			if (layerType == LAYER_TYPE_SOFTWARE) {

				//软件绘制

				buildDrawingCache(true);

				Bitmap cache = getDrawingCache(true);

				if (cache != null) {

					canvas.drawBitmap(cache, 0, 0, mLayerPaint);

				}

			} else {

				...

				if ((mPrivateFlags & PFLAG_SKIP_DRAW) == PFLAG_SKIP_DRAW) {

					//View是ViewGroup，需要绘制子View

					dispatchDraw(canvas);

					...

				} else {

					draw(canvas);

				}

			}

		} finally {

			//将绘制好后的数据填充到renderNode中去

			renderNode.end(canvas);

			setDisplayListProperties(renderNode);

		}

	}

}

updateDisplayListIfDirty主要作用：

• 1.获取当前View的RenderNode。


• 2.如果需要或者支持则更新当前DisplayList

判断是否需要进行重新构建的条件如下：

• 1.mPrivateFlags 设置了 PFLAG_DRAWING_CACHE_VALID，表明当前缓存已经失效，需要重新构建


• 2.!renderNode.isValid()：表明当前Display List的数据不合法，需要重新构建


• 3.mRecreateDisplayList的值等于true，一些其他原因需要重新构建

mRenderNode在View的构造方法中初始化：

public View(Context context) {

	...

	mRenderNode = RenderNode.create(getClass().getName(), this);

}

构建过程如下：

• 1.使用renderNode.start获得一个与当前View关联的DisplayListCanvas。


• 2.使用draw(canvas)，将当前View以及子View绘制到当前DisplayListCanvas


• 3.使用renderNode.end(canvas)，将已经绘制在 DisplayListCanvas 的 Display List Data 填充到当前 View 关联的 Render Node 中

通过上面几个步骤就将View树对应的DisplayList构建好了。而且这个构建过程会递归构建子View的Display List

我们从绘制流程火焰图中也可以看到大概流程：

红色框中部分：是绘制的DecorView的时候，一直递归updateDisplayListIfDirty方法进行Display List的构建
其他颜色框部分是子View Display List的构建

绘制阶段

这个阶段会调用OpenGL接口将构建好视图进行绘制渲染，将渲染好的内容保存到Graphic buffer中，并提交给SurfaceFlinger。

回到ThreadedRenderer的draw方法：
ThreadedRenderer.java

void draw(View view, AttachInfo attachInfo, DrawCallbacks callbacks) {

    ...

    updateRootDisplayList(view, callbacks);//1

    ...

    int syncResult = nSyncAndDrawFrame(mNativeProxy, frameInfo, frameInfo.length);//2

}

在注释1中创建好视图对应的Display List后，在注释2处调用nSyncAndDrawFrame方法通知RenderThread线程进行绘制

nSyncAndDrawFrame是一个native方法，在讲解nSyncAndDrawFrame方法前我们先来看ThreadedRenderer构造函数中做了哪些事。

ThreadedRenderer(Context context, boolean translucent, String name) {

	//这个方法在native层创建RootRenderNode对象并返回对象的地址

	long rootNodePtr = nCreateRootRenderNode();

	mRootNode = RenderNode.adopt(rootNodePtr);

	mRootNode.setClipToBounds(false);

	//这个方法在native层创建一个RenderProxy

	mNativeProxy = nCreateProxy(translucent, rootNodePtr);

}

nCreateRootRenderNode和nCreateProxy方法在android_view_ThreadedRenderer.cpp中实现：

static jlong android_view_ThreadedRenderer_createRootRenderNode(JNIEnv* env, jobject clazz) {

    RootRenderNode* node = new RootRenderNode(env);

    node->incStrong(0);

    node->setName("RootRenderNode");

    return reinterpret_cast(node);

}

static jlong android_view_ThreadedRenderer_createProxy(JNIEnv* env, jobject clazz,

        jboolean translucent, jlong rootRenderNodePtr) {

    RootRenderNode* rootRenderNode = reinterpret_cast(rootRenderNodePtr);

    ContextFactoryImpl factory(rootRenderNode);

    return (jlong) new RenderProxy(translucent, rootRenderNode, &factory);

}

RenderProxy构造方法：

RenderProxy::RenderProxy(bool translucent, RenderNode* rootRenderNode, IContextFactory* contextFactory)

        : mRenderThread(RenderThread::getInstance())//1

        , mContext(nullptr) {

    ...

}

注意到mRenderThread使用的是RenderThread::getInstance()单例线程，也就说整个绘制过程只有一个RenderThread线程。

接着看RenderThread::getInstance()创建线程的方法：

RenderThread::RenderThread() : Thread(true)

	...

	Properties::load();

    mFrameCallbackTask = new DispatchFrameCallbacks(this);

    mLooper = new Looper(false);

    run("RenderThread");

}

居然也是使用的Looper，是不是和我们的主线程的消息机制一样呢？哈哈
调用run方法会执行RenderThread的threadLoop方法。

bool RenderThread::threadLoop() {

	...

    int timeoutMillis = -1;

    for (;;) {

        int result = mLooper->pollOnce(timeoutMillis);

		...

        nsecs_t nextWakeup;

        {

            ...

            while (RenderTask* task = nextTask(&nextWakeup)) {

                workQueue.push_back(task);

            }

            for (auto task : workQueue) {

                task->run();

                // task may have deleted itself, do not reference it again

            }

        }

        if (nextWakeup == LLONG_MAX) {

            timeoutMillis = -1;

        } else {

            nsecs_t timeoutNanos = nextWakeup - systemTime(SYSTEM_TIME_MONOTONIC);

            timeoutMillis = nanoseconds_to_milliseconds(timeoutNanos);

            if (timeoutMillis < 0) {

                timeoutMillis = 0;

            }

        }



        if (mPendingRegistrationFrameCallbacks.size() && !mFrameCallbackTaskPending) {

			...

            requestVsync();

        }



        if (!mFrameCallbackTaskPending && !mVsyncRequested && mFrameCallbacks.size()) {

            ...

            requestVsync();

        }

    }



    return false;

}

石锤了就是应用程序主线程的消息机制模型，

• 
  
  
  
  1. 空闲的时候，Render Thread就睡眠在成员变量mLooper指向的一个Looper对象的成员函数pollOnce中。
  
  
  
  


• 
  
  
  
  2. 当其它线程需要调度Render Thread，就会向它的任务队列增加一个任务，然后唤醒Render Thread进行处理。Render Thread通过成员函数nextTask获得需要处理的任务，并且调用它的成员函数run进行处理。
  
  
  
  

这里做个小结：
ThreadedRenderer构造方法中

• 1.初始化mRootNode指向native层的一个RootRenderNode


• 2.初始化mNativeProxy指向native层的RenderProxy


• 3.在native层创建RenderProxy时，同时也会创建RenderThread线程，这个线程机制和我们主线程消息机制一直，轮询等待获取绘制任务。

好了回头看nSyncAndDrawFrame的native方法

nSyncAndDrawFrame同样也在android_view_ThreadedRenderer.cpp中实现：

static int android_view_ThreadedRenderer_syncAndDrawFrame(JNIEnv* env, jobject clazz,

        jlong proxyPtr, jlongArray frameInfo, jint frameInfoSize) {

    LOG_ALWAYS_FATAL_IF(frameInfoSize != UI_THREAD_FRAME_INFO_SIZE,

            "Mismatched size expectations, given %d expected %d",

            frameInfoSize, UI_THREAD_FRAME_INFO_SIZE);

    RenderProxy* proxy = reinterpret_cast(proxyPtr);

    env->GetLongArrayRegion(frameInfo, 0, frameInfoSize, proxy->frameInfo());

    return proxy->syncAndDrawFrame();

}

这个方法返回值是proxy->syncAndDrawFrame()，进入RenderProxy的syncAndDrawFrame方法：

int RenderProxy::syncAndDrawFrame() {

    return mDrawFrameTask.drawFrame();

}

这里的 mDrawFrameTask.drawFrame其实就是向RenderThread的TaskQueue添加一个drawFrame渲染任务，通知RenderThread渲染UI视图。

如下图：

mDrawFrameTask是DrawFrameTask中的函数

int DrawFrameTask::drawFrame() {

	...

    postAndWait();



    return mSyncResult;

}



void DrawFrameTask::postAndWait() {

    AutoMutex _lock(mLock);

    mRenderThread->queue(this);

    mSignal.wait(mLock);//锁住等待锁释放

}



void RenderThread::queue(RenderTask* task) {

    AutoMutex _lock(mLock);

    mQueue.queue(task);

    if (mNextWakeup && task->mRunAt < mNextWakeup) {

        mNextWakeup = 0;

        mLooper->wake();

    }

}

看到这就知道了drawFrame其实就是往RenderThread线程的任务队列mQueue中按时间顺序加入一个绘制task，并调用mLooper->wake()唤醒RenderThread线程处理。

说到底还是主线程消息机制那套东西。

注意DrawFrameTask在postAndWait的mRenderThread->queue(this)中是将this传入任务队列，所以此任务就是this自己。后面执行绘制任务就使用到了OpenGL对构建好的DisplayList进行渲染。

经过上面的分析，整个硬件绘制流程就有个清晰模型了

点到为止，后面代码大家可以自行找到源码阅读。

绘制阶段这块可能比较复杂些，因为基本上都是native层的东西，有的消化下。

硬件加速和纯软件绘制对比

呈现模式分析工具

Android 4.1（API 级别 16）或更高版本的设备上，

执行以下步骤开启工具：

• 1.启动开发者选项；


• 2.在“监控”部分，找到“GPU呈现模式分析”（不同厂商命名有所区别）；


• 3.点击“GPU呈现模式分析”，弹出页面中，选择“在屏幕上显示为条形图”即可。

这时，GPU 呈现模式工具已经开启了，接下来，我们可以打开我们要测试的APP来进行观察测试了。

视觉呈现

GPU 渲染模式分析工具以图表（以颜色编码的直方图）的形式显示各个阶段及其相对时间。

Android 10 上显示的彩色部分：

注意点:

• 1.一个应用对应一个图形


• 2.沿水平轴的每个竖条代表一个帧，每个竖条的高度表示渲染该帧所花的时间（以毫秒为单位）。


• 3.中间绿色的线是16.6ms的分割线，高于绿色线表示出现了掉帧


• 4.通过加宽竖条降低透明度来反应比较耗时的帧


• 5.每个竖条都有与渲染管道中某个阶段对应的彩色区段。区段数因设备的 API 级别不同而异。

颜色块含义

Android 6.0 及更高版本的设备时分析器输出中某个竖条的每个区段含义：

4.0（API 级别 14）和 5.0（API 级别 21）之间的 Android 版本具有蓝色、紫色、红色和橙色区段。低于 4.0 的 Android 版本只有蓝色、红色和橙色区段。下表显示的是 Android 4.0 和 5.0 中的竖条区段。

GPU 呈现模式工具，很直观的为我们展示了 APP 运行时每一帧的耗时详情。我们只需要关注代表每一帧的柱状图的颜色详情，就可以分析出卡顿的原因了。

好了，现在来回答标题帧的内容，既然硬件优化这么好用，为啥没被普及？

理由如下：

• 1.稳定性，开启硬件加速后，有小概率出现画面崩溃，所以在一些视频播放器会给个开关让用户手动开关。


• 2.功耗：GPU的功耗远远大于CPU，所以使用场景比较少，一般在游戏端开启硬件加速辅助游戏运行。


• 3.内存消耗：使用OpenGL接口初始化就需要8M作用的内存。


• 4.兼容性：不兼容某些接口和api。

这就是所谓的双刃剑吧！用得好还好，用不好就鸽蛋了。。

前言

接下来我们来了解一下 Path 类的一些特性。Path 类用于描述绘制路径，可以实现绘制线段、曲线、自定义形状等功能。本篇我们介绍 Path 的一个描述类 PathMetric 的应用。通过本篇你会了解以下两方面的内容：

• PathMetric 类简介。


• PathMetric 的应用。

PathMetric 简介

PathMetric 是一个用于测量 Path 和抽取子路径（sub-paths） 的工具，通过 Path 类的 computeMetrics方法可以返回一组PathMetric 类。为什么是一组，而不是一个呢？这是因为 Path 可能包含多个不连续的子路径，比如通过 moveTo 可以重新开启新的一段路径。
通过 PathMetric 可以获取到 Path 的长度，路径是否闭合，以及某一段路径是否是 Path的子路径。PathMetrics 是一个迭代器，因此在不获取其中的 PathMetric 对象时，并不会实际进行 Path 的相关计算，这样可以提高效率。另外需要注意的是，通过 computeMetrics 方法计算得到的是一个当前Path 对象的快照，如果在之后更改了 Path 对象，并不会进行更新。
我们来看一下 PathMetric 的一些属性和方法。

• length：Path 对象其中一段（独立的）的长度；


• isClosed：判断 Path 对象是否闭合；


• contourIndex：当前对象在 PathMetrics 中的次序；


• getTangentForOffset：这个方法通过距离起点的长度的偏移量（即从0 到 length 中的某个位置）返回一个 Tangent 对象，通过这个对象可以获取到 Path 某一段路径途中的任意一点的位置以及角度。以下面的图形为例，从点（0, 0）到点（2, 2）的线段总长度为2.82，如果我们通过getTangentForOffset获取距离起始点1.41 的位置的Tangent 对象，就会得到该位置的坐标是(1, 1)，角度是45度（实际以弧度的方式计算）。

• extractPath：通过距离 Path 起点的开始距离和结束距离获取这段路劲的子路径，如下图所示。

PathMetric 应用

我们来通过 PathMetric 实现下面动图的效果。

这张图最开始绘制的是一条贝塞尔曲线，是通过 Path 自带的贝塞尔曲线绘制的，代码如下所示。

Path path = Path();

final curveHeight = 60.0;

final stepWidth = size.width / 4;

path.moveTo(0, size.height / 2);

path.quadraticBezierTo(size.width / 2 - stepWidth,

    size.height / 2 - curveHeight, size.width / 2, size.height / 2);

path.quadraticBezierTo(size.width / 2 + stepWidth,

    size.height / 2 + curveHeight, size.width, size.height / 2);

quadraticBezierTo这个方法就是从 Path 当前的终点到参数3，4（参数名为 x2，y2）绘制一条贝塞尔曲线，控制点为参数1，2（参数名为 x1，y1）。
动画过程中曲线上的红色圆点就是通过 PathMetric 得到的，动画对象 Animation 的值从0-1变化，我们通过这个值乘以曲线的长度就能得到getTangentForOffset方法所需的偏移量，然后就可以确定动画过程中绘制圆点的位置了，代码如下所示。

for (var pathMetric in metrics) {

    var tangent =

        pathMetric.getTangentForOffset(pathMetric.length * animationValue);

  

    paint.style = PaintingStyle.fill;

    canvas.drawCircle(tangent!.position, 4.0, paint);

}

接下来是动画过程中的我们看到红色曲线会逐步覆盖蓝色曲线，这就是用 extractPath获取子路径完成的，在动画过程，我们控制 extractPath的结束位置，就可以逐步完成原有曲线的覆盖了，实现代码只有两行，如下所示。

var subPath =

    pathMetric.extractPath(0.0, pathMetric.length * animationValue);

canvas.drawPath(subPath, paint);

最后是底下的填充，填充我们使用了渐变色，这个利用了之前我们讲过的Paint 对象的 shader 属性实现，具体可以参考之前的文章。填充其实就是一段闭合的 Path，只是在动画过程中控制右边绘制的边界就可以了，然后上面跟随曲线的部分还是基于子路径完成的。填充部分实现代码如下。

var fillPath = Path();

fillPath.moveTo(0, size.height);

fillPath.lineTo(0, size.height / 2);

fillPath.addPath(subPath, Offset(0, 0));

fillPath.lineTo(tangent.position.dx, size.height);

fillPath.lineTo(0, size.height);

paint.shader = LinearGradient(

  begin: Alignment.topCenter,

  end: Alignment.bottomCenter,

  colors: [Colors.red[400]!, Colors.blue[50]!],

).createShader(Rect.fromLTRB(

  0,

  size.height / 2 - curveHeight,

  size.width,

  size.height,

));

canvas.drawPath(fillPath, paint);

完整代码已经提交至：绘图相关代码，文件名为：path_metrics_demo.dart。

总结

本篇介绍了 Flutter 路径Path 的工具类 PathMetric的介绍和应用，通过 PathMetric 我们可以定位到 Path 的指定位长度的位置的信息，也可以通过起始点从 Path 中抽取子路径。有了这些基础，就可以实现很多场景的应用，比如曲线上布局标识或填充，标记指定位置的点等等。

Kotlin 拥有函数式编程的能力，运用得当，可以简化代码，层次清晰，利于阅读，用过都说好。

然而操作符数量众多，根据使用场景选择合适的操作符是一个很大的难题，网上搜索了许久只是学习了一个操作符，还要再去验证它，实在浪费时间，开发效率低下。

一种方式是转至命令式开发，将过程按步骤实现，即可完成需求；另一种方式便是一次学习多个操作符，在下次选择操作符时，增加更多选择。

本篇文章当然关注的是后者，列举一些比较常用 Kotlin 操作符，为提高效率助力，文中有图有代码有讲解，文末有参考资料和一个交互式学习的网站。

让我们开始吧。

1. reduce

reduce 操作符可以将所有数据累加（加减乘除）得到一个结果

listOf(1, 2, 3).reduce { a, b ->

    a + b

}



输出：6

如果 flow 中没有数据，将抛出异常。如不希望抛异常，可使用 reduceOrNull 方法。

reduce 操作符不能变换数据类型。比如，Int 集合的结果不能转换成 String 结果。

2. fold

fold 和 reduce 很类似，但是 fold 可以变换数据类型

有时候，我们不需要一个结果值，而是需要继续操 flow，可使用 runningFold 。

flowOf(1, 2, 3).runningFold("a") { a, b ->

    a + b

}.collect {

    println(it)

}



输出：

a

a1

a12

a123

同样的，reduce 也有类似的方法 runningReduce

flowOf(1, 2, 3).runningReduce { a, b ->

    a + b

}.collect {

    println(it)

}



输出：

1

3

6

3. debounce

debounce 需要传递一个毫秒值参数，功能是：只有达到指定时间后才发出数据，最后一个数据一定会发出。

例如，定义 1000 毫秒，也就是 1 秒，被观察者发出数据，1秒后，观察者收到数据，如果 1 秒内多次发出数据，则重置计算时间。

flow {

    emit(1)

    delay(590)

    emit(2)

    delay(590)

    emit(3)

    delay(1010)

    emit(4)

    delay(1010)

}.debounce(

    1000

).collect {

    println(it)

}



输出结果：

3

4

rebounce 的应用场景是限流功能

4. sample

sample 和 debounce 很像，功能是：在规定时间内，只发送一个数据

flow {

    repeat(4) {

        emit(it)

        delay(50)

    }

}.sample(100).collect {

    println(it)

}



输出结果：

1

3

sample 的应用场景是截流功能

debounce 和 sample 的限流和截流功能已有网友实现，点击这里

5. flatmapMerge

简单的说就是获得两个 flow 的乘积或全排列，合并并且平铺，发出一个 flow。

描述的仍然不好理解，一看代码便能理解了

flowOf(1, 3).flatMapMerge {

    flowOf("$it a", "$it b")

}.collect {

    println(it)

}



输出结果：

1 a

1 b

3 a

3 b

flatmapMerge 还有一个特性，在下一个操作符里提及。

6. flatmapConcat

先看代码。

flowOf(1, 3).flatMapConcat {

    flowOf("a", "b", "c")

}.collect {

    println(it)

}

功能和 flatmapMerge 一致，不同的是 flatmapMerge 可以设置并发量，可以理解为 flatmapMerge 是线程安全的，而 flatmapConcat 不是线程安全的。

本质上，在 flatmapMerge 的并发参数设置为 1 时，和 flatmapConcat 基本一致，而并发参数大于 1 时，采用 channel 的方式发出数据，具体内容请参阅源码。

7. buffer

介绍 buffer 的时候，先要看这样一段代码。

flowOf("A", "B", "C", "D")

.onEach {

    println("1 $it")

}

.collect { println("2 $it") }



输出结果：

1 A

2 A

1 B

2 B

1 C

2 C

1 D

2 D

注意输出的内容。

加上 buffer 的代码。

flowOf("A", "B", "C", "D")

.onEach {

    println("1 $it")

}

.buffer()

.collect { println("2 $it") }



输出结果：

1 A

1 B

1 C

1 D

2 A

2 B

2 C

2 D

输出内容有所不同，buffer 操作符可以改变收发顺序，像有一个容器作为缓冲似的，在容器满了或结束时，下游开始接到数据，onEach 添加延迟，效果更明显。

8. combine

合并两个 flow，长的一方会持续接受到短的一方的最后一个数据，直到结束

flowOf(1, 3).combine(

    flowOf("a", "b", "c")

) { a, b -> b + a }

.collect {

    println(it)

}



输出结果：

a1

b3

c3

9. zip

也是合并两个 flow，结果长度与短的 flow 一致，很像木桶原理。 

flowOf(1, 3).zip(

    flowOf("a", "b", "c")

) { a, b -> b + a }

.collect {

    println(it)

}



输出结果：

a1

b3

10. distinctUntilChanged

就像方法名写的那样，和前一个数据不同，才能收到，和前一个数据想通，会被过滤掉。

flowOf(1, 1, 2, 2, 3, 1).distinctUntilChanged().collect {

    println(it)

}



输出结果：

1

2

3

1

最后

以上就是今天要介绍的操作符，希望对大家有所帮助。

参考文章：Android — 9 Useful Kotlin Flow Operators You Need to Know

Kotlin 交互式操作符网站：交互式操作符网站

1 wait和 sleep 的区别

wait是Object的方法，wait是对象锁，锁定方法不让继续执行，当执行notify方法后就会继续执行，sleep 是Thread的方法，sleep 是使线程睡眠，让出cpu，结束后自动继续执行

2 View和SurfaceView的区别

View基于主线程刷新UI，SurfaceView子线程又可以刷新UI

3. View的绘制原理

View为所有图形控件的基类，View的绘制由3个函数完成
measure,计算视图的大小
layout,提供视图要显示的位置
draw,绘制

4. 简述TCP，UDP，Socket

TCP是经过3次握手，4次挥手完成一串数据的传送
UDP是无连接的，知道IP地址和端口号，向其发送数据即可，不管数据是否发送成功
Socket是一种不同计算机，实时连接，比如说传送文件，即时通讯

5.进程和线程的区别

概念：进程包括多个线程，一个程序一个进程，多线程的优点可以提高执行效率，提高资源利用率
创建：Thread类和Runnable接口，
常用方法有：
start()用于启动线程
run()调用线程对象中的run方法
join()合并插队到当前线程
sellp()睡眠释放cpu资源
setPriority()设置线程优先级

6.RecyclerView和ListView的区别

缓存上:前者缓存的是View+ViewHolder+flag，不用每次调用findViewById,后者则只是缓存View
刷新数据方面，前者提供了局部刷新，后者则全部刷新

7.MVC ，MVP，MVVM

MVC:View是可以直接访问Model的！从而，View里会包含Model信息，不可避免的还要包括一些 业务逻辑。 在MVC模型里，更关注的Model的不变，而同时有多个对Model的不同显示，及View。所以，在MVC模型里，Model不依赖于View，但是 View是依赖于Model的。不仅如此，因为有一些业务逻辑在View里实现了，导致要更改View也是比较困难的，至少那些业务逻辑是无法重用的。
MVP：MVP 是从经典的模式MVC演变而来，它们的基本思想有相通的地方：Controller/Presenter负责逻辑的处理，Model提供数据，View负 责显示。作为一种新的模式，MVP与MVC有着一个重大的区别：在MVP中View并不直接使用Model，它们之间的通信是通过Presenter (MVC中的Controller)来进行的，所有的交互都发生在Presenter内部，而在MVC中View会从直接Model中读取数据而不是通过 Controller。
MVVM：数据双向绑定，通过数据驱动UI，M提供数据，V视图，VM即数据驱动层

8.说下 Activity 跟 跟 window ， view 之间的关系？

Activity 创建时通过 attach()初始化了一个 Window 也就是PhoneWindow，一个 PhoneWindow 持有一个DecorView 的实例，DecorView 本身是一个 FrameLayout，继承于 View，Activty 通过setContentView 将xml 布局控件不断 addView()添加到 View 中，最终显示到 Window 于我们交互；

9.Java中堆和栈的理解

在Java中内存分为两种，一种是栈内存，另一种是堆内存

堆内存：用于存储Java中的对象和数组，当我们new一个对象或创建一个数组的时候，就会在堆内存中开辟一段空间给它，用于存放，堆内存的特点：先进先出，后今后出，②可以动态的分配内存的大小，生存期不必告诉编译器，但存取速度较慢；

栈内存：主要用来执行程序用，比如基本类型的变量和对象的引用变量，其特点：①先进后出，后进后出，②存取速度比堆快，仅次于寄存器，栈数据可以共享，但其在栈中的数据大小和生存期必须是确定的；

栈内存和堆内存都属于Java内存的一种，系统会自动去回收它，但对于堆内存开发人员一般会自动回收。

栈是一块和线程紧密相关的内存区域，每个线程都有自己的栈内存，用于存储本地变量、方法参数和栈调用一个线程中存储的变量，对于其他线程是不可见的，而堆是所有线程共享的一个公用内存区域，对象都在堆里创建，但为了提升效率，线程会从堆中拷贝一个缓存到自己的栈中，如果多个线程使用该变量，就可能引发问题，这是volatile修饰变量就可以发挥作用，他要求线程从主存中读取变量的值。

10.Android常用的数据存储方式（4种）

使用SharedPreference存储：保存基于xml文件存储的key-value键值对数据，通常用来存储一些简单的配置信息；

文件存储方式：Context提供了两个方法来打开数据文件的文件IO流；

SQLite存储数据：SQLite是轻量级的嵌入式数据库引擎，支持SQL语言；

网络存储数据：通过网络存储数据；

11.Activity生命周期中的7个方法：

onCreate( )：当Activity被创建时调用；

onStart( )：当Activity被创建后将可见时调用；

onResume( )：（继续开始）当Activity位于设备最前端，对用户可见时调用；

onPause( )：（暂停）当另一个Activity遮挡当前Activity，当前Activity被切换到后台时调用；

onRestart( )：（重新启动）当另一个Activity执行完onStop（）方法，又被用户打开时调用；

onStop( )：如果另一个Activity完全遮挡了当前Activity时，该方法被调用；

onDestory( )：当Activity被销毁时调用；

12.Activity的四种启动模式

standard、singleTop、singleTask和singleInstance，他们是在配置文件中通过android：LauchMode属性配置；

standard：默认的启动模式，每次启动会在任务栈中新建一个启动的Activity的实例；

SingleTop：如果要启动的Activity实例已位于栈顶，则不会重新创建该Activity的实例，否则会产生一个新的运行实例；

SingleTask：如果栈中有该Activity实例，则直接启动，中间的Activity实例将会被关闭，关闭的顺序与启动的顺序相同；

SingleInstance：该启动模式会在启动一个Activity时，启动一个新的任务栈，将该Activity实例放置在这个任务栈中，并且该任务栈中不会再保存其他的Activity实例；

Activity任务栈：即存放Activity任务的栈，每打开一个Activity时就会往Activity栈中压入一个Activity

任务，每当销毁一个Activity的时候，就会从Activity任务栈中弹出一个Activity任务，

由于安卓手机的限制，只能从手机屏幕获取当前一个Activity的焦点，即栈顶元素（

最上面的Activity)，其余的Activity会暂居后台等待系统的调用；

13.View的绘制原理

View为所有图形控件的基类，View的绘制由3个函数完成
measure,计算视图的大小
layout,提供视图要显示的位置
draw,绘制

14.Okhttp连接池复用机制

15. Rxjava里面有几个角色

Observable：俗称被订阅者，被订阅者是事件的来源，接收订阅者(Observer)的订阅，然后通过发射器(Emitter)发射数据给订阅者。

Observer：俗称订阅者，注册过程传给被订阅者，订阅者监听开始订阅，监听订阅过程中会把Disposable传给订阅者，然后在被订阅者中的发射器(Emitter)发射数据给订阅者(Observer)。

Emitter：俗称发射器，在发射器中会接收下游的订阅者(Observer)，然后在发射器相应的方法把数据传给订阅者(Observer)。

Consumer：俗称消费器，消费器其实是Observer的一种变体，Observer的每一个方法都会对应一个Consumer，比如Observer的onNext、onError、onComplete、onSubscribe都会对应一个Consumer。

Disposable：是释放器，通常有两种方式会返回Disposable，一个是在Observer的onSubscribe方法回调回来，第二个是在subscribe订阅方法传consumer的时候会返回

16.RxJava操作符包含的操作符类型有如下几种：

1、创建操作符 ：创建被观察者（Observable）对象&发送事件

2、转换操作符：变换被观察者(Observable)发送的事件。将Observable发送的数据按照一定的规则做一些变换，然后再将变换的数据发射出去。变换的操作符有map,flatMap，concatMap,switchMap,buffer,groupBy等等。

3、 合并操作符：组合多个被观察者(Observable)&合并需要发送的事件。包含：concatMap(),concat(), merge(),mergeArray(),concateArray(),reduce(),collect(),startWith(),zip(),count()等

4、功能操作符：辅助被观察者(Observable) 发送事件时实现一些功能性需求，如错误处理，线程调度。
5、过滤操作符：用于将Observable发送的数据进行过滤和选择。让Observable返回我们所需要的数据。过滤操作符有buffer()，filter()，skip()，take()，skipLast()，takeLast()，throttleFirst()，distainctUntilChange()。

Kotlin 的标准库提供了不少方便的实用工具函数，比如 with, let, apply 之流，这些工具函数有一个共同特征：都调用了 contract() 函数。

@kotlin.internal.InlineOnly

public inline fun <T, R> with(receiver: T, block: T.() -> R): R {

    contract {

        callsInPlace(block, InvocationKind.EXACTLY_ONCE)

    }

    return receiver.block()

}



@kotlin.internal.InlineOnly

public inline fun repeat(times: Int, action: (Int) -> Unit) {

    contract { callsInPlace(action) }



    for (index in 0 until times) {

        action(index)

    }

}

contract？协议？它到底是起什么作用？

函数协议

contract 其实就是一个顶层函数，所以可以称之为函数协议，因为它就是用于函数约定的协议。

@ContractsDsl

@ExperimentalContracts

@InlineOnly

@SinceKotlin("1.3")

@Suppress("UNUSED_PARAMETER")

public inline fun contract(builder: ContractBuilder.() -> Unit) { }

用法上，它有两点要求：

• 仅用于顶层方法
• 协议描述须置于方法开头，且至少包含一个「效应」（Effect）

可以看到，contract 的函数体为空，居然没有实现，真是一个神奇的存在。这么一来，此方法的关键点就只在于它的参数了。

ContractBuilder

contract的参数是一个将 ContractBuilder 作为接受者的lambda，而 ContractBuilder 是一个接口：

@ContractsDsl

@ExperimentalContracts

@SinceKotlin("1.3")

public interface ContractBuilder {

    @ContractsDsl public fun returns(): Returns

    @ContractsDsl public fun returns(value: Any?): Returns

    @ContractsDsl public fun returnsNotNull(): ReturnsNotNull

    @ContractsDsl public fun <R> callsInPlace(lambda: Function<R>, kind: InvocationKind = InvocationKind.UNKNOWN): CallsInPlace

}

其四个方法分别对应了四种协议类型，它们的功能如下：

• returns：表明所在方法正常返回无异常
• returns(value: Any?)：表明所在方法正常执行，并返回 value（其值只能是 true、false 或者 null）
• returnsNotNull()：表明所在方法正常执行，且返回任意非 null 值
• callsInPlace(lambda: Function<R>, kind: InvocationKind = InvocationKind.UNKNOWN)：声明 lambada 只在所在方法内执行，所在方法执行完毕后，不会再被其他方法调用；可通过 kind 指定调用次数

前面已经说了，contract 的实现为空，所以作为接受着的 ContractBuilder 类型，根本没有实现类 —— 因为没有地方调用，就不需要啊。它的存在，只是为了声明所谓的协议代编译器使用。

InvocationKind

InvocationKind 是一个枚举类型，用于给 callsInPlace 协议方法指定执行次数的说明：

@ContractsDsl

@ExperimentalContracts

@SinceKotlin("1.3")

public enum class InvocationKind {

    // 函数参数执行一次或者不执行

    @ContractsDsl AT_MOST_ONCE,

    // 函数参数至少执行一次

    @ContractsDsl AT_LEAST_ONCE,

    // 函数参数执行一次

    @ContractsDsl EXACTLY_ONCE,

    // 函数参数执行次数未知

    @ContractsDsl UNKNOWN

}

InvocationKind.UNKNOWN，次数未知，其实就是指任意次数。标准工具函数中，repeat 就指定的此类型，因为其「重复」次数由参数传入，确实未知；而除它外，其余像 let、with 这些，都是用的InvocationKind.EXACTLY_ONCE，即单次执行。

Effect

Effect 接口类型，表示一个方法的执行协议约定，其不同子接口，对应不同的协议类型，前面提到的 Returns、ReturnsNotNull、CallsInPlace 均为它的子类型。

public interface Effect



public interface ConditionalEffect : Effect



public interface SimpleEffect : Effect {

    public infix fun implies(booleanExpression: Boolean): ConditionalEffect

}



public interface Returns : SimpleEffect



public interface ReturnsNotNull : SimpleEffect



public interface CallsInPlace : Effect

简单明了，全员接口！来看一个官方使用，以便理解下这些接口的意义和使用：

public inline fun Array<*>?.isNullOrEmpty(): Boolean {

    contract {

        returns(false) implies (this@isNullOrEmpty != null)

    }



    return this == null || this.isEmpty()

}

这里涉及到两个 Effect：Returns 和 ConditionalEffect。此方法的功能为：判断数组为 null 或者是无元素空数组。它的 contract 约定是这样的：

1. 调用 returns(value: Any?) 获得 Returns 协议（当然也就是 SimpleEffect 协议），其传入值是 false
2. 第1步的 Returns 调用 implies 方法，条件是「本对象非空」，得到了一个 ConditionalEffect
3. 于是，最终协议的意思是：函数返回 false 意味着 接受者对象非空

isNullOrEmpty() 的功能性代码给出了返回值为 true 的条件。虽然反过来说，不满足该条件，返回值就是 false，但还是通过 contract 协议里首先说明了这一点。

协议的意义

讲到这里，contract 协议涉及到的基本类型及其使用已经清楚了。回过头来，前面说到，contract() 的实现为空，即函数体为空，没有实际逻辑。这说明，这个调用是没有实际执行效果的，纯粹是为编译器服务。

不妨模仿着 let 写一个带自定义 contract 测试一下这个结论：

// 类比于ContractBuilder

interface Bonjour {



    // 协议方法

    fun <R> parler(f: Function<R>)  {

        println("parler something")

    }

}





// 顶层协议声明工具，类比于contract

inline fun bonjour(b: Bonjour.() -> Unit) {}





// 模仿let

fun<T, R> T.letForTest(block: (T) -> R): R {

    println("test before")

    bonjour {

        println("test in bonjour")

        parler<String> {

            ""

        }

    }

    println("test after")

    return block(this)

}



fun main(args: Array<String>) {

    "abc".letForTest {

        println("main: $it called")

    }

}

letForTest() 是类似于 let 的工具方法（其本身功能逻辑不重要）。执行结果：

test before

test after

main: abc called

如预期，bonjour 协议以及 Bonjour 协议构造器中的所有日志都未打印，都未执行。

这再一次印证，contract 协议仅为编译器提供信息。那协议对编码来说到底有什么意义呢？来看看下面的场景：

fun getString(): String? {

    TODO()

}



fun String?.isAvailable(): Boolean {

    return this != null && this.length > 0

}

getString() 方法返回一个 String 类型，但是有可能为 null。isAvailable 是 String? 类型的扩展，用以判断是否一个字符串非空且长度大于 0。使用如下：

val target = getString()

if (target.isAvailable()) {

    val result: String = target

}

按代码的设计初衷，上述调用没问题，target.isAvailable() 为 true，证明 target 是非空且长度大于 0 的字符串，然后内部将它赋给 String 类型 —— 相当于 String? 转换成 String。

可惜，上述代码，编译器不认得，报错了：

Type mismatch.

    Required:

        String

    Found:

        String?

编译器果然没你我聪明啊！要解决这个问题，自然就得今天的主角上场了：

fun String?.isAvailable(): Boolean {

    contract {

        returns(true) implies (this@isAvailable != null)

    }

    return this != null && this.length > 0

}

使用 contract 协议指定了一个 ConditionalEffect，描述意思为：如果函数返回true，意味着 Receiver 类型非空。然后，编译器终于懂了，前面的错误提示消失。

这就是协议的意义所在：让编译器看不懂的代码更加明确清晰。

小结

函数协议可以说是写工具类函数的利器，可以解决很多因为编译器不够智能而带来的尴尬问题。不过需要明白的是，函数协议还是实验性质的，还没有正式发布为 stable 功能，所以是有可能被 Kotlin 官方 去掉的。

前言

我曾经在一篇介绍 Compose Navigation 的文章 中提到了 Navigation 的状态保存实际是由 rememberSaveable 实现的，有同学反馈希望单独介绍一下 rememberSaveable 的功能及实现原理。

我们都知道 remember 可以保存数据、避免状态因重组而丢失，但它依然无法避免在 ConfigurationChanged 时的数据丢失。想要在横竖屏切换等场景下依然保存状态，就需要使用 rememberSavable。

从一个报错说起

首先，在代码使用上 rememberSaveable 和 remember 没有区别：

//保存列表状态

val list = rememberSaveable {

    mutableListOf<String>()

}



//保存普通状态

var value by rememberSaveable {

    mutableStateOf("")

}

如上，只要将 remember 改为 rememberSaveable，我们创建的状态就可以跨越横竖屏切换甚至跨越进程持续保存了。不过 rememberSaveable 中并非任何类型的值都可以存储：

data class User(

    val name: String = ""

)



val user = rememberSaveable {

    User()

}

上面代码运行时会发生错误：

java.lang.IllegalArgumentException: User(name=) cannot be saved using the current SaveableStateRegistry. The default implementation only supports types which can be stored inside the Bundle. Please consider implementing a custom Saver for this class and pass it to rememberSaveable().

User 无法存入 Bundle。这非常合理，因为 rememberSaveable 中数据的持久化最终在 ComponentActivity#onSaveInstanceState 中执行，这需要借助到 Bundle 。

rememberSaveable 源码分析

那么，rememberSaveable 是如何关联到 onSaveInstanceState 的呢？接下来简单分析一下内部实现

@Composable

fun <T : Any> rememberSaveable(

    vararg inputs: Any?,

    saver: Saver<T, out Any> = autoSaver(),

    key: String? = null,

    init: () -> T

): T {

    //...



    // 通过 CompositionLocal 获取 SaveableStateRegistry

    val registry = LocalSaveableStateRegistry.current

    

    // 通过 init 获取需要保存的数据

    val value = remember(*inputs) {

        // registry 根据 key 恢复数据，恢复的数据是一个 Saveable

        val restored = registry?.consumeRestored(finalKey)?.let {

            // 使用 Saver 将 Saveable 转换为业务类型

            saver.restore(it)

        }

        restored ?: init()

    }



    // 用一个 MutableState 保存 Saver，主要是借助 State 的事务功能避免一致性问题发生

    val saverHolder = remember { mutableStateOf(saver) }

    saverHolder.value = saver



    if (registry != null) {

        DisposableEffect(registry, finalKey, value) {

            //ValueProvider：通过 Saver#save 存储数据

            val valueProvider = {

                with(saverHolder.value) { SaverScope { registry.canBeSaved(it) }.save(value) }

            }

            //试探数值是否可被保存

            registry.requireCanBeSaved(valueProvider())

            //将ValueProvider 注册到 registry ，等到合适的时机被调用

            val entry = registry.registerProvider(finalKey, valueProvider)

            onDispose {

                entry.unregister()

            }

        }

    }

    return value

}

如上，逻辑很清晰，主要是围绕 registry 展开的：

1. 通过 key 恢复持久化的数据


2. 基于 key 注册 ValueProvider，等待合适时机执行数据持久化


3. 在 onDispose 中被注销注册

registry 是一个 SaveableStateRegistry 。

恢复 key 的数据

rememberSaveable 是加强版的 remember，首先要具备 remember 的能力，可以看到内部也确实是调用了 remember 来创建数据同时缓存到 Composition 中。init 提供了 remember 数据的首次创建。被创建的数据在后续某个时间点进行持久化，下次执行 rememberSaveable 时会尝试恢复之前持久化的数据。具体过程分为以下两步：

1. 通过 registry.consumeRestored 查找 key 获取 Saveable，


2. Saveable 经由 saver.restore 转换为业务类型。

上述过程涉及到两个角色：

• SaveableStateRegistry：通过 CompositionLocal 获取，它负责将 Bundle 中的数据反序列化后，返回一个 Saveable


• Saver：Saver 默认有 autoSaver 创建，负责 Saveable 与业务数据之间的转换。

Saveable 并不是一个在具体类型，它可以是可被持久化（写入 Bundle）的任意类型。对于 autoSaver 来说， 这个 Saveable 就是业务数据类型本身。

private val AutoSaver = Saver<Any?, Any>(

    save = { it },

    restore = { it }

)

对于一些复杂的业务结构体，有时并非是所有字段都需要持久化。Saver 为我们提供了这样一个机会机会，可以按照需要将业务类型转化为可序列化类型。Compose 也提供了两个预置的 Saver：ListSaver 和 MapSaver，可以用来转换成 List 或者 Map。

关于恢复数据的 Key ：可以看到数据的保存和恢复都依赖一个 key，按道理 key 需要在保存和恢复时严格保持一致 ，但我们平日调用 rememberSaveable 时并没有指定具体的 key，那么在横竖屏切换甚至进程重启后是如何恢复数据的呢？其实这个 key 是 Compose 自动帮我们设置的，它就是编译期插桩生成的基于代码位置的 key ，所以可以保证每次进程执行到此处都保持不变

注册 ValueProvider

SaveableStateRegistry 在 DisposableEffect 中关联 key 注册 ValueProvider。
ValueProvider 是一个 lambda，内部会调用 Saver#save 将业务数据转化为 Saveable。

Saver#save 是 SaverScope 的扩展函数，所以这里需要创建一个 SaverScope 来调用 save 方法。SaverScope 主要用来提供 canBeSaved 方法，我们在自定义 Saver 时可以用来检查类型是否可被持久化

ValueProvider 创建好后紧接着会调用 registry.registerProvider 进行注册，等待合适的时机（比如 Activity 的 onSaveInstanceState）被调用。在注册之前，先调用 requireCanBeSaved 判断数据类型是否可以保存，这也就是文章前面报错的地方。先 mark 一下，稍后我们看一下具体检查的实现。

注销 registry

最后在 onDispose 中调用 unregister 注销之前的注册 。

rememberSaveable 的基本流程理清楚了，可以看见主角就是 registry，因此有必要深入 SaveableStateRegistry 去看一下。我们顺着 LocalSaveableStateRegistry 可以很容易找到 registry 的出处。

DisposableSavableStateRegistry 源码分析

override fun setContent(content: @Composable () -> Unit) {

    //...

    ProvideAndroidCompositionLocals(owner, content)

    //...

}



@Composable

@OptIn(ExperimentalComposeUiApi::class)

internal fun ProvideAndroidCompositionLocals(

    owner: AndroidComposeView,

    content: @Composable () -> Unit

) {

    val view = owner

    val context = view.context

    

    //...

    

    val viewTreeOwners = owner.viewTreeOwners ?: throw IllegalStateException(

        "Called when the ViewTreeOwnersAvailability is not yet in Available state"

    )

    val saveableStateRegistry = remember {

        DisposableSaveableStateRegistry(view, viewTreeOwners.savedStateRegistryOwner)

    }



    //...

    CompositionLocalProvider(

        //...

        LocalSaveableStateRegistry provides saveableStateRegistry,

        //...

    ) {

        ProvideCommonCompositionLocals(

            owner = owner,

            //...

            content = content

        )

    }

}

如上，我们在 Activity 的 setContent 中设置各种 CompositionLocal，其中就有 LocalSaveableStateRegistry，所以 registry 不仅是一个 SaveableStateRegistry，更是一个 DisposableSaveableStateRegistry 。

接下来看一下 DisposableSaveableStateRegistry 的创建过程 。

saveableStateRegistry 与 SavedStateRegistry

注意下面这个 DisposableSaveableStateRegistry 不是真正的构造函数，它是同名构造函数的一个 Wrapper，在调用构造函数创建实例之前，先调用 androidxRegistry 进行了一系列处理：

internal fun DisposableSaveableStateRegistry(

    id: String,

    savedStateRegistryOwner: SavedStateRegistryOwner

): DisposableSaveableStateRegistry {

    //基于 id 创建 key

    val key = "${SaveableStateRegistry::class.java.simpleName}:$id"

    

    // 基于 key 获取 bundle 数据

    val androidxRegistry = savedStateRegistryOwner.savedStateRegistry

    val bundle = androidxRegistry.consumeRestoredStateForKey(key)

    val restored: Map<String, List<Any?>>? = bundle?.toMap()



    // 创建 saveableStateRegistry，传入 restored 以及 canBeSaved

    val saveableStateRegistry = SaveableStateRegistry(restored) {

        canBeSavedToBundle(it)

    }

    

    val registered = try {

        androidxRegistry.registerSavedStateProvider(key) {

            //调用 register#performSave 并且转为 Bundle

            saveableStateRegistry.performSave().toBundle()

        }

        true

    } catch (ignore: IllegalArgumentException) {

        false

    }

    

    return DisposableSaveableStateRegistry(saveableStateRegistry) {

        if (registered) {

            androidxRegistry.unregisterSavedStateProvider(key)

        }

    }

}

androidxRigistry 跟 rememberSaveable 中的 registry 做的事情类似：

1. 基于 key 恢复 bundle 数据，


2. 基于 key 注册 SavedStateProvider。

但 androidxRegistry 不是一个 SaveableStateRegistry 而是一个 SavedStateRegistry。名字上有点绕，后者来自 androidx.savedstate ，属于平台代码，而 SaveableStateRegistry 属于 compose-runtime 的平台无关代码。可见这个构造函数的同名 Wrapper 很重要，他就像一个桥梁，解耦和关联了平台相关和平台无关代码。

DisposableSaveableStateRegistry 与 SaveableStateRegistryImpl

DisposableSaveableStateRegistry 真正的构造函数定义如下：

internal class DisposableSaveableStateRegistry(

    saveableStateRegistry: SaveableStateRegistry,

    private val onDispose: () -> Unit

) : SaveableStateRegistry by saveableStateRegistry {



    fun dispose() {

        onDispose()

    }

}

这里用了参数 saveableStateRegistry 作为 SaveableStateRegistry 接口的代理。saveableStateRegistry 实际是一个 SaveableStateRegistryImpl 对象，它像这样创建:

val saveableStateRegistry = SaveableStateRegistry(restored) {

    canBeSavedToBundle(it)

}



fun SaveableStateRegistry(

    restoredValues: Map<String, List<Any?>>?,

    canBeSaved: (Any) -> Boolean

): SaveableStateRegistry = SaveableStateRegistryImpl(restoredValues, canBeSaved)

SaveableStateRegistryImpl 被创建时传入两个参数：

• restoredValues：androidxRegistry 恢复的 bundle 数据，是一个 Map 对象。


• canBeSaved : 用来检查数据是否可持久化，可以的看到这里实际调用了 canBeSavedToBundle。

canBeSavedToBundle

文章开头的报错就是 requireCanBeSaved -> canBeSavedToBundle 检查出来的，通过 canBeSavedToBundle 看一下 rememberSaveable 支持的持久化类型：

private fun canBeSavedToBundle(value: Any): Boolean {

    // SnapshotMutableStateImpl is Parcelable, but we do extra checks

    if (value is SnapshotMutableState<*>) {

        if (value.policy === neverEqualPolicy<Any?>() ||

            value.policy === structuralEqualityPolicy<Any?>() ||

            value.policy === referentialEqualityPolicy<Any?>()

        ) {

            val stateValue = value.value

            return if (stateValue == null) true else canBeSavedToBundle(stateValue)

        } else {

            return false

        }

    }

    for (cl in AcceptableClasses) {

        if (cl.isInstance(value)) {

            return true

        }

    }

    return false

}



private val AcceptableClasses = arrayOf(

    Serializable::class.java,

    Parcelable::class.java,

    String::class.java,

    SparseArray::class.java,

    Binder::class.java,

    Size::class.java,

    SizeF::class.java

)

首先， SnapshotMutableState 允许被持久化，因为我们需要在 rememberSaveable 中调用 mutableStateOf；其次，SnapshotMutableState 的泛型必须是 AcceptableClasses 中的类型，我们自定义的 User 显然不符合要求，因此报了开头的错误。

SaveableStateRegistryImpl 源码分析

前面理清了几个 Registry 类型的关系，整理如下图

SaveableStateRegistry 接口的各主要方法都由 SaveableStateRegistryImpl 代理的：

• consumeRestored：根据 key 恢复数据


• registerProvider：注册 ValueProvider


• canBeSaved：用来检查数据是否是可保存类型


• performSave：执行数据保存

canBeSaved 前面介绍过，其实会回调 canBeSavedToBundle。接下来看一下 SaveableStateRegistryImpl 中其他几个方法是如何实现的：

consumeRestored

    override fun consumeRestored(key: String): Any? {

        val list = restored.remove(key)

        return if (list != null && list.isNotEmpty()) {

            if (list.size > 1) {

                restored[key] = list.subList(1, list.size)

            }

            list[0]

        } else {

            null

        }

    }

我们知道 restored 是从 Bundle 中恢复的数据，实际是一个 Map了类型。而 consumeRestored 就是在 restored 中通过 key 查找数据。restore 的 Value 是 List 类型。当恢复数据时，只保留最后一个只。顺便吐槽一下 consumeRestored 这个名字，将 restore 这个 private 成员信息暴露给了外面，有些莫名其妙。

registerProvider

    override fun registerProvider(key: String, valueProvider: () -> Any?): Entry {

        require(key.isNotBlank()) { "Registered key is empty or blank" }

        @Suppress("UNCHECKED_CAST")

        valueProviders.getOrPut(key) { mutableListOf() }.add(valueProvider)

        return object : Entry {

            override fun unregister() {

                val list = valueProviders.remove(key)

                list?.remove(valueProvider)

                if (list != null && list.isNotEmpty()) {

                    // if there are other providers for this key return list back to the map

                    valueProviders[key] = list

                }

            }

        }

    }

将 ValueProvider 注册到 valueProviders ，valueProviders 也是一个值为 List 的 Map，同一个 Key 可以对应多个 Value。返回的 Entry 用于 onDispose 中调用 unregister。

DisposableSaveableStateRegistry 是一个 CompositionLocal 单例，所以需要 unregister 避免不必要的泄露。注意这里要确保同一个 key 中的 List 中的其它值不被移除

不解：什么情况下同一个 key 会 registerProvider 多个值呢？

performSave

    override fun performSave(): Map<String, List<Any?>> {

        val map = restored.toMutableMap()

        valueProviders.forEach { (key, list) ->

            if (list.size == 1) {

                val value = list[0].invoke()

                if (value != null) {

                    check(canBeSaved(value))

                    map[key] = arrayListOf<Any?>(value)

                }

            } else {

                map[key] = List(list.size) { index ->

                    val value = list[index].invoke()

                    if (value != null) {

                        check(canBeSaved(value))

                    }

                    value

                }

            }

        }

        return map

    }

在这里调用了 ValueProvider 获取数据后存入 restored ，这里也是有针对 Value 是 List 类型的特别处理。performSave 的调用时机前面已经出现了，是 androidxRegistry 注册的 Provider 中调用：

 androidxRegistry.registerSavedStateProvider(key) {

            //调用 register#performSave 并且转为 Bundle

            saveableStateRegistry.performSave().toBundle()

        }

SavedStateProvider 会在 onSaveInstance 时被执行。

至此， rememberSaveable 持久化发生的时机与平台进行了关联。

最后回看 androidxRegistry

最后我们再回看一下 DisposableSavableStateRegistry，主要是使用 androidxRegistry 获取 key 对应的数据，并注册 key 对应的 Provider。那么 androidxRegistry 和 key 是怎么来的？

internal fun DisposableSaveableStateRegistry(

    id: String,

    savedStateRegistryOwner: SavedStateRegistryOwner

): DisposableSaveableStateRegistry {

    

    val key = "${SaveableStateRegistry::class.java.simpleName}:$id"



    val androidxRegistry = savedStateRegistryOwner.savedStateRegistry

    

    //...

    

 }

先说 key 。key 由 id 唯一决定，而这个 id 其实是 ComposeView 的 layoutId。我们知道 ComposeView 是 Activity/Fragment 承载 Composable 的容器，rememberSaveable 会按照 ComposeView 为单位来持久化数据。

因为你 ComposeView 的 id 决定了 rememberSaveable 存储数据的位置，如果 Activity/Fragment 范围内如果有多个 ComposeView 使用了同一个 id，则只有第一个 ComposeView 能正常恢复数据，这一点要特别注意

再看一下 androidxRegistry，他由 SavedStateRegistryOwner 提供，而这个 owner 是ComposeView 被 attach 到 Activity 时赋的值，就是 Activity 本身：

public class ComponentActivity extends androidx.core.app.ComponentActivity implements

        ContextAware,

        LifecycleOwner,

        ViewModelStoreOwner,

        HasDefaultViewModelProviderFactory,

        SavedStateRegistryOwner, // ComponentActivity 是一个 SavedStateRegistryOwner

        OnBackPressedDispatcherOwner,

        ActivityResultRegistryOwner,

        ActivityResultCaller {

        

    //...

    

    public final SavedStateRegistry getSavedStateRegistry() {

        return mSavedStateRegistryController.getSavedStateRegistry();

    }

    

    //...

}

mSavedStateRegistryController 会在 Activity 重建时 onCreate 中调用 performRestore；在 onSaveInstanceState 时执行 performSave。

protected void onCreate(@Nullable Bundle savedInstanceState) {

    mSavedStateRegistryController.performRestore(savedInstanceState);

    //...

}





protected void onSaveInstanceState(@NonNull Bundle outState) {

    //...

    mSavedStateRegistryController.performSave(outState);

}

mSavedStateRegistryController 最终调用到 SavedStateRegistry 的同名方法，看一下 SavedStateRegistry#performSave：

fun performSave(outBundle: Bundle) {

    //...

    val it: Iterator<Map.Entry<String, SavedStateProvider>> =

        this.components.iteratorWithAdditions()

    while (it.hasNext()) {

        val (key, value) = it.next()

        components.putBundle(key, value.saveState())

    }

    if (!components.isEmpty) {

        outBundle.putBundle(SAVED_COMPONENTS_KEY, components)

    }

}

components 是注册 SavedStateProvider 的 Map。 performSave 中调用 Provider 的 saveState 方法获取到 rememberSaveable 中保存的 bundle，然后存入 outBundle 进行持久化。

至此，rememberSaveable 在 Android 平台完成了横竖屏切换时的状态保存。

最后我们用一个图收尾，红色是保存数据时的数据流流向，绿色是恢复数据时的数据流流向：

Ktor官方对Ktor的描述是：

Create asynchronous client and server applications. Anything from microservices to multiplatform HTTP client apps in a simple way. Open Source, free, and fun!

创建异步客户端和和服务器应用，从微服务到多平台HTTP客户端应用程序都可以用一种简单的方式完成。开源、免费、有趣！

它具有轻量级+可扩展性强+多平台+异步的特性。

• 
  

  轻量级和可扩展性是因为它的内核比较简单，并且当需要一些功能的时候可以加入别的插件到项目中，并不会造成功能冗余。并且Ktor的扩展是使用插拔的方式，使用起来非常简单！

  
  


• 
  

  异步，Ktor内部是使用Kotlin协程来实现异步，这对于熟悉Kotlin的Android开发非常友好。

  
  

看到这里可能一头雾水，下面将用一个比较简单的例子来带大家入坑Ktor！等看完这篇文章之后就会对Ktor的这些特性有进一步的了解。

小例子 —— 看猫咪

引入依赖

在app模块的gradle中引入依赖

plugins { 

    ... 

    id 'org.jetbrains.kotlin.plugin.serialization' version "1.7.10" // 跟Kotlin版本一致 

}



dependencies {

    ...

    // Ktor

    def ktor_version = "2.1.0"

    implementation "io.ktor:ktor-client-core:$ktor_version"

    implementation "io.ktor:ktor-client-android:$ktor_version"

    implementation "io.ktor:ktor-client-content-negotiation:$ktor_version"

    implementation "io.ktor:ktor-serialization-kotlinx-json:$ktor_version"

}

稍微解释一下这两个依赖

1. 
   

   Ktor的客户端内核

   
   


2. 
   

   由于本APP是部署在Android上的，因此需要引入一个Android依赖，Android平台和其他平台的不同点在于Android具有主线程的概念，Android不允许在主线程发送网络请求，而在Kotlin协程中就是主调度器的概念，其内部是post任务到主线程Handler中，这里就不展开太多。当然如果要使用OkHttp也是可以的！

   
   

   implementation "io.ktor:ktor-client-okhttp:$ktor_version"
   

   
   

   如果想应用到其他客户端平台可以使用CIO

   
   


3. 
   

   第三个简单来说就是数据转换的插件，例如将远端发送来的数据（可以是CBOR、Json、Protobuf）转换成一个个数据类。

   
   


4. 
   

   而第四个就是第三个的衍生插件，相信用过kotlin-serialization的人会比较熟悉，是Kotlin序列化插件，本次引用的是json，类似于Gson，可以将json字符串转换成数据类。

   
   

当然，如果需要其他插件可以到官网上看看，例如打印日志Logging

implementation "ch.qos.logback:logback-classic:$logback_version"

implementation "io.ktor:ktor-client-logging:$ktor_version"

创建HttpClient

首先创建一个HttpClient实例

val httpClient = HttpClient(Android) {

    defaultRequest {

        url {

            protocol = URLProtocol.HTTP

            host = 你的host

            port = 你的端口

        }

    }

    install(ContentNegotiation) {

        json()

    }

}

创建的时候是使用DSL语法的，这里解释一下其中使用的两个配置

• 
  

  defaultRequest：给每个HTTP请求加上BaseUrl

  
  

  例如请求"/get-cat"就会向"http://${你的host}:${你的端口}/get-cat"发起HTTP请求。

  
  


• 
  

  ContentNegotiation：引入数据转换插件。

  
  


• 
  

  json：引入自动将json转换数据类的插件。

  
  

定义数据类

@Serializable

data class Cat(

    val name: String,

    val description: String,

    val imageUrl: String

)

此处给猫咪定义名字、描述和图片url，需要注意的是需要加上@Serializable注解，这是使用kotlin-serialization的前提条件，而需要正常使用kotlin-serialization，需要在app模块的build.gradle加上以下plugin

plugins {

    ...

    id 'org.jetbrains.kotlin.plugin.serialization' version "1.7.10" // 跟Kotlin版本一致

}

创建API

interface CatSource {



    suspend fun getRandomCat(): Result<Cat>



    companion object {

        val instance = CatSourceImpl(httpClient)

    }

}



class CatSourceImpl(

    private val client: HttpClient

) : CatSource {



    override suspend fun getRandomCat(): Result<Cat> = runCatching {

        client.get("random-cat").body()

    }



}