Flutter填坑笔记：从flutter pub get error 开始，定位Dart SDK问题

在使用Flutter开发应用的时候，有时需要使用pub工具获取依赖的包。但是国内的开发者往往会遇到下载失败的问题，现象为pub进程崩溃，堆栈如下：

Running "flutter packages get" in startup_namer...
The setter 'readEventsEnabled=' was called on null.
Receiver: null
Tried calling: readEventsEnabled=false
package:pub/src/source/hosted.dart 344   BoundHostedSource._throwFriendlyError
package:pub/src/source/hosted.dart 144   BoundHostedSource.doGetVersions

长文预警：TLDR版本如下，如果你只想解决下载问题，方案如下：
关闭代理，设置环境变量，使用国内镜像下载。

export PUB_HOSTED_URL=https://pub.flutter-io.cn
export FLUTTER_STORAGE_BASE_URL=https://storage.flutter-io.cn

GitHub上已经有多个Issue，例如/flutter/issues/25068

Dart Team回复的官方解决方案就是上面的办法。

如果你对问题根因感兴趣，请往下看。

作为一个程序员要有所追求，我是不满足Dart team这样的回复的 ^_^。

因为有以下疑问：

我的机器上使用了某灯，fluter的官网和dart官网访问都没有障碍，为何pub不行；
pub需要下载的文件，例如https://pub.dartlang.org/packages/bsdiff/versions/0.1.0.tar.gz，从浏览器中是可以快速下载的。pub只能从中国镜像下载，而且非常慢，项目初始化时太浪费时间。
即使连接不上，pub也不能崩溃处理，从Log看肯定是代码逻辑有问题。

从以上三点出发，我猜想pub没有使用代理，还是走原来的网络链接，所以我决定跟踪一下这个问题的根本原因。

STEP 1：分析入口：flutter pub get 的处理流程 (flutter_tools)

要想解决问题，首先需要需要找到入口，Android Studio工程中，更新package使用的是命令行命令：

flutter pub get

flutter 是FLUTTER SDK 中提供的脚本，封装了各个工具，作为SDK的总入口，真正生效的是如下语句：

"$DART" --packages="$FLUTTER_TOOLS_DIR/.packages" $FLUTTER_TOOL_ARGS "$SNAPSHOT_PATH" "$@"

运行时变量如下：

dart --packages=~/flutter/packages/flutter_tools/.packages  /~/flutter/bin/cache/flutter_tools.snapshot pub get

解释一下：

flutter 作为一个shell脚本，最终通过dart命令调用flutter_tools执行pub get命令；
--packages是命令运行时依赖的package路径，这个场景没有用到；
.snapshot 文件是DART程序预编译生成的快照文件，可执行，可以简单类比JAVA中的.jar文件。
$@ 把后续命令原封不动转发给fluter_tools处理。

flutter_tools代码路径在FLUTTER SDK目录下, 是一个DART语言编写的CLI命令行工具：

~/flutter/packages/flutter_tools

在IDE中可以建立DART Command Line Tool工程查看，编译这个工具，具体可以参考：/flutter/wiki/The-flutter-tool

简单分析一下flutter_tool 的代码逻辑：

项目入口：./bin/flutter_tools.dart; IDE中，配置运行时的文件指定这个，就可以在IDE中运行起来。

void main(List<String> args) {
  executable.main(args);
}

命令处理流程：和JAVA， C常见的CLI程序结构类似，就是分析命令行输入的字符串，路由到对应模块进行处理，例如常用的flutter doctor 命令就在 commands/doctor.dart 中处理：

class DoctorCommand extends FlutterCommand {......}

pub命令：pub命令比较特殊，flutter_tools通过系统命令行接口，调用外部命令实现的：

main() ->
     Executable.main-> 
     FlutterCommandRunner.runCommand -> 
     PackageGetCommand._runPubGet ->
     pubGet() (lib/src/dart/pub.dart)

最终通过SDK的pub组件执行的命令

/// The command used for running pub.
List<String> _pubCommand(List<String> arguments) {
  return <String>[ sdkBinaryName('pub') ]..addAll(arguments);
}

