干货 | 京东技术中台的Flutter实践之路

在 2019 年，Flutter 推出了多个正式版本，支持的终端愈来愈多，使用的项目也愈来愈多。Flutter 正在经历从小范围尝鲜到大面积应用的过程，愈来愈多的研发团队加入到 Flutter 的学习热潮中，京东做为互联网大厂之一也积极参与了 Flutter 的跨端方案研究。本文将介绍京东在 Flutter 上的应用方案和相关优化成果。

为何考虑Flutter技术方案

其实京东很早就开始研究并实践跨端的开发解决方案，最先使用的是Hybrid App的技术方案，从2015年低开始逐步转向RN技术栈，目前应该是业内RN技术平台应用最普遍、配套设施比较完善的公司之一。从2018年中开始，咱们也关注到了Flutter技术，最吸引咱们的特性是高性能和兼容性。这两点也是目前RN技术相对不足的地方。高性能指的是复杂场景和交互下的渲染性能，兼容性指的是不一样终端平台上的布局和体验的一致性，这点在碎片化严重的android平台上尤为重要。

京东在Flutter的实践

随着2018年末Google正式发布了Flutter预览版本，京东内部也愈来愈多的研发团队有用Flutter进行开发业务的诉求。咱们正式启动研发并内部发布了JDFlutter引擎。在官方Flutter引擎之上，咱们作了额外的优化和功能扩展：

• Flutter工程改造： 对Flutter开发环境和dart代码管理进行优化，能够无缝集成到现有APP中并支持自动化dart编译打包，便于开发和调试。

• 路由及多页面管理： 对原生页面和flutter页面实现了集中路由管理，能够双向传参、跳转而且进行了共享内存优化。

• 扩展UI组件库： 官方支持的Material和Cupertino样式不能知足需求，咱们内部实现了自定义样式的组件库。

• 原生能力扩展： 对官方原生能力进行了扩展，封装了包括网络、登录、埋点等等基础能力的打通并提供了50+原生扩展API。

• Android端动态化支持： 在Android端实现了动态化支持，能够线上热更新业务。iOS端暂不支持动态化。

目前京东商城、京东视频、京东到家、京东物流、7Fresh等APP都有业务采用JDFlutter进行开发。

JDFlutter框架设计

JDFlutter总体的框架结构，主要包含：基础框架、组件、工具三部分，如图所示：

 

基础框架

JDFlutter基础框架分为三层架构，包含JDFlutter基础层，通用业务层，业务层。

• 基础层：提供了Flutter的基础组件支持，包括组件管理，状态管理等；基础层彻底独立，对业务没有依赖。

• 通用业务层：提供了通用型业务组件支持，例如登陆组件，支付组件等；通用业务层依赖于基础层。

• 业务层：即具体业务逻辑实现层，根据业务须要进行不一样组件的组合，实现业务页面的快速开发。

 

核心组件

• 组件管理：组件之间经过标准的协议接口进行通讯，下降组件耦合，便于维护及组件升级；

• 状态管理：实现数据和界面分离，统一状态管理，以数据的变化来驱动界面的改变，更有利于数据的持久化和保存，同时也有利于UI组件的复用；

• Hybrid Router：主要解决Flutter和Native之间交叉跳转的问题，减小内存开销，共享同一个Flutter Engine。

工具介绍

• 编译发布：优化Flutter原有的编译逻辑，管理依赖Flutter原生依赖关联，打包Flutter和原生代码，实现自动化构建发布。

• 资源管理：管理图片资源，将资源转换成Flutter类，便于资源的读取操做，相似Andorid的R类；

• 模版代码生成：减小Flutter的代码编写，自动生成Flutter 组件的框架模板代码，提高代码编写效率；

• JSON转换：将JSON数据转换成Flutter code，并提供json转Flutter对象的API，减小动手编写Flutter code及解析。

JDFlutter业务开发实践

JDFlutter为业务研发团队提供了全流程的开发解决方案：

 

配置混合工程

Flutter和原生混合开发有两种状况，其一，开发Flutter业务的同窗，须要和原生作交互，所以须要有Flutter和原生的混合编译环境；其二，使用原生SDK开发业务的同窗，须要和Flutter业务一块儿集成打包，此时需对Flutter透明，以减小对Flutter编译环境的依赖，而且，只依赖原生编译环境便可，此时咱们将Flutter编译成aar依赖，放入原生项目中便可。接下来，咱们将重点介绍Android和iOS的混合编译环境配置。

Android平台配置

建立一个flutter module

flutter create -t module --org com.example my_flutter

在原生根项目的settings.gradle加入以下配置信息

