哔哩哔哩漫画APP实践Flutter也有大半年时间了，我针对线上收集到的错误进行分析，挑选出了一些有一般代表性的错误，列在本文，可供实践 Flutter 的初学者们作为一点参考。

典型错误一：无法掌握的Future

典型错误信息：NoSuchMethodError: The method 'markNeedsBuild' was called on null.

这个错误常出现在异步任务（Future）处理，比如某个页面请求一个网络API数据，根据数据刷新 Widget State。

异步任务结束在页面被pop之后，但没有检查State 是否还是 mounted，继续调用 setState 就会出现这个错误。

示例代码

一段很常见的获取网络数据的代码，调用 requestApi()，等待Future从中获取response，进而setState刷新 Widget：

1
2
3
4
5
6
7
8
9
10

class AWidgetState extends State<AWidget> {
  // ...
  var data;
  void loadData() async {
    var response = await requestApi(...);
    setState((){
      this.data = response.data;
    })
  }
}

原因分析

response 的获取为async-await异步任务，完全有可能在AWidgetState被 dispose之后才等到返回，那时候和该State 绑定的 Element 已经不在了。故而在setState时需要容错。

解决办法： setState之前检查是否 mounted

1
2
3
4
5
6
7
8
9
10
11
12

class AWidgetState extends State {
  // ...
  var data;
  void loadData() async {
    var response = await requestApi(...);
    if (mounted) {
      setState((){
        this.data = response.data;
      })
    }
  }
}

这个mounted检查很重要，其实只要涉及到异步还有各种回调(callback)，都不要忘了检查该值。

比如，在 FrameCallback里执行一个动画(AnimationController)：

1
2
3
4
5
6

@override
void initState(){
  WidgetsBinding.instance.addPostFrameCallback((_) {
    if (mounted) _animationController.forward();
  });
}

AnimationController有可能随着 State 一起 dispose了，但是FrameCallback仍然会被执行，进而导致异常。

又比如，在动画监听的回调里搞点事：

1
2
3
4
5
6
7
8

@override
void initState(){
  _animationController.animation.addListener(_handleAnimationTick);
}

void _handleAnimationTick() {
  if (mounted) updateWidget(...);
}

同样的在_handleAnimationTick被回调前，State 也有可能已经被dispose了。

如果你还不理解为什么，请仔细回味一下Event loop 还有复习一下 Dart 的线程模型。

最近 2019-nCoV 疫情漫延，天天闲在家也没事干，突然觉得非常孤单寂寞冷，今天回顾了一下我相亲这么多回还是孑然一身的原因。以下为正文。。

每逢假期，回老家相亲是不可回避的乡亲们茶余饭后喜闻乐见的节目。

素未谋面的两人抽出时间，凑在一起碰过面之后，如果一方觉得可以进一步发展试试，但却不知对方的态度，接下来就会纠结：是主动表态还是被动等待。

一旦开始了选择，这其实可以将双方看作处于一场非零和博弈中了。

双方组合起来有如下四种策略：

1. 如果🧑👨双方都主动表达好感👩‍❤️‍💋‍👨，意味着可以顺利发展下一步，这时可认为双方获得奖励性回报，双赢，各得2分。
2. 如果🧑主动表达好感，而👨没有，那么认为👨得到“渣男卡”回报3分，而🧑得0分。
3. 反过来，👨主动表态，热脸贴冷屁股，👨获得“好人卡”回报0分，🧑3分。
4. 如果🧑👨都等待对方表态，那多半意味着相亲失败，不过多认识了朋友而已，各得1分。

在实际博弈中，🧑👨双方都会站在自己的角度，只考虑到自己的最佳回报，不约而同地选择了等待（“纳什均衡”），亦即这场相亲最后不了了之，bad end。

哔哩哔哩的漫画业务是在18年末正式官宣成立的，之后便有了收（jie）购（pan）网易漫画的事。虽说是“新业务”，其实内部立项之早或可追溯到2017年，APP 的代码饱含着历史沧桑感，流淌来自B站内部多个部门程序员的心血，杂糅了多种技术栈和代码风格，令现维护者头疼到头秃。

