线程封闭

线程封闭一般通过以下三个方法：

1. Ad-hoc线程封闭：程序控制实现，最糟糕，忽略


2. 堆栈封闭：局部变量，无并发问题


3. ThreadLocal线程封闭：特别好的封闭方法

方法2是最常用的，变量定义在接口内，本文主要讲解方法三，SpringBoot项目通过自定义过滤器和拦截器实现ThreadLocal线程封闭。实现Filter接口自定义过滤器和继承HandlerInterceptorAdapter自定义拦截器。

ThreadLocal线程封闭实现步骤

封装ThredLocal的方法

/**

 * <p>自定义RequestHolder</p></p>

 *

 * @Author zjq

 * @Date 2021/12

 */

public class RequestHolder {



    private final static ThreadLocal<Long> requestHolder = new ThreadLocal<>();



    public static void set(Long id) {

        requestHolder.set(id);

    }



    public static Long get() {

        return requestHolder.get();

    }



    public static void remove() {

        requestHolder.remove();

    }



}

自定义过滤器

自定义定义拦截器继承Filter接口，实现ThredLocal.add()方法

/**

 * <p>自定义过滤器</p>

 *

 * @Author zjq

 * @Date 2021/12/7

 */

@Slf4j

public class HttpFilter implements Filter {



    /**

     * 为Filter初始化 提供支持

     *

     * @param filterConfig

     * @throws ServletException

     */

    @Override

    public void init(FilterConfig filterConfig) throws ServletException {



    }



    /**

     * 拦截到要执行的请求时，doFilter就会执行。这里我们可以写对请求和响应的预处理。

     * FilterChain把请求和响应传递给下一个 Filter处理

     *

     * @param servletRequest

     * @param servletResponse

     * @param filterChain

     * @throws IOException

     * @throws ServletException

     */

    @Override

    public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {

        //把普通servlet强转成httpServlet

        HttpServletRequest httpServletRequest = (HttpServletRequest) servletRequest;

        Long threadId = Thread.currentThread().getId();

        log.info("do filter,threadId:{} servletPath:{}", threadId, httpServletRequest.getServletPath());

        //把当前线程id放入requestHolder

        RequestHolder.set(threadId);

        //放行

        filterChain.doFilter(httpServletRequest, servletResponse);

    }



    /**

     * Filter 实例销毁前的准备工作

     */

    @Override

    public void destroy() {



    }

}

自定义拦截器

自定义拦截器在线程使用完毕后移除ThredLocal中内容，避免内存溢出

/**

 * <p>自定义拦截器</p>

 *

 * @Author zjq

 * @Date 2021/12/7

 */

@Slf4j

public class HttpInterceptor extends HandlerInterceptorAdapter {



    /**

     * 拦截处理程序的执行。在 HandlerMapping 确定合适的处理程序对象之后，在 HandlerAdapter 调用处理程序之前调用。

     * @param request

     * @param response

     * @param handler

     * @return

     * @throws Exception

     */

    @Override

    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {

        log.info("preHandle执行。。。");

        return true;

    }



    /**

     * 请求处理完成后（渲染视图后）的回调。将在处理程序执行的任何结果上调用，从而允许进行适当的资源清理。

     * @param request

     * @param response

     * @param handler

     * @param ex

     * @throws Exception

     */

    @Override

    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {

        RequestHolder.remove();

        log.info("afterCompletion执行。。。");

        return;

    }

}

Application类启动类中配置自定义过滤器和拦截器

/**

 * 

 * @author zjq

 */

@SpringBootApplication

public class Application extends WebMvcConfigurationSupport {



    public static void main(String[] args) {

        SpringApplication.run(ConcurrencyApplication.class, args);

    }



    /**

     * 自定义过滤器

     * @return

     */

    @Bean

    public FilterRegistrationBean filterRegistrationBean(){

        FilterRegistrationBean filterRegistrationBean = new FilterRegistrationBean();

        filterRegistrationBean.setFilter(new HttpFilter());

        //设置自定义过滤器拦截的url

        filterRegistrationBean.addUrlPatterns("/threadLocal/*");

        return filterRegistrationBean;

    }



    /**

     * 定义自定义拦截器原先需要继承WebMvcConfigurerAdapter

     * SpringBoot2.0后WebMvcConfigurerAdapter被定义成过时了，推荐使用继承WebMvcConfigurationSupport

     * @param registry

     */

    @Override

    public void addInterceptors(InterceptorRegistry registry) {

        registry.addInterceptor(new HttpInterceptor()).addPathPatterns("/**");

    }

}

定义调用接口

/**

 * ThreadLocal测试controller

 * @author zjq

 */

@Controller

@RequestMapping("/threadLocal")

public class ThreadLocalController {



    @RequestMapping("/test")

    @ResponseBody

    public Long test() {

        return RequestHolder.get();

    }

}

请求访问验证

访问调用接口，控制台输出如下：

看到结局的问题：如何区分StatelessWidget 和 StatefulWidget 的使用场景，不禁开始自问，对于StatefulWidget ，StatelessWidget，以及flutter中Widget的众多子类我真的足够了解吗？

对于自己经常要打交道的东西，如果只是一知半解则不利于进步。

下面就从源码的角度来学习下flutter基础的几个Widget 都起到了什么作用。

先给个简单总结：

• 其中StatelessWidget 和 StatefulWidget 起到了组织组合子组件的作用。


• RenderObjectWidget 起到渲染作用。包含绘制偏移和测量信息。


• ProxyWidget 可以携带信息，以供其他组件使用。

一、探索StatelessWidget的组件构建

在使用StatelessWidget的时候，通常只需要实现一个build方法。就拿我们常用的Container组件举例，他就是StatelessWidget 的子类。他的build方法返回的就是各种组件的组合嵌套。

他的各种成员属性也只是用来配置子组件的组合方式而已。

1. StatelessWidget 的build调用时机，以及widget树遍历流程

Container组件是StatelessWidget的经典子类。

我们通过断点调试看看Container 组件build方法的调用堆栈

在ComponentElement 的performRebuild 方法调用的时候，触发了build方法，从stateless中获取了build返回的Widget，而又在performRebuild 调用了updateChild方法，对所有的子孙Element进行build遍历。

ComponentElement是Widget对应元素StatelessElement和StatefulElement的父类。

我们拉到最初的调用栈。Element栈调用的起点在于attachRootWidget方法。

还记得我们flutter app开发的起点吗？就是runApp(App())方法，开启了整个flutter app。
attachRootWidget方法正是我们在调用runApp的时候执行的。

在其中，执行了RenderObjectToWidgetAdapter组件的初始化，将renderView 和 rootWidget作为入参。并且调用attachToRenderTree返回元素树顶点的Element。

三颗树的顶点

其中renderView是RenderObject树的顶点，_renderViewElement是Element树的顶点。匿名的RenderObjectToWidgetAdapter则是Widget树的顶点，但是他没有被引用。Widget树的维护依赖于Element树，rootWidget就是我们的runApp组件节点，被作为参数挂载到RenderObjectToWidgetAdapter根组件中，被后续的Element挂载循环使用。

Element中也存放了_parent变量，所以我们通过Element对象可以轻松的追溯到祖先节点。

我们从上面的分析可以得出ComponentElement 的 performRebuild方法是element.build传承关键方法 ，mount方法也能由此挂载出所有子树（其他类型的Element实现方案略有不同）

在ComponentElement中。也由performRebuild构建出一层层的子孙节点。代码如下，注意红色方框的代码。

第一个红框中是build()方法的执行。意味着每次performRebuild被调用的时候，子组件都会被build出来，由此可知widget是唯一的，每次更新都会有新的Widget生成。

在updateChild的过程中，如果子element还未生成，就会调用widget.createElement()方法获得element 。

我们再看StatelessWidget 的源码，实现了createElement方法返回了自定义的StatelessElement。

生成的子Element 都会在ComponentElement中被持有，以便后续更新

由此可知，ComponentElement维系了祖孙关系，其子类Element对应的 StatelessWidget，StatefulWidget，ParentDataWidget 和 InheritedWidget都天然拥有子孙关系能力。

如下所示，StatefulElement 是 ComponentElement 的子类。

2. StatelessWidget 和Element在渲染中的更新

widget的创建都是在element树遍历的过程中执行的。
widget树依赖于element树，在Element创建的时候widget实例将会被持有。
StatelessWidget在布局和渲染流程中依赖Element维系，树关系被Element挖掘。

在Element performeRebuild重新构建的时候，有一个是否更新Element的判定机制，以优化性能。
不管是更新update还是挂载mount，每次子widget都会先build()出来。再进行新旧比较。Widget都是一次性的，如果有状态需要保存是由其他方式实现的。
我们再看updateChild方法。上面一小节提到在子element为空的时候，会在其中createElement。而在子Element不为空的时候，会根据新旧Widget 的不同，进行不同的操作。

其中通过新旧widget的equals判定。决定是否复用之前的element。如果复用了element，根据canUpdate方法的返回值，来执行child.update方法。所以我们可以得出这样一个结论。

widget 的 canUpdate 实现，将很大程度上决定 Element 的复用。减少重新绘制，对State重新赋值，甚至状态丢失的资源浪费。

3. 探索key的作用

canUpdate的默认实现中以Widget的类型和key作为关键字进行判断。如果有对key定义，那么Key的一致性就会对widget的更新显得尤为关键。

这也是我们在做性能优化的时候需要注意的。可以利用Key的配置，来控制组件是否需要更新。

static bool canUpdate(Widget oldWidget, Widget newWidget) {

  return oldWidget.runtimeType == newWidget.runtimeType

      && oldWidget.key == newWidget.key;

}

复制代码

Key的几种子类基本上都是根据需求，对== 操作符做不同的实现。以更好的自定义 canUpdate 的结果。

其中GlobalKey比较特殊。作为全局的唯一秘钥。提供了对应 widget 的 BuildContext 和 widget 的访问方式。并针对 StatefulWidget。还提供了 State 的访问。

以便用户对状态进行全局的更新。比如我们需要在外部使用 BuildContext 进行初始化的时候，可以进行这样调用

4. 小结

通过以上对StatelessWidget和ComponentElement 的分析，可以得出以下的判断。
StatelessWidget 基于 ComponentElement。主要功能就是提供了组合各种widget的能力，并维持了祖孙的build传承。

当然在探索当中也发现了一些技术债务，由于我们已经知道了statelesswidget的使用场景，对于具体的源码细节先按下不表，在此只记录

• 生命周期_lifecycleState 起到什么作用


• _dirty 标记和 markNeedsBuild 的用法和原理是什么


• BuildOwner 的作用是什么

二、探索StatefulWidget的动态刷新机制

StatefulWidget 和 StateflessWidget 有很多共同之处。最主要的原因就是他们创建的元素都是ComponentElement的子类，其提供了widget子孙build传承的能力。

可知StatefulWidget和StateflessWidget一样，也是一个有能力组合各种widget的组件。

1. State生命周期分析

StatefulWidget 定义了createState方法。提供了状态刷新能力。

再次从StatefullElement的build方法入手。直接调用了state.build(this)。代理了state的构建行为。

在performRebuild方法中也进行了state.didChangeDependencies生命周期回调。

在State中，除了生命周期方法外， 最重要的就是build方法了。作用和StatelessWidget的build方法一致。都是提供了组合widget的能力。
initState则给用户提供了初始化state状态的机会。断点调试看看调用栈如何。

调试中直观看到，在firstBuld的时候，state的initState被调用。并在之后调用了didChangeDependencies生命周期方法，和build方法。

代码中也对方法做了限制，不可以返回Future类型。
所以我们可以在initState中放心做一些初始化工作，没有异步参与，工作将会在build之前完成。

2. setState方法刷新页面方式分析

对于setState方法。除开生命周期的判断之外，关键代码只有一句，就是调用了element 的markNeedsBuild()

该方法将对应的element标记为dirty。并且调用owner``!.scheduleBuildFor(``this``);将其加入到 BuildOwner的脏列表(_dirtyElements)中。
将会在下次帧刷新的时候调用BuildOwner.owner.buildScope 重新构建该列表中的元素。

3. 小结

StatelessWidget给使用者提供了一个便捷的布局刷新入口，我们可以利用setState刷新布局。该方法会将对应Element标记为待刷新元素，在下次帧刷新的时候重建布局。状态的改动将会被重建的布局重新获取。

三、探索SingleChildRenderObjectWidget

SingleChildRenderObjectWidget对应的元素类是SingleChildRenderObjectElement。
我们作为开发者，布局过程中SingleChildRenderObjectWidget 的子类使用频率非常频繁，布局的约束，偏移和渲染都是由RenderObjectWidget 实现的，SingleChildRenderObjectWidget继承了RenderObjectWidget的渲染能力，并提供了单子传承的能力。布局的过程中该对象的子类不可或缺，flutter框架中也有不少对应的实现类。

Flutter 框架中实现的SingleChildRenderObjectWidget有以下几种。

1. SizedBox


2. LimitedBox


3. ShaderMask


4. RotatedBox


5. SizedOverflowBox


6. Padding


7. ...

1. 探索SingleChildRenderObjectElement中对于子widget的挂载和更新

SingleChildRenderObjectElement`的`mount` 和 `update`方法都很简单，都是直接调用了`updateChild`方法，传进去的子widget直接是`widget.child

这个方法和ComponentElement基本上一样，都是利用canUpdate的结果进行更新或者是创建子Element。

1. 以Padding为例了解RenderObjectWidget 的布局和绘制实现。

名词解释

RenderObject：渲染对象，flutter对象布局的约束，绘制，位移全是由该对象实现，RenderObject树的祖孙中传递着约束，以做到布局大小的传承影响。

RenderObject的创建

RenderObjectWidget 会在mount挂载的时候，创建RenderObject，直接调用widge.createRenderObject。我们的约束，绘制，位移全是由RenderObject传递和实现的。

RenderPadding的布局实现

以Padding为例。createRenderObject创建了RenderPadding实例，widget的成员原封不动交给了该实例。

约束(BoxConstraint)是Flutter确定布局大小的方案，各种RenderObject对于约束的传递都有自己的实现。

下方是RenderPadding的performLayout代码。红框标记起来的代码中就展示了Padding的约束传承逻辑。
其父布局传给自己约束基础上减去Padding再传递给子RenderObject。

观察performLayout方法可以发现，该方法完成了约束的传递，计算了偏移量Offset，并确定了自己的大小。

确定大小约束之后，就会在paint中绘制自己和子孙。RenderPadding没有自定义绘制，直接使用了父类RenderShiftedBox的实现。RenderShiftedBox 提供了offset偏移。在绘制子renderObject的时候，为其施加绘制偏移量。有些需要计算子布局偏移的widget，如Padding，Align等，都对RenderShiftedBox进行了实现。

可以看到子布局的offset存在他的parentData中。PaddingRender使用的parentData是BoxParentData，内部提供了offset变量以供父布局使用。

/// Parent data used by [RenderBox] and its subclasses.

class BoxParentData extends ParentData {

  /// The offset at which to paint the child in the parent's coordinate system.

  Offset offset = Offset.zero;

  @override

  String toString() => 'offset=$offset';

}

所有的RenderBox都持有BoxParentData对象，用于存储位移信息，在setUpPrentData的时候进行的初始化。红框中的代码展示了这一细节。

到此，就能了解RenderObject是如何被约束BoxConstraint，如何被布局layout，以及如何被绘制paint。

1. RenderObjectElement的传承方式

RenderObjectElement 的父子传承在两个子类中实现，在第1小结中已经提到SingleChildRenderObjectWidget 和ComponentElement十分类似，只是直接把widget.child拿来传承，而不再提供build方法以供子组件组合。

MultiChildRenderObjectElement 也类似，只不过作为多子组件，三棵树分叉的主要因子，维护的是children 列表。

在mount 和 update 的时候，子孙组件会像点了爆竹一样被逐一构建和更新。

1. 小结

每个SingleChildRenderObjectWidget组件都实现了各自的布局和绘制方案，也各自处理了约束并传递下去。

比如ColordBox作为绘制组件，借助了RenderColord，绘制了自身颜色，约束则取得是父约束的最小值。Align作为定位组件，借助了RenderPositionedBox，布局的时候计算了对应的偏移量offset，在绘制子布局的时候使用，约束则在传递的时候转了松约束。

诸如此类，所有组件都利用了对应的RenderObject满足了各自布局和渲染的所有需求。我们自己当然也可以自定义对应的RenderObject实现自己的布局。
MultiChildRenderObjectWidget 和 SingleChildRenderObjectWidget类似，只是维护一个子widget变成了多个子widget。

他的RenderObject基本上都是ContainerRenderObjectMixin和RenderBox的子类，内部维护了头尾两个子节点，并利用存储在parentData中的双相链表维护所有的子RenderObject。

四、谈谈ProxyWidget

最后稍微提一下ProxyWidget。ProxyElement也上ComponentElement的子类。和StatefulWidget 以及StatelessWidget是兄弟关系。也有子孙维系的能力，只不过他的build方法是固定的，返回的就是child。

1. InheritedWidget

我们获取 Theme，MediaQuery数据的时候，都是使用了InheritedWidget

MediaQuery.of(context).size.width;

Theme.of(context).appBarTheme;

通过context 也就是Element实例，获取祖先节点的数据。实现数据共享的效果。
Element中维护了祖先的所有InheritedElement映射，就可以在需要的时候直接通过子孙Element获取。

2. ParentDataWidget

ParentDataWidget提供了子组件向父组件传递渲染信息的能力。
Flexible，Positioned 等组件都是ParentDataWidget 的子类。

需要注意的是：ParentDataWidget只用于渲染信息的传递

在Element.attachRenderObject的时候会调用updateParentData，然后会辗转调用到对应的ParentDataWidget.applyParentData。可以看出只有子组件是RenderObjectWidget子类的时候才会应用对应的ParentDataWidget传递信息。

由此可知，只有在子节点渲染的时候，才会应用RenderObject的数据传递赋值。

子节点的ParentData对象由父布局创建代码如下，创建时机在子节点插入的时候执行。

最后

作为开发者，很多时候完成一个任务只会建立在使用的层面。对于为什么这么使用往往不甚了解。
如果我们能更多的学习他的原理。那么如果在开发中碰到问题，我们能够更加得心应手得去解决。
flutter布局渲染的原理以前总是一层雾蒙在我地眼前。但现在，终于有一片薄雾散去，内部轮廓在我面前变得清晰。
坚持学习，见识真实的世界。

小试

我们最后尝试一下一个简单地布局，分析其三棵树结构。嵌套结构如下。其中builder是StatelessWidget。Column是 MultiChildRenderObjectWidget其他都是SingleChildRenderObjectWidget。

void main() {

  runApp(Builder(builder: (context) {

    return Column(

      mainAxisSize: MainAxisSize.max,

      crossAxisAlignment: CrossAxisAlignment.stretch,

      children: [

        Center(

          child: SizedBox(

            width: 100,

            height: 100,

            child: ColoredBox(color: Colors.blue),

          ),

        ),

        Expanded(

          child: ColoredBox(color: Colors.red),

        ),

      ],

    );

  }));

}

展示出来的样式如下。

分析得出的三棵树如下，源头从RenderView而起，然后构建出RenderObjectToWidgetAdapter，再构建出RootRenderObjectElement。由此从根开始三棵树的循环，直到叶子节点。

RenderObject和Widget并非一一对应，只有RenderObjjectWidget才有，但是RenderObject能自动找出自己的组件RenderObjject 自动插入到其child中，所以也能自动成树。

至此，我们的Widget初步了解完结。

Flutter中如何独立绘制每一个像素点?

前提

前一阵我参照教程：GAMEBOY 仿真器 做了一个game boy模拟器，经过漫长的调试，终于成功的在电脑上运行了起来，但作为一个移动端开发者，我最终还是想要在手机上运行，在经过一番研究后，我卡在了第一个难点：在Flutter中如何单独绘制每一个像素点呢？

Gamyboy的显示器尺寸是160 * 144，素点的格式是RGB，模拟器大概每隔16ms生成一帧画面，当模拟器运行时，我就能源源不断的拿到每一帧的像素数据（这里的像素数据可以看做是一个int32数组，长度为160 * 144），我要做的就是找到一种方法，将每一帧的像素数据绘制到屏幕上。一番搜素后，终于在How do I Render Individual Pixels in Flutter?上找到了答案

绘制像素点

想要直接绘制原始的像素点，需要用到Canvas的一个方法：

/// Draws the given [Image] into the canvas with its top-left corner at the

/// given [Offset]. The image is composited into the canvas using the given [Paint].

void drawImage(Image image, Offset offset, Paint paint)

从方法签名中可以看出，canvas绘制的是一个Image对象，它持有原始的像素数据，所以我们需要先将像素数据转换成Image对象，可以使用decodeImageFromPixels方法

/// Convert an array of pixel values into an [Image] object.

///

/// The `pixels` parameter is the pixel data in the encoding described by

/// `format`.

/// ...

void decodeImageFromPixels(

  Uint8List pixels,

  int width,

  int height,

  PixelFormat format,

  ImageDecoderCallback callback, {

  int? rowBytes,

  int? targetWidth,

  int? targetHeight,

  bool allowUpscaling = true,

})

• pixels是一个一维数组，每一个元素是一个字节


• width和height代表图片的宽和高


• format用来设置像素点的格式，比如：PixelFormat.rgba8888表示一个像素点由四个字节组成，分别表示红，绿，蓝，透明度等信息


• callback为图片解码完成后的回调函数，函数参数为最终生成的Image对象

/// Callback signature for [decodeImageFromList].

typedef ImageDecoderCallback = void Function(Image result);

至此，整个流程已经走通，共分为三步：

1. 生成像素数据


2. 调用decodeImageFromPixels方法将像素数据转换为Image对象


3. 调用Canvas的drawImage方法绘制像素数据

读到这里，有些朋友可能会有疑惑，我从哪里去获取Canvas对象呢? 如何做到实时更新每一帧画面呢？接下来，我将用一个案例将整个流程串起来

演示案例

作为演示，这里用生成的雪花噪点数据来代替模拟器生成的像素数据，完整的案例请看：github.com/hcoderLee/f…

首先我们需要一个不断生成像素数据的类

import 'dart:ui' as ui;



class Emulator {

  /// 每一帧生成的像素所对应的Image对象

  ui.Image? _image;



  ui.Image? get image => _image;



  bool _isRunning = false;

  Timer? _timer;



  /// 用于生成雪花噪点数据

  int xorshift32(int x) {

    x ^= x << 13;

    x ^= x >> 17;

    x ^= x << 5;

    return x;

  }



  int seed = 0xDEADBEEF;

  

  /// 生成原始像素数据，并转换为Image对象

  Future<ui.Image> makeImage() {

    final c = Completer<ui.Image>();

    final pixels = Int32List(lcdWidth * lcdHeight);

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

      seed = pixels[i] = xorshift32(seed);

    }

    void decodeCallback(ui.Image image) {

      c.complete(image);

    }



    // 将像素数据转换为Image对象

    ui.decodeImageFromPixels(

      pixels.buffer.asUint8List(),

      lcdWidth,

      lcdHeight,

      ui.PixelFormat.rgba8888,

      decodeCallback,

    );

    return c.future;

  }



  /// 不断的生成每一帧的画面

  void run() {

    if (_isRunning) {

      return;

    }

    _isRunning = true;



    _timer?.cancel();

    /// 每隔16ms（更新一帧的时间）更新一次画面

    _timer = Timer.periodic(const Duration(milliseconds: 16), (timer) async {

      final newImage = await makeImage();

      _image?.dispose();

      _image = newImage;

    });

  }



  void dispose() {

    _timer?.cancel();

    _timer = null;

    _image?.dispose();

  }

}

当有了Image对象后，需要调用Canvas的drawImage方法来绘制，这里使用CustomPaint组件来获取Canvas对象：

CustomPaint(

    painter: _LCD(

      emulator: _emulator,

      timer: _timer,

    ),

);



class _LCD extends CustomPainter {

  final Emulator emulator;



  _LCD({

    required this.emulator,

    required _Timer timer,

  }) : super(repaint: timer);



  @override

  void paint(ui.Canvas canvas, ui.Size size) {

    final image = emulator.image;

    if (image != null) {

      canvas.drawImage(image, Offset.zero, Paint());

    }

  }



  @override

  bool shouldRepaint(covariant CustomPainter oldDelegate) {

    return true;

  }

}

CustomPaint组件有一个重要的参数: painter, 它是一个CustomPainter对象，我们可以自定义一个类去继承CustomPainter, 实现paint方法，获取到Canvas对象，至此，我们可以利用canvas去绘制任何我们想要的东西

这里我们定义了_LCD去继承CustomPainter，它持有Emulator对象，从而获取要绘制的Image对象，这里有两个地方需要重点关注一下：

