FlutterComponent最佳实践之Timer的妙用

点击上方蓝字关注我，知识会给你力量

Timer在Flutter中，通常是用来构建延时的异步任务的，在讲解它的妙之前，我们先来看看Timer的基操。

Timer基操

Timer广义上可以理解为一个倒计时器，它从创建到结束会经历下面三个过程：

• Creates a timer

• Executes a callback

• The timer finishes

创建一个Timer非常简单。

final timer = Timer(
  const Duration(seconds: 3),
  () {
    // TODO
  },
);

上面这段代码，就代表着3秒延迟后执行回调闭包，当前代码中，这个回调只会执行一次。

那么如果我们需要创建一个周期性的计时器的话，就需要使用Timer.periodic构造函数。

final periodicTimer = Timer.periodic(
  const Duration(seconds: 1),
  (timer) {
    // TODO
  },
);

默认的周期性Timer会无限制的执行下去，所以，和所有的资源一样，我们需要对其进行管理，释放掉不使用的Timer资源。

❝

通常我们会在Widget的dispose方法中释放。

❞

首先就是Timer的cancel方法，拿到Timer的句柄后，我们可以在合适的时机对其进行cancel（多次调用cancel不会产生任何副作用，多余的cancel会被忽略）。

final timer = Timer.periodic(
  const Duration(seconds: 1),
  (timer) {
    // TODO
  },
);

final shouldStop = true;

test() {
  if (shouldStop || timer.isActive) {
    timer.cancel();
  }
}

同时，Timer句柄还提供了isActive来判断当前Timer是否已经销毁，以及timer.tick来获取当前的计数值。

Timer意料之外

上面就是Timer最基础的使用，看上去是不是非常简单，但是，Timer在Flutter中实际上是一个非常重要的类，我们来看下Future的实现。发现了吗，我们创建异步代码的Future，其本质上也是通过Timer来实现的，所以，我们可以借助Timer来实现一个非常有意思的功能——以异步的方式尽快的执行回调。

print('normal code start');
final zeroDurationTimer = Timer(
  Duration.zero,
  () {
    // Execute this callback ASAP but asynchronously
    print('zeroDurationTimer callback');
  },
);
print('normal code end');

我们来看上面的代码，执行结果如下。

normal code start
normal code end
zeroDurationTimer callback

这是因为所有的异步函数都被放到一个队列里进行调度，所以其回调的执行需要一点时间。因此，上面异步回调中的代码，会在最后执行。

❝

上面的代码还有一个简化的写法——使用Timer.run构造函数。

❞

final zeroDurationTimer = Timer.run(
  () {
    // Execute this callback ASAP but asynchronously
  },
);

❝

多个Timer.run，或者说是Future，实际上也会按照异步的方式，按队列顺序依次执行。

❞

批处理Channel

那么这个东西能干嘛呢——它可以帮我们批量处理一部分Microtask里面的操作，例如我们下面这个操作。

import 'package:flutter/material.dart';

import 'batch_method_channel.dart';

void main() => runApp(const MyApp());

class MyApp extends StatefulWidget {
  const MyApp({super.key});

  @override
  State<MyApp> createState() => _MyAppState();
}

class _MyAppState extends State<MyApp> {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: Scaffold(
        appBar: AppBar(title: const Text('Plugin example app')),
        body: GridView.builder(
          gridDelegate: const SliverGridDelegateWithFixedCrossAxisCount(crossAxisCount: 4),
          itemBuilder: (context, index) => TestWidget(index),
        ),
      ),
    );
  }
}

class TestWidget extends StatelessWidget {
  final int index;

  const TestWidget(
    this.index, {
    Key? key,
  }) : super(key: key);

  @override
  Widget build(BuildContext context) {
    batchChannel.invokeMethod('getPlatformVersion', {'index': index.toString()});
    return GridTile(child: Text('data $index'));
  }
}

在上面的代码中，我们模拟一个类似埋点的需求，在Widget build的时候，调用Channel传递一些数据到Native（这里使用的是Plugin Demo的工程进行改造的）。

如果我们使用普通的Channel来处理这个需求，那么每个Item build的时候都会调用一次Channel，这些Channel的调用会造成一定的性能损耗，所以我们需要对Channel进行批处理。

❝

经过测试发现，Channel的性能损耗其实已经很低了，是否批处理带来的性能提升，只能在一些比较差的设备上才能有所体现。

❞

这个批处理的需求，就可以使用Timer来实现，代码如下。

import 'dart:async';

import 'package:flutter/services.dart';

final BatchMethodChannel batchChannel = BatchMethodChannel();

class BatchMethodChannel {
  static const MethodChannel channel = MethodChannel('xys_flutter_batch_channel');

  Timer? _timer;

  final List<Map<String, String>> _methods = [];

  void invokeMethod(String method, [Map<String, String>? arguments]) {
    if (_timer == null || !_timer!.isActive) {
      _methods.clear();
      _timer = Timer(Duration.zero, () {
        channel.invokeMethod(
          'batch_channel_invoke',
          _methods,
        );
      });
    }
    _methods.add({'method': method}..addAll(arguments ?? {}));
  }
}

当Widget build时，调用invokeMethod操作，首次调用时，会创建一个Timer，并将真实的channel.invokeMethod作为异步任务延迟执行，根据前面的解释，这个Callback只有当主线程队列全部执行完成后才会执行，所以，当页面上有源源不断的Widget build时，invokeMethod一直被执行，非首次的执行，会将Method参数添加到List中，等所有Widget调用完成，Callback进行了处理，将前面List中的所有数据一次性通过channel.invokeMethod执行，从而形成了批处理的功能。

那么在Native侧收到批处理的消息后，就需要遍历List来处理每个Method，完成相应的操作。

when (call.method) {
    "batch_channel_invoke" -> {
        val callArguments: List<Map<String, String>> = call.arguments as List<Map<String, String>>
        Log.d("xys", "batch_channel_invoke: $callArguments")
    }
    else -> {
        result.notImplemented()
    }
}

这种对Channel批处理的方式，也是有一些使用局限的。首先，由于批处理的Channel在Native侧执行的时候，不一定全部都是同步方法，所以，批处理Channel无法做到等一批数据处理好之后的统一返回。它最合适的场景还是类似上面这种「单向」的Channel调用场景。其次，Channel的解析过程会比普通方式更加复杂一点，需要看场景使用。

❝

当然，Batch Channel也不一定只能是「单向」的，通过一些其它方式，它也可以做到向普通Channel那样的双向通信，例如，我们可以使用EventChannel来配合BatchChannel使用，这样在Native侧处理好批处理数据后，通过Stream返回给Flutter侧的监听者，从而实现双向通信。这些内容，我们后续再分析。

❞

向大家推荐下我的网站 https://www.yuque.com/xuyisheng  点击原文一键直达

专注 Android-Kotlin-Flutter 欢迎大家访问

往期推荐

• FlutterComponent最佳实践之动画的显和隐
  

• Flutter混编工程之异常处理

• 闲言碎语-第八期

• Kotlin泛型的型变之路
  

本文原创公众号：群英传，授权转载请联系微信(Tomcat_xu)，授权后，请在原创发表24小时后转载。

< END >

作者：徐宜生

更文不易，点个“三连”支持一下👇