从大前端“穿越”到终端，开发者应该必备什么技能？ | 解读终端的 2022

摘访嘉宾 | 郭虹宇（弘禹）、舒文亮（舒文）

编辑 | 闫园园

本文是 “2022 InfoQ 年度技术盘点与展看” 系列文章之一，由 InfoQ 编辑部制造显现，重点聚焦终端领域在 2022 年的重要进展、动态，期看能扶助你正确把握 2022 年终端领域的核心发展脉络，在行业内始终保持足够的技术敏锐度。

“InfoQ 年度技术盘点与展看”是 InfoQ 全年最重要的内容选题之一，将涵盖操作系统、数据库、AI、大数据、云原生、架构、大前端、编程语言、开源安全、数字化十大方向，后续将聚合延展成专题、迷你书、直播周、合集页面，在 InfoQ 媒体矩阵陆续放出，欢迎大家继续关注。

特此感谢郭虹宇（弘禹）、舒文亮（舒文）（按姓名首字母排序）对本文的奉献，他们的真知灼见，是本文能与大家见面的要害。

诚然，刚刚过往的 2022，对整个互联网行业来说，是极具挑战且富有转变的一年，然而聚焦到大前端技术领域，整体上仍保持平稳向前的状态，假如一定要用要害词形容，综合受访专家看法，本文认为“深度优化”一词较为贴切。

所谓“深度优化”，是指前端领域经过蓬勃发展，已逐渐进进成熟期，短时间内并没有出现令人眼前一亮的技术拐点，但同时据多位身处技术洪流中的专家预判，新一代的技术也正在悄然孕育与布局。当然，这也意味着又一道难题摆在了当代开发者面前：大前端领域划时代分水岭将发生在何处？

或许，我们能从近几年发生的某些重要事件中看出一些端倪：

在 WWDC 2019 上，苹果更新了 ARKit 增强现实平台，并公布推出全新的 ARKit 3；

在 WWDC 2021 上，RealityKit 2 新增加了 Object Capture API，通过该 API，能够扶助开发者将在 iPhone 上拍摄的视频，在几分钟内创建真实世界对象的高质量、照片般逼真的 3D 模型，并将它们转换为针对 AR 优化的 3D 模型；

在 2022 Google I/O 上，谷歌 CEO 发布了地图新功能，虚拟与现实相结合，仅通过图像就能生成实景画面，该功能简称为“沉浸式视图”；

同样在 2022 Google I/O 上，谷歌发布了一款 AR 眼镜作为“one more thing”压轴登场；2022 年 7 月，华为正式公布发布 HarmonyOS 3，HarmonyOS 是华为推出的面向万物互联的全场景分布式操作系统；

疫情三年，中国互联网 to B 市场大规模增长。2022 年 12 月，钉钉公布注册用户破 6 亿，第三方数据展示企业微信 MAU 过亿。

那么对于开发者来说，究竟从这些事件中能够得到什么信号，信号又指引了哪些方向？接下来，本文将跟随来自阿里终端委员会两位技术专家弘禹与舒文的脚步，探索终端的过往与未来，试图为身处迷雾中的开发者带来问题的部分答案。

实际上，相较大前端这一技术名词，阿里巴巴曾不止一次提到终端这个概念，这不禁引人好奇，当大前端的含义仍被业内津津乐道之时，终端的说法又从何而来？

从大前端到终端，未来已来

弘禹谈到，终端其实并不是一个新词，甚至对于资深开发者来说已经亲眼见证了几代终端的转变：从最早 80 年代使用的展示器加键盘过渡到 PC 普及，再过渡到如今移动端设备普及，可以看到，可能每十年终端的边界都会迎来一次扩展。基于此技术趋势，阿里巴巴沉淀出对“终端”的定义，即：“为用户提供人机交互的设备及使用。当前以 UI 交互终端为主，如手机、PC、平板等。”

“我们在包括不限于 D2 大会等在内的各个场合都提‘终端’这个概念，是因为阿里正在以自己对行业的理解和认知在对未来做预判。”舒文谈道，同时他借用今年阿里终端委员会成立时对内公布的两段话进一步阐释了终端的内涵：