// MyApp/settings.gradle
include ':app'                        // assumed existing content
setBinding(new Binding([gradle: this]))              // new
evaluate(new File(                                   // new
settingsDir.parentFile,                              // new
  'my_flutter/.android/include_flutter.groovy'       // new
))

在原生App模块中加入flutter依赖

dependencies {
  implementation project(':flutter')
}

这样就能够原生项目一块儿编译了。具体能够参照官方文档：github.com/flutter/flu…这样的方式虽能够知足混编需求，但还不是特别方便，开发完项目后，还须要去Android Studio项目中进行编译，比较麻烦，因此咱们也能够把Flutter项目settings.gradle改造，在Flutter开发环境下直接运行包含原生代码的混合项目，改造方式以下

// MyApp/settings.gradle
//projectName 原生模块名称
//projectPath 原生项目路径
include ":$projectName"
project(":$projectName").projectDir = new File("$projectPath")

这样改造以后便可在Flutter IDE中直接编译Flutter混合工程，并进行调试，也能够运行futter run来启动Flutter混合工程，不过在配置的时候，须要注意Flutter中 gradle编译环境和原生编译环境的一致性，若是不一致可能会致使编译错误。

iOS平台配置

建立flutter module

flutter create -t module my_flutter

进入iOS工程目录，初始化pod环境（若是项目工程已经使用Cocoapods，跳过此步骤）

pod init

编辑Podfile文件

#在Podfile文件添加的新代码
flutter_application_path = '/{flutter module目录}/my_flutter'
eval(File.read(File.join(flutter_application_path, '.ios', 'Flutter', 'podhelper.rb')), binding)

安装pod

pod install

打开工程(***.xcworkspace) 配置build phase，为编译Dart 代码添加编译选项打开iOS项目，选中项目的Build Phases选项，点击左上角+号按钮，选择New Run Script Phase，将下面的shell脚本添加到输入框中：

"$FLUTTER_ROOT/packages/flutter_tools/bin/xcode_backend.sh" build
"$FLUTTER_ROOT/packages/flutter_tools/bin/xcode_backend.sh" embed

 

搭建PUB私服仓库

Flutter开发中使用的组件，通常公司内部会采用共享的方式，以免重复开发，而Flutter组件共享，即须要使用pub仓库。因为公司内部的业务组件不适合上传到pub官方仓库，所以，须要搭建私服仓库，以解决各个业务研发团队，对Flutter组件共享须要。感兴趣的同窗能够研究下官方pub仓库的源码 pub.dartlang.org/，其对Google Cloud 环境有很大的依赖 ， 也能够基于https://github.com/kahnsen/pub_server来搭建一个简易版本的私服仓库，以知足上传和下载功能，pub协议相对比较简单，咱们能够在源码增长协议接口来实现更多功能。运行pub_server

~ $ git clone https://github.com/dart-lang/pub_server.git
~ $ cd pub_server
~/pub_server $ pub get
...
~/pub_server $ dart example/example.dart -d /tmp/package-db
Listening on http://localhost:8080

To make the pub client use this repository configure your shell via:

    $ export PUB_HOSTED_URL=http://localhost:8080

发布一个Flutter组件须要修改 pubspec.yaml，增长如下内容:

name: hello_plugin //plugin名称 
description: A new Flutter plugin. //介绍
version: 0.0.1//版本号
author: xxx <xxx@xxx.com>//做者和邮箱
homepage: https://localhost:8080 //组件的介绍页面
publish_to: http://localhost:8080//仓库上传地址

上传时可使用以下命令检查代码错误，并显示出上传的目录结构。

pub publish --dry-run

若是有不想上传的文件，能够在根目录增长一个.gitignore文件来忽略以下:

/build

Flutter组件的依赖配置，在项目的pubspec.yaml中dependencies:下增长以下信息：

dependencies:
hello_plugin:
  hosted:
    name: hello_plugin
    url: http://localhost:8080 
    version: 0.0.2

这样能够在公司内部实现Flutter组件共享，若是不想搭建本身的pub仓库，也能够采用git依赖，配置以下:

dependencies: hello_plugin: git: url: git://github.com/hello_plugin.git //git地址 ref: dev-branch //分支

dependencies:
  hello_plugin:
    git:
      url: git://github.com/hello_plugin.git //git地址
      ref: dev-branch //分支

Flutter业务的开发与调试

在Flutter IDE中编译代码调试会很方便，直接点击debug按钮便可进行代码调试，若是是混合工程在Android studio或者xcode中运行的工程，则没办法这么作，但也能够实现调试：将要调试的App安装到手机中（安装debug版本），链接电脑，执行以下命令，同步Flutter代码到设备的宿主App中

$ cd flutterProjectPath/
$ flutter attach

执行完命令后会进行等待设备链接状态，而后打开宿主App，进入Flutter页面，看到以下信息提示则表示同步成功

