文章为直播演讲的文字稿，若想观看直播回放可访问B站：Dtalk#5 | 圆桌讨论：高校开发者们的逐梦 Web3
Hello 各位，感谢大家参与到本次的技术分享活动，我是来自 AstroX 的 Alex，同时也是 Flutter 开发者专家和 Flutter 中文社区的核心成员。 今天我将从 Flutter 跨平台开发工程师的角度，给大家分享一下，在 IC 上进行移动开发，开发基于 IC 的移动端跨平台设施及应用的一些细节。
此次分享主要包含以下的内容：
- 移动平台的开发对于 IC 的重要性
- 在 IC 上的团队以及我们 AstroX 是如何选择移动端的技术实现的？
- AstroX 在移动端实现了些什么？包括我们的产品 demo 的展示
- 以及我们还能在 IC 和 Web3 领域做一些什么？
移动开发对于IC的重要性
首先我们来浅聊移动开发对于 IC 的重要性，我主要会从三个因素进行分析：
- 需要移动开发的原因
- 移动开发的特点
- 以及我们在移动平台想达到的目标
首先我们都知道 IC 是高性能链上的跨平台项目，其衍生项目的应用场景不仅限于 Web 和 Mobile，我们可以在任意一个 unix 和 node 环境下主动构建自己成为一个节点，也就是 IC 上的 canister。这样大大拓宽了集成的限制。
另外由于一些项目的部分概念涉及了去中心化，导致用户在使用时也要接收到去中心化的学习成本，会让整个 App 的体验变得异常复杂，并且用户还常常需要使用 PC 与浏览器配合来完成特定的操作，比如我今天出门参加一场宣发会，结果现场空投的 NFT 需要用电脑领取，整个人处于一个崩溃的状态。
那么 在当下的世界，移动端也就是我们说的手机，已经人不离手了，每天醒来你的身边没有手机，可能你就没办法开启你一天的生活，这样的趋势在长期内都不会发生太大的改变。
但是，大家都知道每天手机上持续使用的应用一般不会超过 20 个，你的 App 如何脱颖而出成为二十分之一？首先就要 在速度和体验上都能达到上乘，并且让用户有实际的需求，才能持续保持和提升你的获客水平。当然轻量也是其中一个重要因素，比如 2017 年发布的微信小程序，你会想到它 5 年后的用户群体有当今的规模吗？ 综合以上的这些条件，我们的目标就逐渐浮现了，我们的 App 要 在移动端上兼顾速度和体验。
说了以上内容，我们先来看看现在 IC 上普通 DApp 端到端的交互模式。
这是一张简单的 IC 上开发 DApp 的端到端结构图。左边是传统意义上的后端，在 IC 上是一个 canister，也可以理解为容器和罐子。Canister 可以部署智能合约，合约可以用 Mokoto、Rust 或者其他语言编写，也可以在 Asset canister 上部署前端内容。
如果我们在这里部署的是合约 canister，那么我们所写的合约会提供一个定义的 Candid IDL (interface description language) 规范文件，也就是我们通常所说的接口文档。而最后通过端侧的 agent 代理，注册相关的 IDL service，提供给端侧直接调用合约方法。这个端侧可以有非常多的端平台，比如 Dfinity 官方提供的 JS Agent，比如我们团队为 Flutter 技术栈上开发而实现的 Dart Agent。当然除此之外还可能有给服务端侧使用的 Go Agent 或者我前面嘉宾提到的 Python Agent，只要实现了这个代理 Agent，所有的端侧都可以很方便地调用 canister call。
介绍完这个 E2E 的结构，相信各位同学也对 IC 的交互模型有了一丢丢更深入的理解。
如何选择移动端的技术实现？
接下来我们就来聊聊，如何选择移动端的技术实现。因为 AstroX 团队已经开始了一段时间的移动端开发，所以目前我们的技术栈已经选定了 Flutter，那么它究竟在 IC 上有什么优势和能力呢？
回顾一下我们刚刚提出的目标：在移动端上兼顾速度和体验。Flutter 是否可以做到兼顾？目前经过几个月的经验积累，我们得出的答案是 完全可以。
Flutter 在跨平台特别是移动端的性能是非常良好的，符合我们 Mobile First 的目标。其依赖的 Skia 自绘也在这几年不断地被「借鉴」而成为主流，这几年曾经出过很多的跨平台框架比如 Kraken 和 Weex 2.0 都借鉴了 Flutter 的渲染 pipeline 和 engine 思路。另外 Dart FFI 的引入也为应用层调用底层平台能力提供了非常大的切入口，应用层可以直接享受底层接口的性能。
Flutter 背靠的 Dart 使用的是 Pub 软件包管理，Pub 上现在已经有 26000+ 的 Flutter 插件。尽管我们知道 Flutter 本质上是一个 UI 框架，但是可以通过这些插件来补齐这些目标平台的设备需求，那么我们在 IC 上开发 Flutter 应用也可以扩展我们合约的使用场景。比如我们团队在前段时间的 Supernova 黑客松大会上就提交了 基于人脸识别的身份验证场景应用 Proof of Personhood，充分证明了架构+业务的可行性。
另外在使用 Flutter 开发的过程中，针对框架和 IC 基础设施的工具链相对比较完善，我们可以比较快速地开发新的工具。比如我们团队在 前几个月开源公测了 candid_dart，利用 dart 的 build_runner 将 did 文件生成 dart classes、合约类型以及 IDL 模板代码，应用侧直接可以通过 agent 进行注册并且调用 canister。
当然说到 Flutter 就得说一下大家平时会讨论的人效问题，一般我们说一个 Flutter 开发工程师在业务能力上可以顶 1.8 个左右的不同端原生开发工程师，一个中级的 Flutter 工程师可以独自完成 60% 左右的业务，这样会给团队带来很不错的人效比。但是以一敌多有好处也有坏处，就是这个一是否能撑起一片天。团队组建招募 Flutter 开发人员时需要做一定量的准备工作，要对新语言和框架系统进行学习，并且掌握深度的不同可能会对后续的业务开展带来不一样的影响。
我们在移动端实现了什么？
接下来我们会给大家分享一下 AstroX 在移动平台的一些成果，即我们在移动端实现了什么。
这里展示的是我们目前的移动端主要基础构建的架构图，总共分为四大部分，分别是刚刚提到的 Dart Agent、用于解析 did 文件的 Candid Parser、基于 IC 业务的 Flutter SDK，以及应用层 App。在这里我分开给大家介绍一下：
Agent 在先前有提到过，是作为调用 canister 合约方法的代理。目前 agent 基于 FFI 调用 Rust 产物进行交互，执行一些密码学的运算，同时支持异步及高性能的调用操作。Dart Agent 的内容基本与官方的 JS Agent 平齐，其中还加入了一些方便于 Dart/Flutter 开发的扩展方法，还有我们在开发中遇到常见问题的优化。
Candid parser 会解析 did 文件，将定义的合约方法转换成已知的 类 和 IDL 定义，App 使用这些转换出来的内容后通过我们抽象的 Service 将 IDL 绑定到 agent 与 canister 的连接上，进行具体的合约调用。
最后我们根据 Agent 开发了一些 SDK，包括与 Web 进行互调的 Bridge 和以及给 Flutter 项目使用的 SDK，包括 Authentications 和 Transactions，项目接入后可以直接在我们的基础设施上根据自己 IC 的业务进行开发。
三个基础构建最终统一服务于我们的 App，AstroX 目前主推的移动端项目是 ME App，其他 IC 生态上使用我们 Dart Agent 的应用还有 Distrikt，它是一个去中心化的社交应用。
以上我们团队沉淀的与移动端有关的基础构建中有两个已经开源，有兴趣的同学可以访问左上角我们的 GitHub 进一步研究我们的代码。
说了很久，马上来带大家看看一个简单的 IC 合约交互流程是怎么用 Flutter 写出来的。
（具体 demo 展示请查看视频回放。）
还能在领域内做些什么？
最后我们来说说在 IC 和 Web3 这两个领域，我们在技术上和机会上，还能做些什么？
目前 IC 领域或者我们说 Web3 是一个什么样的状况呢？
首先就是近段时间不断地有高性能的公链诞生，我们来看一张图，这些都是高性能公链。新公链的增加，就会带来需求的猛增，大家都可以在这些公链上进行布道、探索和开发。
基础设施的扩宽就会带来更多专业的行业从业者不断地向行业内涌入，这些从业者选择了他们看到的机会，很多人来自于各大传统头部互联网企业，会带动整个行业进入快速发展期。
当然除了从业人员增多以外，性能提升带来的优势还有各端的开发成本和门槛的降低，其中就包括移动端。例如 StepN 这样的标杆应用为用户的移动端带来了非常良好的体验，不再让 Web3 的用户局限于 PC 但是，在 IC 上进行的跨平台开发对于开发人员来说仍然有较高的准入标准。举个例子，尽管我们刚刚演示的例子中已经打通了相关流程的所有难点，但是在设计这些方法和服务时，仍然需要花费开发者的大量时间去理解其中的运作模式，才能很好地进行业务抽象。所以为 IC 上的开发者做好 DevTools 仍然是一件非常重要的事情，它会大大降低普通开发者在集成 IC 时的难度，从而让更多的产品在 IC 上大放异彩。
而在 Web 以外的平台，目前存在的 SDK 还是比较少，刚刚我们有聊到在不同的平台会有对应的 agent 进行交互，其实大部分平台目前也只有 agent 作为 IC SDK 可以使用，整体量级并没有达到开发者随意就能找到的程度。 AstroX 作为 IC 上的团队，作为 provider，也在以上说的两件事中持续努力中，我们也希望未来能为开发者们提供更好用的 DevTools 和 SDK，所以~
所以我们团队也欢迎各位有兴趣的同学与我们共同探索，包括“五师两理”，期待在 Web3 和 IC 上发光发热。我们所有的工作都是远程弹性工作，希望大家来撩~