随着技术的演进，当下的前端和客户端有了越来越深的相互渗透：Web 的开放性和高效迭代，客户端技术的即时体验和原生能力，继续升级的技术体系像有生命意识一般朝着“既要又要”的方向攀沿：运行在客户端内的 Web、Hybrid API、拥抱 W3C 准则的动态化跨端引擎（Weex 2.0）、基于开源 Flutter 生态的大前端研发体系，都在让前端和客户端不断地交织合成、模糊着边界；

展开全文

更为重要的是，互联网基础设施越来越齐备、终端设备规模 类型爆炸式增长，用户的体验将不再单纯的是网页或 App，不同的信息载体都将拥有自己的体验：头戴式 VR 设备的沉浸式体验、扫码枪的直爽支付、车机的语音和硬件唤喊应答、商场的各类娱乐屏幕、家庭的智能设备，甚至健身房的魔镜都不断在印证着科幻小说作家那句，“未来早已到来，只是尚未平均分布”。用户的体验将被空前的称心，而我们则更应该提前做好预备应对转变，面向用户有统一全局的终端视角。

螺旋形理论讲到，事物的发展或进取不是直线式上升，而是类似于“螺旋”般上升，这个理论放到前端技术领域，同样也适用。结合前文提到的重要事件释放的信号来看，大前端领域虽然未曾行至清楚拐点，但端技术的重要性确是日渐凸显。终端概念的提出，背后的本质正是看到了前端和客户端的互相渗透，同时期看二者能够尽快打破过往壁垒，及早为新的终端设备和体验做好技术和人才上的布局。

了解终端的概念后，下面将按照领域中的重点技术方向，感知当下领域的具体发展现状，以及展看未来，领域中面临的机遇与挑战。

重点技术趋势解读

Web 开发仍是主流

2021 年 5 月，InfoQ 发布的编程语言 4 月排行榜中展示：Web 开发依然是终端领域的主流。据投票数据展示，Web 开发得票率为 68%，iOS 开发得票率为 16%，而 Android 开发则为 5% 。同时，小程序开发以 6% 的得票率超过 Android 开发。那么在 2022 年，这一趋势是否发生了转变？对此，舒文谈道，就其个人看察，这一趋势不仅没有变，从某种角度来讲，反而会变得更为主流。以桌面领域以及移动互联网领域两个纬度分析：

桌面领域

过往两年， to B 市场不断被挖掘，桌面终端技术逐渐升温。基于浏览器的 Web 技术自不必多说，原来的桌面客户端领域也开始大量渗进 Web 技术。究其原因，不外乎三点：

桌面硬件性能高度过剩；

类 Eeletron/Tauri 的开发框架继续完美带来诸多成功案例；

操作系统原生支持 Web 技术进行研发（如 Windows 支持 WebView2、PWA）。

移动互联网领域

其实，无论什么技术形态或者研发模式，本质上都在回答一个务实的问题：如何让技术方案做到便宜（成本低）、好用（易上手）、质量高（交互体验好）。在过往很多年，移动 App 领域中，Web ( WebView ) 天生具备了前两者优势，但却也因受限于太多因素，如独立的进程策略、高耗时的启动渲染逻辑、缓存能力不完美等在高质量交付上总是捉襟见肘。因此在过往，开发者们时常会听到一个说法：“先用 Web 搞，然后慢慢 Native 化。”

而当下，这种情状已发生了浩大的转变，其中，促使这种转变的原因主要有两个：

手机硬件性能的高度过剩，愈发成熟的跨平台基础设施（包括不限于脚本引擎、排版引擎）都使得跨平台研发成为行业的主流诉求；

具象到研发模式上，类 Web 的方式在效率和体验上几乎是规模化研发下的最平衡解。

主流跨端框架

依据终端的定义，目前市面上“端”的形态多种多样，为了解决多端独立开发的问题，跨平台技术便应运而生。目前，在各大互联网公司一起努力下，市面上出现了各种跨平台框架。那么跨平台框架 2022 年使用情状如何呢？首先看几个业界主流解决方案：Flutter、React Native 、Weex。

Flutter