2019年初适逢 Flutter 声名鹊起，经过一段时间技术调研和在网易漫画 APP 上试验后，便开始在哔哩哔哩漫画 APP （后文简称B漫）上紧锣密鼓一步一个脚印跟着版本迭代与用户见面。我给 Flutter 在B漫的落地计划起了个名叫“胡辣汤计划”。

胡辣汤

一晃时间到了19年底，不过区区 6 人的小组将“胡辣汤计划”已经从试验阶段实施到成熟阶段，开始直接对接新页面和业务功能。iOS 和 Android 双端 APP 已由 Flutter 覆盖了多个主路径页面，重写的页面和原来页面相比用户几乎没有感知到差别，日均超七成活跃用户使用过 Flutter 所呈现的页面功能，并且维持着这些页面功能 0.01% 的低错误率、崩溃率，这不能说不是得益于 Flutter 的优秀设计。

网易漫画和哔哩哔哩漫画

Logs

来自线上用户的一个神奇崩溃，日志如下：

java.lang.IndexOutOfBoundsException: setSpan (-1 ... -1) starts before 0
    at android.text.SpannableStringBuilder.checkRange(SpannableStringBuilder.java:1330)
    at android.text.SpannableStringBuilder.setSpan(SpannableStringBuilder.java:684)
    at android.text.SpannableStringBuilder.setSpan(SpannableStringBuilder.java:676)
    at android.view.accessibility.AccessibilityNodeInfo.setText(AccessibilityNodeInfo.java:2645)
    at android.widget.TextView.onInitializeAccessibilityNodeInfoInternal(TextView.java:11652)
    at android.view.View.onInitializeAccessibilityNodeInfo(View.java:8257)
    at android.view.View.createAccessibilityNodeInfoInternal(View.java:8216)
    at android.view.View.createAccessibilityNodeInfo(View.java:8201)
    at android.view.AccessibilityInteractionController$AccessibilityNodePrefetcher.prefetchDescendantsOfRealNode(AccessibilityInteractionController.java:1204)
    at android.view.AccessibilityInteractionController$AccessibilityNodePrefetcher.prefetchAccessibilityNodeInfos(AccessibilityInteractionController.java:1029)
    at android.view.AccessibilityInteractionController.findAccessibilityNodeInfoByAccessibilityIdUiThread(AccessibilityInteractionController.java:341)
    at android.view.AccessibilityInteractionController.access$400(AccessibilityInteractionController.java:75)
    at android.view.AccessibilityInteractionController$PrivateHandler.handleMessage(AccessibilityInteractionController.java:1393)
    at android.os.Handler.dispatchMessage(Handler.java:107)
    at android.os.Looper.loop(Looper.java:214)
    at android.app.ActivityThread.main(ActivityThread.java:7356)
    at java.lang.reflect.Method.invoke(Native Method)
    at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492)
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:930)

当用户触发无障碍服务 (Accessibility) 时，会遍历可点击的 TextView。TextView 再去创建 AccessibilityNodeInfo 传递给无障碍服务，但 AccessibilityNodeInfo 在获取文本用于构造 SpannableStringBuilder 时却发生了异常—— java.lang.IndexOutOfBoundsException

Why?

下面这段摘抄自 AccessibilityNodeInfo.java 的代码告诉了我们原因:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

public void setText(CharSequence text) {
    enforceNotSealed();
    mOriginalText = text;
    // Replace any ClickableSpans in mText with placeholders
    if (text instanceof Spanned) {
        ClickableSpan[] spans =
                ((Spanned) text).getSpans(0, text.length(), ClickableSpan.class);
        if (spans.length > 0) {
            Spannable spannable = new SpannableStringBuilder(text);
            for (int i = 0; i < spans.length; i++) {
                ClickableSpan span = spans[i];
                if ((span instanceof AccessibilityClickableSpan)
                        || (span instanceof AccessibilityURLSpan)) {
                    // We've already done enough
                    break;
                }
                int spanToReplaceStart = spannable.getSpanStart(span);
                int spanToReplaceEnd = spannable.getSpanEnd(span);
                int spanToReplaceFlags = spannable.getSpanFlags(span);
                spannable.removeSpan(span);
                ClickableSpan replacementSpan = (span instanceof URLSpan)
                        ? new AccessibilityURLSpan((URLSpan) span)
                        : new AccessibilityClickableSpan(span.getId());
                spannable.setSpan(replacementSpan, spanToReplaceStart, spanToReplaceEnd,
                        spanToReplaceFlags);
            }
            mText = spannable;
            return;
        }
    }
    mText = (text == null) ? null : text.subSequence(0, text.length());
}

