共计 4179 个字符，预计需要花费 11 分钟才能阅读完成。
原文：https://mp.weixin.qq.com/s/i-ddVaC0iBVXq4t12hz6-Q，点击链接查看更多技术内容。
利用框架，是操作系统连贯开发者生态，实现用户体验的要害基础设施。其中，开发效率和运行体验是永恒的诉求，业界也在继续一直的倒退和演进。
本文重点围绕挪动利用框架，梳理其要害倒退脉络，并剖析其背地的技术演进思路以及目前的局限；同时，进一步联合万物智联的新场景和新生态，围绕相应的利用框架的设计和演进，分享集体在这个畛域的思考，实际，以及下一步摸索。
“预感将来的最好形式，就是发明将来”– 亚伯拉罕 · 林肯
1、面向万物智联的利用框架的架构设计思考
1.1 万物智联下的新场景，新需要
随着越来越多设施的智能化，新的场景以及新的需要也逐渐出现，次要包含：
a. 更多的不同状态的设施反对。包含各类屏幕（不同分辨率，尺寸，纵横比，折叠屏的折叠 / 开展切换，“刘海屏”等），以及各种交互模式（触控、键盘、鼠标、遥控器，表冠，语音，3D 手势等）。
b. 更多的不同能力的设施反对。包含各种芯片规格，各种 RAM（Random Access Memo-ry）/ROM（Read Only Memory）规格（百 KB 级别，MB 级别到 GB 级别），各种零碎能力规格等。
c. 设施之间的交互。包含利用在设施之间流转，协同等。
除此之外，对利用开发者而言，还有两类十分重要的需要：
Ⅰ、跨 OS（Operating System）平台能力
因为事实上多个支流 OS 的存在，如何无效的晋升可同时反对不同 OS（比方 iOS 和 Android 等）的利用开发效率是个重要的需要。目前开发者次要还是依赖三方跨平台框架。有些利用开发者在某些场景下，因为原生框架所带来的成果体验不统一带来较大的适配老本，甚至在一些要害模块不应用原生利用框架的能力，而是从新设计一套具备跨平台一致性的计划。
Ⅱ、动态化内容部署能力
如何将业务的内容在不违反相干规定的状况下迅速部署到客户端，以便业务疾速触达客户，也是大多数利用比拟通用的需要。目前次要是利用开发者通过设计相干框架能力来撑持，不必利用采纳计划各不相同。
这些对利用框架的设计都提出了新的要求，包含自适应能力、模块化能力，分布式能力，跨平台能力，动静内容更新能力等。当然，有些场景须要 OS 底层自身也要做相应的演进，比方可部署到更轻量的设施，分布式基础设施构建等。
1.2 目前利用框架的局限：
纵观现有的各类计划，在新兴的场景和利用需要下，逐步呈现出肯定的局限性。
1.2.1 原生利用框架
先说 Apple。以 Apple 的 iOS 上的利用框架为例，它在面向开发者的简洁高效，面向消费者的天然晦涩，语言、框架、工具的以及软硬件的紧密结合，生态的管控等方面都是第一流的。Apple 的生态是自闭环的，也是有明确边界的，这样的策略在 Apple 生态是一家独大时问题不大，但当事实上是多个支流 OS 生态并存，尤其随着万物智联的生态进一步扩大时，Apple 的形式呈现出了肯定的局限性：
1）Apple 的利用框架仅限于本身 OS 系列，比方 SwiftUI 只会关注 iOS, iPadOS,macOS 等，并没有思考如何在其它 OS 上实现肯定的复用能力。另外，对利用常见的利用内容动静更新的需要，Apple 则是严格的限度，并没有在框架层面思考怎么在一个适合范畴内提供肯定的反对。
2）Apple 的利用框架对系统设施有较高的要求，无奈撑持轻量化的智能设施（比方 M 级内存的设施等）。当然，这个也和 Apple 目前本身的定位相干。
再说 Google。以 Android 为例，目前主推的 Kotlin 和以及 Jetpack Compose 根本是 Google 为了逐渐解脱 Java，并对标 Apple 的 Swift 以及 SwiftUI 而研发的产物。Google 的整体策略绝对凋谢，在架构上，Jetpack Compose 做了分层解耦的设计，提供不同档次的 API 的开发能力供开发者灵便接入。另外，在跨 OS 平台维度，Jetpack Compose 也做了肯定的思考，除了 Android 之外，通过 JetBrains 的推动，也可反对 PC 平台（Windows/macOS）等。不过，目前 Jetpack Compose 在成熟度，以及多设施以及相干配套工具层面能力和 Apple 的 SwfitUI 相比还有不少差距。另外，后面所说的轻量化设施的反对，以及动态化内容更新的能力，也未波及。
1.2.2 三方跨平台利用框架
三方跨平台框架也在一直演进。下图总结了典型的三方框架的要害特色：
Figure 1 比照原生框架，典型三方跨平台框架的要害特色
另外，从语言角度，只管 JS/TS 具备较强的生态能力，业界也在一直的演进相应的引擎、工具链，但从对标原生语言的性能体验维度，还是有要害的有余，如下图所示：
Figure 2 比照原生语言，JS/TS 的现状以及有余
上图简要形容了 JS/TS 从编译到运行的大抵过程。只管业界在 JS 引擎方面继续在做优化晋升，比方重视高性能 JIT 能力的 Google 的 V8 以及 Apple 的 JavaScriptCore，重视轻量化、高效解析能力的 Facebook 的 Hermes, 集体开发者 Fabrice Bellard 的 QuickJS 等，但如果要对标原生语言的运行体验，还有几个重点的维度有待进一步冲破：
1）联合类型信息的优化，和更精细化类型的引入；
2）联合 PGO（Profiling Guide Optimiza-tion）的 AOT 能力;
3）更高效的并行化机制等。
1.3 如何设计利用框架，实现系统性逾越
如上所述，现有的原生利用框架以及三方跨平台框架都有本身定位 / 设计上的局限。那在万物智联的场景下，应该如何设计利用框架，能力较好的满足相干要求，并实现系统性逾越？
让咱们先回归根源，扫视一下利用框架要解决的外围问题。按递进关系，集体总结了三个维度的要害需要，如下所示：
Figure 3 利用框架要解决的外围问题
对同一 OS 平台而言，利用框架要解决的外围问题次要有三类：1. 开发效率；2. 性能体验；3. 跨设施能力。
而当事实上有多个支流 OS 平台长期并存时，跨平台的需要，或者更精确的说，如何进一步升高支流平台上利用适配的老本，就变的十分重要。它包含不同平台上的开发效率，性能体验，以及 SDK 包大小等因素。
除此之外，随着业务演进，动态化内容更新机制也演变为了十分要害的需要。
要构建可对标支流操作系统 (e.g. iOS,Android) 原生利用框架，并可能在面向万物智联的场景实现进一步逾越的新一代利用框架，集体认为，至多需围绕以下几个方面进行系统性的布局和设计：语言生态以及性能体验；申明式开发框架能力；跨设施自适应以及弹性部署能力；跨平台能力。
1.2.3.1 语言生态以及性能体验
iOS 平台的 Swift 以及 Android 平台的 Kotlin 曾经各自造成了相应的平台的主导语言，并有相应的公司来主导。对于新的 OS 平台而言，发明全新的语言是一种形式，不过语言以及相干生态的倒退须要比拟长的周期（从正式公布到肯定规模的利用个别至多须要 5 年以上的工夫）。还有另外一种形式，则是选取现有的绝对中立的并有广泛应用根底的语言，并在此基础上演进。JS/TS 即是这样的语言，它利用生态宽泛，也有相应的业界规范 -ECMAScript 来继续演进。
以下图片来源于 RedMonk 官网：https://redmonk.com/rstephens/2022/03/28/top-20-jan-2022/）
它显示了 2012-2022 这十年来的编程语言的热度排名状况（综合思考 Github 热度以及 StackOverflow 热度）。如下所示，JS/TS 语言继续当先。
Figure 4 编程语言排行榜 – RedMonk
如之前剖析，要让 JS/TS 具备可对标支流平台原生语言的性能以及开发体验，须要在语言、编译器以及运行时实现要害的逾越：
1）基于类型信息的编译以及运行时优化
2）AOT 能力，并可依据要害执行门路信息的反馈实现进一步优化
3）高效的并行化机制
4）申明式语法扩大，实现简洁天然的开发体验
以这些为根底，配合相应的优化的语言规范库，更细粒度的类型扩大，比方 64 位 /128 位等数值类型进一步联合硬件实现 SIMD（Single Instruction Multiple Data）的减速等，就具备了能达成高效的语言执行性能的要害能力。另外，在高效开发方面，除了语言层面的申明式语法扩大，还能够进一步针对分布式场景对数据类型做相应扩大，晋升跨设施场景下利用开发体验。
1.2.3.2 申明式开发框架
申明式开发框架的外围就是以简洁天然的形式来形容 UI，并通过数据的变动来驱动 UI 的主动变更。
从 UI 形容维度，它的要害组成如下（简洁天然是要害需要）：
a. 一套 UI 形容机制，包含根底构造语法，根底布局 / 组件 / 动效 / 事件处理 / 生命周期，以及组件化机制实现 UI 的积木式组合等
b. 一套状态治理形容机制，包含数据和 UI 的关联，数据的共享和传递机制等
c. 一套自定义扩大以及定制化机制，包含可自定义布局 / 绘制 / 动效，可对现有组件依据须要做定制 / 动静扩大等
从运行时维度，它的要害因素如下（性能体验是要害需要）：
a. 高效的 UI 渲染管线，并可实现组件 / 属性按需组合升高内存开销
b. 高效的状态治理 /UI 更新机制，依据数据变动精准定位刷新范畴
c. 自适应 UI 能力，以及多态组件能力（同一 UI 形容在不同设施可主动实现不同 UI 成果，主动适配不同的用户交互模式等）
d. 平台无关的一致性渲染能力
另外，在配套的工具层面，比方 IDE，需具备实时预览能力（包含双向预览，多设施预览，预览和调试交融等）。
1.2.3.3 跨设施自适应以及弹性部署能力
这里次要包含针对不同状态的设施的自适应（包含布局，控件状态等），不同能力的设施弹性部署（包含设施的提供 API 差别，零碎所需的资源差别等）。从架构设计而言，则需具备组件解耦，按需加载，以及轻量化等能力。
1.2.3.4 跨平台
这里次要包含平台形象层设计以及各个支流 OS 相应的适配实现，相干的工具链反对等。这样就能够基于一套主代码，部署到不同的 OS 平台上。其中的要害因素包含通用的 API 设计和实现（晋升利用代码的复用度），组件化机制（升高 SDK 大小），以及上述提到的平台统一化渲染能力等。