站在 2023 年初看来，Flutter 已经是不再是以前小众的跨平台框架了。如图所示，可以看到如今的 Flutter 已经有高达 148k 的 Star 和 24.2k 的 Fork。从官方公布的数据上， Flutter 已经基本超过其他跨平台框架，成为最受欢迎的移动端跨平台开发工具，截至 2022 年 2 月，有近 50 万个使用程序使用了 Flutter。

2022 年 5 月，Flutter 3.0 正式发布，不同于之前的版本，Flutter 3 新增了对 macOS 和 Linux 使用程序的稳定支持。“Flutter 3.0 出来之后，我个人感觉它这套体系会更成熟”，弘禹谈道，同时他认为 Flutter 未来可能会向布局多端多设备上更迈进一步。“这也给业界一个更强的信息，就是真正实现过往我们一直都在谈的一套代码多端运行”。不过，他也坦言这在技术上确实是有一些瓶颈和阻力的。

2022 年 8 月，谷歌又发布了 Flutter 的 2022 年的第 3 个版本，即版本 3.3，随之一起发布的还有 Dart 2.18 。这两个版本都是改良版，没有添加重大的新特性。

React Native

对于 React Native 来说，它一如既往地在跨平台使用程序开发中占据一席之地。大多数科技巨头都使用它来开发使用程序。2022 年我们看到的最新和要害转变之一是其架构的更新。

React Native 0.69 发布了强大的新功能，例如 React 18 支持和捆绑的 Hermes。它带有默认启用的 React 18、useId 等新钩子以及 useTransition 或完全 Suspense 支持等新功能。

Weex

2013 年，阿里开始 All in 无线，整个互联网都在做 PC 到移动端的转型，那几年移动端流量暴涨，设备性能也较差，这时，肩负着历史使命的 Weex 出现了。

目前，手机淘宝仍在大规模使用 Weex，主要使用于需要快速迭代的产品、业务以及大量卡片场景。2020 年八月份启动 Weex 2.0 项目，不再依靠系统 UI，开发自绘渲染引擎，并且保持向前兼容。

受限于篇幅原因，本文无法一一展现全部众多跨平台框架，那么对于开发者来说，又该如何众多跨端框架作抉择呢？

弘禹认为对于初创公司或者规模较小的团队来说，在人员配置以及能力模型契合的前提下，Flutter 或许是一个比较好的抉择。不过，无论抉择哪个跨平台框架，最重要的还是依据项目场景，比如可以用 Flutter 做 App 底座或者 iOS、安卓的跨端技术选型，但假如做跨多端甚至跨使用，则意见抉择偏 Web 的框架。“不管选 Flutter、RN 还是 Weex，我觉得最重要的还是结合场景，同时结合团队不同发展阶段和人员配置情状，再往做综合的推断取舍和抉择。”弘禹总结。

Java Type

2007 年，Jeff Atwood 提出闻名的阿特伍德定律，“any application that can be written in Java, will eventually be written in Java”，意指“任何可以用 Java 来写的使用，最终都将用 Java 来写”。在上述报告中，这一定律再次用数据得到了印证：终端领域编程语言使用情状上，Java 以 78.5% 的得票率，排名第一；而 Type 得票率为 42.9%，排名第二。

对此，舒文推断，目前这一趋势依然不变，并且从长远来看，也会继续较长时间。究竟终端领域的交付，早已并非过往简单地实现还原界面，而是变得越来越繁复，这意味着逻辑复杂且规模浩大的 Java 使用程序成为普及事实，当然，也需要越来越多的工程师参与保护迭代。

Type 中的 “Type”，正是通过程序中的规则来建立秩序的类型系统，从语言层面提供基础，同时缓解这两类问题。借用《人月神话》一书中的看点：

需要协作沟通的人员的数量影响着开发成本，因为成本的主要组成部分是相互的沟通和交流，以及更正沟通不当所引起的不良结果。

需要协作沟通的人员的数量影响着开发成本，因为成本的主要组成部分是相互的沟通和交流，以及更正沟通不当所引起的不良结果。

不过，需要开发者注重的是，以上说法并不意味着 Type 有朝一日完全成为 Java 的替代品。尽管 Type 的主要奉献者 Hejlsberg 确实提到 “竞争”这个词，但此“竞争”单纯从浏览器语言角度出发的。“事实上，它们二者更像是“亲缘”关系，当然，也是超集和子集的关系”。从功能层面，某个功能或特性进进到 ECMA 的准则化流程相对稳定阶段，即会在 Type 中被纳进且进进社区化状态。

