相信这几年负责过上架应用市场的 App 开发，或多或少都躺过上线审核的坑，经历过的各种问题也是千奇百怪，今天就给大家做个汇总，希望可以帮助大家少走弯路，争取做一个“优雅”的客户端开发。

首先，近年来为了 “净化” App 环境、保护用户隐私和优化用户体验，各部委大致出台过如下所示的相关法规：

可能还有一些我不知道的遗漏，那不知道这些法规你是否都听说过，这里举一些常见例子：

• 《互联网用户账号信息管理规定》 的第十二条就是在 App 展示用户 IP 的要求相关条款。


• 《常见类型移动互联网应用程序必要个人信息范围规定》就规定了 App 类目所能获取的权限范围和个人信息索取范围，例如新闻资讯类、浏览器类、安全管理类、应用商店类等无须个人信息，即可使用基本功能服务。

针对上面这个无需权限和个人信息也要提供基本功能服务，如下动图所示，今日头条、知乎和懂车帝就是很好的参考例子，在不同意个人隐私协议的情况下，会有仅浏览的模式，在这个情况下依然可以阅读内容而不是退出 App 。

所以严格意义上讲，现在 App 按照类目的规定，如果你的 App 在某些类目就只能获取对应权限，多了就是违规，而且一些类目必须用户在没有提供权限和同意协议的情况下，也必须提供服务。

• 《互联网弹窗信息推送服务管理规定》里就有： 弹窗推送广告显著标明“广告”，一键关闭，提供取消渠道等。

如下图所示，从意见稿开始之后，基本大部分 App 的启动广告就限制了有效点击范围，产品经理也不能拍着脑袋让你加各种奇奇怪怪的跳转。

• 《个人信息保护法》 这个大家肯定就不会陌生了，我在之前《个人信息保护法》更新究竟是什么 也聊过，其中最主要就是提供个人信息的导出机制和广告推送相关内容。

首先用户必须同意了你才能收集，不同意是不能收集，所以 App 里各式各样的弹出框就来了，这也是目前最常见的“合规方式”。

而导出个人信息的功能普遍是通过邮箱发送实现，事实上目前还有不少 App 没提供类似支持，还有 App 必须提供用户注销功能，这也是现在 App 开发的必选项，另外 App 还需要提供个性化推荐的开关能力，不然也有审核风险，当时有时候只是需要你放个按键。

另外，在《个保法》的提案里也提及了不能以用户不提供个人信息为由不提供服务，当时实际执行往往还是要看应用类目。

而在用户个人信息认定里，设备id （Android ID） 绝对是重灾区 ，因为几乎是个 App 就会使用到设备 ID，特别是接入的各类第三方 SDK 服务里普遍都会获取。

而处理方法也是普通粗旷，用户不同意隐私协议，就不初始化各类 SDK ，当然，有时候你可能还是会遇到某些奇葩的审核，明明你已经做了处理，平台还认定你违规，这时候可能你就需要学会申诉，不要傻傻自己一直摸索哪里还不对。

总的来说上架问题一般是和个人信息隐私相关的问题最多，而常见的问题有：

• 未经用户允许手机个人信息


• 所需信息和服务无关，过度收集


• 未提供导出和删除个人信息的功能服务


• 存在个人信息泄漏风险


• 未明确公布个人信息收集的目的和使用范围

最后这一条也是经常出现问题的点，例如现在会要求你提供哪些 SDK 使用了哪些权限和信息，收集规则是什么用于做什么 ，这也就需要 App 里提供更详细和丰富的隐私政策内容，当然 SDK 提供方也要。

而一般情况下最常见也是最容易触发整改的，就是设备ID，MAC 地址等相关内容，或者说你的 App 其实根本不需要这些也能提供服务，就如前面 《常见类型移动互联网应用程序必要个人信息范围规定》里的要求一样。

这里还有个关键，那就是用户在同意隐私条款时，你不能默认勾选，也就是有需要用户同意☑️的 UI 时，默认时不能选中，需要用户手动勾选同意。

当然，随着审核颗粒度的细化，越来越多奇奇怪怪的问题出现了，例如 Apk 里的资源文件存在安全泄漏问题 ，而解决该问题的有效方法就是：混淆和加固。

加固和混淆也适用于以下相关问题的解决，当然，加固的话建议选用第三方付费服务，免费加固的坑实在太多了。

• 《数据出境安全评估办法》 里针对数据出境也做了要求，其中最直观的例子就是：高德 SDK 无法在以外地区范围服务。

当然，不只是相关法规，平台有时候也有自己的规定和理解，比如有几位群友，先后在小米因为 App 里提供 UI 和商店截图一致被打回，理由是应用截图与应用实际功能不符 ，相信遇到这类问题的兄弟是相当郁闷，因为不一致这个认定其实很主观。

另外小米等平台还有以没通过Monkey 自动化测试为理由拒绝上架 ，一般这种情况推荐自己上传 testit.miui.com ，通过小米自动化测试后在上传审核时把你通过截图作为附加，这样可以解决审核时的扯皮问题。

有时候一些平台也会有安全扫描，例如华为就会扫描同名的包名，然后附上 git 链接告诉你风险 。

另外，华为审核时可能会对你的产品逻辑提出他们的想法，比如空白页面，添加引导，没有客服返回渠道等等。

还有另外一个高风险点就是自启动，相信我，如果你要上架平台，2022 年了就不要再想做什么保活相关的逻辑了。

除此之外，如果平台说你存在问题，尽量想办法要到检测报告，因为有时候一些平台委托的第三方可能会不是很“靠谱“，然后需要你自己出钱区做”二次付费检测“。

除了上面的问题之后，如果你还遇到如下图类似问题，都可以通过一些官方平台的检测如 open.oppomobile.com/opdp/privac… 帮助查找问题，这样也许就可以帮老板省下一笔开销，当然有一些第三方开源平台如 Hegui3.0 和 PrivacySentry 等项目，也可以帮助你解决一些实际问题。

最后，如果关于什么上架审核或者安全合规等问题，欢迎留言评论，也许以后本篇可以作为一个更新集合，继续帮助到更多需要的可怜 App 开发。

前言

热修复到现在2022年已经不是一个新名词，但是作为Android开发核心技术栈的一部分，我这里还得来一次冷饭热炒。

随着移动端业务复杂程度的增加，传统的版本更新流程显然无法满足业务和开发者的需求，
热修复技术的推出在很大程度上改善了这一局面。国内大部分成熟的主流 App都拥有自己的热更新技术，像手淘、支付宝、微信、QQ、饿了么、美团等。

可以说，一个好的热修复技术，将为你的 App助力百倍。对于每一个想在 Android 开发领域有所造诣的开发者，掌握热修复技术更是必备的素质。

热修复是 Android 大厂面试中高频面试知识点，也是我们必须要掌握的知识点。热修复技术，可以看作 Android平台发展成熟至一定阶段的必然产物。
Android热修复了解吗？修复哪些东西？
常见热修复框架对比以及各原理分析？

1.什么是热修复

热修复说白了就是不再使用传统的应用商店更新或者自更新方式，使用补丁包推送的方式在用户无感知的情况下，修复应用bug或者推送新的需求

传统更新和热更新过程对比如下：

热修复优缺点:

• 优点:
  
  
  
  • 1.只需要打补丁包，不需要重新发版本。
  
  
  • 2.用户无感知，不需要重新下载最新应用
  
  
  • 3.修复成功率高
  
  
  
  


• 缺点：
  
  
  
  • 补丁包滥用，容易导致应用版本不可控，需要开发一套完整的补丁包更新机制，会增加一定的成本
  
  
  
  

2.热修复方案

首先我们得知道热修复修复哪些东西？

• 1.代码修复


• 2.资源修复


• 3.动态库修复

2.1:代码修复方案

从技术角度来说，我们的目的是非常明确的：把错误的代码替换成正确的代码。
注意这里的替换，并不是直接擦写dx文件，而是提供一份新的正确代码，让应用运行时绕过错误代码，执行新的正确代码。

想法简单直接，但实现起来并不容易。目前主要有三类技术方案：

2.1.1.类加载方案

之前分析类加载机制有说过:
加载流程先是遵循双亲委派原则，如果委派原则没有找到此前加载过此类，
则会调用CLassLoader的findClass方法，再去BaseDexClassLoader下面的dexElements数组中查找，如果没有找到，最终调用defineClassNative方法加载

代码修复就是基于这点：
将新的做了修复的dex文件，通过反射注入到BaseDexClassLoader的dexElements数组的第一个位置上dexElements[0]，下次重新启动应用加载类的时候，会优先加载做了修复的dex文件，这样就达到了修复代码的目的。原理很简单

代码如下：

public class Hotfix {



    public static void patch(Context context, String patchDexFile, String patchClassName)

                    throws ClassNotFoundException, NoSuchFieldException, IllegalAccessException, InstantiationException, NoSuchMethodException, InvocationTargetException {

        //获取系统PathClassLoader的"dexElements"属性值

        PathClassLoader pathClassLoader = (PathClassLoader) context.getClassLoader();

        Object origDexElements = getDexElements(pathClassLoader);



        //新建DexClassLoader并获取“dexElements”属性值

        String otpDir = context.getDir("dex", 0).getAbsolutePath();

        Log.i("hotfix", "otpdir=" + otpDir);

        DexClassLoader nDexClassLoader = new DexClassLoader(patchDexFile, otpDir, patchDexFile, context.getClassLoader());

        Object patchDexElements = getDexElements(nDexClassLoader);



        //将patchDexElements插入原origDexElements前面

        Object allDexElements = combineArray(origDexElements, patchDexElements);



        //将新的allDexElements重新设置回pathClassLoader

        setDexElements(pathClassLoader, allDexElements);



        //重新加载类

        pathClassLoader.loadClass(patchClassName);

}

private static Object getDexElements(ClassLoader classLoader) throws ClassNotFoundException, NoSuchFieldException, IllegalAccessException {

        //首先获取ClassLoader的“pathList”实例

        Field pathListField = Class.forName("dalvik.system.BaseDexClassLoader").getDeclaredField("pathList");

        pathListField.setAccessible(true);//设置为可访问

        Object pathList = pathListField.get(classLoader);



        //然后获取“pathList”实例的“dexElements”属性

        Field dexElementField = pathList.getClass().getDeclaredField("dexElements");

        dexElementField.setAccessible(true);



        //读取"dexElements"的值

        Object elements = dexElementField.get(pathList);

        return elements;

    }

    //合拼dexElements

    private static Object combineArray(Object obj, Object obj2) {

        Class componentType = obj2.getClass().getComponentType();

        //读取obj长度

        int length = Array.getLength(obj);

        //读取obj2长度

        int length2 = Array.getLength(obj2);

        Log.i("hotfix", "length=" + length + ",length2=" + length2);

        //创建一个新Array实例，长度为ojb和obj2之和

        Object newInstance = Array.newInstance(componentType, length + length2);

        for (int i = 0; i < length + length2; i++) {

                //把obj2元素插入前面

                if (i < length2) {

                        Array.set(newInstance, i, Array.get(obj2, i));

                } else {

                        //把obj元素依次放在后面

                        Array.set(newInstance, i, Array.get(obj, i - length2));

                }

        }

        //返回新的Array实例

        return newInstance;

    }

    private static void setDexElements(ClassLoader classLoader, Object dexElements) throws ClassNotFoundException, NoSuchFieldException, IllegalAccessException {

        //首先获取ClassLoader的“pathList”实例

        Field pathListField = Class.forName("dalvik.system.BaseDexClassLoader").getDeclaredField("pathList");

        pathListField.setAccessible(true);//设置为可访问

        Object pathList = pathListField.get(classLoader);



        //然后获取“pathList”实例的“dexElements”属性

        Field declaredField = pathList.getClass().getDeclaredField("dexElements");

        declaredField.setAccessible(true);



        //设置"dexElements"的值

        declaredField.set(pathList, dexElements);

    }

}

类加载过程如下：

微信Tinker，QQ 空间的超级补丁、手 QQ 的QFix 、饿了 么的 Amigo 和 Nuwa 等都是使用这个方式

缺点：因为类加载后无法卸载，所以类加载方案必须重启App，让bug类重新加载后才能生效。

2.1.2:底层替换方案

底层替换方案不会再次加载新类，而是直接在 Native 层 修改原有类，
这里我们需要提到Art虚拟机中ArtMethod：
每一个Java方法在Art虚拟机中都对应着一个 ArtMethod，ArtMethod记录了这个Java方法的所有信息，包括所属类、访问权限、代码执行地址等。

结构如下：

// art/runtime/art_method.h

class ArtMethod FINAL {

...

 protected:

  GcRoot<mirror::Class> declaring_class_;

  GcRoot<mirror::PointerArray> dex_cache_resolved_methods_;

  GcRoot<mirror::ObjectArray<mirror::Class>> dex_cache_resolved_types_;

  uint32_t access_flags_;

  uint32_t dex_code_item_offset_;

  uint32_t dex_method_index_;

  uint32_t method_index_;



  struct PACKED(4) PtrSizedFields {

        void* entry_point_from_interpreter_;      // 1

        void* entry_point_from_jni_;

        void* entry_point_from_quick_compiled_code_;  //2

  } ptr_sized_fields_;

  ...

}

在 ArtMethod结构体中，最重要的就是 注释1和注释2标注的内容，从名字可以看出来，他们就是方法的执行入口。
我们知道，Java代码在Android中会被编译为 Dex Code。

Art虚拟机中可以采用解释模式或者 AOT机器码模式执行 Dex Code

• 解释模式:
  就是去除Dex Code，逐条解释执行。
  如果方法的调用者是以解释模式运行的，在调用这个方法时，就会获取这个方法的 entry_point_from_interpreter_，然后跳转执行。


• AOT模式:
  就会预先编译好 Dex Code对应的机器码，然后在运行期直接执行机器码，不需要逐条解释执行Dex Code。
  如果方法的调用者是以AOT机器码方式执行的，在调用这个方法时，就是跳转到 entry_point_from_quick_compiled_code_中执行。

那是不是只需要替换这个几个 entry_point_* 入口地址就能够实现方法替换了呢？
并没有那么简单，因为不论是解释模式还是AOT模式，在运行期间还会需要调用ArtMethod中的其他成员字段

AndFix采用的是改变指针指向：

// AndFix/jni/art/art_method_replace_6_0.cpp

void replace_6_0(JNIEnv* env, jobject src, jobject dest) {

    art::mirror::ArtMethod* smeth =

                    (art::mirror::ArtMethod*) env->FromReflectedMethod(src);  // 1



    art::mirror::ArtMethod* dmeth =

                    (art::mirror::ArtMethod*) env->FromReflectedMethod(dest);  // 2

    ...

    // 3

    smeth->declaring_class_ = dmeth->declaring_class_;

    smeth->dex_cache_resolved_methods_ = dmeth->dex_cache_resolved_methods_;

    smeth->dex_cache_resolved_types_ = dmeth->dex_cache_resolved_types_;

    smeth->access_flags_ = dmeth->access_flags_ | 0x0001;

    smeth->dex_code_item_offset_ = dmeth->dex_code_item_offset_;

    smeth->dex_method_index_ = dmeth->dex_method_index_;

    smeth->method_index_ = dmeth->method_index_;



    smeth->ptr_sized_fields_.entry_point_from_interpreter_ =

    dmeth->ptr_sized_fields_.entry_point_from_interpreter_;



    smeth->ptr_sized_fields_.entry_point_from_jni_ =

    dmeth->ptr_sized_fields_.entry_point_from_jni_;

    smeth->ptr_sized_fields_.entry_point_from_quick_compiled_code_ =

    dmeth->ptr_sized_fields_.entry_point_from_quick_compiled_code_;



    LOGD("replace_6_0: %d , %d",

             smeth->ptr_sized_fields_.entry_point_from_quick_compiled_code_,

             dmeth->ptr_sized_fields_.entry_point_from_quick_compiled_code_);

}

缺点：存在一些兼容性问题，由于ArtMethod结构体是Android开源的一部分，所以每个手机厂商都可能会去更改这部分的内容，这就可能导致ArtMethod替换方案在某些机型上面出现未知错误。

Sophix为了规避上面的AndFix的风险，采用直接替换整个结构体。这样不管手机厂商如何更改系统，我们都可以正确定位到方法地址

2.4.3:install run方案

Instant Run 方案的核心思想是——插桩，在编译时通过插桩在每一个方法中插入代码，修改代码逻辑，在需要时绕过错误方法，调用patch类的正确方法。

首先，在编译时Instant Run为每个类插入IncrementalChange变量

IncrementalChange  $change;

为每一个方法添加类似如下代码：

public void onCreate(Bundle savedInstanceState) {

    IncrementalChange var2 = $change;

    //$change不为null，表示该类有修改，需要重定向

    if(var2 != null) {

        //通过access$dispatch方法跳转到patch类的正确方法

        var2.access$dispatch("onCreate.(Landroid/os/Bundle;)V", new Object[]{this, savedInstanceState});

    } else {

        super.onCreate(savedInstanceState);

        this.setContentView(2130968601);

        this.tv = (TextView)this.findViewById(2131492944);

    }

}

如上代码，当一个类被修改后，Instant Run会为这个类新建一个类，命名为xxx&override，且实现IncrementalChange接口，并且赋值给原类的$change变量。

public class MainActivity$override implements IncrementalChange {

｝

此时，在运行时原类中每个方法的var2 != null，通过accessdispatch（参数是方法名和原参数）定位到patch类MainActivitydispatch（参数是方法名和原参数）定位到patch类MainActivityoverride中修改后的方法。

Instant Run是google在AS2.0时用来实现“热部署”的，同时也为“热修复”提供了一个绝佳的思路。美团的Robust就是基于此。

2.2：资源修复方案

这里我们来看看install run的原理即可，市面上的常见修复方案大部分都是基于此方法。

public static void monkeyPatchExistingResources(Context context,

            String externalResourceFile, Collection<Activity> activities) {

    if (externalResourceFile == null) {

            return;

    }

    try {

// 创建一个新的AssetManager

        AssetManager newAssetManager = (AssetManager) AssetManager.class

                        .getConstructor(new Class[0]).newInstance(new Object[0]); // ... 1

        Method mAddAssetPath = AssetManager.class.getDeclaredMethod(

                        "addAssetPath", new Class[] { String.class }); // ... 2

        mAddAssetPath.setAccessible(true);

// 通过反射调用addAssetPath方法加载外部的资源（SD卡资源）

        if (((Integer) mAddAssetPath.invoke(newAssetManager,

                        new Object[] { externalResourceFile })).intValue() == 0) { // ... 3

                throw new IllegalStateException(

                                "Could not create new AssetManager");

        }

        Method mEnsureStringBlocks = AssetManager.class.getDeclaredMethod(

                        "ensureStringBlocks", new Class[0]);

        mEnsureStringBlocks.setAccessible(true);

        mEnsureStringBlocks.invoke(newAssetManager, new Object[0]);

        if (activities != null) {

            for (Activity activity : activities) {

                Resources resources = activity.getResources(); // ... 4

                try { 

// 反射得到Resources的AssetManager类型的mAssets字段

                    Field mAssets = Resources.class

                                    .getDeclaredField("mAssets"); // ... 5

                    mAssets.setAccessible(true);

// 将mAssets字段的引用替换为新创建的newAssetManager

                    mAssets.set(resources, newAssetManager); // ... 6

                } catch (Throwable ignore) {

                    ...

                }



// 得到Activity的Resources.Theme

                Resources.Theme theme = activity.getTheme();

                try {

                    try {

// 反射得到Resources.Theme的mAssets字段

                        Field ma = Resources.Theme.class

                                        .getDeclaredField("mAssets");

                        ma.setAccessible(true);

// 将Resources.Theme的mAssets字段的引用替换为新创建的newAssetManager

                        ma.set(theme, newAssetManager); // ... 7

                    } catch (NoSuchFieldException ignore) {

                            ...

                    }

                        ...

                } catch (Throwable e) {

                    Log.e("InstantRun",

                                    "Failed to update existing theme for activity "

                                                    + activity, e);

                }

                pruneResourceCaches(resources);

        }

        }

/**

*  根据SDK版本的不同，用不同的方式得到Resources 的弱引用集合

*/ 

        Collection<WeakReference<Resources>> references;

        if (Build.VERSION.SDK_INT >= 19) {

            Class<?> resourcesManagerClass = Class

                            .forName("android.app.ResourcesManager");

            Method mGetInstance = resourcesManagerClass.getDeclaredMethod(

                            "getInstance", new Class[0]);

            mGetInstance.setAccessible(true);

            Object resourcesManager = mGetInstance.invoke(null,

                            new Object[0]);

            try {

                Field fMActiveResources = resourcesManagerClass

                                .getDeclaredField("mActiveResources");

                fMActiveResources.setAccessible(true);



                ArrayMap<?, WeakReference<Resources>> arrayMap = (ArrayMap) fMActiveResources

                                .get(resourcesManager);

                references = arrayMap.values();

            } catch (NoSuchFieldException ignore) {

                Field mResourceReferences = resourcesManagerClass

                                .getDeclaredField("mResourceReferences");

                mResourceReferences.setAccessible(true);



                references = (Collection) mResourceReferences

                                .get(resourcesManager);

            }

        } else {

            Class<?> activityThread = Class

                            .forName("android.app.ActivityThread");

            Field fMActiveResources = activityThread

                            .getDeclaredField("mActiveResources");

            fMActiveResources.setAccessible(true);

            Object thread = getActivityThread(context, activityThread);



            HashMap<?, WeakReference<Resources>> map = (HashMap) fMActiveResources

                            .get(thread);



            references = map.values();

        }

//遍历并得到弱引用集合中的 Resources ，将 Resources mAssets 字段引用替换成新的 AssetManager

            for (WeakReference<Resources> wr : references) {

                Resources resources = (Resources) wr.get();

                if (resources != null) {

                    try {

                        Field mAssets = Resources.class

                                        .getDeclaredField("mAssets");

                        mAssets.setAccessible(true);

                        mAssets.set(resources, newAssetManager);

                    } catch (Throwable ignore) {

                        ...

                    }

                    resources.updateConfiguration(resources.getConfiguration(),

                                    resources.getDisplayMetrics());

                }

            }

    } catch (Throwable e) {

            throw new IllegalStateException(e);

    }

}

• 在注释1处创建一个新的 AssetManager ，


• 在注释2 和注释3 处通过反射调用 addAssetPath 方法加载外部（ SD 卡）的资源。


• 在注释4 处遍历 Activity 列表，得到每个 Activity 的 Resources ，


• 在注释5 处通过反射得到 Resources 的 AssetManager 类型的 rnAssets 字段 ，


• 注释6处改写 mAssets 字段的引用为新的 AssetManager 。

采用同样的方式，

• 在注释7处将 Resources. Theme 的 m Assets 字段 的引用替换为新创建的 AssetManager 。


• 紧接着 根据 SDK 版本的不同，用不同的方式得到 Resources 的弱引用集合，


• 再遍历这个弱引用集合， 将弱引用集合中的 Resources 的 mAssets 字段引用都替换成新创建的 AssetManager 。

资源修复原理：

• 1.创建新的AssetManager，通过反射调用addAssetPath方法，加载外部资源，这样新创建的AssetManager就含有了外部资源


• 2.将AssetManager类型的mAsset字段全部用新创建的AssetManager对象替换。这样下次加载资源文件的时候就可以找到包含外部资源文件的AssetManager。

2.3：动态链接库so的修复

1.接口调用替换方案：

sdk提供接口替换System默认加载so库接口

SOPatchManager.loadLibrary(String libName) -> System.loadLibrary(String libName)

SOPatchManager.loadLibrary接口加载 so库的时候优先尝试去加载sdk 指定目录下的补丁so，

加载策略如下：

如果存在则加载补丁 so库而不会去加载安装apk安装目录下的so库
如果不存在补丁so，那么调用System.loadLibrary去加载安装apk目录下的 so库。

我们可以很清楚的看到这个方案的优缺点:
优点：不需要对不同 sdk 版本进行兼容，因为所有的 sdk 版本都有 System.loadLibrary 这个接口。
缺点：调用方需要替换掉 System 默认加载 so 库接口为 sdk提供的接口， 如果是已经编译混淆好的三方库的so 库需要 patch，那么是很难做到接口的替换

虽然这种方案实现简单，同时不需要对不同 sdk版本区分处理，但是有一定的局限性没法修复三方包的so库同时需要强制侵入接入方接口调用，接着我们来看下反射注入方案。

2、反射注入方案

前面介绍过 System. loadLibrary ( "native-lib"); 加载 so库的原理，其实native-lib 这个 so 库最终传给 native 方法执行的参数是 so库在磁盘中的完整路径，比如：/data/app-lib/com.taobao.jni-2/libnative-lib.so, so库会在 DexPathList.nativeLibraryDirectories/nativeLibraryPathElements 变量所表示的目录下去遍历搜索

sdk<23 DexPathList.findLibrary 实现如下

可以发现会遍历 nativeLibraryDirectories数组，如果找到了 loUtils.canOpenReadOnly (path)返回为 true, 那么就直接返回该 path, loUtils.canOpenReadOnly (path)返回为 true 的前提肯定是需要 path 表示的 so文件存 在的。那么我们可以采取类似类修复反射注入方式，只要把我们的补丁so库的路径插入到nativeLibraryDirectories数组的最前面就能够达到加载so库的时候是补丁 库而不是原来so库的目录，从而达到修复的目的。

sdk>=23 DexPathList.findLibrary 实现如下

sdk23 以上 findLibrary 实现已经发生了变化，如上所示，那么我们只需要把补丁so库的完整路径作为参数构建一个Element对象，然后再插入到nativeLibraryPathElements 数组的最前面就好了。

• 优点：可以修复三方库的so库。同时接入方不需要像方案1 —样强制侵入用 户接口调用


• 缺点：需要不断的对 sdk 进行适配，如上 sdk23 为分界线，findLibrary接口实现已经发生了变化。

对于 so库的修复方案目前更多采取的是接口调用替换方式，需要强制侵入用户 接口调用。
目前我们的so文件修复方案采取的是反射注入的方案，重启生效。具有更好的普遍性。
如果有so文件修复实时生效的需求，也是可以做到的，只是有些限制情况。

常见热修复框架？

可以看出，阿里系多采用native底层方案，腾讯系多采用类加载机制。其中，Sophix是商业化方案；Tinker/Amigo支持特性较多，同时也更复杂，如果需要修复资源和so，可以选择；如果仅需要方法替换，且需要即时生效，Robust是不错的选择。

总结：

尽管热修复（或热更新）相对于迭代更新有诸多优势，市面上也有很多开源方案可供选择，但目前热修复依然无法替代迭代更新模式。有如下原因：
热修复框架多多少少会增加性能开销，或增加APK大小
热修复技术本身存在局限，比如有些方案无法替换so或资源文件
热修复方案的兼容性，有些方案无法同时兼顾Dalvik和ART，有些深度定制系统也无法正常工作
监管风险，比如苹果系统严格限制热修复

所以，对于功能迭代和常规bug修复，版本迭代更新依然是主流。一般的代码修复，使用Robust可以解决，如果还需要修复资源或so库，可以考虑Tinker。

LinkedList源码解析

目标

• 理解LinkedList底层数据结构


• 深入源码掌握LinkedList查询慢，新增快的原因

1.简介

List 接口的链接列表实现。实现所有可选的列表操作，并且允许所有元素（包括 null ）。除了实现 List 接口外， LinkedList 类还为在列表的开头及结尾 get 、 remove 和 insert 元素提供了统一 的命名方法。这些操作允许将链接列表用作堆栈、队列或双端队列。

特点 :

• 有序性 : 存入和取出的顺序是一致的


• 元素可以重复


• 含有带索引的方法


• 独有特点 : 数据结构是链表，可以作为栈、队列或者双端队列！

2.LinkedList原理分析

双向链表

底层数据结构源码

public class LinkedList<E> {

