域名备案了 怎么建设网站,网站建设的问题疑问,文化馆的网站怎么建设,网站平台多少钱王康#xff08;正物#xff09;—— Flutter 官方成员 阿里巴巴技术专家#xff0c;之前主要负责 Flutter 在闲鱼中的混合开发体系#xff0c;目前重点关注 Flutter 深入度以及生态相关的工作。本文将分享三方面内容#xff0c; Flutter 的原理、 Flutter 在闲鱼中的应用…
王康正物—— Flutter 官方成员 阿里巴巴技术专家之前主要负责 Flutter 在闲鱼中的混合开发体系目前重点关注 Flutter 深入度以及生态相关的工作。本文将分享三方面内容 Flutter 的原理、 Flutter 在闲鱼中的应用最后介绍我们在深度方面的一些探索。
01、Flutter 原理 当我们谈到跨平台框架时可能会想到很多备选方案。包括早期的 HTML 和 Cordova , 后来的 React Native Weex 以及这两年很是流行的 Flutter 它们都在不同阶段不同程度上解决了我们对跨平台的诉求。如果我们从一些关键指标包括动态性、性能来观察他们的区别还比较明显。
HTML 和 Cordova 具有最好的动态性但他们的性能却是最差的RN / Weex 具有良好的动态性。Flutter 则是一个纯原生的设计其设计使它天生具有很好的性能与跨端一致性。 Flutter 是如何实现优秀的性能和跨端一致性的呢从设计上可以看出 Flutter 在操作系统之上包含了三个层次。最下面是平台相关的嵌入层其向上提供一个 Surface 用以绘制建立了相关的线程模型和事件循环机制。在此之上则是一个平台无关的引擎包括用于绘制的 Skia Dart 的运行时开发模式下包括一个解释器还有一部分是文本绘制相关内容。最上面就是用 Dart 语言编写的 Flutter 框架也是我们最常接触到的内容。Flutter 框架包含一个完整分层的 UI 框架从基础的 Foundation 库到动画手势再到渲染之上又提供了各种丰富的 Widget 库。为了方便开发者使用 Flutter 还提供了两套不同风格的组件库针对安卓的 Material Design 的组件库和针对 iOS 的 Cupertino 风格的组件库。
从这个设计可以看出Flutter 和平台相关的内容其实只提供 Surface 和线程/事件循环模型的嵌入层部分。这种类似用游戏引擎的方式来开发应用的设计很好解释了为什么它具有优秀的跨端一致性。
我们常常说 Flutter 具有这样的几个特点:
精美
丰富的 Widget 库、 Material Design 和 Cupertino 风格的系统库、组合式的 API 、像素级的控制力可以使开发者便捷地构建精美的应用。
高效开发执行快速
Dart 语言是为数不多同时支持 JIT 和 AOT 编译的语言。开发期使用 JIT 编译支持了广受欢迎的热重载功能开发者可以像 PS 图片一样来开发应用开发效率高。发布后 Flutter 使用 AOT 编译 Dart 代码最终被编译成 ARM 汇编指令运行快速。
开放
Flutter 是开源项目其整个的开发工作流都是完全遵循开源项目的运作来完成的。
02、Flutter 在闲鱼中的应用 说完 Flutter 原理我们来看 Flutter 在闲鱼中的应用。在我们的研发中有几个核心关注的问题。
开发效率
闲鱼技术是一个相对较小的团队但业务需求比较重开发人员少需求多这种情况下效率就非常重要。还有部分原因是 iOS 安卓两端开发资源不均衡的问题
用户体验
我们的设计要求我们具有很好的跨端一致性其设计也是同一套风格。
执行性能
不管是复杂的交互还是动画都要求其具有不错的性能。
Flutter 的设计很好地满足了闲鱼业务研发关注的这些问题这也是我们采用它的原因。 我们怎么样让 Flutter 从无到有地在闲鱼中落地与上线这里面包括前期的调研研发期的混合开发体系以及如何保质保量在线上运行。
2017 年我们去接触和调研 Flutter 其当时还处在 Alpha 阶段。
我们需要去了解它的原理看它是如何具有所宣称的诸多优势对其性能做测试看能否满足要求包大小的增加怎么样这个量是否可承受音视频调的出发点在于业务场景我们的详情和发布页面包括了很多图片和视频工具链上 Flutter的开发体验如何我们甚至做了一个 MVP Demo ,这个产品中我们实现了包括发布详情、我的页面等主要设计与逻辑此外我们还很关注其社区的成熟度确保在遇到问题时可以通过自己对原理的理解或者社区去解决问题。 要使用 Flutter 我们就会面临一个混合研发体系的问题。其最开始的设计是面向纯 Flutter 开发的应用。而我们的应用是在原生项目中嵌入 Flutter 也就是 Add2App 。事实上在国内即便是一个纯 Flutter 的应用很多时候因为二方、三方库的原因也会成为一个混合工程。通过我们的实践与影响 Add2App 也变成了 Flutter 演进的重要方向。
工程层面上我们的团队中存在两个视角。一个是传统的 Native 开发的视角一个是 Flutter 视角。我们并没有直接使用 Github 上的 Flutter 项目主要是因为可控性的问题。因为国内的安卓碎片化以及 ROM 中 opengl 的实现不规范使我们不得不存在一些针对性的处理逻辑也就是引擎定制。其产物通过定制的 Flutter 最终被 fwn 工程所使用。fwn 工程包含了实际 Flutter 业务其 Flutter 代码通过产物集成的方式通过 pod( iOS ) 和 gradle ( Android ),最终集成到原生项目中。
混合开发不仅包括工程体系也包括页面侧的逻辑。我们一开始就涉及到了混合页面体系以 Android 为例简要介绍下原理。每个 Flutter 页面对应了一个原生的 BoostFlutterActivity BoostFlutterActivity 通过各自的 BoostFlutterView 去绑定单例的 FlutterEngine 。当 Flutter 页面在做切换时 BoostFlutterActivity 也会同步切换将 FlutterEngine 动态地 Detach 和 Attach 。Native 和 Flutter 之间可以互相关闭和打开页面 Native 的生命周期也会同步到 Flutter 侧。 Flutter 支持 UI 构建以及逻辑实现,但可能我们还需要去获取 wifi 状态或电量等系统状态。
面对这样的场景 Flutter 提供了很多机制去扩展应用。以获取电量为例 Flutter 提供了 Channel 机制用于同 Native 之间的双向通信。Dart 代码在 Release 下会变成汇编代码直接调用到 Engine ( C )再调用到 OC (直接)或 JAVA 通过 JNI 间接这种设计下的性能是原生体验。
Flutter 不仅在逻辑侧提供了 Channel 机制去扩展应用在渲染相关也提供了一些机制去做更多。我们写的 Flutter 视图布局最终会通过 DartRuntime 调用到 Engine 中的 LayerTree-Paint 方法。在这个渲染管线中 LayerTree 会调用到 SkCanva-Draw 最终通过 PresentRenderBuffer / SwapBuffer 将内容绘制到 GPU 上。LayerTree 中包含很多种 Layer 其中有一个特殊的 TextureLayer 可用于扩展。
以 Android 为例 TextureLayer 可以在 SurfaceTexture 的帮助下同一个 Surface 相关联。基于 Surface 可以将视频播放的内容传入并完成渲染或者结合 VirtualDisplay 和 Presentation 完成 NativeView 的嵌入。需要注意的是因为 VirtualDisplay API 的限制此部分的逻辑需要 API Level 在 20 及其以上。 也就是说 Flutter 提供了 Channel 机制用来扩展系统特性相关的逻辑通过 Texture 机制来支持视频播放器等场景和原生视图的嵌入。
在开发过程中我们其实也遇到很多问题不管是混合栈或者是视频嵌入 iOS 兼容等很多今天已经不再是问题, 但我还是想和大家分享下其中的一些思路。首先了解各层面原理是很重要的 Flutter 本身是一整套庞大完整的内容针对不同层次团队中都应该有相关的同学有一定理解要有能力识别出关键问题可以复现和定位问题提供最小化的 Demo 用于复现它在通过社区解决问题的场景下最小的可复现的 Demo 是尤其重要的还有就是要同社区有紧密的联系与合作。 我们不仅要关注技术本身也一定要保证业务稳定。这里有一些手段来和大家分享。用灰度来发现那些容易发现的问题用分桶和降级策略逐渐增加 Flutter 的业务比例通过线上 APM 去监控质量这些手段来保障质量。
总的来看目前我们有 20 多个页面来使用 Flutter 构建 Crash 水平在万分之一的数量级详情页等帧率在 52 帧以上可交互的页面加载时长是 300 毫秒。 这些是我们目前使用 Flutter 开发的部分页面包括详情发布、我的等。涉及到的设计元素较多包括视频、图片、聊天、评论、拍摄等比较完备的内容。我们最早使用详情和发布来验证 Flutter 也是要看 Flutter 能否支撑业务场景最复杂的情况此外也需要分桶与降级的机制来保障最坏情况下的业务可用性。背后的演进并不容易也是个逐渐改善解决的过程但这并不是原理上的大问题很多是细节上的问题典型如安卓上面的碎片化问题。 除了业务落地外我们也做了一些体系化的建设这里面很多内容都同 Native 侧。就 Flutter 而言从下往上包括一些针对 Flutter 的 SDK 像其特有的 APM 采集大量 SDK 的桥接在其上构建用于 Flutter 开发的编程框架如 Fish Redux FlutterBoost 等最终去支撑各个 Flutter 业务的研发。
03、Flutter 深度实践 分享完 Flutter 在闲鱼中的应用接下来介绍我们的一些深度实践。
在 Engine 侧主要解决 Android 碎片化所带来的问题以及 iOS 上的内存优化。
在 Dart 侧的工作主要围绕着 Dill 展开我们开发了一个基于 Dill 编织的 AOP 框架提供了一种新的方式来实现中间语言层面的代码编织。基于此我们也正在做 JSON 转换轻量级反射等部分的内容。
在 Flutter 侧我们的工作包括 APM FlutterBoost , FishRedux 等面向业务研发的开发框架。
在 UI 部分我们也在做一些图片转代码部分的工作。
简单介绍下 AOP 框架和 UI To Code 两部分的工作。 如果想去解决 AOP For Flutter 的问题有哪些问题需要解决呢首先我们要描述清楚这段代码是想对哪个库、哪个类的哪个方法去做怎么样的操作要让 AOP 代码没有侵入性使原生代码和 AOP 代码可以分开编写并最终在合适层面进行编织我们还需要一种机制去提取散落各处的注解形式的切面逻辑并将其应用到目标方法中去。
在 AspectD 的设计中通过提供面向 Dart 的 Aspect 设计我们解决了描述切面的问题通过提供基于 Kernel to Kernel Transform的Transformer 我们解决了提取注解和编织的问题。
相对于传统 AOP 框架所提供的 Call 和 Execute 的语法 AspectD 还提供了 Inject 的语法这主要是因为 Flutter 禁止反射造成的。
目前还有一个问题就是对于构建过程的侵入性。Flutter 的构建过程( flutter tools )和我们以前的习惯有区别并没有提供太多的扩展点。目前 AspectD 本身有一点对于构建流程的修改用于拦截原始的 Dill 构建并用操作过的 Dill 文件替换原始 Dill 文件这一侵入性同 AOP 本身没有什么关系我们正在和 Flutter 团队去解决这一问题。 还有就是我们在做的 UI To Code 。即通过 UI 去分析版面识别组件属性和布局生成中间的 DSL 描述。后端基于此完成针对 Flutter 的布局推导树的构建优化与最终代码转化。
04、总结 展望 回顾一下本文我们分享了跨平台方案与 Flutter 的原理。在 Flutter 的业务落地中如何去调研问题如何完成混合开发体系和能力扩展如何去解决关键问题和保证线上质量也展开介绍了我们在 AOP 和 UI To Code 等领域做得一些深入性工作。 展望未来我们谈谈 Flutter 的一些未来的趋势。
首先 Flutter 原理很自然地支持了 Mobile 和 Desktop 以及神秘的 Fuchsia 系统。针对 Flutter For Web 我最近也写了一点分析这是一个实验性的项目从原理上来说可以支持 Flutter 代码无成本地运行在 Web 上但可能存在性能的损失。当然如果业务不是很复杂或不是很高的性能要求的话可以考虑尝试下。
除了我们自身的实践外我们也希望一些大的应用可以更多地进来。更复杂的应用场景和生态链的支持可以让 Flutter 的社群更加完善。
目前我们现在也在做一些 Flutter China 的工作核心目标就是完善国内的生态降低大家的开发门槛让更多的团队能够受益。最后大家如果有什么问题可以在下方评论区进行交流。 精彩回顾 原文链接 本文为云栖区原创内容未经允许不得转载。