回忆 2022 年，Type 版本迭代很快，2 月 Type 4.6 发布，5 月 Type 4.7 发布，8 月 Type 4.8 发布，11 月 Type 4.9 发布。几个版本迭代中，除了常规的语法改良和性能增强、工具优化，也有较为亮眼的三点升级：

性能分析层面 (v4.6)：针对高消耗性能的类型，Type 有 generateTrace 进行输出，但是易读性很低，现在提供可视化方法进行阅读。在此基础上，还发布了一个 Trace 分析工具；

Node 支持（v4.7）：对 Node.js 16 的 ECMA 模块 (ESM) 支持以及新的编程语法、新的要害字、新的 Compiler Options、类型推导增强等；

引进文件系统事件检测文件 (v4.9)：在之前的版本 Type 使用轮询检测文件，它意味着需要周期性的文件检查。虽然轮询不会引进跨平台问题，但在非常大的 Type 工程项目中，意味着额外的性能开销。在 4.9 之后默认了文件系统事件，只做失败回退（至轮询）。

在发布两个 Beta 和两个 RC 版本之后，Type 团队发布了将于 2023 年 5 月释放 v5.0 的计划，在该计划中，团队也明确了 Type 的下一步路线：语言和编译器紧跟准则（社区 准则化）、优化生产工具效率（生态）、优化性能（基座）。“当然，大多优异的开源项目都有着清楚的演进路线，但是，最近几年 Type 团队在演进确定性、核心逻辑坚持上给予了开发者非常强的信心，这也值得我们每个工程师学习。”

WebAssembly

有人说 WebAssembly 的发明，相当于再一次发明了 Flash、Silverlight 甚至是 Java。作为一种新的运行时，它与 Java 运行时协同工作，具有轻量级、泛语言支持、兼具高性能和移植性等优势，可以说一诞生就自带光环。2022 年 4 月，W3C 公布了 WebAssembly 2.0 的第一批公共工作草案。

目前来看，这项技术在国内外已有了一些非常典型的使用场景，国外包括 Google Earth、Figma 、AutoCAD Web 版、Photoshop Web 版、微软的 Blazor WebAssembly 等，国内包括但不限于蚂蚁链智能合约、腾讯邮箱（部分功能）、开源项目 flv.js 等。

单纯从浏览器厂商来讲，WebAssembly 的重要性已经受到了一致认可，甚至连原本支持计划落后的 Safari 都在 2021、2022 年加快了对它的支持。但也可以看到，WebAssembly 2.0 仍然只是一个草案，意味着仍然有待讨论的问题未达成一致，这里面既涉及到一些技术细节，也受到一定程度的厂商考量。“从这个角度来看，WebAssembly 志远道艰且阻。”

然而，假如换个角度往看，WebAssembly 的前景似乎也谈得上光明：

首先，从 Web 开发者来看，虽然以 Java/CSS/HTML 为基座的使用开发模式占据了浏览器使用的唯一选项，但依然有两个难题自诞生之初就悬在整个开发生态之上：

受限于 Java 语言缺陷和 ECMA 的齐备支持程度，大型使用的可开发、可保护性；复杂使用下的用户端体验性能问题。

前者已经出现 Type 及各类生态工具链的完美等解决方法来用以规避，而后者，截至目前，WebAssembly 仍是最有影响力的根因解法之一。

其次，从行业视角来看，大型软件、复杂使用面临最大的问题之一即是跨平台研发的成本问题，而浏览器及其依靠的准则具备天然的、法理性的跨平台特性。由此也带来一个非常严厉的探求：假如有一项技术方案能够将大型软件、复杂使用低成本移植到浏览器环境下，且保持足够的性能，那它除了获得成本收益外，还将具备更低成本的用户体验提升（免安装、中心化迭代），其背后的价值潜力将布满想像。舒文认为，这正是 Figma 具有叹为看止的商业估值的原因之一，再进一步讲，这也正是当前较齐备的 WebAssembly 的产品范例都是工业化程度、复杂度较高的软件使用的原因。