1. 
   

   shouldRepaint方法表示如果上层组件发生重建，生成了新的CustomPaint对象，是否需要重新调用paint方法绘制内容，因为我的需求是每一帧都要绘制新的画面，所以这里直接返回true（表示需要重新调用paint方法），真实的业务场景需要根据具体情况去判断是否返回true

   
   


2. 
   

   构造函数中有一个_Timer对象，并调用了super(repaint: timer)，那么这个_Timer对象是用来做什么的呢？

   
   

查看CustomPainter的文档，有这么一段说明：

/// The painter will repaint whenever `repaint` notifies its listeners.

repaint会通知CustomPainter去重新绘制画面，我们再查看repaint的类型是Listenable，这里我们自定义一个_Timer类，用来在每一帧更新的时候去通知CustomPainter重绘

class _Timer extends ChangeNotifier {

  final TickerProvider _vsync;

  late final Ticker _ticker;



  _Timer(this._vsync) {

    _ticker = _vsync.createTicker(_onTick);

    _ticker.start();

  }



  void _onTick(Duration elapsed) {

    notifyListeners();

  }



  @override

  void dispose() {

    _ticker.stop();

    _ticker.dispose();

    super.dispose();

  }

}

这里我们继承了ChangeNotifier，因此间接继承了Listenable
在构造函数里创建了一个Ticker对象，用来获取每一帧更新的时机，_onTick方法会在每一帧更新的时候调用，并通知CustomPaint去重绘。实际上，Flutter的动画也是使用Ticker对象，在每一帧更新的时候触发组件重绘
为了创建Ticker对象，需要用到TickerProvider对象，它提供了创建Ticker对象的方法（createTicker），并确保onTick回调函数只在组件处在前台活跃状态的时候才触发。为了获得TickerProvider对象，最常用的做法是创建一个StatefullWidget，并给State添加SingleTickerProviderStateMixin mixin，如果大家写过动画相关的代码，对这一套应该不陌生：

class _GameView extends StatefulWidget {

  const _GameView({Key? key}) : super(key: key);



  @override

  State<_GameView> createState() => _GameViewState();

}



class _GameViewState extends State<_GameView>

    with SingleTickerProviderStateMixin {

  late final Emulator _emulator;

  /// 在每一帧更新的时候去通知_LCD重绘

  late final _Timer _timer;



  @override

  void initState() {

    super.initState();

    _emulator = Emulator();

    // 运行模拟器，不断的产生每一帧的像素数据

    _emulator.run();

    _timer = _Timer(this);

  }



  @override

  Widget build(BuildContext context) {

    return SizedBox(

      width: lcdWidth.toDouble(),

      height: lcdHeight.toDouble(),

      child: CustomPaint(

        painter: _LCD(

          emulator: _emulator,

          timer: _timer,

        ),

      ),

    );

  }



  @override

  void dispose() {

    _emulator.dispose();

    _timer.dispose();

    super.dispose();

  }

}

至此，我们已经完成了所有的步骤，看一下运行效果：

总结

本文讲述了Flutter中如何实时绘制自己生成的像素数据，有以下几个步骤：

1. 生成像素数据


2. 调用decodeImageFromPixels方法将像素数据转换为Image对象


3. 调用Canvas的drawImage方法绘制像素数据


4. 使用Ticker对象获取每一帧更新的时机，并通知CustomPainter去重绘

如果有错误，还请大家帮忙指正, 希望能够对大家有所帮助

一、我讲

今天，我主要讲一下android里面的服务Service，以及它的使用方法。

1.1 服务 Service

Service其实是Android的四大组件之一。

安卓有四大组件，前面我们说的Activity和BroadCastReceiver,其实都属于四大组件。你看，我没有一上来就讲让你先记住四大组件，而是慢慢渗透，因为没有例子的应用，记那些没有意义。

在Android中，能看到的属于Activity，看不到的属于Service。

Service的运行不依赖于任何用户界面，即使程序被切换到后台，或者用户打开了另一个应用程序，Service仍然能够保持正常运行。

1.2 Service的使用

创建

可选中包名，右键点击菜单，输入你的服务的名称进行创建。

其实，你这步操作，影响了两处代码。

第一，新建了一个继承Service的类。

public class MyService extends Service {



    @Override

    public void onCreate() {

        super.onCreate();

    }



    @Override

    public int onStartCommand(final Intent intent, int flags, int startId) {

        // 巴拉巴拉

        return super.onStartCommand(intent, flags, startId);

    }



    @Override

    public void onDestroy() {

        super.onDestroy();

    }

}

当服务每次启动时，都会执行onStartCommand方法，所以我们终点会把逻辑写到这里面。

第二，在AndroidManifest.xml中做了注册。

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

<manifest>

    <application>

        ……

        <service

            android:name=".MyService"

            android:enabled="true"

            android:exported="true"></service>

        

    </application>

</manifest>

启动和停止

服务的启动和停止，一般通过Intent在Activity中进行。

Intent intent = new Intent(this, MyService.class);

startService(intent);

stopService(intent);

通过Intent构建要提供哪一个服务，然后调用startService启动服务，stopService停止服务。

二、你做

我们要搞一个这样的功能：

启动服务后，在服务里面循环播放古诗，退出程序也不打断，看其他应用也不打断。这样，能播放一整天，你看抖音时也弹。这导致你，无奈地就学会了一首诗。

虽然，我们说服务没有界面，但是启动它要界面，我们写在MainActivity中，它的布局是activity_main.xml,就两个按钮，一个启动，一个关闭。

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

<ConstraintLayout tools:context=".MainActivity">

    <Button

        android:id="@+id/button1"

        android:layout_width="match_parent"

        android:layout_height="wrap_content"

        android:text="启动服务"

        android:onClick="start" />

    <Button

        android:id="@+id/button2"

        android:layout_width="match_parent"

        android:layout_height="wrap_content"

        android:text="关闭服务"

        android:onClick="stop" />

</ConstraintLayout>

又看到了熟悉的onClick=""这个我们之前讲过。

对应下面的逻辑控制代码，里面有服务的启动和停止。

public class MainActivity extends Activity {



    Intent intent;

    @Override

    protected void onCreate(Bundle savedInstanceState) {

        super.onCreate(savedInstanceState);

        setContentView(R.layout.activity_main);

        intent = new Intent(this, MyService.class);

    }





    public void start(View view) {

        startService(intent);

    }



    public void stop(View view) {

        stopService(intent);

    }

}

最后，也是重点，就是我们的服务实现逻辑。

先定义一个字符串数组texts用于存储每一句诗词。

然后在onStartCommand里，启动一个线程。

线程里有一个循环，每休眠3秒钟，就往外发送一条消息。

这条消息由Handler发送和接收，接收到后切换诗句，然后通过Toast弹出来。

public class MyService extends Service {



    String[] texts = new String[]{"窗前明月光","疑是地上霜","举头望明月","低头思故乡"};

    int index = 0;

    boolean isRun = true;

    

    ……

    

    @Override

    public int onStartCommand(final Intent intent, int flags, int startId) {



        new Thread(){

        

            @Override

            public void run() {

                while (isRun){

                    if (index+1 > texts.length){

                        index = 0;

                    }

                    handler.sendEmptyMessage(index);

                    sleep(3000);

                    index++;

                }

            }

        }.start();

        

        return super.onStartCommand(intent, flags, startId);

    }



    Handler handler = new Handler(){

        @Override

        public void handleMessage(Message msg) {

            super.handleMessage(msg);

            Toast.makeText(MyService.this, ""+texts[msg.what], Toast.LENGTH_SHORT).show();

        }

    };



    @Override

    public void onDestroy() {

        super.onDestroy();

        isRun = false;

    }

}

需要注意，isRun是控制是否还循环，如果为false了，while循环就不执行了，线程结束。

另外，Service也是有生命周期的，这个生命周期和Activity的生命周期类似，当 onDestroy() 销毁时，需要做一些收尾工作。

好了，最后点击运行，启动服务，去看看效果吧。

最近，使用compose编写了一个类QQ的image picker。完成android library的编写，在此记录下发布这个Library到maven central的流程以及碰到的问题。

maven：mvnrepository.com/artifact/io…

github：github.com/huhx/compos…

Sonatype 账号

MavenCentral 和 Sonatype 的关系

因此我们要发布Library到Maven Central的话，首先需要Sonatype的账号以及权限。

申请 Sonatype 账号

申请账号地址： issues.sonatype.org/secure/Sign…

登录账号创建issue

创建issue地址：issues.sonatype.org/secure/View…

点击 Create 按钮, 然后会弹出 Create Issue的窗口：

点击Configure Fields, 选择 Custom 选项

grouId的话最好使用: io.github.github_name, 要不然使用其他的还需要在 DNS 配置中配置一个TXT记录来验证域名所有权

填写完所有的信息点击创建，一个新的issue就创建成功了，以下就是我创建的issue，附上链接：issues.sonatype.org/browse/OSSR…

值得注意的是sonatype要求我们创建一个github仓库来验证我们的github账号。创建完仓库之后，我们回复热心的工作人员，接下来就是等他们的处理结果了。大概30分钟就能好吧

收到这样的回复，代表一切ready了你可以上传package到maven central。

编写gradle脚本上传Lib

这篇文章里面，我是使用的android library做例子的。如果你想要发布java的Library，可以参考：docs.gradle.org/current/use…

In module project, build.gradle file

// add maven-publish and signing gradle plugin

plugins {

    id 'maven-publish'

    id 'signing'

}



// add publish script

publishing {

    publications {

        release(MavenPublication) {

            pom {

                name = 'Image Picker Compose'

                description = 'An Image Picker Library for Jetpack Compose'

                url = 'https://github.com/huhx/compose_image_picker'



                licenses {

                    license {

                        name = 'The Apache License, Version 2.0'

                        url = 'http://www.apache.org/licenses/LICENSE-2.0.txt'

                    }

                }



                developers {

                    developer {

                        id = 'huhx'

                        name = 'hongxiang'

                        email = 'gohuhx@gmail.com'

                    }

                }



                scm {

                    connection = 'https://github.com/huhx/compose_image_picker.git'

                    developerConnection = 'https://github.com/huhx/compose_image_picker.git'

                    url = 'https://github.com/huhx/compose_image_picker'

                }

            }



            groupId "io.github.huhx"

            artifactId "compose-image-picker"

            version "1.0.2"



            afterEvaluate {

                from components.release

            }

        }

    }

    repositories {

        maven {

            url "https://s01.oss.sonatype.org/service/local/staging/deploy/maven2/"

            credentials {

                username ossrhUsername // ossrhUsername is your sonatype username

                password ossrhPassword // ossrhUsername is your sonatype password

            }

        }

    }

}



// signing, this need key, secret, we put it into gradle.properties

signing {

    sign publishing.publications.release

}

ossrhUsername 和 ossrhPassword 是我们在第一步注册的sonatype账号。用户名和密码是敏感信息，我们放在gradle.properties并且不会提交到github。因此在 gradle.properties文件中，我们添加了以下内容：

# signing information

signing.keyId=key

signing.password=password

signing.secretKeyRingFile=file path



# sonatype account

ossrhUsername=username

ossrhPassword=password

其中包含了签名的三个重要信息，这个我们会在下面详细讲解

创建gpg密钥

我使用的是mac，这里就拿mac来说明如何创建gpg密钥。以下是shell脚本

# 安佳 gpg

> brew install gpg



# 创建gpg key，过程中会提示你输入密码。

# 记住这里要输入的密码就是上述提到你需要配置的signing.password

> gpg --full-gen-key



# 切换目录到~/.gnupg/openpgp-revocs.d, 你会发现有一个 .rev文件。

# 这个文件名称的末尾8位字符就是上述提到你需要配置的signing.keyId

> cd ~/.gnupg/openpgp-revocs.d && ls



# 创建secretKeyRingFile, 以下命令会创建一个文件secret.gpg

# 然后~/.gnupg/secret.gpg就是上述提到你需要配置的signing.secretKeyRingFile

> cd ~/.gnupg/ && gpg --export-secret-keys -o secret.gpg

把signing相关的信息成功填写到gradle.properties之后，我们就可以借助maven-publish插件发布我们的andoird包到maven的中心仓库了

maven publish的gradle task

# 这个是发布到我们的本地，你可以在~/.m2/repository/的目录找到你发布的包

> ./gradlew clean publishToMavenLocal



# 这个是发布到maven的中心仓库，你可以在https://s01.oss.sonatype.org/#stagingRepositories找到

> ./gradlew clean publish

我们执行./gradlew clean publish命令之后，访问地址：s01.oss.sonatype.org/#stagingRep…

可以看到我们的android包已经在nexus repository了，接下来你要做的两步就是Close and Release。

Maven检验以及发布

第一步：点击Close按钮，它会触发对发布包的检验。我在这个过程中碰到一个signature validation失败的问题。

# 失败原因：No public key in hkp://keyserver.ubuntu.com:11371，是因为同步key可能会花些时间。这里我们可以手动发布我们的key到相应的服务器上

> gpg --keyserver hkp://keyserver.ubuntu.com:11371 --send-keys signing.keyId

第二步：确保你填入的信息是满足要求之后，Release按钮就会被激活。点击Release，接下来就是等待时间了，不出意外的话。30分钟你可以在nexus repository manager找到，但是在mvnrepository.com/找到的话得花更长的时间。

背景

Android系统模块代码的编译实在是太耗时了，即使寥寥几行代码的修改，也能让一台具有足够性能的编译服务器工作十几分钟以上（模块单编），只为编出一些几兆大小的jar和dex。

这里探究的是系统完成过一次整编后进行的模块单编，即m、mm、mmm等命令。

除此之外，一些不会更新源码、编译配置等文件的内容的操作，如touch、git操作等，会被Android系统编译工具识别为有差异，从而在编译时重新生成编译配置，重新编译并没有更新的源码、重新生成没有差异的中间文件等一系列严重耗时操作。

本文介绍关于编译过程中的几个阶段，以及这些阶段的耗时点/耗时原因，并最后给出一个覆盖一定应用场景的基于ninja的加快编译的方法（实际上是裁剪掉冗余的编译工作）。

环境

编译服务器硬件及Android信息：

• Ubuntu 18.04.4 LTS
• Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz (28核56超线程)
• MemTotal: 65856428 kB (62.8GiB)
• AOSP Android 10.0
• 仅修改某个Java文件内部的boolean初始化值（true改false）
• 不修改其他任何内容，包括源码、mk、bp的情况下，使用m单编模块（在清理后，使用对比的ninja进行单编）
• 使用time计时
• 此前整个系统已经整编过一次
• 编译时不修改任何编译配置文件如Android.mk

之所以做一个代码修改量微乎其微的case，是因为要分析编译性能瓶颈，代码变更量越小的情况下，瓶颈就越明显，越有利于分析。

关键编译阶段和耗时分析

由于Makefile结构复杂、不易调试、难以扩展，因此Android决定将它替换掉。Android在7.0时引入了Soong，它将Android从Makefile的编译架构带入到了ninja的时代。

Soong包含两大模块，其中Kati负责解析Makefile并转换为.ninja，第二个模块Ninja则基于生成的.ninja完成编译。

Kati是对GNU Make的clone，并将编译后端实现切换到ninja。Kati本身不进行编译，仅生成.ninja文件提供给Ninja进行编译。

Makefile/Android.mk -> Kati -> Ninja

Android.bp -> Blueprint -> Soong -> Ninja

因此在执行编译之前（即Ninja真正开动时），还有一些生成.ninja的步骤。关键编译阶段如下：

1. Soong的自举（Bootstrap），将Soong本身编译出来
   1. 系统代码首次编译会比较耗时，其中一个原因是Soong要全新编译它自己
2. 遍历源码树，收集所有编译配置文件（Makefile/Android.mk/Android.bp)
   1. 遍历、验证非常耗时，多么强劲配置的机器都将受限于单线程效率和磁盘IO效率
   2. 由于Android系统各模块之间的依赖、引入，因此即使是单编模块，Soong（Kati）也不得不确认目标模块以外的路径是否需要重新跟随编译。
3. 验证编译配置文件的合法性、有效性、时效性、是否应该加入编译，生成.ninja
   1. 如果没有任何更改，.ninja不需要重新生成
   2. 最终生成的.ninja文件很大（In my case，1GB以上），有很明显的IO性能效率问题，显然在查询效率方面也很低下
4. 最后一步，真正执行编译，调用ninja进入多线程编译
   1. 由于Android加入了大量的代码编译期工作，如API权限控制检查、API列表生成等工作（比如，生成系统API保护名单、插桩工作等等），因此编译过程实际上不是完全投入到编译中
   2. 编译过程穿插“泛打包工作”，如生成odex、art、res资源打包。虽然不同的“泛打包”可以多线程并行进行，但是每个打包本身只能单线程进行

下面将基于模块单编（因开发环境系统全新编译场景频率较低，不予考虑），对这四个关键阶段进行性能分析。

阶段一：Soong bootstrap

在系统已经整编过一次的情况下，Soong已经完成了编译，因此其预热过程占整个编译时间的比例会比较小。

在“环境”下，修改一行Framework代码触发差异进行编译。并且使用下面的命令进行编译。

time m services framework -j57

编译实际耗时22m37s：

 build completed successfully (22:37 (mm:ss)) ####

real    22m37.504s

user    110m25.656s

sys     12m28.056s

对应的分阶段耗时如下图。

• 可以看到，包括Soong bootstrap流程在内的预热耗时占比非常低，耗时约为11.6s，总耗时约为1357s，预热耗时占比为0.8%。

• Kati和ninja，也就是上述编译关键流程的第2步和第3步，分别占了接近60%（820秒，13分钟半）和约35%（521秒，8分钟半）的耗时，合计占比接近95%的耗时。

注：这个耗时是仅小幅度修改Java代码后测试的耗时。如果修改编译配置文件如Android.mk，会有更大的耗时。

小结：看来在完成一次整编后的模块单编，包括Soong bootstrap、执行编译准备脚本、vendorsetup脚本的耗时占比很低，可以完全排除存在性能瓶颈的可能。

阶段二：Kati遍历、mk搜集与ninja生成

从上图可以看到，Kati耗时占比很大，它的任务是遍历源码树，收集所有的编译配置文件，经过验证和筛选后，将它们解析并转化为.ninja。

从性能角度来看，它的主要特点如下：

1. 它要遍历源码树，收集所有mk文件（In my case，有983个mk文件）
2. 解析mk文件（In my case，framework/base/Android.mk耗费了~6800ms）
3. 生成并写入对应的.ninja
4. 单线程

直观展示如下，它是一个单线程的、IO速度敏感、CPU不敏感的过程：

Kati串行地处理文件，此时对CPU利用率很低，对IO的压力也不高。

小结：可以确定它的性能瓶颈来源于IO速度，单纯为编译实例分配更多的CPU资源也无益于提升Kati的速度。

阶段三：Ninja编译

SoongClone了一份GNU Make，并将其改造为Kati。即使我们没有修改任何mk文件，前面Kati仍然会花费数分钟到数十分钟的工作耗时，只为了生成一份能够被Ninja或.ninja的生成工具能够识别的文件。接下来是调用Ninja真正开始编译工作。

从性能角度来看，它的主要特点如下：

1. 根据目标target及依赖，读取前面生成的.ninja配置，进行编译
2. 比较独立，不与前面的组件，如blueprint、kati等耦合，只要.ninja文件中能找到target和build rule就能完成编译
3. 多线程

直观展示如下，Ninja将会根据传入的并行任务数参数启动对应数量的线程进行编译。Ninja编译阶段会真正的启动多线程。但做不到一直多线程编译，因为部分阶段如部分编译目标（比如生成一个API文档）、泛打包阶段等本身无法多线程并行执行。

可以看到此时CPU利用率应该是可以明显上升的。但是耗时较大的阶段仅启用了几个线程，后面的阶段和最后的图形很细（时间占比很小）的阶段才用起来更多的线程。

其中，一些阶段（图中时间占比较长的几条记录）没能跑满资源的原因是这些编译目标本身不支持并行，且本次编译命令指定的目标已经全部“安排”了，不需要调动更多资源启动其他编译目标的工作。当编译整个系统时就能够跑满了。

最后一个阶段（图中最后的几列很细的记录）虽然跑满了所有线程资源，但是运行时间很短。这是因为本case进行编译分析的过程中，仅修改了一行代码来触发编译。因编译工作量很小，所以这几列很细。

小结：我们看到，Ninja编译启动比较快，这表明Ninja对.ninja文件的读取解析并不敏感。整个过程也没有看到显著的耗时点。且最后面编译量很小，表明Ninja能够确保增量编译、未更新不编译。

编译优化

本节完成点题——Android系统编译优化：使用Ninja加快编译。

根据前面分析的小结，可以总结性能瓶颈:

1. Kati遍历、生成太慢，受限于IO速率
2. Kati吞吐量太低，单线程
3. 不论有无更新均重新解析Makefile

利用Ninja进行编译优化的思路是，大多数场景，可以舍弃Kati的工作，仅执行Ninja的工作，以节省掉60%以上的时间。其核心思路，也是制约条件，即在不影响编译正确性的前提下，舍弃不必要的Kati编译工作。

• 使用Ninja直接基于.ninja文件进行编译来改善耗时：

结合前面的分析，容易想到，如果目标被构建前，能够确保mk文件没有更新也不需要重新生成一长串的最终编译目标（即.ninja），那么make命令带来的Soong bootstrap、Kati等工作完全是重复的冗余的——这个性质Soong和Kati自己识别不出来，它们会重复工作一次。

既重新生成.ninja是冗余的，那么直接命令编译系统根据指定的.ninja进行编译显然会节省大量的工作耗时。ninja命令is the key:

使用源码中自带的ninja:

./prebuilts/build-tools/linux-x86/bin/ninja --version

1.8.2.git

对比最上面列出的make命令的编译，这里用ninja编译同样的目标：

 time ./prebuilts/build-tools/linux-x86/bin/ninja -j 57 -v -f out/combined-full_xxxxxx.ninja services framework

ninja自己识别出来CPU平台后，默认使用-j58。这里为了对比上面的m命令，使用-j57编译

-f参数指定.ninja文件。它是编译配置文件，在Android中由Kati生成。这里文件名用'x'替换修改

编译结果，对比上面的m，有三倍的提升：

real    7m57.835s

user    97m12.564s

sys     8m31.756s

编译耗时为8分半，仅make的三分之一。As we can see，当能够确保编译配置没有更新，变更仅存在于源码范围时，使用Ninja直接编译，跳过Kati可以取得很显著的提升。

直接使用ninja:

./prebuilts/build-tools/linux-x86/bin/ninja -j $MAKE_JOBS -v -f out/combined-*.ninja <targets...>

对比汇总

这里找了一个其他项目的编译Demo，该Demo的特点是本身代码较简单，编译配置也较简单，整体编译工作较少，通过make编译的大部分耗时来自soong、make等工具自身的消耗，而真正执行编译的ninja耗时占比极其低。由于ninja本身跳过了soong，因此可以跳过这一无用的繁琐的耗时。可以看到下面，ninja编译iperf仅花费10秒。这个时间如果给soong来编译，预热都不够。

$ -> f_ninja_msf iperf

Run ninja with out/combined-full_xxxxxx.ninja to build iperf.

====== ====== ======

Ninja: ./prebuilts/build-tools/linux-x86/bin/ninja@1.8.2.git

Ninja: build with out/combined-full_xxxxxx.ninja

Ninja: build targets iperf

Ninja: j72

====== ====== ======

time /usr/bin/time ./prebuilts/build-tools/linux-x86/bin/ninja -j 72 -f out/combined-full_xxxxxx.ninja iperf



[24/24] Install: out/target/product/xxxxxx/system/bin/iperf

53.62user 11.09system 0:10.17elapsed 636%CPU (0avgtext+0avgdata 5696772maxresident)

4793472inputs+5992outputs (4713major+897026minor)pagefaults 0swaps



real    0m10.174s

user    0m53.624s

sys     0m11.096s

下面给出soong编译的恐怖耗时：

$ -> rm out/target/product/xxxxxx/system/bin/iperf

$ -> time m iperf -j72



...



[100% 993/993] Install: out/target/product/xxxxxx/system/bin/iperf



#### build completed successfully (14:45 (mm:ss)) ####





real    14m45.164s

user    23m40.616s

sys     11m46.248s

As we can see，m和ninja一个是10+ minutes，一个是10+ seconds，比例是88.5倍。

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

@kotlin.internal.InlineOnly

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

    contract {

        callsInPlace(block, InvocationKind.EXACTLY_ONCE)

    }

    return receiver.block()

}



@kotlin.internal.InlineOnly

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

    contract { callsInPlace(action) }



    for (index in 0 until times) {

        action(index)

    }

}

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

函数协议

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

@ContractsDsl

@ExperimentalContracts