也就是说，代理连接失败，问题不在flutter_tools中，需要继续分析pub流程。

STEP 2：缩小范围：pub get 的处理流程 (pub)

pub 的二进制文件路径在**~/flutter/bin/cache/dart-sdk/bin/pub**，同样，这是一个shell脚本，最终执行的是。./flutter/bin/cache/dart-sdk/bin/snapshots/pub.dart.snapshot
为了解决问题，我们需要pub的源码，pub 是dart sdk提供的工具，所以源码在dart-lang中，./dart-lang/pub
在Android Studio中同样配置Dart Comman Line工程，不再赘述。pug get -v 可以打印详细log.
pub流程分析限于篇幅这里省略，根据崩溃堆栈分析和代码逻辑，pub使用的是dart:io 中的HttpClient

STEP 3: 问题定位：DEMO复现, 编译SDK，跟踪SDK逻辑

既然问题在dart:io中，我于是单独写了一个DEMO，使用 dart:io 中的 HttpClient 测试，发现问题竟然可以简单复现，激动不已，绕了一大圈终于找到了责任人：

import "dart:io";
import 'dart:convert';
main() async {
  var google = "https://www.google.com/";
  var httpClient = HttpClient();
//  // Lantern proxy, cause crash
  httpClient.findProxy = (uri) {
    return "PROXY 127.0.0.1:45653";
  };
  HttpClientRequest request = await httpClient.getUrl(Uri.parse(baidu));
  HttpClientResponse response = await request.close();
  var responseBody = await response.transform(Utf8Decoder()).join();
  print(responseBody);
}

解释：

测试OS：Ubuntu 18.04
开启某灯：HttpClient使用某灯作为代理（HttpClient. findProxy()设置）执行，崩溃日志如下, 可以看到和pub崩溃的日志类似都有 The setter 'readEventsEnabled=' was called on null. 姑且认为是同一个问题导致的。

Unhandled exception: NoSuchMethodError: 
    The setter 'readEventsEnabled=' was called on null. 
    Receiver: null Tried calling: readEventsEnabled=false 
#0 _rootHandleUncaughtError.<anonymous closure> (dart:async/zone.dart:1112:29) 
#1 _microtaskLoop (dart:async/schedule_microtask.dart:41:21) 
#2 _startMicrotaskLoop (dart:async/schedule_microtask.dart:50:5) 
#3 _runPendingImmediateCallback (dart:isolate-patch/isolate_patch.dart:116:13) 
#4 _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:173:5)

这里吐槽一下Dart的StackTrace，崩溃日志完全没有打印出现场，T_T，但是可以明确的是问题肯定发生在Dart SDK 的 dart:io library中。于是，为了定位问题，下载SDK代码，编译，跟踪：

下载代码 github.com/dart-lang/s…
编译指导 github.com/dart-lang/s…
编译debug 版本

cd dart-sdk/sdk
./tools/build.py --mode debug --arch x64 create_sdk

这里再一次吐槽一下Dart，SDK编译以后，调试时竟然不能打断点跟踪，后续有时间需要分析一下原因。此处省略定位流程(后续补充HttClient源码分析，敬请期待)。通过跟踪代码逻辑，最终定位到崩溃地址如下：

  static Future<RawSecureSocket> secure(RawSocket socket,
      {StreamSubscription<RawSocketEvent> subscription,
      host,
      SecurityContext context,
      bool onBadCertificate(X509Certificate certificate),
      List<String> supportedProtocols}) {
    **//crashed at the following line. socket == null**
    socket.readEventsEnabled = false;
    **//crashed at the following line. socket == null**
    socket.writeEventsEnabled = false;
    ......
  }

HttpClient设置代理，此处socket == null；但是socket为什么为null未知；

STEP 4 根本原因定位：

问题已经定位，但是根本原因并不清楚：socket为什么为null，正常的代理流程应该是什么样。因此，我考虑抓一个正确的场景日志作参考：本机建立了两个proxyserver，一个是tinyproxy，一个是lantern。根据Http协议，客户端首先向proxy server 发送Connect 请求：