上述代码关键是在替换 text中的 ClickableSpan 对象为 AccessibilityURLSpan或者AccessibilityClickableSpan：

1. 首先，从原始的 text 中获取的 ClickableSpan 对象数组 spans。
2. 其次，遍历获取每个 ClickableSpan 在原始 text 中的位置。
3. 最后，替换掉 Spannable 对应位置的 ClickableSpan。

崩溃就发生最最后一步 spannable.setSpan(...)。程序执行到这里的时候， spanToReplaceStart和spanToReplaceEnd都是 -1，就是说对应的 ClickableSpan 在经过 SpannableStringBuilder 拷贝后不见了 ！！

why ???

站在三十岁的第一天回头看，
生活就是一个七天接着一个七天。

人生短暂，
须臾模糊了发际线。

时间教会我的：
现在过的每一天，
都是余生中最年轻的一天。

。
。
。
没错，句子是东拼西凑抄来的╮(￣▽￣)╭

众所周知，官方提供了好几个办法来让我们在开发 Flutter app 的过程中可以使用查看 fps等性能数据，如devtools，具体见文档 Debugging Flutter apps 、Flutter performance profiling 等。

但是这些工具统计到的数据充其量只能算开发过程中的“试验室”数据，假如需要统计app 在线上在用户手机上的运行情况，该如何在 flutter 端代码里自己计算性能数据，比如 fps 这个值呢？

经过阅读源码，发现其实很简单，给window对象注册 onReportTimings 即可，去看api文档。

1
2
3
4
5
6
7
8

void main() {
  runApp(...);
  window.onReportTimings = _onReportTimings;
}

void _onReportTimings(List<FrameTiming> timings) {
  // TODO
}

代码给你看

考虑计算fps，只需要保留最近 N 个FrameTiming 来计算即可，最好用类似stack的数据结构存起来，参考了文档，我们选用 Queue ，N 指定为 100

1
2
3
4
5
6
7
8
9
10
11
12
13
14

const maxframes = 100; // 100 帧足够了，对于 60 fps 来说
final lastFrames = ListQueue<FrameTiming>(maxframes);

void _onReportTimings(List<FrameTiming> timings) {
  // 把 Queue 当作堆栈用
  for (FrameTiming timing in timings) {
    lastFrames.addFirst(timing);
  }

  // 只保留 maxframes
  while (lastFrames.length > maxframes) {
    lastFrames.removeLast();
  }
}

lastFrames 的头就是最后一帧，尾是队伍里最开始的一帧，现在你可以计算 FPS 了：

1
2
3
4
5
6
7
8

double get fps {
  int frames = lastFrames.length;
  var start = lastFrames.last.timestampInMicroseconds(FramePhase.buildStart);
  var end = lastFrames.first.timestampInMicroseconds(FramePhase.rasterFinish);
  var duration = (end - start) / Duration.microsecondsPerMillisecond;

  return frames * Duration.millisecondsPerSecond / duration;
}

但，你会发现，这样算出来和官方工具算的对不上，而且错的离谱。

why ??

flutter 的崩溃日志收集主要有两个方面：

1. flutter dart 代码的异常（包含app和framework代码两种情况，一般不会引起闪退，你猜为什么）
2. flutter engine 的崩溃日志（一般会闪退）

Flutter App 代码异常捕获

人写的代码是无数异常交织起来的偶然产物，代码发生异常才是正常情况。

除了在关键的地方加上 try-catch 让它们变成已知异常之外，抓到未知异常才是真本事。

比如下面的一段代码中的try-catch是无效的：

1
2
3
4
5

try {
    Future.error("asynchronous surprise");
} catch (e){
    print(e)
}

