在使用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代码，编译，跟踪：
- 下载代码 https://github.com/dart-lang/sdk
- 编译指导 https://github.com/dart-lang/sdk/wiki/Building
- 编译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 有风险，如坑需谨慎，道路或曲折，前途很光明。