@InlineOnly

@SinceKotlin("1.3")

@Suppress("UNUSED_PARAMETER")

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

用法上，它有两点要求：

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

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

ContractBuilder

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

@ContractsDsl

@ExperimentalContracts

@SinceKotlin("1.3")

public interface ContractBuilder {

    @ContractsDsl public fun returns(): Returns

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

    @ContractsDsl public fun returnsNotNull(): ReturnsNotNull

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

}

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

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

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

InvocationKind

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

@ContractsDsl

@ExperimentalContracts

@SinceKotlin("1.3")

public enum class InvocationKind {

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

    @ContractsDsl AT_MOST_ONCE,

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

    @ContractsDsl AT_LEAST_ONCE,

    // 函数参数执行一次

    @ContractsDsl EXACTLY_ONCE,

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

    @ContractsDsl UNKNOWN

}

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

Effect

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

public interface Effect



public interface ConditionalEffect : Effect



public interface SimpleEffect : Effect {

    public infix fun implies(booleanExpression: Boolean): ConditionalEffect

}



public interface Returns : SimpleEffect



public interface ReturnsNotNull : SimpleEffect



public interface CallsInPlace : Effect

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

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

    contract {

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

    }



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

}

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

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

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

协议的意义

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

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

// 类比于ContractBuilder

interface Bonjour {



    // 协议方法

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

        println("parler something")

    }

}





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

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





// 模仿let

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

    println("test before")

    bonjour {

        println("test in bonjour")

        parler<String> {

            ""

        }

    }

    println("test after")

    return block(this)

}



fun main(args: Array<String>) {

    "abc".letForTest {

        println("main: $it called")

    }

}

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

test before

test after

main: abc called

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

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

fun getString(): String? {

    TODO()

}



fun String?.isAvailable(): Boolean {

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

}

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

val target = getString()

if (target.isAvailable()) {

    val result: String = target

}

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

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

Type mismatch.

    Required:

        String

    Found:

        String?

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

fun String?.isAvailable(): Boolean {

    contract {

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

    }

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

}

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

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

小结

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

之前一些列的文章重点在于分析协程本质原理，了解了协程的内核再来看其它衍生的知识就比较容易了。

接下来这边文章着重分析协程框架提供的一些重要的函数原理，通过本篇文章，你将了解到：

1. runBlocking 使用与原理


2. launch 使用与原理


3. join 使用与原理


4. async/await 使用与原理


5. delay 使用与原理

1. runBlocking 使用与原理

默认分发器的runBlocking

使用

老规矩，先上Demo：

    fun testBlock() {

        println("before runBlocking thread:${Thread.currentThread()}")

        //①

        runBlocking {

            println("I'm runBlocking start thread:${Thread.currentThread()}")

            Thread.sleep(2000)

            println("I'm runBlocking end")

        }

        //②

        println("after runBlocking:${Thread.currentThread()}")

    }

runBlocking 开启了一个新的协程，它的特点是：

协程执行结束后才会执行runBlocking 后的代码。

也就是① 执行结束后 ② 才会执行。

可以看出，协程运行在当前线程，因此若是在协程里执行了耗时函数，那么协程之后的代码只能等待，基于这个特性，runBlocking 经常用于一些测试的场景。

runBlocking 可以定义返回值，比如返回一个字符串：

    fun testBlock2() {

        var name = runBlocking {

            "fish"

        }

        println("name $name")

    }

原理

    #Builders.kt

    public fun <T> runBlocking(context: CoroutineContext = EmptyCoroutineContext, block: suspend CoroutineScope.() -> T): T {

        //当前线程

        val currentThread = Thread.currentThread()

        //先看有没有拦截器

        val contextInterceptor = context[ContinuationInterceptor]

        val eventLoop: EventLoop?

        val newContext: CoroutineContext

        //----------①

        if (contextInterceptor == null) {

            //不特别指定的话没有拦截器，使用loop构建Context

            eventLoop = ThreadLocalEventLoop.eventLoop

            newContext = GlobalScope.newCoroutineContext(context + eventLoop)

        } else {

            eventLoop = (contextInterceptor as? EventLoop)?.takeIf { it.shouldBeProcessedFromContext() }

                ?: ThreadLocalEventLoop.currentOrNull()

            newContext = GlobalScope.newCoroutineContext(context)

        }

        //BlockingCoroutine 顾名思义，阻塞的协程

        val coroutine = BlockingCoroutine<T>(newContext, currentThread, eventLoop)

        //开启

        coroutine.start(CoroutineStart.DEFAULT, coroutine, block)

        //等待协程执行完成----------②

        return coroutine.joinBlocking()

    }

重点看①②。

先说①，因为我们没有指定分发器，因此会使用loop，实际创建的是BlockingEventLoop，它继承自EventLoopImplBase，最终继承自CoroutineDispatcher（注意此处是个重点）。

根据我们之前分析的协程知识可知，协程启动后会构造DispatchedContinuation，然后依靠dispatcher将runnable 分发执行，而这个dispatcher 即是BlockingEventLoop。

    #EventLoop.common.kt

    //重写dispatch函数

    public final override fun dispatch(context: CoroutineContext, block: Runnable) = enqueue(block)



    public fun enqueue(task: Runnable) {

        //将task 加入队列，task = DispatchedContinuation

        if (enqueueImpl(task)) {

            unpark()

        } else {

            DefaultExecutor.enqueue(task)

        }

    }

BlockingEventLoop 的父类EventLoopImplBase 里有个成员变量：_queue，它是个队列，用来存储提交的任务。

再看②：

协程任务已经提交到队列里，就看啥时候取出来执行了。

#Builders.kt

    fun joinBlocking(): T {

        try {

            try {

                while (true) {

                    //当前线程已经中断了，直接退出

                    if (Thread.interrupted()) throw InterruptedException().also { cancelCoroutine(it) }

                    //如果eventLoop！= null，则从队列里取出task并执行

                    val parkNanos = eventLoop?.processNextEvent() ?: Long.MAX_VALUE

                    //协程执行结束，跳出循环

                    if (isCompleted) break

                    //挂起线程，parkNanos 指的是挂起时间

                    parkNanos(this, parkNanos)

                    //当线程被唤醒后，继续while循环

                }

            } finally { // paranoia

            }

        }

        //返回结果

        return state as T

    }



#EventLoop.common.kt

    override fun processNextEvent(): Long {

        //延迟队列

        val delayed = _delayed.value

        //延迟队列处理，这里在分析delay时再解释

        //从队列里取出task

        val task = dequeue()

        if (task != null) {

            //执行task

            task.run()

            return 0

        }

        return nextTime

    }

上面代码的任务有两个：

1. 尝试从队列里取出Task。


2. 若是没有则挂起线程。

结合①②两点，再来过一下场景：

1. 先创建协程，包装为DispatchedContinuation，作为task。


2. 分发task，将task加入到队列里。


3. 从队列里取出task执行，实际执行的即是协程体。


4. 当3执行完毕后，runBlocking()函数也就退出了。

其中虚线箭头表示执行先后顺序。

由此可见，runBlocking()函数需要等待协程执行完毕后才退出。

指定分发器的runBlocking

上个Demo在使用runBlocking 时没有指定其分发器，若是指定了又是怎么样的流程呢？

    fun testBlock3() {

        println("before runBlocking thread:${Thread.currentThread()}")

        //①

        runBlocking(Dispatchers.IO) {

            println("I'm runBlocking start thread:${Thread.currentThread()}")

            Thread.sleep(2000)

            println("I'm runBlocking end")

        }

        //②

        println("after runBlocking:${Thread.currentThread()}")

    }

指定在子线程里进行分发。

此处与默认分发器最大的差别在于：

默认分发器加入队列、取出队列都是同一个线程，而指定分发器后task不会加入到队列里，task的调度执行完全由指定的分发器完成。

也就是说，coroutine.joinBlocking()后，当前线程一定会被挂起。等到协程执行完毕后再唤醒当前被挂起的线程。

唤醒之处在于：

#Builders.kt

    override fun afterCompletion(state: Any?) {

        // wake up blocked thread

        if (Thread.currentThread() != blockedThread)

            //blockedThread 即为调用coroutine.joinBlocking()后阻塞的线程

            //Thread.currentThread() 为线程池的线程

            //唤醒线程

            unpark(blockedThread)

    }

不管是否指定分发器，runBlocking() 都会阻塞等待协程执行完毕。

2. launch 使用与原理

想必大家刚接触协程的时候使用最多的还是launch启动协程吧。

看个Demo：

    fun testLaunch() {

        var job = GlobalScope.launch {

            println("hello job1 start")//①

            Thread.sleep(2000)

            println("hello job1 end")//②

        }

        println("continue...")//③

    }

非常简单，启动一个线程，打印结果如下：

③一定比①②先打印，同时也说明launch()函数并不阻塞当前线程。

关于协程原理，在之前的文章都有深入分析，此处不再赘述，以图示之：

3. join 使用与原理

虽然launch()函数不阻塞线程，但是我们就想要知道协程执行完毕没，进而根据结果确定是否继续往下执行，这时候该Job.join()出场了。

先看该函数的定义：

#Job.kt

public suspend fun join()

是个suspend 修饰的函数，suspend 是咱们的老朋友了，说明协程执行到该函数会挂起(当前线程不阻塞，另有他用)。

继续看其实现：

    #JobSupport.kt

    public final override suspend fun join() {

        //快速判断状态，不耗时

        if (!joinInternal()) { // fast-path no wait

            coroutineContext.ensureActive()

            return // do not suspend

        }

        //挂起的地方

        return joinSuspend() // slow-path wait

    }



    //suspendCancellableCoroutine 典型的挂起操作

    //cont 是封装后的协程

    private suspend fun joinSuspend() = suspendCancellableCoroutine<Unit> { cont ->

        //执行完这就挂起

        //disposeOnCancellation 是将cont 记录在当前协程的state里，构造为node

        cont.disposeOnCancellation(invokeOnCompletion(handler = ResumeOnCompletion(cont).asHandler))

    }

其中suspendCancellableCoroutine 是挂起的核心所在，关于挂起的详细分析请移步：讲真，Kotlin 协程的挂起没那么神秘(原理篇)

joinSuspend()函数有2个作用：

1. 将当前协程体存储到Job的state里（作为node)。


2. 将当前协程挂起。

什么时候恢复呢？当然是协程执行完成后。

#JobSupport.kt

private class ResumeOnCompletion(

    private val continuation: Continuation<Unit>

) : JobNode() {

    //continuation 为协程的包装体，它里面有我们真正的协程体

    //之后重新进行分发

    override fun invoke(cause: Throwable?) = continuation.resume(Unit)

}

当协程执行完毕，会例行检查当前的state是否有挂着需要执行的node，刚好我们在joinSuspend()里放了node，于是找到该node，进而找到之前的协程体再次进行分发。根据协程状态机的知识可知，这是第二次执行协程体，因此肯定会执行job.join()之后的代码，于是乎看起来的效果就是：

job.join() 等待协程执行完毕后才会往下执行。

语言比较苍白，来个图：

注：此处省略了协程挂起等相关知识，如果对此有疑惑请阅读之前的文章。

4. async/await 使用与原理

launch 有2点不足之处：协程执行没有返回值。

这点我们从它的定义很容易获悉：

    fun testAsync() {

        runBlocking {

            //启动协程

            var job = GlobalScope.async {

                println("job1 start")

                Thread.sleep(10000)

                //返回值

                "fish"

            }

            //等待协程执行结束，并返回协程结果

            var result = job.await()

            println("result:$result")

        }

    }

运行结果：

接着来看实现原理。

    public fun <T> CoroutineScope.async(

        context: CoroutineContext = EmptyCoroutineContext,

        start: CoroutineStart = CoroutineStart.DEFAULT,

        block: suspend CoroutineScope.() -> T

    ): Deferred<T> {

        val newContext = newCoroutineContext(context)

        //构造DeferredCoroutine

        val coroutine = if (start.isLazy)

            LazyDeferredCoroutine(newContext, block) else

            DeferredCoroutine<T>(newContext, active = true)

        //coroutine == DeferredCoroutine

        coroutine.start(start, coroutine, block)

        return coroutine

    }

与launch 启动方式不同的是，async 的协程定义了返回值，是个泛型。并且async里使用的是DeferredCoroutine，顾名思义：延迟给结果的协程。

后面的流程都是一样的，不再细说。

再来看Job.await()，它与Job.join()类似：

1. 先判断是否需要挂起，若是协程已经结束/被取消，当然就无需等待直接返回。


2. 先将当前协程体包装到state里作为node存放，然后挂起协程。


3. 等待async里的协程执行完毕，再重新调度执行await()之后的代码。


4. 此时协程的值已经返回。

这里需要重点关注一下返回值是怎么传递过来的。

将testAsync()反编译：

    public final Object invokeSuspend(@NotNull Object $result) {

        //result 为协程执行结果

        Object var6 = IntrinsicsKt.getCOROUTINE_SUSPENDED();

        Object var10000;

        switch(this.label) {

            case 0:

                //第一次执行这

                ResultKt.throwOnFailure($result);

                Deferred job = BuildersKt.async$default((CoroutineScope) GlobalScope.INSTANCE, (CoroutineContext)null, (CoroutineStart)null, (Function2)(new Function2((Continuation)null) {

                    int label;

                    @Nullable

                    public final Object invokeSuspend(@NotNull Object var1) {

                        Object var4 = IntrinsicsKt.getCOROUTINE_SUSPENDED();

                        switch(this.label) {

                            case 0:

                                ResultKt.throwOnFailure(var1);

                                String var2 = "job1 start";

                                boolean var3 = false;

                                System.out.println(var2);

                                Thread.sleep(10000L);

                                return "fish";

                            default:

                                throw new IllegalStateException("call to 'resume' before 'invoke' with coroutine");

                        }

                    }

                }), 3, (Object)null);

                this.label = 1;

                //挂起

                var10000 = job.await(this);

                if (var10000 == var6) {

                    return var6;

                }

                break;

            case 1:

                //第二次执行这

                ResultKt.throwOnFailure($result);

                //result 就是demo里的"fish"

                var10000 = $result;

                break;

            default:

                throw new IllegalStateException("call to 'resume' before 'invoke' with coroutine");

        }



        String result = (String)var10000;

        String var4 = "result:" + result;

        boolean var5 = false;

        System.out.println(var4);

        return Unit.INSTANCE;

    }

很明显，外层的协程(runBlocking)体会执行2次。

第1次：调用invokeSuspend(xx)，此时参数xx=Unit，后遇到await 被挂起。

第2次：子协程执行结束并返回结果"fish"，恢复外部协程时再次调用invokeSuspend(xx)，此时参数xx="fish"，并将参数保存下来，因此result 就有了值。

值得注意的是：

async 方式启动的协程，若是协程发生了异常，不会像launch 那样直接抛出，而是需要等待调用await()时抛出。

5. delay 使用与原理

线程可以被阻塞，协程可以被挂起，挂起后的协程等待时机成熟可以被恢复。

    fun testDelay() {

        GlobalScope.launch {

            println("before getName")

            var name = getUserName()

            println("after getName name:$name")

        }

    }

    suspend fun getUserName():String {

        return withContext(Dispatchers.IO) {

            //模拟网络获取

            Thread.sleep(2000)

            "fish"

        }

    }

获取用户名字是在子线程获取的，它是个挂起函数，当协程执行到此时挂起，等待获取名字之后再恢复运行。

有时候我们仅仅只是想要协程挂起一段时间，并不需要去做其它操作，这个时候我们可以选择使用delay(xx)函数：

    fun testDelay2() {

        GlobalScope.launch {

            println("before delay")

            //协程挂起5s

            delay(5000)

            println("after delay")

        }

    }

再来看看其原理。

#Delay.kt

    public suspend fun delay(timeMillis: Long) {

        //没必要延时

        if (timeMillis <= 0) return // don't delay

        return suspendCancellableCoroutine sc@ { cont: CancellableContinuation<Unit> ->

            //封装协程为cont，便于之后恢复

            if (timeMillis < Long.MAX_VALUE) {

                //核心实现

                cont.context.delay.scheduleResumeAfterDelay(timeMillis, cont)

            }

        }

    }

主要看context.delay 实现：

#DefaultExecutor.kt

internal actual val DefaultDelay: Delay = kotlinx.coroutines.DefaultExecutor



//单例

internal actual object DefaultExecutor : EventLoopImplBase(), Runnable {

    const val THREAD_NAME = "kotlinx.coroutines.DefaultExecutor"

    //...

    private fun createThreadSync(): Thread {

        return DefaultExecutor._thread ?: Thread(this, DefaultExecutor.THREAD_NAME).apply {

            DefaultExecutor._thread = this

            isDaemon = true

            start()

        }

    }

    //...

    override fun run() {

        //循环检测队列是否有内容需要处理

        //决定是否要挂起线程

    }

    //...

}

DefaultExecutor 是个单例，它里边开启了线程，并且检测队列里任务的情况来决定是否需要挂起线程等待。

先看队列的出入队情况。

放入队列

我们注意到DefaultExecutor 继承自EventLoopImplBase()，在最开始分析runBlocking()时有提到过它里面有成员变量_queue 存储队列元素，实际上它还有另一个成员变量_delayed：

#EventLoop.common.kt

internal abstract class EventLoopImplBase: EventLoopImplPlatform(), Delay {

    //存放正常task

    private val _queue = atomic<Any?>(null)

    //存放延迟task

    private val _delayed = atomic<EventLoopImplBase.DelayedTaskQueue?>(null)

}



private inner class DelayedResumeTask(

    nanoTime: Long,

    private val cont: CancellableContinuation<Unit>

) : EventLoopImplBase.DelayedTask(nanoTime) {

    //协程恢复

    override fun run() { with(cont) { resumeUndispatched(Unit) } }

    override fun toString(): String = super.toString() + cont.toString()

}

delay.scheduleResumeAfterDelay 本质是创建task：DelayedResumeTask，并将该task加入到延迟队列_delayed里。

从队列取出

DefaultExecutor 一开始就会调用processNextEvent()函数检测队列是否有数据，如果没有则将线程挂起一段时间(由processNextEvent()返回值确定)。

那么重点转移到processNextEvent()上。

##EventLoop.common.kt

    override fun processNextEvent(): Long {

        if (processUnconfinedEvent()) return 0

        val delayed = _delayed.value

        if (delayed != null && !delayed.isEmpty) {

            //调用delay 后会放入

            //查看延迟队列是否有任务

            val now = nanoTime()

            while (true) {

                //一直取任务，直到取不到(时间未到)

                delayed.removeFirstIf {

                    //延迟任务时间是否已经到了

                    if (it.timeToExecute(now)) {

                        //将延迟任务从延迟队列取出，并加入到正常队列里

                        enqueueImpl(it)

                    } else

                        false

                } ?: break // quit loop when nothing more to remove or enqueueImpl returns false on "isComplete"

            }

        }

        // 从正常队列里取出

        val task = dequeue()

        if (task != null) {

            //执行

            task.run()

            return 0

        }

        //返回线程需要挂起的时间

        return nextTime

    }

而执行任务最终就是执行DelayedResumeTask.run()函数，该函数里会对协程进行恢复。

至此，delay 流程就比较清晰了：

1. 构造task 加入到延迟队列里，此时协程挂起。


2. 有个单独的线程会检测是否需要取出task并执行，没到时间的话就要挂起等待。


3. 时间到了从延迟队列里取出并放入正常的队列，并从正常队列里取出执行。


4. task 执行的过程就是协程恢复的过程。

老规矩，上图：