    transient int size = 0;

    //双向链表的头结点

    transient Node<E> first;

    //双向链表的最后一个节点

    transient Node<E> last;



    //节点类【内部类】

    private static class Node<E> {

        E item;//数据元素

        Node<E> next;//下一个节点

        Node<E> prev;//上一个节点



        //节点的构造方法

        Node(Node<E> prev, E element, Node<E> next) {

            this.item = element;

            this.next = next;

            this.prev = prev;

        }

    } /

            /...

}

2.1 LinkedList的数据结构

LinkedList是双向链表，在代码中是一个Node类。内部并没有数组的结构。双向链表肯定存在一个头节 点和一个尾部节点。node节点类，是以内部类的形式存在于LinkedList中的。Node类都有两个成员变 量:

• prev : 当前节点上一个节点，头节点的上一个节点是null


• next : 当前节点下一个节点，尾结点的下一个节点是null

链表数据结构的特点 : 查询慢，增删快！

• 链表数据结构基本构成，是一个node类


• 每个node类中，有上一个节点【prev】和下一个节点【next】


• 链表一定存在至少两个节点，first和last节点


• 如果LinkedList没有数据，first和last都是为null

2.2 LinkedList默认容量&最大容量

没有默认容量，也没有最大容量

2.3 LinkedList扩容机制

无需扩容机制，只要你的内存足够大，可以无限制扩容下去。前提是不考虑查询的效率。

2.4 为什么LinkedList查询慢，增删快？

LinkedList的数据结构的特点，链表的数据结构就是这样的特点！

• 链表是一种查询慢的结构【相对于数组来说】


• 链表是一种增删快的结构【相对于数组来说】

2.5 LinkedList源码剖析-为什么增删快？

新增add

//想LinkedList添加一个元素

public boolean add(E e){

//连接到链表的末尾

        linkLast(e);

        return true;

        }/

        /连接到最后一个节点上去

        void linkLast(E e){

//将全局末尾节点赋值给l

final Node<E> l=last;

//创建一个新节点 : (上一个节点, 当前插入元素, null)

final Node<E> newNode=new Node<>(l,e,null);

//将当前节点作为末尾节点

        last=newNode;

//判断l节点是否为null

        if(l==null)

//既是尾结点也是头节点

        first=newNode;

        else

//之前的末尾节点，下一个节点时末尾节点！

        l.next=newNode;

        size++;//当前集合的元素数量+1

        modCount++;//操作集合数+1。modCount属性是修改技术器

        }/

        /------------------------------------------------------------------

//向链表中部添加

//参数1，添加的索引位置，添加元素

public void add(int index,E element){

//检查索引位是否符合要求

        checkPositionIndex(index);

//判断当前所有是否是存储元素个数

        if(index==size)//true，最后一个元素

        linkLast(element);

        else

//连接到指定节点的后面【链表中部插入】

        linkBefore(element,node(index));

        }/

        /根据索引查询链表中节点！

        Node<E> node(int index){

// 判断索引是否小于 已经存储元素个数的1/2

        if(index< (size>>1)){//二分法查找 : 提高查找节点效率

        Node<E> x=first;

        for(int i=0;i<index; i++)

        x=x.next;

        return x;

        }else{

        Node<E> x=last;

        for(int i=size-1;i>index;i--)

        x=x.prev;

        return x;

        }

        }/

        /将当前元素添加到指定节点之前

        void linkBefore(E e,Node<E> succ){

        // 取出当前节点的前一个节点

        final Node<E> pred=succ.prev;

        //创建当前元素的节点 : 上一个节点，当前元素，下一个节点

        final Node<E> newNode=new Node<>(pred,e,succ);

        //为指定节点上一个节点重新值

        succ.prev=newNode;

//判断当前节点的上一个节点是否为null

        if(pred==null)

        first=newNode;//当前节点作为头部节点

        else

        pred.next=newNode;//将新插入节点作为上一个节点的下个节点

        size++;//新增元素+1

        modCount++;//操作次数+1

        }

remove删除指定索引元素

//删除指定索引位置元素

public E remove(int index){

//检查元素索引

        checkElementIndex(index);

//删除元素节点，

//node(index) 根据索引查到要删除的节点

//unlink()删除节点

        return unlink(node(index));

        }//根据索引查询链表中节点！

        Node<E> node(int index){

// 判断索引是否小于 已经存储元素个数的1/2

        if(index< (size>>1)){//二分法查找 : 提高查找节点效率

        Node<E> x=first;

        for(int i=0;i<index; i++)

        x=x.next;

        return x;

        }else{

        Node<E> x=last;

        for(int i=size-1;i>index;i--)

        x=x.prev;

        return x;

        }

        }/

        /删除一个指定节点

        E unlink(Node<E> x){

//获取当前节点中的元素

final E element=x.item;

//获取当前节点的上一个节点

final Node<E> next=x.next;

//获取当前节点的下一个节点

final Node<E> prev=x.prev;

//判断上一个节点是否为null

        if(prev==null){

//如果为null，说明当前节点为头部节点

        first=next;

        }else{

//上一个节点，的下一个节点改为下下节点

        prev.next=next;

//将当前节点的上一个节点置空

        x.prev=null;

        }/

        /判断下一个节点是否为null

        if(next==null){

//如果为null，说明当前节点为尾部节点

        last=prev;

        }else{

//下一个节点的上节点，改为上上节点

        next.prev=prev;

//当前节点的上节点置空

        x.next=null;

        }/

        /删除当前节点内的元素

        x.item=null;

        size--;//集合中的元素个数-1

        modCount++;//当前集合操作数+1。modCount计数器，记录当前集合操作次数

        return element;//返回删除的元素

        }

2.6 LinkedList源码剖析-为什么查询慢？

查询快和慢是一个相对概念！相对于数组来说

//根据索引查询一个元素

public E get(int index){

//检查索引是否存在

        checkElementIndex(index);

// node(index)获取索引对应节点，获取节点中的数据item

        return node(index).item;

        }/

        /根据索引获取对应节点对象

        Node<E> node(int index){

//二分法查找索引对应的元素

        if(index< (size>>1)){

        Node<E> x=first;

//前半部分查找【遍历节点】

        for(int i=0;i<index; i++)

        x=x.next;

        return x;

        }else{

        Node<E> x=last;

//后半部分查找【遍历】

        for(int i=size-1;i>index;i--)

        x=x.prev;

        return x;

        }

        }/

        /查看ArrayList里的数组获取元素的方式

public E get(int index){

        rangeCheck(index);//检查范围

        return elementData(index);//获取元素

        }E

        elementData(int index){

        return(E)elementData[index];//一次性操作

        }

这是《Spring Security 进阶》专栏的第三篇文章，给大家介绍一下Spring Security 中内置的加密算法BCrypt，号称最安全的加密算法，究竟有着什么魔力能让黑客闻风丧胆

哈希（Hash）与加密（Encrypt）

哈希（Hash）是将目标文本转换成具有相同长度的、不可逆的杂凑字符串（或叫做消息摘要），而加密（Encrypt）是将目标文本转换成具有不同长度的、可逆的密文。

• 哈希算法往往被设计成生成具有相同长度的文本，而加密算法生成的文本长度与明文本身的长度有关。


• 哈希算法是不可逆的，而加密算法是可逆的。

HASH 算法是一种消息摘要算法，不是一种加密算法，但由于其单向运算，具有一定的不可逆性，成为加密算法中的一个构成部分。

JDK的String的Hash算法。代码如下：

public int hashCode() {

    int h = hash;

    if (h == 0 && value.length > 0) {

        char val[] = value;

        for (int i = 0; i < value.length; i++) {

            h = 31 * h + val[i];

        }

        hash = h;

    }

    return h;

}

从JDK的API可以看出，它的算法等式就是s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]，其中s[i]就是索引为i的字符，n为字符串的长度。

HashMap的hash计算时先计算hashCode(),然后进行二次hash。代码如下：

// 计算二次Hash    

int hash = hash(key.hashCode());



static int hash(int h) {

	h ^= (h >>> 20) ^ (h >>> 12);

	return h ^ (h >>> 7) ^ (h >>> 4);

}

可以发现，虽然算法不同，但经过这些移位操作后，对于同一个值使用同一个算法，计算出来的hash值一定是相同的。

那么，hash为什么是不可逆的呢？

假如有两个密码3和4，我的加密算法很简单就是3+4，结果是7，但是通过7我不可能确定那两个密码是3和4，有很多种组合，这就是最简单的不可逆，所以只能通过暴力破解一个一个的试。

在计算过程中原文的部分信息是丢失了。一个MD5理论上是可以对应多个原文的，因为MD5是有限多个而原文是无限多个的。

不可逆的MD5为什么是不安全的？

因为hash算法是固定的，所以同一个字符串计算出来的hash串是固定的，所以，可以采用如下的方式进行破解。

1. 暴力枚举法：简单粗暴地枚举出所有原文，并计算出它们的哈希值，看看哪个哈希值和给定的信息摘要一致。


2. 字典法：黑客利用一个巨大的字典，存储尽可能多的原文和对应的哈希值。每次用给定的信息摘要查找字典，即可快速找到碰撞的结果。


3. 彩虹表（rainbow）法：在字典法的基础上改进，以时间换空间。是现在破解哈希常用的办法。

对于单机来说，暴力枚举法的时间成本很高（以14位字母和数字的组合密码为例，共有1.24×10^25种可能，即使电脑每秒钟能进行10亿次运算，也需要4亿年才能破解），字典法的空间成本很高（仍以14位字母和数字的组合密码为例，生成的密码32位哈希串的对照表将占用5.7×10^14 TB的存储空间）。但是利用分布式计算和分布式存储，仍然可以有效破解MD5算法。因此这两种方法同样被黑客们广泛使用。

如何防御彩虹表的破解？

虽然彩虹表有着如此惊人的破解效率，但网站的安全人员仍然有办法防御彩虹表。最有效的方法就是“加盐”，即在密码的特定位置插入特定的字符串，这个特定字符串就是“盐（Salt）”，加盐后的密码经过哈希加密得到的哈希串与加盐前的哈希串完全不同，黑客用彩虹表得到的密码根本就不是真正的密码。即使黑客知道了“盐”的内容、加盐的位置，还需要对H函数和R函数进行修改，彩虹表也需要重新生成，因此加盐能大大增加利用彩虹表攻击的难度。

一个网站，如果加密算法和盐都泄露了，那针对性攻击依然是非常不安全的。因为同一个加密算法同一个盐加密后的字符串仍然还是一毛一样滴！

一个更难破解的加密算法Bcrypt

BCrypt是由Niels Provos和David Mazières设计的密码哈希函数，他是基于Blowfish密码而来的，并于1999年在USENIX上提出。

除了加盐来抵御rainbow table 攻击之外，bcrypt的一个非常重要的特征就是自适应性，可以保证加密的速度在一个特定的范围内，即使计算机的运算能力非常高，可以通过增加迭代次数的方式，使得加密速度变慢，从而可以抵御暴力搜索攻击。

Bcrypt可以简单理解为它内部自己实现了随机加盐处理。使用Bcrypt，每次加密后的密文是不一样的。

对一个密码，Bcrypt每次生成的hash都不一样，那么它是如何进行校验的？

1. 虽然对同一个密码，每次生成的hash不一样，但是hash中包含了salt（hash产生过程：先随机生成salt，salt跟password进行hash）；


2. 在下次校验时，从hash中取出salt，salt跟password进行hash；得到的结果跟保存在DB中的hash进行比对。

在Spring Security 中 内置了Bcrypt加密算法，构建也很简单，代码如下：

@Bean

public PasswordEncoder passwordEncoder(){

    return new BCryptPasswordEncoder();

}

生成的加密字符串格式如下：

$2b$[cost]$[22 character salt][31 character hash]

比如：

$2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy

\__/\/ \____________________/\_____________________________/

 Alg Cost      Salt                        Hash

上面例子中，$2a$ 表示的hash算法的唯一标志。这里表示的是Bcrypt算法。

10 表示的是代价因子，这里是2的10次方，也就是1024轮。

N9qo8uLOickgx2ZMRZoMye 是16个字节（128bits）的salt经过base64编码得到的22长度的字符。

最后的IjZAgcfl7p92ldGxad68LJZdL17lhWy是24个字节（192bits）的hash，经过bash64的编码得到的31长度的字符。

PasswordEncoder 接口

这个接口是Spring Security 内置的，如下：

public interface PasswordEncoder {

   String encode(CharSequence rawPassword);



   boolean matches(CharSequence rawPassword, String encodedPassword);



   default boolean upgradeEncoding(String encodedPassword) {

      return false;

   }

}

这个接口有三个方法：

• encode方法接受的参数是原始密码字符串，返回值是经过加密之后的hash值，hash值是不能被逆向解密的。这个方法通常在为系统添加用户，或者用户注册的时候使用。


• matches方法是用来校验用户输入密码rawPassword，和加密后的hash值encodedPassword是否匹配。如果能够匹配返回true，表示用户输入的密码rawPassword是正确的，反之返回fasle。也就是说虽然这个hash值不能被逆向解密，但是可以判断是否和原始密码匹配。这个方法通常在用户登录的时候进行用户输入密码的正确性校验。


• upgradeEncoding设计的用意是，判断当前的密码是否需要升级。也就是是否需要重新加密？需要的话返回true，不需要的话返回fasle。默认实现是返回false。

例如，我们可以通过如下示例代码在进行用户注册的时候加密存储用户密码

//将User保存到数据库表，该表包含password列

user.setPassword(passwordEncoder.encode(user.getPassword()));

BCryptPasswordEncoder 是Spring Security推荐使用的PasswordEncoder接口实现类

public class PasswordEncoderTest {

  @Test

  void bCryptPasswordTest(){

    PasswordEncoder passwordEncoder =  new BCryptPasswordEncoder();

    String rawPassword = "123456";  //原始密码

    String encodedPassword = passwordEncoder.encode(rawPassword); //加密后的密码



    System.out.println("原始密码" + rawPassword);

    System.out.println("加密之后的hash密码:" + encodedPassword);



    System.out.println(rawPassword + "是否匹配" + encodedPassword + ":"   //密码校验：true

            + passwordEncoder.matches(rawPassword, encodedPassword));



    System.out.println("654321是否匹配" + encodedPassword + ":"   //定义一个错误的密码进行校验:false

            + passwordEncoder.matches("654321", encodedPassword));

  }

}

上面的测试用例执行的结果是下面这样的。（注意：对于同一个原始密码，每次加密之后的hash密码都是不一样的，这正是BCryptPasswordEncoder的强大之处，它不仅不能被破解，想通过常用密码对照表进行大海捞针你都无从下手），输出如下：

原始密码123456

加密之后的hash密码:$2a$10$zt6dUMTjNSyzINTGyiAgluna3mPm7qdgl26vj4tFpsFO6WlK5lXNm

123456是否匹配$2a$10$zt6dUMTjNSyzINTGyiAgluna3mPm7qdgl26vj4tFpsFO6WlK5lXNm:true

654321是否匹配$2a$10$zt6dUMTjNSyzINTGyiAgluna3mPm7qdgl26vj4tFpsFO6WlK5lXNm:false

BCrypt 产生随机盐（盐的作用就是每次做出来的菜味道都不一样）。这一点很重要，因为这意味着每次encode将产生不同的结果。

前言

个人打算开发个视频编辑的APP，然后把一些用上的技术总结一下，这次主要是APP的底部菜单栏用到了一个自定义View去绘制实现的，所以这次主要想讲讲自定义View的一些用到的点和自己如何去DIY一个不一样的自定义布局。

实现的效果和思路

可以先看看实现的效果

两个页面的内容还没做，当前就是一个Demo，可以看到底部的菜单栏是一个绘制出来的不规则的一个布局，那要如何实现呢。可以先来看看它的一个绘制区域：

就是一个底部的布局和3个子view，底部的区域当然也是个规则的区域，只不过我们是在这块区域上去进行绘制。

可以把整个过程分为几个步骤：

1. 绘制底部布局

    (1) 绘制矩形区域

    (2) 绘制外圆形区域

    (3) 绘制内圆形区域

2. 添加子view进行布局

3. 处理事件分发的区域 (底部菜单上边的白色区域不触发菜单的事件)

4. 写个动画意思意思

1. 绘制底部布局

这里做的话就没必要手动去添加view这些了，直接全部手动绘制就行。

companion object{



    const val DIMENS_64 = 64.0

    const val DIMENS_96 = 96.0

    const val DIMENS_50 = 50.0

    const val DIMENS_48 = 48.0



    interface OnChildClickListener{

        fun onClick(index : Int)

    }



}



private var paint : Paint ?= null  // 绘制蓝色区域的画笔

private var paint2 : Paint ?= null  // 绘制白色内圆的画笔

private var allHeight : Int = 0  // 总高度，就是绘制的范围

private var bgHeight : Int = 0  // 背景的高度，就是蓝色矩阵的范围

private var mRadius : Int = 0  // 外圆的高度

private var mChildSize : Int = 0

private var mChildCenterSize : Int = 0



private var mWidthZone1 : Int = 0

private var mWidthZone2 : Int = 0

private var mChildCentre : Int = 0



private var childViews : MutableList<View> = mutableListOf()

private var objectAnimation : ObjectAnimator ?= null

var onChildClickListener : OnChildClickListener ?= null



init {

    initView()

}



private fun initView(){

    val lp = ViewGroup.LayoutParams(ViewGroup.LayoutParams.MATCH_PARENT,

        DimensionUtils.dp2px(context, DIMENS_64).toInt())

    layoutParams = lp



    allHeight = DimensionUtils.dp2px(context, DIMENS_96).toInt()

    bgHeight = DimensionUtils.dp2px(context, DIMENS_64).toInt()

    mRadius = DimensionUtils.dp2px(context, DIMENS_50).toInt()

    mChildSize = DimensionUtils.dp2px(context, DIMENS_48).toInt()

    mChildCenterSize = DimensionUtils.dp2px(context, DIMENS_64).toInt()

    setWillNotDraw(false)



    initPaint()

}



private fun initPaint(){

    paint = Paint()

    paint?.isAntiAlias = true

    paint?.color = context.resources.getColor(R.color.kylin_main_color)



    paint2 = Paint()

    paint2?.isAntiAlias = true

    paint2?.color = context.resources.getColor(R.color.kylin_third_color)

}

上边是先把一些尺寸给定义好（我这边是没有设计图，自己去直接调整的，所以可能有些视觉效果不太好，如果有设计师帮忙的话效果肯定会好些），绘制流程就是绘制3个形状，然后代码里也加了些注释哪个变量有什么用，这步应该不难，没什么可以多解释的。

