开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第7天，点击查看活动详情

这是参与日新计划的第七篇，算是一个小里程碑。

这篇没有什么特别的技术干货，更想讲一些对移动开发的感悟。

前言

为什么现在 iOS / Android 招聘上都要求有 Web / Flutter / C++ 等经验中的一种或多种？

各位移动端同学应该深有感触，移动互联网早已是昨日黄花。

Q: 移动端开发的前路在哪里呢？

A: 从各大厂把“移动端”慢慢更名为“终端”就可以看出，多端融合早已是一个必然的趋势，从移动端开发衍生为多终端开发。

Q: 移动端原生开发语言还重要吗？

A: 还是很重要，毕竟很多平台特性的开发还是需要原生语言的。

Q: 从技术角度讲未来的学习侧重点？

A: 代码设计思想 > 终端工程架构 > 终端平台特性。

这里解释一下，代码设计思想指的是什么？

语言的学习虽然重要，但设计思想更为重要些，比如要知道各类语言是如何处理内存安全的。抛开语言本身的束缚，才能快速的学习多种语言。

意义

话说回来，跟本文所说的“跨端工具链”又有什么关系？

上文说到的 “终端工程架构” 是一个抽象的架构设计，容器设计、组件设计、通信设计、存储设计等等。

当然你可以用（或者现在正在用）原生语言（Java、Kotlin、OC、Swift）来实现一个“移动端工程架构”。

现在我们需要面向未来的站在“终端开发者”的角度来设计“终端工程架构”，比如 Rust 实现通用的通信层、 Flutter | Web 实现统一的 UI 渲染层。

但中间有一个关键问题，就是它们之间要如何联系？

打个比方，相当于一个个孤岛（设计/语言），我们就要有一个或多个桥梁把它们串联起来，甚至填海来拓宽它们的联系，让岛上的信息互通有无。

这个就是我们要建设的“跨端工具链”。

释例

通过上述比方大家能明白“跨端工具链”的意义，但具体是做什么的，可能还是一头雾水，下面举几个开源项目为例。

application-services（Rust）

这也是笔者产生建设“跨端工具链”的来由，我们内部“跨端工具链”也是用 “application-services” 来命名。

简单的说， Mozilla 的 “application-services” 主要是用于解决 Rust 如何融合到各端（iOS/Android/web/desktop）的开发问题。

它可以帮助我们通过 Rust 代码定义直接生成 C-FFI、以及各端的代码桥接部分（Swift、Kotlin 等等）。

带来的直接好处就是可以立即用它开发 Rust 跨端模块了，也有已开放的 rc_log、logins、support/sql 等可直接使用的模块。

这里简单的解释下它的原理：

github.com/mozilla/uni… 这个是它生成工具代码。

其中 uniffi_bindgen 模块是他的生成核心，里面包括各端的模版代码以及生成方式，如下图：

这样 uniffi_bindgen 会将传入的 xxx.udl 文件转换为完整的各端代码。

其中 xxx.udl 解析的核心是 weedle2 这个库（docs.rs/weedle/late…）

它能用 Rust 生成各端桥的实质上是 字符串处理，没有什么特殊的银弹

（这里只下了源码，没有编译，所以会标红）

可以看到，它定义了各类符号和语法关键字来把 xxx.udl 中的代码转换成 AST (Abstract Syntax Tree)

DSL 模型给 uniffi_bindgen 后，再生成为各端代码。

pigeon（Flutter）

Flutter 官方的通信生成插件。

它的实质上跟 “application-services” 一样，，通过 xxx.dart 代码定义，来生成 iOS（OC）/ Android（Java） 。

但它的使用限制颇多，很多语法并不支持，通信过程上也是通过 messageChannel 而不是 ffi。

关键问题是执行效率很慢，这可能因为它的原理不是字符串处理而是 dart AST 解析 [手动狗头]。

但思想上是一致的： Flutter 代码 -> AST -> 各端代码。

“稿定 App” 在 Flutter 多引擎方案中是在使用的 “pigeon”，为了执行效率慢的问题，也做了很多优化。

在使用上，用的是配置及代码的方式：YAML 配置文件 -> Flutter 代码 -> AST -> 各端代码，区别主要是用途范围。

用代码更是一种通用的工具能力，而用配置来说，更多的是做一种约束。

代码即配置还是配置即代码，这应该没有好坏之分，甚至应该是相辅相成的。

style-dictionary（TS）

这个是 Amazon 的 "Design Token" (设计令牌的) 实现。

简单的介绍下，就是设计师设计的 UI 标准可以直接在各个端上使用，开发不再关心具体数值，而是直接用具体语义的常量定义。

它的实现上其实更简单一些，用 Typescript 脚本，JSON 定义 -> 各端代码。它现在支持很多种语言，但很多也没办法直接使用，还是需要改造下。

总结

根据上述的几个例子，希望大家也能对 “跨端工具链” 有所感触。放一下 “稿定 App” 我们现在做的 “application-services”，但也不是 “跨端工具链” 的全部，这还在持续摸索中。

“工具”语言选型上 Python 、Ruby 、TS 都有，还是前言那句话，不要让语言束缚了。

下一篇会是干货：讲一下 flutter_boost 遇到的多键盘崩溃问题

如果对你开发学习上有丝丝作用，请点个赞[开心] ～