头条 Flutter iOS 混合工程实践

来源:http://www.sh-fengwen.com 作者:美高梅游戏平台网站 人气:97 发布时间:2019-10-03
摘要:Flutter 1.0的发布对我们来说是一个很重要的起点,长路漫漫,我们仍有很多工作要做。这里我们向大家公开我们的产品路线图规划,一方面是保持开源项目的透明度,同时开发者们也可

Flutter 1.0 的发布对我们来说是一个很重要的起点,长路漫漫,我们仍有很多工作要做。这里我们向大家公开我们的产品路线图规划,一方面是保持开源项目的透明度,同时开发者们也可以通过我们的工作优先级以制定更适合的工程方案。

从 App Store 下载或更新头条(6.9.2 或以上版本),找到 懂车帝 -> 热门车型,点击打开后即可体验 Flutter 的页面效果。

以下几点是我们今年会着重关注的:

图片 1image

1.核心和基础

由于前期业务改造顺利,线上 Crash 少,性能良好,目前我们正在进行小视频模块的 Flutter 重构,即将上线。

2.易用性

本文主要介绍头条 iOS 端在接入 Flutter 的过程中,选择的技术方案,遇到的问题和未来的计划。虽然是以 iOS 为例,但很多内容都是双端通用的。

3.生态系统

为了方便对 Flutter 零基础读者阅读本文,首先介绍一些 Flutter 的基础知识。

4.移动端之外的支持

当我们写完 Dart 代码后,需要编译后才能给客户端使用。Flutter 的产物分为两种模式,一个是 Debug 模式,采用 JIT(Just In Time)的方式,类似于解释型语言,好处是可以支持热更新,方便调试。另一种是 AOT(Ahead Of Time)模式,类似于编译型语言,好处是性能比较好。

5.动态更新

因此在开发中,我们一般使用 Debug 模式的产物来提升调试效率,正式上线后再换成 Release 模式获得极致的性能。不管是哪种模式,在 iOS 下的产物都是三个:

6.工具链

  1. App.framework:和 flutter 的业务逻辑相关,在 Debug 模式下就是一个很小的空壳,在 Release 模式下包含全部业务逻辑
  2. flutter_assets:也和 flutter 的业务逻辑相关,在 Debug 模式下包含全部业务逻辑,在 Release 模式下很小。
  3. Flutter.framework:实现 Flutter 框架自己的逻辑

我们的计划会根据大家的反馈以及新的市场变化来做调整,这份路线图里的内容不尽然是我们一定会完成的工作。如果你有任何反馈,我们鼓励你通过 Issuse,或者在我们的邮件群组等与我们保持联系。Flutter 是一个开源项目,我们鼓励你参与到我们当中来。

目前主流的方案中主要有两种,一种在 Google 的官方文档里 ,它最大的问题在于, 需要创建一步 BUILD PHASE 调用 shell 脚本去编译 Flutter。编译 Flutter 的过程需要本机有 Flutter 环境才行。

使用 Flutter 的开发者们可以选择一个「频道」来「接收」我们的版本更新和变化,我们目前有四个频道:master、dev、beta 和 stable,质量和稳定性从前向后依次递增,发布速度当然也会是依次相对放缓。

这显然是不能接受的。其实我们先不考虑 Flutter 这件事,不管是搭建什么类型的混合工程,都一定要保证以下两点:

我们计划每个月发布一个 beta 频道的版本,这个发布通常会是在月初,全年会在 stable 频道发布四个较大的“正式”版本发布。在生产环境里,我们建议开发者们使用 stable 频发布的 Flutter 版本。如果你想了解更多关于我们的版本发布流程,可以查看 发布流程 这篇 Wiki。

  1. 对原生工程无侵入:原生工程可以增加组件的依赖,但不能修改主工程的配置,更不能让原生工程对环境产生新的依赖。
  2. 方便调试:不管是原生工程开发,调试新接入的模块(比如 Flutter),还是模块开发调试原生工程,都应该支持断点调试。