站在当下，假如要真正解决前面提到的两个难题，仍需要更齐备的技术支撑，并且要解决的问题也要远超过当前此技术的进展：除了 2.0 草案提到的 WebAssembly Core Specification、WebAssembly Java Interface、WebAssembly Web API 亟待解决以外，还有未形成共识的 Relaxed SIMD（宽松 SIMD）、Exception handling（反常处理）、Threads（真正的多线程） 等问题需要注重。

总之，短期来看，WebAssembly 的发展是低于行业看察者预期的，即使是像反常处理这种特性已经在 Phase 3 阶段，但假如搜索常见的 WebAssembly 库 ，时髦的库仍局限在特定数学计算、利用大型成熟 C++ 代码库将其功能带到 Web（无需移植到 Java），按照这个态势发展，它会转变成是典型的利基（Niche）技术，这其实是失控的。

而长期来看，WebAssembly 是一项非常值得关注的技术领域，其诞生不过十年间快速受到社区认可并纳进准则，并被厂商广泛支持，对接广泛的语言支持（Rust、Go、C、C++ 等），甚至衍生到公开技术联盟（Bytecode Alliance），还是有相当大的机会解决前面提到的复杂 Web 使用下的端体验问题。“当然，前提是在适合的场景下。”

DevOps

DevOps 是一整套成熟、完全的软件开发 测试运维的方法论和实施体系。在崇尚灵敏迭代、高效部署的现代软件研发思潮中，它在众多高级技术决策者心目中几乎是事实正义。

而它的实践在过往几年，也被执行得果敢且继续：这不仅反映在大量科技公司的运维部门和开发部门的高度合并，同时也催生出海量的衍生技术产品。

Ledge 公司 DevOps 元素周期表

聚焦到终端领域，相对中心化的 Web 产品而言，移动 App 的 DevOps 的贯彻对于技术效率的提升显得尤为要害。这里弘禹、舒文以手淘为例进行了阐明：

首先，对于手淘 App 来说，从平台视角看因为淘宝业务体量、架构自身复杂度、代码库规模浩大等原因，单版本集成模块数超过百级，双端构建时长超过 15 分钟，出包成功率极端情状下也不足 80%。因此，阿里终端团队今年将重点解决两大工程技术命题，一方面如何通过构建技术突破继续优化超级 App 的构建时长和成功率，通过包括不限于构建技术升级、构建过程优化、构建软硬件优化等技术手段，最终成功地将“一杯咖啡，构建成功”变成现实。与此同时，为了改良日常工程师的研发环境痛点，通过 Web/CLI 多端工程产品升级使“做 XXX 一行命令就够了、分钟级配好迭代配置”的研发体验交付到工程师手中，极大地提升了日常研发效率，逐渐成为终端的一种工作方式。

同时，对于手淘业务来讲，从业务视角看需求全周期上线时长决定了业务创新速度，App 版效及需求交付效率是最大瓶颈，全量发布流程在叠加各类卡口情状下约需要 150+ 环节，App 版本发布及运维成本居高不下，需求迭代生命周期也相当复杂：需求经历从设计、开发、变更、集成、一灰 BugFix、二灰 BugFix、多外部渠道上架、自有渠道全量整个过程直接制约了业务发展。为了解决这一挑战，阿里终端团队一方面通过工程平台的版效能力升级，实现了全环节 70% 自动化率，使手淘实现低成本的周版发布，另一方面基于 Android AppBundle 研发了无 Hack、低适配成本、零性能损耗的原生动态化框架，云端结合实现手淘 App 的发布动态化，基本实现小时级近千万设备的更新覆盖效率，同时也有机会革新集成窗口机制，让业务创新更快发生，阿里巴巴在终端工程效能水平上明显提升。

另外，关于 DevOps 的讨论其实一直也没有停止。2021 年 7 月， Sid Palas 在推特上一语惊起千层浪 ：" DevOps is dead , long live Platform Engineering! " ，2022 年 8 月，InfoQ 也曾转译过 Scott Carey 的文章：“ 要什么 DevOps，我们开发者根本不想做运维！ ”这两个讨论中，他们都有相类似的看点，即 DevOps 是技术治理者的美好愿看，但是对于编程主业的工作者来说，他们并不期看与 Infra 和 Ops 产生深进联系，因此，大家提出了平台工程（Platform Engineering）的概念。