CONNECT www.google.com:443 HTTP/1.1
user-agent: Dart2.5(dart:io)
accept-encoding:gzip
content-length:0
host:www.google.com:443

tinyproxy 回复：程序正常运行

HTTP/1.0 200 Connection established
Proxy-agent: tinyproxy/1.8.4

lantern 回复：

HTTP/1.1 200 OK
Date: Wednesday, 14-Aug-19 16:13:22 CST
Keep-Alive: timeout=58
Content-Length: 0

崩溃！
于是，跟踪HttpResponse解析流程，发现 http_parser.dart, _HttpParser._onData 中在处理Http响应有差异。收到lantern的响应后，由于"Content-Length: 0"，_HttpParser关闭了socket，从而导致上述socket == null。而tinyproxy走不同的分支，socket得以保留，所以没有问题。

 http_parser.dart

bool _headersEnd() {
......
if (_transferLength == 0 ||
(_messageType == _MessageType.RESPONSE && _noMessageBody)) {
_reset();
var tmp = _incoming;
 *****socket will closed here as "Content-Length: 0"
_closeIncoming();
_controller.add(tmp);
return false;
} else if (_chunked) {
_state = _State.CHUNK_SIZE;
_remainingContent = 0;
} else if (_transferLength > 0) {
_remainingContent = _transferLength;
_state = _State.BODY;
} else {
*****tinyproxy will go to this branch. not closing socket
// Neither chunked nor content length. End of body
// indicated by close.
_state = _State.BODY;
}

因此，修改方案也很简单，增加一个_keepAlive flag，当Http Response 中有 Keep-Alive 字段时，走tinyproxy分支，不关闭socket。

void _doParse() {
...
if (headerField == "keep-alive") {
_keepAlive = true;
}
...

if ((_transferLength == 0 && !_keepAlive) // 不走这个分支，走else
...

本地测试，问题解决。

最后

洋洋洒洒一大篇，如流水帐一样记录了一下Dart SDK的问题定位流程。回头来看，pub使用了代理，只不过dart:io 使用代理时出现了兼容性问题。目前这个问题已经提了issues/37808，因为涉及到HttpResponse字段的解析，需要对HTTP协议详细分析后才能修改。所以，待最终方案入库后SDK更新才能解决pub error的问题。不过对于我本地而言，使用本地SDK编译的pub已经可以正常工作了。
写几点学习DART的体会吧：

Dart的优点：现代化的编成语言，拥有最流行的语言特性（async-await, stream, future）,单线程模型降低编码难度，提升gc效率。最关键的是基于dart的flutter框架真正的支持跨平台，Android，iOS，Fuchsia一统天下，前景无限光明。
Dart的不足：太年轻，不够成熟稳重例如本文这个问题可以归类为一个兼容性问题。目前DART还很年轻，有很多类似的兼容性的问题可能还会出现。我使用 JAVA 的 APACHE HttpClient写了一个测试程序就没有这样的问题。JAVA生态成熟度要远高于Dart
DART 还需要在易用性问题上作更好的修改，例如目前遇到的StackTrace不太友好，SDK中的文件不能单步跟踪调试等，对开发人员都形成了一些障碍。
一点建议：对于dart:io 这个lib，大量的代码还是以Future<>.then 的方式写的，如果用async await方式改写，会更好理解些。

总之，DART 有风险，如坑需谨慎，道路或曲折，前途很光明。

Flutter填坑笔记：从flutter pub get error 开始，定位Dart SDK问题

STEP 1： 分析入口：flutter pub get 的处理流程 (flutter_tools)

STEP 2： 缩小范围：pub get 的处理流程 (pub)

STEP 3: 问题定位：DEMO复现, 编译SDK，跟踪SDK逻辑

STEP 4 根本原因定位：

最后

STEP 1：分析入口：flutter pub get 的处理流程 (flutter_tools)

STEP 2：缩小范围：pub get 的处理流程 (pub)