override fun onMeasure(widthMeasureSpec: Int, heightMeasureSpec: Int) {

    super.onMeasure(widthMeasureSpec, heightMeasureSpec)

    val wSize = MeasureSpec.getSize(widthMeasureSpec)

    // 拿到子view做操作的，和这步无关，可以先不看

    if (childViews.size <= 0) {

        for (i in 0 until childCount) {

            val cView = getChildAt(i)

            initChildView(cView, i)

            childViews.add(cView)

            if (i == childCount/2){

                val ms: Int = MeasureSpec.makeMeasureSpec(mRadius, MeasureSpec.AT_MOST)

                measureChild(cView, ms, ms)

            }else {

                val ms: Int = MeasureSpec.makeMeasureSpec(mChildSize, MeasureSpec.AT_MOST)

                measureChild(cView, ms, ms)

            }

        }

    }



    setMeasuredDimension(wSize, allHeight)

}

这步其实也很简单，就是说给当前自定义view设置高度为allHeight

override fun onDraw(canvas: Canvas?) {

    super.onDraw(canvas)

    // 绘制长方形区域

    canvas?.drawRect(left.toFloat(), ((allHeight - bgHeight).toFloat()),

        right.toFloat(), bottom.toFloat(), paint!!)



    // 绘制圆形区域

    paint?.let {

        canvas?.drawCircle(

            (width/2).toFloat(), mRadius.toFloat(),

            mRadius.toFloat(),

            it

        )

    }



    // 绘制内圆区域

    paint2?.let {

        canvas?.drawCircle(

            (width/2).toFloat(), mRadius.toFloat(),

            (mRadius - 28).toFloat(),

            it

        )

    }

}

最后进行绘制， 就是上面说的绘制3个图形，代码里的注释也说得很清楚。

2. 添加子view

我这里是外面布局去加子view的，想弄得灵活点（但感觉也不太好，后面还是想改成里面定义一套规范来弄会好些，如果自由度太高的话去做自定义就很麻烦，而且实际开发中这种需求也没必要把扩展性做到这种地步，基本就是整个APP只有一个地方使用）

但是这边也只是一个Demo先做个演示。

<com.kylin.libkcommons.widget.BottomMenuBar

    android:id="@+id/bv_content"

    android:layout_width="match_parent"

    android:layout_height="wrap_content"

    android:layout_alignParentBottom="true"

    >



    <ImageView

        android:layout_width="wrap_content"

        android:layout_height="wrap_content"

        android:src="@drawable/home"

        />



    <ImageView

        android:layout_width="wrap_content"

        android:layout_height="wrap_content"

        android:src="@drawable/video"

        />



    <ImageView

        android:layout_width="wrap_content"

        android:layout_height="wrap_content"

        android:src="@drawable/more"

        />



</com.kylin.libkcommons.widget.BottomMenuBar>

override fun onMeasure(widthMeasureSpec: Int, heightMeasureSpec: Int) {

    super.onMeasure(widthMeasureSpec, heightMeasureSpec)

    val wSize = MeasureSpec.getSize(widthMeasureSpec)



    if (childViews.size <= 0) {

        for (i in 0 until childCount) {

            val cView = getChildAt(i)

            initChildView(cView, i)

            childViews.add(cView)

            if (i == childCount/2){

                val ms: Int = MeasureSpec.makeMeasureSpec(mRadius, MeasureSpec.AT_MOST)

                measureChild(cView, ms, ms)

            }else {

                val ms: Int = MeasureSpec.makeMeasureSpec(mChildSize, MeasureSpec.AT_MOST)

                measureChild(cView, ms, ms)

            }

        }

    }



    setMeasuredDimension(wSize, allHeight)

}

拿到子view进行一个管理，做一些初始化的操作，主要是设点击事件这些，这里不是很重要。

override fun onLayout(changed: Boolean, l: Int, t: Int, r: Int, b: Int) {

    if (mChildCentre == 0){

        mChildCentre = width / 6

    }



    // 辅助事件分发区域

    if (mWidthZone1 == 0 || mWidthZone2 == 0) {

        mWidthZone1 = width / 2 - mRadius / 2

        mWidthZone2 = width / 2 + mRadius / 2

    }



    // 设置每个子view的显示区域

    for (i in 0 until childViews.size) {

        if (i == childCount/2){

            childViews[i].layout(mChildCentre*(2*i+1) - mChildCenterSize/2 ,

                allHeight/2 - mChildCenterSize/2,

                mChildCentre*(2*i+1) + mChildCenterSize/2 ,

                allHeight/2 + mChildCenterSize/2)

        }else {

            childViews[i].layout(mChildCentre*(2*i+1) - mChildSize/2 ,

                allHeight - bgHeight/2 - mChildSize/2,

                mChildCentre*(2*i+1) + mChildSize/2 ,

                allHeight - bgHeight/2 + mChildSize/2)

        }

    }



}

进行布局，这里比较重要，因为能看出，中间的图标会更大一些，所以要做一些适配。其实这里就是把宽度分为6块，然后3个view分别在1,3,5这三个左边点，y的话就是除中间那个，其它两个都是bgHeight绘制高度的的一半，中间那个是allHeight总高度的一半，这样3个view的x和y坐标都能拿到了，再根据宽高就能算出l,t,r,b四个点，然后布局。

3. 处理事件分发

可以看出我们的区域是一个不规则的区域，按照我们用抽象的角度去思考，我们希望这个菜单栏的区域只是显示蓝色的那个区域，所以蓝色区域上面的白色区域就算是我们自定义view的范围，他触发的事件也应该是后面的view的事件（Demo中后面的View是一个ViewPager），而不是菜单栏。

// 辅助事件分发区域

if (mWidthZone1 == 0 || mWidthZone2 == 0) {

    mWidthZone1 = width / 2 - mRadius / 2

    mWidthZone2 = width / 2 + mRadius / 2

}

这两块是圆外的x的区域。

/**

 *  判断点击事件是否在点击区域中

 */

private fun isShowZone(x : Float, y : Float) : Boolean{

    if (y >= allHeight - bgHeight){

        return true

    }

    if (x >= mWidthZone1 && x <= mWidthZone2){

        // 在圆内

        val relativeX = abs(x - width/2)

        val squareYZone = mRadius.toDouble().pow(2.0) - relativeX.toDouble().pow(2.0)

        return y >= mRadius - sqrt(squareYZone)

    }

    return false

}

先判断y如果在背景的矩阵中（上面说了自定义view分成矩阵，外圆，内圆），那肯定是菜单的区域。如果不在，那就要判断y在不在圆内，这里就必须用勾股定理去判断。

override fun onTouchEvent(event: MotionEvent?): Boolean {

    // 点击区域进行拦截

    if (event?.action == MotionEvent.ACTION_DOWN && isShowZone(event.x, event.y)){

        return true

    }

    return super.onTouchEvent(event)

}

最后做一个事件分发的拦截。除了计算区域那可能需要去想想，其它地方我觉得都挺好理解的吧。

4. 做个动画

给子view设点击事件让外部处理，然后给中间的按钮做个动画效果。

private fun initChildView(cView : View?, index : Int) {

    cView?.setOnClickListener {

        if (index == childViews.size/2) {

            startAnim(cView)

        }else {

            onChildClickListener?.onClick(index)

        }

    }

}

private fun startAnim(view : View){

    if (objectAnimation == null) {

        objectAnimation = ObjectAnimator.ofFloat(view,

            "rotation", 0f, -15f, 180f, 0f)

        objectAnimation?.addListener(object : Animator.AnimatorListener {



            override fun onAnimationStart(p0: Animator) {

            }



            override fun onAnimationEnd(p0: Animator) {

                onChildClickListener?.onClick(childViews.size / 2)

            }



            override fun onAnimationCancel(p0: Animator) {

                onChildClickListener?.onClick(childViews.size / 2)

            }



            override fun onAnimationRepeat(p0: Animator) {

            }



        })

        objectAnimation?.duration = 1000

        objectAnimation?.interpolator = AccelerateDecelerateInterpolator()

    }

    objectAnimation?.start()

}

注意做释放操作。

fun onDestroy(){

    try {

        objectAnimation?.cancel()

        objectAnimation?.removeAllListeners()

    }catch (e : Exception){

        e.printStackTrace()

    }finally {

        objectAnimation = null

    }

}

5. 小结

其实代码都挺简单的，关键是你要去想出一个方法来实现这个场景，然后感觉这个自定义viewgroup也是比较经典的，涉及到measure、layout、draw，涉及到动画，涉及到点击冲突。

这个Demo表示你要实现怎样的效果都可以，只要是draw能画出来的，你都能实现，我这个是中间凸出来，你可以实现凹进去，你可以实现波浪的样子，可以实现复杂的曲线，都行，你用各种基础图形去做拼接，或者画贝塞尔等等，其实都不难，主要是要有个计算和调试的过程。但是你的形状要和点击区域关联起来，你设计的图案越复杂，你要适配的点击区域计算量就越大。

甚至我还能做得效果更屌的是，那3个子view的图标，我都能画出来，就不用ImagerView，直接手动画出来，这样做的好处是什么呢？我对子view的图标能做各种炫酷的属性动画，我在切换viewpager时对图标做属性动画，那不得逼格再上一层。 为什么我没做呢，因为没有设计，我自己做的话要花大量的时间去调，要是有设计的话他告诉我尺寸啊位置啊这些信息，做起来就很快。我的APP主要是打算实现视频的编辑为主，所以这些支线就没打算花太多时间去处理。

一、简介

了解过协程Flow 的同学知道是典型的冷数据流，而SharedFlow与StateFlow则是热数据流。

• 冷流：只有当订阅者发起订阅时，事件的发送者才会开始发送事件。


• 热流：不管订阅者是否存在，只要发送了事件就会被消费，意思是不管接受方是否能够接收到，在这一点上有点像我们Android的LiveData。

解释：LiveData新的订阅者不会接收到之前发送的事件，只会收到之前发送的最后一条数据，这个特性和SharedFlow的参数replay设置为1相似

二、使用分析

最好的分析是从使用时入手冷流flow，热流SharedFlow和StateFlow热流的具体的实现类分别是MutableSharedFlow和MutableStateFlow

用一个简单的例子来说明什么是冷流，什么是热流。

• 冷流flow:

private fun testFlow() {

    val flow = flow<Int> {

        (1..5).forEach {

            delay(1000)

            emit(it)

        }

    }

    mBind.btCollect.setOnClickListener {

        lifecycleScope.launch {

            flow.collect {

                Log.d(TAG, "testFlow 第一个收集器: 我是冷流：$it")

            }

        }

        lifecycleScope.launch {

            delay(5000)

            flow.collect {

                Log.d(TAG, "testFlow:第二个收集器 我是冷流：$it")

            }

        }

    }



}

我点击收集按钮响应事件后，打印结果如下图：

这就是冷流，需要去触发收集，才能接收到结果。

从上图时间可知flow每次重新订阅收集都会将所有事件重新发送一次

• 热流MutableSharedFlow和

private fun testSharedFlow() {



    val sharedFlow = MutableSharedFlow<Int>(

        replay = 0,//相当于粘性数据

        extraBufferCapacity = 0,//接受的慢时候，发送的入栈

        onBufferOverflow = BufferOverflow.SUSPEND

    )

    lifecycleScope.launch {

        launch {



            sharedFlow.collect {

                println("collect1 received ago shared flow $it")



            }

        }

        launch {

            (1..5).forEach {

                println("emit1  send ago  flow $it")

                sharedFlow.emit(it)

                println("emit1 send after flow $it")

            }

        }

        // wait a 100

        delay(100)

        launch {

            sharedFlow.collect {

                println("collect2 received shared flow $it")

            }

        }

    }



}

第二个流收集被延迟，晚了100毫秒后就收不到了，想当于不管是否订阅，流都会发送，只管发，而collect1能够收集到是因为他在发送之前进行了订阅收集。

三、分析MutableSharedFlow中参数的具体含义

以上面testSharedFlow（）方法中对象为例，上面的配置就是，当前对象的默认配置
源码如下图：

val sharedFlow = MutableSharedFlow<Int>(

    replay = 0,//相当于粘性数据

    extraBufferCapacity = 0,//接受的慢时候，发送的入栈

    onBufferOverflow = BufferOverflow.SUSPEND //产生背压现象后的，执行策略

)

3.1、 reply:事件粘滞数

reply:事件粘滞数以testSharedFlow方法为例如果设置了数目的话，那么其他订阅者不管什么时候订阅都能够收到replay数目的最新的事件，reply=1的话有点类似Android中使用的livedata。

eg:和testSharedFlow方法区别在于 replay = 2

private fun testSharedFlowReplay() {



    val sharedFlow = MutableSharedFlow<Int>(

        replay = 2,//相当于粘性数据

        extraBufferCapacity = 0,//接受的慢时候，发送的入栈

        onBufferOverflow = BufferOverflow.SUSPEND

    )

    lifecycleScope.launch {

        launch {



            sharedFlow.collect {

                println("collect1 received ago shared flow $it")



            }

        }

        launch {

            (1..5).forEach {

                println("emit1  send ago  flow $it")

                sharedFlow.emit(it)

                println("emit1 send after flow $it")

            }

        }

        // wait a minute

        delay(100)

        launch {

            sharedFlow.collect {

                println("collect2 received shared flow $it")

            }

        }

    }



}

按照上面的解释collect2会收集到最新的4，5两个事件如下图：

3.2 extraBufferCapacity：缓存容量

extraBufferCapacity：缓存容量，就是先发送几个事件，不管已经订阅的消费者是否接收，这种只管发不管消费者消费能力的情况就会出现背压，参数onBufferOverflow就是用于处理背压问题

eg:和testSharedFlow方法区别在于 extraBufferCapacity = 2

private fun testSharedFlowCapacity() {



    val sharedFlow = MutableSharedFlow<Int>(

        replay = 0,//相当于粘性数据

        extraBufferCapacity = 2,//接受的慢时候，发送的入栈

        onBufferOverflow = BufferOverflow.SUSPEND

    )

    lifecycleScope.launch {

        launch {



            sharedFlow.collect {

                println("collect1 received ago shared flow $it")



            }

        }

        launch {

            (1..5).forEach {

                println("emit1  send ago  flow $it")

                sharedFlow.emit(it)

                println("emit1 send after flow $it")

            }

        }

        // wait a minute

        delay(100)

        launch {

            sharedFlow.collect {

                println("collect2 received shared flow $it")

            }

        }

    }



}

结果如下图：

优先发送将其缓存起来，testSharedFlow测试中发送与接收在没有干扰（延时之类的干扰）的情况下 是一条顺序链，而设置了extraBufferCapacity优先发送两条，不管消费情况，不设置的话（extraBufferCapacity = 0）这时如果在collect1里面设置延时delay（100），send会被阻塞（因为默认是 onBufferOverflow = BufferOverflow.SUSPEND的策略）

3.3、onBufferOverflow

onBufferOverflow：由背压就有处理策略，sharedflow默认为BufferOverflow.SUSPEND
，也即是如果当事件数量超过缓存，发送就会被挂起，上面提到了一句，DROP_OLDEST销毁最旧的值，DROP_LATEST销毁最新的值

三种参数含义

public enum class BufferOverflow {

    /**

     * 在缓冲区溢出时挂起。

     */

    SUSPEND,



    /**

     * 在缓冲区溢出时删除** *旧的**值，添加新的值到缓冲区，不挂起。

     */

    DROP_OLDEST,



    /**

     * 在缓冲区溢出时，删除当前添加到缓冲区的最新的**值\

*(使缓冲区内容保持不变)，不要挂起。

     */

    DROP_LATEST

}

eg:和testSharedFlowCapacity方法区别在于 多了个delay(100)

• SUSPEND模式

private fun testSharedFlow2() {



    val sharedFlow = MutableSharedFlow<Int>(

        replay = 0,//相当于粘性数据

        extraBufferCapacity = 2,//接受的慢时候，发送的入栈

        onBufferOverflow = BufferOverflow.SUSPEND

    )

    lifecycleScope.launch {

        launch {



            sharedFlow.collect {

                println("collect1 received ago shared flow $it")

                delay(100)

            }

        }

        launch {

            (1..5).forEach {

                println("emit1  send ago  flow $it")

                sharedFlow.emit(it)

                println("emit1 send after flow $it")

            }

        }

        // wait a minute

        delay(100)

        launch {

            sharedFlow.collect {

                println("collect2 received shared flow $it")

            }

        }

    }



}

SUSPEND情况下从第一张图知道collect1都收集了，第二张图发现collect2也打印了两次，为什么只有两次呢？

因为 extraBufferCapacity = 2,等于2，错过了两次的事件发送的接收，不信的话可以试一下extraBufferCapacity = 0，这时候肯定打印了4次，可能有人问为什么是4次呢，因为collect2的订阅者延时了100毫秒才开始订阅，

• DROP_LATEST模式

private fun testSharedFlow2() {



    val sharedFlow = MutableSharedFlow<Int>(

        replay = 0,//相当于粘性数据

        extraBufferCapacity = 2,//接受的慢时候，发送的入栈

        onBufferOverflow = BufferOverflow.DROP_LATEST



    )

    lifecycleScope.launch {

        launch {



            sharedFlow.collect {

                println("collect1 received ago shared flow $it")

                delay(100)

            }

        }

        launch {

            (1..5).forEach {

                println("emit1  send ago  flow $it")

                sharedFlow.emit(it)

                println("emit1 send after flow $it")

            }

        }

        // wait a minute

        delay(100)

        launch {

            sharedFlow.collect {

                println("collect2 received shared flow $it")

            }

        }

    }



}

发送过快的话，销毁最新的，只保留最老的两条事件，我们可以知道1，2，肯定保留其他丢失

要想不丢是怎么办呢，很简单不要产生背压现象就行，在emit中延时delay（200）,比收集耗时长就行。

• DROP_OLDEST模式
  该模式同理DROP_LATEST模式，保留最新的extraBufferCapacity = 2（多少）的数据就行。

四、StateFlow

初始化

val stateFlow = MutableStateFlow<Int>(value = -1)

由上图的继承关系可知stateFlow其实就是一种特殊的SharedFlow,它多了个初始值value

由上图可知：每次更新数据都会和旧数据做一次比较，只有不同时候才会更新数值。

SharedFlow和StateFlow的侧重点

• StateFlow就是一个replaySize=1的sharedFlow,同时它必须有一个初始值，此外，每次更新数据都会和旧数据做一次比较，只有不同时候才会更新数值。


• StateFlow重点在状态，ui永远有状态，所以StateFlow必须有初始值，同时对ui而言，过期的状态毫无意义，所以stateFLow永远更新最新的数据（和liveData相似），所以必须有粘滞度=1的粘滞事件，让ui状态保持到最新。另外在一个时间内发送多个事件，不会管中间事件有没有消费完成都会执行最新的一条.(中间值会丢失)


• SharedFlow侧重在事件，当某个事件触发，发送到队列之中，按照挂起或者非挂起、缓存策略等将事件发送到接受方，在具体使用时，SharedFlow更适合通知ui界面的一些事件，比如toast等，也适合作为viewModel和repository之间的桥梁用作数据的传输。

eg测试如下中间值丢失：

    private fun testSharedFlow2() {

        val stateFlow = MutableStateFlow<Int>(value = -1)



        lifecycleScope.launch {

            launch {



                stateFlow.collect {

                    println("collect1 received ago shared flow $it")

                }

            }

            launch {

                (1..5).forEach {

                    println("emit1  send ago  flow $it")

                    stateFlow.emit(it)

                    println("emit1 send after flow $it")

                }

            }

            // wait a minute

            delay(100)

            launch {

                stateFlow.collect {

                    println("collect2 received shared flow $it")

                }

            }

        }



    }

由下图可知，中间值丢失，collect2结果可知永远有状态

好了到这里文章就结束了，源码分析后续再写。

前言

协程通信三剑客：Channel、Select、Flow，上篇已经分析了Channel的深水区，本篇将会重点分析Select的使用及原理。
通过本篇文章，你将了解到：

1. Select 的引入
2. Select 的使用
3. Invoke函数 的妙用
4. Select 的原理
5. Select 注意事项

1. Select 的引入

多路数据的选择

串行执行

如今的二维码识别应用场景越来越广了，早期应用比较广泛的识别SDK如zxing、zbar，它们各有各的特点，也存在识别不出来的情况，为了将两者优势结合起来，我们想到的方法是同一份二维码图片分别给两者进行识别。
如下：

    //从zxing 获取二维码信息

    suspend fun getQrcodeInfoFromZxing(bitmap: Bitmap?): String {

        //模拟耗时

        delay(2000)

        return "I'm fish"

    }



    //从zbar 获取二维码信息

    suspend fun getQrcodeInfoFromZbar(bitmap: Bitmap?): String {

        delay(1000)

        return "I'm fish"

    }



    fun testSelect() {

        runBlocking {

            var bitmap = null

            var starTime = System.currentTimeMillis()

            var qrcoe1 = getQrcodeInfoFromZxing(bitmap)

            var qrcode2 = getQrcodeInfoFromZbar(bitmap)

            println("qrcode1=$qrcoe1 qrcode2=$qrcode2 useTime:${System.currentTimeMillis() - starTime} ms")

        }

    }

查看打印，最后花费的时间：

qrcode1=I'm fish qrcode2=I'm fish useTime:3013 ms

当然这是串行的方式效率比较低，我们想到了用协程来优化它。

协程并行执行

如下：

    fun testSelect1() {

        var bitmap = null;

        var starTime = System.currentTimeMillis()

        var deferredZxing = GlobalScope.async {

            getQrcodeInfoFromZxing(bitmap)

        }



        var deferredZbar = GlobalScope.async {

            getQrcodeInfoFromZbar(bitmap)

        }



        runBlocking {

            //挂起等待识别结果

            var qrcoe1 = deferredZxing.await()

            //挂起等待识别结果

            var qrcode2 = deferredZbar.await()

            println("qrcode1=$qrcoe1 qrcode2=$qrcode2 useTime:${System.currentTimeMillis() - starTime} ms")

        }

    }

查看打印，最后花费的时间：

qrcode1=I'm fish qrcode2=I'm fish useTime:2084 ms

可以看出，花费时间明显变少了。
与上个Demo 相比，虽然识别过程是放在协程里并行执行的，但是在等待识别结果却是串行的。我们引入两个识别库的初衷是哪个识别快就用哪个的结果，为了达成这个目的，传统的方式是：

同时监听并记录识别结果的返回。

同时监听多路结果

如下：

    fun testSelect2() {

        var bitmap = null;

        var starTime = System.currentTimeMillis()

        var deferredZxing = GlobalScope.async {

            getQrcodeInfoFromZxing(bitmap)

        }



        var deferredZbar = GlobalScope.async {

            getQrcodeInfoFromZbar(bitmap)

        }



        var isEnd = false

        var result: String? = null

        GlobalScope.launch {

            if (!isEnd) {

                //没有结束，则继续识别

                var resultTmp = deferredZxing.await()

                if (!isEnd) {

                    //识别没有结束，说明自己是第一个返回结果的

                    result = resultTmp

                    println("zxing recognize ok useTime:${System.currentTimeMillis() - starTime} ms")

                    //标记识别结束

                    isEnd = true

                }

            }

        }



        GlobalScope.launch {

            if (!isEnd) {

                var resultTmp = deferredZbar.await()

                if (!isEnd) {

                    //识别没有结束，说明自己是第一个返回结果的

                    result = resultTmp

                    println("zbar recognize ok useTime:${System.currentTimeMillis() - starTime} ms")

                    isEnd = true

                }

            }

        }



        //检测是否有结果返回

        runBlocking {

            while (!isEnd) {

                delay(1)

            }

            println("recognize result:$result")

        }

    }