对于这一看点，这里，舒文也向 InfoQ 提出了自己的看法：

“手机淘宝的移动体验平台团队打造的各类开发者产品即是 Platform Engineering 的典型实践，只是目前处在快速上升期”，舒文介绍。同时，据了解目前对于 Platform Engineering 乃至 IDP 的建设，阿里终端也正在探索自己的发展路线与最佳实践，即基于在过往移动高速发展的 10 年在终端研发、交付、运维、体验、高可用、移动 PaaS 能力、SDK 软件给予链与合规等相关领域的沉淀的齐备的中台能力基建与工具链，着手合成升级全新体验的终端一站式工作平台。

低代码

2020 年被称之为低代码元年，在这一年低代码平台在国内起步，到了 2021 年，低代码平台开始在国内迅速蔓延，到了 2022 年，各大资本看好低代码发展，纷纷投资潜力厂商：低代码平台 Swimlane 获得 7000 万美元融资；Baserow 筹集 500 万欧元用于创建无代码工具链；无代码软件测试平台 Sofy 获得 775 万美元种子轮融资；无代码初创公司 Sitemate 获得 520 万美元以加速无代码软件平台......

虽然低代码热度空前，但关于其的争论却未曾消失，一直到今天仍有人坚持认为它是“新瓶装旧酒”，并以诞生于上世纪的 “Dreamweaver 也是低代码工具” 作为佐证。对此舒文也提出了看法，他认为当一个技术理念开始爆发式地变得平民化且发明价值，那意味着它可能率是正确的。“具体到低代码这个方向，我是非常认可的”，他进一步阐明低代码的本质实际上就是使非专业人员在具备组织逻辑、设定输进、掌握输出的信息化能力，并且能将这种能力用于解决日常事务。例如在曾经，“打字员”甚至是一种职业，这对 Z 世代的青少年们来说是很难理解的。

聚焦到终端领域，无论是 to C 还是 to B/G 领域，终端工程师们制造出了不计其数的 "View"。在此过程中，为了代码层复用，工程师们设计了 UI 组件库、功能模块库；为了能够更高效生产，工程师们借助了各种理念做到 Image to Code ；为了能够规模化生成，工程师们设计语义化的流程编排能力，进行低成本组装，而这正是工程师们一步步优化生产效率，继续追求精美化、规模化的过程。“它就是低代码 / 无代码，我认为这是非常了不起的”，舒文谈道，但同时他也认为，“我们也不能够迷信它，让它解决所有的问题，必须不断利用更先进的方式来提升零代码覆率”。

移动端性能优化

“在多元化体验时代的今天，移动互联网流量规模见顶后，各赛道对时长争夺的白热化阶段，消费者面对多平台抉择下对体验容忍度、忠诚度也逐年降低。对手机淘宝来讲如何让前台用户操作体验顺畅、全程购物体验称心，特殊在平台用户时长不断提升及浏览深度在不断加深的同时，保障好基本盘稳定性、长时在线的网络可用性、全链路性能的确定性可能是下一阶段赢得用户信赖的要害所在。而这些的背后都这意味着终端团队一直在跟业务和技术复杂度、设备性能挖掘与合理利用、复杂网络环境在做对抗。”弘禹谈道。

他提出性能优化相关技术其实已经是老生常谈，业界今天的关注点也已经从过往的常规手段，比如包大小治理、启动性能优化、外链唤端跳失率等，转移到今天的看可视可交互时长影响访问体验、帧率与顺畅度影响浏览体验、图片 / 视频上屏影响转化、内存可用性及崩溃率影响浏览深度等问题，从过往的平台技术视角转换到用户体验 / 业务价值重新审阅今天体验技术命题。

然而，一直到现在，有一个问题一直悬而未决，那就是在面对前台业务快速转变、表达型态更加多样化，如何将性能体验常态化、不劣化，“如何将能力建设跑在业务前面，用较低的技术投进成本下，让业务天然跑在一个性能高水位上，这可能是终端技术人需要探求并往解决的问题”。弘禹进一步谈道，针对此问题，可能还并没有确切答案，需要业界继续探索，但就当下来看，可以从眼下三点进手：

