阿里妹导读：对于开发者而言，Flutter工程和我们的Android/iOS工程有何差别？Flutter的渲染和事件传递机制如何工作？构建缓慢或出错又如何去定位，修改和生效呢？凡此种种，都需要对Flutter从设计，开发构建，到最终运行有一个全局视角的观察。
本文由闲鱼技术团队出品，将以一个简单的hello_flutter为例，介绍下Flutter相关原理及定制与优化。
Embedder是一个嵌入层，即把Flutter嵌入到各个平台上去，这里做的主要工作包括渲染Suce设置,线程设置，以及插件等。从这里可以看出，Flutter的平台相关层很低，平台(如iOS)只是提供一个画布，剩余的所有渲染相关的逻辑都在Flutter内部，这就使得它具有了很好的跨端一致性。
Debug模式：对应了Dart的JIT模式，又称检查模式或者慢速模式。支持设备，模拟器(iOS/Android)，此模式下打开了断言，包括所有的调试信息，服务扩展和Observatory等调试辅助。此模式为快速开发和运行做了优化，但并未对执行速度，包大小和部署做优化。Debug模式下，编译使用JIT技术，支持广受欢迎的亚秒级有状态的hot reload。
Release模式：对应了Dart的AOT模式，此模式目标即为部署到终端用户。只支持真机，不包括模拟器。关闭了所有断言，尽可能多地去掉了调试信息，关闭了所有调试工具。为快速启动，快速执行，包大小做了优化。了所有调试辅助手段，服务扩展。
Profile模式：类似Release模式，只是多了对于Profile模式的服务扩展的支持，支持，以及最小化使用信息需要的依赖，例如，observatory可以连接上进程。Profile并不支持模拟器的原因在于，模拟器上的诊断并不代表真实的性能。
其中gen_snapshot是dart编译器，采用了tree shaking(类似依赖树逻辑，可生成最小包，也因而在Flutter中了dart支持的反射特性)等技术,用于生成汇编形式的机器代码，再通过xcrun等编译工具链生成最终的App.framework。换句话说，所有的dart代码，包括业务代码，三方package代码，它们所依赖的flutter框架代码，最终将会变成App.framework。
不同于AOT模式下的App.framework是Dart代码对应的本地机器代码，JIT模式下，App.framework只有几个简单的API，其Dart代码存在于snapshot_blob.bin文件里。这部分的snapshot是脚本快照，里面是简单的标记化的源代码。所有的注释，空白字符都被移除，常量也被规范化，也没有机器码，tre西野花梨e shaking或者是混淆。
鉴于Android和iOS除了部分平台相关的特性外，其他逻辑如Release对应AOT，Debug对应JIT等均类似，此处只涉及两者不同。
isolate/vm_snapshot_data/instr均最后位于app的本地data目录下，而这部分又属于可写内容，因此可以通过下载并替换的方式，完成App的整个替换和更新。
在介绍了iOS/Android下的Flutter编译原理后，下面着重描述下如何定制flutter/engine以完成定制和优化。鉴于Flutter处于敏捷的迭代中，现在的问题后续不一定是问题，因而此部分并不是要去解决多少问题，而是选取不同类别的问题来说明解决思。
Flutter是一个很复杂的系统，除了上述提到的三层架构中的内容外，还包括Flutter Android Studio(Intellij)插件，pub仓库管理等。但我们的定制和优化往往是在flutter的工具链相关，具体代码位于flutter仓库的flutter_tools包。接下来举例说明下如何对这部分做定制。
当开发者在研发中发现flutter有些卡顿时，猜测可能是逻辑的原因，也可能是因为是Debug下的flutter。此时可以构建release下的apk，也可以将flutter强制修改为release模式如下：
事实上flutter本身是支持iOS下的armv7的，但目前并未提供支持，需要自行修改相关逻辑，具体如下：
例如我们想了解flutter在构建debug模式下的apk的时候，具体执行的逻辑如何，可以按照下面的思走：
假设我们在flutter beta v0.3.1的基础上进行定制与业务开发，为了稳定，一定周期内并不升级SDK，而此时，flutter在master上修改了某个v0.3.1上就有的bug，记为fix_bug_commit。如何才能和管理这种情形呢？
另闲鱼技术团队诚聘各英才，flutter，C++，iOS/Android，Java都要，欢迎简历来砸。联系邮箱
本文由 恒宇国际（www.neivn.cn）整理发布
网友评论 ()条 查看