图上虚线紫色框部分表明delay 执行到此就结束了，协程挂起(不阻塞当前线程），剩下的就交给单例的DefaultExecutor 调度，等待延迟的时间结束后通知协程恢复即可。

关于协程一些常用的函数分析到此就结束了，下篇开始我们一起探索协程通信(Channel/Flow 等)相关知识。

由于篇幅原因，省略了一些源码的分析，若你对此有疑惑，可评论或私信小鱼人。

前言

在上一篇普通的加载千篇一律，有趣的 loading 万里挑一 中，我们介绍了使用Path类的PathMetrics属性来控制绘制点在路径上运动来实现比较有趣的loading效果。有评论说因为是黑色背景，所以看着好看。黑色背景确实显得高端一点，但是并不是其他配色也不行，本篇我们来封装一个可以自定义配置前景色和背景色的Loading组件。

组件定义

loading组件共定义4个入口参数：

• 前景色：绘制图形的前景色；
• 背景色：绘制图形的背景色；
• 图形尺寸：绘制图形的尺寸；
• 加载文字：可选，如果有文字就显示，没有就不显示。

得到的Loading组件类如下所示：

class LoadingAnimations extends StatefulWidget {

  final Color bgColor;

  final Color foregroundColor;

  String? loadingText;

  final double size;

  LoadingAnimations(

      {required this.foregroundColor,

      required this.bgColor,

      this.loadingText,

      this.size = 100.0,

      Key? key})

      : super(key: key);



  @override

  _LoadingAnimationsState createState() => _LoadingAnimationsState();

}

圆形Loading

我们先来实现一个圆形的loading，效果如下所示。  这里绘制了两组沿着一个大圆运动的轴对称的实心圆，半径依次减小，圆心间距随着动画时间逐步拉大。实际上实现的核心还是基于Path的PathMetrics。具体实现代码如下：

_drawCircleLoadingAnimaion(

      Canvas canvas, Size size, Offset center, Paint paint) {

  final radius = boxSize / 2;

  final ballCount = 6;

  final ballRadius = boxSize / 15;



  var circlePath = Path()

    ..addOval(Rect.fromCircle(center: center, radius: radius));



  var circleMetrics = circlePath.computeMetrics();

  for (var pathMetric in circleMetrics) {

    for (var i = 0; i < ballCount; ++i) {

      var lengthRatio = animationValue * (1 - i / ballCount);

      var tangent =

          pathMetric.getTangentForOffset(pathMetric.length * lengthRatio);



      var ballPosition = tangent!.position;

      canvas.drawCircle(ballPosition, ballRadius / (1 + i), paint);

      canvas.drawCircle(

          Offset(size.width - tangent.position.dx,

              size.height - tangent.position.dy),

          ballRadius / (1 + i),

          paint);

    }

  }

}

其中路径比例为lengthRatio，通过animationValue乘以一个系数使得实心圆的间距越来越大 ，同时通过Offset(size.width - tangent.position.dx, size.height - tangent.position.dy)绘制了一组对对称的实心圆，这样整体就有一个圆形的效果了，动起来也会更有趣一点。

椭圆运动Loading

椭圆和圆形没什么区别，这里我们搞个渐变的效果看看，利用之前介绍过的Paint的shader可以实现渐变色绘制效果。

实现代码如下所示。

final ballCount = 6;

final ballRadius = boxSize / 15;



var ovalPath = Path()

  ..addOval(Rect.fromCenter(

      center: center, width: boxSize, height: boxSize / 1.5));

paint.shader = LinearGradient(

  begin: Alignment.topLeft,

  end: Alignment.bottomRight,

  colors: [this.foregroundColor, this.bgColor],

).createShader(Offset.zero & size);

var ovalMetrics = ovalPath.computeMetrics();

for (var pathMetric in ovalMetrics) {

  for (var i = 0; i < ballCount; ++i) {

    var lengthRatio = animationValue * (1 - i / ballCount);

    var tangent =

        pathMetric.getTangentForOffset(pathMetric.length * lengthRatio);



    var ballPosition = tangent!.position;

    canvas.drawCircle(ballPosition, ballRadius / (1 + i), paint);

    canvas.drawCircle(

        Offset(size.width - tangent.position.dx,

            size.height - tangent.position.dy),

        ballRadius / (1 + i),

        paint);

  }

}

当然，如果渐变色的颜色更丰富一点会更有趣些。

贝塞尔曲线Loading

通过贝塞尔曲线构建一条Path，让一组圆形沿着贝塞尔曲线运动的Loading效果也很有趣。

原理和圆形的一样，首先是构建贝塞尔曲线Path，代码如下。

var bezierPath = Path()

  ..moveTo(size.width / 2 - boxSize / 2, center.dy)

  ..quadraticBezierTo(size.width / 2 - boxSize / 4, center.dy - boxSize / 4,

      size.width / 2, center.dy)

  ..quadraticBezierTo(size.width / 2 + boxSize / 4, center.dy + boxSize / 4,

      size.width / 2 + boxSize / 2, center.dy)

  ..quadraticBezierTo(size.width / 2 + boxSize / 4, center.dy - boxSize / 4,

      size.width / 2, center.dy)

  ..quadraticBezierTo(size.width / 2 - boxSize / 4, center.dy + boxSize / 4,

      size.width / 2 - boxSize / 2, center.dy);

这里实际是构建了两条贝塞尔曲线，先从左边到右边，然后再折回来。之后就是运动的实心圆了，这个只是数量上多了，ballCount为30，这样效果看着就有一种拖影的效果。

var ovalMetrics = bezierPath.computeMetrics();

for (var pathMetric in ovalMetrics) {

  for (var i = 0; i < ballCount; ++i) {

    var lengthRatio = animationValue * (1 - i / ballCount);

    var tangent =

        pathMetric.getTangentForOffset(pathMetric.length * lengthRatio);



    var ballPosition = tangent!.position;

    canvas.drawCircle(ballPosition, ballRadius / (1 + i), paint);

    canvas.drawCircle(

        Offset(size.width - tangent.position.dx,

            size.height - tangent.position.dy),

        ballRadius / (1 + i),

        paint);

  }

}

这里还可以改变运动方向，实现一些其他的效果，例如下面的效果，第二组圆球的绘制位置实际上是第一组圆球的x、y坐标的互换。

var lengthRatio = animationValue * (1 - i / ballCount);

var tangent =

    pathMetric.getTangentForOffset(pathMetric.length * lengthRatio);



var ballPosition = tangent!.position;

canvas.drawCircle(ballPosition, ballRadius / (1 + i), paint);

canvas.drawCircle(Offset(tangent.position.dy, tangent.position.dx),

    ballRadius / (1 + i), paint);

组件使用

我们来看如何使用我们定义的这个组件，使用代码如下，我们用Future延迟模拟了一个加载效果，在加载过程中使用loading指示加载过程，加载完成后显示图片。

class _LoadingDemoState extends State<LoadingDemo> {

  var loaded = false;



  @override

  void initState() {

    super.initState();

    Future.delayed(Duration(seconds: 5), () {

      setState(() {

        loaded = true;

      });

    });

  }



  @override

  Widget build(BuildContext context) {

    return Scaffold(

      backgroundColor: Colors.white,

      appBar: AppBar(

        title: Text('Loading 使用'),

      ),

      body: Center(

        child: loaded

            ? Image.asset(

                'images/beauty.jpeg',

                width: 100.0,

              )

            : LoadingAnimations(

                foregroundColor: Colors.blue,

                bgColor: Colors.white,

                size: 100.0,

              ),

      ),

    );

  }

最终运行的效果如下，源码已提交至：绘图相关源码，文件名为loading_animations.dart。

总结

本篇介绍了Loading组件的封装方法，核心要点还是利用Path和动画控制绘制元素的运动轨迹来实现更有趣的效果。在实际应用过程中，也可以根据交互设计的需要，做一些其他有趣的加载动效，提高等待过程的趣味性。

mmap初入

我们常说的mmap，其实是一种内存映射文件的方法，mmap将一个文件或者其它对象映射进内存。但是更加确切的来说，其实是linux中的线性区提供的可以和基于磁盘文件系统的普通文件的某一个部分相关联的操作。线性区其实是由进程中连续的一块虚拟文件区域，由struct vm_area_struct结构体表示，我们的mmap操作，其实就是最本质的，就是通过其进行的内存操作。

按照归类的思想，其实mmap主要用到的分为两类（还有其他标识不讨论）

1. 共享的：即对该线性区中的页（注意是以页为单位）的任何写操作，都会修改磁盘上的文件，并且如果一个进程对进行了mmap的页进行了写操作，那么对于其他进程（同样也通过mmap进行了映射），同样也是可见的


2. 私有的：对于私有映射页的任何写操作，都会使linux内核停止映射该文件的页（注意，假如有进程a，b同时映射了该页，a对页进行了修改，此时这个页就相当于复制出来了一份，a以后的操作就在复制的该页进行操作，b还是引用原来的页，原来的页就可以继续参与内存映射，而复制出来的页，就被停止映射了），因此，在私有情况下，写操作是不会改变磁盘上的文件，同时所做的修改对于其他进程来说，就是不可见的。

我们看一下图片
共享模式下

私有模式下

mmap分析

概念我们有了，我们看一下代码mmap定义

#if defined(__USE_FILE_OFFSET64)

void* mmap(void* __addr, size_t __size, int __prot, int __flags, int __fd, off_t __offset) __RENAME(mmap64);

#else

void* mmap(void* __addr, size_t __size, int __prot, int __flags, int __fd, off_t __offset);

#endif



#if __ANDROID_API__ >= 21

/**

 * mmap64() is a variant of mmap() that takes a 64-bit offset even on LP32.

 *

 * See https://android.googlesource.com/platform/bionic/+/master/docs/32-bit-abi.md

 *

 * mmap64 wasn't really around until L, but we added an inline for it since it

 * allows a lot more code to compile with _FILE_OFFSET_BITS=64.

 */

void* mmap64(void* __addr, size_t __size, int __prot, int __flags, int __fd, off64_t __offset) __INTRODUCED_IN(21);

#endif

mmap分为好多个版本，但是其他的也是根据不同的Android版本或者abi进行部分的区分，我们来看一下具体含义：

1. addr:参数addr指定文件应被映射到进程空间的起始地址，一般被指定一个空指针，此时选择起始地址的任务留给内核来完成。当然，我们也可以设定一个自己的地址，但是如果flag中设定起来MAP_FIXED标志，且内核也没办法从我们指定的线性地址开始分配新线性区的话，就会产生调用失败


2. size:映射到调用进程地址空间的字节数，它从被映射文件开头offset个字节开始算起


3. prot:指定对线性区的一组权限，比如读权限（PROT_READ）,写权限（PROT_WRITE），执行权限（PROT_EXEC）


4. flags:一组标志，比如我们上面说的共享模式（MAP_SHARED）或者私有模式（MAP_PRIVATE）等


5. fd：文件描述符，要映射的文件


6. offset：要映射的文件的偏移量（比如我想要从文件的某部分开始映射）

使用例子

下面是demo例子

#include <sys/mman.h>

#include <sys/types.h>

#include <sys/stat.h>

#include <sys/fcntl.h>

#include <errno.h>

#include <string.h>

#include <stdio.h>

#include <stdlib.h>

#include <unistd.h>

 

#define TRUE 1

#define FALSE -1

#define FILE_SIZE 100

 

#define MMAP_FILE_PATH "./mmap.txt"



 

int main(int argc, char **argv) 

{

    int fd = -1;

    //char buff[100] = {0};

    void *result;

    int lseek_result = -1;

    int file_length = -1;

    

    // 1. open the file

    fd = open(MMAP_FILE_PATH, O_RDWR|O_CREAT, S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH);

    if (-1 == fd) {

        printf("open failed\n");

        printf("%s\n", strerror(errno));

        return FALSE;

    }



    //2. call mmap 这里可以尝试一下其他的flag，比如MAP_PRIVATE

    result = mmap(0, 100（这里是demo文件长度）, \

                PROT_READ|PROT_WRITE, \

                MAP_SHARED, \

                fd, 0);

    if (result == (void *)-1) {

        printf("mmap failed\n");

        printf("%s\n", strerror(errno));

        return FALSE;

    }

 

    //3. release the file descriptor

    close(fd);

 

    //4. write something to mmap addr,

    strncpy(result, "test balabala...", file_length);

 

    //5. call munmap

    munmap(0, file_length);

 

    return 0;

}

深入了解mmap

不得不说，mmap的函数实现非常复杂，首先会调用到do_mmap_pgoff进行平台无关的代码分支，然后会调用到do_mmap里面，这个函数非常长！！！

我们挑几个关键的步骤：

1. 先检查要映射的文件是否定义了mmap文件操作，（如果是目录就不存在mmap文件操作了）如果没有的话就直接调用失败


2. 检查一系列的一致性检查，同时根据mmap的参数与打开文件的权限标志进行对比：比如检查当前文件是否有文件锁，如果是以MAP_SHARED模式打开进行写入的话，也要检查文件是否有可写的权限，正所谓权限要一致


3. 设置线性区的vm_flag字段，因为我们mmap返回的地址肯定也是要给到当前进程的，这个线性区的权限所以也要设置，比如VM_READ,VM_WRITE等标识，表明了这块内存的权限


4. 增加文件的引用计数，因为我们进程mmap用到了该文件对吧，所以计数器也要加一，这样系统才会知道当前文件被多少个进程引用了


5. 对文件进行映射操作，并且初始化该线性区的页，注意这个时候并没有对页进行操作，因为有可能申请了这个页而没有操作，所以这个时候是以no_page标识的，这里不得不感慨linux的写时复制思想用到了各处！只有真正访问的时候，就会产生一个缺页异常，由内核调度请求完成对该页的填充

unsigned long do_mmap(struct file *file, unsigned long addr,

   unsigned long len, unsigned long prot,

   unsigned long flags, vm_flags_t vm_flags,

   unsigned long pgoff, unsigned long *populate)

{

 struct mm_struct *mm = current->mm;        //获取该进程的memory descriptor

 int pkey = 0;



 *populate = 0;

 //函数对传入的参数进行一系列检查, 假如任一参数出错，都会返回一个errno

 if (!len)

  return -EINVAL;



 /*

  * Does the application expect PROT_READ to imply PROT_EXEC?

  *

  * (the exception is when the underlying filesystem is noexec

  *  mounted, in which case we dont add PROT_EXEC.)

  */

 if ((prot & PROT_READ) && (current->personality & READ_IMPLIES_EXEC))

  if (!(file && path_noexec(&file->f_path)))

   prot |= PROT_EXEC;

 //假如没有设置MAP_FIXED标志，且addr小于mmap_min_addr, 因为可以修改addr, 所以就需要将addr设为mmap_min_addr的页对齐后的地址

 if (!(flags & MAP_FIXED))

  addr = round_hint_to_min(addr);



 /* Careful about overflows.. */

 len = PAGE_ALIGN(len);         //进行Page大小的对齐

 if (!len)

  return -ENOMEM;



 /* offset overflow? */

 if ((pgoff + (len >> PAGE_SHIFT)) < pgoff)

  return -EOVERFLOW;



 /* Too many mappings? */

 if (mm->map_count > sysctl_max_map_count)    //判断该进程的地址空间的虚拟区间数量是否超过了限制

  return -ENOMEM;



 //get_unmapped_area从当前进程的用户空间获取一个未被映射区间的起始地址

 addr = get_unmapped_area(file, addr, len, pgoff, flags);

 if (offset_in_page(addr))        //检查addr是否有效

  return addr;



 if (prot == PROT_EXEC) {

  pkey = execute_only_pkey(mm);

  if (pkey < 0)

   pkey = 0;

 }



 /* Do simple checking here so the lower-level routines won't have

  * to. we assume access permissions have been handled by the open

  * of the memory object, so we don't do any here.

  */

 vm_flags |= calc_vm_prot_bits(prot, pkey) | calc_vm_flag_bits(flags) |

   mm->def_flags | VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC;

 //假如flags设置MAP_LOCKED，即类似于mlock()将申请的地址空间锁定在内存中, 检查是否可以进行lock

 if (flags & MAP_LOCKED)

  if (!can_do_mlock())

   return -EPERM;



 if (mlock_future_check(mm, vm_flags, len))

  return -EAGAIN;



 if (file) {          // file指针不为nullptr, 即从文件到虚拟空间的映射

  struct inode *inode = file_inode(file);   //获取文件的inode



  switch (flags & MAP_TYPE) {       //根据标志指定的map种类，把为文件设置的访问权考虑进去

  case MAP_SHARED:

   if ((prot&PROT_WRITE) && !(file->f_mode&FMODE_WRITE))

    return -EACCES;



   /*

    * Make sure we don't allow writing to an append-only

    * file..

    */

   if (IS_APPEND(inode) && (file->f_mode & FMODE_WRITE))

    return -EACCES;



   /*

    * Make sure there are no mandatory locks on the file.

    */

   if (locks_verify_locked(file))

    return -EAGAIN;



   vm_flags |= VM_SHARED | VM_MAYSHARE;

   if (!(file->f_mode & FMODE_WRITE))

    vm_flags &= ~(VM_MAYWRITE | VM_SHARED);



   /* fall through */

  case MAP_PRIVATE:

   if (!(file->f_mode & FMODE_READ))

    return -EACCES;

   if (path_noexec(&file->f_path)) {

    if (vm_flags & VM_EXEC)

     return -EPERM;

    vm_flags &= ~VM_MAYEXEC;

   }



   if (!file->f_op->mmap)

    return -ENODEV;

   if (vm_flags & (VM_GROWSDOWN|VM_GROWSUP))

    return -EINVAL;

   break;



  default:

   return -EINVAL;

  }

 } else {

  switch (flags & MAP_TYPE) {

  case MAP_SHARED:

   if (vm_flags & (VM_GROWSDOWN|VM_GROWSUP))

    return -EINVAL;

   /*

    * Ignore pgoff.

    */

   pgoff = 0;

   vm_flags |= VM_SHARED | VM_MAYSHARE;

   break;

  case MAP_PRIVATE:

   /*

    * Set pgoff according to addr for anon_vma.

    */

   pgoff = addr >> PAGE_SHIFT;

   break;

  default:

   return -EINVAL;

  }

 }



 /*

  * Set 'VM_NORESERVE' if we should not account for the

  * memory use of this mapping.

  */

 if (flags & MAP_NORESERVE) {

  /* We honor MAP_NORESERVE if allowed to overcommit */

  if (sysctl_overcommit_memory != OVERCOMMIT_NEVER)

   vm_flags |= VM_NORESERVE;



  /* hugetlb applies strict overcommit unless MAP_NORESERVE */

  if (file && is_file_hugepages(file))

   vm_flags |= VM_NORESERVE;

 }

 //一顿检查和配置，调用核心的代码mmap_region

 addr = mmap_region(file, addr, len, vm_flags, pgoff);

 if (!IS_ERR_VALUE(addr) &&

     ((vm_flags & VM_LOCKED) ||

      (flags & (MAP_POPULATE | MAP_NONBLOCK)) == MAP_POPULATE))

  *populate = len;

 return addr;

}

do_mmap() 根据用户传入的参数做了一系列的检查，然后根据参数初始化 vm_area_struct 的标志 vm_flags，vma->vm_file = get_file(file) 建立文件与vma的映射, mmap_region() 负责创建虚拟内存区域:



unsigned long mmap_region(struct file *file, unsigned long addr,

  unsigned long len, vm_flags_t vm_flags, unsigned long pgoff)

{

 struct mm_struct *mm = current->mm;     //获取该进程的memory descriptor

 struct vm_area_struct *vma, *prev;

 int error;

 struct rb_node **rb_link, *rb_parent;

 unsigned long charged = 0;



 /* 检查申请的虚拟内存空间是否超过了限制 */

 if (!may_expand_vm(mm, vm_flags, len >> PAGE_SHIFT)) {

  unsigned long nr_pages;



  /*

   * MAP_FIXED may remove pages of mappings that intersects with

   * requested mapping. Account for the pages it would unmap.

   */

  nr_pages = count_vma_pages_range(mm, addr, addr + len);



  if (!may_expand_vm(mm, vm_flags,

     (len >> PAGE_SHIFT) - nr_pages))

   return -ENOMEM;

 }



 /* 检查[addr, addr+len)的区间是否存在映射空间，假如存在重合的映射空间需要munmap  */

 while (find_vma_links(mm, addr, addr + len, &prev, &rb_link,

         &rb_parent)) {

  if (do_munmap(mm, addr, len))

   return -ENOMEM;

 }



 /*

  * Private writable mapping: check memory availability

  */

 if (accountable_mapping(file, vm_flags)) {

  charged = len >> PAGE_SHIFT;

  if (security_vm_enough_memory_mm(mm, charged))

   return -ENOMEM;

  vm_flags |= VM_ACCOUNT;

 }



 //检查是否可以合并[addr, addr+len)区间内的虚拟地址空间vma

 vma = vma_merge(mm, prev, addr, addr + len, vm_flags,

   NULL, file, pgoff, NULL, NULL_VM_UFFD_CTX);

 if (vma)       //假如合并成功，即使用合并后的vma, 并跳转至out

  goto out;

 //如果不能和已有的虚拟内存区域合并，通过Memory Descriptor来申请一个vma

 vma = kmem_cache_zalloc(vm_area_cachep, GFP_KERNEL);

 if (!vma) {

  error = -ENOMEM;

  goto unacct_error;

 }

 //初始化vma

 vma->vm_mm = mm;

 vma->vm_start = addr;

 vma->vm_end = addr + len;

 vma->vm_flags = vm_flags;

 vma->vm_page_prot = vm_get_page_prot(vm_flags);

 vma->vm_pgoff = pgoff;

 INIT_LIST_HEAD(&vma->anon_vma_chain);



 if (file) { //假如指定了文件映射 

  if (vm_flags & VM_DENYWRITE) {   //映射的文件不允许写入，调用deny_write_accsess(file)排斥常规的文件操作

   error = deny_write_access(file);

   if (error)

    goto free_vma;

  }

  if (vm_flags & VM_SHARED) {   //映射的文件允许其他进程可见, 标记文件为可写

   error = mapping_map_writable(file->f_mapping);

   if (error)

    goto allow_write_and_free_vma;

  }



  //递增File的引用次数，返回File赋给vma

  vma->vm_file = get_file(file);

  error = file->f_op->mmap(file, vma);  //调用文件系统指定的mmap函数

  if (error)

   goto unmap_and_free_vma;



  /* Can addr have changed??

   *

   * Answer: Yes, several device drivers can do it in their

   *         f_op->mmap method. -DaveM

   * Bug: If addr is changed, prev, rb_link, rb_parent should

   *      be updated for vma_link()

   */

  WARN_ON_ONCE(addr != vma->vm_start);



  addr = vma->vm_start;

  vm_flags = vma->vm_flags;

 } else if (vm_flags & VM_SHARED) {

  error = shmem_zero_setup(vma);  //假如标志为VM_SHARED，但没有指定映射文件，需要调用shmem_zero_setup(),实际映射的文件是dev/zero

  if (error)

   goto free_vma;

 }

 //将申请的新vma加入mm中的vma链表

 vma_link(mm, vma, prev, rb_link, rb_parent);

 /* Once vma denies write, undo our temporary denial count */

 if (file) {

  if (vm_flags & VM_SHARED)

   mapping_unmap_writable(file->f_mapping);

  if (vm_flags & VM_DENYWRITE)

   allow_write_access(file);

 }

 file = vma->vm_file;

out:

 perf_event_mmap(vma);

 //更新进程的虚拟地址空间mm

 vm_stat_account(mm, vm_flags, len >> PAGE_SHIFT);

 if (vm_flags & VM_LOCKED) {

  if (!((vm_flags & VM_SPECIAL) || is_vm_hugetlb_page(vma) ||

     vma == get_gate_vma(current->mm)))

   mm->locked_vm += (len >> PAGE_SHIFT);

  else

   vma->vm_flags &= VM_LOCKED_CLEAR_MASK;

 }



 if (file)

  uprobe_mmap(vma);



 /*

  * New (or expanded) vma always get soft dirty status.

  * Otherwise user-space soft-dirty page tracker won't

  * be able to distinguish situation when vma area unmapped,

  * then new mapped in-place (which must be aimed as

  * a completely new data area).

  */

 vma->vm_flags |= VM_SOFTDIRTY;



 vma_set_page_prot(vma);



 return addr;



unmap_and_free_vma:

 vma->vm_file = NULL;

 fput(file);



 /* Undo any partial mapping done by a device driver. */

 unmap_region(mm, vma, prev, vma->vm_start, vma->vm_end);

 charged = 0;

 if (vm_flags & VM_SHARED)

  mapping_unmap_writable(file->f_mapping);

allow_write_and_free_vma:

 if (vm_flags & VM_DENYWRITE)

  allow_write_access(file);

free_vma:

 kmem_cache_free(vm_area_cachep, vma);

unacct_error:

 if (charged)

  vm_unacct_memory(charged);

 return error;

}

munmap

当进程准备清除一个mmap映射时，就可以调用munmap函数

int munmap(void* __addr, size_t __size);

如demo例子所示，第一个函数是要删除的线性地址的第一个单元的地址，第二个函数是线性区的长度，由于这个函数比较简单，就是系统调用do_munmap函数，这里就不详细分析啦！

数据写回磁盘

经过上面的mmap操作，我们也知道了mmap的使用了，不知道大家有没有留意一个细节，就是上面图中我们内存写入的下一步是页高速缓存，这个时候真正的数据保存，其实还是没有真正写入到磁盘里面的，真正写入其实是靠系统调用写入，即msync函数

int msync(void* __addr, size_t __size, int __flags);

mmap的数据写入依靠着这个系统调用保证，即当前进程被异常销毁了，也可以通过这个系统级别的调用，把属于内存映射的脏页数据写回去磁盘。参数1跟2需要写回去的头地址跟大小，我们重点看一下最后一个参数flags，它有以下几个参数选择：

• MS_SYNC:要求系统挂起调用进程，直到I/O操作完成


• MS_ASYNC:可以系统调用立即返回，不用挂起调用进程（大多数使用到mmap库选择）


• MS_INVALLDATE:要求系统调用从进程地址空间删除mmap映射的所有页
  这个函数主要功能是进行脏页标记，并进行真正的磁盘写入，大概的路径就是通过调用flush_tlb_page把缓冲器标记为脏页标识，同时获取文件对应的索引节点i_sem信号量，进行写入时的上锁，然后刷新到磁盘！

这里可以看到，mmap依靠系统调用，把数据刷新回到磁盘！虽然这个刷新动作是由linux系统进行刷入的，保证了进程出问题的时候，也能够在系统级别刷入数据，比如MMKV的设计就采用了这点，但是这个也不是百分百可靠的，因为这个刷入操作是没有备份操作的/异常容灾处理，如果系统异常或者断电的情况，就会出现错误数据或者没有完全刷入磁盘的数据，造成数据异常，我们也可以看到mmkv介绍

mmap不足

mmap最大的不足，就是被映射的线性区只能是按照页的整数倍进行计算，如果说我们要映射的内存少于这个数，也是按照一个页进行映射的，当然，一个页长度会根据不同架构而不同，比如常见的4kb等，同时也要时刻注意映射区的生命周期，不然无脑映射也很容易造成oom

扩展

当然，说到mmap，肯定也离不开对mmkv的介绍，虽然mmkv很优秀，但是也不能无脑就使用，这方面可以参考朱凯大佬发布的文章Android 的键值对存储有没有最优解？，这里就不再赘述，按照自己所需的使用，当然，jetpack的DataStore也是很香啊！有机会的话也出一篇解析文！

前言

之前在网上看到有人问协程能不能像线程一样 wait（暂停） 和 notify（恢复） 。

应用场景是开启一个线程然后执行一段逻辑，得到了某一个数据，然后需要拿到这个数据去处理一些别的事情，需要把线程先暂停，然后等逻辑处理完成之后再把线程 notify。

首先我们不说有没有其他的方式实现，我当然知道有其他多种其他实现的方式。单说这一种逻辑来看，我们使用协程能不能达到同样的效果？

那么问题来了，协程能像线程那样暂停与恢复吗？

协程默认是不能暂停与恢复的，不管是协程内部还是返回的Job对象，都不能暂停与恢复，最多只能delay延时一下，无法精准控制暂停与恢复。

但是我们可以通过 suspendCancellableCoroutine 来间接的实现这个功能。

那问题又来了，suspendCancellableCoroutine 是个什么东西？怎么用？

一、suspendCancellableCoroutine的用法

很多人不了解这个类，不知道它是干嘛的，其实我们点击去看源码就知道，源码已经给出了很清晰的注释，并且还附带了使用场景

简单的说就是把Java/Kotlin 的一些回调方法，兼容改造成 suspend 的函数，让它可以运行在协程中。

以一个非常经典的例子，网络请求我们可以通过 Retrofit+suspend 的方式，也可以直接使用 OkHttp 的方式，我们很早之前都是自己封装 OkHttpUtils 的，然后以回调的方式返回正确结果和异常处理。

我们就可以通过 suspendCancellableCoroutine 把 OkHttpUtils 的回调方式进行封装，像普通的 suspend 方法一样使用了。

    fun suspendSth() {



        viewModelScope.launch {



            val school = mRepository.getSchool()  //一个是使用Retrofit + suspend



            try {

                val industry = getIndustry()        //一个是OkHttpUtils回调的方式

            } catch (e: Exception) {

                e.printStackTrace()  //捕获OkHttpUtils返回的异常信息

            }



        }



    }



    private suspend fun getIndustry(): String? {

        return suspendCancellableCoroutine { cancellableContinuation ->



            OkhttpUtil.okHttpGet("http://www.baidu.com/api/industry", object : CallBackUtil.CallBackString() {



                override fun onFailure(call: Call, e: Exception) {

                    cancellableContinuation.resumeWithException(e)

                }



                override fun onResponse(call: Call, response: String?) {

                    cancellableContinuation.resume(response)

                }



            })

        }

    }

感觉使用起来真是方便呢，那除了 suspendCancellableCoroutine 有没有其他的方式转换回调？有，suspendCoroutine，那它们之间的区别是什么？

suspendCancellableCoroutine 和 suspendCoroutine 区别

SuspendCancellableCoroutine 返回一个 CancellableContinuation， 它可以用 resume、resumeWithException 来处理回调和抛出 CancellationException 异常。

它与 suspendCoroutine的唯一区别就是 SuspendCancellableCoroutine 可以通过 cancel() 方法手动取消协程的执行，而 suspendCoroutine 没有该方法。

所以尽可能使用 suspendCancellableCoroutine 而不是 suspendCoroutine ，因为协程的取消是可控的。

那我们不使用回调直接用行不行？当然可以，例如：

  fun suspendSth() {



     viewModelScope.launch {



            val school = mRepository.getSchool()



            if (school is OkResult.Success) {



                val lastSchool = handleSchoolData(school.data)



                YYLogUtils.w("处理过后的School:" + lastSchool)

            }



        }





    }



  private suspend fun handleSchoolData(data: List<SchoolBean>?): SchoolBean? {



        return suspendCancellableCoroutine {



            YYLogUtils.w("通过开启一个线程延时5秒再返回")

            thread {

                Thread.sleep(5000)



                it?.resume(mSchoolList?.last(), null)

            }



        }

    }

那怎么能达到协程的暂停与恢复那种效果呢？我们把参数接收一下，变成成员变量不就行了吗？想什么时候resume就什么时候resume。

二、实现协程的暂停与恢复

我们定义一个方法开启一个协程，内部使用一个 suspendCancellableCoroutine 函数包裹我们的逻辑（暂停），再定义另一个方法内部使用 suspendCancellableCoroutine 的 resume 来返回给协程（恢复）。

  fun suspendSth() {



     viewModelScope.launch {



            val school = mRepository.getSchool() //网络获取数据



            if (school is OkResult.Success) {



                val lastSchool = handleSchoolData(school.data)



                //下面的不会执行的，除非 suspendCancellableCoroutine 的 resume 来恢复协程，才会继续走下去



                YYLogUtils.w("处理过后的School:" + lastSchool)

            }



        }





    }



    private var mCancellableContinuation: CancellableContinuation<SchoolBean?>? = null

    private var mSchoolList: List<SchoolBean>? = null



    private suspend fun handleSchoolData(data: List<SchoolBean>?): SchoolBean? {



        mSchoolList = data



        return suspendCancellableCoroutine {



            mCancellableContinuation = it



            YYLogUtils.w("开启线程睡眠5秒再说")

            thread {

                Thread.sleep(5000)



                YYLogUtils.w("就是不返回，哎，就是玩...")



            }



        }

    }



    //我想什么时候返回就什么时候返回

    fun resumeCoroutine() {



        YYLogUtils.w("点击恢复协程-返回数据")



        if (mCancellableContinuation?.isCancelled == true) {

            return

        }



        mCancellableContinuation?.resume(mSchoolList?.last(), null)



    }

使用： 点击开启协程暂停了，再点击下面的按钮即恢复协程

fun testflow() {

    mViewModel.suspendSth()

}



fun resumeScope() {

    mViewModel.resumeCoroutine()

}

效果是点击开启协程之后我等了20秒恢复了协程，打印如下：

总结

协程虽然默认是不支持暂停与恢复，但是我们可以通过 suspendCancellableCoroutine 来间接的实现。

虽然如此，但实例开发上我还是不太推荐这么用，这样的场景我们有多种实现方式。可以用其他很好的方法实现，比如用一个协程不就好了吗串行执行，或者并发协程然后使用协程的通信来传递，或者用线程+队列也能做等等。真的一定要暂停住协程吗？不是不能实现，只是感觉不是太优雅。

(注：不好意思，这里有点主观意识了，大家不一定就要参考，毕竟它也只是一种场景需求实现的方式而已，只要性能没问题，所有的方案都是可行，大家按需选择即可)

当然关于 suspendCancellableCoroutine 谷歌的本意是让回调也能兼容协程，这也是它最大的应用场景。

本期内容如讲的不到位或错漏的地方，希望同学们可以指出交流。

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

Ok,这一期就此完结。

1. Barrier

是一个准则，可以说是对其的规则，这样说还不够名义，我们可以列表一些比较常见的场景； 官网 Barrier。

1. 具体看图

 “第二行的label”和“第二行value”是一个整体，他们距离上面是 100dp ，但是有可能“第二行value”的值为空或者是空，也需要“第二行label”距离上面的距离是 100dp ，由于我们知道“第二行value”的高度高于第一个，所以采用的是“第二行label”跟“第二行value”对其，“第二行value”距离上边 100dp 的距离，但是由于“第二行value”有可能为空，所以当“第二行value”为空的时候就会出现下面的效果：

 我们发现达不到预期，现在能想到的办法有，首先在代码控制的时候随便把“第二行label”的 marginTop 也添加进去；还有就是换布局，将“第二行label”和“第二行value”放到一个布局中，比如 LinearLayout ，这样上边的 marginTop 由 LinearLayout 控制；这样的话即便“第二行value”消失了也会保持上边的效果。

除了上边的方法还能使用其他的嘛，比如我们不使用代码控制，我们不使用其他的布局，因为我们知道布局嵌套太多性能也会相应的下降，所以在编写的时候能减少嵌套的情况下尽可能的减少，当然也不能为了减少嵌套让代码变得格外的复杂。

为了满足上面的需求， Barrier 出现了，它能做到隐藏的也能依靠它，并且与它的距离保持不变对于隐藏的“第二行value”来说，虽然消失了，但保留了 marginTop 的数值。下面看看布局：

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

<androidx.constraintlayout.widget.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"

    xmlns:app="http://schemas.android.com/apk/res-auto"

    xmlns:tools="http://schemas.android.com/tools"

    android:layout_width="match_parent"

    android:layout_height="match_parent"

    tools:context=".MainActivity">



  <TextView

      android:id="@+id/textView4"

      android:layout_width="wrap_content"

      android:layout_height="wrap_content"

      android:text="头部"

      android:textSize="36sp"

      app:layout_constraintBottom_toTopOf="@id/barrier3"

      app:layout_constraintStart_toStartOf="parent"

      app:layout_constraintTop_toTopOf="parent" />





  <androidx.constraintlayout.widget.Barrier

      android:id="@+id/barrier3"

      android:layout_width="wrap_content"

      android:layout_height="wrap_content"

      app:barrierDirection="top"

      android:layout_marginTop="100dp"

      app:constraint_referenced_ids="textView2,textView3" />



  <TextView

      android:id="@+id/textView2"

      android:layout_width="wrap_content"

      android:layout_height="wrap_content"

      android:layout_marginStart="4dp"

      android:text="第二行label"

      android:textSize="36sp"

      app:layout_constraintBottom_toBottomOf="@+id/textView3"

      app:layout_constraintStart_toStartOf="@+id/textView4"

      app:layout_constraintTop_toTopOf="@+id/textView3"

      app:layout_constraintVertical_bias="0.538" />



  <TextView

      android:id="@+id/textView3"

      android:layout_width="wrap_content"

      android:layout_height="100dp"

      android:layout_marginStart="12dp"

      android:layout_marginTop="100dp"

      android:text="第二行value"

      android:textSize="36sp"

      app:layout_constraintStart_toEndOf="@+id/textView2"

      app:layout_constraintTop_toBottomOf="@+id/barrier3" />



</androidx.constraintlayout.widget.ConstraintLayout>

这样即便将“第二行value”消失，那么总体的布局仍然达到预期，并且也没有添加很多布局内容。在代码中：

<androidx.constraintlayout.widget.Barrier

      android:id="@+id/barrier3"

      android:layout_width="wrap_content"

      android:layout_height="wrap_content"

      app:barrierDirection="top"

      android:layout_marginTop="100dp"

      app:constraint_referenced_ids="textView2,textView3" />

这里主要有两个属性 app:barrierDirection 和 app:constraint_referenced_ids ：

• app:barrierDirection 是代表位置，也就是在包含内容的哪一个位置，我这里写的是 top ，是在顶部，还有其他的属性 top,bottom,left,right,start 和 end 这几个属性，看意思就很明白了。
• app:constraint_referenced_ids 上面说的内容就是包含在这里面的，这里面填写的是 id 的名称，如果有多个，那么使用逗号隔开；这里面的到 Barrier 的距离不会改变，即便隐藏了也不会变。

这里可能会有疑惑，为啥我写的 id 为 textView4 的也依赖于 Barrier ，这是因为本身 Barrier 只是规则不是实体，它的存在只能依附于实体，不能单独存在于具体的位置，如果我们只有“第二行value”依赖于它，但是本身“第二行value”没有上依赖，也相当于没有依赖，这样只会导致“第二行label”和“第二行value”都消失，如果 textView4 依赖于 Barrier ，由于 textView4 的位置是确定的，所以 Barrier 的位置也就确定了。

2. 类似表格的效果。看布局效果：

 我要做成上面的样子。也就是右边永远与左边最长的保持距离。下面是我的代码：

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

<androidx.constraintlayout.widget.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"

    xmlns:app="http://schemas.android.com/apk/res-auto"

    xmlns:tools="http://schemas.android.com/tools"

    android:layout_width="match_parent"

    android:layout_height="match_parent"

    tools:context=".MainActivity">





  <TextView

      android:id="@+id/textView4"

      android:layout_width="wrap_content"

      android:layout_height="wrap_content"

      android:layout_marginStart="8dp"

      android:text="头部"

      android:textSize="36sp"

      app:layout_constraintStart_toStartOf="parent"

      app:layout_constraintTop_toTopOf="parent" />



  <TextView

      android:id="@+id/textView2"

      android:layout_width="wrap_content"

      android:layout_height="wrap_content"

      android:layout_marginStart="4dp"

      android:text="第二行"

      android:textSize="36sp"

      app:layout_constraintBottom_toBottomOf="@+id/textView3"

      app:layout_constraintStart_toStartOf="@+id/textView4"

      app:layout_constraintTop_toTopOf="@+id/textView3" />



  <TextView

      android:id="@+id/textView3"

      android:layout_width="wrap_content"

      android:layout_height="50dp"

      android:layout_marginStart="20dp"

      android:layout_marginTop="10dp"

      android:text="第二行value"

      android:textSize="36sp"

      app:layout_constraintStart_toEndOf="@+id/barrier4"

      app:layout_constraintTop_toBottomOf="@+id/textView4" />





  <TextView

      android:id="@+id/textView5"

      android:layout_width="wrap_content"

      android:layout_height="wrap_content"

      android:layout_marginStart="4dp"

      android:text="第三次测试"

      android:textSize="36sp"

      app:layout_constraintBottom_toBottomOf="@+id/textView6"

      app:layout_constraintStart_toStartOf="@+id/textView4"

      app:layout_constraintTop_toTopOf="@+id/textView6" />



  <TextView

      android:id="@+id/textView6"

      android:layout_width="wrap_content"

      android:layout_height="50dp"

      android:layout_marginStart="20dp"

      android:layout_marginTop="10dp"

      android:text="第三行value"

      android:textSize="36sp"

      app:layout_constraintStart_toEndOf="@+id/barrier4"

      app:layout_constraintTop_toBottomOf="@+id/textView3" />



  <androidx.constraintlayout.widget.Barrier

      android:id="@+id/barrier4"

      android:layout_width="wrap_content"

      android:layout_height="wrap_content"

      app:barrierDirection="end"

      app:constraint_referenced_ids="textView2,textView5"

      tools:layout_editor_absoluteX="411dp" />





</androidx.constraintlayout.widget.ConstraintLayout>

添加好了，记得让右边的约束指向 Barrier 。这里的 Barrier ，我们看到包含 textView2 和 textView5 ，这个时候就能做到谁长听谁的，如果此时 textView2 变长了，那么就会将就 textView2 。

2. Chains

我们特别喜欢使用线性布局，因为我们发现 UI 图上的效果使用线性布局都可以使用，当然也有可能跟大部分人的思维方式有关系。比如我们非常喜欢的，水平居中，每部分的空间分布等等都非常的顺手。既然线性布局这么好用，那为啥还有约束布局呢，因为线性布局很容易写出嵌套很深的布局，但约束布局不会，甚至大部分情况都可以不需要嵌套就能实现，那是不是代表线性布局有的约束布局也有，答案是肯定的。

使用普通的约束关系就很容易实现水平居中等常用效果，其他的如水平方向平均分布空间，使用一般的约束是实现不了的，于是就要使用 Chains ，这个就很容易实现下面的效果：

 其实上一篇中我已经把官网的教程贴上去了，这里主要写双向约束怎么做，一旦双向约束形成，那么就自然进入到 Chains 模式。

1）在视图模式中操作

如果直接操作，那么只能单向约束，如果要形成这样的约束，需要选择相关的的节点，比如我这里就是同时选择 A 和 B ，然后点击鼠标右键，就可以看到 Chains → Create Horizontal Chain 。

对应的操作

选择图中的选项即可完成从 A 指向 B ，修改的示意图为：

我们发现已经实现了水平方向的排列效果了。至于怎么实现上面的效果，主要是改变 layout_constraintVertical_chainStyle 和 layout_constraintHorizontal_chainStyle 属性。至于权重则是属性 layout_constraintHorizontal_weight 。

layout_constraintHorizontal_chainStyle 属性说明：

• spread 默认选项，效果就是上面的那种，也就是平均分配剩余空间；
• spread_inside 两边的紧挨着非 Chains 的视图，中间的平均分配；

• packed 所有的都在中间

 注意了， layout_constraintHorizontal_weight 这个属性只有在 A 身上设置才可以，也就是首节点上设置才可行，同时 layout_constraintHorizontal_weight 是代表水平方向，只能在水平方向才发生作用，如果水平的设置了垂直则不生效。

layout_constraintHorizontal_weight 这个属性只有在当前视图的宽或者高是 0dp 。至于这个的取值跟线性布局相同。

2）代码的方式 跟上面的差别就是在做双向绑定，用代码就很容易实现双向绑定，可平时添加约束相同。

 Android 12 高斯模糊

新功能：更易用的模糊、彩色滤镜等特效 。

新的 API 让你能更轻松地将常见图形效果应用到视图和渲染结构上。

• 
  

  使用 RenderEffect 将模糊、色彩滤镜等效果应用于 RenderNode 或 View。

  
  


• 
  

  使用新的 Window.setBackgroundBlurRadius() API 为窗口背景创建雾面玻璃效果，

  
  


• 
  

  使用 blurBehindRadius 来模糊窗口后面的所有内容。

  
  

咱们一个一个玩。

🔥 RenderEffect

💥 实现效果

    private void setBlur(){

        View.setRenderEffect(RenderEffect.createBlurEffect(3, 3, Shader.TileMode.REPEAT));

        ...

    }

使用特别简单，走你。

🌀 X 轴的模糊效果图

咱再看看代码

    private void setBlur(){

        agb.iv1.setRenderEffect(RenderEffect.createBlurEffect(3, 0, Shader.TileMode.CLAMP));

        agb.iv2.setRenderEffect(RenderEffect.createBlurEffect(8, 0, Shader.TileMode.REPEAT));

        agb.iv3.setRenderEffect(RenderEffect.createBlurEffect(18, 0 ,Shader.TileMode.MIRROR));

        agb.iv4.setRenderEffect(RenderEffect.createBlurEffect(36, 0,Shader.TileMode.DECAL));

    }

RenderEffect.createBlurEffect()的四个参数：

• 
  

  radiusX 沿 X 轴的模糊半径

  
  


• 
  

  radiusY 沿 Y 轴的模糊半径

  
  


• 
  

  inputEffect 模糊一次(传入 RenderEffect)

  
  


• 
  

  edgeTreatment 用于如何模糊模糊内核边缘附近的内容

  
  

下面两种仅看效果图。就不做代码设置了。

🌀 Y 轴的模糊效果图

🌀 XY同时模糊效果图

第四个参数对边缘模糊，效果图如下:

Shader.TileMode 提供了四个选项恕我没看出来。。

这里还有一堆方法等你玩。

注意：注意如此完美的画面只能在 Android 12(SDK31)及以上的设备上使用，其他版本的设备使用会导致崩溃，谨记谨记。
效果有了，下面咱们一起看看源码。

💥 源码

🌀 View.setRenderEffect()

    public void setRenderEffect(@Nullable RenderEffect renderEffect) {

        ...

    }

这个方法就是：renderEffect 应用于 View。 传入 null清除之前配置的RenderEffect 。这里咱们先看传入的 RenderEffect。

🌀 RenderEffect.createBlurEffect()

    public static RenderEffect createBlurEffect(

            float radiusX,

            float radiusY,

            @NonNull RenderEffect inputEffect,

            @NonNull TileMode edgeTreatment

    ) {

        long nativeInputEffect = inputEffect != null ? inputEffect.mNativeRenderEffect : 0;

        return new RenderEffect(

                nativeCreateBlurEffect(

                        radiusX,

                        radiusY,

                        nativeInputEffect,

                        edgeTreatment.nativeInt

                )

            );

    }

两个 createBlurEffect() 方法，分别为三参(模糊一次)和四参(模糊两次)。inputEffect 先进行了一次模糊。

看效果图：

模糊程度一样，但是实现方式不同：

    private void setBlur() {

        RenderEffect radiusXRenderEffect = RenderEffect.createBlurEffect(10, 0, Shader.TileMode.MIRROR);

        RenderEffect radiusYRenderEffect = RenderEffect.createBlurEffect(0, 10, Shader.TileMode.MIRROR);

        agb.iv1.setRenderEffect(RenderEffect.createBlurEffect(10, 10, Shader.TileMode.CLAMP));

        agb.iv2.setRenderEffect(RenderEffect.createBlurEffect(10, 10, Shader.TileMode.REPEAT));

        //自身radiusY 为 0 ，传入的radiusYRenderEffect设置的radiusY为10；

        agb.iv3.setRenderEffect(RenderEffect.createBlurEffect(10, 0, radiusYRenderEffect, Shader.TileMode.MIRROR));

        //自身radiusX 为 0 ，传入的radiusXRenderEffect设置的radiusX为10；

        agb.iv4.setRenderEffect(RenderEffect.createBlurEffect(0, 10, radiusXRenderEffect, Shader.TileMode.DECAL));

    }

这个方法返回一个 new RenderEffect(nativeCreateBlurEffect(...)。

那咱们去看看 nativeCreateBlurEffect()

🌀 nativeCreateBlurEffect()

frameworks/base/libs/hwui/jni/RenderEffect.cpp

static const JNINativeMethod gRenderEffectMethods[] = {

    ...

    {"nativeCreateBlurEffect", "(FFJI)J", (void*)createBlurEffect},

    ...

};



static jlong createBlurEffect(JNIEnv* env , jobject, jfloat radiusX,

        jfloat radiusY, jlong inputFilterHandle, jint edgeTreatment) {

    auto* inputImageFilter = reinterpret_cast<SkImageFilter*>(inputFilterHandle);

    sk_sp<SkImageFilter> blurFilter =

            SkImageFilters::Blur(

                    Blur::convertRadiusToSigma(radiusX),

                    Blur::convertRadiusToSigma(radiusY),

                    static_cast<SkTileMode>(edgeTreatment),

                    sk_ref_sp(inputImageFilter),

                    nullptr);

    return reinterpret_cast<jlong>(blurFilter.release());

}

这里有两个函数来处理我们传过来的模糊的值，咱进去看看。

🌀 convertRadiusToSigma(convertSigmaToRadius)

//该常数近似于在SkBlurMask::Blur()(1/sqrt(3)中，在软件路径的"高质量"模式下进行的缩放。

static const float BLUR_SIGMA_SCALE = 0.57735f;



float Blur::convertRadiusToSigma(float radius) {

    return radius > 0 ? BLUR_SIGMA_SCALE * radius + 0.5f : 0.0f;

}



float Blur::convertSigmaToRadius(float sigma) {

    return sigma > 0.5f ? (sigma - 0.5f) / BLUR_SIGMA_SCALE : 0.0f;

}

🌀 sk_ref_sp(inputImageFilter)

external/skia/include/core/SkRefCnt.h

/*

 *  返回包装提供的 ptr 的 sk_sp 并对其调用 ref （如果不为空）

 */

template <typename T> sk_sp<T> sk_ref_sp(T* obj) {

    //sk_sp<SkImageFilter> :

    return sk_sp<T>(SkSafeRef(obj));

}



//SkSafeRef：检查参数是否为非空，如果是，则调用 obj->ref() 并返回 obj。

template <typename T> static inline T* SkSafeRef(T* obj) {

    if (obj) {

        obj->ref();

    }

    return obj;

}

再往下走

🌀 SkImageFilters::Blur()

#define SK_Scalar1                  1.0f

#define SK_ScalarNearlyZero         (SK_Scalar1 / (1 << 12))



sk_sp<SkImageFilter> SkImageFilters::Blur(

        SkScalar sigmaX, SkScalar sigmaY, SkTileMode tileMode, sk_sp<SkImageFilter> input,

        const CropRect& cropRect) {

    if (sigmaX < SK_ScalarNearlyZero && sigmaY < SK_ScalarNearlyZero && !cropRect) {

        return input;

    }

    return sk_sp<SkImageFilter>(

          new SkBlurImageFilter(sigmaX, sigmaY, tileMode, input, cropRect));

}

附上最后的倔强

    constexpr sk_sp() : fPtr(nullptr) {}

    constexpr sk_sp(std::nullptr_t) : fPtr(nullptr) {}



    /**

     *  Shares the underlying object by calling ref(), so that both the argument and the newly

     *  created sk_sp both have a reference to it.

     */

    sk_sp(const sk_sp<T>& that) : fPtr(SkSafeRef(that.get())) {}

    template <typename U,

              typename = typename std::enable_if<std::is_convertible<U*, T*>::value>::type>

    sk_sp(const sk_sp<U>& that) : fPtr(SkSafeRef(that.get())) {}



    /**

     *  Move the underlying object from the argument to the newly created sk_sp. Afterwards only

     *  the new sk_sp will have a reference to the object, and the argument will point to null.

     *  No call to ref() or unref() will be made.

     */

    sk_sp(sk_sp<T>&& that) : fPtr(that.release()) {}

    template <typename U,

              typename = typename std::enable_if<std::is_convertible<U*, T*>::value>::type>

    sk_sp(sk_sp<U>&& that) : fPtr(that.release()) {}



    /**

     *  Adopt the bare pointer into the newly created sk_sp.

     *  No call to ref() or unref() will be made.

     */

    explicit sk_sp(T* obj) : fPtr(obj) {}

createBlurEffect() 得到 long 类型的 native 分配的的非零地址， 传入 new RenderEffect()

🌀 new RenderEffect()

    /* 构造方法：仅从静态工厂方法构造 */

    private RenderEffect(long nativeRenderEffect) {

        mNativeRenderEffect = nativeRenderEffect;

        RenderEffectHolder.RENDER_EFFECT_REGISTRY.registerNativeAllocation(

                this, mNativeRenderEffect);

    }

继续

    /**

      * @param classLoader ClassLoader 类加载器。

      * @param freeFunction 类型为 nativePtr 的本机函数的地址，用于释放这种本机分配

      * @return 由系统内存分配器分配的本机内存的 NativeAllocationRegistry。此版本更适合较小的对象(通常小于几百 KB)。

      */

    private static class RenderEffectHolder {

        public static final NativeAllocationRegistry RENDER_EFFECT_REGISTRY =

                NativeAllocationRegistry.createMalloced(

                        RenderEffect.class.getClassLoader(), nativeGetFinalizer());

    }

🌀 NativeAllocationRegistry.createMalloced()

libcore/luni/src/main/java/libcore/util/NativeAllocationRegistry.java

    @SystemApi(client = MODULE_LIBRARIES)

    public static NativeAllocationRegistry createMalloced(

            @NonNull ClassLoader classLoader, long freeFunction, long size) {

        return new NativeAllocationRegistry(classLoader, freeFunction, size, true);

    }

🌀 NativeAllocationRegistry()

libcore/luni/src/main/java/libcore/util/NativeAllocationRegistry.java

    private NativeAllocationRegistry(ClassLoader classLoader, long freeFunction, long size,

            boolean mallocAllocation) {

        if (size < 0) {

            throw new IllegalArgumentException("Invalid native allocation size: " + size);

        }

        this.classLoader = classLoader;

        this.freeFunction = freeFunction;

        this.size = mallocAllocation ? (size | IS_MALLOCED) : (size & ~IS_MALLOCED);

    }

既然拿到 NativeAllocationRegistry 那就继续调用其
registerNativeAllocation() 方法。

🌀 registerNativeAllocation ()

    @SystemApi(client = MODULE_LIBRARIES)

    @libcore.api.IntraCoreApi

    public @NonNull Runnable registerNativeAllocation(@NonNull Object referent, long nativePtr) {

        //当 referent 或nativePtr 为空

        ...

        CleanerThunk thunk;

        CleanerRunner result;

        try {

            thunk = new CleanerThunk();

            Cleaner cleaner = Cleaner.create(referent, thunk);

            result = new CleanerRunner(cleaner);

            registerNativeAllocation(this.size);

        } catch (VirtualMachineError vme /* probably OutOfMemoryError */) {

            applyFreeFunction(freeFunction, nativePtr);

            throw vme;

        } 

        // Enable the cleaner only after we can no longer throw anything, including OOME.

        thunk.setNativePtr(nativePtr);

        // Ensure that cleaner doesn't get invoked before we enable it.

        Reference.reachabilityFence(referent);

        return result;

    }

向 ART 注册新的 NativePtr 和关联的 Java 对象(也就是咱们设置的模糊类)。

返回的 Runnable 可用于在引用变得无法访问之前释放本机分配。如果运行时或使用 runnable 已经释放了本机分配，则 runnable 将不起作用。

RenderEffect 算是搞完了，咱们回到View.setRenderEffect()

🌀 View.setRenderEffect()

    public void setRenderEffect(@Nullable RenderEffect renderEffect) {

        if (mRenderNode.setRenderEffect(renderEffect)) {

            //视图属性更改（alpha、translationXY 等）的快速失效。

            invalidateViewProperty(true, true);

        }

    }

这里有个 mRenderNode.setRenderEffect(renderEffect)。咱们近距离观望一番。

🌀 mRenderNode 的创建

咱们先找找他是在什么地方创建的。

    public View(Context context) {

        ...

        //在View的构造方法中创建

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

        ...

    }

🌀 RenderNode.create()

    /** @hide */

    public static RenderNode create(String name, @Nullable AnimationHost animationHost) {

        return new RenderNode(name, animationHost);

    }

    

    private RenderNode(String name, AnimationHost animationHost) {

        mNativeRenderNode = nCreate(name);

        //注册 Native Allocation。

        NoImagePreloadHolder.sRegistry.registerNativeAllocation(this, mNativeRenderNode);

        mAnimationHost = animationHost;

    }    

再往下感觉也看不到啥了 跟上面类似，看.cpp动态分配类的地址还是有点懵。让我缓缓~以后补充。

概述

典型的chip是一个圆角的小盒子。它有一个文本标签，并以一种有意义且紧凑的方式显示信息。chip可以在同一区域同时显示多个交互元素。一些流行的chip用例是：

• 发布标签（您可以在许多 WordPress ，VuePress，知乎，掘金，公众号或 GitHub等大型平台上看到它们）。


• 可删除的内容列表（一系列电子邮件联系人、最喜欢的音乐类型列表等）。

在 Flutter 中，您可以使用以下构造函数来实现 Chip 小部件：

Chip({

  Key? key, 

  Widget? avatar, 

  required Widget label, 

  TextStyle? labelStyle, 

  EdgeInsetsGeometry? labelPadding, 

  Widget? deleteIcon, 

  VoidCallback? onDeleted, 

  Color? deleteIconColor, 

  bool useDeleteButtonTooltip = true, 

  String? deleteButtonTooltipMessage, 

  BorderSide? side, 

  OutlinedBorder? shape, 

  Clip clipBehavior = Clip.none, 

  FocusNode? focusNode, 

  bool autofocus = false, 

  Color? backgroundColor, 

  EdgeInsetsGeometry? padding, 

  VisualDensity? visualDensity, 

  MaterialTapTargetSize? materialTapTargetSize, 

  double? elevation, 

  Color? shadowColor

})

只有label属性是必需的，其他是可选的。一些常用的有：

• avatar：在标签前显示一个图标或小图像。


• backgroundColor : chip的背景颜色。


• padding：chip内容周围的填充。


• deleteIcon：让用户删除chip的小部件。


• onDeleted：点击deleteIcon时调用的函数。

您可以在官方文档中找到有关其他属性的更多详细信息。但是，对于大多数应用程序，我们不需要超过一半。

简单示例

这个小例子向您展示了一种同时显示多个chip的简单使用的方法。我们将使用Wrap小部件作为chip列表的父级。当当前行的可用空间用完时，筹码会自动下行。由于Wrap 小部件的间距属性，我们还可以方便地设置chip之间的距离。

截屏：

代码：

Scaffold(

      appBar: AppBar(

        title: const Text('大前端之旅'),

      ),

      body: Padding(

        padding: const EdgeInsets.symmetric(vertical: 30, horizontal: 10),

        child: Wrap(

            // space between chips

            spacing: 10,

            // list of chips

            children: const [

              Chip(

                label: Text('Working'),

                avatar: Icon(

                  Icons.work,

                  color: Colors.red,

                ),

                backgroundColor: Colors.amberAccent,

                padding: EdgeInsets.symmetric(vertical: 5, horizontal: 10),

              ),

              Chip(

                label: Text('Music'),

                avatar: Icon(Icons.headphones),

                backgroundColor: Colors.lightBlueAccent,

                padding: EdgeInsets.symmetric(vertical: 5, horizontal: 10),

              ),

              Chip(

                label: Text('Gaming'),

                avatar: Icon(

                  Icons.gamepad,

                  color: Colors.white,

                ),

                backgroundColor: Colors.pinkAccent,

                padding: EdgeInsets.symmetric(vertical: 5, horizontal: 10),

              ),

              Chip(

                label: Text('Cooking & Eating'),

                avatar: Icon(

                  Icons.restaurant,

                  color: Colors.pink,

                ),

                backgroundColor: Colors.greenAccent,

                padding: EdgeInsets.symmetric(vertical: 5, horizontal: 10),

              )

            ]),

      ),

    );

在这个例子中，chip只呈现信息。在下一个示例中，chip是可交互的。

复杂示例：动态添加和移除筹码

应用预览

我们要构建的应用程序包含一个浮动操作按钮。按下此按钮时，将显示一个对话框，让我们添加一个新chip。可以通过点击与其关联的删除图标来删除每个chip。

以下是应用程序的工作方式：

完整代码

main.dart中的最终代码和解释：

// main.dart

import 'package:flutter/material.dart';



void main() {

  runApp(const MyApp());

}



class MyApp extends StatelessWidget {

  const MyApp({Key? key}) : super(key: key);



  @override

  Widget build(BuildContext context) {

    return MaterialApp(

      debugShowCheckedModeBanner: false,

      title: '大前端之旅',

      theme: ThemeData(

        primarySwatch: Colors.green,

      ),

      home: const HomePage(),

    );

  }

}



// Data model for a chip

class ChipData {

  // an id is useful when deleting chip

  final String id;

  final String name;

  ChipData({required this.id, required this.name});

}



class HomePage extends StatefulWidget {

  const HomePage({Key? key}) : super(key: key);



  @override

  _HomePageState createState() => _HomePageState();

}



class _HomePageState extends State<HomePage> {

  // list of chips

  final List<ChipData> _allChips = [];



  // Text controller (that will be used for the TextField shown in the dialog)

  final TextEditingController _textController = TextEditingController();

  // This function will be triggered when the floating actiong button gets pressed

  void _addNewChip() async {

    await showDialog(

        context: context,

        builder: (_) {

          return AlertDialog(

            title: const Text('添加'),

            content: TextField(

              controller: _textController,

            ),

            actions: [

              ElevatedButton(

                  onPressed: () {

                    setState(() {

                      _allChips.add(ChipData(

                          id: DateTime.now().toString(),

                          name: _textController.text));

                    });



                    // reset the TextField

                    _textController.text = '';



                    // Close the dialog

                    Navigator.of(context).pop();

                  },

                  child: const Text('提交'))

            ],

          );

        });

  }



  // This function will be called when a delete icon associated with a chip is tapped

  void _deleteChip(String id) {

    setState(() {

      _allChips.removeWhere((element) => element.id == id);

    });

  }



  @override

  Widget build(BuildContext context) {

    return Scaffold(

      appBar: AppBar(

        title: const Text('大前端之旅'),

      ),

      body: Padding(

        padding: const EdgeInsets.all(15),

        child: Wrap(

          spacing: 10,

          children: _allChips

              .map((chip) => Chip(

                    key: ValueKey(chip.id),

                    label: Text(chip.name),

                    backgroundColor: Colors.amber.shade200,

                    padding:

                        const EdgeInsets.symmetric(vertical: 7, horizontal: 10),

                    deleteIconColor: Colors.red,

                    onDeleted: () => _deleteChip(chip.id),

                  ))

              .toList(),

        ),

      ),

      floatingActionButton: FloatingActionButton(

        onPressed: _addNewChip,

        child: const Icon(Icons.add),

      ),

    );

  }

}

结论

我们已经探索了 Chip 小部件的许多方面，并经历了不止一个使用该小部件的示例。

大家喜欢的话，点赞支持一下坚果

1. DeepLink 简介

DeepLink:“深度链接”技术，这个名词初看比较抽象，不过在我们身边却有不少应用，比如以下场景：

• 刷抖音看到转转的广告，点击视频下方的下载链接，如果没有安装转转则下载转转，并在打开转转后跳转到相应活动页面


• 在微信看到朋友分享的转转商品，点击后如果没有安装转转则下载转转，并在打开转转跳转到相应商品的详情页


• 看到转转发送的订单提醒短信，点击链接后如果没有安装转转则下载转转, 并在打开转转跳转到相应订单详情页

DeepLink 使用户能够在目标 APP 之外，比如广告（抖音）/社交媒体（微信）/短信中通过点击链接，直接跳转到目标 APP 特定的页面（对于已经安装了 APP 会直接进行跳转，未安装 APP 会引导下载，下载安装完成之后跳转）。DeepLink 技术可以实现场景的快速还原，缩短用户使用路径，更重要的是能够用于 APP 拉新推广场景，降低用户流失率。

随着短视频的风靡，通过短视频投放广告获客的方式也流行起来， 本文主要介绍在新媒体拉新推广场景中 DeepLink 的应用以及服务端的搭建。

2 .应用场景

我在刷抖音时刷到一个转转回收的广告视频，而家里刚好有闲置的手机，我就抱着试一试的态度点击视频下方的下载链接下载转转，看看能不能在这个平台上处理掉手中的闲置，当下载安装成功之后打开跳转到了回收页面，我可能会眉头一挑，嗯~这个体验还挺好，然后测了下闲置手机值多少钱，回收价又刚好满足我的心理预期，而且还能为碳中和贡献一份自己的力量，何乐而不为之。

以上是比较常见的一种场景，通过在抖音、快手或者其他渠道来投放广告来吸引一些有需求的用户来到转转，并通过 DeepLink 技术在下载完成打开转转后直接跳转到用户感兴趣的页面。

对于上述场景安卓和 IOS 的实现是有所区别的，包括下载策略以及 APP 内部跳转到用户感兴趣页面的策略。

2.1 IOS 应用场景

由于 IOS 下载APP只能通过 AppStore，所以 DeepLink 服务针对 IOS 会重定向到一个 H5 中间页，在 H5 中间页将服务端返回的 DeepLink 跳转链接复制到剪切板中，并拉起 AppStore 引导用户下载转转 APP，安装打开后 IOS 从剪切板中获取跳转链接进行跳转，到达用户感兴趣的页面。

2.2 安卓应用场景

安卓可以直接通过 DeepLink 服务下载转转 APP，而 DeepLink 跳转链接以 APK Signature Scheme v2 方式打入 apk 包中，安装打开后解析跳转链接跳转到用户感兴趣的页面。

APK Signature Scheme v2 是 Android 7.0 引入的一项新的应用签名方案 ，它能提供更快的应用安装时间和更多针对未授权 APK 文件更改的保护。

下图是新的签名方案和旧的签名方案的一个对比：

APK Signing Block 结构

APK Signing Block 中的 ID-value 是可扩展的，由于 APK Signing Block 的数据块不会参与签名校验，也就是说我们可以自定义一组 ID-value，用于存储额外的信息，我们通过自定义ID-value将跳转信息打入APK包中。

3. DeepLink 服务

在 IOS DeepLink 方案中服务端只是负责重定向到一个 H5 中间页，因此不再赘述，下面我们主要介绍下安卓的 DeepLink 方案。

3.1 投放链接设计

投放链接是投放到各个渠道的下载链接，需要考虑以下几点：

1. 
   

   各个渠道链接规则不一样，保证我们链接规则能够覆盖所有渠道

   
   

   通过我们的调研有些渠道只支持 Get 请求，有些渠道不允许带参数，有些渠道必须以.apk 进行结尾

   
   


2. 
   

   投放方便，链接投放出去之后不需要再改动

   
   

   由于投放链接是给到一些自媒体创作者，在给出链接之后能够保证从始至终都能下到最新的APP

   
   


3. 
   

   充分利用 CDN

   
   

   转转 APP、找靓机 APP 的包百兆左右，为了保证服务的稳定性同样为了节约带宽，尽量发挥 CDN 的作用把绝大多数请求让 CDN 服务器来进行处理返回

   
   

3.1.1 兼容版本1.0

考虑到兼容各个渠道，某些渠道必须以 apk 结尾、某些渠道不支持Get请求带参数，采用什么方式？

既然不能带参数，那我们的参数信息可以直接拼到path中，参数以某种规则组装，服务端解析，需要的信息包括 APP 类型、渠道信息、DeepLink 链接信息、版本号等，简要设计出的投放链接 1.0 大致如下：

apk.zhuanstatic.com/deeplink/**…

• appType: APP 类型，目前支持转转和找靓机，可扩展，如 zhuanzhuan


• channel：渠道类型，根据每个投放渠道单独设置渠道 id，如 douyin666


• version：APP 版本号，如 9.0.0


• deepLink：deepLink 信息，目前传输 deepLinkId，deepLinkId 和端内跳转链接的映射关系由后台维护，服务端通过映射关系拿到跳转链接打入 apk 包中，如 huishou

3.1.2 升级版本2.0

1.0的版本号是直接写到 path 中的，这会造成很多隐患

1. 可以通过修改版本号恶意下载 APP 的任意版本


2. 保证用户一直下到最新的包需要版本更新之后更新所有投放链接

这显然是不合理的，针对以上两点我们必然需要删掉 version，替代方案可以让服务端在处理下载请求的时候通过其他方式拿到版本信息，修正后的投放链接 2.0 如下：

apk.zhuanstatic.com/deeplink/**…

3.1.3 最终版本3.0

2.0中没有了版本信息进而导致相同的渠道投放链接是一致的，只要 CDN 中有老版本APP的缓存，下载的是缓存的老版本APP，无法获取最新APP

因此我们考虑中间做一次重定向，通过一个不接入 CDN 的固定链接去重定向到一个接入 CDN 的带版本号的链接，这样问题就迎刃而解了，因此投放链接 3.0 应运而生：

apk.zhuanzhuan.com/deeplink/**…

apk.zhuanstatic.com/deeplink/**…

apk.zhuanzhuan.com 不走 CDN，只是将链接中的版本号补全并重定向到走 CDN 的 apk.zhuanstatic.com ，这样在投放链接不变的情况下能保证用户下载到最新的包。

3.2 打包&下载

投放链接设计好之后，通过投放链接可以解析到一些参数信息，比如：
apk.zhuanstatic.com/deeplink/zh…

我们知道用户下载的是douyin666渠道转转9.0.0版本的包，并且APP打开后需要跳转回收的页面。

下载渠道包服务端逻辑主要分为两大块，第一部分是拿到相应版本的原始包，然后通过 APK Signature Scheme v2 方式将渠道号和 DeepLink 跳转链接打入原始包中获得渠道包，将渠道包提供给用户进行下载。

为了能应对 APP 升级和渠道投放带来的流量，尤其是 CDN 中还没有缓存的时候，避免大量请求将我们服务打垮，所以需要引入本地缓存，如何引入？

首先我们分析下服务端的主要逻辑找出不可变的数据，第一原始包肯定是不变的，第二在原始包相同的情况下如果 channel 和 deepLink 跳转链接是一致的，那我们打包出来的渠道包也相应是不可变的，因此我们可以针对这两部分来进行缓存。

接下来我们分析缓存选型以及缓存策略，本地缓存的组件有好多可选的，比如 Caffeine Cache、Guava Cache 等，网上关于他们的测评如下：

可以看到在读场景下，caffeine cache 是当之无愧的王者，而且我们的场景基本是接近 100%的读，所以我们优先选择了 Caffeine Cache。

以下是两个本地缓存策略介绍：

3.2.1 一级缓存（渠道包）

     /**

     * 缓存高频渠道包文件

     */

    private static final Cache<String, byte[]> channelFinalAppCache = CacheBuilder

            .newBuilder()

            .expireAfterAccess(1, TimeUnit.DAYS)

            .maximumSize(15)

            .build();

渠道包的缓存 key 是 appType+version+channel+deepLink,由于 channel 和 deepLink 组合的众多，通过分析之前的下载数据缓存最高频的 15 个渠道包就基本满足 90%以上的请求而且不至于占用太多的内存，而为了获取最高频的 15 个渠道，我们通过大数据平台以 T+1 的方式将渠道数据更新到数据库中，DeepLink服务通过定时任务读取数据库中的渠道数据刷新缓存。

3.2.2 二级缓存（原始包）

    /**

     * 缓存原始包文件

     */

    private static final Cache<String, byte[]> channelAppCache = CacheBuilder

            .newBuilder()

            .expireAfterAccess(2, TimeUnit.DAYS)

            .maximumSize(10)

            .build();

原始包的缓存 key 是 appType+version,由于我们只下载最新版本的包， APP 类型暂时只有转转和找靓机，所有我们设置最大数量 10 是足够的，在我们应用启动的时候会对这个缓存进行初始化，以避免第一次用户下载速度过慢，并在之后监听APP的发版信息，新版本更新后刷新缓存。

4. 总结

DeepLink 服务支撑了新媒体投放以及 APP 内置更新的下载能力，为了保证服务稳定性和性能，除上述缓存策略外，还有其他策略来协同，比如 APP 发新版本时会进行 CDN 预热，将下载量高的渠道包缓存到 CDN 中，以使大部分流量能够在 CDN 服务器被消化，即使有突发流量打过来也会有限流规则过滤流量以保证服务的稳定性。

最初的retrofit请求

我们先看下原来如何通过retrofit发起一个网络请求的，这里我们直接以官网的例子举例：

动态代理创建请求服务

interface GitHubService {

    //创建get请求方法

    @GET("users/{user}/repos")

    fun listRepos(@Path("user") user: String?): Call<Response>

}



//动态代理创建GitHubService

fun createService(): GitHubService {

    val retrofit = Retrofit.Builder()

        .baseUrl("https://api.github.com/")

        .build()



    return retrofit.create(GitHubService::class.java)

}

• 
  

  retrofit.create底层是通过动态代理创建的GitHubService的一个子实现类；

  
  


• 
  

  创建的这个GitHubService一般作为单例进行使用，这里只是简单举例没有实现单例；

  
  

发起网络请求

fun main() {

    //异步执行网络请求

    createService().listRepos("").enqueue(object : Callback<Response> {

        override fun onResponse(call: Call<Response>, response: retrofit2.Response<Response>) {

            //主线程网络请求成功回调

        }



        override fun onFailure(call: Call<Response>, t: Throwable) {

            //主线程网络请求失败回调

        }

    })

}

这种调用enqueue()异步方法并执行callback的方式是不是感觉很麻烦，如果有下一个请求依赖上一个请求的执行结果，那就将会形成回调地狱这种可怕场景。

而协程suspend本就有着以同步代码编写执行异步操作的能力，所以天然是解决回调地狱好帮手。接下来我们看下如何使用协程suspend。

借助suspend发起网络请求

suspend声明接口方法

interface GitHubService {

    @GET("users/{user}/repos")

    suspend fun listRepos(@Path("user") user: String?): Response<String>

}

可以看到就是在listRepos方法声明前加了个suspend关键字就完了。

创建协程执行网络请求

fun main() {

    //1.创建协程作用域，需要保证协程的调度器是分发到主线程执行

    val scope = MainScope()

    scope.launch(CoroutineExceptionHandler { _, _ ->

        //2.捕捉请求异常

    }) {

        //3.异步执行网络请求

        val result = createService().listRepos("")

        

        val content = result.body()?

    }

}

1. 
   

   首先创建一个协程作用域，需要保证协程调度器类型为Dispatchers.Main，这样整个协程的代码块都会默认在主线程中执行，我们就可以直接在里面执行UI相关操作

   
   


2. 
   

   创建一个CoroutineExceptionHandler捕捉协程执行过程中出现的异常，这个捕捉异常的粒度比较大，是捕捉整个协程块的异常，可以考虑使用try-catch专门捕获网络请求执行的异常：

   
   

   //异步执行网络请求
   
   try {
   
       val result = createService().listRepos("")
   
   } catch (e: Exception) {
   
       //可以考虑执行重连等逻辑或者释放资源
   
   }
   

   
   


3. 
   

   直接调用listRepos()方法即可，不需要传入任何回调，并直接返回方法结果。这样我们就实现了以同步的代码实现了异步网络请求。

   
   

接下来我们就看下如何retrofit源码是如何实现这一效果的。

retrofit如何适配suspend

直接定位到HttpServiceMethod.parseAnnotations()方法：

static <ResponseT, ReturnT> HttpServiceMethod<ResponseT, ReturnT> parseAnnotations(

    Retrofit retrofit, Method method, RequestFactory requestFactory) {

  //1.判断是否为suspend挂起方法

  boolean isKotlinSuspendFunction = requestFactory.isKotlinSuspendFunction;



  //省略一堆和当前分析主题不想关的代码



  if (!isKotlinSuspendFunction) {

    return new CallAdapted<>(requestFactory, callFactory, responseConverter, callAdapter);

  } else if (continuationWantsResponse) {

    //挂起执行

    return (HttpServiceMethod<ResponseT, ReturnT>) new SuspendForResponse<>();

  } else {

    //挂起执行

    return (HttpServiceMethod<ResponseT, ReturnT>) new SuspendForBody<>();

  }

}

1.判断是否为suspend挂起方法

看下requestFactory.isKotlinSuspendFunction赋值的地方，经过一番查找（省略...），最终方法在RequestFactory的parseParameter间接赋值：

private @Nullable ParameterHandler<?> parseParameter() {

//...

    //1.是否是方法最后一个参数

    if (allowContinuation) {

      try {

        if (Utils.getRawType(parameterType) == Continuation.class) {

          //2.标识为suspend挂起方法

          isKotlinSuspendFunction = true;

          return null;

        }

      } catch (NoClassDefFoundError ignored) {

      }

    }

}

如果一个方法被声明为suspend，该方法翻译成java代码就会给该方法添加一个Continuation类型的参数，并且放到方法参数的最后一个位置，比如：

private suspend fun test66(name: String) {  

}

会被翻译成：

private final Object test66(String name, Continuation $completion) {

   return Unit.INSTANCE;

}

所以上面的代码就可以判断出请求的接口方法是否被suspend声明，是isKotlinSuspendFunction将会被置为true。

2.挂起则创建SuspendForResponse或SuspendForBody

这个地方我们以SuspendForBody进行分析，最终会执行到其adapt()方法：

@Override

protected Object adapt(Call<ResponseT> call, Object[] args) {

  call = callAdapter.adapt(call);

  //1.获取参数

  Continuation<ResponseT> continuation = (Continuation<ResponseT>) args[args.length - 1];

  

  try {

    return isNullable

        ? KotlinExtensions.awaitNullable(call, continuation)

        //2.调用真正的挂起方法

        : KotlinExtensions.await(call, continuation);

  } catch (Exception e) {

    return KotlinExtensions.suspendAndThrow(e, continuation);

  }

}

1. 
   

   获取调用的suspend声明的接口方法中获取最后一个Continuation类型参数

   
   


2. 
   

   调用await方法，由于这是一个kotlin定义的接收者为Call的挂起方法，如果在java中调用，首先第一个参数要传入接收者，也就是call，其实await()是一个挂起方法，翻译成java还会增加一个Continuation类型参数，所以调用await()还要传入第一步获取的Continuation类型参数。

   
   

3.核心调用await()方法探究

await()就是retrofit适配suspend实现同步代码写异步请求的关键，也是消除回调地狱的关键：

suspend fun <T : Any> Call<T>.await(): T {

  return suspendCancellableCoroutine { continuation ->

    continuation.invokeOnCancellation {

      cancel()

    }

    enqueue(object : Callback<T> {

      override fun onResponse(call: Call<T>, response: Response<T>) {

        if (response.isSuccessful) {

          val body = response.body()

          if (body == null) {

              //关键

            continuation.resumeWithException(KotlinNullPointerException())

          } else {

              //关键

            continuation.resume(body)

          }

        } else {

            //关键

          continuation.resumeWithException(HttpException(response))

        }

      }



      override fun onFailure(call: Call<T>, t: Throwable) {

          //关键

        continuation.resumeWithException(t)

      }

    })

  }

}

使用到了协程的一个非常关键的方法suspendCancellableCoroutine{}，该方法就是用来捕获传入的Continuation并决定什么恢复挂起的协程执行的，比如官方的delay()方法也是借助该方法实现的。

所以当我们执行调用enqueue()方法时在网络请求没有响应(成功或失败)前，协程一直处于挂起的状态，之后收到网络响应后，才会调用resume()或resumeWithException()恢复挂起协程的执行，这样我们就实现了同步代码实现异步请求的操作，而不需要任何的callback嵌套地狱。

总结

本篇文章详细分析retrofit如何适配suspend协程的，并且不用编写任何的callback回调，直接以同步代码编写实现异步请求的操作。

业务背景：

在条件允许的情况下（无 SIM 卡的手机，无法触发一键登录），通过运行商提供的服务，进行【一键登录】。简化用户的登录操作，提高 App 的登录注册率以及使用率。

本方案采用的是阿里云中【一键登录】方案。

效果图：

前提知识：

• 整个流程如图所

（图源自网络[掘金大佬-NanBox]，侵删）

• 该方案下，不允许使用完全自定义的授权页。但是可以通过属性配置，进行一定的修改。可修改的属性如下图所示

Android 接入流程：

1.浅析 Demo

通常第一步都是下载官方 Demo 后，进行一番调试，盘点功能列表，是否符合自身需求。

链接：pan.baidu.com/s/1RX5yGp06… 提取码：qbx0

接下来，简单分析 Demo 项目架构，帮助大家尽快上手这个项目。

首先，我们要知道这个 Demo，是包括【一键登录】和【本机号码校验】两个功能。根据自己的需求分析对应的代码即可。这次我们只使用到前者，所以后者内容不在这里讲述。

主要看到下列三个模块：

Config - 就是上面预告知识中说到的配置项，主要是授权页的一些配置项

OneKeyLoginActivity - 登录页面

MessageActivity - 模拟【其他登录方式】页面

那具体的实现，就可以直接看对应模块的内容即可。可以在原 Demo，进行调试。

2.接入思路分析

基于判断是否支持【一键登录】的时机 提供两种接入思路

第一种：启动登录功能前判断

判断的方式可以通过

mPhoneNumberAuthHelper.checkEnvAvailable(PhoneNumberAuthHelper.SERVICE_TYPE_LOGIN)

复制代码

是否支持【一键登录】。该流程未经检验，大家可以执行验证。

第二种：直接唤起【一键登录】，失败后再唤起【其他登录方式】

Demo 也是第二种方式。这种方式需要用到一个壳 Activity 。但这个壳主要的作用是初始化SDK，以及做逻辑判断和处理（即并无实际内容展示）。

这里引发一个思考：

既然用不到 Activity 的内容，那能不能换种方式呢呢？对于单例，我思考后，一开始觉得是没问题的，但是等写完后，发现我写成了一个 OneKeyLoginHelper 的单例，发现相应逻辑处理需要传入 activity 或者 fragment 的引用。那么我们知道单例中是不能持有这样的引用的（这里可以考虑使用弱引用），这会导致内容泄漏。不知道是否还有其他的方法？

3.代码接入流程

//STEP 1.初始化监听器(这里根据业务自己做处理)

//STEP 2.初始化SDK实例

//STEP 3.设置SDK秘钥

//STEP 4.唤起一键登录页

4.避坑

接着，讲一下接入过程中，遇到的一些问题。帮大家避免无效劳动，可以有更多的时间学（hua ）习（shui）。

问题描述： 因为选择了第二种思路，那么会有个壳 Activity 的问题。这个壳，我们不处理的话，是不透明的，这样当我们进到这个壳的时候，再跳转到别的页面就会有个空白页。

解决方案： 将壳的主题改为透明色，经过实验，下述代码可以实现。（壳Activity 需要继承 AppCompatActivity）

<style name="Theme.Transparent" parent="@style/Theme.AppCompat.DayNight.NoActionBar">

    <item name="android:windowBackground">@android:color/transparent</item>

    <item name="android:windowNoTitle">true</item>

    <item name="android:windowIsFloating">true</item>

    <item name="android:windowIsTranslucent">true</item>

    <item name="android:windowContentOverlay">@null</item>

    <item name="android:backgroundDimEnabled">false</item>

</style>

问题描述： 发现从【授权页】跳到【其他方式登录】的时候，授权页会逐渐变透明，会看到下一层页面的内容。如动图中，粉红色的箭头所示。

解决方案： 可以直接忽略，这个是 SDK 本身的问题。因为阿里那边给的回复是：（是否有最新解决方案，会及时更新，或者可以以你们当时咨询的为准）

目录

0. 注释


1. 函数式接口


2. 高阶函数


3. 扩展函数

注释

Java：

    /**

     * @see AdVideoUserInfoContainerData#type

     */

    public Builder type(int type) {

        userInfoData.type = type;

        return this;

    }

    /** 事件配置, 对应于 {@link FeedAdLottieRepoInfo#name 属性} */

    public String lottieConfig;

Kotlin：

/**

 * 由[CountDownType.type] mapTo [CountDownType]

 * 避免了使用 when(type) 写 else 了

 */

private fun type2Enum(type: () -> String): CountDownType {

    return CountDownType.values().firstOrNull {

        it.type == type()

    } ?: CountDownType.CIRCLE

}

Kotlin 可以使用内联标记来引用类、方法、属性等，这比 Java 中的 @see、@link 更加易用。

文档：kotlinlang.org/docs/kotlin…

函数式接口

非函数式接口：

internal interface ICountDownCallback {

    /**

     * 倒计时完成时回调

     */

    fun finish()

}



internal fun setCountDownCallback(callback: ICountDownCallback) {

    // ignore

}



internal fun show() {

    setCountDownCallback(object : ICountDownCallback {

        override fun finish() {

            TODO("Not yet implemented")

        }

    })

}

函数式接口：

internal fun interface ICountDownCallback {

    /**

     * 倒计时完成时回调

     */

    fun finish()

}



internal fun setCountDownCallback(callback: ICountDownCallback) {

    // ignore

}



internal fun show() {

    setCountDownCallback { 

        TODO("Not yet implemented")

    }

}

函数式接口也被称为单一抽象方法（SAM）接口，使用函数式接口可以使代码更加简洁，富有表现力。

对于 Java 的接口，比如 View.OnClickListener，它在使用的时候可以直接转 lambda 使用的，只有是 kotlin 的单一抽象方法，需要加 fun 关键字标示它为函数式接口。

文档：kotlinlang.org/docs/fun-in…

高阶函数

如果对象的初始化比较麻烦，可以使用高阶函数，让代码更加流畅：

    // 定义

    open fun attachToViewGroup(

        viewGroup: ViewGroup,

        index: Int = -1,

        lp: () -> MarginLayoutParams = {

            MarginLayoutParams(

                LayoutParams.WRAP_CONTENT,

                LayoutParams.WRAP_CONTENT

            )

        }

    ) {

        (this.parent as? ViewGroup)?.removeView(this)

        viewGroup.addView(this, lp.invoke())

    }



    // 使用

    override fun attachToViewGroup(viewGroup: ViewGroup, index: Int, lp: () -> MarginLayoutParams) {

        super.attachToViewGroup(viewGroup, index) {

            MarginLayoutParams(

                ViewGroup.LayoutParams.WRAP_CONTENT,

                ViewGroup.LayoutParams.WRAP_CONTENT

            ).apply {

                leftMargin = 14.px(context)

                topMargin = 44.px(context)

            }

        }

    }

如果参数的获取比较复杂，代码比较长，有不少判断逻辑，也可以使用高阶函数：

// 定义

fun getCountDownViewByType(context: Context, type: () -> String = { "0" }) {

    // ignore

}

// 使用

countDownView = CountDownType.getCountDownViewByType(this) {

    rewardVideoCmdData.cmdPolicyData?.countDownType ?: ""

}

如果方法的返回值是一个状态值，然后根据状态值去做相关逻辑处理。这种情况下，其实我们想要的是一个行为，比如代码中充斥着大量的数据解析、校验等逻辑，我们也可以是使用高阶函数重构：

// 重构之前

/**

 * 校验数据有效（校验标题和按钮有一个不为空，就可以展示 Dialog）

 */

fun checkValid(): Boolean {

    return !dialogTitle.isNullOrEmpty() || !buttonList.isNullOrEmpty()

}



private fun bindData() {

    rewardData = RewardDialogData(arguments?.getString(EXTRA_REWARD_DATA) ?: "")

    // 弹窗数据不合法，就不需要展示 dialog 了

    if (rewardData == null || !rewardData!!.checkValid()) {

        dismiss()

        return

    }

    // 更新字体颜色等

    updateSkin()

}



 

// 重构之后

/**

 * 数据校验失败，执行 [fail] 函数

 */

internal inline fun RewardDialogData?.checkFailed(fail: () -> Unit) {

    this?.let {

        if (dialogTitle.isNullOrEmpty() && buttonList.isNullOrEmpty()) {

            fail()

        }

    } ?: fail()

}

 



private fun bindData() {

    rewardData = RewardDialogData(arguments?.getString(EXTRA_REWARD_DATA) ?: "")

    // 弹窗数据不合法，就不需要展示 dialog 了

    rewardData?.checkFailed {

        dismiss()

        return

    }

    // 更新字体颜色等

    updateSkin()

}

kotlin 标准库里面也是有非常多的高阶函数的，比如作用域函数（let、apply、run等等），除此之外，还有一些集合类的标准库函数：

// filter

fun showCharge() {

    adMonitorUrl?.filter {

        !it.showUrl.isNullOrEmpty()

    }?.forEach {

        ParallelCharge.charge(it.showUrl)

    }

}

// forEachIndexed

list.forEachIndexed { index, i ->

    // ignore

}

文档：kotlinlang.org/docs/lambda…

扩展函数

// 比较不流畅的写法

val topImgUrl = rewardData?.topImg

if (topImgUrl.isNullOrBlank()) {

    topImg.visibility = View.GONE

} else {

    topImg.hierarchy?.useGlobalColorFilter = false

    topImg.visibility = View.VISIBLE

    topImg.setImageURI(topImgUrl)

}

// 使用局部返回标签

topImg.apply {

    if (topImgUrl.isNullOrEmpty()) {

        visibility = View.GONE

        return@apply

    }

    hierarchy?.useGlobalColorFilter = false

    setImageURI(topImgUrl)

    visibility = View.VISIBLE

}

/**

 * 校验 View 可见性

 *

 * @return [predicate] false: GONE；true: VISIBLE

 */

internal inline fun <reified T : View> T.checkVisible(predicate: () -> Boolean): T? {

    return if (predicate()) {

        visibility = View.VISIBLE

        this

    } else {

        visibility = View.GONE

        null

    }

}



// 使用扩展函数

topImg.checkVisible {

    !topImgUrl.isNullOrEmpty()

}?.run {

    hierarchy?.useGlobalColorFilter = false

    setImageURI(topImgUrl)

}

背景

昨天一个我高中的女同桌突然发微信问我“你是不是程序猿 我有问题求助”，

先是激动后是茫然再是冷静，毕业多年不见联系，突然发个信息求助，感觉大脑有点反应不过来... 再说我一个搞Android的也不咋会python啊（不是说Java不能实现，大家懂的，人生苦短，我用python），即使如此，
为了大家的面子，为了程序猿们的脸，不就简单的小Python嘛，必须答应！

梳理需求

现有excel表格记录着 有效图片的名字，如：

要从一个文件夹里把excel表格里记录名字的图片筛选出来；

需求也不是很难，代码思路就有了：

1. 读取Excel表格第一列的信息并放入A集合


2. 遍历文件夹下所有的文件，判断文件名字是否存在A集合


3. 存在A集合则拷贝到目标文件夹

实现（Python 2.7）

读取Excel表格

加载Excel表格的方法有很多种，例如pandas、xlrd、openpyxl，我这里选择openpyxl库，
先安装库

pip install openpyxl

代码如下：

from openpyxl import load_workbook



def handler_excel(filename=r'C:/Users/xxx/Desktop/haha.xlsx'):

    # 根据文件路径加载一个excel表格，这里包含所有的sheet

    excel = load_workbook(filename)

    # 根据sheet名称加载对应的table

    table = excel.get_sheet_by_name('Sheet1')

    imgnames = []

    # 读取所有列 

    for column in table.columns:

        for cell in column:

            imgnames.append(cell.value+".png")

    # 选择图片

    pickImg(imgnames)

遍历文件夹读取文件名，找到target并拷贝

使用os.listdir 方法遍历文件，这里注意windows环境下拿到的unicode编码，需要GBK重新解码

def pickImg(pickImageNames):

    # 遍历所有图片集的文件名

    for image in os.listdir(

            r"C:\Users\xxx\Desktop\work\img"):

        # 使用gbk解码，不然中文乱码

        u_file = image.decode('gbk')

        print(u_file)

        if u_file in pickImageNames:

            oldname = r"C:\Users\xxx\Desktop\work\img/" + image

            newname = r"C:\Users\xxx\Desktop\work\target/" + image

            # 文件拷贝

            shutil.copyfile(oldname, newname)

简单搞定！没有砸程序猿的招牌，豪横的把成果发给女同桌，结果：

换来有机会请你吃饭，微信都不带回的，哎 ，xdm，小丑竟是我自己！

Kotlin协程不是什么空中阁楼，Kotlin源代码会被编译成class字节码文件，最终会运行到虚拟机中。所以从本质上讲，Kotlin和Java是类似的，都是可以编译产生class的语言，但最终还是会受到虚拟机的限制，它们的代码最终会在虚拟机上的某个线程上被执行。

之前我们分析了launch的原理，但当时我们没有去分析协程创建出来后是如何与线程产生关联的，怎么被分发到具体的线程上执行的，本篇文章就带大家分析一下。

前置知识

要想搞懂Dispatchers，我们先来看一下Dispatchers、CoroutineDispatcher、ContinuationInterceptor、CoroutineContext之间的关系

public actual object Dispatchers {

    @JvmStatic

    public actual val Default: CoroutineDispatcher = DefaultScheduler

    

    @JvmStatic

    public actual val Main: MainCoroutineDispatcher get() = MainDispatcherLoader.dispatcher

    

    @JvmStatic

    public actual val Unconfined: CoroutineDispatcher = kotlinx.coroutines.Unconfined

    

    @JvmStatic

    public val IO: CoroutineDispatcher = DefaultIoScheduler

}



public abstract class CoroutineDispatcher :

    AbstractCoroutineContextElement(ContinuationInterceptor), ContinuationInterceptor {

}



public interface ContinuationInterceptor : CoroutineContext.Element {}



public interface Element : CoroutineContext {}

Dispatchers中存放的是协程调度器（它本身是一个单例），有我们平时常用的IO、Default、Main等。这些协程调度器都是CoroutineDispatcher的子类，这些协程调度器其实都是CoroutineContext。

demo

我们先来看一个关于launch的demo：

fun main() {

    val coroutineScope = CoroutineScope(Job())

    coroutineScope.launch {

        println("Thread : ${Thread.currentThread().name}")

    }

    Thread.sleep(5000L)

}

在生成CoroutineScope时，demo中没有传入相关的协程调度器，也就是Dispatchers。那这个launch会运行到哪个线程之上？

运行试一下：

Thread : DefaultDispatcher-worker-1

居然运行到了DefaultDispatcher-worker-1线程上，这看起来明显是Dispatchers.Default协程调度器里面的线程。我明明没传Dispatchers相关的context，居然会运行到子线程上。说明运行到default线程是launch默认的。

它是怎么与default线程产生关联的？打开源码一探究竟：

public fun CoroutineScope.launch(

    context: CoroutineContext = EmptyCoroutineContext,

    start: CoroutineStart = CoroutineStart.DEFAULT,

    block: suspend CoroutineScope.() -> Unit

): Job {

    //代码1

    val newContext = newCoroutineContext(context)

    

    //代码2

    val coroutine = if (start.isLazy)

        LazyStandaloneCoroutine(newContext, block) else

        StandaloneCoroutine(newContext, active = true)

    

    //代码3

    coroutine.start(start, coroutine, block)

    return coroutine

}

1. 将传入的CoroutineContext构造出新的context


2. 启动模式，判断是否为懒加载，如果是懒加载则构建懒加载协程对象，否则就是标准的


3. 启动协程

我们重点关注代码1，这是与CoroutineContext相关的。

public actual fun CoroutineScope.newCoroutineContext(context: CoroutineContext): CoroutineContext {

    //从父协程那里继承过来的context+这次的context

    val combined = coroutineContext.foldCopiesForChildCoroutine() + context

    val debug = if (DEBUG) combined + CoroutineId(COROUTINE_ID.incrementAndGet()) else combined

    //combined可以简单的把它看成是一个map，它是CoroutineContext类型的

    //如果当前context不等于Dispatchers.Default，而且从map里面取ContinuationInterceptor（用于拦截之后分发线程的）值为空，说明没有传入协程应该在哪个线程上运行的相关参数

    return if (combined !== Dispatchers.Default && combined[ContinuationInterceptor] == null)

        debug + Dispatchers.Default else debug

}

调用launch的时候，我们没有传入context，默认参数是EmptyCoroutineContext。这里的combined，它其实是CoroutineContext类型的，可以简单的看成是map（其实不是，只是类似）。通过combined[ContinuationInterceptor]可以将传入的线程调度相关的参数给取出来，这里如果取出来为空，是给该context添加了一个Dispatchers.Default，然后把新的context返回出去了。所以launch默认情况下，会走到default线程去执行。

补充一点：CoroutineContext能够通过+连接是因为它内部有个public operator fun plus函数。能够通过combined[ContinuationInterceptor]这种方式访问元素是因为有个public operator fun get函数。

public interface CoroutineContext {

     /**

     * Returns the element with the given [key] from this context or `null`.

     */

    public operator fun <E : Element> get(key: Key<E>): E?

    

     /**

     * Returns a context containing elements from this context and elements from  other [context].

     * The elements from this context with the same key as in the other one are dropped.

     */

    public operator fun plus(context: CoroutineContext): CoroutineContext {

        ......

    }

}

startCoroutineCancellable

上面我们分析了launch默认情况下，context中会增加Dispatchers.Default的这个协程调度器，到时launch的Lambda会在default线程上执行，其中具体流程是怎么样的，我们分析一下。

在之前的文章 Kotlin协程之launch原理 中我们分析过，launch默认情况下会最终执行到startCoroutineCancellable函数。

public fun <T> (suspend () -> T).startCoroutineCancellable(completion: Continuation<T>): Unit = runSafely(completion) {

    //构建ContinuationImpl

    createCoroutineUnintercepted(completion).intercepted().resumeCancellableWith(Result.success(Unit))

}



public actual fun <T> (suspend () -> T).createCoroutineUnintercepted(

    completion: Continuation<T>

): Continuation<Unit> {

    val probeCompletion = probeCoroutineCreated(completion)

    return if (this is BaseContinuationImpl)

        //走这里

        create(probeCompletion)

    else

        createCoroutineFromSuspendFunction(probeCompletion) {

            (this as Function1<Continuation<T>, Any?>).invoke(it)

        }

}

在Kotlin协程之launch原理 文章中，咱们分析过create(probeCompletion)这里创建出来的是launch的那个Lambda，编译器会产生一个匿名内部类，它继承自SuspendLambda，而SuspendLambda是继承自ContinuationImpl。所以 createCoroutineUnintercepted(completion)一开始构建出来的是一个ContinuationImpl，接下来需要去看它的intercepted()函数。

internal abstract class ContinuationImpl(

    completion: Continuation<Any?>?,

    private val _context: CoroutineContext?

) : BaseContinuationImpl(completion) {

    constructor(completion: Continuation<Any?>?) : this(completion, completion?.context)



    public override val context: CoroutineContext

        get() = _context!!



    @Transient

    private var intercepted: Continuation<Any?>? = null



    public fun intercepted(): Continuation<Any?> =

        intercepted

            ?: (context[ContinuationInterceptor]?.interceptContinuation(this) ?: this)

                .also { intercepted = it }

}

第一次走到intercepted()函数时，intercepted肯定是为null的，还没初始化。此时会通过context[ContinuationInterceptor]取出Dispatcher对象，然后调用该Dispatcher对象的interceptContinuation()函数。这个Dispatcher对象在demo这里其实就是Dispatchers.Default。

public actual object Dispatchers {

    @JvmStatic

    public actual val Default: CoroutineDispatcher = DefaultScheduler

}

可以看到，Dispatchers.Default是一个CoroutineDispatcher对象，interceptContinuation()函数就在CoroutineDispatcher中。

public abstract class CoroutineDispatcher :

    AbstractCoroutineContextElement(ContinuationInterceptor), ContinuationInterceptor {

    public final override fun <T> interceptContinuation(continuation: Continuation<T>): Continuation<T> =

        DispatchedContinuation(this, continuation)

}



public fun <T> (suspend () -> T).startCoroutineCancellable(completion: Continuation<T>): Unit = runSafely(completion) {

    createCoroutineUnintercepted(completion).intercepted().resumeCancellableWith(Result.success(Unit))

}

这个方法非常简单，就是新建并且返回了一个DispatchedContinuation对象，将this和continuation给传入进去。这里的this是Dispatchers.Default。

所以，最终我们发现走完startCoroutineCancellable的前2步之后，也就是走完intercepted()之后，创建的是DispatchedContinuation对象，最后是调用的DispatchedContinuation的resumeCancellableWith函数。最后这步比较关键，这是真正将协程的具体执行逻辑放到线程上执行的部分。

internal class DispatchedContinuation<in T>(

    //这里传入的dispatcher在demo中是Dispatchers.Default

    @JvmField val dispatcher: CoroutineDispatcher,

    @JvmField val continuation: Continuation<T>

) : DispatchedTask<T>(MODE_UNINITIALIZED), CoroutineStackFrame, Continuation<T> by continuation {



    inline fun resumeCancellableWith(

        result: Result<T>,

        noinline onCancellation: ((cause: Throwable) -> Unit)?

    ) {

        val state = result.toState(onCancellation)

        //代码1

        if (dispatcher.isDispatchNeeded(context)) {

            _state = state

            resumeMode = MODE_CANCELLABLE

            //代码2

            dispatcher.dispatch(context, this)

        } else {

            //代码3

            executeUnconfined(state, MODE_CANCELLABLE) {

                if (!resumeCancelled(state)) {

                    resumeUndispatchedWith(result)

                }

            }

        }

    }

}



internal abstract class DispatchedTask<in T>(

    @JvmField public var resumeMode: Int

) : SchedulerTask() {

    ......

}



internal actual typealias SchedulerTask = Task



internal abstract class Task(

    @JvmField var submissionTime: Long,

    @JvmField var taskContext: TaskContext

) : Runnable {

    ......

}



public abstract class CoroutineDispatcher :

    AbstractCoroutineContextElement(ContinuationInterceptor), ContinuationInterceptor {

    

    public abstract fun dispatch(context: CoroutineContext, block: Runnable)

    

    public open fun isDispatchNeeded(context: CoroutineContext): Boolean = true

    

}

从DispatchedContinuation的继承结构来看，它既是一个Continuation（通过委托给传入的continuation参数），也是一个Runnable。

• 首先看代码1：这个dispatcher在demo中其实是Dispatchers.Default ，然后调用它的isDispatchNeeded(),这个函数定义在CoroutineDispatcher中，默认就是返回true，只有Dispatchers.Unconfined返回false


• 代码2：调用Dispatchers.Default的dispatch函数，将context和自己（DispatchedContinuation,也就是Runnable）传过去了


• 代码3：对应Dispatchers.Unconfined的情况，它的isDispatchNeeded()返回false

现在我们要分析代码2之后的执行逻辑，也就是将context和Runnable传入到dispatch函数之后是怎么执行的。按道理，看到Runnable，那可能这个与线程执行相关，应该离我们想要的答案不远了。回到Dispatchers，我们发现Dispatchers.Default是DefaultScheduler类型的，那我们就去DefaultScheduler中或者其父类中去找dispatch函数。

public actual object Dispatchers {

    @JvmStatic

    public actual val Default: CoroutineDispatcher = DefaultScheduler

}



internal object DefaultScheduler : SchedulerCoroutineDispatcher(

    CORE_POOL_SIZE, MAX_POOL_SIZE,

    IDLE_WORKER_KEEP_ALIVE_NS, DEFAULT_SCHEDULER_NAME

) {

    ......

}



internal open class SchedulerCoroutineDispatcher(

    private val corePoolSize: Int = CORE_POOL_SIZE,

    private val maxPoolSize: Int = MAX_POOL_SIZE,

    private val idleWorkerKeepAliveNs: Long = IDLE_WORKER_KEEP_ALIVE_NS,

    private val schedulerName: String = "CoroutineScheduler",

) : ExecutorCoroutineDispatcher() {



    private var coroutineScheduler = createScheduler()



    private fun createScheduler() =

        CoroutineScheduler(corePoolSize, maxPoolSize, idleWorkerKeepAliveNs, schedulerName)



     override fun dispatch(context: CoroutineContext, block: Runnable): Unit = coroutineScheduler.dispatch(block)

}

最后发现dispatch函数在其父类SchedulerCoroutineDispatcher中，在这里构建了一个CoroutineScheduler，直接调用了CoroutineScheduler对象的dispatch，然后将Runnable（也就是上面的DispatchedContinuation对象）传入。

internal class CoroutineScheduler(

    @JvmField val corePoolSize: Int,

    @JvmField val maxPoolSize: Int,

    @JvmField val idleWorkerKeepAliveNs: Long = IDLE_WORKER_KEEP_ALIVE_NS,

    @JvmField val schedulerName: String = DEFAULT_SCHEDULER_NAME

) : Executor, Closeable {

    override fun execute(command: Runnable) = dispatch(command)

    

    fun dispatch(block: Runnable, taskContext: TaskContext = NonBlockingContext, tailDispatch: Boolean = false) {

        trackTask() // this is needed for virtual time support

        //代码1：构建Task，Task实现了Runnable接口

        val task = createTask(block, taskContext)

        //代码2：取当前线程转为Worker对象,Worker是一个继承自Thread的类

        val currentWorker = currentWorker()

        //代码3：尝试将Task提交到本地队列并根据结果执行相应的操作

        val notAdded = currentWorker.submitToLocalQueue(task, tailDispatch)

        if (notAdded != null) {

            //代码4：notAdded不为null，则再将notAdded（Task）添加到全局队列中

            if (!addToGlobalQueue(notAdded)) {

                throw RejectedExecutionException("$schedulerName was terminated")

            }

        }

        val skipUnpark = tailDispatch && currentWorker != null

        // Checking 'task' instead of 'notAdded' is completely okay

        if (task.mode == TASK_NON_BLOCKING) {

            if (skipUnpark) return

            //代码5: 创建Worker并开始执行该线程

            signalCpuWork()

        } else {

            // Increment blocking tasks anyway

            signalBlockingWork(skipUnpark = skipUnpark)

        }

    }

    

    private fun currentWorker(): Worker? = (Thread.currentThread() as? Worker)?.takeIf { it.scheduler == this }

    

    internal inner class Worker private constructor() : Thread() {

        .....

    }

}

观察发现，原来CoroutineScheduler类实现了java.util.concurrent.Executor接口，同时实现了它的execute方法，这个方法也会调用dispatch()。

• 代码1：首先是通过Runnable构建了一个Task，这个Task其实也是实现了Runnable接口，只是把传入的Runnable包装了一下


• 代码2：将当前线程取出来转换成Worker，当然第一次时，这个转换不会成功，这个Worker是继承自Thread的一个类


• 代码3：将task提交到本地队列中，这个本地队列待会儿会在Worker这个线程执行时取出Task，并执行Task


• 代码4：如果task提交到本地队列的过程中没有成功，那么会添加到全局队列中，待会儿也会被Worker取出来Task并执行


• 代码5：创建Worker线程，并开始执行

开始执行Worker线程之后，我们需要看一下这个线程的run方法执行的是啥，也就是它的具体执行逻辑。

internal inner class Worker private constructor() : Thread() {

    override fun run() = runWorker()

    private fun runWorker() {

        var rescanned = false

        while (!isTerminated && state != WorkerState.TERMINATED) {

            //代码1

            val task = findTask(mayHaveLocalTasks)

            if (task != null) {

                rescanned = false

                minDelayUntilStealableTaskNs = 0L

                //代码2

                executeTask(task)

                continue

            } else {

                mayHaveLocalTasks = false

            }

            if (minDelayUntilStealableTaskNs != 0L) {

                if (!rescanned) {

                    rescanned = true

                } else {

                    rescanned = false

                    tryReleaseCpu(WorkerState.PARKING)

                    interrupted()

                    LockSupport.parkNanos(minDelayUntilStealableTaskNs)

                    minDelayUntilStealableTaskNs = 0L

                }

                continue

            }

            tryPark()

        }

        tryReleaseCpu(WorkerState.TERMINATED)

    }

        

    fun findTask(scanLocalQueue: Boolean): Task? {

        if (tryAcquireCpuPermit()) return findAnyTask(scanLocalQueue)

        // If we can't acquire a CPU permit -- attempt to find blocking task

        val task = if (scanLocalQueue) {

            localQueue.poll() ?: globalBlockingQueue.removeFirstOrNull()

        } else {

            globalBlockingQueue.removeFirstOrNull()

        }

        return task ?: trySteal(blockingOnly = true)

    }

    

    private fun executeTask(task: Task) {

        val taskMode = task.mode

        idleReset(taskMode)

        beforeTask(taskMode)

        runSafely(task)

        afterTask(taskMode)

    }

    

    fun runSafely(task: Task) {

        try {

            task.run()

        } catch (e: Throwable) {

            val thread = Thread.currentThread()

            thread.uncaughtExceptionHandler.uncaughtException(thread, e)

        } finally {

            unTrackTask()

        }

    }

    

}

run方法直接调用的runWorker()，在里面是一个while循环，不断从队列中取Task来执行。

• 代码1：从本地队列或者全局队列中取出Task


• 代码2：执行这个task，最终其实就是调用这个Runnable的run方法。

也就是说，在Worker这个线程中，执行了这个Runnable的run方法。还记得这个Runnable是谁么？它就是上面我们看过的DispatchedContinuation，这里的run方法执行的就是协程任务，那这块具体的run方法的实现逻辑，我们应该到DispatchedContinuation中去找。

internal class DispatchedContinuation<in T>(

    @JvmField val dispatcher: CoroutineDispatcher,

    @JvmField val continuation: Continuation<T>

) : DispatchedTask<T>(MODE_UNINITIALIZED), CoroutineStackFrame, Continuation<T> by continuation {

    ......

}



internal abstract class DispatchedTask<in T>(

    @JvmField public var resumeMode: Int

) : SchedulerTask() {

    public final override fun run() {

        assert { resumeMode != MODE_UNINITIALIZED } // should have been set before dispatching

        val taskContext = this.taskContext

        var fatalException: Throwable? = null

        try {

            val delegate = delegate as DispatchedContinuation<T>

            val continuation = delegate.continuation

            withContinuationContext(continuation, delegate.countOrElement) {

                val context = continuation.context

                val state = takeState() // NOTE: Must take state in any case, even if cancelled

                val exception = getExceptionalResult(state)

                /*

                 * Check whether continuation was originally resumed with an exception.

                 * If so, it dominates cancellation, otherwise the original exception

                 * will be silently lost.

                 */

                val job = if (exception == null && resumeMode.isCancellableMode) context[Job] else null

                

                //非空，且未处于active状态

                if (job != null && !job.isActive) {

                    //开始之前，协程已经被取消，将具体的Exception传出去

                    val cause = job.getCancellationException()

                    cancelCompletedResult(state, cause)

                    continuation.resumeWithStackTrace(cause)

                } else {

                    //有异常，传递异常

                    if (exception != null) {

                        continuation.resumeWithException(exception)

                    } else {

                        //代码1

                        continuation.resume(getSuccessfulResult(state))

                    }

                }

            }

        } catch (e: Throwable) {

            // This instead of runCatching to have nicer stacktrace and debug experience

            fatalException = e

        } finally {

            val result = runCatching { taskContext.afterTask() }

            handleFatalException(fatalException, result.exceptionOrNull())

        }

    }

}

我们主要看一下代码1处，调用了resume开启协程。前面没有异常，才开始启动协程，这里才是真正的开始启动协程，开始执行launch传入的Lambda表达式。这个时候，协程的逻辑是在Worker这个线程上执行的了，切到某个线程上执行的逻辑已经完成了。

ps: rusume会走到BaseContinuationImpl的rusumeWith，然后走到launch传入的Lambda匿名内部类的invokeSuspend方法，开始执行状态机逻辑。前面的文章 Kotlin协程createCoroutine和startCoroutine原理 我们分析过这里，这里就只是简单提一下。

到这里，Dispatchers的执行流程就算完了，前后都串起来了。

小结

Dispatchers是协程框架中与线程交互的关键。底层会有不同的线程池，Dispatchers.Default、IO，协程任务来了的时候会封装成一个个的Runnable，丢到线程中执行，这些Runnable的run方法中执行的其实就是continuation.resume，也就是launch的Lambda生成的SuspendLambda匿名内部类，也就是开启协程状态机，开始协程的真正执行。

一般情况下，服务端接口都会有一套数据结构规范，比如

{

    "items": [],

    "success": true,

    "msg": ""

}

不同的接口，items 中返回的数据结构一般都是不一样的，这时使用泛型，可以简化代码

本文将以 wanAndroid 提供的开放 API 为例，介绍如何通过泛型类接解析 JSON 数据，简化代码。另外，对 wanAndroid 提供开放 API 的行为表示感谢。

本文解析 JSON 使用的方案，是官方推荐的 json_serializable，至于为什么选择 json_serializable，可以参考我之前写的一篇文章：Flutter 使用 json_serializable 解析 JSON 最佳方案

下面开始进入正文

使用 json_serializable 支持泛型

json_serializable 在大概两年前发布的 v3.5.0 版本开始支持泛型，只需要在 @JsonSerializable() 注解中设置 genericArgumentFactories 为 true，同时需要对 fromJson 和 toJson 方法进行调整，即可支持泛型解析，如下所示：

@JsonSerializable(genericArgumentFactories: true)

class Response<T> {

  int status;

  T value;

  

  factory Response.fromJson(

      Map<String, dynamic> json,

      T Function(dynamic json) fromJsonT,

      ) =>

      _$ResponseFromJson<T>(json, fromJsonT);



  Map<String, dynamic> toJson(Object? Function(T value) toJsonT) =>

      _$ResponseToJson<T>(this, toJsonT);

}

和正常实体类相比，fromJson 方法多了一个函数参数 T Function(dynamic json) fromJsonT；toJson 方法也多了一个函数参数：Object? Function(T value) toJsonT

分析数据结构

下面使用 wanAndroid 开放 API 接口数据，进行代码实践，我们先看一下服务端接口返回的数据结构

一般接口返回数据结构如下：

{

  "data": [

    {

      "desc": "一起来做个App吧",

      "id": 10,

      "imagePath": "https://www.wanandroid.com/blogimgs/50c115c2-cf6c-4802-aa7b-a4334de444cd.png",

      "isVisible": 1,

      "order": 1,

      "title": "一起来做个App吧",

      "type": 1,

      "url": "https://www.wanandroid.com/blog/show/2"

    }

  ],

  "errorCode": 0,

  "errorMsg": ""

}

带分页信息的列表接口，返回数据结构如下：

{

  "data": {

    "curPage": 1,

    "datas": [

      {

        "id": 23300,

        "link": "https://juejin.cn/post/7114142706557075487",

        "niceDate": "2022-06-28 15:30",

        "niceShareDate": "2022-06-28 15:30",

        "publishTime": 1656401449000,

        "realSuperChapterId": 493,

        "shareDate": 1656401449000,

        "shareUser": "灰尘",

        "superChapterId": 494,

        "superChapterName": "广场Tab",

        "title": "Flutter 使用 json_serializable 解析 JSON 最佳方案"

      }

    ],

    "offset": 0,

    "over": false,

    "pageCount": 3,

    "size": 20,

    "total": 46

  },

  "errorCode": 0,

  "errorMsg": ""

}

通过上面的接口示例，我们可以发现，返回的数据结构有以下两种情况：

在一般情况下 data 是一个数组

{

    "data": [],

    "errorCode": 0,

    "errorMsg": ""

}

在分页相关接口，data 是一个对象

{

    "data": {},

    "errorCode": 0,

    "errorMsg": ""

}

复杂方案

如果想定义一个模型类，同时处理上述两种情况，可以把整个 data 都定义为泛型，代码如下：

import 'package:json_annotation/json_annotation.dart';



part 'base_response.g.dart';



@JsonSerializable(genericArgumentFactories: true)

class BaseResponse<T> {

  T data;

  int errorCode;

  String errorMsg;



  BaseResponse({

    required this.data,

    required this.errorCode,

    required this.errorMsg,

  });



  factory BaseResponse.fromJson(

      Map<String, dynamic> json,

      T Function(dynamic json) fromJsonT,

      ) =>

      _$BaseResponseFromJson<T>(json, fromJsonT);



  Map<String, dynamic> toJson(Object? Function(T value) toJsonT) =>

      _$BaseResponseToJson<T>(this, toJsonT);

}







@JsonSerializable(genericArgumentFactories: true)

class ListData<T> {

  int? curPage;

  List<T> datas;

  int? offset;

  bool? over;

  int? pageCount;

  int? size;

  int? total;



  ListData({

    this.curPage,

    required this.datas,

    this.offset,

    this.over,

    this.pageCount,

    this.size,

    this.total,

  });



  factory ListData.fromJson(

      Map<String, dynamic> json,

      T Function(dynamic json) fromJsonT,

      ) =>

      _$ListDataFromJson<T>(json, fromJsonT);



  Map<String, dynamic> toJson(Object? Function(T value) toJsonT) =>

      _$ListDataToJson<T>(this, toJsonT);

}

测试代码如下：

void main() {

  test("json", () {

    String str =

        '{"data": [{"category": "设计","icon": "","id": 31,"link": "https://tool.gifhome.com/compress/","name": "gif压缩","order": 4444,"visible": 1}],"errorCode": 0,"errorMsg": ""}';



    Map<String, dynamic> json = jsonDecode(str);



    BaseResponse<List<CategoryModel>> result =

        BaseResponse.fromJson(json, (json) {

      return (json as List<dynamic>)

          .map((e) => CategoryModel.fromJson(e as Map<String, dynamic>))

          .toList();

    });



    List<CategoryModel> list = result.data;



    CategoryModel model = list[0];



    print(model.toJson());



    expect("category:设计", "category:${model.category}");

  });



  test("json list", () {

    String str =

        '{"data": {"curPage": 1,"datas": [{"id": 23300,"link": "https://juejin.cn/post/7114142706557075487","niceDate": "2022-06-28 15:30","niceShareDate": "2022-06-28 15:30","publishTime": 1656401449000,"realSuperChapterId": 493,"shareDate": 1656401449000,"shareUser": "灰尘","superChapterId": 494,"superChapterName": "广场Tab","title": "Flutter 使用 json_serializable 解析 JSON 最佳方案"}],"offset": 0,"over": false,"pageCount": 3,"size": 20,"total": 46},"errorCode": 0,"errorMsg": ""}';



    Map<String, dynamic> json = jsonDecode(str);



    BaseResponse<ListData<ArticleModel>> result =

        BaseResponse.fromJson(json, (json) {

      return ListData.fromJson(json, (json) => ArticleModel.fromJson(json));

    });



    ListData<ArticleModel> listData = result.data;

    List<ArticleModel> datas = listData.datas;

    ArticleModel model = datas[0];



    print(model.toJson());



    expect("id:23300", "id:${model.id}");

  });

}

虽然一个 BaseResponse 解决了两种数据结构，但使用时的代码会有些复杂，很容易出错。

一般接口：

    BaseResponse<List<CategoryModel>> result =

        BaseResponse.fromJson(json, (json) {

      return (json as List<dynamic>)

          .map((e) => CategoryModel.fromJson(e as Map<String, dynamic>))

          .toList();

    });

分页接口：

    BaseResponse<ListData<ArticleModel>> result =

        BaseResponse.fromJson(json, (json) {

      return ListData.fromJson(json, (json) => ArticleModel.fromJson(json));

    });

简化方案

可以对一般接口和列表分页接口进行单独处理，

处理一般接口的泛型类，命名为 BaseCommonResponse，代码如下：

import 'package:json_annotation/json_annotation.dart';



part 'base_common_response.g.dart';



@JsonSerializable(genericArgumentFactories: true)

class BaseCommonResponse<T> {

  List<T> data;

  int errorCode;

  String errorMsg;



  BaseCommonResponse({

    required this.data,

    required this.errorCode,

    required this.errorMsg,

  });



  factory BaseCommonResponse.fromJson(

    Map<String, dynamic> json,

    T Function(dynamic json) fromJsonT,

  ) =>

      _$BaseCommonResponseFromJson<T>(json, fromJsonT);



  Map<String, dynamic> toJson(Object? Function(T value) toJsonT) =>

      _$BaseCommonResponseToJson<T>(this, toJsonT);

}

处理分页列表接口的泛型类，命令为 BaseListResponse

import 'package:json_annotation/json_annotation.dart';



part 'base_list_response.g.dart';



@JsonSerializable(genericArgumentFactories: true)

class BaseListResponse<T> {

  ListData<T> data;

  int errorCode;

  String errorMsg;



  BaseListResponse({

    required this.data,

    required this.errorCode,

    required this.errorMsg,

  });



  factory BaseListResponse.fromJson(

    Map<String, dynamic> json,

    T Function(dynamic json) fromJsonT,

  ) =>

      _$BaseListResponseFromJson<T>(json, fromJsonT);



  Map<String, dynamic> toJson(Object? Function(T value) toJsonT) =>

      _$BaseListResponseToJson<T>(this, toJsonT);

}







@JsonSerializable(genericArgumentFactories: true)

class ListData<T> {

  int? curPage;

  List<T> datas;

  int? offset;

  bool? over;

  int? pageCount;

  int? size;

  int? total;



  ListData({

    this.curPage,

    required this.datas,

    this.offset,

    this.over,

    this.pageCount,

    this.size,

    this.total,

  });



  factory ListData.fromJson(

    Map<String, dynamic> json,

    T Function(dynamic json) fromJsonT,

  ) =>

      _$ListDataFromJson<T>(json, fromJsonT);



  Map<String, dynamic> toJson(Object? Function(T value) toJsonT) =>

      _$ListDataToJson<T>(this, toJsonT);

}

测试代码如下：

void main() {

  test("json", () {

    String str =

        '{"data": [{"category": "设计","icon": "","id": 31,"link": "https://tool.gifhome.com/compress/","name": "gif压缩","order": 4444,"visible": 1}],"errorCode": 0,"errorMsg": ""}';



    Map<String, dynamic> json = jsonDecode(str);



    BaseCommonResponse<CategoryModel> result = BaseCommonResponse.fromJson(

        json, (json) => CategoryModel.fromJson(json));



    List<CategoryModel> list = result.data;



    CategoryModel model = list[0];



    print(model.toJson());



    expect("category:设计", "category:${model.category}");

  });



  test("json list", () {

    String str =

        '{"data": {"curPage": 1,"datas": [{"id": 23300,"link": "https://juejin.cn/post/7114142706557075487","niceDate": "2022-06-28 15:30","niceShareDate": "2022-06-28 15:30","publishTime": 1656401449000,"realSuperChapterId": 493,"shareDate": 1656401449000,"shareUser": "灰尘","superChapterId": 494,"superChapterName": "广场Tab","title": "Flutter 使用 json_serializable 解析 JSON 最佳方案"}],"offset": 0,"over": false,"pageCount": 3,"size": 20,"total": 46},"errorCode": 0,"errorMsg": ""}';



    Map<String, dynamic> json = jsonDecode(str);



    BaseListResponse<ArticleModel> result =

    BaseListResponse.fromJson(json, (json) => ArticleModel.fromJson(json));



    ListData<ArticleModel> listData = result.data;

    List<ArticleModel> datas = listData.datas;

    ArticleModel model = datas[0];



    print(model.toJson());



    expect("id:23300", "id:${model.id}");

  });

}

这时使用时的代码，就比较简单了，代码如下：

一般接口，使用 BaseCommonResponse

    BaseCommonResponse<CategoryModel> result = BaseCommonResponse.fromJson(

    json, (json) => CategoryModel.fromJson(json));

列表分页接口，使用 BaseListResponse

    BaseListResponse<ArticleModel> result = BaseListResponse.fromJson(

    json, (json) => ArticleModel.fromJson(json));

以上就是我在 Flutter 中解析 JSON 数据时处理泛型的实践经验，如果对你有所帮助，欢迎一键三连，👍👍👍

如果大家有相关问题，欢迎评论留言。

前言

本文介绍闭包。闭包其实不算是新东西了。 其实 Kotlin 就基本没有多少新东西，甚至可以说新型编程语言基本都没有新东西。是把先前编程语言好用的特性组装起来，再加一部分拓展。

本文大纲

1. 闭包介绍

首次接触 闭包 应该是在 JavaScript 上，有函数为“一等公民”特性的编程语言都有这个概念。 函数是“一等公民”的意思是，函数跟变量一样，是某种类型的实例，可以被赋值，可以被引用。函数还可以被调用。变量类型是某个声明的类，函数类型就是规定了入参个数，类型和返回值类型（不规定名字。函数名就和变量名一样，任意定义但要符合规则）。

如要声明 Kotlin 一个函数类型，入参是两个整数，出参是一个整数，那应该这样写： val add: (Int, Int) -> Int。箭头左边括号内表示入参，括号不可省略。箭头右边表示返回值。

wiki上闭包的概念是：引用了自由变量的函数，这个被引用的自由变量将和这个函数一同存在。从定义来说，对闭包的理解，是基于普通函数之上的。一般的函数，能处理的只有入参和全局变量，然后返回一个结果。闭包比普通函数功能更强，可以获取当前上下文的局部变量。当然了，捕获局部变量的前提是可以在局部环境里声明一个函数，这只有把函数当作“一等公民”才可以做到。

2. 闭包与匿名类比较

在 Java 中，匿名类其实就是代替闭包而存在的。不过 Java 严格要求所有函数都需要在类里面，所以巧妙的把“声明一个函数”这样的行为变成了“声明一个接口”或“重写一个方法”。匿名类也可以获取当前上下文的 final 局部变量。和闭包不一样的是，匿名类无法修改获取的局部变量final 不可修改

匿名类能引用 final 局部变量，是因为在编译阶段，会把该局部变量作为匿名类的构造参数传入。

Java8 lambda 是进一步接近闭包的特性，lambda 的 JVM 实现是类似函数指针的东西。 但 Java7 中的 lambda 语法糖兼容不算是真正的 lambda，只是简化了匿名类的书写。

3. 闭包使用

来看一个闭包的例子：

fun returnFun(): () -> Int {

    var count = 0

    return { count++ }

}



fun main() {

    val function = returnFun()

    val function2 = returnFun()

    println(function()) // 0

    println(function()) // 1

    println(function()) // 2

    

    println(function2()) // 0

    println(function2()) // 1

    println(function2()) // 2

}

分析上面的代码，returnFun返回了一个函数，这个函数没有入参，返回值是Int。可以用变量接收它，还可以调用它。function和function2分别是创建的两个函数实例。

可以看到，每调用一次function()，count都会加一，说明count 被function持有了而且可以被修改。而function2和function的count是独立的，不是共享的。

而通过 jadx 反编译可以看到：

public final class ClosureKt {

    @NotNull

    public static final Function0<Integer> returnFun() {

        IntRef intRef = new IntRef();

        intRef.element = 0;

        return (Function0) new 1<>(intRef);

    }



    public static final void main() {

        Function0 function = returnFun();

        Function0 function2 = returnFun();

        System.out.println(((Number) function.invoke()).intValue());

        System.out.println(((Number) function.invoke()).intValue());

        System.out.println(((Number) function2.invoke()).intValue());

        System.out.println(((Number) function2.invoke()).intValue());

    }

}

被闭包引用的 int 局部变量，会被封装成 IntRef 这个类。 IntRef 里面保存着 int 变量，原函数和闭包都可以通过 intRef 来读写 int 变量。Kotlin 正是通过这种办法使得局部变量可修改。除了 IntRef，还有 LongRef，FloatRef 等，如果是非基础类型，就统一用 ObjectRef 即可。Ref 家族源码：github.com/JetBrains/k…

在 Java 中，如果想要匿名类来操作外部变量，一般做法是把这个变量放入一个 final 数组中。这和 Kotlin 的做法本质上是一样的，即通过持有该变量的引用来使得两个类可以修改同一个变量。

4. 总结

根据示例上面分析，可以总结出：

• 闭包不算是新东西，是把函数作为“一等公民”的编程语言的特性；
• 匿名类是 Java 世界里的闭包，但有局限性，即只能读 final 变量，不能写任何变量；
• Kotlin 的闭包可以获取上下文的局部变量，并可以修改它。实现办法是 Kotlin 编译器给引用的局部变量封装了一层引用。

Kotlin中StateFlow的使用