核心和基础

很明显,官网的方案不满足第一点要求,我们不能让每个参与原生工程开发的同学,本机都安装 Flutter 环境。

我们的首要任务依然是为 Flutter 现有的核心和基础添砖加瓦:

从 Flutter 的官网教程 中可以看到,它支持 flutter run 命令或者从 IDE 启动 iOS 工程。其实只要观察一下 ios 目录下的 Runner.xcworkspace 工程就会发现,Flutter 项目运行的就是这个工程。当然如果直接把我们的 iOS 工程拷贝过来是无法运行的。

修复 Bug:Bug 修复的优先级主要是基于 Issue 下的互动数量,比如 GitHub 自带的一些针对 Issue 的表情互动,点赞等;

至少在目前最新的 dev 分支(Tag:v0.10.0)上是不行的,因为 flutter 的代码中写死了工程的名字就是 Runner,可以验证一下:

性能调优:包括减少内存、引擎占用空间,提高帧率等。如果开发者们有特别的性能基准要求,可以通过 devicelab 测试数据给我们看一下;

图片 2image

改进 Flutter 测试流程:以确保为开发者们提供稳定的版本构建不会出现版本回归;

这也就催生了目前主流的,也是闲鱼最先介绍的方案,魔改 Flutter 源码,让它能运行自己的工程。然而个人觉得这种方式还是太 trick,主要有两个问题:

改进错误消息提醒:通过 Google 用户研究(User Research)团队的工作,使错误提醒更具备可操作性以及包含一些常见的解决方案;

  1. 后续如果 Flutter 升级了,还得把修改的部分应用到新的分支上去,并且修复冲突。
  2. 如果公司或者业内有别的团队要用,接入成本比较高。

API 文档改进:特别是提供示例代码和图表等,让我们的 API 文档更易用。

观察一下 Runner 的工程结构:

易用性

图片 3image

为新晋使用 Flutter 的开发者清扫绊脚石,如:

再看一眼 Flutter 编译脚本就会发现,这一步并不是必须放在主工程的 BUILD 阶段进行。只要拥有 Flutter 的编译产物,项目就可以接入 Flutter 的功能了。因此头条选择的方案是:

1.完善和满足希望使用混合工程,即将 Flutter 应用于现有工程项目的开发者们的需求,如提供新的插件模板和 Android 内嵌 API;

  1. 利用 flutter build iosflutter build ios --debug 命令,先后构建两种模式下的产物并上传到 CDN
  2. 构建一个 Pod,并且让 Pod 依赖上述产物

2.更新 Flutter 官方文档以提供更详尽的文档和使用教程;

在第一步中,运行 flutter build ios 实际上会依赖 Runner 工程,相当于是我们借助这个空壳去得到产物。不过要想编译通过,还需要做如下两个微小的改动:

3.在 Flutter 应用里管理 state 的最佳实践;

  1. 修改项目的 Bundle ID,使用自己的证书。否则无法通过签名
  2. 打开 Xcode -> File -> Workspace -> Setting,把 BUILD_SYSTEM 切换为 Legacy,否则会产生编译错误

4.更好的帮助 iOS 开发者:投入时间持续更新和维护我们的 Cupertino widgets;

第二步中,重点在于如何让 Pod 动态的下载资源,因为需要指定使用哪个版本,哪种模式的 Flutter 产物。我们目前的策略是在打包机器上使用 Release 模式产物,在开发机器上使用 Debug 模式产物。

5.在非完整工具链和运行环境下更容易体验和使用 Flutter。

至于动态指定版本号,可以这样写:

本文由美高梅游戏平台网站发布于美高梅游戏平台网站,转载请注明出处:头条 Flutter iOS 混合工程实践

关键词:

上一篇:没有了

下一篇:没有了

频道精选

最火资讯