通过检测isEnd 标记来判断是否有某个模块返回结果。
结果如下：

• zbar recognize ok useTime:1070 ms
• recognize result:I'm fish

由于模拟设定的zbar 解析速度快，因此每次都是采纳的是zbar的结果，所花费的时间大幅减少了，该结果符合预期。

Select 闪亮登场

虽说上个Demo结果符合预期，但是多了很多额外的代码、多引入了其它协程，并且需要子模块对标记进行赋值（对"isEnd"进行赋值），没有达到解耦的目的。我们希望子模块的任务是单一且闭环的，如果能在一个函数里统一检测结果的返回就好了。
Select 就是为了解决多路数据的选择而生的。
来看看它是怎么解决该问题的：

    fun testSelect3() {

        var bitmap = null;

        var starTime = System.currentTimeMillis()

        var deferredZxing = GlobalScope.async {

            getQrcodeInfoFromZxing(bitmap)

        }

        var deferredZbar = GlobalScope.async {

            getQrcodeInfoFromZbar(bitmap)

        }

        runBlocking {

            //通过select 监听zxing、zbar 结果返回

            var result = select<String> {

                //监听zxing

                deferredZxing.onAwait {value->

                    //value 为deferredZxing 识别的结果

                    "zxing result $value"

                }



                //监听zbar

                deferredZbar.onAwait { value->

                    "zbar result $value"

                }

            }



            //运行到此，说明已经有结果返回

            println("result from $result useTime:${System.currentTimeMillis() - starTime}")

        }

    }

结果如下：

result from zbar result I'm fish useTime:1079

符合预期，同时可以看出：相比上个Demo，这样写简洁了许多。

2. Select 的使用

除了可以监听async的结果，Select 还可以监听Channel的发送方/接收方 数据，我们以监听接收方数据为例：

    fun testSelect4() {

        runBlocking {

            var bitmap = null;

            var starTime = System.currentTimeMillis()

            var receiveChannelZxing = produce {

                //生产数据

                var result = getQrcodeInfoFromZxing(bitmap)

                //发送数据

                send(result)

            }



            var receiveChannelZbar = produce {

                var result = getQrcodeInfoFromZbar(bitmap)

                send(result)

            }



            var result = select<String> {

                //监听是否有数据发送过来

                receiveChannelZxing.onReceive {

                    value->"zxing result $value"

                }



                receiveChannelZbar.onReceive {

                        value->"zbar result $value"

                }

            }



            println("result from $result useTime:${System.currentTimeMillis() - starTime}")

        }

    }

结果如下：

result from zbar result I'm fish useTime:1028

不论是async还是Channel，Select 都可以监听它们的数据，从而形成多路复用的效果。

在监听协程里调用select 表达式，表达式{}内声明需要监听的协程的数据，对于select 来说有两种场景：

1. 没有数据，则select 挂起协程并等待直到其它协程数据准备完成后再次恢复select 所在的协程。
2. 有数据，则select 正常执行并返回获取的数据。

3. Invoke函数 的妙用

在分析Select 原理之前，需要弄明白invoke函数的原理。
对于Kotlin 类来说，都可以重写其invoke函数。

    operator fun invoke():String {

        return "I'm fish"

    }

如上，重写了SelectDemo里的invoke函数，和普通成员函数一样，我们可以通过对象调用它。

fun main(args: Array<String>) {

    var selectDemo = SelectDemo()

    var result = selectDemo.invoke()

    println("result：$result")

}

当然，可以进一步简化：

fun main(args: Array<String>) {

    var selectDemo = SelectDemo()

    var result = selectDemo()

    println("result：$result")

}

这里涉及到了kotlin的语法糖：对象居然可以像函数一样调用。
作为函数，invoke 当然也可以接收高阶函数作为参数：

    operator fun invoke(block: (Int) -> String): String {

        return block(3)

    }



fun main(args: Array<String>) {

    var selectDemo = SelectDemo()

    var result = selectDemo { age ->

        when (age) {

            3 -> "I'm fish3"

            4 -> "I'm fish4"

            else -> "error"

        }

    }

    println("result：$result")

}

因此，当看到对象作为函数调用时，实际上调用的是invoke函数，具体的逻辑需要查看其invoke函数的实现。

4. Select 的原理

上篇分析过Channel，因此本篇趁热打铁，通过Select 监听Channel数据的变化来分析其原理，为方便讲解，我们先以监听一个Channel的为例。
先从select 表达式本身入手。

    fun testSelect5() {

        runBlocking {

            var starTime = System.currentTimeMillis()

            var receiveChannelZxing = produce {

                //发送数据

                send("I'm fish")

            }



            //确保channel 数据已经send

            delay(1000)

            var result = select<String> {

                //监听是否有数据发送过来

                receiveChannelZxing.onReceive { value ->

                    "zxing result $value"

                }

            }

            println("result from $result useTime:${System.currentTimeMillis() - starTime}")

        }

    }

select 是挂起函数，因此协程运行到此有可能被挂起。

#Select.kt

public suspend inline fun <R> select(crossinline builder: SelectBuilder<R>.() -> Unit): R {

    //...

    return suspendCoroutineUninterceptedOrReturn { uCont ->

        //传入父协程体

        val scope = SelectBuilderImpl(uCont)

        try {

            //执行builder

            builder(scope)

        } catch (e: Throwable) {

            scope.handleBuilderException(e)

        }

        //通过返回值判断是否需要挂起协程

        scope.getResult()

    }

}

重点看builder(scope)，builder 是高阶函数，实际上就是执行了select花括号里的内容，而它里面就是监听数据是否返回。

receiveChannelZxing.onReceive
刚开始看的时候势必以为onReceive是个函数，然而它是ReceiveChannel 里的成员变量：

#Channel.kt

    public val onReceive: SelectClause1<E>

通过上一节的分析可知，关键是要找到SelectClause1 的invoke的实现。

#Select.kt

public interface SelectBuilder<in R> {

    //block 有个入参

    //声明了SelectClause1的扩展函数invoke

    public operator fun <Q> SelectClause1<Q>.invoke(block: suspend (Q) -> R)

}



override fun <Q> SelectClause1<Q>.invoke(block: suspend (Q) -> R) {

    //SelectBuilderImpl 实现了 SelectClause1 的invoke函数

    registerSelectClause1(this@SelectBuilderImpl, block)

}

再看onReceive 的赋值：

#AbstractChannel.kt

final override val onReceive: SelectClause1<E>

    get() = object : SelectClause1<E> {

        @Suppress("UNCHECKED_CAST")

        override fun <R> registerSelectClause1(select: SelectInstance<R>, block: suspend (E) -> R) {

            registerSelectReceiveMode(select, RECEIVE_THROWS_ON_CLOSE, block as suspend (Any?) -> R)

        }

    }

因此，简单总结调用栈如下：

当调用receiveChannelZxing.onReceive{}，实际上调用了SelectClause1.invoke()，而它里面又调用了SelectClause1.registerSelectClause1()，最终调用了AbstractChannel.registerSelectReceiveMode。

AbstractChannel. registerSelectReceiveMode

#AbstractChannel.kt

private fun <R> registerSelectReceiveMode(select: SelectInstance<R>, receiveMode: Int, block: suspend (Any?) -> R) {

    while (true) {

        //如果已经有结果了，则直接返回------->①

        if (select.isSelected) return

        if (isEmptyImpl) {

            //没有发送者在等待，则入队等待，并返回 ------->②

            if (enqueueReceiveSelect(select, block, receiveMode)) return

        } else {

            //直接取出值------->③

            val pollResult = pollSelectInternal(select)

            when {

                pollResult === ALREADY_SELECTED -> return

                pollResult === POLL_FAILED -> {} // retry

                pollResult === RETRY_ATOMIC -> {} // retry

                //调用block------->④

                else -> block.tryStartBlockUnintercepted(select, receiveMode, pollResult)

            }

        }

    }

}

分为4个点，接着来一一分析。
①
select 同时监听多个值，若是有1个符合要求的数据返回了，那么该isSelected 标记为true，当检测到该标记为true时直接退出。
结合之前的Demo，zbar 已经识别出结果了，当select 检测zxing的结果时直接返回。

②

#AbstractChannel.kt

