概要

Flutter 1.17 | 2020 首个稳定版发布！ 全线迁移到AndroidX,现有app迁移成本巨大(几乎不可能迁移)

• 改造Flutter engine、工具链，1.17支持support库
• 跟一下工具链flutter create的源码实现方式

概览

• 将上一节中UI线程生成了laytertree，交给GPU线程的rasterizer
• 调用LayerTree的Preroll、Paint2个方法，完成所有Layer的绘制前准备以及绘制操作
• 将纹理化的结果，上屏

概览

这一部分的主要工作是WidgetTree转化成LayerTree，主要分为下面几个阶段

• Animate: 首先执行动画，这个过程可能会改变状态state
• Build: 重新build脏节点的widget（状态改变）
• Layout: 对脏节点进行重新的layout
• Paint: 脏节点重新绘制
• 更新layertree，提交给gpu线程

流程还是比较清晰、容易理解的

概览

解决2个问题

• 容器和engine的对应关系
• 路由管理

核心点

主要分为3个部分

• 启动Engine前的准备(Platform端Android)
• Engine的启动(创建DartVM、相关线程、初始化相关配置)
• Engine加载Dart产物，直到执行main.dart中的main方法

给官方提交了相关PR给官方，支持engine异步初始化

Engine创建流程不是很合理，底层在做异步任务的时候，主线程会wait阻塞，非常影响体验。

概述

其中，前3个基本是面向前端生态的解决方案，而Flutter更像是面向native生态的解决方案。

当然也有基于这几种方案之上，各种各样的魔改方案

Weex架构原理

• JSFRAM 负责和JS框架(VUE/RAX)交互，生成DomTree，将数据传给WeexCore
• WeexCore 有3部分
  • JSSide: 运行在JS进程中，负责jsbinding、创建、管理js的vm、context
  • CoreSide: 运行在主进程中，负责layout以及将RenderTree以命令形式交给Platform绘制
  • IPC: 跨进程通信
• Platform(Android/iOS)
  • 将RenderTree转化为平台对应的ViewTree,进行渲染
  • native能力调用提供
• JSRuntime: 底层封装JSC/V8接口，WeexCore使用JSRuntime和jsengine通信

Weex架构图如下

概览

进程通信方式

线程同步

|||

概述

对应官网文档地址

将流程分为三大部分

概述

对应官网文档地址

接上篇 ,继续 6-10 步的启动过程。