终端高可用：如今的移动互联网业务型态已经发生浩大转变，从过往单一图文型态开始走向直播 / 短视频为主流、无游戏 / 无互动不增长、3D/AR 不断体验创新，在此背景下终端设备始终是资源受限系统，如何做到长时间使用及深度浏览不崩溃，做好全局资源使用合理性与基础可用性的治理能力，以手机淘宝为例从过往看平台 Crash 率到分场景的精美化可用性治理、要害场景如加购下单阻断，在“留量时代”都是在对大盘增长做奉献。过往几年在阿里终端团队不断推进架构治理与技术攻坚下，终端高可用技术体系也有了长足的演进，体现在 Crash/Abort 率、技术舆情率等方向逐渐在收敛至良好水平。

APM/NPM：据不完全统计，中国目前有超过 500 万个不同类型的 App 并且数量天天都在继续增加，从各渠道不完全统计阿里系活跃 App 就超数百款，覆盖多平台 / 多设备 / 多系统 / 多渠道，且因业务型态与用户场景的不同，所抉择的技术选型各异。在此背景下终端如何面向异构复杂技术架构、多平台 x 系统 x 设备差异性下继续做好体验治理与性能表现的一致性，基础性能治理 APM 以及网络性能治理 NPM 的建设，对每个互联网企业的终端团队都至关重要。可以看到的是，过往几年阿里在不断完美性能可信指标体系、线上性能数据化能力、设备体验分级能力、弱网对抗与策略化能力等方面建设已取得一定阶段性的结果，使用更科学有效的方法使核心场景的顺畅度指标达标率提升到了 90% 以上，卡顿类 NPS 调研也升 10 个 pt 以上。

全链路可看测性：“当前每个移动 App 都期看留住更多用户，增加访问时长和浏览深度”，弘禹坦言，因此可以看到用户长时间使用产品时，在各种复杂无线环境下用户难免面临一些弱网掉线、无响应无返回、反常白屏等情状，叠加东西向多容器技术选型、南北向从业务到基础的链路复杂性，就要求终端团队对全链路有能力进行贯穿治理，“明确使用过程中压倒用户的最后一根稻草是什么”。

新兴热点合成

移动互联网的爆发和发展，带动了相关技术的一并兴起。对于移动端来说，目前也正在向智能汽车、IoT、元宇宙等方向探索。那么这些新兴技术热点又会对终端产生怎样的影响？

“我觉得多端多设备一定是个趋势”，弘禹谈道，所谓的多端多设备正是华为提出的“1+8+N”战术，其中，“1”代表手机，是核心；“8”代表 PC、平板、聪明屏、音箱、眼镜、手表、车机、耳机；“N”代表摄像头、扫地机、智能秤等外围智能硬件。

可以看到，今天的 IoT 或者车载系统，都是朝着智能化方向往发展，因此，未来可能会有一种新的体验出现：一个手机代表一个人的主身份跟汽车或 IoT 连接，即多设备之间发生无缝连接，形成一个智能体验闭环。落到具体技术的话，未来可能会对应出现端端协同、端云协同以及端和周边智能协同的新的技术体系或者方向。

弘禹推断，边缘化可能率是会来到的，但最终要看除了手机之外，其他设备多久能够实现智能化、数字化，假如这一天早点到来，也进一步会加速端交互上的协同。“我觉得这会形成一股新的增量，然后让各家 App 考虑如何将 App 作为用户一个身份，往跟更多的场景往合成和无缝连接。”

展看未来

综合多位技术专家的预判，终端领域已经行至新时代的前夜，那么在这个阶段，终端领域假如想有较大发展，需要解决哪些挑战，同时此阶段又蕴含哪些机遇？

综合两位受访专家的看法，终端领域若要有重大变革，需要考虑以下因素：

硬件、软件、使用的要害因素何时能够转变。这里，硬件即指终端设备，比如 VR、AR 或者能够替代手机的其他设备何时能够出现；软件即指与硬件相辅相成的操作系统，比如面向多端多设备协同的新的操作系统何时能够出现；

云和无线何时能够成熟。受端上摩尔定律和 CPU 的限制，如何在足够的带宽延时情状下，与云计算结合提升用户体验。