zbdeMacBook-Pro:example zb$ flutter attach
Waiting for a connection from Flutter on MI 5X...
Done.
Syncing files to device MI 5X...                             1.2s

🔥  To hot reload changes while running, press "r". To hot restart (and rebuild state), press "R".
An Observatory debugger and profiler on MI 5X is available at: http://127.0.0.1:54422/
For a more detailed help message, press "h". To detach, press "d"; to quit, press "q".

打开http://127.0.0.1:54422能够查看调试信息，若有代码改动能够按r来实时同步界面，若是改动没有实时生效能够按R从新启动Flutter应用。

JDFlutter热更新实践

大部分跨端框架，诸如React Native / Weex / H5等，基本都能作到随时进行热修复，并随时上线，用于及时修复突发的在线问题，架构很是灵活。Flutter因其AOT的设计，预想会很难达到这种灵活度，但技术上仍具备必定的可行性，正如咱们在以前的Flutter介绍文章中提到的，按照先有的API设计，是能够支持热修复的，但仅限于Android。官方最新的架构上已经支持了热修复架构，你们能够更新到1.2.1版本查看，可是官方的功能还比较弱，没法作到版本控制和回滚的灵活性，因此JDFlutter并无采用。咱们能够首先一块儿看一下Google官方热修复方案的设计原理：Flutter1.2.1 版本引入了 Dynamic Patch

为了更清楚的了解官方热修复的原理和过程，咱们须要首先深刻了解Flutter的业务包结构和总体运行过程：

Flutter App的包结构

能够看到主体代码集中在asset目录中，除此以外还有少许Android端的框架java代码及flutter so引擎库外：

一、icudtl.dat

二、isolate_snapshot_data

三、isolate_snapshot_instr

Flutter包的初始化流程

Flutter页面启动时是如何加载这些代码的呢？那就要从Flutter的初始化提及了，在页面启动前须要调用FlutterMain.startInitialization来作初始化：

能够看到该初始化是要求在主线程完成的，另外主要完成了如下三点：

• 配置了一些环境数据，好比各个核心包的路径，主要是提供给其余一些模块全局调用

• 检查 asset 下 Flutter 包的完整性，主要是上面介绍的一些核心包，一旦缺乏核心的一些库，就会直接抛异常。开发过程当中咱们常常由于配置致使有些文件没有打包进去，而后会直接 crash，就是在这里触发的，具体代码以下：

• 解压部分 asset 下的资源到 data 分区，如下是一些片断的代码，那为何要解压呢？放在 asset 下也是能够经过 assetManager 读取的。这里 google 应该是从性能角度要求解压的，由于频繁的使用 assetManager 读取 asset 是很容易形成多线程阻塞的，一旦阻塞了将会致使整个 Flutter 业务所有没法渲染，因此须要解压一些核心的资源库，而不是解压了全部的资源 (例如图片就没有解压)

从代码来看，先增长要解压的核心库的目录，而后启动 task 从 asset 中解压库到 data 分区对应 app 数据下的 app_flutter 目录，如下是解压后的目录结构：

其中 res_timestamp 文件用于标记一些时间戳，算法比较固定，根据客户端的安装时间及 app 的 version code 生成，也就是说当用户打开 Flutter 页面后这个值就是固定的，若是有任何修改引擎会默认有变化，删除现有 app_flutter 的包，从新解压

 

运行原理

上面是对Flutter程序加载的分析，最终Flutter页面显示是须要呈如今原生组件Flutter View中的，这个组件会和底层Flutter Native View 进行绑定，并最终运行上面说到的data分区的Dart代码来渲染UI。若是使用的是Flutter Activity，则默认Flutter View是全屏显示，如须要定制页面，须要本身设计Activity。

热修复实验

了解了这些，其实热修复方案已经呼之欲出，替换原有解压后的app_flutter包，杀进程，而后从新加载Flutter页面便可。这里咱们能够作个简单的实验：采用adb命令push一些修改过的并编译的dart代码到app_flutter目录：

• 先打开Flutter页面，默认会加载asset下的包，并解压到data分区

• 修改一个Flutter工程，并编译代码，最终在工程目录my_flutter/.android/Flutter/build/intermediates/flutter/release中看到打包生成的文件

• 这么文件目录中只有 flutter_assets 目录和 isolate_snapshot_data 文件是包含业务代码和图片的，其余部分基本不会变化，因此咱们这里要替换的目录也就是这两个，你们可使用 adb push 命令将资源文件 push 到对应的 data 分区来作个实验。

adb push my_flutter/.android/Flutter/build/intermediates/flutter/release/isolate_snapshot_data /data/data/app包名  /app_flutter

 