好在，Dart 有一个 Zone 的概念，有点类似sandbox的意思。不同的 Zone 代码上下文是不同的互不影响，Zone 还可以创建新的子Zone。Zone 可以重新定义自己的print、timers、microtasks还有最关键的how uncaught errors are handled 未捕获异常的处理

1
2
3
4
5

runZoned(() {
    Future.error("asynchronous error");
}, onError: (dynamic e, StackTrace stack) {
    reportError(e, stack);
});

在 reportError 里即可以进行上报处理（详见后面介绍）。

Flutter framework 异常捕获

注册 FlutterError.onError 回调，用于收集 Flutter framework 外抛的异常。

1
2
3

FlutterError.onError = (FlutterErrorDetails details) {
    reportError(details.exception, details.stack);
};

该 error 一般是由 Widget 在 build 的时候抛出，如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

@override
void performRebuild() {
  Widget built;
  try {
    built = build();
  } catch (e, stack) {
    built = ErrorWidget.builder(_debugReportException(ErrorDescription("building $this"), e, stack));
  } finally {
    _dirty = false;
  }
  try {
    _child = updateChild(_child, built, slot);
  } catch (e, stack) {
    built = ErrorWidget.builder(_debugReportException(ErrorDescription("building $this"), e, stack));
    _child = updateChild(null, built, slot);
  }
}

普遍的，不论大小Android应用都会配置 proguard 在release 编译的时候混淆自己的代码：

1
2
3
4
5
6
7
8

android {
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
 }

但无论 Proguard 还是 R8，他们的混淆字典默认都太简单了，只是 abcdefg 而已，反编译后还是很容易阅读的，如下所示：

1
2
3
4
5
6
7
8

final class b {
  Object a;
  aes b;
  ada c;

  b() {
  }
}

所幸，Proguard 支持自定义字典：

1
2
3

-obfuscationdictionary dict.txt
-classobfuscationdictionary dict.txt
-packageobfuscationdictionary dict.txt

如果，有那么一个字典，里面的字或词不仅费眼睛电脑字体还没收录的更佳。

万能的github 上还真有符合要求的。但是直接生成好的字典文件一直用也是有隐患的，如果两个版本之间类、方法的个数差别不大的话，最终的mapping其实是很相似的，有可能前一个版本叫 aa，现在叫 ab。

而且翻看了部分实现方案，要么是字典文件里词汇量不够大，要么生成代码实现可能有其它bug。故而干脆自己撸起袖子几行代码搞定。

Reproduce

Add abiFilters to android/app/build.gradle :

1
2
3
4
5
6
7

android {
  defaultConfig {
    ndk {
      abiFilters 'armeabi-v7a'
    }
  }
}

Run command:

1

$ flutter run

Flutter app crashed by java.lang.UnsatisfiedLinkError:

java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[[zip file “/data/app/xxxx/base.apk”],nativeLibraryDirectories=[/data/app/xxxx/lib/arm, /data/app/xxxx/base.apk!/lib/armeabi-v7a, /system/lib, /vendor/lib, /product/lib]]] couldn’t find “libflutter.so”
at java.lang.Runtime.loadLibrary0(Runtime.java:1011)
at java.lang.System.loadLibrary(System.java:1660)
at io.flutter.view.FlutterMain.startInitialization(FlutterMain.java:156)
at io.flutter.view.FlutterMain.startInitialization(FlutterMain.java:133)
at io.flutter.app.FlutterApplication.onCreate(FlutterApplication.java:22)

…

As you can see, flutter run seems like forgot to put “libflutter.so” into apk.

譬如你跟他说某开源项目很好值得深入学习，他可能点个star表示已阅，或者点个fork表示可以深入研究，clone代码那是万万不可能的。

但假如在某程序员聚集地说某项目源码泄漏了，那景象好比炸窝，蜂拥而上，生怕吃不上热的，star+fork+clone素质三连，忙得不亦乐乎。

费劲周折毕竟拿到代码了，也不管看不看得懂，像是对着名画，总要品头论足一番，凭着一知半解发表几点高论。

开动鹰眼扫代码要是发现点奇特的地方，那如同发现新大陆，喜不自胜，更丝毫不吝啬自己的言辞到处去说。

程序员真的是个热爱学习的群体。