相信稍微接触过Kotlin的同学都知道Kotlin Coroutine(协程）的大名，甚至有些同学认为重要到"无协程，不Kotlin"的地步，吓得我赶紧去翻阅了协程源码，同时也学习了不少博客，博客里比较典型的几个说法：

• 协程是轻量级线程、比线程耗费资源少


• 协程是线程框架


• 协程效率高于线程


• ...

一堆术语听起来是不是很高端的样子？这些表述正确吗？妥当吗？你说我学了大半天，虽然我也会用，但还是没弄懂啥是协程...

为了彻底弄懂啥是协程，需要将进程、线程拉进来一起pk。

通过本篇文章，你将了解到：

1、程序、进程、CPU、内存关系

2、进程与线程的故事

3、线程与Kotlin协程的故事

4、Kotlin 协程的使命

1、程序、进程、CPU、内存关系

如上图，平时我们打包好一个应用，放在磁盘上，此时我们称之为程序或者应用，是静态的。也就是咱们平常说的：我下载个程序，你传给apk给我，它们都是程序(应用)。

当我们执行程序(比如点击某个App)，OS 会将它加载进内存，CPU 从内存某个起始地址开始读取指令并执行程序。

程序从磁盘上加载到内存并被CPU运行期间，称之为进程。因此我们通常说某个应用是否还在存活，实际上说的是进程是否还在内存里；也会说某某程序CPU占用率太高，实际上说的是进程的CPU占用率。

而操作系统负责管理磁盘、内存、CPU等交互，可以说是大管家。

2、进程与线程的故事

接下来我们以一个故事说起。

上古时代的合作

在上古时候，一个设备里只有一个CPU，能力比较弱，单位时间内能够处理的任务量有限，内存比较小，能加载的应用不多，相应的那会儿编写的程序功能单一，结构简单。

OS 说："大家都知道，我们的情况比较具体，只有一个CPU，内存也很小，而现在有不少应用想要占用CPU和内存，无规矩不成方圆，我现在定下个规矩："

每个应用加载到内存后，我将给他安排内存里的一块独立的空间，并记录它的一些必要信息，最后规整为一个叫进程的东西，就是代表你这个应用的所有信息，以后我就只管调度进程即可。

并且进程之间的内存空间是隔离的，无法轻易访问，特殊情况需要经过我的允许。

应用(程序)说："哦，我知道了，意思就是：进程是资源分派的基本单位嘛"

OS 说："对的，悟性真好，小伙子。"

规矩定下了，大家就开始干活了：

1、应用被加载到内存后，OS分派了一些资源给它。

2、CPU 从内存里逐一取出并执行进程。

3、其它没有得到CPU青睐的进程则静候等待，等待被翻牌。

中古时代的合作

一切都有条不紊的进行着，大家配合默契，其乐融融，直到有一天，OS 发现了一些端倪。

他发现CPU 在偷懒...找到CPU，压抑心中的愤怒说到：

"我发现你最近不是很忙哎，是不是工作量不饱和？"

CPU 忙不迭说到："冤枉啊，我确实不是很忙，但这不怪我啊。你也知道我最近升级了频率，处理速度快了很多，进程每次给我的任务我都快速执行完了，不过它们却一直占用我，不让我处理其它进程的，我也是没办法啊。"

OS 大吃一惊到："大胆进程，居然占着茅坑不拉屎！"

CPU 小声到："我又不是茅坑..."

OS 找来进程劈头盖脸训斥一道："进程你好大的胆，我之前不是给你说请CPU 做事情要讲究一个原则：按需占有，用完就退。你把我话当耳边风了？"

进程直呼："此事与我无关啊，你知道的我最讲原则了，你之前说过对CPU 的使用：应占尽占。我现在不仅要处理本地逻辑，还要从磁盘读取文件，这个时候我虽然不占用CPU，但是我后面文件读结束还是需要他。"

OS 眉头紧皱，略微思索了一下对进程和CPU道："此事前因后果均已知悉，容我斟酌几日。"

几天后，OS 过来对他俩说："我现在重新拟定一个规则：进程不能一直占用CPU到任务结束为止，需要规定占用的时间片，在规定的时间片内进程能完成多少是多少，时间一到立即退出CPU换另一个进程上，没能完成任务的进程等下个轮到自己的时间片再上"

进程和CPU 对视一眼，立即附和："谨遵钧令，使命必达！"

近现代的合作

自从实行新规定以来，进程们都有机会抢占CPU了，算是雨露均沾，很少出现某进程长期霸占CPU的现象了，OS 对此很是满意。

一则来自进程的举报打破这黎明前的宁静。

OS 收到一则举报："我进程实名举报CPU 偷懒。"

OS 心里咯噔一跳，寻思着咋又是CPU，于是叫来CPU 对簿公堂。

CPU 听到OS 召唤，暗叫不妙，心里立马准备了一套说辞。

OS 对着CPU 和 进程说："进程说你偷懒，你在服务进程的时间片内无所事事，我希望你能给我一个满意的答复。"

CPU 一听这话，心里一阵鄙视，果不出我所料，就知道你问这事。虽然心里诽腹不已，脸上却是郑重其事道："这事是因为进程交给我的任务很快完成了，它去忙别的事了，让我等等他。"

OS 诧异道："你这么快就将进程的任务处理完成了？"

CPU 面露得以之色道："你知道的我一直追求进步，这不前阵子又升级了一下嘛，处理能力又提升了。如果说优秀是一种原罪的话，那这个罪名由我承担吧，再如果..."

OS 看了进程一眼，对CPU 说："行行行，打住，此事确实与你无关。进程虽然你误会了CPU，但是你提出的问题确实是一个好的思考点，这个下来我想个方案，回头咱们评审一下。"

一个月后，OS 将进程和CPU召集起来，并拿出方案说："我们这次将进行一次大的调整，鉴于CPU 处理能力提升，他想要承担更多的工作，而目前以进程为单位提交任务颗粒度太大了，需要再细化。我建议将进程划分为若干线程，这些线程共享进程的资源池，进程想要执行某任务直接交给线程即可，而CPU每次以线程为单位执行。接下来，你们说说各自的意见吧。"

进程说到："这个方案很优秀，相当于我可以弄出分身，让各个分身干各项任务，处理UI一个线程，处理I/O是另一个线程，处理其它任务是其它线程，我只需要分派各个任务给线程，剩下的无需我操心了。CPU 你觉得呢？"

CPU 心底暗道："你自己倒是简单，只管造分身，脏活累活都是我干..."

表面故作沉重说到："这个改动有点大，我现在需要直接对接线程，这块需要下来好好研究一下，不过问题不大。"

进程补充道："CPU 你可以要记清楚了，以后线程是CPU 调度的基本单位了。"

CPU 应道："好的，好的，了解了(还用你复述OS 的话嘛...)。"

规矩定下了，大家热火朝天地干活。

进程至少有一个线程在运行，其余按需制造线程，多个线程共用进程资源，每个线程都被CPU 执行。

新时代的合作

OS 照例视察各个模块的合作，这天进程又向它抱怨了："我最近各个线程的数据总是对不上，是不是内存出现了差错？"

OS 愣了一下，说到："这问题我知道了，还没来得及和你说呢。最近咱们多放了几个CPU 模块提升设备的整体性能，你的线程可能在不同的CPU上运行，因此拿到的数据有点问题。"

进程若有所思道："以前只有一个CPU，各个进程看似同时运行，实则分享CPU时间片，是并发行为。现在CPU 多了，不同的线程有机会同时运行，这就是真并行了吧。"

OS 道："举一反三能力不错哦，不管并行还是并发，多个线程共享的数据有可能不一致，尤其加入了多CPU后，现象比较明显，这就是多线程数据安全问题。底层已经提供了一些基本的机制，比如CPU的MESI，但还是无法完全解决这问题，剩下的交给上层吧。"

进程道："了解了，那我告诉各个线程，如果他们有共享数据的需求，自己协商解决一下。"

进程告知线程自己处理线程安全问题，线程答到："我只是个工具人，谁用谁负责处理就好。"

一众编程语言答到："我自己来处理吧。"

多CPU 如下，每个线程都有可能被其它CPU运行。

3、线程与Kotlin协程的故事

Java 线程调用

底层一众大佬已经将坑踩得差不多了，这时候得各个编程语言出场了。

C 语言作为骨灰级人物远近闻名，OS、驱动等都是由他编写，这无需介绍了。

之后如雨后春笋般又冒出了许多优秀的语言，如C++、Java、C#、Qt 等，本小结的主人公：Java。

Java 从小目标远大，想要跨平台运行，借助于JVM他可以实现这个梦想，每个JVM 实例对应一个进程，并且OS 还给了他操作线程的权限。

Java 想既然大佬这么支持，那我要撸起袖子加油干了，刚好在Android 上接到一个需求：

通过学生的id，向后台(联网)查询学生的基本信息，如姓名、年龄等。

Java 心想："这还不简单，且看我猛如虎的操作。"

先定义学生Bean类型：

public class StudentInfo {

    //学生id

    private long stuId = 999;

    private String name = "fish";

    private int age = 18;

}

再定义一个获取的动作：

    //从后台获取信息

    public StudentInfo getWithoutThread(long stuId) {

        try {

            //模拟耗时操作

            Thread.sleep(2000);

        } catch (InterruptedException e) {

            e.printStackTrace();

        }

        return new StudentInfo(); 

    }

信心满满地运行，却被现实无情打脸，只见控制台显目的红色：

不能在主线程进行网络请求。

同步调用

Java 并不气馁，这问题简单，我开个线程取获取不就得了?

    Callable<StudentInfo> callable = new Callable<StudentInfo>() {

        @Override

        public StudentInfo call() throws Exception {

            try {

                //模拟耗时操作

                Thread.sleep(2000);

            } catch (InterruptedException e) {

                e.printStackTrace();

            }

            return new StudentInfo();

        }

    };



    public StudentInfo getStuInfo(long stuId) {

        //定义任务

        FutureTask<StudentInfo> futureTask = new FutureTask<>(callable);

        //开启线程，执行任务

        new Thread(futureTask).start();

        try {

            //阻塞获取结果

            StudentInfo studentInfo = futureTask.get();

            return studentInfo;

        } catch (ExecutionException e) {

            e.printStackTrace();

        } catch (InterruptedException e) {

            e.printStackTrace();

        }

        return null;

    }

而后，再在界面上弹出学生姓名：

 JavaStudent javaStudent = new JavaStudent();

        StudentInfo studentInfo = javaStudent.getWithoutThread(999);

        Toast.makeText(this, "学生姓名:" + studentInfo.getName(), Toast.LENGTH_LONG).show();

刚开始能弹出Toast，然而后面动不动UI就卡顿，甚至出现ANR 弹窗。

Java 百思不得其解，后得到Android 本尊指点：

Android 主线程不能进行耗时操作。

Java 说到："我就简单获取个信息，咋这么多限制..."

Android 答到："Android 通常需要在主线程更新UI，主线程不能做过多耗时操作，否则影响UI 渲染流畅度。不仅是Android，你Java 本身的主线程(main线程)通常也不会做耗时啊，都是通过开启各个线程去完成任务，要不然每一步都要主线程等待，那主线程的其它关键任务就没法开启了。"

Java 沉思道："有道理，容我三思。"

异步调用与回调

Java 果不愧是编程语言界的老手，闭关几天就想出了方案，直接show us code：

    //回调接口

    public interface Callback {

        void onCallback(StudentInfo studentInfo);

    }



    //异步调用

    public void getStuInfoAsync(long stuId, Callback callback) {

        new Thread(() -> {

            try {

                //模拟耗时操作

                Thread.sleep(2000);

            } catch (InterruptedException e) {

                e.printStackTrace();

            }



            StudentInfo studentInfo = new StudentInfo();

            if (callback != null) {

                //回调给调用者

                callback.onCallback(studentInfo);

            }

        }).start();

    }

在调用耗时方法时，只需要将自己的凭证(回调对象)传给方法即可，调用者不管方法里具体是咋实现的，才不管你开几个线程呢，反正你有结果通过回调给我。

调用者只需要在需要的地方实现回调接收即可：

        JavaStudent javaStudent = new JavaStudent();

        javaStudent.getStuInfoAsync(999, new JavaStudent.Callback() {

            @Override

            public void onCallback(StudentInfo studentInfo) {

                //异步调用，回调从子线程返回，需要切换到主线程更新UI

                runOnUiThread(() -> {

                    Toast.makeText(TestJavaActivity.this, "学生姓名:" + studentInfo.getName(), Toast.LENGTH_LONG).show();

                });

            }

        });

异步调用的好处显而易见：

1、不用阻塞调用者，调用者可继续做其它事情。

2、线程没有被阻塞，相比同步调用效率更高。

缺点也是比较明显：

1、没有同步调用直观。

2、容易陷入多层回调，不利于阅读与调试。

3、从内到外的异常处理缺失传递性。

Kotlin 协程毛遂自荐

Java 靠着左手同步调用、右手异步调用的左右互搏技能，成功实现了很多项目，虽然异步调用有着一些缺点，但瑕不掩瑜。

这天，Java 又收到需求变更了：

通过学生id，获取学生信息，通过学生信息，获取他的语文老师id，通过语文老师id，获取老师姓名，最后更新UI。

Java 不假思索到："简单，我再嵌套一层回调即可。"

    //回调接口

    public interface Callback {

        void onCallback(StudentInfo studentInfo);

        //新增老师回调接口

        default void onCallback(TeacherInfo teacherInfo){}

    }



    //异步调用

    public void getTeachInfoAsync(long stuId, Callback callback) {

        //先获取学生信息

        getStuInfoAsync(stuId, new Callback() {

            @Override

            public void onCallback(StudentInfo studentInfo) {

                //获取学生信息后，取出关联的语文老师id，获取老师信息

                new Thread(() -> {

                    try {

                        //模拟耗时操作

                        Thread.sleep(2000);

                    } catch (InterruptedException e) {

                        e.printStackTrace();

                    }

                    

                    TeacherInfo teacherInfo = new TeacherInfo();

                    if (callback != null) {

                        //老师信息获取成功

                        callback.onCallback(teacherInfo);

                    }

                }).start();

            }

        });

    }

眼看Java 一下子实现了功能，Android再提需求：

通过老师id，获取他所在的教研组信息，再通过教研组id获取教研组排名...

Java 抗议道："哪有这么奇葩的需求，那我不是要无限回调吗，我可以实现，但不好维护，过几天我自己看都看不懂了。"

Android："不就是几个回调的问题嘛，亏你还是老员工，实在不行，我找其他人。"

Java："...我再想想。"

正当Java 一筹莫展之际，吃饭时刚好碰到了Kotlin，Java 难得有时间和这位新入职的小伙伴聊聊天，发发牢骚。

Kotlin 听了Java 的遭遇，表达了同情并劝说Java 赶紧离职，Android 这块不适合他。

Kotlin 随后找到Android，略微紧张地说："吾有一计，可安天下。"

Android 对于毛遂自荐的人才是非常欢迎的，问曰："计将安出"

Kotlin 随后激动到：协程。

Android 诧异道："协程，旅游？"

class StudentCoroutine {

    private val FIXED_TEACHER_ID = 888

    fun getTeachInfo(act: Activity, stuId: Long) {

        GlobalScope.launch(Dispatchers.Main) {



            var studentInfo: StudentInfo

            var teacherInfo: TeacherInfo? = null



            //先获取学生信息

            withContext(Dispatchers.IO) {

                //模拟网络获取

                Thread.sleep(2000)

                studentInfo = StudentInfo()

            }

            //再获取教师信息

            withContext(Dispatchers.IO) {

                if (studentInfo.lanTechId.toInt() === FIXED_TEACHER_ID) {

                    //模拟网络获取

                    Thread.sleep(2000)

                    teacherInfo = TeacherInfo()

                }

            }

            //更新UI

            Toast.makeText(act, "teacher name:${teacherInfo?.name}", Toast.LENGTH_LONG).show()

        }

        Toast.makeText(act, "主线程还在跑...", Toast.LENGTH_LONG).show()

    }

}

外部调用：

    var student = StudentCoroutine()

    student.getTeachInfo(this@MainActivity, 999)

Android 一看，大吃一惊："想不到，语言界竟然有如此厚颜无耻之...不对，如此简洁的写法。"

Kotlin 道："协程这概念早就有了，其它兄弟语言Python、Go等也实现了，我也是站在巨人的肩膀上，秉着解决用户痛点的思路来设计的。"

Android 随即大手一挥道："就冲着你这简洁的语法，今后Android 业务你来搞吧，希望你能够担起重担。"

Kotlin 立马道："没问题，我本身也是跨平台的，只是Java 那边...。"

Android："这个你无需顾虑，Java 的工作我来做，成年人应该知道这世界是残酷的。"

Java 听到Kotlin 逐渐蚕食了自己在Android上的业务，略微生气，于是看了Kotlin 的写法，最后长舒一口气："确实比较简洁，看起来功能阻塞了主线程，实际并没有。其实就是 用同步的写法，表达异步的调用。"

Koltin ："知我者，老大哥Java 也。"

4、Kotlin 协程的使命

通过与Java 的比对，大家也知道了协程最大的特色：

将异步编程同步化。

当然还有一些特点，如异常处理、协程取消等。

再回过头来看看上面的疑问。

1、协程是轻量级线程、比线程耗费资源少
这话虽然是官方说的，但我觉得有点误导的作用，协程是语言层面的东西，线程是系统层面的东西，两者没有可比性。

协程就是一段代码块，既然是代码那就离不开CPU的执行，而CPU调度的基本单位是线程。

2、协程是线程框架
协程解决了移步编程时过多回调的问题，既然是异步编程，那势必涉及到不同的线程。Kotlin 协程内部自己维护了线程池，与Java 线程池相比有些优化的地方。在使用协程过程中，无需关注线程的切换细节，只需指定想要执行的线程即可，从对线程的封装这方面来说这说话也没问题。

3、协程效率高于线程
与第一点类似，协程在运行方面的高效率其实换成回调方式也是能够达成同样的效果，实际上协程内部也是通过回调实现的，只是在编译阶段封装了回调的细节而已。因此，协程与线程没有可比性。

阅读完上述内容，想必大家都知道进程、线程、协程的关系了，也许大家还很好奇协程是怎么做到不阻塞调用者线程的？它又是怎么在获取结果后回到原来的位置继续执行呢？线程之间如何做到丝滑般切换的？

不要着急，这些点我们一点点探秘，下篇文章开始徒手开启一个协程，并分析其原理。

Kotlin 源码阅读需要一定的Kotlin 基础，尤其是高阶函数，若是这方面还不太懂的同学可以查阅之前的文章：Kotlin 高阶函数从未如此清晰 系列

本文基于Kotlin 1.5.3，文中完整Demo请点击

废话不多说，先上效果图：

该效果其实由三部分组成：

• 渐变


• 圆角


• 文本

渐变

关于渐变，估计大家都不会陌生，以往都是使用gradient进行制作：

shape_gradient.xml

<?xml version="1.0" encoding="utf-8"?>

<shape xmlns:android="http://schemas.android.com/apk/res/android">

    <gradient

        android:startColor="#B620E0"

        android:endColor="#E38746" />

</shape>

    <View

        android:layout_width="match_parent"

        android:layout_height="70dp"

        android:background="@drawable/shape_gradient" />

但是，这个只能支持双色渐变，超过双色就无能为力了，所以，我们要考虑使用其它方式：

    /**

     * Create a shader that draws a linear gradient along a line.

     *

     * @param x0           The x-coordinate for the start of the gradient line

     * @param y0           The y-coordinate for the start of the gradient line

     * @param x1           The x-coordinate for the end of the gradient line

     * @param y1           The y-coordinate for the end of the gradient line

     * @param colors       The colors to be distributed along the gradient line

     * @param positions    May be null. The relative positions [0..1] of

     *                     each corresponding color in the colors array. If this is null,

     *                     the the colors are distributed evenly along the gradient line.

     * @param tile         The Shader tiling mode

    */

    public LinearGradient(float x0, float y0, float x1, float y1, @NonNull @ColorInt int colors[],

            @Nullable float positions[], @NonNull TileMode tile)

    /**

     * x0、y0、x1、y1为决定渐变颜色方向的两个坐标点，x0、y0为起始坐标，x1、y1为终点坐标

     * @param colors       所有渐变颜色的数组，即放多少个颜色进去，就有多少种渐变颜色

     * @param positions    渐变颜色的比值，默认为均匀分布。

     * 把总长度理解为1，假如里面的值为[0.3，0.2，0.5]，那么，渐变的颜色就会以 0.3 : 0:2 :0.5 比例进行排版

     * @param tile         着色器模式

    */

public LinearGradient(float x0, float y0, float x1, float y1, int colors[], float positions[],

           TileMode tile) 

创建自定义View

public class ColorView extends View {

    public ColorView(Context context) {

        super(context);

    }



    public ColorView(Context context, @Nullable AttributeSet attrs) {

        super(context, attrs);

    }



    public ColorView(Context context, @Nullable AttributeSet attrs, int defStyleAttr) {

        super(context, attrs, defStyleAttr);

    }



    @Override

    protected void onDraw(Canvas canvas) {

        super.onDraw(canvas);

        //获取宽高

        int width = getWidth();

        int height = getHeight();



        //渐变的颜色

        int colorStart = Color.parseColor("#E38746");

        int color1 = Color.parseColor("#B620E0");

        int colorEnd = Color.parseColor("#5995F6");

        //绘画渐变效果

        Paint paintColor = new Paint();

        LinearGradient backGradient = new LinearGradient(0, height, width, 0, new int[]{colorStart, color1, colorEnd}, null, Shader.TileMode.CLAMP);

        paintColor.setShader(backGradient);

        canvas.drawRect(0, 0, width, height, paintColor);

    }

}

    <com.jm.xpproject.ColorView

        android:layout_width="match_parent"

        android:layout_height="70dp" />

效果：

圆角

关于圆角，我们需要使用到BitmapShader，使用方式：

        BitmapShader bitmapShaderColor = new BitmapShader(bitmapColor, Shader.TileMode.CLAMP, Shader.TileMode.CLAMP);

        // 初始化画笔

        Paint paintFillet = new Paint();

        paintFillet.setAntiAlias(true);

        paintFillet.setShader(bitmapShaderColor);

        //绘画到画布中

        canvas.drawRoundRect(new RectF(0, 0, width, height), radius, radius, paintFillet);

由于这里的BitmapShader是对于Bitmap进行操作的，所以，对于渐变效果，我们不能直接把他绘画到原始画布上，而是生成一个Bitmap，将渐变绘画记录下来：

还是刚刚的自定义View

    @Override

    protected void onDraw(Canvas canvas) {

        super.onDraw(canvas);

        //获取View的宽高

        int width = getWidth();

        int height = getHeight();



        //第一步，绘画出一个渐变效果的Bitmap

        //创建存放渐变效果的bitmap

        Bitmap bitmapColor = Bitmap.createBitmap(width, height, Bitmap.Config.ARGB_8888);

        Canvas canvasColor = new Canvas(bitmapColor);

        //渐变的颜色

        int colorStart = Color.parseColor("#E38746");

        int color1 = Color.parseColor("#B620E0");

        int colorEnd = Color.parseColor("#5995F6");

        //绘画渐变效果

        Paint paintColor = new Paint();

        LinearGradient backGradient = new LinearGradient(0, height, width, 0, new int[]{colorStart, color1, colorEnd}, null, Shader.TileMode.CLAMP);

        paintColor.setShader(backGradient);

        canvasColor.drawRect(0, 0, width, height, paintColor);

        //第二步，绘画出一个圆角渐变效果

        //绘画出圆角渐变效果

        BitmapShader bitmapShaderColor = new BitmapShader(bitmapColor, Shader.TileMode.CLAMP, Shader.TileMode.CLAMP);

        // 初始化画笔

        Paint paintFillet = new Paint();

        paintFillet.setAntiAlias(true);

        paintFillet.setShader(bitmapShaderColor);

        //绘画到画布中

        canvas.drawRoundRect(new RectF(0, 0, width, height), 100, 100, paintFillet);

    }

效果：

至于中间的空白部分，其实我们依葫芦画瓢，再画上一个白色的圆角Bitmap即可：

        //创建存放白底的bitmap

        Bitmap bitmapWhite = Bitmap.createBitmap(width - colorWidth * 2, height - colorWidth * 2, Bitmap.Config.RGB_565);

        bitmapWhite.eraseColor(Color.parseColor("#FFFFFF"));



        BitmapShader bitmapShaderWhite = new BitmapShader(bitmapWhite, Shader.TileMode.CLAMP, Shader.TileMode.CLAMP);

        // 初始化画笔

        Paint paintWhite = new Paint();

        paintWhite.setAntiAlias(true);

        paintWhite.setShader(bitmapShaderWhite);

        // 将白色Bitmap绘制到画布上面

        canvas.drawRoundRect(new RectF(colorWidth, colorWidth, width - colorWidth, height - colorWidth), radius, radius, paintWhite);

总体代码：

    @Override

    protected void onDraw(Canvas canvas) {

        super.onDraw(canvas);

        //获取View的宽高

        int width = getWidth();

        int height = getHeight();



        //第一步，绘画出一个渐变效果的Bitmap

        //创建存放渐变效果的bitmap

        Bitmap bitmapColor = Bitmap.createBitmap(width, height, Bitmap.Config.ARGB_8888);

        Canvas canvasColor = new Canvas(bitmapColor);

        //渐变的颜色

        int colorStart = Color.parseColor("#E38746");

        int color1 = Color.parseColor("#B620E0");

        int colorEnd = Color.parseColor("#5995F6");

        //绘画渐变效果

        Paint paintColor = new Paint();

        LinearGradient backGradient = new LinearGradient(0, height, width, 0, new int[]{colorStart, color1, colorEnd}, null, Shader.TileMode.CLAMP);

        paintColor.setShader(backGradient);

        canvasColor.drawRect(0, 0, width, height, paintColor);

        //第二步，绘画出一个圆角渐变效果

        //绘画出圆角渐变效果

        BitmapShader bitmapShaderColor = new BitmapShader(bitmapColor, Shader.TileMode.CLAMP, Shader.TileMode.CLAMP);

        // 初始化画笔

        Paint paintFillet = new Paint();

        paintFillet.setAntiAlias(true);

        paintFillet.setShader(bitmapShaderColor);

        //绘画到画布中

        canvas.drawRoundRect(new RectF(0, 0, width, height), 100, 100, paintFillet);



        //第三步，绘画出一个白色的bitmap覆盖上去

        //创建存放白底的bitmap

        Bitmap bitmapWhite = Bitmap.createBitmap(width - 5 * 2, height - 5 * 2, Bitmap.Config.RGB_565);

        bitmapWhite.eraseColor(Color.parseColor("#FFFFFF"));



        BitmapShader bitmapShaderWhite = new BitmapShader(bitmapWhite, Shader.TileMode.CLAMP, Shader.TileMode.CLAMP);

        // 初始化画笔

        Paint paintWhite = new Paint();

        paintWhite.setAntiAlias(true);

        paintWhite.setShader(bitmapShaderWhite);

        // 将白色Bitmap绘制到画布上面

        canvas.drawRoundRect(new RectF(5, 5, width - 5, height - 5), 100, 100, paintWhite);

    }

效果：

文本

像文本就简单了，使用drawText即可，只要注意在绘画的时候，要对文本进行居中显示，因为 Android 默认绘画文本，是从左下角进行绘画的，就像这样：

        Paint paintText = new Paint();

        paintText.setAntiAlias(true);

        paintText.setColor(Color.parseColor("#000000"));

        paintText.setTextSize(100);

        canvas.drawText("收藏", width / 2, height / 2, paintText);

        canvas.drawLine(width / 2, 0, width / 2, height, paintText);

        canvas.drawLine(0, height / 2, width, height / 2, paintText);

正确做法：

        String text = "收藏";

        Rect rect = new Rect();

        Paint paintText = new Paint();

        paintText.setAntiAlias(true);

        paintText.setColor(Color.parseColor("#000000"));

        paintText.setTextSize(100);

        paintText.getTextBounds(text, 0, text.length(), rect);

        int widthFont = rect.width();//文本的宽度

        int heightFont = rect.height();//文本的高度

        canvas.drawText(text, (width - widthFont) / 2, (height+heightFont) / 2, paintText);

至此，基本功能的制作就完成了

    @Override

    protected void onDraw(Canvas canvas) {

        super.onDraw(canvas);

        //获取View的宽高

        int width = getWidth();

        int height = getHeight();



        //第一步，绘画出一个渐变效果的Bitmap

        //创建存放渐变效果的bitmap

        Bitmap bitmapColor = Bitmap.createBitmap(width, height, Bitmap.Config.ARGB_8888);

        Canvas canvasColor = new Canvas(bitmapColor);

        //渐变的颜色

        int colorStart = Color.parseColor("#E38746");

        int color1 = Color.parseColor("#B620E0");

        int colorEnd = Color.parseColor("#5995F6");

        //绘画渐变效果

        Paint paintColor = new Paint();

        LinearGradient backGradient = new LinearGradient(0, height, width, 0, new int[]{colorStart, color1, colorEnd}, null, Shader.TileMode.CLAMP);

        paintColor.setShader(backGradient);

        canvasColor.drawRect(0, 0, width, height, paintColor);

        //第二步，绘画出一个圆角渐变效果

        //绘画出圆角渐变效果

        BitmapShader bitmapShaderColor = new BitmapShader(bitmapColor, Shader.TileMode.CLAMP, Shader.TileMode.CLAMP);

        // 初始化画笔

        Paint paintFillet = new Paint();

        paintFillet.setAntiAlias(true);

        paintFillet.setShader(bitmapShaderColor);

        //绘画到画布中

        canvas.drawRoundRect(new RectF(0, 0, width, height), 100, 100, paintFillet);



        //第三步，绘画出一个白色的bitmap覆盖上去

        //创建存放白底的bitmap

        Bitmap bitmapWhite = Bitmap.createBitmap(width - 5 * 2, height - 5 * 2, Bitmap.Config.RGB_565);

        bitmapWhite.eraseColor(Color.parseColor("#FFFFFF"));



        BitmapShader bitmapShaderWhite = new BitmapShader(bitmapWhite, Shader.TileMode.CLAMP, Shader.TileMode.CLAMP);

        // 初始化画笔

        Paint paintWhite = new Paint();

        paintWhite.setAntiAlias(true);

        paintWhite.setShader(bitmapShaderWhite);

        // 将白色Bitmap绘制到画布上面

        canvas.drawRoundRect(new RectF(5, 5, width - 5, height - 5), 100, 100, paintWhite);



        String text = "收藏";

        Rect rect = new Rect();

        Paint paintText = new Paint();

        paintText.setAntiAlias(true);

        paintText.setColor(Color.parseColor("#000000"));

        paintText.setTextSize(100);

        paintText.getTextBounds(text, 0, text.length(), rect);

        int widthFont = rect.width();//文本的宽度

        int heightFont = rect.height();//文本的高度

        canvas.drawText(text, (width - widthFont) / 2, (height+heightFont) / 2, paintText);

    }

封装

上面虽然已经把全部功能都讲解完了，但是，假如就直接这样放入项目中，是极其不规范的，无法动态设置文本、文本大小、颜色厚度等等

这里，我进行了简易封装，大家可以基于此进行业务修改：

attrs.xml

    <declare-styleable name="GradientColorButton">

        <attr name="btnText" format="string" />

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

        <attr name="btnTextColor" format="color" />

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

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

    </declare-styleable>

public class GradientColorButton extends View {



    /**

     * 文本

     */

    private String text = "";

    /**

     * 文本颜色

     */

    private int textColor;

    /**

     * 文本大小

     */

    private float textSize;

    /**

     * 颜色的宽度

     */

    private float colorWidth;

    /**

     * 圆角度数

     */

    private float radius;



    //渐变的颜色

    private int colorStart = Color.parseColor("#E38746");

    private int color1 = Color.parseColor("#B620E0");

    private int colorEnd = Color.parseColor("#5995F6");



    //控件的宽高

    private int width;

    private int height;

    /**

     * 渐变颜色的Bitmap

     */

    private Bitmap bitmapColor;



    //画笔

    private Paint paintColor;

    private Paint paintFillet;

    private Paint paintWhite;

    private Paint paintText;

    //字体的宽高

    private int widthFont;

    private int heightFont;



    public GradientColorButton(Context context) {

        super(context);

    }



    public GradientColorButton(Context context, @Nullable AttributeSet attrs) {

        this(context, attrs, 0);

    }



    public GradientColorButton(Context context, @Nullable AttributeSet attrs, int defStyleAttr) {

        super(context, attrs, defStyleAttr);



        //获取参数

        TypedArray a = context.obtainStyledAttributes(attrs,

                R.styleable.GradientColorButton, defStyleAttr, 0);



        text = a.getString(R.styleable.GradientColorButton_btnText);

        textColor = a.getColor(R.styleable.GradientColorButton_btnTextColor, Color.BLACK);

        textSize = a.getDimension(R.styleable.GradientColorButton_btnTextSize, 16);

        colorWidth = a.getDimension(R.styleable.GradientColorButton_colorWidth, 5);

        radius = a.getDimension(R.styleable.GradientColorButton_colorRadius, 100);





    }



    @Override

    protected void onLayout(boolean changed, int left, int top, int right, int bottom) {

        super.onLayout(changed, left, top, right, bottom);



        //获取View的宽高

        width = getWidth();

        height = getHeight();



        //制作一个渐变效果的Bitmap

        createGradientBitmap();



        //初始化圆角配置

        initFilletConfiguration();



        //初始化白色Bitmap配置

        initWhiteBitmapConfiguration();



        //初始化文本配置

        initTextConfiguration();



    }





    /**

     * 创建渐变颜色的Bitmap

     */

    private void createGradientBitmap() {

        //创建存放渐变效果的bitmap

        bitmapColor = Bitmap.createBitmap(width, height, Bitmap.Config.ARGB_8888);

        Canvas canvasColor = new Canvas(bitmapColor);

        LinearGradient backGradient = new LinearGradient(0, height, width, 0, new int[]{colorStart, color1, colorEnd}, null, Shader.TileMode.CLAMP);

        //绘画渐变效果

        paintColor = new Paint();

        paintColor.setShader(backGradient);

        canvasColor.drawRect(0, 0, width, height, paintColor);

    }





    /**

     * 初始化圆角配置

     */

    private void initFilletConfiguration() {

        //绘画出圆角渐变效果

        BitmapShader bitmapShaderColor = new BitmapShader(bitmapColor, Shader.TileMode.CLAMP, Shader.TileMode.CLAMP);

        // 初始化画笔

        paintFillet = new Paint();

        paintFillet.setAntiAlias(true);

        paintFillet.setShader(bitmapShaderColor);

    }



    /**

     * 初始化白色Bitmap配置

     */

    private void initWhiteBitmapConfiguration() {

        //创建存放白底的bitmap

        Bitmap bitmapWhite = Bitmap.createBitmap((int) (width - colorWidth * 2), (int) (height - colorWidth * 2), Bitmap.Config.RGB_565);

        bitmapWhite.eraseColor(Color.parseColor("#FFFFFF"));



        BitmapShader bitmapShaderWhite = new BitmapShader(bitmapWhite, Shader.TileMode.CLAMP, Shader.TileMode.CLAMP);

        // 初始化画笔

        paintWhite = new Paint();

        paintWhite.setAntiAlias(true);

        paintWhite.setShader(bitmapShaderWhite);

    }



    /**

     * 初始化文本配置

     */

    private void initTextConfiguration() {

        Rect rect = new Rect();

        paintText = new Paint();

        paintText.setAntiAlias(true);

        paintText.setColor(textColor);

        paintText.setTextSize(textSize);

        if (!TextUtils.isEmpty(text)) {

            paintText.getTextBounds(text, 0, text.length(), rect);

            widthFont = rect.width();//文本的宽度

            heightFont = rect.height();//文本的高度



        }

    }





    @Override

    protected void onDraw(Canvas canvas) {

        super.onDraw(canvas);



        //将圆角渐变bitmap绘画到画布中

        canvas.drawRoundRect(new RectF(0, 0, width, height), radius, radius, paintFillet);

        // 将白色Bitmap绘制到画布上面

        canvas.drawRoundRect(new RectF(colorWidth, colorWidth, width - colorWidth, height - colorWidth), radius, radius, paintWhite);





        if (!TextUtils.isEmpty(text)) {

            canvas.drawText(text, (width - widthFont) / 2, (height + heightFont) / 2, paintText);

        }



    }

}

    <com.jm.xpproject.GradientColorButton

        android:layout_width="120dp"

        android:layout_height="70dp"

        android:layout_margin="10dp"

        app:btnText="收藏"

        app:btnTextColor="#123456"

        app:btnTextSize="18sp"

        app:colorRadius="50dp"

        app:colorWidth="5dp" />

这个问题是我最近做业务开发和业余开发都遇到的，这里的 angle 指的是旋转弧度。不是旋转角度。

先看一下我使用 angle 的场景吧：

图一中使用了 canvas.drawArc，传入了 startAngle 和 sweepAngle。图二也是如此。图三是 Flutter ConstraintLayout 中圆形定位的 example，我没有使用 Flutter ConstraintLayout 自带的旋转能力，而是用了 Transform.rotate，传入了 angle。Flutter ConstraintLayout 自带的对 Widget 的旋转能力用了 canvas.rotate，也传入了 angle。

我现在还没搞明白弧度和角度的对应关系，官网文档中也没有详细说明。但对于我来说，我根本就不想去关心弧度是多少，我只关心角度，这个角度的范围是 [0.0, 360.0]。以图三中的时钟为例，旋转 0.0 或 360.0 度时，指针应该指向 12，旋转 90.0 度时，指针应该指向 3，旋转 180.0 度时，指针应该指向 6，旋转 270.0 度时，指针应该指向 9。

于是我们需要将旋转弧度转换成旋转角度，我研究出的转换公式如下：

Transform.rotate：

pi + pi * (angle / 180)

canvas.rotate：

angle * pi / 180

canvas.drawArc：

startAngle = -pi / 2

sweepAngle = angle * pi / 180

看见没有，这三类旋转的转换公式都不一样。我不明白 Flutter 官方为什么要这么设计，为啥这么优秀的 Flutter 引入了这么糟糕的 API。于是我带着气愤给官方提了个 Issue，想喷一喷设计这几个 API 的哥们：

结果我被反杀了。

冷静下来之后，我决定提交一个 Pull Request 来修正这个 API。但这需要时间，因为提交 Pull Request 的周期很长，上次我提了个 bug，Oppo 的一个哥们修复了它，Pull Request 等了将近两个月才合并。

GraphQL是一个用于API的查询语言，它可以使客户端准确地获得所需的数据，没有任何冗余。在Flutter项目中怎么使用Graphql呢？我们需要借助graphql-flutter插件

Tip： 这里以4.0.1为例

1. 添加依赖

首先添加到pubspec.yaml

然后我们再看看graphql-flutter(API)有什么，以及我们该怎么用。

2.重要API

GraphQLClient

• 仿apollo-client，通过配置Link和Cache构造客户端实例


• 像apollo-client一样通过构造不同Link来丰富client实例的功能

client实例方法几乎跟apollo-client一致，如query 、mutate 、 subscribe，也有些许差别的方法watchQuery 、 watchMutation 等，后面具体介绍使用区别

Link

• 作为抽象类，提供了Link.concat 、 Link.from的等factory函数，如上

graphql-flutter里基于Link实现了一些比较使用的类，如下

HttpLink

• 设置请求地址，默认header等

AuthLink

• 通过函数的形式设置Authentication

ErrorLink

• 设置错误拦截

DedupeLink

• 请求去重

GraphQLCache

• 配置实体缓存，官方推荐使用 HiveStore 配置持久缓存

• HiveStore在项目中关于环境是Web还是App需要作判断，所以我们需要一个方法

综上各个Link以及Cache构成了Client，我们稍加对这些API做一个封装，以便在项目复用。

3.基本封装

• 代码及释义如下

import 'dart:async';

import 'package:flutter/material.dart';

import 'package:graphql/client.dart';



import 'package:flutter/foundation.dart' show kIsWeb;

import 'package:path_provider/path_provider.dart'

    show getApplicationDocumentsDirectory;

import 'package:path/path.dart' show join;

import 'package:hive/hive.dart' show Hive;



class Gql {

  final String source;

  final String uri;

  final String token;

  final Map<String, String> header;



  HttpLink httpLink;

  AuthLink authLink;

  ErrorLink errorLink;



  GraphQLCache cache;

  GraphQLClient client;



  String authHeaderKey = 'token';

  String sourceKey = 'source';



  Gql({

    @required this.source,

    @required this.uri,

    this.token,

    this.header = const {},

  }) {

    // 设置url，复写传入header

    httpLink = HttpLink(uri, defaultHeaders: {

      sourceKey: source,

      ...header,

    });

    // 通过复写getToken动态设置auth

    authLink = AuthLink(getToken: getToken, headerKey: authHeaderKey);

    // 错误拦截

    errorLink = ErrorLink(

      onGraphQLError: onGraphQLError,

      onException: onException,

    );

    // 设置缓存

    cache = GraphQLCache(store: HiveStore());



    client = GraphQLClient(

      link: Link.from([

        DedupeLink(), // 请求去重

        errorLink,

        authLink,

        httpLink,

      ]),

      cache: cache,

    );

  }



  static Future<void> initHiveForFlutter({

    String subDir,

    Iterable<String> boxes = const [HiveStore.defaultBoxName],

  }) async {

    if (!kIsWeb) { // 判断App获取path，初始化

      var appDir = await getApplicationDocumentsDirectory(); // 获取文件夹路径

      var path = appDir.path;

      if (subDir != null) {

        path = join(path, subDir);

      }

      Hive.init(path);

    }



    for (var box in boxes) {

      await Hive.openBox(box);

    }

  }



  FutureOr<String> getToken() async => null;



  void _errorsLoger(List<GraphQLError> errors) {

    errors.forEach((error) {

      print(error.message);

    });

  }



  // LinkError处理函数

  Stream<Response> onException(

      Request req,

      Stream<Response> Function(Request) _,

      LinkException exception,

      ) {

    if (exception is ServerException) {  // 服务端错误

      _errorsLoger(exception.parsedResponse.errors);

    }



    if (exception is NetworkException) { // 网络错误

      print(exception.toString());

    }



    if (exception is HttpLinkParserException) { // http解析错误

      print(exception.originalException);

      print(exception.response);

    }



    return _(req);

  }



  // GraphqlError

  Stream<Response> onGraphQLError(

      Request req,

      Stream<Response> Function(Request) _,

      Response res,

      ) {

    // print(res.errors);

    _errorsLoger(res.errors); // 处理返回错误

    return _(req);

  }

}

4. 基本使用

• main.dart

void main() async {



  await Gql.initHiveForFlutter(); // 初始化HiveBox



  runApp(App());

}

• clent.dart

import 'dart:async';

import 'package:flutter/material.dart';

import 'package:shared_preferences/shared_preferences.dart';





const codeMessage = {

  401: '登录失效,',

  403: '用户已禁用',

  500: '服务器错误',

  503: '服务器错误',

};



// 通过复写，实现错误处理与token设置

class CustomGgl extends Gql {

  CustomGgl({

    @required String source,

    @required String uri,

    String token,

    Map<String, String> header = const {},

  }) : super(source: source, uri: uri, token: token, header: header);



  String authHeaderKey = 'token';



  @override

  FutureOr<String> getToken() async {  // 设置token

    final sharedPref = await SharedPreferences.getInstance();

    return sharedPref.getString(authHeaderKey);

  }



  @override

  Stream<Response> onGraphQLError( // 错误处理并给出提示

      Request req,

      Stream<Response> Function(Request) _,

      Response res,

      ) {

    res.errors.forEach((error) {

      final num code = error.extensions['exception']['status'];

      Toast.error(message: codeMessage[code] ?? error.message);

      print(error);

    });

    return _(req);

  }

}



// 创建ccClient

final Gql ccGql = CustomGgl(

  source: 'cc',

  uri: 'https://xxx/graphql',

  header: {

    'header': 'xxxx',

  },

);

• demo.dart

import 'package:flutter/material.dart';



import '../utils/client.dart';

import '../utils/json_view/json_view.dart';

import '../models/live_bill_config.dart';

import '../gql_operation/gql_operation.dart';



class GraphqlDemo extends StatefulWidget {

  GraphqlDemo({Key key}) : super(key: key);



  @override

  _GraphqlDemoState createState() => _GraphqlDemoState();

}



class _GraphqlDemoState extends State<GraphqlDemo> {

  ObservableQuery observableQuery;

  ObservableQuery observableMutation;



  Map<String, dynamic> json;

  num pageNum = 1;

  num pageSize = 10;



  @override

  void initState() {

    super.initState();



    Future.delayed(Duration(), () {

      initObservableQuery();

      initObservableMutation();

    });

  }



  @override

  Widget build(BuildContext context) {

    return SingleChildScrollView(

      child: Column(

        crossAxisAlignment: CrossAxisAlignment.start,

        children: [

          Wrap(

            spacing: 10.0,

            runSpacing: 10.0,

            children: [

              RaisedButton(

                onPressed: getLiveBillConfig,

                child: Text('Basic Query'),

              ),

              RaisedButton(

                onPressed: sendPhoneAuthCode,

                child: Text('Basic Mutation'),

              ),

              RaisedButton(

                onPressed: () {

                  pageNum++;



                  observableQuery.fetchMore(FetchMoreOptions(

                    variables: {

                      'pageNum': pageNum,

                      'pageSize': pageSize,

                    },

                    updateQuery: (prev, newData) => newData,

                  ));

                },

                child: Text('Watch Query'),

              ),

              RaisedButton(

                onPressed: () {

                  observableMutation.fetchResults();

                },

                child: Text('Watch Mutation'),

              ),

            ],

          ),

          Divider(),

          if (json != null)

            SingleChildScrollView(

              child: JsonView.map(json),

              scrollDirection: Axis.horizontal,

            ),

        ],

      ),

    );

  }





  @override

  dispose() {

    super.dispose();



    observableQuery.close();

  }



  void getLiveBillConfig() async {

    Toast.loading();



    try {

      final QueryResult result = await ccGql.client.query(QueryOptions(

        document: gql(LIVE_BILL_CONFIG),

        fetchPolicy: FetchPolicy.noCache,

      ));



      final liveBillConfig =

      result.data != null ? result.data['liveBillConfig'] : null;

      if (liveBillConfig == null) return;



      setState(() {

        json = LiveBillConfig.fromJson(liveBillConfig).toJson();

      });

    } finally {

      if (Toast.loadingType == ToastType.loading) Toast.dismiss();

    }

  }





  void sendPhoneAuthCode() async {

    Toast.loading();



    try {

      final QueryResult result = await ccGql.client.mutate(MutationOptions(

        document: gql(SEND_PHONE_AUTH_CODE),

        fetchPolicy: FetchPolicy.cacheAndNetwork,

        variables: {

          'phone': '15883300888',

          'authType': 2,

          'platformName': 'Backend'

        },

      ));



      setState(() {

        json = result.data;

      });

    } finally {

      if (Toast.loadingType == ToastType.loading) Toast.dismiss();

    }

  }



  void initObservableQuery() {

    observableQuery = ccGql.client.watchQuery(

      WatchQueryOptions(

        document: gql(GET_EMPLOYEE_CONFIG),

        variables: {

          'pageNum': pageNum,

          'pageSize': pageSize,

        },

      ),

    );



    observableQuery.stream.listen((QueryResult result) {

      if (!result.isLoading && result.data != null) {

        if (result.isLoading) {

          Toast.loading();

          return;

        }



        if (Toast.loadingType == ToastType.loading) Toast.dismiss();

        setState(() {

          json = result.data;

        });

      }

    });

  }



  void initObservableMutation() {

    observableMutation = ccGql.client.watchMutation(

      WatchQueryOptions(

        document: gql(LOGIN_BY_AUTH_CODE),

        variables: {

          'phone': '15883300888',

          'authCodeType': 2,

          'authCode': '5483',

          'statisticInfo': {'platformName': 'Backend'},

        },

      ),

    );



    observableMutation.stream.listen((QueryResult result) {

      if (!result.isLoading && result.data != null) {

        if (result.isLoading) {

          Toast.loading();

          return;

        }



        if (Toast.loadingType == ToastType.loading) Toast.dismiss();

        setState(() {

          json = result.data;

        });

      }

    });

  }

}

总结

这篇文章介绍了如何在Flutter项目中简单快速的使用GraphQL。并实现了一个简单的Demo。但是上面demo将UI和数据绑定在一起，导致代码耦合性很高。在实际的公司项目中，我们都会将数据和UI进行分离，常用的做法就是将GraphQL的 ValueNotifier client 调用封装到VM层中，然后在Widget中把VM数据进行绑定操作。网络上已经有大量介绍Provider|Bloc|GetX的文章，这里以介绍GraphQL使用为主，就不再赘述了。

介绍

在2017年，那时，观察者模式有效的简化了开发，但是诸如RxJava一类的库有一些太过复杂，学习成本太高，为此，LiveData出现了，一个专用于Android的，具备自主生命周期感知能力的，可观测的数据存储类。同时也出现了ViewModel这个组件，配合LiveData，更方便的实现MVVM模式中Model与View的分离。那么就让本文来带大家来学习LiveData与ViewModel的使用吧。

LiveData和ViewModel的关系：

本文的案例代码：github.com/taxze6/Jetp…

LiveData

参考资料：

🌟官方文档：developer.android.google.cn/topic/libra…

🌟LiveData postValue详解：http://www.cnblogs.com/button123/p…

LiveData是一种可观察的数据存储器类(响应式编程，类似Vue)。与常规的可观察类不同，LiveData 具有生命周期感知能力。LiveData最重要的是它了解观察者的生命周期，如Activity和Fragment。

因此，当LiveData发送变化时，UI会收到通知，然后UI可以使用新数据重新绘制自己。换句话说，LiveData可以很容易地使屏幕上发生的事情与数据保持同步（响应式编程的核心）

使用 LiveData 具有以下优势：

• 
  

  UI与数据状态匹配

  
  
  
  
  • LiveData 遵循观察者模式。当底层数据发生变化时，LiveData 会通知Observer对象。您可以整合代码以在这些 Observer对象中更新界面。这样一来，您无需在每次应用数据发生变化时更新界面，因为观察者会替您完成更新。
  
  
  
  


• 
  

  提高代码的稳定性

  
  

  代码稳定性在整个应用程序生命周期中增加：

  
  
  
  
  • 活动停止时不会发生崩溃。如果应用程序组件处于非活动状态，则这些更改不受影响。因此，您在更新数据时无需担心应用程序组件的生命周期。对于后台堆栈中的活动，它不会接受任何LiveData事件
  
  
  • 内存泄漏会减少，观察者会绑定到Lifecycle对象，并在其关联的生命周期遭到销毁后进行自我清理
  
  
  • 取消订阅任何观察者时无需担心
  
  
  • 如果由于配置更改（如设备旋转）而重新创建了 Activity 或 Fragment，它会立即接收最新的可用数据。
  
  
  
  


• 
  

  不再需要手动处理生命周期

  
  

  界面组件只是观察相关数据，不会停止或恢复观察。LiveData 将自动管理所有这些操作，因为它在观察时可以感知相关的生命周期状态变化。

  
  


• 
  

  数据始终保持最新状态

  
  

  如果生命周期变为非活跃状态，它会在再次变为活跃状态时接收最新的数据。例如，曾经在后台的 Activity 会在返回前台后立即接收最新的数据。

  
  


• 
  

  共享资源

  
  

  像单例模式一样，我们也可以扩展我们的LiveData对象来包装系统服务，以便它们可以在我们的应用程序中共享。一旦LiveData对象连接到系统服务，任何需要资源的观察者可以轻松地观看LiveData对象。

  
  

在以下情况中，不要使用LiveData：

• 您需要在信息上使用大量运算符，尽管LiveData提供了诸如转换之类的工具，但只有Map和switchMap可以帮助您


• 您没有与信息的UI交互


• 您有一次性的异步操作


• 您不必将缓存的信息保存到UI中

如何使用LiveData

一般来说我们会在 ViewModel 中创建 Livedata 对象，保证app配置变更时，数据不会丢失，然后再 Activity/Fragment 的 onCreate 中注册 Livedata 监听（因为在 onStart 和 onResume 中进行监听可能会有冗余调用）

基础使用流程：

1.创建一个实例LiveData来保存某种类型的数据。一般在你创建的ViewModel类中完成

class MainViewModel : ViewModel() {

    var mycount: MutableLiveData<Int> = MutableLiveData()

}

2.在Activity或者Fragment中获取到ViewModel，通过ViewModel获取到对应的LiveData

class MainActivity : AppCompatActivity() {

    lateinit var viewModel: MainViewModel

    override fun onCreate(savedInstanceState: Bundle?) {

        ...

        /**记住绝对不可以直接去创建ViewModel实例

        一定要通过ViewModelProvider(ViewModelStoreOwner)构造函数来获取。

        因为每次旋转屏幕都会重新调用onCreate()方法，如果每次都创建新的实例的话就无法保存数据了。

        用上述方法后，onCreate方法被再次调用,

        它会返回一个与MainActivity相关联的预先存在的ViewModel，这就是保存数据的原因。*/

        viewModel = ViewModelProvider(this@MainActivity,ViewModelProvider.

                        NewInstanceFactory()).get(MainViewModel::class.java)

    }

}

3.给LiveData添加观察者监听，用来监听LiveData中的数据变化，在Observer的onChanged中使用监听回调数据

/**

 *  订阅 ViewModel,mycount是一个LiveData类型 可以观察

 * */        

viewModel.mycount.observe(this@MainActivity) {

    countTv.text = viewModel.mycount.value.toString()

}

// LiveData onchange会自动感应生命周期 不需要手动

//        viewModel.mycount.observe(this, object : Observer<Int> {

//            override fun onChanged(t: Int?) {

//

//            }

//        })

进阶用法：

Transformations.map

现在有一个场景：我们通过网络请求，获得了一个User类数据（LiveData），但是，我们只想把User.name暴露给外部观察者，这样我们就可以通过Transformations.map来转化LiveData的数据类型，从而来实现上述场景。这个函数常用于对数据的封装。

//实体类

data class User(var name: String)

...

//Transformations.map接收两个参数，第一个参数是用于转换的LiveData原始对象，第二个参数是转换函数。

private val userLiveData: MutableLiveData<User> = MutableLiveData()

    val userNames: LiveData<String> = Transformations

        .map(userLiveData) { user ->

            user.name

}

Transformations.switchMap

switchMap是根据传入的LiveData的值，然后判断这个值，然后再去切换或者构建新的LiveData。比如我们有些数据需要依赖其他数据进行查询，就可以使用switchMap。

例如，有一个学生，他有两门课程的成绩，但是在UI组件中，我们一次只能显示一门课的成绩，在这个需要判断展示哪门课程成绩的需求下，我们就可以使用switchMap。

data class Student

    (var englishScore: Double, var mathScore: Double, val scoreTAG: Boolean)



.....

class SwitchMapViewModel:ViewModel {

    var studentLiveData = MutableLiveData<Student>()

    val transformationsLiveData = Transformations.switchMap(studentLiveData) {

        if (it.scoreTAG) {

            MutableLiveData(it.englishScore)

        } else {

            MutableLiveData(it.mathScore)

        }

    }

}



//使用时：

var student = Student()

person.englishScore = 88.2

person.mathScore = 91.3

//判断显示哪个成绩

person.condition = true

switchMapViewModel.conditionLiveData.postValue(person)

MediatorLiveData

MediatorLiveData继承于MutableLiveData，在MutableLiveData的基础上，增加了合并多个LiveData数据源的功能。其实就是通过addSource()这个方法去监听多个LiveData。

例如：现在有一个存在本地的dbLiveData，还有一个网络请求来的LiveData，我们需要讲上面两个结果结合之后展示给用户，第一种做法是我们在Activity中分别注册这两个LiveData的观察者，当数据发生变化时去更新UI，但是我们其实使用MediatorLiveData可以简化这个操作。

class MediatorLiveDataViewModel : ViewModel() {

    var liveDataA = MutableLiveData<String>()

    var liveDataB = MutableLiveData<String>()



    var mediatorLiveData = MediatorLiveData<String>()

    

    init {

        mediatorLiveData.addSource(liveDataA) {

            Log.d("This is livedataA", it)

            mediatorLiveData.postValue(it)

        }



        mediatorLiveData.addSource(liveDataB) {

            Log.d("This is livedataB", it)

            mediatorLiveData.postValue(it)

        }

    }

}

解释：

如果是第一次接触到LiveData的朋友可能会发现，我们虽然一直在提LiveData，但是用的时候却是MutableLiveData，这两个有什么关系呢，既然都没怎么用LiveData，那么把标题直接改成MutableLiveData吧
其实，LiveData与MutableLiveData在概念上是一模一样的。唯一的几个区别分别是：

💡“此处引用:LiveData与MutableLiveData的区别文章中的段落”

• MutableLiveData的父类是LiveData


• LiveData在实体类里可以通知指定某个字段的数据更新


• MutableLiveData则是完全是整个实体类或者数据类型变化后才通知.不会细节到某个字段。

原理探究：

对于LiveData的基础使用我们就讲到这里，想要探索LiveData原理的朋友可以从下面几个角度：

• LiveData的工作原理


• LiveData的observe方法源码分析


• LifecycleBoundObserver源码分析


• activeStateChanged源码分析（用于粘性事件）


• postValue和setValue


• considerNotify判断是否发送数据分析


• 粘性事件的分析

相信大家从以上几个角度去分析LiveData会有不小的收获💪

ViewModel

官方文档：developer.android.google.cn/topic/libra…

官方简介

ViewModel类旨在以注重生命周期的方式存储和管理界面相关的数据。ViewModel类让数据可在发生屏幕旋转等配置更改后继续留存。

生命周期

ViewModel的生命周期会比创建它的Activity、Fragment的生命周期都要长。所以ViewModel中的数据会一直存活在Activity/Fragment中。

基础使用流程：

1.构造数据对象

自定义ViewModel类，继承ViewModel，然后在自定义的ViewModel类中添加需要的数据对象

class MainViewModel : ViewModel() {

    ...

}

2.获取数据

有两种常见的ViewModel创建方式，第一种是在activity或fragment种直接基于 ViewModelProvider 获取。第二种是通过ViewModelFactory 创建

//第一种 ViewModelProvider直接获取

ViewModelProvider(this@MainActivity).get(MainViewModel::class.java)



//第二种 通过 ViewModelFactory 创建

class TestViewModelFactory(private val param: Int) : ViewModelProvider.Factory {

    override fun <T : ViewModel> create(modelClass: Class<T>): T {

        return TestViewModel(param) as T

    }

}



ViewModelProvider(this@MainActivity,TestViewModelFactory(0)).get(TestViewModel::class.java)

使用ViewModel就是这么简单🚢

ViewModel常见的使用场景

• 使用ViewModel，在横竖屏切换后，Activity重建，数据仍可以保存


• 同一个Activity下，Fragment之间的数据共享


• 与LiveData配合实现代码的解耦

ViewModel和onSaveInstanceState的区别

我相信大家一定知道onSaveInstanceState，它也是用来保存UI状态的，你可以使用它保存你所想保存的东西，在Activity被杀死之前，它一般在onStop或者onPause之前触发。虽然ViewModel被设计为应用除了onSaveInstanceState的另一个选项，但是还是有一些明显的区别。由于资源限制，ViewModel无法在进程关闭后继续存在，但onSaveInstance包含执行此任务。ViewModel是存储数据的绝佳选择，而onSaveInstanceState bundles不是用于该目的的合适选项。

ViewModel用于存储尽可能多的UI数据。因此，在配置更改期间不需要重新加载或重新生成该数据。

另一方面，如果该进程被框架关闭，onSaveInstanceState应该存储回复UI状态所需的最少数据量。例如，可以将所有用户的数据存放在ViewModel中，而仅将用户的数据库ID存储在onSaveInstanceState中。

android onSaveInstanceState调用时机详细总结

onSaveInstanceState用法及源码分析

ViewModel和Context

ViewModel不应该包含对Activity,Fragment或context的引用，此外，ViewModel不应包含对UI控制器（如View）的引用，因为这将创建对Context的间接引用。当您旋转Activity被销毁的屏幕时，您有一个ViewModel包含对已销毁Activity的引用，这就是内存泄漏。因此，如果需要使用上下文，则必须使用应用程序上下文 （AndroidViewModel） 。

LiveData和ViewModel的基本用法我们已经介绍完了，现在用几个例子带大家来更好的使用它们

案例一：计数器 — 两个Activity共享一个ViewModel

话不多说，先上效果图：

虽然这个案例是比较简单的，但是我相信可以帮助你更快的熟悉LiveData和ViewModel

想要实现效果图的话需要从下面几步来写（只讲解核心代码，具体代码请自己查看仓库）：

第一步：创建ViewModel

import androidx.lifecycle.LiveData

import androidx.lifecycle.MutableLiveData

import androidx.lifecycle.ViewModel



class MainViewModel : ViewModel() {

    private var _mycount: MutableLiveData<Int> = MutableLiveData()

    //只暴露不可变的LiveData给外部

    val mycount: LiveData<Int> get() = _mycount

    init {

        //初始化

        _mycount.value = 0

    }

    /**

     * mycount.value若为空就赋值为0，不为空则加一

     * */

    fun add() {

        _mycount.value = _mycount.value?.plus(1)

    }

    /**

     * mycount.value若为空就赋值为0，不为空则减一，可以为负数

     * */

    fun reduce() {

        _mycount.value = _mycount.value?.minus(1)

    }

    /**

     * 随机参数

     * */

    fun random() {

        val random = (0..100).random()

        _mycount.value = random

    }

    /**

     * 清除数据

     * */

    fun clear() {

        _mycount.value = 0

    }

}

第二步：标记ViewModel的作用域

因为，我们是两个Activity共享一个ViewModel，所以我们需要标记ViewModel的作用域

import androidx.lifecycle.*



/**

 * 用于标记viewmodel的作用域

 */

@Retention(AnnotationRetention.RUNTIME)

@Target(AnnotationTarget.FIELD)

annotation

class VMScope(val scopeName: String) {}



private val vMStores = HashMap<String, VMStore>()



fun LifecycleOwner.injectViewModel() {

    //根据作用域创建商店

    this::class.java.declaredFields.forEach { field ->

        field.getAnnotation(VMScope::class.java)?.also { scope ->

            val element = scope.scopeName

            var store: VMStore

            if (vMStores.keys.contains(element)) {

                store = vMStores[element]!!

            } else {

                store = VMStore()

                vMStores[element] = store

            }

            val clazz = field.type as Class<ViewModel>

            val vm = ViewModelProvider(store, ViewModelProvider.NewInstanceFactory()).get(clazz)

            field.set(this, vm)

        }

    }

}



class VMStore : ViewModelStoreOwner {

    private var vmStore: ViewModelStore? = null

    override fun getViewModelStore(): ViewModelStore {

        if (vmStore == null)

            vmStore = ViewModelStore()

        return vmStore!!

    }



}

第三步：在Activity中使用(都是部分代码)

class MainActivity : AppCompatActivity() {

    @VMScope("count") //设置作用域

    lateinit var viewModel: MainViewModel



    override fun onCreate(savedInstanceState: Bundle?) {

        super.onCreate(savedInstanceState)

        setContentView(R.layout.activity_main)

        injectViewModel()

        initEvent()

    }



    private fun initEvent() {

        val cardReduce: CardView = findViewById(R.id.card_reduce)

        .....

        cardReduce.setOnClickListener {

            //调用自定义ViewModel中的方法

            viewModel.reduce()

        }

        

        .....

        

        /**

         *  订阅 ViewModel,mycount是一个LiveData类型 可以观察

         * */

        viewModel.mycount.observe(this@MainActivity) {

            countTv.text = viewModel.mycount.value.toString()

        }

}

    

在第二个Activity中也是类似...

这样就可以实现效果图啦🏀

案例二：同一个Activity下的两个Fragment共享一个ViewModel

话不多说，先上效果图

这个效果就很简单了，在同一个Activity下，有两个Fragment，这两个Fragment共享一个ViewModel

这个案例主要是想带大家了解一下ViewModel在Fragment中的使用

第一步：依旧是创建ViewModel

class BlankViewModel : ViewModel() {

    private val numberLiveData = MutableLiveData<Int>()



    private var i = 0

    fun getLiveData(): LiveData<Int> {

        return numberLiveData

    }



    fun addOne(){

        i++

        numberLiveData.value = i

    }

}

非常简单的一个ViewModel

第二步：在Fragment中使用

//左Fragment

class LeftFragment : Fragment() {

    

    private val viewModel:BlankViewModel by activityViewModels()

    override fun onCreateView(

        inflater: LayoutInflater, container: ViewGroup?,

        savedInstanceState: Bundle?

    ): View? {

        return inflater.inflate(R.layout.fragment_left, container, false)

    }



    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {

        super.onViewCreated(view, savedInstanceState)

        //对+1按钮监听

        left_button.setOnClickListener {

            viewModel.addOne()

        }

        activity?.let {it ->

            viewModel.getLiveData().observe(it){

                left_text.text = it.toString()

            }

        }

    }

}



//右Fragment

class RightFragment : Fragment() {

    private val viewModel: BlankViewModel by activityViewModels()

    

    override fun onCreateView(

        inflater: LayoutInflater, container: ViewGroup?,

        savedInstanceState: Bundle?

    ): View? {

        return inflater.inflate(R.layout.fragment_right, container, false)

    }



    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {

        super.onViewCreated(view, savedInstanceState)

        right_button.setOnClickListener {

            viewModel.addOne()

        }

        activity?.let { it ->

            viewModel.getLiveData().observe(it) {

                right_text.text = it.toString()

            }

        }

    }

}

这样，这个简单的案例就实现啦。

尾述

终于把LiveData和ViewModel的大致使用讲解了一遍，但仅仅这样还是不够的，你还需要在更多更多的实践中去熟悉，去深入学习....

不久之前，部门进行了一次代码评审。

代码整体比较简单，该吹B的地方都已经吹过了，无非是些if else的老问题而已。当翻到一段定时任务的一步执行代码时，我的双眼一亮，觉得该BB两句了。

谁知这群家伙，评审的时候满满的认同感，但评审结束不久，就给我冠了个事B的称号。

今天我就把当时的这些话儿整理整理，让大家说道说道，我到底是不是个事B。淦！

一个任务处理例子

代码的结构大体是这样的。

通过定时，这段代码每天晚上凌晨都要对数据库的记录进行一遍对账。主要的逻辑，就是使用独立的线程，渐进式的读取数据库中的相关记录，然后把这些记录，放在循环中逐条进行处理。

ExecutorService service = Executors.newFixedThreadPool(10);

...

service.submit(()->{

    while(true){

        if(CollectionUtils.isEmpty(items)){

            break;

        }

        List<Data> items = queryPageData(start, end); // 分页逻辑

        for(Data item : items){

            try {

                Thread.sleep(10L);

            } catch (InterruptedException e) {

                //noop 

            }

            processItem(item);

        }

    }

});

等一下。在代码马上被翻过去的时候，我叫停了，这里的processItem没有捕获异常。

通常情况下，这不会有什么问题。但静好的岁月，总是偶尔会被一些随机的事故打断。如果这是你任务的完整代码，那它就有一种非常隐晦的故障处理方式。即使你的单元测试写的再好，这段代码我们依然可以通过远程投毒的方式，通过问题记录来让它产生问题。

是的。以上代码的根本原因，就是没有捕捉processItem函数可能产生的异常。如果在记录处理的时候，有任何一条抛出了异常，不管是checked异常还是unchecked异常，整个任务的执行都会终止！

不要觉得简单哦，踩过这个坑的同学，请记得扣个666。或者翻一下你的任务执行代码，看看是不是也有这个问题。

Java编译器在很多情况下都会提示你把异常给捕捉了，但总有些异常会逃出去，比如空指针异常。如下图，RuntimeException和Error都属于unchecked异常。

RuntimeException可以不用try...catch进行处理，但是如果一旦出现异常，则会导致程序中断执行，JVM将统一处理这些异常。

你捕捉不到它，它自然会让你的任务完蛋。

如果你想要异步的执行一些任务，最好多花一点功夫到异常设计上面。在这上面翻车的同学比比皆是，这辆车并不介意再带上你一个。

评审的小伙很谦虚，马上就现场修改了代码。

不要生吞异常

且看修改后的代码。

ExecutorService service = Executors.newFixedThreadPool(10);

...

service.submit(()->{

    while(true){

        if(CollectionUtils.isEmpty(items)){

            break;

        }

        List<Data> items = queryPageData(start, end); // 分页逻辑

        for(Data item : items){

            try {

                Thread.sleep(10L);

            } catch (InterruptedException e) {

                //noop 

            }

            try{

                processItem(item);

            }catch(Exception ex){

                LOG.error(...,ex);

            }

        }

    }

});

...

service.shutdownNow();

为了控制任务执行的频率，sleep大法是个有效的方法。

代码里考虑的很周到，按照我们上述的方式捕捉了异常。同时，还很贴心的把sleep相关的异常也给捕捉了。这里不贴心也没办法，因为不补齐这部分代码的话，编译无法通过，我们姑且认为是开发人员的水平够屌。

由于sleep抛出的是InterruptedException，所以代码什么也没处理。这也是我们代码里常见的操作。不信打开你的项目，忽略InterruptedException的代码肯定多如牛毛。

此时，你去执行这段代码，虽然线程池使用了暴力的shutdownNow函数，但你的代码依然无法终止，它将一直run下去。因为你忽略了InterruptedException异常。

当然，我们可以在捕捉到InterruptedException的时候，终止循环。

try {

    Thread.sleep(10L);

} catch (InterruptedException e) {

    break;

}

虽然这样能够完成预期，但一般InterruptedException却不是这么处理的。正确的处理方式是这样的：

while (true) {

    Thread currentThread = Thread.currentThread();

    if(currentThread.isInterrupted()){

        break;

    }

    try {

        Thread.sleep(1L);

    } catch (InterruptedException e) {

        currentThread.interrupt();

    }

}

除了捕捉它，我们还要再次把interrupt状态给复位，否则它就随着捕捉给清除了。InterruptedException在很多场景非常的重要。当有些方法一直阻塞着线程，比如耗时的计算，会让整个线程卡在那里什么都干不了，InterruptedException可以中断任务的执行，是非常有用的。

但是对我们现在代码的逻辑来说，并没有什么影响。被评审的小伙伴不满意的说。

还有问题！

有没有影响是一回事，是不是好的习惯是另一回事 。我尽量的装了一下B，其实，你的异常处理代码里还有另外隐藏的问题。

还有什么问题？，大家都一改常日慵懒的表情，你倒是说说。

我们来看一下小伙伴现场改的问题。他直接使用catch捕获了这里的异常，然后记录了相应的日志。我要说的问题是，这里的Exception粒度是不对的，太粗鲁。

try{

    processItem(item);

}catch(Exception ex){

    LOG.error(...,ex);

}

processItem函数抛出了IOException，同时也抛出了InterruptedException，但我们都一致对待为普通的Exception，这样就无法体现上层函数抛出异常的意图。

比如processItem函数抛出了一个TimeoutExcepiton，期望我们能够基于它做一些重试；或者抛出了SystemBusyExcption，期望我们能够多sleep一会，给服务器一点时间。这种粗粒度的异常一股脑的将它们捕捉，在新异常添加的时候根本无法发现这些代码，会发生风险。

一时间会议室里寂静无比。

我觉得你说的很对 ，一位比较资深的老鸟说， 你的意思是把所有的异常情况都分别捕捉，进行精细化处理。但最后你还是要使用Exception来捕捉RuntimeException，异常还是捕捉不到啊。

果然是不同凡响的发问。

优秀的、标准的代码写法，其中无法实施的一个重要因素，就是项目中的其他代码根本不按规矩来。如果我们下层的代码，进行了正确的空指针判断、数组越界操作，或者使用类似guava的Preconditions这类API进行了前置的异常翻译，上面的这种问题根本不用回答。

但上面这种代码的情况，我们就需要手动的捕捉RuntimeException，进行单独的处理。

你们这个项目，烂代码太多了，所以不好改。我虽然有情商，但我更有脾气。

大家不欢而散。

End

我实在是想不通，代码review就是用来发现问题的。结果这review会一开下来，大家都在背后讽刺我。这到底是我的问题呢？还是这个团队的问题呢？让人搞不懂。

你们在纠结使用Integer还是int的时候，我也没说什么呀，现在就谈点异常处理的问题，就那么玻璃心受不了了。这B不能全都让你们装了啊。

什么？你要review一下我的代码？看看我到底有没有像我说的一样写代码，有没有以身作则？是在不好意思，我可是架构师哎，我已经很多年没写代码了。

你的这个愿望让你落空了！

在电商、支付等领域，往往会有这样的场景，用户下单后放弃支付了，那这笔订单会在指定的时间段后进行关闭操作，细心的你一定发现了像某宝、某东都有这样的逻辑，而且时间很准确，误差在1s内；那他们是怎么实现的呢？

一般的做法有如下几种

• 
  

  定时任务关闭订单

  
  


• 
  

  rocketmq延迟队列

  
  


• 
  

  rabbitmq死信队列

  
  


• 
  

  时间轮算法

  
  


• 
  

  redis过期监听

  
  

一、定时任务关闭订单（最low）

一般情况下，最不推荐的方式就是关单方式就是定时任务方式，原因我们可以看下面的图来说明

我们假设，关单时间为下单后10分钟，定时任务间隔也是10分钟；通过上图我们看出，如果在第1分钟下单，在第20分钟的时候才能被扫描到执行关单操作，这样误差达到10分钟，这在很多场景下是不可接受的，另外需要频繁扫描主订单号造成网络IO和磁盘IO的消耗，对实时交易造成一定的冲击，所以PASS

二、rocketmq延迟队列方式

延迟消息
生产者把消息发送到消息服务器后，并不希望被立即消费，而是等待指定时间后才可以被消费者消费，这类消息通常被称为延迟消息。
在RocketMQ开源版本中，支持延迟消息，但是不支持任意时间精度的延迟消息，只支持特定级别的延迟消息。
消息延迟级别分别为1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h，共18个级别。

发送延迟消息（生产者）

/**

     * 推送延迟消息

     * @param topic 

     * @param body 

     * @param producerGroup 

     * @return boolean

     */

    public boolean sendMessage(String topic, String body, String producerGroup)

    {

        try

        {

            Message recordMsg = new Message(topic, body.getBytes());

            producer.setProducerGroup(producerGroup);



            //设置消息延迟级别，我这里设置14，对应就是延时10分钟

            // "1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h"

            recordMsg.setDelayTimeLevel(14);

            // 发送消息到一个Broker

            SendResult sendResult = producer.send(recordMsg);

            // 通过sendResult返回消息是否成功送达

            log.info("发送延迟消息结果：======sendResult：{}", sendResult);

            DateFormat format =new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");

            log.info("发送时间：{}", format.format(new Date()));



            return true;

        }

        catch (Exception e)

        {

            e.printStackTrace();

            log.error("延迟消息队列推送消息异常:{},推送内容:{}", e.getMessage(), body);

        }

        return false;

    }

消费延迟消息（消费者）

/**

     * 接收延迟消息

     * 

     * @param topic

     * @param consumerGroup

     * @param messageHandler

     */

    public void messageListener(String topic, String consumerGroup, MessageListenerConcurrently messageHandler)

{

        ThreadPoolUtil.execute(() ->

        {

            try

            {

                DefaultMQPushConsumer consumer = new DefaultMQPushConsumer();

                consumer.setConsumerGroup(consumerGroup);

                consumer.setVipChannelEnabled(false);

                consumer.setNamesrvAddr(address);

                //设置消费者拉取消息的策略，*表示消费该topic下的所有消息，也可以指定tag进行消息过滤

                consumer.subscribe(topic, "*");

                //消费者端启动消息监听，一旦生产者发送消息被监听到，就打印消息，和rabbitmq中的handlerDelivery类似

                consumer.registerMessageListener(messageHandler);

                consumer.start();

                log.info("启动延迟消息队列监听成功:" + topic);

            }

            catch (MQClientException e)

            {

                log.error("启动延迟消息队列监听失败:{}", e.getErrorMessage());

                System.exit(1);

            }

        });

    }

实现监听类，处理具体逻辑

/**

 * 延迟消息监听

 * 

 */

@Component

public class CourseOrderTimeoutListener implements ApplicationListener<ApplicationReadyEvent>

{



    @Resource

    private MQUtil mqUtil;



    @Resource

    private CourseOrderTimeoutHandler courseOrderTimeoutHandler;



    @Override

    public void onApplicationEvent(ApplicationReadyEvent applicationReadyEvent)

{

        // 订单超时监听

        mqUtil.messageListener(EnumTopic.ORDER_TIMEOUT, EnumGroup.ORDER_TIMEOUT_GROUP, courseOrderTimeoutHandler);

    }

}

/**

 *  实现监听

 */

@Slf4j

@Component

public class CourseOrderTimeoutHandler implements MessageListenerConcurrently

{



    @Override

    public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> list, ConsumeConcurrentlyContext consumeConcurrentlyContext) {

        for (MessageExt msg : list)

        {

            // 得到消息体

            String body = new String(msg.getBody());

            JSONObject userJson = JSONObject.parseObject(body);

            TCourseBuy courseBuyDetails = JSON.toJavaObject(userJson, TCourseBuy.class);



            // 处理具体的业务逻辑，，，，，



      DateFormat format =new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");

           log.info("消费时间：{}", format.format(new Date()));

           

        return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;

    }

}

这种方式相比定时任务好了很多，但是有一个致命的缺点，就是延迟等级只有18种（商业版本支持自定义时间），如果我们想把关闭订单时间设置在15分钟该如何处理呢？显然不够灵活。

三、rabbitmq死信队列的方式

Rabbitmq本身是没有延迟队列的，只能通过Rabbitmq本身队列的特性来实现，想要Rabbitmq实现延迟队列，需要使用Rabbitmq的死信交换机（Exchange）和消息的存活时间TTL（Time To Live）

死信交换机
一个消息在满足如下条件下，会进死信交换机，记住这里是交换机而不是队列，一个交换机可以对应很多队列。

一个消息被Consumer拒收了，并且reject方法的参数里requeue是false。也就是说不会被再次放在队列里，被其他消费者使用。
上面的消息的TTL到了，消息过期了。

队列的长度限制满了。排在前面的消息会被丢弃或者扔到死信路由上。
死信交换机就是普通的交换机，只是因为我们把过期的消息扔进去，所以叫死信交换机，并不是说死信交换机是某种特定的交换机

消息TTL（消息存活时间）
消息的TTL就是消息的存活时间。RabbitMQ可以对队列和消息分别设置TTL。对队列设置就是队列没有消费者连着的保留时间，也可以对每一个单独的消息做单独的设置。超过了这个时间，我们认为这个消息就死了，称之为死信。如果队列设置了，消息也设置了，那么会取值较小的。所以一个消息如果被路由到不同的队列中，这个消息死亡的时间有可能不一样（不同的队列设置）。这里单讲单个消息的TTL，因为它才是实现延迟任务的关键。

byte[] messageBodyBytes = "Hello, world!".getBytes();  

AMQP.BasicProperties properties = new AMQP.BasicProperties();  

properties.setExpiration("60000");  

channel.basicPublish("my-exchange", "queue-key", properties, messageBodyBytes);  

可以通过设置消息的expiration字段或者x-message-ttl属性来设置时间，两者是一样的效果。只是expiration字段是字符串参数，所以要写个int类型的字符串：当上面的消息扔到队列中后，过了60秒，如果没有被消费，它就死了。不会被消费者消费到。这个消息后面的，没有“死掉”的消息对顶上来，被消费者消费。死信在队列中并不会被删除和释放，它会被统计到队列的消息数中去

处理流程图

创建交换机（Exchanges）和队列（Queues）

创建死信交换机

如图所示，就是创建一个普通的交换机，这里为了方便区分，把交换机的名字取为：delay

创建自动过期消息队列
这个队列的主要作用是让消息定时过期的，比如我们需要2小时候关闭订单，我们就需要把消息放进这个队列里面，把消息过期时间设置为2小时

创建一个一个名为delay_queue1的自动过期的队列，当然图片上面的参数并不会让消息自动过期，因为我们并没有设置x-message-ttl参数，如果整个队列的消息有消息都是相同的，可以设置，这里为了灵活，所以并没有设置，另外两个参数x-dead-letter-exchange代表消息过期后，消息要进入的交换机，这里配置的是delay，也就是死信交换机，x-dead-letter-routing-key是配置消息过期后，进入死信交换机的routing-key,跟发送消息的routing-key一个道理，根据这个key将消息放入不同的队列

创建消息处理队列
这个队列才是真正处理消息的队列，所有进入这个队列的消息都会被处理

消息队列的名字为delay_queue2
消息队列绑定到交换机
进入交换机详情页面，将创建的2个队列（delayqueue1和delayqueue2）绑定到交换机上面

自动过期消息队列的routing key 设置为delay
绑定delayqueue2

delayqueue2 的key要设置为创建自动过期的队列的x-dead-letter-routing-key参数，这样当消息过期的时候就可以自动把消息放入delay_queue2这个队列中了
绑定后的管理页面如下图：

当然这个绑定也可以使用代码来实现，只是为了直观表现，所以本文使用的管理平台来操作
发送消息

String msg = "hello word";  

MessageProperties messageProperties = newMessageProperties();  

messageProperties.setExpiration("6000");

messageProperties.setCorrelationId(UUID.randomUUID().toString().getBytes());

Message message = newMessage(msg.getBytes(), messageProperties);

rabbitTemplate.convertAndSend("delay", "delay",message);

设置了让消息6秒后过期
注意：因为要让消息自动过期，所以一定不能设置delay_queue1的监听，不能让这个队列里面的消息被接受到，否则消息一旦被消费，就不存在过期了

接收消息
接收消息配置好delay_queue2的监听就好了

package wang.raye.rabbitmq.demo1;

import org.springframework.amqp.core.AcknowledgeMode;  

import org.springframework.amqp.core.Binding;  

import org.springframework.amqp.core.BindingBuilder;  

import org.springframework.amqp.core.DirectExchange;  

import org.springframework.amqp.core.Message;  

import org.springframework.amqp.core.Queue;  

import org.springframework.amqp.rabbit.connection.CachingConnectionFactory;  

import org.springframework.amqp.rabbit.connection.ConnectionFactory;  

import org.springframework.amqp.rabbit.core.ChannelAwareMessageListener;  

import org.springframework.amqp.rabbit.listener.SimpleMessageListenerContainer;  

import org.springframework.beans.factory.annotation.Autowired;  

import org.springframework.context.annotation.Bean;  

import org.springframework.context.annotation.Configuration;

@Configuration

publicclassDelayQueue{  

    /** 消息交换机的名字*/

    publicstaticfinalString EXCHANGE = "delay";

    /** 队列key1*/

    publicstaticfinalString ROUTINGKEY1 = "delay";

    /** 队列key2*/

    publicstaticfinalString ROUTINGKEY2 = "delay_key";

    /**

     * 配置链接信息

     * @return

     */

    @Bean

    publicConnectionFactory connectionFactory() {

        CachingConnectionFactory connectionFactory = newCachingConnectionFactory("120.76.237.8",5672);

        connectionFactory.setUsername("kberp");

        connectionFactory.setPassword("kberp");

        connectionFactory.setVirtualHost("/");

        connectionFactory.setPublisherConfirms(true); // 必须要设置

        return connectionFactory;

    }

    /**  

     * 配置消息交换机

     * 针对消费者配置  

        FanoutExchange: 将消息分发到所有的绑定队列，无routingkey的概念  

        HeadersExchange ：通过添加属性key-value匹配  

        DirectExchange:按照routingkey分发到指定队列  

        TopicExchange:多关键字匹配  

     */  

    @Bean  

    publicDirectExchange defaultExchange() {  

        returnnewDirectExchange(EXCHANGE, true, false);

    }

    /**

     * 配置消息队列2

     * 针对消费者配置  

     * @return

     */

    @Bean

    publicQueue queue() {  

       returnnewQueue("delay_queue2", true); //队列持久  

    }

    /**

     * 将消息队列2与交换机绑定

     * 针对消费者配置  

     * @return

     */

    @Bean  

    @Autowired

    publicBinding binding() {  

        returnBindingBuilder.bind(queue()).to(defaultExchange()).with(DelayQueue.ROUTINGKEY2);  

    }

    /**

     * 接受消息的监听，这个监听会接受消息队列1的消息

     * 针对消费者配置  

     * @return

     */

    @Bean  

    @Autowired

    publicSimpleMessageListenerContainer messageContainer2(ConnectionFactory connectionFactory) {  

        SimpleMessageListenerContainer container = newSimpleMessageListenerContainer(connectionFactory());  

        container.setQueues(queue());  

        container.setExposeListenerChannel(true);  

        container.setMaxConcurrentConsumers(1);  

        container.setConcurrentConsumers(1);  

        container.setAcknowledgeMode(AcknowledgeMode.MANUAL); //设置确认模式手工确认  

        container.setMessageListener(newChannelAwareMessageListener() {

            publicvoid onMessage(Message message, com.rabbitmq.client.Channel channel) throwsException{

                byte[] body = message.getBody();  

                System.out.println("delay_queue2 收到消息 : "+ newString(body));  

                channel.basicAck(message.getMessageProperties().getDeliveryTag(), false); //确认消息成功消费  

            }  

        });  

        return container;  

    }  

}

这种方式可以自定义进入死信队列的时间；是不是很完美，但是有的小伙伴的情况是消息中间件就是rocketmq，公司也不可能会用商业版，怎么办？那就进入下一节

四、时间轮算法

(1)创建环形队列，例如可以创建一个包含3600个slot的环形队列(本质是个数组)

(2)任务集合，环上每一个slot是一个Set
同时，启动一个timer，这个timer每隔1s，在上述环形队列中移动一格，有一个Current Index指针来标识正在检测的slot。

Task结构中有两个很重要的属性：
(1)Cycle-Num：当Current Index第几圈扫描到这个Slot时，执行任务
(2)订单号，要关闭的订单号（也可以是其他信息，比如：是一个基于某个订单号的任务）

假设当前Current Index指向第0格，例如在3610秒之后，有一个订单需要关闭，只需：
(1)计算这个订单应该放在哪一个slot，当我们计算的时候现在指向1，3610秒之后，应该是第10格，所以这个Task应该放在第10个slot的Set中
(2)计算这个Task的Cycle-Num，由于环形队列是3600格(每秒移动一格，正好1小时)，这个任务是3610秒后执行，所以应该绕3610/3600=1圈之后再执行，于是Cycle-Num=1

Current Index不停的移动，每秒移动到一个新slot，这个slot中对应的Set，每个Task看Cycle-Num是不是0：
(1)如果不是0，说明还需要多移动几圈，将Cycle-Num减1
(2)如果是0，说明马上要执行这个关单Task了，取出订单号执行关单(可以用单独的线程来执行Task)，并把这个订单信息从Set中删除即可。
(1)无需再轮询全部订单，效率高
(2)一个订单，任务只执行一次
(3)时效性好，精确到秒(控制timer移动频率可以控制精度)

五、redis过期监听

1.修改redis.windows.conf配置文件中notify-keyspace-events的值
默认配置notify-keyspace-events的值为 ""
修改为 notify-keyspace-events Ex 这样便开启了过期事件

2. 创建配置类RedisListenerConfig（配置RedisMessageListenerContainer这个Bean）

package com.zjt.shop.config;

import org.springframework.beans.factory.annotation.Autowired;

import org.springframework.context.annotation.Bean;

import org.springframework.context.annotation.Configuration;

import org.springframework.data.redis.connection.RedisConnectionFactory;

import org.springframework.data.redis.core.RedisTemplate;

import org.springframework.data.redis.listener.RedisMessageListenerContainer;

import org.springframework.data.redis.serializer.GenericJackson2JsonRedisSerializer;

import org.springframework.data.redis.serializer.StringRedisSerializer;

 

 

@Configuration

public class RedisListenerConfig {

 

    @Autowired

    private RedisTemplate redisTemplate;

 

    /**

     * @return

     */

    @Bean

    public RedisTemplate redisTemplateInit() {

 

        // key序列化

        redisTemplate.setKeySerializer(new StringRedisSerializer());

 

        //val实例化

        redisTemplate.setValueSerializer(new GenericJackson2JsonRedisSerializer());

 

        return redisTemplate;

    }

 

    @Bean

    RedisMessageListenerContainer container(RedisConnectionFactory connectionFactory) {

        RedisMessageListenerContainer container = new RedisMessageListenerContainer();

        container.setConnectionFactory(connectionFactory);

        return container;

    }

 

}

3.继承KeyExpirationEventMessageListener创建redis过期事件的监听类

package com.zjt.shop.common.util;

import com.baomidou.mybatisplus.core.conditions.query.QueryWrapper;

import com.baomidou.mybatisplus.core.conditions.update.UpdateWrapper;

import com.zjt.shop.modules.order.service.OrderInfoService;

import com.zjt.shop.modules.product.entity.OrderInfoEntity;

import com.zjt.shop.modules.product.mapper.OrderInfoMapper;

import lombok.extern.slf4j.Slf4j;

import org.springframework.beans.factory.annotation.Autowired;

import org.springframework.data.redis.connection.Message;

import org.springframework.data.redis.listener.KeyExpirationEventMessageListener;

import org.springframework.data.redis.listener.RedisMessageListenerContainer;

import org.springframework.stereotype.Component;

 



@Slf4j

@Component

public class RedisKeyExpirationListener extends KeyExpirationEventMessageListener {

 

    public RedisKeyExpirationListener(RedisMessageListenerContainer listenerContainer) {

        super(listenerContainer);

    }

 

    @Autowired

    private OrderInfoMapper orderInfoMapper;

 

    /**

     * 针对redis数据失效事件，进行数据处理

     * @param message

     * @param pattern

     */

    @Override

    public void onMessage(Message message, byte[] pattern) {

      try {

          String key = message.toString();

          //从失效key中筛选代表订单失效的key

          if (key != null && key.startsWith("order_")) {

              //截取订单号，查询订单，如果是未支付状态则为-取消订单

              String orderNo = key.substring(6);

              QueryWrapper<OrderInfoEntity> queryWrapper = new QueryWrapper<>();

              queryWrapper.eq("order_no",orderNo);

              OrderInfoEntity orderInfo = orderInfoMapper.selectOne(queryWrapper);

              if (orderInfo != null) {

                  if (orderInfo.getOrderState() == 0) {   //待支付

                      orderInfo.setOrderState(4);         //已取消

                      orderInfoMapper.updateById(orderInfo);

                      log.info("订单号为【" + orderNo + "】超时未支付-自动修改为已取消状态");

                  }

              }

          }

      } catch (Exception e) {

          e.printStackTrace();

          log.error("【修改支付订单过期状态异常】：" + e.getMessage());

      }

    }

}

4：测试
通过redis客户端存一个有效时间为3s的订单：

结果：

RxJava思想

• 
  

  文章概述：

  
  
  
  
  • 本文围绕Rx编程思想(响应式编程)进行深入细致探讨；以获取服务器图片为例，通过传统方式与Rx方式对比进一步体现Rx 编程方式的魅力；借助卡片式编程思想，对Rx编程方式进行第一次优化；借助 Java泛型对Rx编程进一步优化；
  
  
  
  

Rx编程出现背景：改变思维来提升效率

• 
  

  通过事件流动，推进业务执行

  
  
  
  
  • 
    

    从起点到终点，逻辑严密

    
    
    
    
    • 下一层依赖上一层：体现在函数参数
    
    
    
    
  
  
  • 
    

    链式调用只是里面的一环

    
    
  
  
  • 
    

    样例：每一层逻辑上关联

    
    
    
    
    • 起点（分发事件：点击登录）----------登录API-------请求服务器--------获取响应码----------> 终点（更新UI登录成功 消费事件）
    
    
    
    
  
  
  
  

RxJava 配合 Retrofit

• 
  

  业务逻辑：

  
  
  
  
  • Retrofit通过OKHHTTP请求服务器拿到响应码，交给RxJava由RxJava处理数据
  
  
  
  


• 
  

  防抖：

  
  
  
  
  • 一秒钟点击了20次，只响应一次
  
  
  
  


• 
  

  网络嵌套：拿到主数据再拿到item数据

  
  


• 
  

  doNext运用：异步与主线之间频繁切换

  
  
  
  
  • 异步线程A拿到数据，切换至UI线程更新，再次切换到异步线程B，再拿到UI线程
  
  
  
  

对比说明Rx 编程优势：统一业务代码逻辑

• 主要内容：以获取服务器图片为例，通过传统方式与Rx方式对比进一步体现Rx 编程方式的魅力；

传统模式获取图片

• 
  

  实现效果：

  
  

  

  
  


• 
  

  传统编写思路：

  
  
  
  
  • 
    

    弹出加载框

    
    
  
  
  • 
    

    开启异步线程：此时有多种途径

    
    
    
    
    • 封装方法....
    
    
    • 全部写在一起
    
    
    • new Thread
    
    
    • 使用 线程池
    
    
    
    
  
  
  • 
    

    将从服务器获取的图片转成Bitmap

    
    
  
  
  • 
    

    从异步线程切换至UI线程更新UI

    
    
  
  
  • 
    

    代码实现：

    
    

     public void downloadImageAction(View view) {
    
         progressDialog = new ProgressDialog(this);
    
         progressDialog.setTitle("下载图片中...");
    
         progressDialog.show();
    
     
    
         //       异步线程处理耗时任务
    
         new Thread(new Runnable() {
    
             @Override
    
             public void run() {
    
                 try {
    
                     URL url = new URL(PATH);
    
                     HttpURLConnection httpURLConnection = (HttpURLConnection) url.openConnection();
    
                     httpURLConnection.setConnectTimeout(5000);
    
                     int responseCode = httpURLConnection.getResponseCode(); // 才开始 request
    
                     if (responseCode == HttpURLConnection.HTTP_OK) {
    
                         InputStream inputStream = httpURLConnection.getInputStream();
    
                         //                        图片丢给bitmap
    
                         Bitmap bitmap = BitmapFactory.decodeStream(inputStream);
    
                         //                        使用Handler 进行切换
    
                         Message message = handler.obtainMessage();
    
                         message.obj = bitmap;
    
                         handler.sendMessage(message);
    
                     }
    
                 } catch (Exception e) {
    
                     e.printStackTrace();
    
                 }
    
             }
    
         }).start();
    
     }
    
     
    
     //    使用Handler处理问题
    
     private final Handler handler = new Handler(new Handler.Callback() {
    
     
    
         @Override
    
         public boolean handleMessage(@NonNull Message msg) {
    
             Bitmap bitmap = (Bitmap) msg.obj;
    
             image.setImageBitmap(bitmap);
    
     
    
             if (progressDialog != null) progressDialog.dismiss();
    
             return false;
    
         }
    
     });
    
    

    
    
  
  
  
  

• 
  

  传统方式弊端：

  
  
  
  
  • 
    

    在具体实现(切换线程)时，因为思维不统一，导致实现方式不同

    
    
  
  
  
  

RxJava思路：采用观察者设计模式，实现响应式(Rx)编程

• 
  

  以事件流动推进业务执行

  
  


• 
  

  角色：

  
  
  
  
  • 
    

    起点：被观察者(为其分配异步线程--->请求服务器)

    
    

     // 起点
    
     Observable.just(PATH)  // 内部会分发  PATH Stirng  // TODO 第二步
    
    

    
    
  
  
  • 
    

    终点：观察者(为其分配UI线程--->更新UI)

    
    

     //终点
    
     .subscribe(
    
         new Observer<Bitmap>() {
    
             //订阅
    
             @Override
    
             public void onSubscribe(Disposable d) {
    
                
    
             }
    
             //拿到事件：因为上一层是一个String类型的Path事件
    
             @Override
    
             public void onNext(@NonNull Bitmap bitmap) {
    
                 image.setImageBitmap(bitmap);
    
             }
    
     
    
             // 错误事件
    
             @Override
    
             public void onError(Throwable e) {
    
     
    
             }
    
     
    
             // 完成事件
    
             @Override
    
             public void onComplete() {
    
              
    
             }
    
         });
    
    

    
    
  
  
  
  


• 
  

  编写思路：框架在实际使用中是U型逻辑(终点--->起点--->终点--->……)

  
  
  
  
  • 
    

    第一步：处理终点中拿到事件后的业务逻辑

    
    

     //拿到事件：因为上一层是一个String类型的Path事件
    
     @Override
    
     public void onNext(@NonNull String s) {
    
         image.setImageBitmap(bitmap);
    
     }
    
    

    
    
    
    
    • 
      

      细节：onNext的参数问题

      
      
      
      
      • 
        

        Rx 整体是以事件流动推进业务逻辑，如果上一层是String类型的事件(Path)那么它的下一层应该也是String类型的事件(参数为String类型)

        
        
      
      
      • 
        

        但Rx 中根据业务进行事件的拦截

        
        
        
        
        • A层(String事件)，B层(Bitmap事件)，逻辑为A层--->B层
        
        
        • 那么就需要在A层到B层之间添加一个拦截器，进行事件转换
        
        
        
        
      
      
      
      
    
    
    
    
  
  
  • 
    

    第二步：在起点与终点之间添加拦截器

    
    
    
    
    • 
      

      为什么要添加拦截器：业务需求是拿到一个Bitmap而起点提供的是String类型的事件

      
      
    
    
    • 
      

      拦截器为map(K,V)：K为上层事件，V为下层事件

      
      

       //上层事件为String类型，由系统自动推断；但此时拦截器并不知道下一层是什么事件，因此为Object
      
       .map(new Function<String, Object>() {
      
       })
      
      

      
      
    
    
    
    
    
    
    
    • 
      

      终点要求Bitmap事件

      
      

       //根据业务将map 中的value改为 Bitmap类型
      
       .map(new Function<String, Object>() {
      
       })
      
      

      
      
      
      
      • 
        

        终点完成事件(onNext报错，联动变化)：注意由Rx思想决定，那么终点处的完成事件参数因为Bitmap

        
        

         //由Rx思想决定，那么终点处的完成事件参数因为Bitmap
        
         @Override
        
         public void onNext(@NonNull Bitmap bitmap) {
        
         image.setImageBitmap(bitmap);
        
         }
        
        

        
        
      
      
      • 
        

        整体事件流向：

        
        

        

        
        
      
      
      
      
    
    
    
    
  
  
  • 
    

    第三步：在拦截器内添加网络请求

    
    

     @Override
    
     public Bitmap apply(@NonNull String s) throws Exception {
    
     
    
         //处理网络请求：将String类型的Path事件处理为Bitmap实例
    
         URL url = new URL(PATH);
    
         HttpURLConnection httpURLConnection = (HttpURLConnection) url.openConnection();
    
         int responseCode = httpURLConnection.getResponseCode();
    
         if(responseCode == httpURLConnection.HTTP_OK){
    
             InputStream inputStream = httpURLConnection.getInputStream();
    
             Bitmap bitmap = BitmapFactory.decodeStream(inputStream);
    
             return bitmap;
    
         }
    
         return null;
    
     }
    
    

    
    
    
    
    • 此时不要使用Handler，因为拦截器已经将String类型事件转为Bitmap类型了，将Bitmap流向终点进行显示
    
    
    
    
  
  
  • 
    

    第四步：分配线程

    
    
    
    
    • 
      

      起点到此时拦截器结束，应当分配异步线程(因为需要请求服务器)

      
      

       //给上边代码分配异步线程，用于请求服务器
      
       .subscribeOn(Schedulers.io())
      
      

      
      
    
    
    • 
      

      拦截器结束位置到终点处，应当分配UI主线程(因为需要更新UI)

      
      

       //给下边的代码分配主线程，用于更新UI
      
       .observeOn(AndroidSchedulers.mainThread())
      
      

      
      
      
      
      • 
        

        分配的主线程跟下面这个是一样的

        
        

         // Thread.currentThread().getName(); == Android的主线程，这个跟RxJava切的android主线程是一样的
        
        

        
        
      
      
      
      
    
    
    
    
  
  
  • 
    

    到此基础功能已经实现，为了使得用户友好，需要添加下列步骤

    
    
  
  
  
  

Rx 代码优化(一)：卡片式编程

• 
  

  什么是卡片式编程：

  
  
  
  
  • 因为Rx 响应式编程是依靠事件流动推进业务执行，那么我们可以在起点与终点之间添加卡片(拦截器)实现具体的业务功能
  
  
  
  


• 
  

  代码扩展：点击按钮后立即加载对话框，拿到图片并更新，随后关闭对话框

  
  
  
  
  • 
    

    整体流程：

    
    
    
    
    • 
      

      预处理：点击按钮后，立即加载对话框，开始准备事件分发

      
      

       //在终点订阅开始处加载对话框(预处理操作)
      
       // 订阅开始：一订阅就要显示对话框
      
       @Override
      
       public void onSubscribe(Disposable d) {
      
           //                                第一步：事件分发前预准备
      
           progressDialog = new ProgressDialog(Test.this);
      
           progressDialog.setTitle("开始下载");
      
           progressDialog.show();
      
       }
      
      

      
      
    
    
    • 
      

      第一步：回到起点，开始分发事件

      
      

       Observable.just(PATH)
      
      

      
      
    
    
    • 
      

      第二步：拦截器工作将String事件转为Bitmap事件(附带网络请求，从服务器拿到数据)

      
      
    
    
    • 
      

      第三步：抵达终点拿到事件处，更新UI

      
      

       //拿到事件：因为上一层是一个String类型的Path事件
      
       @Override
      
       public void onNext(@NonNull Bitmap bitmap) {
      
           image.setImageBitmap(bitmap);
      
       }
      
      

      
      
    
    
    
    
    
    
    
    • 
      

      第四步：抵达终点完成事件完成处，此时事件整体结束(Rx 编程结束尾巴)

      
      

       // 完成事件
      
       @Override
      
       public void onComplete() {
      
           //如果不为空那么就隐藏起来
      
           if (progressDialog != null)
      
           progressDialog.dismiss();
      
       }
      
      

      
      
    
    
    
    
  
  
  
  

• 
  

  这种编程方式成为卡片式编程

  
  
  
  
  • 
    

    好处：后期若需要添加功能，仅需在起点与重点之间添加对应的拦截器，在其中进行处理即可

    
    
  
  
  • 
    

    图片示例：一开始的

    
    
    
    
    • 事件流动顺序
    
    
    
    

    

    
    
    
    
    • 
      

      运行结果：

      
      

      

      
      
    
    
    
    
  
  
  
  
  
  
  
  • 
    

    图片示例：此时需要添加个需求，将下载下来的图片添加水印后再展示

    
    
    
    
    • 
      

      事件流动顺序

      
      

      

      
      
    
    
    • 
      

      添加代码：图片上绘制文字 加水印

      
      

       // 图片上绘制文字 加水印
      
       private final Bitmap drawTextToBitmap(Bitmap bitmap, String text, Paint paint, int paddingLeft, int paddingTop) {
      
           Bitmap.Config bitmapConfig = bitmap.getConfig();
      
       
      
           paint.setDither(true); // 获取跟清晰的图像采样
      
           paint.setFilterBitmap(true);// 过滤一些
      
           if (bitmapConfig == null) {
      
               bitmapConfig = Bitmap.Config.ARGB_8888;
      
           }
      
           bitmap = bitmap.copy(bitmapConfig, true);
      
           Canvas canvas = new Canvas(bitmap);
      
       
      
           canvas.drawText(text, paddingLeft, paddingTop, paint);
      
           return bitmap;
      
       }
      
      

      
      
    
    
    • 
      

      添加代码：在前面一个拦截器后添加

      
      

       .map(new Function<Bitmap, Bitmap>() {
      
           @Override
      
           public Bitmap apply(@NonNull Bitmap bitmap) throws Exception {
      
               //开始添加水印
      
               Paint paint = new Paint();
      
               paint.setTextSize(88);
      
               paint.setColor(Color.GREEN);
      
               return drawTextToBitmap(bitmap,"水印",paint,88,88);
      
           }
      
       })
      
      

      
      
    
    
    • 
      

      运行结果：从服务器获取图片并添加水印

      
      

      

      
      
    
    
    
    
  
  
  • 
    

    还可以添加：及时记录日志等功能

    
    
  
  
  
  

Rx 代码优化(二)：封装代码部分功能提升程序结构

• 封装线程分配

 //为上游(起点到拦截器结束)分配异步线程，为下游(拦截器结束位置到终点结束)分配android主线程

 private final static <UD> ObservableTransformer<UD,UD> opMixed(){

     return new ObservableTransformer<UD, UD>() {

         @NonNull

         @Override

         //分配线程

         public ObservableSource<UD> apply(@NonNull Observable<UD> upstream) {

             return upstream.subscribeOn(Schedulers.io()).

             observeOn(AndroidSchedulers.mainThread())

             //继续链式调用

             .map(new Function<UD, UD>() {

                 @Override

                 public UD apply(@NonNull UD ud) throws Exception {

                     Log.d(TAG,"日志记录")

                     return ud;

                 }

             })

 

             //还可以加卡片(拦截器)

             ;

 

         }

 

     };

 }

• 仅需在终点前调用封装好的库就行了

 ……

 //是需要在终点前调用封装好的东西就行了

 .compose(opMixed())

     //终点

     .subscribe(

Rx 编程完整代码：

 package com.xiangxue.rxjavademo.downloadimg;

 

 import android.app.ProgressDialog;

 import android.graphics.Bitmap;

 import android.graphics.BitmapFactory;

 import android.graphics.Canvas;

 import android.graphics.Paint;

 import android.os.Bundle;

 import android.os.Handler;

 import android.os.Message;

 import android.util.Log;

 import android.view.View;

 import android.widget.ImageView;

 

 import androidx.annotation.NonNull;

 import androidx.appcompat.app.AppCompatActivity;

 

 import com.xiangxue.rxjavademo.R;

 

 import java.io.InputStream;

 import java.net.HttpURLConnection;

 import java.net.URL;

 

 import io.reactivex.Observable;

 import io.reactivex.ObservableSource;

 import io.reactivex.ObservableTransformer;

 import io.reactivex.Observer;

 import io.reactivex.android.schedulers.AndroidSchedulers;

 import io.reactivex.disposables.Disposable;

 import io.reactivex.functions.Function;

 import io.reactivex.schedulers.Schedulers;

 

 public class Test extends AppCompatActivity {

 

     // 网络图片的链接地址，String类型的Path事件

     private final static String PATH = "http://pic1.win4000.com/wallpaper/c/53cdd1f7c1f21.jpg";

 

     // 弹出加载框

     private ProgressDialog progressDialog;

 

     // ImageView控件，用来显示结果图像

     private ImageView image;

 

     @Override

     protected void onCreate(Bundle savedInstanceState) {

         super.onCreate(savedInstanceState);

         setContentView(R.layout.activity_download);

         image = findViewById(R.id.image);

 

         // Thread.currentThread().getName(); == Android的主线程，这个跟RxJava切的android主线程是一样的

     }

 

     // 通过订阅将 起点 和 终点 关联起来

     public void rxJavaDownloadImageAction(View view) {

 

         // 起点

         Observable.just(PATH)  // 内部会分发  PATH Stirng  // TODO 第二步

         //流程中的卡片

         .map(new Function<String, Bitmap>() {

             @Override

             public Bitmap apply(@NonNull String s) throws Exception {

 

                 //处理网络请求：将String类型的Path事件处理为Bitmap实例

                 URL url = new URL(PATH);

                 HttpURLConnection httpURLConnection = (HttpURLConnection) url.openConnection();

                 int responseCode = httpURLConnection.getResponseCode();

                 if(responseCode == httpURLConnection.HTTP_OK){

                     InputStream inputStream = httpURLConnection.getInputStream();

                     Bitmap bitmap = BitmapFactory.decodeStream(inputStream);

                     return bitmap;

                 }

                 return null;

             }

         })

         //给上边代码分配异步线程，用于请求服务器

         .subscribeOn(Schedulers.io())

         //给下边的代码分配主线程，用于更新UI

         .observeOn(AndroidSchedulers.mainThread())

 

         //终点

         .subscribe(

             new Observer<Bitmap>() {

 

                 // 订阅开始：一订阅就要显示对话框

                 @Override

                 public void onSubscribe(Disposable d) {

                     //                                第一步：事件分发前预准备

                     progressDialog = new ProgressDialog(Test.this);

                     progressDialog.setTitle("开始下载");

                     progressDialog.show();

                 }

                 //拿到事件：因为上一层是一个String类型的Path事件

                 @Override

                 public void onNext(@NonNull Bitmap bitmap) {

                     image.setImageBitmap(bitmap);

                 }

 

                 // 错误事件

                 @Override

                 public void onError(Throwable e) {

 

                 }

 

                 // 完成事件

                 @Override

                 public void onComplete() {

                     //如果不为空那么就隐藏起来

                     if (progressDialog != null)

                     progressDialog.dismiss();

                 }

             });

 

     }

 

 

     // 图片上绘制文字 加水印

     private final Bitmap drawTextToBitmap(Bitmap bitmap, String text, Paint paint, int paddingLeft, int paddingTop) {

         Bitmap.Config bitmapConfig = bitmap.getConfig();

 

         paint.setDither(true); // 获取跟清晰的图像采样

         paint.setFilterBitmap(true);// 过滤一些

         if (bitmapConfig == null) {

             bitmapConfig = Bitmap.Config.ARGB_8888;

         }

         bitmap = bitmap.copy(bitmapConfig, true);

         Canvas canvas = new Canvas(bitmap);

 

         canvas.drawText(text, paddingLeft, paddingTop, paint);

         return bitmap;

     }

 }

正文

这是我在网上找到的一份 Android 键值对存储方案的性能测试对比（数越小越好）：

可以看出，DataStore 的性能比 MMKV 差了一大截。MMKV 是腾讯在 2018 年推出的，而 DataStore 是 Android 官方在 2020 年推出的，并且它的正式版在 2021 年 8 月才发布。一个官方发布的、更（gèng）新的库，性能竟然比不过比它早两年发布的、第三方的库。而且我们能看到，更离谱的是，它甚至还比不过 SharedPreferences 。Android 官方当初之所以推出 DataStore，就是要替代掉 SharedPreferences，并且主要原因之一就是 SharedPreferences 有性能问题，可是测试结果却是它的性能不如 SharedPreferences。

所以，这到底是为什么？

啊，我知道了——因为 Google 是傻逼！

SharedPreferences：不知不觉被嫌弃

大家好，我是扔物线朱凯。

键值对的存储在移动开发里非常常见。比如深色模式的开关、软件语言、字体大小，这些用户偏好设置，很适合用键值对来存。而键值对的存储方案，最传统也最广为人知的就是 Android 自带的 SharedPreferences。它里面的 -Preferences，就是偏好设置的意思，从名字也能看出它最初的定位。

SharedPreferences 使用起来很简单，也没什么问题，大家就这么用了很多年。——但！渐渐地，有人发现它有一个问题：卡顿，甚至有时候会出现 ANR。

MMKV：好快！

怎么办？换！2018 年 9 月，腾讯开源了一个叫做 MMKV 的项目。它和 SharedPreferences 一样，都是做键值对存储的，可是它的性能比 SharedPreferences 强很多。真的是强，很，多。在 MMKV 推出之后，很多团队就把键值对存储方案从 SharedPreferences 换到了 MMKV。

DataStore：官方造垃圾？

再然后，就是又过了两年，Google 自己也表示受不了 SharedPreferences 了，Android 团队公布了 Jetpack 的新库：DataStore，目标直指 SharedPreferences，声称它就是 Android 官方给出的 SharedPreferences 的替代品。

替代的理由，Android 团队列了好几条，但不出大家意料地，「性能」是其中之一：

也就是说，Android 团队直接抛弃了 SharedPreferences，换了个新东西来提供更优的性能。

但是，问题随之就出现了：大家一测试，发现这 DataStore 的性能并不强啊？跟 MMKV 比起来差远了啊？要知道，MMKV 的发布是比 DataStore 早两年的。DataStore 比人家晚两年发布，可是性能却比人家差一大截？甚至，从测试数据来看，它连要被它替代掉的 SharedPreferences 都比不过。这么弱？那它搞个毛啊！

Android 团队吭哧吭哧搞个新东西出来，竟然还没有市场上两年前就出现的东西强？这是为啥？

首先，肯定得排除「DataStore 是垃圾」这个可能性。虽然这猛一看、粗一想，明显就是 DataStore 垃圾、Google 傻逼，但是你仔细想想，这可能吗？

那如果不是的话，又是因为什么？——因为你被骗了。

MMKV 的一二三四

被谁骗了？不是被 MMKV 骗了，也不是具体的某个人。事情其实是这样的：

大家知道 MMKV 当初为什么会被创造出来吗？其实不是为了取代 SharedPreferences。

最早是因为微信的一个需求（来源：MMKV 组件现在开源了）：

微信作为一个全民的聊天 App，对话内容中的特殊字符所导致的程序崩溃是一类很常见、也很需要快速解决的问题；而哪些字符会导致程序崩溃，是无法预知的，只能等用户手机上的微信崩溃之后，再利用类似时光倒流的回溯行为，看看上次软件崩溃的最后一瞬间，用户收到或者发出了什么消息，再用这些消息中的文字去尝试复现发生过的崩溃，最终试出有问题的字符，然后针对性解决。

那么这个「时光倒流」应该怎么做，就成了问题的关键。我们要知道，程序中的所有变量都是存活在内存里的，一旦程序崩溃，所有变量全都灰飞烟灭。

所以要想实现「时光倒流」，就需要把想回溯的时光预先记录下来。说人话就是，我们需要把界面里显示的文字写到手机磁盘里，才能在程序崩溃、重新启动之后，通过读取文件的方式来查看。

更麻烦的是，这种记录的目标是用来回溯查找「导致程序崩溃的那段文字」，而同时，正是因为没有人知道哪段文字会导致程序崩溃才去做的记录，这就要求每一段文字都需要先写入磁盘、然后再去显示，这样才能保证程序崩溃的时候那段导致崩溃的文字一定已经被记录到了磁盘。

对吧？

这就有点难了。

我们来想象一下实际场景：

• 如果用户的微信现在处于一个对话界面中，这时候来了一条新的消息，这条消息里可能会包含微信处理不了的字符，导致微信的崩溃。

• 而微信为了及时地找出导致崩溃的字符或者字符串，所以给程序增加了逻辑：所有的对话内容在显示之前，先保存到磁盘再显示：

val bubble: WxTextView = ...

recordTextToDisk(text) // 显示之前，先保存到磁盘

bubble.setText(text)

• 那么你想一下，这个「保存到磁盘」的行为，我应该做成同步的还是异步的？
  
  
  
  
  • 为了不卡主线程，我显然应该做成异步的；
  
  
  • 但这是马上就要显示的文字，如果做成异步的，就极有可能在程序崩溃的时候，后台线程还没来得及把文字存到磁盘。这样的话，就无法进行回溯，从而这种记录也就失去了价值。
  
  
  
  
  
  
  
  • 所以从可用性的角度来看，我只能选择放弃性能，把它做成同步的，也就是在主线程进行磁盘的写操作。
  
  
  
  
  
  
  
  • 一次磁盘的写操作，花个一两毫秒是很正常的，三五毫秒甚至超过 10 毫秒也都是有可能的。具体的方案可以选择 SharedPreferences，也可以选择数据库，但不管选哪个，只要在主线程去完成这个写操作，这种耗时就绝对无法避免。一帧的时间也就 16 毫秒而已——那时候还没有高刷，我们就先不谈高刷了，一帧就是 16 毫秒——16 毫秒里来个写磁盘的操作，用户很可能就会感受到一次卡顿。
  
  
  
  


• 这还是相对比较好的情况。我们再想一下，如果用户点开了一个活跃的群，这个群里有几百条没看过的消息：
  
  
  
  • 那么在他点开的一瞬间，是不是界面中会显示出好几条消息气泡？这几条消息的内容，哪些需要记录到磁盘？全都要记录的，因为谁也知道哪一条会导致微信的崩溃，任何一条都是可能的。
  
  
  • 而如果把这几条消息都记录下来，是不是每条消息的记录都会涉及一次写磁盘的操作？这几次写磁盘行为，是发生在同一帧里的，所以在这一帧里因为记录文字而导致的主线程耗时，也会相比起刚才的例子翻上好几倍，卡顿时间就同样也会翻上好几倍。
  
  
  
  


• 还有更差的情况。如果用户看完这一页之后，决定翻翻聊天记录，看看大家之前都聊了什么：
  
  
  
  • 这时候，是不是上方每一个新的聊天气泡的出现，都会涉及一次主线程上的写磁盘行为？
  
  
  • 而如果用户把手猛地往下一滑，让上面的几十条消息依次滑动显示出来，这是不是就会导致一次爆发性的、集中式的对磁盘的写入？
  
  
  • 用户的手机，一定会卡爆。
  
  
  
  

所以这种「高频、同步写入磁盘」的需求，让所有的现有方案都变得不可行了：不管你是用 SharedPreferences 还是用数据库还是别的什么，只要你在主线程同步写入磁盘，就一定会卡，而且是很卡。

但是微信还是有高手，还是有能想办法的人，最终微信找到了解决方案。他们没有用任何的现成方案，而是使用了一种叫做内存映射（mmap()）的底层方法。
15.18.23@2x.png" loading="lazy">
它可以让系统为你指定的文件开辟一块专用的内存，这块内存和文件之间是自动映射、自动同步的关系，你对文件的改动会自动写到这块内存里，对这块内存的改动也会自动写到文件里。

更多更深的原理，说实话我也不是看得很懂，就不跟大家装了。但关键是，有了这一层内存作为中间人，我们就可以用「写入内存」的方式来实现「写入磁盘」的目标了。内存的速度多快呀，耗时几乎可以忽略，这样一下子就把写磁盘造成卡顿的问题解决了。

而且这个内存映射还有一点很方便的是，虽然这块映射的内存不是实时向对应的文件写入新数据，但是它在程序崩溃的时候，并不会随着进程一起被销毁掉，而是会继续有条不紊地把它里面还没同步完的内容同步到它所映射的文件里面去。

至于更下层的原理，我也说了，没看懂，你也别问我。

总之，有了这些特性，内存映射就可以让程序用往内存里写数据的速度实现往磁盘里写数据的实际效果，这样的话，「高频、同步写入磁盘」的需求就完美满足了。不管是用户打开新的聊天页面，还是滑动聊天记录来查看聊天历史，用内存映射的方式都可以既实时写入所有即将被渲染的文字，又不会造成界面的卡顿。这种性能，是 SharedPreferences 和数据库都做不到的——顺便提一句，虽然我总在提 SharedPreferences，但其实这种做法本来是先在 iOS 版的微信里应用的，后来才移植到了 Android 版微信。这也是我刚才说的，MMKV 的诞生并不是为了取代 SharedPreferences。

再后来，就是 2018 年，微信把这个叫做 MMKV 的项目开源了。它的名字，我猜就是直白的「Memory-Map based Key-Value（方案）」，基于内存映射的键值对。不过没有找作者求证，如果说错了欢迎指正。

在 MMKV 开源之后，很多团队就把键值对存储方案从 SharedPreferences 迁移到了 MMKV。为什么？因为它快呀。

MMKV 并不总是快如闪电

不过……事情其实没那么简单。MMKV 虽然大的定位方向和 SharedPreferences 一样，都是对于键值对的存储，但它并不是一个全方位更优的方案。

比如性能。我前面一直在说 MMKV 的性能更强，对吧？但事实上，它并不是任何时候都更强。由于内存映射这种方案是自行管理一块独立的内存，所以它在尺寸的伸缩上面就比较受限，这就导致它在写大一点的数据的时候，速度会慢，而且可能会很慢。我做了一份测试：

在连续 1000 次写入 Int 值的场景中，SharedPreferences 的耗时是 1034 毫秒，也就是 1 秒多一点；而 MMKV 只有 2 毫秒，简直快得离谱；而且最离谱的是，Android 官方最新推出的 DataStore 是 1215 毫秒，竟然比 SharedPreferences 还慢。这个前面我也提过，别人的测试也是这样的结果。

可是，SharedPreferences 是有异步 API 的，而 DataStore 是基于协程的。这就意味着，它们实际占用主线程的时间是可以低于这份测试出的时间的，而界面的流畅在意的正是主线程的时间消耗。所以如果我统计的不是全部的耗时，而是主线程的耗时，那么统计出的 SharedPreferences 和 DataStore 的耗时将会大幅缩减：

还是比 MMKV 慢很多，是吧？但是这是对于 Int类型的高频写入，Int 数据是很小的。而如果我把写入的内容换成长字符串，再做一次测试：

MMKV 就不具备优势了，反而成了耗时最久的；而这时候的冠军就成了 DataStore，并且是遥遥领先。这也就是我在开头说的：你可能被骗了。被谁骗了？被「耗时」这个词：我们关注性能，考量的当然是耗时，但要明确：是主线程的耗时。所以视频开头的那张图，是不具备任何参考意义的。
20.52.01@2x.png" loading="lazy">

但其实，它们都够快了

不过在换成了这种只看主线程的耗时的对比方案之后，我们会发现谁是冠军其实并不是很重要，因为从最终的数据来看，三种方案都不是很慢。虽然这半秒左右的主线程耗时看起来很可怕，但是要知道这是 1000 次连续写入的耗时，而我们在真正写程序的时候，怎么会一次性做 1000 次的长字符串的写入？所以真正在项目中的键值对写入的耗时，不管你选哪个方案，都会比这份测试结果的耗时少得多的，都少到了可以忽略的程度，这是关键。

各自的优势和弱点

那……既然它们的耗时都少到了可以忽略，不就是选谁都行？那倒不是。

MMKV 优势：写速度极快

我们来看一个 MMKV 官方给出的数据对比图：

从这张图看来，SharedPreferences 的耗时是 MMKV 的接近 60 倍。很明显，如果 SharedPreferences 用异步的 API 也就是 apply() 来保存的话，是不可能有这么差的性能的，这个一定是使用同步的 commit() 的性能来做的对比。那么为什么 MMKV 官方会这样做对比呢？这个又要说到它的诞生场景了：MMKV 最初的功能是在文字显示之前先把它记录到磁盘，然后如果接下来这个文字显示失败导致程序崩溃，稍后就可以从磁盘里把这段文字恢复出来，进行分析。而刚才我也说过，这种场景的特殊性在于，导致程序崩溃的文字往往是刚刚被记录下来，程序就崩溃了，所以如果采用异步处理的方案，就很有可能在文字还没来得及真正存储到磁盘的时候程序就发生了崩溃，那就没办法把它恢复出来进行分析了。因此这样的场景，是不能接受异步处理的方案的，只能同步进行。所以 MMKV 在意的，就是同步处理机制下的耗时，它不在意异步，因为它不接受异步。

而在同步处理的机制下，MMKV 的性能优势就太明显了。原因上面说过了，它写入内存就几乎等于写入了磁盘，所以速度巨快无比。这就是 MMKV 的优势之一：极高的同步写入磁盘的性能。

另外 MMKV 还有个特点是，它的更新并不像 SharedPreferences 那样全量重新写入磁盘，而是只把要更新的键值对写入，也就是所谓的增量式更新。这也会给它带来一些性能优势，不过这个优势并不算太核心，因为 SharedPreferences 虽然是全量更新的模式，但只要把保存的数据用合适的逻辑拆分到多个不同的文件里，全量更新并不会对性能造成太大的拖累。所以这个性能优势虽然有，但并不是关键。

还有刚才提到的，对于大字符串的场景，MMKV 的写入性能并不算快，甚至在我们的测试结果里是最慢的，对吧？这一点算是劣势。但是实事求是地说，我们在开发里不太可能连续不断地去写入大字符串吧？所以这个性能劣势虽然有，但也并不是关键。

整体来说，MMKV 比起 SharedPreferences 和 DataStore 来说，在写入小数据的情况下，具有很高的写入性能，这就让高频写入的场景非常适合使用 MMKV 来处理。因此如果你的项目里也有像微信的崩溃回溯的这种高频写入的需求，MMKV 就很可能是你的最佳方案。而如果你除了「高频写入」，还和微信一样要求「同步写入」，那 MMKV 就可能是你的唯一选择了。不过，如果你真的主要是存储大字符串的——例如你写的是一个文本编辑软件，需要保存的总是大块的文本——那么用 MMKV 不一定会更快了，甚至可能会比较慢。

MMKV 优势：支持多进程

另外，MMKV 还有一个巨大的优势：它支持多进程。

行业内也有很多公司选用 MMKV 并不是因为它快，而是因为它支持多进程。SharedPreferences 是不支持多进程的，DataStore 也不支持——从 DataStore 提交的代码来看，它已经在加入多进程的支持了，但目前还没有实现。所以如果你们公司的 App 是需要在多个进程里访问键值对数据，那么 MMKV 是你唯一的选择。

MMKV 劣势：丢数据

除了速度快和支持多进程这两个优势之外，MMKV 也有一个弱点：它会丢数据。

任何的操作系统、任何的软件，在往磁盘写数据的过程中如果发生了意外——例如程序崩溃，或者断电关机——磁盘里的文件就会以这种写了一半的、不完整的形式被保留。写了一半的数据怎么用啊？没法用，这就是文件的损坏。这种问题是不可能避免的，MMKV 虽然由于底层机制的原因，在程序崩溃的时候不会影响数据往磁盘的写入，但断电关机之类的操作系统级别的崩溃，MMKV 就没办法了，文件照样会损坏。对于这种文件损坏，SharedPreferences 和 DataStore 的应对方式是在每次写入新数据之前都对现有文件做一次自动备份，这样在发生了意外出现了文件损坏之后，它们就会把备份的数据恢复过来；而 MMKV，没有这种自动的备份和恢复，那么当文件发生了损坏，数据就丢了，之前保存的各种信息只能被重置。也就是说，MMKV 是唯一会丢数据的方案。

可能会有人好奇，为什么 MMKV 不做全自动的备份和恢复。我的猜测是这样的：MMKV 底层的原理是内存映射，而内存映射这种方式，它从内存往磁盘里同步写入的过程并不是实时的，也就是说并不是每次我们写入到映射的内存里就会立即从这块内存写入到磁盘，而是会有一些滞后。而如果我们要做全自动的备份，那就需要每次往内存里写入之后，立即手动把内存里最新的数据同步到磁盘。但这就和 MMKV 的定位不符了：因为这种「同步」本质上就是一次从内存到磁盘的写入，并且是同步的写入；而 MMKV 是要高频写入的，如果在高频写入内存的同时，还要实时地把数据从内存同步到磁盘，就会一下子把写入速度从内存级别下降到磁盘级别，MMKV 的性能优势也就荡然无存了。所以从原理上，自动备份是个很难实现的需求，因为它和 MMKV 的定位是矛盾的。不过正好 MMKV 所要记录的这些要显示的文字，也并不是不能丢失的内容——真要是丢了就丢了呗，反正是崩溃日志，丢了就不要了，我下次启动程序之后继续记录就是了——所以既然要求必须高频写入而导致很难实现自动备份，并且也确实能接受因为不做自动备份而导致的数据损坏，那就干脆不做自动备份了。不过这也是我猜的啊，大家如果有不同意见欢迎留言评论指正。

所以如果你要用 MMKV，一定要记得只能用它来存可以接受丢失、不那么重要的数据。或者你也可以选择对数据进行定期的手动备份——全自动的实时备份应该是会严重影响性能的，不过我没试过，你如果有兴趣可以试试。另外据我所知，国内在使用 MMKV 的团队里，几乎没有对 MMKV 数据做了备份和恢复的处理的。

那么说到这里，很容易引出一个问题：微信自己就不怕丢数据吗？（大字：微信就不怕丢数据？）关于这一点，我相信，微信绝对不会把用户登录状态相关的信息用 MMKV 保存并且不做任何的备份，因为这一定会导致每天都会有一些用户在新一次打开微信的时候发现自己登出了。这会是非常差的用户体验，所以微信一定不会让这种事发生。至于一些简单的用户设置，那我就不清楚了。比如深色主题重要吗？这是个不好说的事情：某个用户在打开软件的时候，发现自己之前设置的深色主题失效了，软件突然变回了亮色方案，这肯定是不舒服的事；但我们要知道，MMKV 的文件损坏终归是个概率极低的事件，所以偶尔地发生一次这样的事件在产品的角度是否可以接受，那可能是需要产品团队自身做一个综合考量的事了。对于不同的产品和团队，也许不可接受，也许无伤大雅。而对于你所开发的产品应该是怎样的判断，就得各位自己和团队去商量了。所以像深色主题这种「可以重要也可以不重要」的信息，用不用 MMKV 保存、用的时候做不做备份，大家需要自己去判断。

总之，大家要知道这件事：MMKV 是有数据损坏的概率的，这个在 MMKV 的官方文档就有说明：MMKV 的 GitHub wiki 页面显示，微信的 iOS 版平均每天有 70 万次的数据校验不通过（即数据损坏）。这还是 2020 年的数据，现在可能会更多。

所以我们在使用 MMKV 的时候，一定要考虑到这个问题，你要知道这件事。至于具体的应对，是接受它、坏就坏了，还是要认真应对、做好备份和恢复，这就是大家自己的决策了。

SharedPreferences 的优势：不丢数据

好，那么说完了 MMKV，我来说一下 SharedPreferences，这个最传统的方案。

它有什么优势呢？——它没有优势。跟 MMKV 比起来，它不会丢数据，这个倒是它比 MMKV 强的地方，但是我觉得更应该归为 MMKV 的劣势，而不是 SharedPreferences 的优势，因为只有 MMKV 会丢数据嘛，是吧？

不过不管是这个的优势还是那个的劣势，如果你不希望丢数据，并且也不想花时间去做手动的备份和恢复，同时对于 MMKV 的超高写入性能以及多进程支持都没有需求，那你其实更应该选择 SharedPreferences，而不是 MMKV。对吧？

SharedPreferences 的劣势：卡顿

但更进一步地说：如果你选择了 SharedPreferences，那么你更应该考虑 DataStore。因为 DataStore 是一个完全超越了 SharedPreferences 的存在。你看 SharedPreferences 和 MMKV 它俩是各有优劣对吧？虽然 MMKV 几乎完胜，但是毕竟 SharedPreferences 不会丢数据呀，所以它俩是各有优劣的。但当 DataStore 和 SharedPreferences 比起来，那就是 DataStore 完胜了。这其实也很合理，因为 DataStore 被创造出来，就是用于替代掉 SharedPreferences 的；而 MMKV 不一样，它的诞生有它独特的使命，它是为了「高频同步写入」而诞生的，所以不能全角度胜过 SharedPreferences 也很正常。

我们还说回 DataStore。DataStore 被创造出来的目标就是替代 SharedPreferences，而它解决的 SharedPreferences 最大的问题有两点：一是性能问题，二是回调问题。

先说性能问题：SharedPreferences 虽然可以用异步的方式来保存更改，以此来避免 I/O 操作所导致的主线程的耗时；但在 Activity 启动和关闭的时候，Activity 会等待这些异步提交完成保存之后再继续，这就相当于把异步操作转换成同步操作了，从而会导致卡顿甚至 ANR（程序未响应）。这是为了保证数据的一致性而不得不做的决定，但它也确实成为了 SharedPreferences 的一个弱点。而 MMKV 和 DataStore 用不同的方式各自都解决了这个问题——事实上，当初 MMKV 被公布的时候之所以在业界有相当大的反应，就是因为它解决了 SharedPreferences 的卡顿和 ANR 的问题。

不过有一点我的观点可能和一些人不同：SharedPreferences 所导致的卡顿和 ANR，其实并不是个很大的问题。它和 MMKV 的数据损坏一样，都是非常低概率的事件。它俩最大的区别在于其实是政治上的：SharedPreferences 的卡顿很容易被大公司的性能分析后台监测到，所以不解决的话会扣绩效，而解决掉它会提升绩效；而 MMKV 的数据损坏是无法被监测到的，所以……哈？事实上，大家想一下：卡顿和数据损坏，哪个更严重？当然是数据损坏了，对吧。

其实除了写数据时的卡顿，SharedPreferences 在读取数据的时候也会卡顿。虽然它的文件加载过程是在后台进行的，但如果代码在它加载完成之前就去尝试读取键值对，线程就会被卡住，直到文件加载完成，而如果这个读取的过程发生在主线程，就会造成界面卡顿，并且数据文件越大就会越卡。这种卡顿，不是 SharedPreferences 独有的，MMKV 也是存在的，因为它初始化的过程同样也是从磁盘里读取文件，而且是一股脑把整个文件读完，所以耗时并不会比 SharedPreferences 少。而 DataStore，就没有这种问题。DataStore 不管是读文件还是写文件，都是用的协程在后台进行读写，所有的 I/O 操作都是在后台线程发生的，所以不论读还是写，都不会卡主线程。

简单来说，SharedPreferences 会有卡顿的问题，这个问题 MMKV 解决了一部分（写时的卡顿），而 DataStore 完全解决了。所以如果你的目标在于全方位的性能，那么你应该考虑的是 DataStore，因为它是唯一完全不会卡顿的。

SharedPreferences 的劣势：回调

DataStore 解决的 SharedPreferences 的另一个问题就是回调。SharedPreferences 如果使用同步方式来保存更改（commit())，会导致主线程的耗时；但如果使用异步的方式，给它加回调又很不方便，也就是如果你想做一些「等这个异步提交完成之后再怎么怎么样」的工作，会很麻烦。

而 DataStore 由于是用协程来做的，线程的切换是非常简单的，你就把「保存完成之后做什么」直接写在保存代码的下方就可以了，很直观、很简单。

对比来说，MMKV 虽然没有使用协程，但是它太快了，所以大多数时候并不需要切线程也不会卡顿。总之，在这件事上，只有 SharedPreferences 最弱。

总结

区别大概就是这么些区别了，大致总结一下就是：

如果你有多进程支持的需求，MMKV 是你唯一的选择；如果你有高频写入的需求，你也应该优先考虑 MMKV。但如果你使用 MMKV，一定要知道它是可能丢失数据的，不过概率很低就是了，所以你要在权衡之后做好决定：是自行实现数据的备份和恢复方案，还是直接接受丢数据的事实，在每次丢失数据之后帮用户把相应的数据进行初始化。当然了，一个最鸡贼的做法是：反正数据监测不会监测到 MMKV 的数据丢失，又不影响绩效，那就不管它呗！不过我个人是不太赞同这种策略的，有点不负责哈。

另外，如果你没有多进程的需求，也没有高频写入的需求，DataStore 作为性能最完美的方案，应该优先被考虑。因为它在任何时候都不会卡顿，而 MMKV 在写大字符串和初次加载文件的时候是可能会卡顿的，而且初次加载文件的卡顿不是概率性的，只要文件大到了引起卡顿的程度，就是 100% 的卡顿。不过如果你的团队没有在用协程，甚至没有在用 Kotlin，那 DataStore 也暂时不适合你们，因为它是完全依赖 Kotlin 协程来实现和使用的。

哦对了，其实我今天说的 DataStore 只是面向简单键值对存储的 DataStore 方案，它的全称叫 Preferences DataStore，而 DataStore 还有用于保存结构化数据的方案，叫做 Proto DataStore，它内部用的是 Protocol Buffer 作为数据结构的支持。但是这个有点跑题，我就不展开了。

至于 SharedPreferences 嘛，在这个时代，它真的可以被放弃了。除非——像我刚说的——如果你们还没在用协程，那 SharedPreferences 可能还能苟延残喘一下。

前言

招聘季节一般都在金三银四，或者金九银十。最近在这五六月份，陆陆续续面试了十几个高级前端。有一套考察算法的小题目。后台返回一个扁平的数据结构，转成树。

我们看下题目：打平的数据内容如下：

let arr = [

    {id: 1, name: '部门1', pid: 0},

    {id: 2, name: '部门2', pid: 1},

    {id: 3, name: '部门3', pid: 1},

    {id: 4, name: '部门4', pid: 3},

    {id: 5, name: '部门5', pid: 4},

]

输出结果

[

    {

        "id": 1,

        "name": "部门1",

        "pid": 0,

        "children": [

            {

                "id": 2,

                "name": "部门2",

                "pid": 1,

                "children": []

            },

            {

                "id": 3,

                "name": "部门3",

                "pid": 1,

                "children": [

                    // 结果 ,,,

                ]

            }

        ]

    }

]

我们的要求很简单，可以先不用考虑性能问题。实现功能即可，回头分析了面试的情况，结果使我大吃一惊。

10%的人没思路，没碰到过这种结构

60%的人说用过递归，有思路，给他个笔记本，但就是写不出来

20%的人在引导下，磕磕绊绊能写出来

剩下10%的人能写出来，但性能不是最佳

感觉不是在招聘季节遇到一个合适的人真的很难。

接下来，我们用几种方法来实现这个小算法

什么是好算法，什么是坏算法

判断一个算法的好坏，一般从执行时间和占用空间来看,执行时间越短，占用的内存空间越小，那么它就是好的算法。对应的，我们常常用时间复杂度代表执行时间，空间复杂度代表占用的内存空间。

时间复杂度

时间复杂度的计算并不是计算程序具体运行的时间，而是算法执行语句的次数。

随着n的不断增大，时间复杂度不断增大，算法花费时间越多。 常见的时间复杂度有

• 常数阶O(1)


• 对数阶O(log2 n)


• 线性阶O(n)


• 线性对数阶O(n log2 n)


• 平方阶O(n^2)


• 立方阶O(n^3)


• k次方阶O(n^K)


• 指数阶O(2^n)

计算方法

1. 选取相对增长最高的项


2. 最高项系数是都化为1


3. 若是常数的话用O(1)表示

举个例子：如f(n)=3*n^4+3n+300 则 O(n)=n^4

通常我们计算时间复杂度都是计算最坏情况。计算时间复杂度的要注意的几个点

• 如果算法的执行时间不随n的增加而增长，假如算法中有上千条语句，执行时间也不过是一个较大的常数。此类算法的时间复杂度是O(1)。 举例如下：代码执行100次，是一个常数，复杂度也是O(1)。

    let x = 1;

    while (x <100) {

     x++;

    }

• 有多个循环语句时候，算法的时间复杂度是由嵌套层数最多的循环语句中最内层语句的方法决定的。举例如下：在下面for循环当中，外层循环每执行一次，内层循环要执行n次，执行次数是根据n所决定的，时间复杂度是O(n^2)。

  for (i = 0; i < n; i++){

         for (j = 0; j < n; j++) {

             // ...code

         }

     }

• 循环不仅与n有关，还与执行循环判断条件有关。举例如下：在代码中，如果arr[i]不等于1的话，时间复杂度是O(n)。如果arr[i]等于1的话，循环不执行，时间复杂度是O(0)。

    for(var i = 0; i<n && arr[i] !=1; i++) {

    // ...code

    }

空间复杂度

空间复杂度是对一个算法在运行过程中临时占用存储空间的大小。

计算方法：

1. 忽略常数，用O(1)表示


2. 递归算法的空间复杂度=(递归深度n)*(每次递归所要的辅助空间)

计算空间复杂度的简单几点

• 仅仅只复制单个变量，空间复杂度为O(1)。举例如下：空间复杂度为O(n) = O(1)。

   let a = 1;

   let b = 2;

   let c = 3;

   console.log('输出a,b,c', a, b, c);

• 递归实现，调用fun函数，每次都创建1个变量k。调用n次，空间复杂度O(n*1) = O(n)。

    function fun(n) {

       let k = 10;

       if (n == k) {

           return n;

       } else {

           return fun(++n)

       }

    }

不考虑性能实现，递归遍历查找

主要思路是提供一个递getChildren的方法，该方法递归去查找子集。
就这样，不用考虑性能，无脑去查，大多数人只知道递归，就是写不出来。。。

/**

 * 递归查找，获取children

 */

const getChildren = (data, result, pid) => {

  for (const item of data) {

    if (item.pid === pid) {

      const newItem = {...item, children: []};

      result.push(newItem);

      getChildren(data, newItem.children, item.id);

    }

  }

}



/**

* 转换方法

*/

const arrayToTree = (data, pid) => {

  const result = [];

  getChildren(data, result, pid)

  return result;

}

从上面的代码我们分析，该实现的时间复杂度为O(2^n)。

不用递归，也能搞定

主要思路是先把数据转成Map去存储，之后遍历的同时借助对象的引用，直接从Map找对应的数据做存储

function arrayToTree(items) {

  const result = [];   // 存放结果集

  const itemMap = {};  // 

    

  // 先转成map存储

  for (const item of items) {

    itemMap[item.id] = {...item, children: []}

  }

  

  for (const item of items) {

    const id = item.id;

    const pid = item.pid;

    const treeItem =  itemMap[id];

    if (pid === 0) {

      result.push(treeItem);

    } else {

      if (!itemMap[pid]) {

        itemMap[pid] = {

          children: [],

        }

      }

      itemMap[pid].children.push(treeItem)

    }



  }

  return result;

}

从上面的代码我们分析，有两次循环，该实现的时间复杂度为O(2n)，需要一个Map把数据存储起来，空间复杂度O(n)

最优性能

主要思路也是先把数据转成Map去存储，之后遍历的同时借助对象的引用，直接从Map找对应的数据做存储。不同点在遍历的时候即做Map存储,有找对应关系。性能会更好。

function arrayToTree(items) {

  const result = [];   // 存放结果集

  const itemMap = {};  // 

  for (const item of items) {

    const id = item.id;

    const pid = item.pid;



    if (!itemMap[id]) {

      itemMap[id] = {

        children: [],

      }

    }



    itemMap[id] = {

      ...item,

      children: itemMap[id]['children']

    }



    const treeItem =  itemMap[id];



    if (pid === 0) {

      result.push(treeItem);

    } else {

      if (!itemMap[pid]) {

        itemMap[pid] = {

          children: [],

        }

      }

      itemMap[pid].children.push(treeItem)

    }



  }

  return result;

}

从上面的代码我们分析，一次循环就搞定了，该实现的时间复杂度为O(n)，需要一个Map把数据存储起来，空间复杂度O(n)

小试牛刀

从我们的测试结果来看，随着数量的增大，递归的实现会越来越慢，基本成指数的增长方式。

什么是Channel

Channel API是用来在多个协程之间进行通信的，并且它是并发安全的。它的概念有点与BlockQueue相似，都遵循先进先出的规则，差别就在于Channel使用挂起的概念替代了BlockQueque中的阻塞。使用它我们可以很轻易的构建一个生产者消费者模型。并且Channel支持任意数量的生产者和消费者

从源码我们可以看出Channel主要实现了两个接口

public interface Channel<E> : SendChannel<E>, ReceiveChannel<E> {}



interface SendChannel<in E> {

    suspend fun send(element: E)

    public fun trySend(element: E): ChannelResult<Unit>

    fun close(): Boolean

    //...

}



interface ReceiveChannel<out E> {

    suspend fun receive(): E

    public fun tryReceive(): ChannelResult<E>

    fun cancel(cause: CancellationException? = null)

    // ...

}

• SendChannel: 用于添加元素到通道中和关闭通道;


• ReceiveChannel:主要用于接收通道中的元素

你会发现SendChannel中的send()和ReceiveChannel中的receive方法都是挂起函数，为什么会怎么设计，在通道中如果存储元素的数量达到了我们设置的通道存储大小的时候，再通过send()方法往通道中发送数据，就会挂起，直至通道有空闲空间是才会将挂起的发送动作恢复。同理，如果我们的通道中没有可用的元素时，这个时候我们通过receive方法去接收数据，就会发现此操作将会被挂起，直到通道中存在可用元素为止。

如果我们需要在非挂起函数中去接收和发送数据，我们可以使用trySend和tryReceive,这两个操作都会立即返回一个ChannelResult,结果中会包含此次操作的的结果以及数据，但是这两个操作只能使用在容量有限的通道上。

Channel的使用

下面我们通过构建一个简单的消费者和生产者模型了解以下Channel的使用

suspend fun main(): Unit = runBlocking {

        val channel = Channel<String>()

	//生产者协程

         launch { 

            channel.send("Hello World!")

         }

        //消费者协程

        launch {

            val received = channel.receive()

            println(received)

    	}

    }

}

上面这种创建Channel的方式，在我们使用完通道之后很容易忘记一个close操作，特别是如果其中一个生产者协程应为某些情况发生异常，停止了生产，那么消费者协程会一直挂起等待生产者生产完成进行消费。所以我们可以使用协程的一个扩展方法produce，当协程发生异常，或者是协程完成时，它会自动去调用close方法，并且它会返回一个ReceiveChannel,下面我们就来看看怎么使用

runBlocking {

    val channel = produce {

        listOf("apple","banana","orange").forEach {

             send(it)

        }

    }

	for (element in channel){

         print(element)

     }

}

Channel有哪些

我们在使用Channel函数在创建通道时，我们会指定通道的容量大小，然后会根据容量创建不同类型的通道

public fun <E> Channel(

    capacity: Int = RENDEZVOUS,

    onBufferOverflow: BufferOverflow = BufferOverflow.SUSPEND,

    onUndeliveredElement: ((E) -> Unit)? = null

): Channel<E> =

    when (capacity) {

        RENDEZVOUS -> {

            if (onBufferOverflow == BufferOverflow.SUSPEND)

                RendezvousChannel(onUndeliveredElement) 

            else

                ArrayChannel(1, onBufferOverflow, onUndeliveredElement)

        }

        CONFLATED -> {

		   require(onBufferOverflow == BufferOverflow.SUSPEND) {

                "CONFLATED capacity cannot be used with non-default onBufferOverflow"

            }

            ConflatedChannel(onUndeliveredElement)

        }

        UNLIMITED -> LinkedListChannel(onUndeliveredElement)

        BUFFERED -> ArrayChannel( 

            if (onBufferOverflow == BufferOverflow.SUSPEND)

            	CHANNEL_DEFAULT_CAPACITY

            else 1,

            onBufferOverflow, onUndeliveredElement

        )

        else -> {

            if (capacity == 1 && onBufferOverflow == BufferOverflow.DROP_OLDEST)

                ConflatedChannel(onUndeliveredElement) 

            else

                ArrayChannel(capacity, onBufferOverflow, onUndeliveredElement)

        }

    }

可以从以上源码看出我们的通道主要分为4种类型

• RENDEZVOUS ：默认容量为0，且生产者和消费者只有在相遇时才能进行数据的交换


• CONFLATED ：容量大小为1,且每个新元素会替换前一个元素


• UNLIMITED： 无限容量缓冲区且send永不挂起的通道。


• BUFFERED ： 默认容量为64，且在溢出时挂起的通道，可以通过设置JVM的 DEFAULT_BUFFER_PROPERTY_NAME来覆盖它

我们从Channel源码看出，Channel在创建时还会指定缓冲区溢出时的策略

public enum class BufferOverflow {

	//缓冲区满时，将操作进行挂起，等待缓冲区有空间

    SUSPEND,

	//删除旧值

    DROP_OLDEST,

	//将即将要添加进缓冲区的值删除

    DROP_LATEST

}

Channel函数还有一个可选参数onUndeliveredElement,接收一个Lambda在元素被发送且未被消费时调用，我们通常使用它来关闭一些该通道发送的资源。

在Channel内部结构种维护的缓冲区结构除了ArrayChannel内部自己维护了一个数组作为缓冲区，其余的都是使用AbstractSendChannel的链表作为缓冲区

那么我们将两个管道的内容合并成一个呢

fun <T> CoroutineScope.fanIn(

    channels: List<ReceiveChannel<T>>

): ReceiveChannel<T> = produce {

    for (channel in channels) {

        launch {

            for (elem in channel) {

                send(elem)

            }

        }

    }

}

扇出：多个协程从单个通道接收数据。为了正确地接收数据，我们应该使用for循环(使用consumeEach是不安全的)。

扇入：多个协程对单个通道发送数据

Key用来干嘛

Flutter中的Key，一直都是作为一个可选参数在很多Widget中出现，那么它到底有什么用，它到底怎么用，本篇文章将带你从头到尾，好好理解下，Flutter中的Key。

我们首先来看下面这个Demo：

Column(

  mainAxisAlignment: MainAxisAlignment.center,

  children: [

    Container(

      width: 100,

      height: 100,

      color: Colors.red,

    ),

    Container(

      width: 100,

      height: 100,

      color: Colors.blue,

    ),

  ],

)

展示为两个不同颜色的方块。

问题1

这时候，如果我们在代码中交换两个Container的位置，Hot reload之后，它们的位置会发生改变吗？

下面我们把Demo修改一下，将Container抽取出来，并在中间放一个Text用来做计时器，并改为StatefulWidget，代码如下。

class KeyBox extends StatefulWidget {

  final Color color;



  KeyBox(this.color);



  @override

  _KeyBoxState createState() => _KeyBoxState();

}



class _KeyBoxState extends State<KeyBox> {

  var counter = 0;



  @override

  Widget build(BuildContext context) {

    return Container(

      width: 100,

      height: 100,

      color: widget.color,

      child: Center(

        child: TextButton(

          onPressed: () {

            setState(() => counter++);

          },

          child: Text(

            counter.toString(),

            style: const TextStyle(fontSize: 60),

          ),

        ),

      ),

    );

  }

}

Column(

  mainAxisAlignment: MainAxisAlignment.center,

  children: [

    KeyBox(Colors.yellow),

    KeyBox(Colors.green),

  ],

)

这样当我们点击计时器工作之后，展示如下。

问题2

这时候，如果我们在代码中交换两个Container的位置，Hot reload之后，它们的数字会发生改变吗？

问题3

如果我们删掉第一个Widget，Hot reload之后，显示的是数字几？

问题4

如果我们再重新把删掉的Widget加回来，Hot reload之后，又会如何显示？

问题5

如果在问题2的基础上，给第一个Widget外新增一个Center，那么又会如何显示呢？

如果你能完全回答上面的这几个问题并知道为什么，那么恭喜你，看完这篇文章，你会浪费十几分钟，当然，如果你不清楚，那么这十几分钟的时间，将给你带来不小的收益。

Key是什么

Flutter通过Widget来渲染UI，那么它是如何区分上面的两个不同颜色的Container的呢？通过颜色吗？当然不是，如果Container的颜色相同，那岂不是无法区分了？

所以，Key就成了Flutter区分不同Widget的依据，这就好比是Android中布局的ViewID。

知道Key是什么还不够，我们还得知道，我们为什么需要Key，首先，我们来看下上面的三个问题。

对于问题1，这个应该很简单了，Container是StatelessWidget，所以每次Hot reload都会重新build，因此颜色肯定会发生互换，这个很好理解。

那么对于问题2呢？StatelessWidget改成了StatefulWidget，这次再交换两个Widget的位置，你可以发现，虽然颜色互换了，但是数字没变。

要怎么解决这个问题呢？这就需要用到Key了，我们给KeyBox增加一个Key的参数。

新的Flutter Lint已经会提示你构造函数需要增加key的可选参数了。

const KeyBox(this.color, {Key? key}) : super(key: key);

在使用的地方，传入ValueKey即可。

KeyBox(Colors.yellow, key: ValueKey(2)),

SizedBox(height: 20),

KeyBox(Colors.cyan, key: ValueKey(1)),

这时候你再切换两个Container的位置，数字就会跟着变换了。

Key的原理

Key实际上是Flutter用来标记Widget的唯一标识，但是为什么需要Key，就要从Flutter的渲染流程上说起了。

Widget作为Flutter中的不可变数据，是作为渲染的数据类而存在的，它实际上就是内容的配置表，根据View的树形结构，自然而然模拟出了一个Widget Tree的概念。

Widget在运行时会创建Element实例，这些Element和Widget也组成了一一对应的关系，对于StatefulWidget来说，Widget中包含了组件的外观、位置等信息，而Element中，包含了State信息，这也是Flutter的核心原理。所以，在上面的Demo中，Counter作为State，被保存在Element中，而颜色，被保存在Widget中。

Widget和Element分离之后，如果修改颜色等Widget属性，那么可以直接创建新的Widget替换旧的Widget，同时还可以保留Element中的数据，因为创建Widget的成本是很低的，而Element则会高很多，所以Element会持续尽可能长的时间。

那么在Widget被改变之后，Element是如何和Widget进行关联的呢？这就需要两个东西了：

• runtimeType


• Key

所以Element会先对比当前新的Widget Tree中的新元素，是否跟当前Element的类型一致，如果不一致，那么说明Element已经无效了，只能重新创建，如果类型一致，那么就需要进一步判断Key了。

问题2的原因

所以，在问题2中，由于两个Widget的类型并没有发生变化，而又没有Key，所以，Widget被重新创建后，与原来的Element又关联起来了，看上去就是只修改了颜色。

那么在问题2的解法中，我们给Widget增加了Key，当我们调换两个Widget的位置时，虽然类型没有改变，但是Key发生了改变，Element在原来的位置找不到对应的Widget，那么这时候，它会选择在当前层级下，继续搜索这个Key。

这里要注意，Element只会在当前层级下搜索，如果这个Key的Widget被移入了其它层级，那么也是无法找到的，在问题2的场景下，由于只是交换了两个Widget的顺序，所以Element会在后面找到之前Key的Widget，同理，下一个Element也会找到，所以，两个Widget都被关联起来了，所以State也显示正确了。

问题3的原因

那么在问题3中，我们删除了第一个Widget，当没有Key时，Element会在Widget Tree中搜索，当它发现第二个Key类型是一样的时，它就以为它找到了，而第二个Element，因为找不到Widget，就销毁了。最终的效果就是剩下第二个Box的颜色和第一个Box的数字。

那么如果有Key呢？有Key的话，就不会找错了啊，所以自然能够对应上，与我们预想的也就是一样的了。

问题4的原因

理解了问题3，那么问题4就好理解了。当我们在开头创建同一个类型的Widget时，Element会把这个新增的Widget当作是以前的Widget，因为它们类型相同，所以Element被关联到了这个新的Widget，而另一个Widget发现已经没有Element了，所以会选择新建一个Element，这时候，数字就是默认值0了。

问题5的原因

对于问题5来说，实际上就是Element的搜寻机制，前面解释了，Element只会在当前层级进行搜索，所以Center的加入，改变了Widget的层级，Element无法对应了，所以它也选择了消耗重建，所以第一个Widget会显示默认值0。

但是要注意的是，如果类型不一致，那么Flutter会直接判断不相同，从而直接消耗重建，所以，在这些问题里，如果在KeyBox之间插上一些不同类型的Widget，那么就瞬间破防了，演示的效果就完全不同了。

Key有哪些Key

Key从整体上来说，分为两种，即：

• Local Key：分为Value Key、Object Key和Unique Key


• Global Key

Local Key顾名思义，指的是在当前Widget层级下，有唯一的Key属性，而Global Key，则是在全局APP中，具有唯一性。Global Key的性能会比Local Key差很多。

Value Key

在前面的Demo中，我们给KeyBox增加了Key之后，Widget在修改、移动之后，Element就可以正确的找到对应的Widget了，这里我们使用的是Value Key。

Value Key，顾名思义，就是使用Value来对Key做标识的Key，例如我们在Demo中使用的，ValueKey(1)，value可以是任意类型，这里是1，其实更符合的场景，应该是用Color，或者是更加具有语义性的value来作为Key的value。

Value Key在同一层级下需要具有唯一性，所以当两个KeyBox都设置成ValueKey(1)时，程序就会报错，告诉你Key重复了。

Object Key

Object Key与Value Key类似，但是又不完全一样，Value Key对比的是Value，Value相等，就是相等，而Object Key，对比的是实例，实例相同，才是相等，就好比一个Java中的equals，一个是「==」。我们看下Object Key的源码就一目了然了。

@override

bool operator ==(Object other) {

  if (other.runtimeType != runtimeType)

    return false;

  return other is ObjectKey

      && identical(other.value, value);

}

假如我们有一个自定义的Class，重写了它的==函数，那么用Value Key，new两个同样的对象，它们就是相等的，而Object Key，则不相等，原因就是一个比较的是值，一个比较的是引用。

Unique Key

Unique Key自己都说了，它是独一无二的，也就是说，Unique Key只和自己相等，任意创建多个Unique Key，都是不相等的，相当于唯一标识了。

如果在Build函数中创建Unique Key，那么这个Key在大部分场景下就没有意义，因为Hot reload时，Build函数会重建，所以Unique Key被重建，而且和之前也不相等。

这就很奇怪了，这玩意有什么用呢？

用处确实不多，但一旦用到，就必须得用，例如下面这个例子。

假如我们要用AnimatedSwitcher来实现切换时的动画效果，这时候，我们需要让每次改变都要执行动画，那么这里就可以使用Unique Key，强制每一次都是新的Widget，这样才能有动画效果。

那么另一种使用场景，就是在无法使用Value Key和Object Key的时候使用，但是这时候，需要将Unique Key定义在Build函数之外，这样Unique Key只会创建一次，从而保证唯一性的同时，不用去创建value和Object。

Global Key

Global Key全局唯一且只和自己相等，还记得之前Element在关联新变化的Widget时是怎么比较Key的吗——Element为了效率问题，只会在当前层级下进行寻找，所以，在问题5中，一旦我们修改了某个Widget的层级，那么Element就会消耗重建，那么如果使用了Global Key呢？当Key的类型是Global Key时，Element会不惜代价在全局寻找这个Key，这也是为什么Global Key的效率会比较低的原因。

那么有了Global Key，即使Widget Tree发生了改变，也依然可以找到这个Widget进行关联，但是要注意的是，Global Key需要定义在Build函数之外，否则每次都会重新创建Global Key，那就没有意义了。

除此之外，Global Key还有一个作用，那就是给一个Widget增加一个全局标识，这样有点像命令式编程的意思，类似Android中的FindViewByID，通过Global Key就可以找到当前标记的这个Widget，从而获取它的一些相关信息。

final count = (globalKey.currentState as _KeyBoxState).counter;

print('count: $count');

final color = (globalKey.currentWidget as KeyBox).color;

print('color: $color');

final size = (globalKey.currentContext?.findRenderObject() as RenderBox).size;

print('size: $size');

final position = (globalKey.currentContext?.findRenderObject() as RenderBox).localToGlobal(Offset.zero);

print('position: $position');



// output

flutter: count: 0

flutter: color: MaterialColor(primary value: Color(0xff4caf50))

flutter: size: Size(100.0, 100.0)

flutter: position: Offset(145.0, 473.5)

由此可见，通过Global Key，我们可以拿到State、Widget、Element（Context）以及通过Element关联的RenderObject，这样就可以获取Widget中的一些配置参数，State中的数据变量，以及RenderObject中的绘制信息，例如尺寸、位置、约束等等。

一、启动运行乱码

没错，启动一个demo,遇到坑了，如图所示

点击Android Studio上方运行按钮，程序启动之后汉字文字显示乱码，这是由于flutter web有三种渲染模式，auto 、html 和 canvaskit，点击运行按钮（flutter build web命令）默认的渲染模式为auto，这种模式在移动端使用html渲染，在pc端使用canvaskit渲染。

解决办法 1： 用命令行运行，并指定渲染模式,就能解决问题。

// 指定渲染模式为html

flutter build web --web-renderer html

解决办法 2： 上面虽然能解决问题，但我习惯用按钮运行程序怎么办？当然也找到了其他办法。在程序包下web/index.html文件中body标签下copy如下代码。

 <!--指定web运行模式-->

  <!--      window.flutterWebRenderer = "canvaskit";-->

  <script type="text/javascript">

      window.flutterWebRenderer = "html";



  </script>

  <script src="main.dart.js" type="application/javascript"></script>

二、Debug启动运行断点失败

web开发和APP端开发一样，也可以断点。项目之初断点是可以的，但是不知道怎么的，debug可以运行，但断不到，很奇怪，花了一上午，发现同事因为发版改了下web/index.html中head->base标签下 href="***"的值。

解决办法 ：

// 之前，断点可用

 <base href="$FLUTTER_BASE_HREF">

 

// 同事改动,断点不可用

 <base href="git/******">

 

// 修复后,断点可用

<base href="/">

不能断点开发实在是麻烦。

三、Hot Reload热重载、点击浏览器刷新，都会重启整个程序

在APP端开发时，在某个页面点hot reload按钮，只会重新运行当前页面，但是在web中，点热重载会重启，这只是开发中的不方便。已经上线的程序，用户只要点击浏览器刷新就会重启整个程序，无论在哪个页面，都会回到第一个页面，这与我浏览网页的习惯明显是不符的。

查找原因，发现是flutter底层问题，仔细观察web页面是通过不同的url来确定的，而Flutter从始至终都是一个url，只是flutter在一个网页中绘制了不同的页面（与APP端原理一致），所以想解决问题就是要每个页面都有自己的url。

解决办法 ： 用静态路由的方式跳转页面和传参，具体代码如下。

  // 跳转与传参

  static Future toName(String pageName, Map<String, dynamic> params) {

    var uri = Uri(scheme: RoutePath.scheme, host: pageName, queryParameters: params);

    return Navigator.of(currentContext).pushNamed(uri.toString());

  }

  

  // 取参方式

  static Route<dynamic> generateRoute(RouteSettings settings) {

    return PageRouteBuilder(

        settings: settings,

        pageBuilder: (BuildContext c, Animation<double> a,Animation<double> sa) {

          var uri = Uri.parse(settings.name ?? ''); //解析页面名

          switch (uri.host) {

            case RoutePath.name:

              return NamePage(uri.queryParameters); 、、传参

            default:

              return Scaffold(

                body: Center(

                  child: Text('没有找到对应的页面：${settings.name}'),

                ),

              );

          }

        });

  }

通过以上方式，跳转时每个页面都会有自己的url和拼接的参数，这样刷新的时候就不会重启整个程序，会停留在当前页面。

四、用静态路由的方式跳转，全局变量，单例对象丢失，页面栈记录丢失。

没错，坑是连着的，我也是服了。当在某页面热重载或点击浏览器刷新，会停留在当前页面，但是无法返回，就算点击跳转至其他页面，也会报错，因为全局变量都已经丢失，比如：登录信息，用户信息，已经初始化的工具类对象等。

已经有人提了Issues，国内也有大神分析了原因和不完全结局方案

目前flutter web对于浏览器还是没有适配完全，无论Navigator1.0还是Navigator2.0，都存在不可解决的严重问题。目前来看google的对flutter web的意图，还是开发移动web并在App中通过webkit这种内核使用，并没有想开发者使用flutter web来开发真正的web应用，或者后续会完善这部分。

我的解决方案

1. 除了登录页和首页，其他页面不用静态路由的方式跳转，这样做即使用户刷新，也不会回到登录页，而是回首页。


2. 在有刷新需求的页面上提供刷新图标，可触发刷新，避免用户点击浏览器的刷新。


3. 全局变量持久化，用html.window.localStorage并配合工厂模式持久化数据，当被触发刷新，会从本地重新赋值，比如：登录信息等。


4. 弱化全局成员变量，非必要不使用全局类的变量，数据尽量放云端，页面间不耦合。

五、检测浏览器/标签页关闭还是刷新

解决办法 ： 可以使用函数onBeforeUnload来检查选项卡是否正在关闭。它也可能检测到页面刷新。

import 'dart:html' as html;

html.window.onBeforeUnload.listen((event) async{

  // do something

});

或者

import 'dart:html' as html;

html.window.onUnload.listen((event) async{

  // do something

});