• 关闭 Flutter 页面，在 Task 中杀掉进程，回来后从新打开 Flutter 页面，就能看到改动的效果，图片资源是存放在 flutter_asset 目录的，将图片放到这个目录，一样能更新图片

上面这个实验，验证了方案基本是可行的，但这里只是简单替换，实际使用中替换仍是有不少问题的。那 Google 官方是如何设计的呢？

Google热修复设计

热修复步骤

Flutter SDK 1.2.1中，Google提供了ResourceUpdater，用来作包的检查和下载解压。升级步骤以下：

• 在页面初始化时，检查固定的下载更新目录有没有业务升级包，从代码来看，必须在manifest中打开该功能，设置DynamicPatching

从逻辑上来看，只有在页面 onResume 或者 App 从新开启的时候会下载升级包，总体下载是经过 http 请求完成的，总体实现代码你们能够参考 ResourceUpdater 中 DownloadTask 的实现部分，这里就不细说了。

• 每次 init 的时候都会触发检查 data 分区的 app_flutter 包，若是不存在就会从 aaset 目录解压出来，而升级包的替换就是在这步完成的，按照逻辑会优先检查升级目录有没有包存在，若是存在则优先从升级目录解压，若是不存在仍是从 asset 目录解压；

• 固然在检查到有升级包时，会对升级包的一些配置作校验，主要是 manifest.json 文件，里面会包含 buildNumber/baselineChecksum 字段，同时也会对"isolate_snapshot_data", "isolate_snapshot_instr", "flutter_assets/isolate_snapshot_data"等文件作 CRC32 校验。

 

• 升级后的版本时间戳是从配置的 manifest.json 文件中读取 patchNumber 和文件下载时间肯定的，完成文件覆盖后会从新生成。

如下是升级包的大概路径以下：

如何配置服务器

文章上部分介绍了怎么打开升级patch的功能，因升级涉及到服务端，那Google是怎么作到关联到服务器的呢？其实原理比较简单，须要配置客户端的manifest文件的meta属性，增长PatchServerURL，也就是咱们服务的地址，以及下载模式PatchDownloadMode和加载模式PatchInstallMode，默认是ON_NEXT_RESTART（下次初始化时）

总体流程

存在的缺陷

• 过于定制化，所有在引擎完成，很难适配一些特殊的需求定制；

• 不支持如今比较主流的升级流程，诸如灰度和白名单等功能；

• 版本号的维度很差控制，同时不能作版本回滚等操做。

JDFlutter如何实现热修复

实现原理

JDFlutter的总体实现原理，其实和Google是同样的，目前来看不修改引擎的前提下，只有这种方案最简单，可是咱们没有使用Google的这套升级架构，默认关闭了patch功能，并框架以外实现了替换包和加载的逻辑，优势是总体兼容性更强、更灵活。一、服务端根据客户端的惟一标识支持了白名单和灰度下发升级包；二、优化下载和替换流程。Flutter的升级包通常有4-5M，并且从网络端获取，失败率较高，替换过程又涉及到文件操做，操做不当容易产生UI阻塞或者包异常。接入JDFlutter的客户端下载包后，并不会直接替换文件，而是修更名称后解压到app_flutter目录，等待业务页面从新打开或者从新初始化时再修改为Flutter标准名称的文件。这种操做不存在性能问题，另外会把旧版的文件备份，以便回滚代码；三、同时并发运行的Flutter页面较多，需避免由于升级出现一些中间状态，使得业务或者页面没法打开的状况；四、升级失败或者下载后业务包有问题，出现没法加载的状况或者文件丢失的状况能够控制回滚代码；五、线上出现大量异常后，能够指定对应的Flutter业务执行降级策略，让该业务迅速降级到H5页面。

热修复规划

将来，JDFlutter会继续在热修复方面进行探索和验证，以知足京东业务的快速发展须要。而针对目前的方案，咱们思考了以下的优化点：Flutter业务包差量升级：现有的升级模式都是全量包覆盖，即便压缩后升级包仍是很大，影响升级成功率及用户流量，后续会采用一些diff工具，对比生成差量的patch，经过服务端下发后，在客户端合并成完整包，但升级次数较多后会致使最终版本碎片化，须要作好版本以前的维护关系，难度较大。

升级后及时更新页面：现有方案（包括标准google升级方案）没有办法作到下载业务包或者替换业务包后及时刷新页面，须要restart进程后从新开启才能刷新页面。将来咱们会优化引擎，经过释放底层资源并从新加载，来完成随时刷新页面的功能。

将来展望

Google Flutter是很是出色的跨端开发技术，如今已经取得了长足的发展。社区生态和框架成熟度也正在快速追赶RN。相信不久的未来，Flutter+RN必定会成为跨端开发平台的绝代双骄。

点击“京东云”了解京东云移动跨端开发解决方案