private fun <R> enqueueReceiveSelect(

    select: SelectInstance<R>,

    block: suspend (Any?) -> R,

    receiveMode: Int

): Boolean {

    //构造为Node元素

    val node = AbstractChannel.ReceiveSelect(this, select, block, receiveMode)

    //添加到Channel队列里

    val result = enqueueReceive(node)

    if (result) select.disposeOnSelect(node)

    return result

当select 时，发现Channel里没有数据，说明Channel还没有开始send，因此构造了Node(ReceiveSelect)加入到Channel queue里。当send数据时，会查找queue里是否有接收者等待，若有则调用Node(ReceiveSelect.completeResumeReceive)：

#AbstractChannel.kt

        override fun completeResumeReceive(value: E) {

            block.startCoroutineCancellable(

                if (receiveMode == RECEIVE_RESULT) ChannelResult.success(value) else value,

                select.completion,

                resumeOnCancellationFun(value)

            )

        }

block 被调度执行，最后会恢复select 协程的执行。

③
取出数据，并尝试恢复send协程。

④
在③的基础上，拿到数据后，直接执行block（此时并没有切换线程进行调度）。

小结一下select 原理：

可以看出：

select 本身执行并不耗时，若最终没有数据返回则挂起等待，若是有数据返回则不会挂起协程。

我们从头再捋一下select 配合Channel 的原理：

虽然以Channel为例讲解了select 原理，实际上async等结合select 原理大致差不多，重点都是利用了协程的挂起/恢复做文章。

5. Select 注意事项

如果select有多个数据同时到达，select 默认会选择第一个数据，若想要随机选择数据，可做如下处理：

            var result = selectUnbiased<String> {

                //监听是否有数据发送过来

                receiveChannelZxing.onReceive { value ->

                    "zxing result $value"

                }

            }

想要知道select 还可以监听哪些数据，可查看该数据是否实现了SelectClauseX(X 表示0、1、2）。

以上即为Select 的原理及其使用，下篇将会进入协程的精华部分：Flow的运用，该部分内容较多，可能会分几篇分析，敬请期待。

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

    本文分析示例代码如下：

launch(Dispatchers.Main) {

  flow {

    emit(1)

    emit(2)

  }.flowOn(Dispatchers.IO).collect {

    delay(1000)



    withContext(Dispatchers.IO) {

      Log.d("liduo", "$it")

    }



    Log.d("liduo", "$it")

  }

}

一.flowOn方法

    flowOn方法用于将上游的流切换到指定协程上下文的调度器中执行，同时不会把协程上下文暴露给下游的流，即flowOn方法中协程上下文的调度器不会对下游的流生效。如下面这段代码所示：

launch(Dispatchers.Main) {

  flow {

    emit(2) // 执行在IO线程池

  }.flowOn(Dispatchers.IO).map {

    it + 1 // 执行在Default线程池

  }.flowOn(Dispatchers.Default).collect {

    Log.d("liduo", "$it") //执行在主线程

  }

}

    接下来，分析一下flowOn方法，代码如下：

public fun <T> Flow<T>.flowOn(context: CoroutineContext): Flow<T> {

    // 检查当前协程没有执行结束

    checkFlowContext(context)

    return when {

        // 为空，则返回自身

        context == EmptyCoroutineContext -> this

        // 如果是可融合的Flow，则尝试融合操作，获取新的流

        this is FusibleFlow -> fuse(context = context)

        // 其他情况，包装成可融合的Flow

        else -> ChannelFlowOperatorImpl(this, context = context)

    }

}



// 确保Job不为空

private fun checkFlowContext(context: CoroutineContext) {

    require(context[Job] == null) {

        "Flow context cannot contain job in it. Had $context"

    }

}

    在flowOn方法中，首先会检查方法所在的协程是否执行结束。如果没有结束，则会执行判断语句，这里flowOn方法传入的上下文不是空上下文，且通过flow方法构建出的Flow对象也不是FusibleFlow类型的对象，因此这里会走到else分支，将上游flow方法创建的Flow对象和上下文包装成ChannelFlowOperatorImpl类型的对象。

1.ChannelFlowOperatorImpl类

    ChannelFlowOperatorImpl类继承自ChannelFlowOperator类，用于将上游的流包装成一个ChannelFlow对象，它的继承关系如下图所示：

    通过上图可以知道，ChannelFlowOperatorImpl类最终继承了ChannelFlow类，代码如下：

internal class ChannelFlowOperatorImpl<T>(

    flow: Flow<T>,

    context: CoroutineContext = EmptyCoroutineContext,

    capacity: Int = Channel.OPTIONAL_CHANNEL,

    onBufferOverflow: BufferOverflow = BufferOverflow.SUSPEND

) : ChannelFlowOperator<T, T>(flow, context, capacity, onBufferOverflow) {

    // 用于流融合时创建新的流

    override fun create(context: CoroutineContext, capacity: Int, onBufferOverflow: BufferOverflow): ChannelFlow<T> =

        ChannelFlowOperatorImpl(flow, context, capacity, onBufferOverflow)

    

    // 若当前的流不需要通过Channel即可实现正常工作时，会调用此方法

    override fun dropChannelOperators(): Flow<T>? = flow

    

    // 触发对下一级流进行收集

    override suspend fun flowCollect(collector: FlowCollector<T>) =

        flow.collect(collector)

}

二.collect方法

    在Kotlin协程：Flow基础原理中讲到，当执行collect方法时，内部会调用最后产生的Flow对象的collect方法，代码如下：

public suspend inline fun <T> Flow<T>.collect(crossinline action: suspend (value: T) -> Unit): Unit =

    collect(object : FlowCollector<T> {

        override suspend fun emit(value: T) = action(value)

    })

    这个最后产生的Flow对象就是ChannelFlowOperatorImpl类对象。

1.ChannelFlowOperator类的collect方法

    ChannelFlowOperatorImpl类没有重写collect方法，因此调用的是它的父类ChannelFlowOperator类的collect方法，代码如下：

override suspend fun collect(collector: FlowCollector<T>) {

    // OPTIONAL_CHANNEL为默认值，这里满足条件，之后会详细讲解

    if (capacity == Channel.OPTIONAL_CHANNEL) {

        // 获取当前协程的上下文

        val collectContext = coroutineContext

        // 计算新的上下文

        val newContext = collectContext + context

        // 如果前后上下文没有发生变化

        if (newContext == collectContext)

            // 直接触发对下一级流的收集

            return flowCollect(collector)

        // 如果上下文发生变化，但不需要切换线程

        if (newContext[ContinuationInterceptor] == collectContext[ContinuationInterceptor])

            // 切换协程上下文，调用flowCollect方法触发下一级流的收集

            return collectWithContextUndispatched(collector, newContext)

    }

    // 调用父类的collect方法

    super.collect(collector)

}



// 获取当前协程的上下文，该方法会被编译器处理

@SinceKotlin("1.3")

@Suppress("WRONG_MODIFIER_TARGET")

@InlineOnly

public suspend inline val coroutineContext: CoroutineContext

    get() {

        throw NotImplementedError("Implemented as intrinsic")

    }

    ChannelFlowOperator类的collect方法在设计上与协程的withContext方法设计思路是一致的：在方法内根据上下文的不同情况进行判断，在必要时才会切换线程去执行任务。

    通过flowOn方法创建的ChannelFlowOperatorImpl类对象，参数capacity为默认值OPTIONAL_CHANNEL。因此代码在执行时会进入到判断中，但因为我们指定了上下文为Dispatchers.IO，因此上下文发生了变化，同时拦截器也发生了变化，所以最后会调用ChannelFlowOperator类的父类的collect方法，也就是ChannelFlow类的collect方法。

2.ChannelFlow类的collect方法

    ChannelFlow类的代码如下：

override suspend fun collect(collector: FlowCollector<T>): Unit =

    coroutineScope {

        collector.emitAll(produceImpl(this))

    }

    在ChannelFlow类的collect方法中，首先通过coroutineScope方法创建了一个作用域协程，接着调用了produceImpl方法，代码如下：

public open fun produceImpl(scope: CoroutineScope): ReceiveChannel<T> =

    scope.produce(context, produceCapacity, onBufferOverflow, start = CoroutineStart.ATOMIC, block = collectToFun)

    produceImpl方法内部调用了produce方法，并且传入了待执行的任务collectToFun。

    produce方法在Kotlin协程：协程的基础与使用中曾提到过，它是官方提供的启动协程的四个方法之一，另外三个方法为launch方法、async方法、actor方法。代码如下：

internal fun <E> CoroutineScope.produce(

    context: CoroutineContext = EmptyCoroutineContext,

    capacity: Int = 0,

    onBufferOverflow: BufferOverflow = BufferOverflow.SUSPEND,

    start: CoroutineStart = CoroutineStart.DEFAULT,

    onCompletion: CompletionHandler? = null,

    @BuilderInference block: suspend ProducerScope<E>.() -> Unit

): ReceiveChannel<E> {

    // 根据容量与溢出策略创建Channel对象

    val channel = Channel<E>(capacity, onBufferOverflow)

    // 计算新的上下文

    val newContext = newCoroutineContext(context)

    // 创建协程

    val coroutine = ProducerCoroutine(newContext, channel)

    // 监听完成事件

    if (onCompletion != null) coroutine.invokeOnCompletion(handler = onCompletion)

    // 启动协程

    coroutine.start(start, coroutine, block)

    return coroutine

}

    在produce方法内部，首先创建了一个Channel类型的对象，接着创建了类型为ProducerCoroutine的协程，并且传入Channel对象作为参数。最后，produce方法返回了一个ReceiveChannel接口指向的对象，当协程执行完毕后，会通过Channel对象将结果通过send方法发送出来。

    至此，可以知道flowOn方法的实现实际上是利用了协程拦截器的拦截功能。

    在这里之后，代码逻辑分成了两部分，一部分是block在ProducerCoroutine协程中的执行，另一部分是通过ReceiveChannel对象获取执行的结果。

3.flow方法中代码的执行

    在produceImpl方法中，调用了produce方法，并且传入了collectToFun对象，这个对象将会在produce方法创建的协程中执行，代码如下：

internal val collectToFun: suspend (ProducerScope<T>) -> Unit

    get() = { collectTo(it) }

    当调用collectToFun对象的invoke方法时，会触发collectTo方法的执行，该方法在ChannelFlowOperator类中被重写，代码如下：

protected override suspend fun collectTo(scope: ProducerScope<T>) =

    flowCollect(SendingCollector(scope))

    在collectTo方法中，首先将参数scope封装成SendingCollector类型的对象，接着调用了flowCollect方法，该方法在ChannelFlowOperatorImpl类中被重写，代码如下：

override suspend fun flowCollect(collector: FlowCollector<T>) =

    flow.collect(collector)

    ChannelFlowOperatorImpl类的flowCollect方法内部调用了flow对象的collect方法，这个flow对象就是最初通过flow方法构建的对象。根据Kotlin协程：Flow基础原理的分析，这个flow对象类型为SafeFlow，最后会通过collectSafely方法，触发flow方法中的block执行。代码如下：

private class SafeFlow<T>(private val block: suspend FlowCollector<T>.() -> Unit) : AbstractFlow<T>() {

    override suspend fun collectSafely(collector: FlowCollector<T>) {

        // 触发执行

        collector.block()

    }

}

    当flow方法在执行过程中需要向下游发出值时，会调用emit方法。根据上面flowCollect方法和collectTo方法可以知道，collectSafely方法的collector对象就是collectTo方法中创建的SendingCollector类型的对象，代码如下：

@InternalCoroutinesApi

public class SendingCollector<T>(

    private val channel: SendChannel<T>

) : FlowCollector<T> {

    // 通过Channel类对象发送值

    override suspend fun emit(value: T): Unit = channel.send(value)

}

    当调用SendingCollector类型的对象的emit方法时，会通过调用类型为Channel的对象的send方法，将值发送出去。

    接下来，将分析下游如何接收上游发出的值。

4.接收flow方法发出的值

    回到ChannelFlow类的collect方法，之前提到collect方法中调用produceImpl方法，开启了一个新的协程去执行任务，并且返回了一个ReceiveChannel接口指向的对象。代码如下：

override suspend fun collect(collector: FlowCollector<T>): Unit =

    coroutineScope {

        collector.emitAll(produceImpl(this))

    }

    在调用完produceImpl方法后，接着调用了emitAll方法，将ReceiveChannel接口指向的对象作为emitAll方法的参数，代码如下：

public suspend fun <T> FlowCollector<T>.emitAll(channel: ReceiveChannel<T>): Unit =

    emitAllImpl(channel, consume = true)

    emitAll方法是FlowCollector接口的扩展方法，内部调用了emitAllImpl方法对参数channel进行封装，代码如下：

private suspend fun <T> FlowCollector<T>.emitAllImpl(channel: ReceiveChannel<T>, consume: Boolean) {

    // 用于保存异常

    var cause: Throwable? = null

    try {

        // 死循环

        while (true) {

            // 挂起，等待接收Channel结果或Channel关闭

            val result = run { channel.receiveOrClosed() }

            // 如果Channel关闭了

            if (result.isClosed) {

                // 如果有异常，则抛出

                result.closeCause?.let { throw it }

                // 没有异常，则跳出循环

                break

            }

            // 获取并发送值

            emit(result.value)

        }

    } catch (e: Throwable) {

        // 捕获到异常时抛出

        cause = e

        throw e

    } finally {

         // 执行结束关闭Channel

        if (consume) channel.cancelConsumed(cause)

    }

}

    emitAllImpl方法是FlowCollector接口的扩展方法，而这里的FlowCollector接口指向的对象，就是collect方法中创建的匿名对象，代码如下：

public suspend inline fun <T> Flow<T>.collect(crossinline action: suspend (value: T) -> Unit): Unit =

    collect(object : FlowCollector<T> {

        override suspend fun emit(value: T) = action(value)

    })

    在emitAllImpl方法中，当通过receiveOrClosed方法获取到上游发出的值时，会调用emit方法通知下游，这时就会触发collect方法中block的执行，最终实现值从流的上游传递到了下游。

三.flowOn方法与流的融合

    假设对一个流连续调用两次flowOn方法，那么流最终会在哪个flowOn方法指定的调度器中执行呢？代码如下：

launch(Dispatchers.Main) {

    flow {

        emit(2)

      // emit方法是在IO线程执行还是在主线程执行呢？  

    }.flowOn(Dispatchers.IO).flowOn(Dispatchers.Main).collect {

        Log.d("liduo", "$it")

    }

}

    答案是在IO线程执行，为什么呢？

    根据本篇上面的分析，当第一次调用flowOn方法时，上游的流会被包裹成ChannelFlowOperatorImpl对象，代码如下：

public fun <T> Flow<T>.flowOn(context: CoroutineContext): Flow<T> {

    // 检查当前协程没有执行结束

    checkFlowContext(context)

    return when {

        // 为空，则返回自身

        context == EmptyCoroutineContext -> this

        // 如果是可融合的Flow，则尝试融合操作，获取新的流

        this is FusibleFlow -> fuse(context = context)

        // 其他情况，包装成可融合的Flow

        else -> ChannelFlowOperatorImpl(this, context = context)

    }

}

    而当第二次调用flowOn方法时，由于此时上游的流——ChannelFlowOperatorImpl类型的对象，实现了FusibleFlow接口，因此，这里会触发流的融合，直接调用上游的流的fuse方法，并传入新的上下文。这里容量和溢出策略均为默认值。

    根据Kotlin协程：Flow的融合、Channel容量、溢出策略的分析，这里会调用ChannelFlow类的fuse方法。相关代码如下：

public override fun fuse(context: CoroutineContext, capacity: Int, onBufferOverflow: BufferOverflow): Flow<T> {

    ...

    

    // 计算融合后流的上下文

    // context为下游的上下文，this.context为上游的上下文 

    val newContext = context + this.context

    

    ...

}

    再根据之前在Kotlin协程：协程上下文与上下文元素中的分析，当两个上下文进行相加时，后一个上下文中的拦截器会覆盖前一个上下文中的拦截器。在上面的代码中，后一个上下文为上游的流的上下文，因此会优先使用上游的拦截器。代码如下：

public operator fun plus(other: CoroutineDispatcher): CoroutineDispatcher = other

四.总结

    粉线为使用时代码编写顺序，绿线为下游触发上游的调用顺序，红线为上游向下游发送值的调用顺序，蓝线为线程切换的位置。

    本文分析示例代码如下：

launch(Dispatchers.Main) {

    val task = flow {

        emit(2)

        emit(3)

    }.onEach {

        Log.d("liduo", "$it")

    }



    task.collect()

}

一.Flow的触发与消费

    在Kotlin协程：Flow基础原理的分析中，流的触发与消费都是同时进行的。每当调用collect方法时，会触发流的执行，并同时在collect方法中对流发出的值进行消费。

    而在协程中，其实还提供了分离流的触发与消费的操作——onEach方法。通过使用onEach方法，可以将原本在collect方法中的消费过程的移动到onEach方法中。这样在构建好一个Flow对象后，不会立刻去执行onEach方法，只有当调用collect方法时，才会真正的去触发流的执行。这样就实现了流的触发与消费的分离。

    接下来，将对onEach方法进行分析。

1.onEach方法

    onEach方法用于预先构建流的消费过程，只有在触发流的执行后，才会对流进行消费，代码如下：

public fun <T> Flow<T>.onEach(action: suspend (T) -> Unit): Flow<T> = transform { value ->

    action(value)

    return@transform emit(value)

}

    onEach方法是一个Flow接口的扩展方法，返回一个类型为Flow的对象。Flow方法内部通过transform方法实现。

2.transform方法

    transform方法是onEach方法的核心实现，代码如下：

public inline fun <T, R> Flow<T>.transform(

    @BuilderInference crossinline transform: suspend FlowCollector<R>.(value: T) -> Unit

): Flow<R> = flow { // 创建Flow对象

    collect { value -> // 触发collect

        return@collect transform(value)

    }

}

    transform方法也是Flow接口的扩展方法，同样会返回一个类型为Flow的对象。并且在transform方法内部，首先构建了一个类型为Flow的对象，并且在这个Flow对象的执行体内，调用上游的流的collect来触发消费过程，并通过调用参数transform来实现消费。这个collect方法是一个扩展方法，在Kotlin协程：Flow基础原理分析过，因此不再赘述。

    这就是onEach方法实现触发与消费分离的核心，它将对上游的流的消费过程包裹在了一个新的流内，只有当这个新的流或其下游的流被触发时，才会触发这个新的流自身的执行，从而实现对上游的流的消费。

    接下来分析一下流的消费过程。

3.collect方法

    collect方法用于触发流的消费，我们这里调用的collect方法，是一个无参数的方法，代码如下：

public suspend fun Flow<*>.collect(): Unit = collect(NopCollector)

    这里的无参数collect方法是Flow接口的扩展方法。在无参数collect方法中，调用了另一个有参数的collect方法，这个有参数的collect方法在Kotlin协程：Flow基础原理中提到过，就是Flow接口中定义的方法，并且传入了NopCollecor对象，代码如下：

internal object NopCollector : FlowCollector<Any?> {

    override suspend fun emit(value: Any?) {

        // 什么都不做

    }

}

    NopCollecor是一个单例类，它实现了FlowCollector接口，但是emit方法为空实现。

    因此，这里会调用onEach方法返回的Flow对象的collect方法，这部分在Kotlin协程：Flow基础原理进行过分析，最后会触发flow方法中的block参数的执行。而这个Flow对象就是transform方法返回的Flow对象。代码如下：

public inline fun <T, R> Flow<T>.transform(

    @BuilderInference crossinline transform: suspend FlowCollector<R>.(value: T) -> Unit

): Flow<R> = flow { // 创建Flow对象

    collect { value -> // 触发collect

        return@collect transform(value)

    }

}

    通过上面的transform方法可以知道，在触发flow方法中的block参数执行后，会调用collect方法。上面提到transform方法是Flow接口的扩展方法，因此这里有会继续调用上游Flow对象的collect方法。这个过程与刚才分析的类似，这里调用的上游的Flow对象，就是我们在示例代码中通过flow方法构建的Flow对象。

    此时，会触发上游flow方法中block参数的执行，并在执行过程中，通过emit方法将值发送到下游。

    接下来，在transform方法中，collect方法的block参数会被会被回调执行，处理上游发送的值。这里又会继续调用transform方法中参数的执行，这部分逻辑在onEach方法中，代码如下：

public fun <T> Flow<T>.onEach(action: suspend (T) -> Unit): Flow<T> = transform { value ->

    action(value)

    return@transform emit(value)

}

    这里会调用参数action的执行，流在这里最终被消费。同时，onEach方法会继续调用emit方法，将上游返回的值再原封不动的传递到下游，交由下游的流处理。

二.多消费过程的执行

    首先看下面这段代码：

launch(Dispatchers.Main) {

    val task = flow {

        emit(2)

        emit(3)

    }.onEach {

        Log.d("liduo1", "$it")

    }.onEach {

        Log.d("liduo2", "$it")

    }



    task.collect()

}

    根据上面的分析，两个onEach方法会按顺序依次执行，打印出liduo1：2、liduo2：2、liduo1：3、liduo2：3。就是因为onEach方法会将上游的值继续向下游发送。

    同样的，还有下面这段代码：

launch(Dispatchers.Main) {

    val task = flow {

        emit(2)

        emit(3)

    }.onEach {

        Log.d("liduo1", "$it")

    }



    task.collect {

        Log.d("liduo2", "$it")

    }

}

    这段代码也会打印出liduo1：2、liduo2：2、liduo1：3、liduo2：3。虽然使用了onEach方法，但也可以调用有参数的collect方法来对上游发送的数据进行最终的处理。

三.总结

    粉线为代码编写顺序，绿线为下游触发上游的调用顺序，红线为上游向下游发送值的调用顺序，蓝线为onEach方法实现的核心。

为避免数据在分发过程中被恶意篡改，Kotlin 将 SealedClass 参数设置为 val 即可，

Java 17 以下未引入 SealedClass，且若实现 Kotlin val 同等效果，样板代码瞬间飙出许多，等于解决了数据一致性的同时，滋生了更多 “不一致” 问题，例如日后修改某字段，而忘配置构造方法等等。

痛定思痛，SealedClass4Java 应运而生，通过注解自动生成 SealedClass，像 Kotlin 一样使用 SealedClass。

献给喜欢 Kotlin 但又不得不维护 Java 老项目的朋友。

Github：SealedClass4Java

使用说明

1.创建一个接口，添加 SealedClass 注解，且接口名开头 _ 下划线，

@SealedClass

public interface _TestEvent {

  void resultTest1(String a, int b);

  void resultTest2(String a, int b, int c);

}

2.编译即可生成目标类，例如 TestEvent，然后像 Kotlin 一样使用该类：

TestEvent event = TestEvent.ResultTest1("textx");



switch (event.id) {

  case TestEvent.ResultTest1.ID:

    TestEvent.ResultTest1 event1 = (TestEvent.ResultTest1) event;

    event1.copy(1);

    event1.paramA;

    event1.resultB;

    break;

  case TestEvent.ResultTest2.ID:

    break;

}

进阶使用

本框架是 MVI-Dispatcher 项目优化过程中，为消除 “消息分流场景 final 样板代码” 而萌生的产物，所以我们不妨以 MVI-Dispatcher 使用场景为例：

注：“消息(message)、事件(event)、意图(intent)”，不同场景，叫法不同，但本质上是指同一东西，即 “可被消费的一次性数据”。

A.纯粹消息分发场景

1.定义一个接口，例如 _Messages，在方法列表中定义不携带参数的纯粹消息，定义完 build 生成对应 Messages 类。

@SealedClass

public interface _Messages {

  void refreshNoteList();

  void finishActivity();

}

2.在 MVI-View 中发送一个 Messages.RefreshNoteList( ) 纯粹消息

public class TestFragment {

  public void onInput() {

    MVI-Model.input(Messages.RefreshNoteList());

  }

}

3.在 MVI-Model 中转发消息

public class PageMessenger extends MVI-Disptacher {

  protected void onHandle(Messages intent){

    sendResult(intent);

  }

}

4.在 MVI-View 中响应消息

public class TestFragment {

  public void onOutput() {

    MVI-Model.output(this, intent-> {

      switch(intent.id) {

        case Messages.RefreshNoteList.ID: ... break;

        case Messages.FinishActivity.ID: ... break;

      }

    });

  }

}

B.带参数的意图分发场景

该场景十分普遍，例如页面向后台请求一数据，通过意图来传递参数，后台处理好结果，将结果注入到意图中，回传给页面。

所以该场景下，意图会携带 “参数” 和 “结果”，且发送场景下只需注入参数，回推场景下只需注入结果，

因而使用方法即，

1.定义接口，为参数添加 @Param 注解，

@SealedClass

public interface _NoteIntent {

  void addNote(@Param Note note, boolean isSuccess);

  void removeNote(@Param Note note, boolean isSuccess);

}

build 生成的静态方法，比如 AddNote 方法中，只提供 “参数” 列表，不提供结果列表，结果字段皆赋予默认值，以符合意图发送场景的使用。

public static NoteIntent AddNote(Note note) {

  return new AddNote(note, false);

}

2.在 MVI-View 中发送一个 NoteIntent.AddNote(note) 意图，

public class TestFragment {

  public void onInput() {

    MVI-Model.input(NoteIntent.AddNote(note));

  }

}

3.在 MVI-Model 中处理业务逻辑，注入结果和回推意图。

由于意图为确保 “数据一致性” 而不可修改，因此在注入结果的场景下，可通过 copy 方法拷贝一份新的意图，而 copy 方法的入参即 “结果” 列表，以符合意图回推场景的使用。

public class NoteRequester extends MVI-Disptacher {

  protected void onHandle(NoteIntent intent){

    switch(intent.id) {

      case NoteIntent.AddNote.ID: 

        DataRepository.instance().addNote(result -> {

          NoteIntent.AddNote addNote = (NoteIntent.AddNote) intent;

          sendResult(addNote.copy(result.isSuccess));

        });

        break;

      case NoteIntent.RemoveNote.ID: 

        ...

        break;

    }

  }

}

4.在 MVI-View 中响应意图

public class TestFragment {

  public void onOutput() {

    MVI-Model.output(this, intent-> {

      switch(intent.id) {

        case NoteIntent.AddNote.ID: 

          updateUI();

          break;

        case NoteIntent.RemoveNote.ID: 

          ...

          break;

      }

    });

  }

}

C.不带参的事件分发场景

也即没有初值传参，只用于结果分发的情况。

这种场景和 “带参数意图分发场景” 通常重叠和互补，所以使用上其实大同小异。

1.定义接口，方法不带 @Param 注解。那么该场景下 NoteIntent.GetNotes 静态方法提供无参和有参两种，我们通常是使用无参，也即事件在创建时结果是被给到默认值。

@SealedClass

public interface _NoteIntent {

  void getNotes(List<Note> notes);

}

2.在 MVI-View 中发送一个 NoteIntent.GetNotes() 事件，

public class TestFragment {

  public void onInput() {

    MVI-Model.input(NoteIntent.GetNotes());

  }

}

3.在 MVI-Model 中处理业务逻辑，注入结果和回推意图。

由于意图为确保 “数据一致性” 而不可修改，因此在注入结果的场景下，可通过 copy 方法拷贝一份新的意图，而 copy 方法的入参即 “结果” 列表，以符合意图回推场景的使用。

public class NoteRequester extends MVI-Disptacher {

  protected void onHandle(NoteIntent intent){

    switch(intent.id) {

      case NoteIntent.GetNotes.ID: 

        DataRepository.instance().getNotes(result -> {

          NoteIntent.GetNotes getNotes = (NoteIntent.GetNotes) intent;

          sendResult(getNotes.copy(result.notes));

        });

        break;

      case NoteIntent.RemoveNote.ID: 

        ...

        break;

    }

  }

}

4.在 MVI-View 中响应事件

public class TestFragment {

  public void onOutput() {

    MVI-Model.output(this, intent-> {

      switch(intent.id) {

        case NoteIntent.GetNotes.ID: 

          updateUI();

          break;

        case NoteIntent.RemoveNote.ID: 

          ...

          break;

      }

    });

  }

}

Github：SealedClass4Java

现在互联网产品，感觉谁家的App不整点视频功能，严格意义上都不能说是一个现代互联网App了😂，我们知道最火的是抖音、快手这类短视频App，在刷视频的同时，他们的App交互上面的一些特色能让我们一直沉浸在刷视频中；

比如，我们今天要聊的，短视频翻页流列表，视频加载缓冲的时候，Loading的设计：

它设计：在视频底部，进度条上面，当视频缓冲加载等待的时候，它有一个波纹的扩散效果，

即不干扰用户刷视频的操作，也没有很明显的突兀效果

（比如：突兀的屏幕中间大圆圈Loading，就很突兀）

一定要记得：『点赞❤️+关注❤️+收藏❤️』起来，划走了可就再也找不到了😅😅🙈🙈

我们先来看一下“抖音、快手App”的视频进度条Loading效果（GIF图稍微失真了点）

快手短视频首页的视频Loading

从视频里面可以看出来在视频底部，出现缓冲加载视频的时候，会有一个：“从中间往2边扩散”的效果。

GIF图放慢了一点，方便大家观看，实际研究过程，我一般是通过录制完视频，通过相册的视频编辑，去一帧一帧看，做了哪些动作，如下：

看完，我们发现：

1、一开始是在屏幕中间的位置，大概是20dp左右的宽度开始显示；

2、从中间扩散到屏幕边缘之后，会执行渐隐；

3、渐隐到透明，又开始从中间往2边扩散；

有了上面的前奏，我们就可以开始我们的编码了，那么在开始编码前，肯定需要知道宽度是多少，这里我们拿BoxWithConstraints来包我们的child composable，
我们可以看到BoxWithConstraints的代码如下：

// 代码来自：androidx.compose.foundation.layout

@Composable

@UiComposable

fun BoxWithConstraints(

    modifier: Modifier = Modifier,

    contentAlignment: Alignment = Alignment.TopStart,

    propagateMinConstraints: Boolean = false,

    content:

        @Composable @UiComposable BoxWithConstraintsScope.() -> Unit

) {

    val measurePolicy = rememberBoxMeasurePolicy(contentAlignment, propagateMinConstraints)

    SubcomposeLayout(modifier) { constraints ->

        val scope = BoxWithConstraintsScopeImpl(this, constraints)

        val measurables = subcompose(Unit) { scope.content() }

        with(measurePolicy) { measure(measurables, constraints) }

    }

}

里面用到了SubcomposeLayout，来推迟内容组合，我们可以在BoxWithConstraintsScope里面获取到最大宽度maxWidth (单位dp)。

Loading线条，我们可以用DrawScope.drawLine来画，扩散效果肯定需要有动画来更新。

我们使用 rememberInfiniteTransition() 执行无限动画，使用animateFloat来获取动画更新的值：

// 代码来自：androidx.compose.animation.core

@Composable

fun InfiniteTransition.animateFloat(

    initialValue: Float,

    targetValue: Float,

    animationSpec: InfiniteRepeatableSpec<Float>

): State<Float>

初始值(initialValue)可以定义成50F(读者可自行修改)，目标值(targetValue)定义多少合适呢？

通过慢镜头查看“抖音、快手”的效果，发现它扩散完，会“渐隐到透明”，然后再从intialValue处开始重新扩散。

targetValue定义成maxWidth不行，那么我们拉大这个数值，可以定义成大概1.8倍的maxWidth;

由于maxWidth获取到的是dp单位的，我们需要转换成px，下面我们统一叫：width

val width = with(LocalDensity.current) {  maxWidth.toPx() }

然后，我们的线条动画值就变成下面这样：

val lineProgressAnimValue by infiniteTransition.animateFloat(

    initialValue = 100F,

    targetValue = width * 1.8F,

    animationSpec = infiniteRepeatable(

            animation = tween(

            durationMillis = TIME_PERIOD,

            easing = FastOutLinearInEasing

        )

    )

)

private const val TIME_PERIOD = 1100

线条扩散到屏幕边缘的时候，需要执行渐隐，得出下面的alpha

val lineAlphaValue = if(lineProgressAnimValue <= width) {

    // 读者可以根据自己体验

    lineProgressAnimValue * 1.0F/ width * 1.0F

    // 读者可以根据自己体验

    //Math.min((lineProgressAnimValue.value) * 1.0F / width * 1.0F, 0.7F)

    // 抖音、快手看效果都是1F，根据自己体验来设置吧

    // 1F

} else {

    // 扩散到屏幕边缘的时候，开始触发：渐隐

    (width * 1.8F - lineProgressAnimValue) / width * 0.8F

}

// 线条宽度

val lineWidth = if(lineProgressAnimValue <= width) {

    lineProgressAnimValue / 2

} else {

    width / 2

}

最后，我们通过Canvas来绘制这个线条

Canvas(modifier = modifier) {

    drawLine(

        color = Color.White.copy(alpha = lineAlphaValue),

        start = Offset(x = size.width / 2 - lineWidth, y = 0F),

        end = Offset(x = size.width / 2 + lineWidth, y = 0F),

        strokeWidth = 2.5F

    )

}

来看看我们的最终效果吧：

委托其实是一种设计模式,但Kotlin把此特性编写进了语法中,可以方便开发者快速使用，本篇也来具体讲解下关于Kotlin中属性委托的使用

委托对应的关键字是by

属性委托

先讲下属性委托吧,首先,复习下kotlin中设置set和get方法

默认的set和get我们可以隐藏,实际上一个简单的类代码如下:

class Person {

	var personName = ""

	// 这是默认的 get/set(默认是隐藏的)

	get() = field

	set(value) {

		field = value

	}

}

这里具体知识点可以查看之前所说Kotlin学习快速入门（3）——类 继承 接口 - Stars-One的杂货小窝

当然,如果是数据bean类,我们会将get和set方法隐藏(或者使用data关键字来声明一个数据类)

若我们需要在get或set方法的时候做一下逻辑处理,比如说上面的personName字段,我们只允许接收长度小于等于10的字符串,超过10长度的字符串就不接收(即不设置新数值),则是应该这样写:

class Person{

    var personName = ""

        // 这是重写的 get/set

        get() = "PersonName $field"

        set(value) {

            field = if (value.length <= 10) value else field

        }

}

然后,我们再延伸出来,如果此规则不止应用于personName字段,还可用到其他类的字段中,这个时候就是使用到属性委托。

简单描述: 我们将此规则抽取出来,需要应用到此规则的字段的get/set方法委托给规则去做,这就叫属性委托

延迟加载(懒加载)

在开始讲属性委托之前,先说明下延迟加载

Kotlin中提供了lazy方法,使用by+lazy{}联用,我们就实现延迟加载(也可称作懒加载)

fun main() {



    val demo = Demo()

    val textContent = demo.textContent

    val result = demo.textContent.substring(1)

    println(result)

    println("打印:$textContent")

}



class Demo{



    val textContent by lazy { loadFile() }



}

fun loadFile(): String {

    println("读取文件...")

    //模拟读取文件返回数据

    return "读取的数据"

}

这里的关键词by出现在属性名后面，表示属性委托，即将属性的读和写委托给另一个对象，被委托的对象必须满足一定的条件：

• 对于 val 修饰的只读变量进行属性委托时，被委托的对象必须实现getValue()接口，即定义如何获取变量值。


• 对于 var 修饰的读写变量进行属性委托时，被委托对象必须实现getValue()和setValue()接口，即定义如何读写变量值。

lazy()方法,接收一个lambda函数,返回值是一个Lazy对象,所以就可以简写成上面的样子,其只实现了getValue()接口,所以,当你尝试将textContent改为var类型,IDE会提示报错!!

也是因为这点,属于延迟加载的字段,是不可被再次修改了,所以采用lazy懒加载的方式,其实就是单例模式

lazy函数默认是线程安全的，而且是通过加锁实现的。如果你的变量不会涉及到多线程，那么请务必使用LazyThreadSafetyMode.NONE参数，避免不必要的性能开销,如下示例代码

val name:String by lazy(LazyThreadSafetyMode.NONE) { "Karl" }

Delegates.vetoable

还记得上述我们要实现的规则吗,其实Kotlin中已经有了几个默认的委托规则供我们快速使用(上述的lazy其实也是一个)

Delegates.vetoable()的规则就是上述规则的通用封装,解释为:

但会在属性被赋新值生效之前会传递给Delegates.vetoable()进行处理，依据Delegates.vetoable()的返回的布尔值判断要不要赋新值。

如下面例子:

class Person {

    var personName by Delegates.vetoable("") { property, oldValue, newValue ->

        //当设置的新值满足条件,则会设置为新值

        newValue.length <= 10

    }

}

Delegates.notNull

设置字段不能为null,不过想不到具体的应用情景

class Person {

    var personName by Delegates.notNull<String>()

}

Delegates.observable

使用Delegates.observable可以帮我们快速实现观察者模式,只要字段数值发生改变,就会触发

class Person{

    var age by Delegates.observable(0){ property, oldValue, newValue ->

        //这里可以写相关的逻辑

        if (newValue >= 18) {

            tip = "已成年"

        }else{

            tip = "未成年"

        }

    }



    var tip =""

}

上面的例子就比较简单，设置age同时更新提示，用来判断是否成年

 val person = Person()

    person.age = 17

    println(person.tip)

补充-自定义委托

上述都是官方定义好的一些情形,但如果不满足我们的需求,这就需要自定义委托了

官方提供了两个基础类供我们自定义委托使用:

ReadWriteProperty 包含get和set方法,对应var关键字
ReadOnlyProperty 只有get方法,对应val关键字

PS:实际上，我们自己随意创建个委托类也是可以的，不过这样写不太规范，所以我们一般直接实现官方给的上述两个类即可

ReadWriteProperty和ReadOnlyProperty都需要传两个泛型，分别为R，T

• R 持有属性的类型


• T 字段类型

可能上面描述不太明白，下面给个简单例子，Person类中有个name字段（String），首字母需要大写：

class Person {

    var name by NameToUpperCase("")

}



class NameToUpperCase(var value:String) :ReadWriteProperty<Person,String>{

    //NameToUpperCase类中默认有个属性字段，用来存数据

    

    override fun getValue(thisRef: Person, property: KProperty<*>): String {

        return this.value

    }



    override fun setValue(thisRef: Person, property: KProperty<*>, value: String) {

        //在设置数值的时候，将第一个字母转为大写，一般推荐在setValue里编写逻辑

        this.value = value.substring(0,1).toUpperCase()+value.substring(1)

    }

}

个人看法，一般在setValue的时候进行设置数值比较好，因为getValue作操作的话，会触发多次，处理的逻辑复杂的话可能会浪费性能...

当然，再提醒下，上面的逻辑也可以直接去字段里的setValue()里面改，使用委托的目的就是方便抽取出去供其他类使用同样的规则，减少模板代码

PS: 如果你的委托不是针对特定的类，R泛型可以改为Any

类委托

这个一般与多态一起使用，不过个人想不到有什么具体的应用情景，暂时做下简单的记录

interface IDataStorage{

    fun add()

    fun del()

    fun query()

}



class SqliteDataStorage :IDataStorage{

    override fun add() {

        println("SqliteDataStorage add")

    }



    override fun del() {

        println("SqliteDataStorage del")

    }



    override fun query() {

        println("SqliteDataStorage query")

    }



}

假如现在我们有个MyDb类，查询的方法与SqliteDataStorage这个里的方法有所区别,但其他方法都是没有区别，这个时候就会用到类委托了

有以下几种委托的使用方式

1.委托类作为构造器形参传入（常用）

class MyDb(private val storage:IDataStorage) : IDataStorage by storage{

    override fun add() {

        println("mydb add")

    }

}

val db = MyDb(SqliteDataStorage())

db.add()

db.query()

输出结果：

mydb add

SqliteDataStorage query

如果是全部都是委托给SqliteDataStorage的话，可以简写为这样：

class MyDb(private val storage:IDataStorage) : IDataStorage by storage

2.新建委托类对象

class MyDb : IDataStorage by SpDataStorage(){

    override fun add() {

        println("mydb add")

    }

}

这里测试的效果与上文一样，不在重复赘述

参考

• kotlin-属性委托_南郭竽的博客-CSDN博客_kotlin属性委托


• Kotlin 基础 | 委托及其应用_普通网友的博客-CSDN博客


• Kotlin修炼指南（五）—Delegates_eclipse_xu的博客-CSDN博客


• kotlin类委托、属性委托_水煮鱼在飞的博客-CSDN博客_kotlin 类委托

async await 与 Future

在异步调用中有三个关键词，async、await、Future，其中async和await需要一起使用。在Dart中可以通过async和await进行异步操作，async表示开启一个异步操作，也可以返回一个Future结果。如果没有返回值，则默认返回一个返回值为null的Future。

await的操作，不会影响方法外后续代码的执行;只会阻塞async方法的后续代码

例子1

_testAsyncKeyword() {

    print("test函数开始了：${DateTime.now()}");

    _testString().then((value) => print(value));

    print("test函数结束了：${DateTime.now()}");

  }



  Future<String> _testString() async {

    Future f = Future.delayed(Duration(milliseconds: 300), () {

      return "我是测试字符串===1";

    });

    String result = await f;

    print("我是测试字符串===2");

    return result;

  }

// flutter: test函数开始了：

// flutter: test函数结束了：

// flutter: 我是测试字符串===2

// flutter: 我是测试字符串===1

在代码示例中,执行到_testString()方法,会同步进入方法内部进行执行，当执行到await时就会停止async内部的执行，从而继续执行外面的代码。所以await的操作，不会影响后面代码的执行("test函数结束了"会先于_testString()内部打印)。
当await有返回后，会继续从await的位置继续执行(所以先打印出了 "我是测试字符串===2" ,然后返回Future的结果,并通过print打印出 "我是测试字符串===1")。

例子2

_testAsyncKeyword() async {

    print("test函数开始了：${DateTime.now()}");

    print(await _testString());

    print("test函数结束了：${DateTime.now()}");

  }



  Future<String> _testString() async {

    Future f = Future.delayed(Duration(milliseconds: 300), () {

      return "我是测试字符串===1";

    });

    String result = await f;

    print("我是测试字符串===2");

    return result;

  }



// flutter: test函数开始了：

// flutter: 我是测试字符串===2

// flutter: 我是测试字符串===1

// flutter: test函数结束了：

在代码示例中, _testAsyncKeyword() 本身内部就有一个await操作,当执行到await时就会停止_testAsyncKeyword() async内部的执行.等待_testString()有结果返回之后,继续执行.

_testString()内部也是有一个await操作,当执行到await时就会停止_testString() async内部的执行,等待300毫秒,Future有结果后,打印字符串2

_testAsyncKeyword() 继续执行 打印 字符串1 及 结束

例子3

_testAsyncKeyword() {

    print("test函数开始了：${DateTime.now()}");

    firstString().then((value) => print(value));

    secondString().then((value) => print(value));

    thirdString().then((value) => print(value));

    print("test函数结束了：${DateTime.now()}");

  }



_testKeyword2() async{

    print("test函数开始了：${DateTime.now()}");

    print(await firstString());

    print(await secondString());

    print(await thirdString());

    print("test函数结束了：${DateTime.now()}");

  }

Future<String> firstString() {

    return Future.delayed(Duration(milliseconds: 300), () {

      return "我是一个字符串";

    });

  }



  Future<String> secondString() {

    return Future.delayed(Duration(milliseconds: 200), () {

      return "我是二个字符串";

    });

  }



  Future<String> thirdString() {

    return Future.delayed(Duration(milliseconds: 100), () {

      return "我是三个字符串";

    });

  }



//_testAsyncKeyword() 的打印:

//flutter: test函数开始了：

//flutter: test函数结束了：

//flutter: 我是三个字符串

//flutter: 我是二个字符串

//flutter: 我是一个字符串



//_testKeyword2() 的打印:

//flutter: test函数开始了：

//flutter: 我是一个字符串

//flutter: 我是二个字符串

//flutter: 我是三个字符串

//flutter: test函数结束了：

通过上面三个例子 , 可以看出 await async 和 then之间的区别和联系了.

async、await的原理

async、await的操作属于**"假异步"**,这是为什么呢?
如果想要得到这个问题的答案,首先我们需要了解async、await的原理，了解协程的概念，因为async、await本质上就是协程的一种语法糖。协程，也叫作coroutine，是一种比线程更小的单元。如果从单元大小来说，基本可以理解为 进程->线程->协程。

任务调度

在弄懂协程之前，首先要明白并发和并行的概念

• 并发: 指的是由系统来管理多个IO的切换，并交由CPU去处理。


• 并行: 指的是多核CPU在同一时间里执行多个任务。

并发的实现由非阻塞操作+事件通知来完成，事件通知也叫做“中断”。操作过程分为两种，一种是CPU对IO进行操作，在操作完成后发起中断告诉IO操作完成。另一种是IO发起中断，告诉CPU可以进行操作。

线程: 本质上也是依赖于中断来进行调度的，线程还有一种叫做“阻塞式中断”，就是在执行IO操作时将线程阻塞，等待执行完成后再继续执行,通过单线程并发可以进行大量并发操作。但线程的消耗是很大的，并不适合大量并发操作的处理,且单个线程只能使用到单个CPU。当多核CPU出现后，单个线程就无法很好的利用多核CPU的优势了，所以又引入了线程池的概念，通过线程池来管理大量线程。当需要同时执行多项任务的时候，我们就会采用多线程并发执行.

Dart单线程运行模型: 输入单吸纳成运行机制,主要是通过消息循环机制来实现任务调度和处理的.

协程coroutine

多线程并发 操作系统在线程等待IO的时候，会阻塞当前线程，切换到其它线程，这样在当前线程等待IO的过程中，其它线程可以继续执行。当系统线程较少的时候没有什么问题，但是当线程数量非常多的时候，却产生了问题。一是系统线程会占用非常多的内存空间，二是过多的线程切换会占用大量的系统时间。
协程 运行在线程之上，当一个协程执行完成后，可以选择主动让出，让另一个协程运行在当前线程之上。协程并没有增加线程数量，只是在线程的基础之上通过分时复用的方式运行多个协程，而且协程的切换在用户态完成，切换的代价比线程从用户态到内核态的代价小很多。
协程分为无线协程和有线协程.

• 无线协程在离开当前调用位置时，会将当前变量放在 堆区，当再次回到当前位置时，还会继续从堆区中获取到变量。所以，一般在执行当前函数时就会将变量直接分配到堆区，而async、await就属于无线协程的一种。


• 有线协程则会将变量继续保存在 栈区，在回到指针指向的离开位置时，会继续从栈中取出调用。

async、await原理

之所以说async/await是假异步,是因为他在执行过程中并没有开启新的线程更没有并发执行,而是通过单线程上的任务调度(协程,没有并发执行功能)实现的:
当代码执行到async则表示进入一个协程，会同步执行async的代码块。async的代码块本质上也相当于一个函数，并且有自己的上下文环境。当执行到await时，则表示有任务需要等待，CPU则去调度执行其他IO，也就是后面的代码或其他协程代码。过一段时间CPU就会轮询一次，看某个协程是否任务已经处理完成，有返回结果可以被继续执行，如果可以被继续执行的话，则会沿着上次离开时指针指向的位置继续执行，也就是await标志的位置。

由于并没有开启新的线程，只是进行IO中断改变CPU调度，所以网络请求这样的异步操作可以使用async、await，但如果是执行大量耗时同步操作的话，应该使用isolate开辟新的线程去执行。

废话不多说,先来看今天要完成的效果:

在上一篇:android setContentView()解析中我们介绍了,如何通过Factory2来自己解析View,

那么我们就通过这个机制,来完成今天的效果《视差动画》,

回顾

先来回顾一下如何在Fragment中自己解析View

 class MyFragment : Fragment(), LayoutInflater.Factory2 {

     override fun onCreateView(

         inflater: LayoutInflater,

         container: ViewGroup?,

         savedInstanceState: Bundle?,

    ): View {

         val newInflater = inflater.cloneInContext(activity)

         LayoutInflaterCompat.setFactory2(newInflater, this)

         return newInflater.inflate(R.layout.my_fragment, container, false)

    }

   

   // 重写Factory2的方法

   override fun onCreateView(

         parent: View?,

         name: String,

         context: Context,

         attrs: AttributeSet,

    ): View? {

     

      val view = createView(parent, name, context, attrs)

      // 此时的view就是自己创建的view!

     

     // ...................

     

 return view

  }

   

   // 重写Factory2的方法

   override fun onCreateView(name: String, context: Context, attrs: AttributeSet): View? {

         return onCreateView(null, name, context, attrs)

    }

   

   // SystemAppCompatViewInflater() 复制的系统源码

   private var mAppCompatViewInflater = SystemAppCompatViewInflater()

    private fun createView(

         parent: View?, name: String?, mContext: Context,

         attrs: AttributeSet,

    ): View? {

         val is21 = Build.VERSION.SDK_INT < 21

      // 自己去解析View

         return mAppCompatViewInflater.createView(parent, name, mContext, attrs, false,

             is21,  /* Only read android:theme pre-L (L+ handles this anyway) */

             true,  /* Read read app:theme as a fallback at all times for legacy reasons */

             false /* Only tint wrap the context if enabled */

        )

    }

 }

如果对这段代码有兴趣的,可以去看 上一篇:android setContentView()解析,

思路分析

0. 
   

   viewpager + fragment

   
   


1. 
   

   自定义属性:

   
   
   
   
   • 旋转: parallaxRotate
   
   
   • 缩放 : parallaxZoom
   
   
   • 出场移动:parallaxTransformOutX,parallaxTransformOutY
   
   
   • 入场移动:parallaxTransformInX,parallaxTransformInY
   
   
   
   


2. 
   

   给需要改变变换的view设置属性

   
   


3. 
   

   在fragment的时候自己创建view,并且通过AttributeSet解析所有属性

   
   


4. 
   

   将需要变换的view保存起来,

   
   


5. 
   

   在viewpager滑动过程中,通过addOnPageChangeListener{} 来监听viewpager变化,当viewpager变化过程中,设置对应view对应变换即可!

   
   

viewPager+Fragment

首先先实现最简单的viewpager+Fragment

代码块1.1

 class ParallaxBlogViewPager(context: Context, attrs: AttributeSet?) : ViewPager(context, attrs) {

 

     fun setLayout(fragmentManager: FragmentManager, @LayoutRes list: ArrayList<Int>) {

         val listFragment = arrayListOf<C3BlogFragment>()

         // 加载fragment

         list.map {

             C3BlogFragment.instance(it)

        }.forEach {

             listFragment.add(it)

        }

 

         adapter = ParallaxBlockAdapter(listFragment, fragmentManager)

    }

 

     private inner class ParallaxBlockAdapter(

         private val list: List<Fragment>,

         fm: FragmentManager

    ) : FragmentPagerAdapter(fm) {

         override fun getCount(): Int = list.size

         override fun getItem(position: Int) = list[position]

    }

 }

C3BlogFragment:

代码块1.2

 class C3BlogFragment private constructor() : Fragment(), LayoutInflater.Factory2 {

     companion object {

         @NotNull

         private const val LAYOUT_ID = "layout_id"

       

         fun instance(@LayoutRes layoutId: Int) = let {

             C3BlogFragment().apply {

                 arguments = bundleOf(LAYOUT_ID to layoutId)

            }

        }

    }

 

     private val layoutId by lazy {

         arguments?.getInt(LAYOUT_ID) ?: -1

    }

 

     override fun onCreateView(

         inflater: LayoutInflater,

         container: ViewGroup?,

         savedInstanceState: Bundle?,

    ): View {

         val newInflater = inflater.cloneInContext(activity)

         LayoutInflaterCompat.setFactory2(newInflater, this)

         return newInflater.inflate(layoutId, container, false)

    }

 

     override fun onCreateView(

         parent: View?,

         name: String,

         context: Context,

         attrs: AttributeSet,

    ): View? {

         val view = createView(parent, name, context, attrs)

         /// 。。。 在这里做事情。。。 

         return view

    }

 

     private var mAppCompatViewInflater = SystemAppCompatViewInflater()

 

     override fun onCreateView(name: String, context: Context, attrs: AttributeSet): View? {

         return onCreateView(null, name, context, attrs)

    }

     private fun createView(

         parent: View?, name: String?, mContext: Context,

         attrs: AttributeSet,

    ): View? {

         val is21 = Build.VERSION.SDK_INT < 21

         return mAppCompatViewInflater.createView(parent, name, mContext, attrs, false,

             is21, 

             true, 

             false 

        )

    }

 }

这个fragment目前的作用就是接收传过来的布局,展示,

并且自己解析view即可!

xml与调用:

R.layout.c3_1.item,这些布局很简单,就是

• 一张静态图片


• 一张动态图片

其他的布局都是一样的,这里就不看了.

来看看当前的效果

自定义属性

通常我们给一个view自定义属性,我们会选择在attrs.xml 中来进行,例如这样:

但是很明显,这么做并不适合我们的场景,因为我们想给任何view都可以设置属性,

那么我们就可以参考ConstraintLayout中的自定义属性:

我们自己定义属性:

并且给需要变换的view设置值

• app:parallaxRotate="10" 表示在移动过程中旋转10圈


• app:parallaxTransformInY="0.5" 表示入场的时候,向Y轴方向偏移 height * 0.5


• app:parallaxZoom="1.5" 表示移动过程中慢慢放大1.5倍

Fragment中解析自定义属性

我们都知道,所有的属性都会存放到AttributeSet中,先打印看一看:

 (0 until attrs.attributeCount).forEach {

     Log.i("szj属性",

         "key:${attrs.getAttributeName(it)}\t" +

                 "value:${attrs.getAttributeValue(it)}")

 }

这样一来就可以打印出所有的属性,并且找到需要用的属性!

那么接下来只需要将这些属性保存起来,在当viewpager滑动过程中取出用即可!

这里我们的属性是保存到view的tag中,

需要注意的是,如果你的某一个view需要变换,那么你的view就一定得设置一个id,因为这里是通过id来存储tag!

监听ViewPager滑动事件

 # ParallaxBlogViewPager.kt

 

 // 监听变化

 addOnPageChangeListener(object : OnPageChangeListener {

     // TODO 滑动过程中一直回调

     override fun onPageScrolled(

         position: Int,

         positionOffset: Float,

         positionOffsetPixels: Int,

    ) {

         Log.e("szjParallaxViewPager",

            "onPageScrolled:position:$position\tpositionOffset:${positionOffset}\tpositionOffsetPixels:${positionOffsetPixels}")

 

    }

 

     //TODO 当页面切换完成时候调用 返回当前页面位置

     override fun onPageSelected(position: Int) {

         Log.e("szjParallaxViewPager", "onPageSelected:$position")

    }

 

     // 

     override fun onPageScrollStateChanged(state: Int) {

         when (state) {

             SCROLL_STATE_IDLE -> {

                 Log.e("szjParallaxViewPager", "onPageScrollStateChanged:页面空闲中..")

            }

             SCROLL_STATE_DRAGGING -> {

                 Log.e("szjParallaxViewPager", "onPageScrollStateChanged:拖动中..")

            }

             SCROLL_STATE_SETTLING -> {

                 Log.e("szjParallaxViewPager", "onPageScrollStateChanged:拖动停止了..")

            }

        }

    }

 })

这三个方法介绍一下:

• 
  

  onPageScrolled(position:Int , positionOffset:Float, positionOffsetPixels)

  
  
  
  
  • @param position: 当前页面下标
  
  
  • @param positionOffset:当前页面滑动百分比
  
  
  • @param positionOffsetPixels: 当前页面滑动的距离
  
  
  
  

  在这个方法中需要注意的是,当假设当前是第0个页面,从左到右滑动,

  
  
  
  
  • position = 0
  
  
  • positionOffset = [0-1]
  
  
  • positionOffsetPixels = [0 - 屏幕宽度]
  
  
  
  

  当第1个页面的时候,从左到右滑动,和第0个页面的状态都是一样的

  
  

  但是从第1个页面从右到左滑动的时候就不一样了,此时

  
  
  
  
  • position = 0
  
  
  • positionOffset = [1-0]
  
  
  • positionOffsetPixels = [屏幕宽度 - 0]
  
  
  
  

• 
  

  onPageSelected(position:Int)

  
  
  
  
  • @param position: 但页面切换完成的时候调用
  
  
  
  


• 
  

  onPageScrollStateChanged(state:Int)

  
  
  
  
  • 
    

    @param state: 但页面发生变化时候调用,一共有3种状体

    
    
    
    
    • SCROLL_STATE_IDLE 空闲状态
    
    
    • SCROLL_STATE_DRAGGING 拖动状态
    
    
    • SCROLL_STATE_SETTLING 拖动停止状态
    
    
    
    
  
  
  
  

了解了viewpager滑动机制后,那么我们就只需要在滑动过程中,

获取到刚才在tag种保存的属性,然后改变他的状态即可!

 # ParallaxBlogViewPager.kt

 

 // 监听变化

 addOnPageChangeListener(object : OnPageChangeListener {

     // TODO 滑动过程中一直回调

     override fun onPageScrolled(

         position: Int,

         positionOffset: Float,

         positionOffsetPixels: Int,

    ) {

         // TODO 当前fragment

         val currentFragment = listFragment[position]

         currentFragment.list.forEach { view ->

 // 获取到tag中的值

             val tag = view.getTag(view.id)

 

            (tag as? C3Bean)?.also {

                 // 入场

                 view.translationX = -it.parallaxTransformInX * positionOffsetPixels

                 view.translationY = -it.parallaxTransformInY * positionOffsetPixels

                 view.rotation = -it.parallaxRotate * 360 * positionOffset

 

 

                 view.scaleX =

                     1 + it.parallaxZoom - (it.parallaxZoom * positionOffset)

                 view.scaleY =

                     1 + it.parallaxZoom - (it.parallaxZoom * positionOffset)

 

            }

        }

 

         // TODO 下一个fragment

         // 防止下标越界

         if (position + 1 < listFragment.size) {

             val nextFragment = listFragment[position + 1]

             nextFragment.list.forEach { view ->

                 val tag = view.getTag(view.id)

 

                (tag as? C3Bean)?.also {

                     view.translationX =

                         it.parallaxTransformInX * (width - positionOffsetPixels)

                     view.translationY =

                         it.parallaxTransformInY * (height - positionOffsetPixels)

 

                     view.rotation = it.parallaxRotate * 360 * positionOffset

 

                     view.scaleX = (1 + it.parallaxZoom * positionOffset)

                     view.scaleY = (1 + it.parallaxZoom * positionOffset)

                }

            }

        }

    }

 

     //TODO 当页面切换完成时候调用 返回当前页面位置

     override fun onPageSelected(position: Int) {...}

 

     override fun onPageScrollStateChanged(state: Int) { ... }

 })

来看看现在的效果:

此时效果就基本完成了

但是一般情况下,引导页面都会在最后一个页面有一个跳转到主页的按钮

为了方便起见,我们只需要将当前滑动到的fragment页面返回即可!

这么一来,我们就可以在layout布局中为所欲为,因为我们可以自定义属性,并且自己解析,可以做任何自己想做的事情!

思路参考自

完整代码

原创不易,您的点赞与关注就是对我最大的支持!

前言

flutter项目中，有许多可以实现跨组件通讯的方案，其中包括InheritedWidget，Notification，EventBus等。本文主要探讨的是EventBus事件总线实现跨组件通讯的方法。

EventBus的简介

EventBus的核心是基于Streams。它允许侦听器订阅事件并允许发布者触发事件，使得不同组件的数据不需要一层层传递，可以直接通过EventBus实现跨组件通讯。

EventBus最主要是通过触发事件和监听事件两项操作来实现不同页面的跨层访问。触发事件是通过fire(event)方法进行，监听事件则是通过on<T>()方法进行的，其中泛型可以传入指定类型，事件总线将进行针对性监听，如果泛型传值为空，则默认监听所有类型的事件：

void fire(event) {

  streamController.add(event);

}

Stream<T> on<T>() {

  if (T == dynamic) {

    return streamController.stream as Stream<T>;

  } else {

    return streamController.stream.where((event) => event is T).cast<T>();

  }

}

EventBus的实际应用

1、在pubspec.yaml文件中引用eventBus事件总线依赖；

2、创建一个全局的EventBus实例；

3、使用fire(event)方法在事件总线上触发一个新事件（触发事件）；

4、为事件总线注册一个监听器（监听事件）；

5、取消EventBus事件订阅，防止内存泄漏。

// 1、在pubspec.yaml文件中引用eventBus事件总线依赖；

dependencies:

    event_bus: ^2.0.0

// 2、创建一个全局的EventBus实例；

EventBus myEventBus = EventBus();

// 3、使用fire(event)方法在事件总线上触发一个新事件（触发事件）；

Center(

  child: ElevatedButton(

    onPressed: () {

      myEventBus.fire('通过EventBus触发事件');

    },

    child: Text('触发事件'),

  ),

)

var getData;



@override

void initState() {

  // TODO: implement initState

  super.initState();

  // 4、为事件总线注册一个监听器（监听事件）；

  getData = myEventBus.on().listen((event) {

    print(event);

  });

}



@override

void dispose() {

  // TODO: implement dispose

  super.dispose();

  // 5、取消EventBus事件订阅，防止内存泄漏。

  getData.cancel();

}

总结

EventBus遵循的是发布/订阅模式，能够通过事件的触发和监听操作，有效实现跨组件通讯的功能。

1. 业务逻辑和构建逻辑

对界面呈现来说，最重要的逻辑有两个部分：业务数据的维护逻辑 和 界面布局的构建逻辑 。其中应用运行中相关数据的获取、修改、删除、存储等操作，就是业务逻辑。比如下面是秒表的三个界面，核心 数据 是秒表的时刻。在秒表应用执行功能时，数据的变化体现在秒数的变化、记录、重置等。

默认情况	暂停	记录

界面的构建逻辑主要体现在界面如何布局，维持界面的出现效果。另外，在界面构建过程中，除了业务数据，还有一些数据会影响界面呈现。比如打开秒表时，只有一个启动按钮；在运行中，显示暂停按钮和记录按钮；在暂停时，记录按钮不可用，重置按钮可用。这样在不同的交互场景中，有不同的界面表现，也是构建逻辑处理的一部分。

2. 数据的维护

所以的逻辑本身都是对 数据 的维护，界面能够显示出什么内容，都依赖于数据进行表现。理解需要哪些数据、数据存储在哪里，从哪里来，要传到哪里去，是编程过程中非常重要的一个环节。由于数据需要在构建界面时使用，所以很自然的：在布局写哪里，数据就在哪里维护。

比如默认的计数器项目，其中只有一个核心数据 _counter ，用于表示当前点击的次数。

代码实现时， _counter 数据定义在 _MyHomePageState 中，改数据的维护也在状态类中：

对于一些简单的场景，这样的处理无可厚非。但在复杂的交互场景中，业务逻辑和构建逻辑杂糅在 State 派生类中，会导致代码复杂，逻辑混乱，不便于阅读和维护。

3.秒表状态数据对布局的影响

现在先通过代码来实现如下交互，首先通过 StopWatchType 枚举来标识秒表运行状态。在初始状态 none 时，只有一个开始按钮；点击开始，秒表在运行中，此时显示三个按钮，重置按钮是灰色，不可点击，点击旗子按钮，可以记录当前秒表值；暂停时，旗子按钮不可点击，点击重置按钮时，回到初始态。

enum StopWatchType{

  none, // 初始态

  stopped, // 已停止

  running, // 运行中

}

如下所示，通过 _buildBtnByState 方法根据 StopWatchState 状态值构建底部按钮。根据不同的 state 情况处理不同的显示效果，这就是构建逻辑的体检。而此时的关键数据就是 StopWatchState 对象。

Widget _buildBtnByState(StopWatchType state) {

  bool running = state == StopWatchType.running;

  bool stopped = state == StopWatchType.stopped;

  Color activeColor  = Theme.of(context).primaryColor;

  return Wrap(

    spacing: 20,

    children: [

      if(state!=StopWatchType.none)

        FloatingActionButton(

        child: const Icon(Icons.refresh),

        backgroundColor: stopped?activeColor:Colors.grey,

        onPressed: stopped?reset:null,

      ),

      FloatingActionButton(

        child: running?const Icon(Icons.stop):const Icon(Icons.play_arrow_outlined),

        onPressed: onTapIcon,

      ),

      if(state!=StopWatchType.none)

        FloatingActionButton(

          backgroundColor: running?activeColor:Colors.grey,

          child: const Icon(Icons.flag),

        onPressed: running?onTapFlag:null,

      ),

    ],

  );

}

这样按照常理，应该在 _HomePageState 中定义 StopWatchType 对象，并在相关逻辑中维护 state 数据的值，如下 tag1,2,3 处：

StopWatchType state = StopWatchState.none;



void reset(){

  duration.value = Duration.zero;

  setState(() {

    state = StopWatchState.none; // tag1

  });

}



void onTapIcon() {

  if (_ticker.isTicking) {

    _ticker.stop();

    lastDuration = Duration.zero;

    setState(() {

      state = StopWatchType.stopped; // tag2

    });

  } else {

    _ticker.start();

    setState(() {

      state = StopWatchType.running; // tag3

    });

  }

}

4.秒表记录值的维护

如下所示，在秒表运行时点击旗子，可以记录当前的时刻并显示在右侧：

由于布局界面在 _HomePageState 中，事件的触发也在该类中定义。按照常理，又需要在其中维护 durationRecord 列表数据，进行界面的展现。

List<Duration> durationRecord = [];

final TextStyle recordTextStyle = const TextStyle(color: Colors.grey);



Widget buildRecordeList(){

  return ListView.builder(

      itemCount: durationRecord.length,

      itemBuilder: (_,index)=>Center(child:

      Padding(

        padding: const EdgeInsets.all(4.0),

        child: Text(

            durationRecord[index].toString(),style: recordTextStyle,

        ),

      )

      ));

}



void onTapFlag() {

  setState(() {

    durationRecord.add(duration.value);

  });

}



void reset(){

  duration.value = Duration.zero;

  durationRecord.clear();

  setState(() {

    state = StopWatchState.none;

  });

}

其实到这里可以发现，随着功能的增加，需要维护的数据会越来越多。虽然全部塞在 _HomePageState 类型访问和修改比较方便，但随着代码的增加，状态类会越来越臃肿。所以分离逻辑在复杂的场景中是非常必要的。

5. 基于 flutter_bloc 的状态管理

状态类的核心逻辑应该在于界面的 构建逻辑，而业务数据的维护，我们可以提取出来。这里通过 flutter_bloc 来将秒表中数据的维护逻辑进行分离，由 bloc 承担。

我们的目的是为 _HomePageState 状态类 "瘦身" ，如下，其中对于数据的处理逻辑都交由 StopWatchBloc 通过 add 相关事件来触发。_HomePageState 自身就无须书写维护业务数据的逻辑，可以在很大程度上减少 _HomePageState 的代码量，从而让状态类专注于界面构建逻辑。

class _HomePageState extends State<HomePage> {

  StopWatchBloc get stopWatchBloc => BlocProvider.of<StopWatchBloc>(context);



  void onTapIcon() {

    stopWatchBloc.add(const ToggleStopWatch());

  }



  void onTapFlag() {

    stopWatchBloc.add(const RecordeStopWatch());

  }



  void reset() {

    stopWatchBloc.add(const ResetStopWatch());

  }

首先创建状态类 StopWatchState 来维护这三个数据：

part of 'bloc.dart';



enum StopWatchType {

  none, // 初始态

  stopped, // 已停止

  running, // 运行中

}



class StopWatchState {

  final StopWatchType type;

  final List<Duration> durationRecord;

  final Duration duration;



  const StopWatchState({

    this.type = StopWatchType.none,

    this.durationRecord = const [],

    this.duration = Duration.zero,

  });



  StopWatchState copyWith({

    StopWatchType? type,

    List<Duration>? durationRecord,

    Duration? duration,

  }) {

    return StopWatchState(

      type: type ?? this.type,

      durationRecord: durationRecord??this.durationRecord,

      duration: duration??this.duration,

    );

  }

}

然后定义先关的行为事件，比如 ToggleStopWatch 用于开启或暂停秒表；ResetStopWatch 用于重置秒表；RecordeStopWatch 用于记录值。这就是最核心的三个功能：

abstract class StopWatchEvent {

  const StopWatchEvent();

}



class ResetStopWatch extends StopWatchEvent{

  const ResetStopWatch();

}



class ToggleStopWatch extends StopWatchEvent {

  const ToggleStopWatch();

}



class _UpdateDuration extends StopWatchEvent {

  final Duration duration;



  _UpdateDuration(this.duration);

}



class RecordeStopWatch extends StopWatchEvent {

  const RecordeStopWatch();

}

最后在 StopWatchBloc 中监听相关的事件，进行逻辑处理，产出正确的 StopWatchState 状态量。这样就将数据的维护逻辑封装到了 StopWatchBloc 中。

part 'event.dart';

part 'state.dart';



class StopWatchBloc extends Bloc<StopWatchEvent,StopWatchState>{

  Ticker? _ticker;



  StopWatchBloc():super(const StopWatchState()){

    on<ToggleStopWatch>(_onToggleStopWatch);

    on<ResetStopWatch>(_onResetStopWatch);

    on<RecordeStopWatch>(_onRecordeStopWatch);

    on<_UpdateDuration>(_onUpdateDuration);

  }



  void _initTickerWhenNull() {

    if(_ticker!=null) return;

    _ticker = Ticker(_onTick);

  }



  Duration _dt = Duration.zero;

  Duration _lastDuration = Duration.zero;





  void _onTick(Duration elapsed) {

    _dt = elapsed - _lastDuration;

    add(_UpdateDuration(state.duration+_dt));

    _lastDuration = elapsed;

  }



  @override

  Future<void> close() async{

    _ticker?.dispose();

    _ticker = null;

    return super.close();

  }



  void _onToggleStopWatch(ToggleStopWatch event, Emitter<StopWatchState> emit) {

    _initTickerWhenNull();

    if (_ticker!.isTicking) {

      _ticker!.stop();

      _lastDuration = Duration.zero;

      emit(state.copyWith(type:StopWatchType.stopped));

    } else {

      _ticker!.start();

      emit(state.copyWith(type:StopWatchType.running));

    }

  }



  void _onUpdateDuration(_UpdateDuration event, Emitter<StopWatchState> emit) {

    emit(state.copyWith(

      duration: event.duration

    ));

  }



  void _onResetStopWatch(ResetStopWatch event, Emitter<StopWatchState> emit) {

    _lastDuration = Duration.zero;

    emit(const StopWatchState());

  }



  void _onRecordeStopWatch(RecordeStopWatch event, Emitter<StopWatchState> emit) {

    List<Duration> currentList = state.durationRecord.map((e) => e).toList();

    currentList.add(state.duration);

    emit(state.copyWith(durationRecord: currentList));

  }

}

6. 组件状态类对状态的访问

这样 StopWatchBloc 封装了状态的变化逻辑，那如何在构建时让 组件状态类 访问到 StopWatchState 呢？实现需要在 HomePage 的上层包裹 BlocProvider 来为子节点能访问 StopWatchBloc 对象。

BlocProvider(

  create: (_) => StopWatchBloc(),

  child: const HomePage(),

),

比如构建表盘是通过 BlocBuilder 替代 ValueListenableBuilder ，这样当状态量 StopWatchState 发生变化是，且满足 buildWhen 条件时，就会 局部构建 来更新 StopWatchWidget 组件 。其他两个部分同理。这样在保证功能的实现下，就对逻辑进行了分离：

Widget buildStopWatch() {

  return BlocBuilder<StopWatchBloc, StopWatchState>(

    buildWhen: (p, n) => p.duration != n.duration,

    builder: (_, state) => StopWatchWidget(

      duration: state.duration,

      radius: 120,

    ),

  );

}

另外，由于数据已经分离，记录数据已经和 _HomePageState 解除了耦合。这就意味着记录面板可以毫无顾虑地单独分离出来，独立维护。这又进一步简化了 _HomePageState 中的构建逻辑，简化代码，便于阅读，这就是一个良性的反馈链。

到这里，关于通过状态管理如何分离 业务逻辑 和构建逻辑 就介绍的差不多了，大家可以细细品味。其实所有的状态管理库都大同小异，它们的目的不是在于 优化性能 ，而是在于 优化结构层次 。这里用的是 flutter_bloc ，你完全也可以使用其他的状态管理来实现类似的分离。工具千变万化，但思想万变不离其宗。谢谢观看 ~

前言

最近有一个小需求：图表支持局部显示，如下底部的区域选择器支持

• 左右拖动调节中间区域


• 拖拽中间区域，可以进行移动


• 图表数据根据中间区域的占比进行显示部分数据

这样当图表的数据量过大，不宜全部展示时，可选择的局部展示就是个不错的解决方案。由于一般的图表库没有提供该功能，这里自己通过绘制来实现以下，操作效果如下所示：

1. 使用 chart_range_selector

目前这个范围选择器已经发布到 pub 上了，名字是 chart_range_selector。大家可以通过依赖进行添加

dependencies:

  chart_range_selector: ^1.0.0

这个库本身是作为独立 UI 组件存在的，在拖拽过程中改变区域范围时，会触发回调。使用者可以通过监听来获取当前区域的范围。这里的区域起止是以分率的形式给出的，也就是最左侧是 0 最右侧是 1 。如下的区域范围是 0.26 ~ 0.72 。

ChartRangeSelector(

  height: 30,

  initStart: 0.4,

  initEnd: 0.6,

  onChartRangeChange: _onChartRangeChange,

),



void _onChartRangeChange(double start, double end) {

  print("start:$start, end:$end");

}

封装的组件名为： ChartRangeSelector ，提供了如下的一些配置参数：

2. ChartRangeSelector 实现思路分析

这个组件整体上是通过 ChartRangeSelectorPainter 绘制出来的，其实这些图形都是挺规整的，绘制来说并不是什么难事。重点在于事件的处理，拖拽不同的部位需要处理不同的逻辑，还涉及对拖拽部位的校验、高亮示意，对这块的整合还是需要一定的功力的。

代码中通过 RangeData 可监听对象为绘制提供必要的数据，其中 minGap 用于控制范围的最小值，保证范围不会过小。另外定义了 OperationType 枚举表示操作，其中有四个元素，none 表示没有拖拽的普通状态；dragHead 表示拖动起始块，dragTail 表示拖动终止块，dragZone 表示拖动范围区域。

enum OperationType{

  none,

  dragHead,

  dragTail,

  dragZone

}



class RangeData extends ChangeNotifier {

  double start;

  double end;

  double minGap;

  OperationType operationType=OperationType.none;



  RangeData({this.start = 0, this.end = 1,this.minGap=0.1});

  

  //暂略相关方法...

}

在组件构建中，通过 LayoutBuilder 获取组件的约束信息，从而获得约束区域宽度最大值，也就是说组件区域的宽度值由使用者自行约束，该组件并不强制指定。使用 SizedBox 限定画板的高度，通过 CustomPaint 组件使用 ChartRangeSelectorPainter 进行绘制。使用 GestureDetector 组件进行手势交互监听，这就是该组件整体上实现的思路。

3.核心代码实现分析

可以看出，这个组件的核心就是 绘制 + 手势交互 。其中绘制比较简单，就是根据 RangeData 数据和颜色配置画些方块而已，稍微困难一点的是对左右控制柄位置的计算。另外，三个可拖拽物的激活状态是通过 RangeData#operationType 进行判断的。

也就是说所有问题的焦点都集中在 手势交互 中对 RangeData 数据的更新。如下是处理按下的逻辑，当触电横坐标左右 10 逻辑像素之内，表示激活头部。如下 tag1 处通过 dragHead 方法更新 operationType 并触发通知，这样画板绘制时就会激活头部块，右侧和中间的激活同理。

---->[RangeData#dragHead]----

void dragHead(){

  operationType=OperationType.dragHead;

  notifyListeners();

}

void _onPanDown(DragDownDetails details, double width) {

  double start = width * rangeData.start;

  double x = details.localPosition.dx;

  double end = width * rangeData.end;

  if (x >= start - 10 && x <= end + 10) {

    if ((start - details.localPosition.dx).abs() < 10) {

      rangeData.dragHead(); // tag1

      return;

    }

    if ((end - details.localPosition.dx).abs() < 10) {

      rangeData.dragTail();

      return;

    }

    rangeData.dragZone();

  }

}

对于拖手势的处理，是比较复杂的。如下根据 operationType 进行不同的逻辑处理，比如当 dragHead 时，触发 RangeData#moveHead 方法移动 start 值。这里将具体地逻辑封装在 RangeData 类中。可以使代码更加简洁明了，每个操作都有 bool 返回值用于校验区域也没有发生变化，比如拖拽到 0 时，继续拖拽是会触发事件的，此时返回 false，避免无意义的 onChartRangeChange 回调触发。

void _onUpdate(DragUpdateDetails details, double width) {

  bool changed = false;

  if (rangeData.operationType == OperationType.dragHead) {

    changed = rangeData.moveHead(details.delta.dx / width);

  }

  if (rangeData.operationType == OperationType.dragTail) {

    changed = rangeData.moveTail(details.delta.dx / width);

  }

  if (rangeData.operationType == OperationType.dragZone) {

    changed = rangeData.move(details.delta.dx / width);

  }

  if (changed) widget.onChartRangeChange.call(rangeData.start, rangeData.end);

}

如下是 RangeData#moveHead 的处理逻辑，_recordStart 用于记录起始值，如果移动后未改变，返回 false。表示不执行通知和触发回调。

---->[RangeData#moveHead]----

bool moveHead(double ds) {

  start += ds;

  start = start.clamp(0, end - minGap);

  if (start == _recordStart) return false;

  _recordStart = start;

  notifyListeners();

  return true;

}

4. 结合图表使用

下面是结合 charts_flutter 图标库实现的范围显示案例。其中核心点是 domainAxis 可以通过 NumericAxisSpec 来显示某个范围的数据，而 ChartRangeSelector 提供拽的交互操作来更新这个范围，可谓相辅相成。

class RangeChartDemo extends StatefulWidget {

  const RangeChartDemo({Key? key}) : super(key: key);



  @override

  State<RangeChartDemo> createState() => _RangeChartDemoState();

}



class _RangeChartDemoState extends State<RangeChartDemo> {

  List<ChartData> data = [];



  int start = 0;

  int end = 0;



  @override

  void initState() {

    super.initState();

    data = randomDayData(count: 96);

    start = 0;

    end = (0.8 * data.length).toInt();

  }



  Random random = Random();



  List<ChartData> randomDayData({int count = 1440}) {

    return List.generate(count, (index) {

      int value = 50 + random.nextInt(200);

      return ChartData(index, value);

    });

  }



  @override

  Widget build(BuildContext context) {



    List<charts.Series<ChartData, int>> seriesList = [

      charts.Series<ChartData, int>(

        id: 'something',

        colorFn: (_, __) => charts.MaterialPalette.blue.shadeDefault,

        domainFn: (ChartData sales, _) => sales.index,

        measureFn: (ChartData sales, _) => sales.value,

        data: data,

      )

    ];



    return Column(

      children: [

        Expanded(

          child: charts.LineChart(seriesList,

              animate: false,

              primaryMeasureAxis: const charts.NumericAxisSpec(

                  tickProviderSpec: charts.BasicNumericTickProviderSpec(desiredTickCount: 5),),

              domainAxis: charts.NumericAxisSpec(

                viewport: charts.NumericExtents(start, end),

              )),

        ),

        const SizedBox(

          height: 10,

        ),

        SizedBox(

          width: 400,

          child: ChartRangeSelector(

              height: 30,

              initEnd: 0.5,

              initStart: 0.3,

              onChartRangeChange: (start, end) {

                this.start = (start * data.length).toInt();

                this.end = (end * data.length).toInt();

                setState(() {});

              }),

        ),

      ],

    );

  }

}



class ChartData {

  final int index;

  final int value;



  ChartData(this.index, this.value);

}

本文就介绍到这里，更多的实现细节感兴趣的可以研究一下源码。谢谢观看 ~

collect通知flow执行

public suspend inline fun <T> Flow<T>.collect(crossinline action: suspend (value: T) -> Unit): Unit =

    collect(object : FlowCollector<T> {

        override suspend fun emit(value: T) = action(value)

    })

flow是冷流，只有调用collect{}方法时才能触发flow代码块的执行。还有一点要注意，collect{}方法是个suspend声明的方法，需要在协程作用域的范围能调用。

除此之外，collect{}方法的参数是一个被crossinline修饰的函数类型，旨在加强内联，禁止在该函数类型中直接使用return关键字（return@标签除外）。

fun main() {

    GlobalScope.launch {

        flow {

            emit("haha")

        }.collect {

            

        }

    }

}

launchIn()指定协程作用域通知flow执行

public fun <T> Flow<T>.launchIn(scope: CoroutineScope): Job = scope.launch {

    collect() // tail-call

}

这个方法允许我们直接传入一个协程作用域的参数，不需要直接在外部开启一个协程执行。本质上就是使用我们传入的协程作用域手动开启一个协程代码块调用collect{}通知协程执行。

这里看官方的源码有个tail-call的注释，也就是尾调用的意思，猜测这里可能官方会在这里进行了优化，减少了栈中方法调用的层级，降低栈溢出的风险。

fun main() {

    flow {

        emit("haha")

    }.launchIn(GlobalScope)

}

catch{}捕捉异常

public fun <T> Flow<T>.catch(action: suspend FlowCollector<T>.(cause: Throwable) -> Unit): Flow<T> =

    flow {

        val exception = catchImpl(this)

        if (exception != null) action(exception)

    }

这个就是用来捕捉异常的，不过注意，只能捕捉catch()之前的异常，下面来个图阐述下：

即，只能捕捉第一个红框中的异常，而不能捕捉第二个红框中的异常。

merge()合流

public fun <T> merge(vararg flows: Flow<T>): Flow<T> = flows.asIterable().merge()

最终的实现类如下：

请注意，这个合流的每个流可以理解为是并行执行的，而不是后一个流等待前一个流中的flow代码块中的逻辑执行完毕再执行，这样做的目的可以提供合流的每个流的执行效果。

测试代码如下：

fun main() {

    GlobalScope.launch {

        merge(flow {

            delay(1000)

            emit(4)

        }, flow {

            println("flow2")

            delay(2000)

            emit(20)

        }).collect {

            println("collect value: $it")

        }

    }

}

输出日志如下：

、

map{}变换发送的数据类型

public inline fun <T, R> Flow<T>.map(crossinline transform: suspend (value: T) -> R): Flow<R> = transform { value ->

   return@transform emit(transform(value))

}

这个api没什么可将的，很多的地方比如集合、livedata中都有它的影子，它的作用就是将当前数据类型变换成另一种数据类型（可以相同）。

fun main() {

    GlobalScope.launch {

        flow {

            emit(5)

        }.map {

            "ha".repeat(it)

        }.collect {

            println("collect value: $it")

        }

    }

}

总结

本篇文章介绍了flow常见的api，接下来还会有一些列文章用来介绍flow的其他api，感谢阅读。

在Android应用的开发中，必然会遇上通知的开发需求，本文主要讲一下Android中的通知 Notification的简单基本使用，主要包含创建通知渠道、初始化通知、显示通知、显示图片通知、通知点击、以及配合WorkManager发送延迟通知。

Demo下载

创建通知渠道

首先，创建几个常量和变量，其中渠道名是会显示在手机设置-通知里app对应展示的通知渠道名称，一般基于通知作用取名。

    companion object {

        //渠道Id

        private const val CHANNEL_ID = "渠道Id"



        //渠道名

        private const val CHANNEL_NAME = "渠道名-简单通知"



        //渠道重要级

        private const val CHANNEL_IMPORTANCE = NotificationManager.IMPORTANCE_DEFAULT

    }



    private lateinit var context: Context



    //Notification的ID

    private var notifyId = 100

    private lateinit var manager: NotificationManager

    private lateinit var builder: NotificationCompat.Builder

然后获取系统通知服务，创建通知渠道，其中因为通知渠道是Android8.0才有的，所以增加一个版本判断：

        //获取系统通知服务

        manager = context.getSystemService(Context.NOTIFICATION_SERVICE) as NotificationManager

        //创建通知渠道，Android8.0及以上需要

        createChannel()

    private fun createChannel() {

        //创建通知渠道，Android8.0及以上需要

        if (Build.VERSION.SDK_INT < Build.VERSION_CODES.O) {

            return

        }

        val notificationChannel = NotificationChannel(

            CHANNEL_ID,

            CHANNEL_NAME,

            CHANNEL_IMPORTANCE

        )

        manager.createNotificationChannel(notificationChannel)

    }

初始化通知

先生成NotificationCompat.Builder，然后初始化通知Builder的通用配置：

        builder = NotificationCompat.Builder(context.applicationContext, CHANNEL_ID)

        initNotificationBuilder()

    /**

     * 初始化通知Builder的通用配置

     */

    private fun initNotificationBuilder() {

        builder

            .setAutoCancel(true) //设置这个标志当用户单击面板就可以让通知自动取消

            .setSmallIcon(R.drawable.ic_reminder) //通知的图标

            .setWhen(System.currentTimeMillis()) //通知产生的时间，会在通知信息里显示

            .setDefaults(Notification.DEFAULT_ALL)

    }

此外builder还有setVibrate、setSound、setStyle等方法，按需配置即可。

显示通知

给builder设置需要通知需要显示的title和content，然后通过builder.build()生成生成通知Notification，manager.notify()方法将通知发送出去。

    fun configNotificationAndSend(title: String, content: String){

        builder.setContentTitle(title)

            .setContentText(content)

        val notification = builder.build()

        //发送通知

        manager.notify(notifyId, notification)

        //id自增

        notifyId++

    }

最简单的通知显示至此上面三步就完成了。

效果如下图：

显示图片通知

当通知内容过多一行展示不下时，可以通过设置

builder.setStyle(NotificationCompat.BigTextStyle().bigText(content)) //设置可以显示多行文本

这样通知就能收缩和展开，显示多行文本。 另外setStyle还可以设置图片形式的通知：

setStyle(NotificationCompat.BigPictureStyle().bigPicture(BitmapFactory.decodeResource(resources,R.drawable.logo)))//设置图片样式

效果如下图：

通知点击

目前为止的通知还只是显示，因为设置了builder.setAutoCancel(true)，点击通知之后通知会自动消失，除此之外还没有其他操作。 给builder设置setContentIntent(PendingIntent)就能有通知点击之后的其他操作了。PendingIntent可以看作是对Intent的一个封装，但它不是立刻执行某个行为，而是满足某些条件或触发某些事件后才执行指定的行为。PendingIntent获取有三种方式：Activity、Service和BroadcastReceiver获取。通过对应方法PendingIntent.getActivity、PendingIntent.getBroadcast、PendingIntent.getService就能获取。 这里就示例一下PendingIntent.getBroadcast和PendingIntent.getActivity

PendingIntent.getBroadcast

首先创建一个BroadcastReceiver：

class NotificationHandleReceiver : BroadcastReceiver() {

    companion object {

        const val NOTIFICATION_HANDLE_ACTION = "notification_handle_action"

        const val NOTIFICATION_LINK = "notificationLink"

        const val TAG = "NotificationReceiver"

    }



    override fun onReceive(context: Context, intent: Intent?) {

        if (intent?.action == NOTIFICATION_HANDLE_ACTION) {

            val link = intent.getStringExtra(NOTIFICATION_LINK)

        }

    }

}

别忘了在清单文件中还需要静态注册BroadcastReceiver：

    <receiver

        android:name=".NotificationHandleReceiver"

        android:exported="false">

        <intent-filter>

            <action android:name="notification_handle_action" />

        </intent-filter>

    </receiver>

然后创建一个上面BroadcastReceiver的Intent，在intent.putExtra传入相应的点击通知之后需要识别的操作：

   fun generateDefaultBroadcastPendingIntent(linkParams: (() -> String)?): PendingIntent {

        val intent = Intent(NotificationHandleReceiver.NOTIFICATION_HANDLE_ACTION)

        intent.setPackage(context.packageName)

        linkParams?.let {

            val params = it.invoke()

            intent.putExtra(NotificationHandleReceiver.NOTIFICATION_LINK, params)

        }

        return PendingIntent.getBroadcast(

            context,

            notifyId,

            intent,

            PendingIntent.FLAG_IMMUTABLE

        )

    }

这样生成的PendingIntent再builder.setContentIntent(pendingIntent)，在我们点击通知之后，NotificationHandleReceiver的onReceive里就会收到信息了，根据信息处理后续操作即可。

PendingIntent. getActivity

Activity的PendingIntent用于跳转到指定activity，创建一个跳转activity的Intent(同普通的页面跳转的Intent)，也是同上面在intent.putExtra传入相应的点击通知之后需要识别的操作：

        val intent = Intent(this, XXXX::class.java).apply {

            putExtra("title", title).putExtra("content", content)

        }

        return PendingIntent.getActivity(context, 0, intent, PendingIntent.FLAG_IMMUTABLE)

也是这样生成的PendingIntent再builder.setContentIntent(pendingIntent)，在我们点击通知之后，就会跳转到对应的activity页面，然后intent里就会收到信息了，根据信息处理后续操作即可。

Android12之PendingIntent特性

行为变更：以 Android 12 为目标平台的应用

查看上面关于Android12的特性

在Android12平台上有关于PendingIntent的两点特性：

• 一是待处理 intent 可变性，必须为应用创建的每个 PendingIntent 对象指定可变性，这也是上面创建PendingIntent时需要设置flag为PendingIntent.FLAG_IMMUTABLE。
• 二是通知 trampoline 限制，以 Android 12 或更高版本为目标平台的应用无法从用作通知 trampoline 的服务或广播接收器中启动 activity。换言之，当用户点按通知或通知中的操作按钮时，您的应用无法在服务或广播接收器内调用 startActivity()。所以当需要点击通知实现activity跳转时，需要使用PendingIntent. getActivity，而不是使用PendingIntent.getBroadcast，然后在BroadcastReceiver里实现activity跳转，后者方式在Android 12 或更高版本为目标平台的应用中将被限制。

配合WorkManager发送延迟通知

配合上WorkManager，就能实现发送延迟通知，主要是通过OneTimeWorkRequest的延迟特性。

创建一个延迟的OneTimeWorkRequest，加入WorkManager队列中：

    fun sendWorkRequest(

        context: Context,

        reminderId: Int,

        title: String,

        content: String,

        link: String,

        triggerTime: Long

    ): OneTimeWorkRequest {

        val duration = triggerTime - System.currentTimeMillis()

        val data =

            Data.Builder().putInt(REMINDER_WORKER_DATA_ID, reminderId).putString(REMINDER_WORKER_DATA_TITLE, title)

                .putString(REMINDER_WORKER_DATA_CONTENT, content).putString(REMINDER_WORKER_DATA_LINK, link)

                .build()

        val uniqueWorkName =

            "reminderData_${reminderId}"

        val request = OneTimeWorkRequest.Builder(ReminderWorker::class.java)

            .setInitialDelay(duration, TimeUnit.MILLISECONDS)

            .setInputData(data)

            .build()

        WorkManager.getInstance(context)

            .enqueueUniqueWork(uniqueWorkName, ExistingWorkPolicy.REPLACE, request)

        return request

    }

然后在doWork方法中拿到数据进行我们上面的通知发送显示即可。具体关于OneTimeWorkRequest的使用在本文中就不详细说明了。当需要发送延迟通知时，知道可以通过配合WorkManager实现。

Android13 通知权限

在目前最新的Android 13（API 级别 33）上对于通知增加了权限限制，具体可看官方描述：

通知运行时权限

前言

许多编程语⾔（包括 Java）中最常⻅的错误之⼀，就是访问空成员会导致空异常(NullPointerException 或简称 NPE)。

开发中，经常会遇到空指针异常，如果对这个问题处理不当，还会引起程序的崩溃（crash），在Kotlin中，为了避免出现空指针异常，引入了 Null机制，本篇就来了解一下Kotlin中的 Null机制。

本文总览

1. 可空类型变量（?）

Kotlin中把变量分成了两种类型

• 可空类型变量


• 非空类型变量

通常，一个变量默认是非空类型。若要变量的值可以为空，必须在声明处的数据类型后添加 ? 来标识该变量可为空。如下示例：

var phone: String   //声明非空变量 

var price: Int?     //声明可空变量

上述代码中，phone 为非空变量，price 为可空变量。若给变量name赋值为null，编译器会提示“Null can not be a value of a non-null type String”错误信息。引起这个错误的原因是Kotlin官方约定变量默认为非空类型时，该变量不能赋值为null， 而price 赋值为null，编译可以通过。

声明可空变量时，若不知道初始值，则需将其赋值为null，否则会报“variable price must be initialized”异常信息。

通过一段示例代码来学习如何判断变量是否为空，以及如何使用可空变量：

fun main() {

    var name: String = "Any"    // 非空变量

    var phone: String? = null   // 可空变量

    if (phone != null) {

        print(phone.length)

    } else {

        phone = "12345678901"

        print("phone = " + phone)

   }

}

运行结果：

phone = 12345678901

上述代码，定义一个非空变量 name，一个可空变量 phone。这段示例代码对可空变量进行判断，如果 phone 不为空则输出 phone的长度，否则将phone赋值为12345678901并打印输出。

2. 安全调用符（?.）

上一点的示例中，可空变量在使用时需要先通过if…else判断，然后再进行相应的操作，这样使用还是比较繁琐。Kotlin提供了一个安全调用符?.，用于调用可空类型变量中的成员方法或属性，语法格式为“变量?.成员”。其作用是先判断变量是否为null，如果不为null才调用变量的成员方法或者属性。

fun main() {

    var name: String = "Any"

    var phone: String? = null

    var result = phone?.length

    println(result)

}

运行结果：

null

结果可以看出，在使用?.调用可空变量的属性时，若当前变量为空，则程序编译正常运行，且返回一个null值。

3. Elvis操作符（?:）

安全调用符调用可空变量中的成员方法或属性时，如果当前变量为空，则返回一个null值，但有时不想返回一个null值而是指定一个默认值，该如何处理呢？Kotlin中提供了一个Elvis操作符（?:），通过Elvis操作符（?:）可以指定可空变量为null时，调用该变量中的成员方法或属性的返回值，其语法格式为 表达式 ?: 表达式 。若左边表达式非空，则返回左边表达式的值，否则返回右边表达式的值。

fun main() {

    var name: String = "Any"

    var phone: String? = null

    var result = phone?.length ?: "12345678901"

    println(result)

}

运行结果：

12345678901

从结果可以看出，当变量phone为空时，使用?:操作符会返回指定的默认值“12345678901”，而非null值。

4. 非空断言（!!.）

除了使用安全调用符（?.）来使用可空类型的变量之外，还可以通过非空断言（!!.）来调用可空类型变量的成员方法或属性。使用非空断言时，调用变量成员方法或属性的语法结构为 “变量!!.成员” 。非空断言（!!.）会将任何变量（可空类型变量或者非空类型变量）转换为非空类型的变量，若该变量为空则抛出异常。接下来我们通过一个例子来演示非空断言（!!.）的使用，具体代码如下所示。

fun main() {

    var phone: String? = null    // 声明可空类型变量

    var result = phone!!.length  // 使用非空断言

    println(result)

}

运行结果：

Exception in thread"main"kotlin.KotlinNullPointerException

at NoEmptyAssertionKt.main

（NoEmptyAssertion.kt:4）

运行结果抛出了空指针异常，若变量phone赋值不为空，则程序可以正常运行。

安全调用符与非空断言运算符都可以调用可空变量的方法，但是在使用时有一定的差别，如表所示。

总结

上面四种情况的介绍，可以说的很全面地囊括 kotlin 中的空处理情况，开发中应根据实际场景使用合适的操作符。

本文一个定制样式的SwitchButton，使用Compose来写是非常容易的，下面先来看看我们对外提供如下方法：

@Composeable

fun IosSwitchButton(

    modifier: Modifier,

    checked: Boolean,

    width: Dp = 50.dp,

    height: Dp = 30.dp,

    // Thumb和Track的边缘间距

    gapBetweenThumbAndTrackEdge: Dp = 2.dp,

    checkedTrackColor: Color = Color(0xFF4D7DEE),

    uncheckedTrackColor: Color = Color(0xFFC7C7C7),

    onCheckedChange: ((Boolean) -> Unit)

)

我们先来实现点击切换，后面再来实现滑动切换，checked状态是需要外面(ViewModel)传过来，同样onCheckedChange回调的状态，需要同步更新到ViewModel中。

我们来简单的看看，只实现，点击切换按钮状态的效果代码：

// 定义按钮点击的状态记录

val switchONState = remember { mutableStateOf(checked) }

// Thumb的半径大小

val thumbRadius = height / 2 - gapBetweenThumbAndTrackEdge

// Thumb水平的位移

val thumbOffsetAnimX by animateFloatAsState(

    targetValue = if (checked)

       with(LocalDensity.current) { (width - thumbRadius - gapBetweenThumbAndTrackEdge).toPx() }

    else

       with(LocalDensity.current) { (thumbRadius + gapBetweenThumbAndTrackEdge).toPx() }

)

// Track颜色动画

val trackAnimColor by animateColorAsState(

    targetValue = if (checked) checkedTrackColor else uncheckedTrackColor

)

上面的准备工作做完，我们就需要用到Canvas 来绘制Thumb和Track，按钮的点击我们需要用Modifier的pointerInput修饰符提供点按手势检测器:

Modifier.pointerInput(Unit) {

    detectTapGestures(

        onPress = { /* Called when the gesture starts */ },

        onDoubleTap = { /* Called on Double Tap */ },

        onLongPress = { /* Called on Long Press */ },

        onTap = { /* Called on Tap */ }

    )

}

看看我们的Canvas

Canvas(

   modifier = modifier

       .size(width = width, height = height)

       .pointerInput(Unit) {

           detectTapGestures(

               onTap = {

                   // 更新切换状态

                   switchONState.value = !switchONState.value

                   onCheckedChange.invoke(switchONState.value)

               }

           )

       }

) {

    // 这里绘制Track和Thumb

}

绘制Track，我们需要更新drawRoundRect的color值，我们使用上面根据checked状态变更后的trackAnimColor颜色值：

drawRoundRect(

   color = animateTrackColor,

   // 圆角

   cornerRadius = CornerRadius(x = height.toPx(), y = height.toPx())

)

绘制Thumb，我们需要更新drawCircle里面的中心坐标X轴数值，我们使用状态变更后的动画值thumbOffsetAnimX：

drawCircle(

    color = Color.White,

    // Thumb的半径

    radius = thumbRadius.toPx(),

    center = Offset(

        x = thumbOffsetAnimX,

        y = size.height / 2

    )

)

上面实现只有点击功能，效果如下:

只能点击

GIF录制的效果不太明显，实际上根据大家个人的需求，如果只是为了点击能切换，上面的十几行代码就足够了；

当然我们对效果还是有追求的，请继续往下看，我们来看，如何实现滑动切换,我们还是看一下最后实现可滑动，可点击的效果吧，方便我们下面讲解：

可滑动，可点击，动画连贯

一定要记得：『点赞❤️+关注❤️+收藏❤️』起来，划走了可就再也找不到了😅😅🙈🙈

既然要用到滑动，那么我们就需要使用到Modifier的swipeable修饰符：

允许我们通过锚点设置，实现组件呈现吸附效果的动画，常用于开关等动画，需要注意的是：swipeable不会为被修饰的组件提供任何默认动画，只能为组件提供手势偏移量等信息。可以根据偏移量结合其他修饰符定制动画。

我们这里需要同时实现“点击”和“滑动”，这里需要把这2个修饰符组合到一个扩展文件里面，我们创建一个IOSSwitchModifierExtensions.kt文件:

// IOSSwitchModifierExtensions.kt



@ExperimentalMaterialApi

internal fun Modifier.swipeTrack(

    anchors: Map<Float, Int>,

    swipeableState: SwipeableState<Int>,

    onClick: () -> Unit

) = composed {

    this.then(Modifier

        .pointerInput(Unit) {

            detectTapGestures(

                onTap = {

                    // 点击回调

                    onClick.invoke()

                }

            )

        }

        .swipeable(

            state = swipeableState,

            anchors = anchors,

            thresholds = { _, _ ->

                // 锚点间吸附效果的临界阈值

                FractionalThreshold(0.3F)

            },

            // 水平方向

            orientation = Orientation.Horizontal

        )

    )

}

我们下面会用到这个扩展方法，我们可以看到swipeable修饰符，需要SwipeableState和anchors

初始化swipeableState

val swipeableState = rememberSwipeableState(initialValue = 0, animationSpec = tween())

我们还需要初始化anchors设置在不同状态时对应的偏移量信息:

// Thumb的半径

val thumbRadius = (height / 2) - gapBetweenThumbAndTrackEdge

// 开始的锚点位置

val startAnchor = with(LocalDensity.current) {

   (thumbRadius + gapBetweenThumbAndTrackEdge).toPx()

}

// 结束的锚点位置

val endAnchor = with(LocalDensity.current) {

   (width - thumbRadius - gapBetweenThumbAndTrackEdge).toPx()

}

// 根据上面的注释，很明显了

val anchors = mapOf(startAnchor to 0, endAnchor to 1)

到这里，我们需要如何继续呢，我仍然是通过录制视频，然后通过一帧一帧的去分析IOS样式的switch动画效果来做的。

我们先看最终效果图，然后继续往下拆解：

可以看到，拖动Thumb的时候，灰色的矩形区域是缩小的，然后蓝色部分是一个颜色渐变动画，同样的，点击也是需要做对应的工作。

大家先思考一下，点击和滑动怎么做到一样的？

我们发现Swipeable有个animateTo方法，那这不就好使了吗？对不对

// 代码来自androidx.compose.material.Swipeable.kt

// 通过动画将状态设置为targetValue

suspend fun animateTo(targetValue: T, anim: AnimationSpec<Float> = animationSpec)

来了一个点，第二个点，第三个点，都来了：

// 因为animateTo是挂起函数，我们需要在coroutineScope.launch里面执行

val scope = rememberCoroutineScope()

从上面看到这里的小伙伴，应该知道，我们上面定义了一个IOSSwitchModifierExtensions.kt文件，我们在swipeTrack的onClick方法里面执行animateTo，其实这个animateTo只是更新我们当前的checked状态而已。

Canvas(

    modifier = modifier

       .size(width = width, height = height)

       .swipeTrack(

           anchors = anchors,

           swipeableState = swipeableState,

           onClick = {

               scope.launch {

                  swipeableState.animateTo(if (!switchONState.value) 1 else 0)

               }

           }

       )

    ) {

    // 选中状态下的Track背景

    // 未选中状态下的Track背景

    // Thumb

}

接下来，应该怎么继续呢，我觉得大家可以先思考一下，再继续往下看。

刚刚上面，提到了有2个Track背景，一个背景是颜色渐变动画，一个是缩放动画。

Compose的Canvas怎么写scale呢？ 别急，我们可以在源码和文档中找到Canvas#scale

不仅仅可以scale，还可以rotate、insert、translate等等。

还有一个问题，背景颜色渐变动画，我们要用animate*AsState来做吗？
animate*AsState 函数是 Compose 中最简单的动画 API，用于为单个值添加动画效果。您只需提供结束值（或目标值），该 API 就会从当前值开始向指定值播放动画。

我们发现animate*AsState并不是我们想要的，我们想要的是：

滑动的时候根据“当前滑动移动的距离”来更新Track背景色渐变

没有用Compose的时候，我们可以用初始化一个ArgbEvaluator，然后调用：

argbEvaluator.evaluate(fraction, startColor, stopColor)

在Compose中，我们应该怎么做呢？
我们发现Color.kt中的一个方法lerp：
androidx.compose.ui.graphics.ColorKt#lerp

上面的疑惑全部解开，下面就看看我们剩下的实现吧：

// 未选中状态下的Track的scale大小（0F - 1F）

val unCheckedTrackScale = rememberSaveable { mutableStateOf(1F) }

// 选中状态下Track的背景渐变色

val checkedTrackLerpColor by remember {

    derivedStateOf {

        lerp(

           // 开始的颜色

           uncheckedTrackColor,

           // 结束的颜色

           checkedTrackColor,

           // 选中的Track颜色值，根据缩放值计算颜色【转换的渐变进度】

           min((1F - unCheckedTrackScale.value) * 2, 1F)

        )

    }

}



LaunchedEffect(swipeableState.offset.value) {

    val swipeOffset = swipeableState.offset.value

    // 未选中的Track缩放大小

    var trackScale: Float

    ((swipeOffset - startAnchor) / endAnchor).also {

         trackScale = if (it < 0F) 0F else it

    }

    // 未选中的Track缩放大小更新，上面👆👆的:选中的Track颜色值，是根据这个来算的

    unCheckedTrackScale.value = 1F - trackScale

    // 更新开关状态

    switchONState.value = swipeOffset >= endAnchor

    // 回调状态

    onCheckedChange.invoke(switchONState.value)

}

所以，我们的Canvas里面Track和Thumb最终颜色和缩放，是根据上面计算出来的值来更新的：

Canvas(

    modifier = modifier.size(...).swipeTrack(...)

) {

   // 选中状态下的背景

   drawRoundRect(

       //这种的不再使用：Color(ArgbEvaluator().evaluate(t, AndroidColor.RED, AndroidColor.BLUE) as Int)

       color = checkedTrackLerpColor,

       cornerRadius = CornerRadius(x = height.toPx(), y = height.toPx()),

   )

   // 未选中状态下的背景，随着滑动或者点击切换了状态，进行缩放

   scale(

       scaleX = unCheckedTrackScale.value,

       scaleY = unCheckedTrackScale.value,

       pivot = Offset(size.width * 1.0F / 2F + startAnchor, size.height * 1.0F / 2F)

    ) {

       drawRoundRect(

           color = uncheckedTrackColor,

           cornerRadius = CornerRadius(x = height.toPx(), y = height.toPx()),

       )

    }

    // Thumb

    drawCircle(

        color = Color.White,

        radius = thumbRadius.toPx(),

        center = Offset(swipeableState.offset.value, size.height / 2)

    )

}

经过上面的漫长分析和实现，最终效果如下：

源码地址： ComposeIOSSwitchButton

前言

对于Flutter开发者来说，build_runner 可以说并不是一个陌生的东西，很多package中就要求调用build_runner 来自动生成处理代码，比如说json_serializable;

但正如其描述中所述的那样，其是通过 Dart Build System来实现的，build_runner 和其又是一个什么关系，接下来就来学习一下dart的build系统

dart 的 build 系统

组成

dart 的 build系统，由 build_config、 build_modules、build_resolvers、 build_runner、 build_test、 build_web_compilers 共同组合、完成了dart 的 build 系统；