同时，也需要解决以下问题：

又快又好地面向业务交付。整个终端领域，无论是 Web 还是移动 App 开发，都面临着纷繁复杂的基础设施、层出不穷的看似新兴的技术方案的困扰，同时隔离的操作系统平台、高度分化的 App 版本和发布渠道等问题严重制约了 App 迭代的效率，而 Web 在移动场景下的体验和原生调用能力，也限制了它的使用场景。

在交付的基础上理解业务、通过技术扶助业务成功。聚焦到技术本身，互动游戏领域的工程师，需要更专注在图形技术、渲染技术，为业务抽象出超前、有创意的实现能力；中后台（运营、商家、广告主、政企事业）等业务域的工程师，需要更专注低代码、业务能力编排、流程自动化（RPA）等技术，大大提升客户解决事务的效率；短视频、直播领域的工程师，需要专注在音、视频等媒体技术，为用户提供一流的富媒体体验。（部份）桌面客户端的工程师，也需要关注跨平台研发技术（Node.js、Eletron 或者 Qt 等）。

当然，处在巨变前夕，除了挑战，两位受访专家也在本次摘访中预判了最有可能成为下一个风口的技术细分领域：

3D/XR。目前，各家终端使用都在往这一方向做相关探索，或许在 2023 年，3D 直播、3D 绘本等内容场景会涌现；

原生或跨端体验上或有创新；

工程体系上将进一步向平台工程上演进。

不过，弘禹也谈到，他推断短期之内终端生态并不会有爆发式变革：终端可能率以手机为主，设备主场景依然会是以 iOS、安卓为主流的平台。但是正如前文提到，这套体系会深度将前端及客户端进行整合，并且打磨用户体验仍是当下的重中之重。同时，对于业界来说，还要找到降低这部分的复杂度和门槛的有效方法，才能让终端工程师能够以较低复杂度的技术方式，继续提升业务交付效率及全链路体验。

对工程师说

随着终端概念的继续深化，此技术领域也将变得更加完全且全面，这也意味着不同的场景会逐渐产生差异化的技术特征和领域性。这对于一个技术领域来说，无疑意味着向前跨了一步，但对于身处其中的工程师来说，身上的担子却更加繁重。

2022 年是一个非常特殊的年份，大量的互联网公司光环褪色，越来越多的公司逐渐更务实。在降本增效的大环境下，工程师们既要保住基本盘，又要面对即将到来的新技术快速进行转型，“学习力、适应力和韧性是非常重要的，而且要有一个变革自己的心态”，弘禹提醒道。

另一方面，舒文也谈到即使面对诸多压力和挑战，倒也不必刻意追求时髦热门的技术。这里，他也提出几点适用于绝大多数终端工程师的基本逻辑：

踏实专注于当前所处的技术领域；

适当跳出当前的技术 Scope：如 Web 的工程师一定要跳出浏览器宿主的视野关注关联技术（如 Rust）、移动 App 的工程师避免被操作系统绑架关注跨平台交付技术；

面向未来的方向，要有好奇和探索之心：如从事 C 端领域关注 3D/XR 技术；to BG 领域关注可逻辑化编排的低代码方向；做使用交付要关注基于云化的全栈技术。

“继续面向业务交付当下和未来的技术价值，不痴迷于眼花缭乱的新奇巧技，才是追求专业的中正之道。”

摘访嘉宾：

郭虹宇 ( 弘禹 )：阿里巴巴终端委员会核心委员，大淘宝终端体验平台负责人。

舒文亮（舒文）：阿里巴巴终端委员会核心委员，大淘宝跨端技术、Web 技术负责人。

假如你对本文感兴致，欢迎在文末留言，或加进 InfoQ 写作平台话题讨论：/

VS Code 有多么不安全：一个扩展就可能导致公司 GitHub 中的所有代码被擦除？

清华应届硕士炮轰字节：恶意低薪，硕士白读还倒贴；马云不再实际掌握蚂蚁；开源 ROM 魔趣创始人公布删库跑路｜Q 资讯

百万用户逃离Twitter转向这个小众社交平台，互联网中心化终将走向大溃败？

芯片的后半场，“提速”依旧是第一要务，那除此之外呢？