共计 8262 个字符，预计需要花费 21 分钟才能阅读完成。
原文：https://mp.weixin.qq.com/s/G6o6xSAWroz0fJK7oShYLA，点击链接查看更多技术内容。
利用框架，是操作系统连贯开发者生态，实现用户体验的要害基础设施。其中，开发效率和运行体验是永恒的诉求，业界也在继续一直的倒退和演进。
本文重点围绕挪动利用框架，梳理其要害倒退脉络，并剖析其背地的技术演进思路以及目前的局限；同时，进一步联合万物智联的新场景和新生态，围绕相应的利用框架的设计和演进，分享集体在这个畛域的思考，实际，以及下一步摸索。
“但凡过往，皆为序章”- 威廉 · 莎士比亚
1、利用框架概览
1.1 利用，以及利用框架的根本组成
利用是用户应用操作系统 / 设施的入口，利用框架则是利用开发和运行的基础设施。用户通过各种各样的利用来和操作系统 / 设施交互，来满足相应的需要。以挪动平台为例，一个典型的利用以及绝对应的利用框架的根底组成大抵如下所示：
Figure 1 典型的利用构造以及相应的零碎运行环境
一个典型的利用构造次要包含以下几个局部:
1）用户界面以及相应的业务解决逻辑。这里次要包含构建用户界面所需的 UI（User Interface）组件，布局，动效，事件交互响应解决，所需的资源（图片 / 字体等），以及联合 UI 出现的业务逻辑解决等。从运行时的维度来看，它次要对应了零碎运行环境中的 UI 框架（含语言运行时），以及局部的零碎能力 API (Application Programming Interface)；
2）共享库。这里次要包含开发者封装好的 SDK（Software Development Kit），以及应用的三方库等。从运行时维度来看，它次要对应了零碎能力 API 以及语言运行时，如果共享库波及 UI 的话，还对应了 UI 框架；
3）包清单文件。这里次要包含利用包的构造形容，权限申明等，它次要对应了零碎运行环境中的包治理，利用生命周期 / 权限治理 / 过程治理等。其中，UI 框架的次要组成如下图所示：
Figure 2 UI 框架的次要组成
开发模型：对开发者提供的开发范式、UI 组件 /API 能力、编程语言等，重点体现的是开发效率与难易水平；
运行框架：UI 界面渲染及交互的根底能力框架，将开发者的程序运行在具体零碎平台上，包含利用整体渲染解决流程，语言逻辑执行流程，以及平台能力扩大机制，重点体现的是利用运行的性能体验；
平台适配：承载框架的具体操作系统或平台的适配层。
一般而言，利用框架中的包治理、生命周期 / 权限治理，和具体的操作系统关联较紧，并绝对稳固；能力 API 则是操作系统对设施能力的封装，次要影响利用应用设施的能力。UI 框架以及相应的编程语言则是影响用户体验（包含开发和运行体验）的要害因素，尤其随着挪动平台的一直遍及以及挪动设施的差别，挪动平台上的 UI 框架（含编程语言）是业界一直演进的重点畛域。
1.2 挪动平台上利用框架的演进
纵观十年来的倒退，总体而言，挪动平台上利用框架围绕着原生框架，三方跨平台框架交错倒退，并联合相应语言、工具的配套演进。下图形容了其中的要害框架 / 语言的演进概览。
Figure 3 挪动平台上要害语言 / 开发框架 / 工具演进概览
图中有几个要害节点：
1）2013 年，Facebook 公布的 React.js 第一次综合的将数据绑定，虚构 DOM（Document Object Model）等机制引入前端开发框架设计中。开发者只需申明好相应的数据和 UI 的绑定，之后由框架来跟踪数据的变动，并通过虚构 DOM 树的比照找出变动点，从而实现界面的自动更新，而无需开发者手动基于 DOM 编程。
2）2018 年，Google 公布的 Flutter 则是个重要的分界点。Flutter 交融了 Dart 语言，是第一个深度交融了语言的较为残缺的申明式开发框架，实现了齐全通过数据驱动的 UI 变更。另外，Flutter 通过基于 Skia 的自绘制引擎实现了高性能的跨平台的平台一致性的渲染能力，并提供了 Hot Reload 机制晋升开发测试体验。不过，Flutter 的整体设计哲学偏差底层的灵活性 – 次要通过底层的细粒度的能力供开发者自由组合，另外，Google 对 Dart 语言的简洁度的改良较少，整体上开发的简洁度以及对用户的友好度绝对有余。
3）2019 年，Apple SwiftUI 的推出，意味着支流 OS 的原生利用框架开始逐渐往申明式开发方式迁徙。SwiftUI 推动了 Swift 语言个性扩大实现了更加简洁天然的 UI 形容，并通过 XCode 开发工具的所见即所得的高效预览能力进一步晋升开发效率。同时，SwiftUI 也是真正意义上开始通过一套框架，逐渐对立 Apple 生态中的不同的设施 /OS 上的利用开发。
另外，2019 年 Google 将更简洁的 Kotlin 语言降级为 Android 首选的编程语言，并在 2021 年推出基于 Kotlin 的 UI 框架 Jetpack Compose, 同时联合开发工具 Android Studio 逐渐往多设施以及跨平台演进。
总体而言，挪动端利用框架的演进蕴含以下几个要害特色：
1）从命令式 UI 开发逐渐演进到申明式 UI 开发
2）UI 和编程语言的交融从绝对涣散演进到逐渐严密
3）开发范畴从单设施演进到多设施，从单平台演进到多平台
接下来的章节会别离围绕跨平台框架，以及原生利用框架逐渐开展，梳理其具体的演进脉络。
1.2.1 跨平台框架
因为 W3C（World Wide Web Consortium）规范的遍及以及 Web 人造的跨平台能力，跨平台框架次要是基于 Web 或 Web 的衍生技术。
最早试图补齐 Web 跨平台能力是一家叫做 PhoneGap 的公司，前面被 Adobe 收买，2012 年以 Cordova 的我的项目名开源公布。过后的 W3C 规范更多涵盖的是页面渲染，而设施相干能力的规范十分缺失，PhoneGap 的指标则是围绕着“Phone”补齐这方面能力“Gap”– 它定义了一套挪动平台上罕用的设施能力的 JS API，并基于 JS 引擎设计了一套扩大形式来实现不同平台上的 API，同时联合零碎的 Webview，配套相干零碎整合以及打包工具，部署成相应平台上的利用格局在指标操作系统平台上运行。PhoneGap 肯定水平上促成了 Web 在挪动设施上的倒退，然而它没有解决 Web 引擎自身的体验问题。过后的 Web 引擎(零碎自带的 Webview），尤其是 Android 平台上，能力较弱，并缺失硬件加速，略微简单的利用体验较差。针对这些问题，2014 年 Intel 开源技术核心推出了 Crosswalk 我的项目，在 Chromium 内核根底上，针对挪动平台上 Web 利用，做了进一步解耦和性能优化（包含硬件加速，包体积优化，以及针对游戏专门设计一套渲染门路等），并联合了 Cordova 补齐相干 API 能力，构建了可独立打包演进的 Web 引擎，性能体验失去了较大的晋升。而且，通过独立打包，也解决了因为 Android 零碎的碎片化，Webview 的版本不一，从而引起的利用体验（包含渲染能力和性能）不统一的问题。
Crosswalk 公布一年左右就吸引了近千款利用基于 Crosswalk 构建，其中无数款利用都达到了超过百万级的下载量。不过后续因为 Intel 在挪动平台上的策略调整，没有进一步演进。但这块的要害思路，后续或多或少在业界看到了相干的影子，比方 Google 后续推出的可独立降级的 ChromeWebview，以及国内各互联网公司各自构建的 WebView(腾讯的 X5 内核，阿里巴巴的 UC 内核等)。
Cordova+Crosswalk，肯定水平上晋升了基于 Web 的跨平台框架所需的 API 能力以及渲染性能，不过还有几个方面，还须要继续晋升：
Ⅰ、开发范式 / 前端框架
规范的 Web 还是一种“半申明式”的开发方式，即通过 HTML（Hyper Text Markup Langua-ge）, CSS（Cascading Style Sheets）来形容整体页面构造和款式，但当要扭转其中的界面元素时，开发者须要基于 W3C DOM API，通过具体编程，来实现其中相干节点的定位以及增删改。当所面对的界面交互越简单，所关联的数据越多，开发者累赘就越重，也越容易出错。
2013 年 Facebook 公布的 React.js，引入了数据和 UI 主动绑定，以及组件化机制，将申明式的能力较好的交融到前端框架中。这是开发理念的一次比拟大的提高。这样形式下，开发者无需去手动更改 UI 的构造，只须要形容好 UI 构造自身，以及数据和 UI 的绑定关系，框架层会主动跟踪数据的变动并更新相应的 UI，这样进一步晋升了 UI 框架开发效率。后续集体开发者尤雨溪推出的 Vue.js 框架实质上也是采纳了相似的思路，只不过在表达方式以及具体实现上有所不同。另外，通过前端框架层提供的组件能力，实质上是对 W3C HTML/CSS 规范的进行了进一步封装，提供了更加高层的能力，这样有利于聚焦于绝对罕用的 W3C 规范能力，同时通过相似 Virtual DOM 的机制，对底层的 Web 引擎做了进一步的解耦，从而为后续的进一步演进建设了肯定的根底。
Ⅱ、性能体验
因为 W3C 规范自身庞杂的历史积攒和复杂性，绝对应的 Web 引擎复杂度也十分高。简单的渲染管线，千万量级的代码，百兆级的二进制大小，以及大几十兆甚至百兆级的根底内存占用，让基于 Web 引擎的利用在整体性能体验，资源占用等相干方面，尤其在挪动平台上，和原生利用都有较大的差距，并难以较好解决。
2015 年 Facebook 在 React.js 根底上推出的 RN(React Native)，是 Web+Native 的一个典型代表。RN 的基本思路是开发范式上基于 React.js，而具体渲染门路上，则齐全绕过 Web 引擎，间接桥接到了操作系统原生的 UI 框架。2016 年阿里巴巴推出的 Weex 也是采纳了和 RN 相似的思路。
另外，针对 RN 的要害架构，Facebook 继续做了不少演进：
1）布局引擎（Yoga）。2016 年推出。通过实现 CSS 子集的模式实现高效的统一的跨平台布局体验；
2）JS 引擎（Hermes）。2019 年推出。针对挪动平台上体验问题做相应改良，比方通过引入肯定的 AOT（Ahead Of Time）机制，次要是两头码预编译，来晋升启动速度；
3）高效交互 / 按需加载等新架构。2022 年推出。反对高效的跨语言交互、数据共享，组件按需加载等相干机制。
通过这些相干的改良，RN 实现了肯定的均衡，基于 Web 的开发范式实现了较好的性能体验。不过，因为原生 UI 框架自身的差别，RN 难以达成较好的跨平台一致性；另外因为须要额定一层 Web 到 Native 的桥接转换，和原生相比，RN 在性能体验上人造就有肯定差距，难以逾越。
Google 在 2018 年推出的 Flutter，则是借鉴了 React 的思维，走了另外一条较为翻新的路。次要特色如下：
1）基于 Dart 语言的全新申明式范式设计，所有皆为 Widget，可灵便组合，并通过数据驱动 UI 渲染
2）基于底层画布的高效自绘制能力
3）Dart 运行时优化，比方高效的小对象调配开释能力，AOT 机制等
再配合绝对残缺的跨平台能力，以及相应的工具链，Flutter 具备了较好的综合竞争力。和类 RN 的计划相比，Flutter 在以下几个方面具备肯定劣势：
1）跨平台一致性。通过自绘制机制，具备更好的跨平台一致性的高效的渲染能力。
2）语言执行性能。通过强类型语言 Dart 的引入以及相应的运行时优化（AOT 等），具备更好的语言执行性能，实践上可对标 iOS/Android 原生语言。
不过，Flutter 也有本身的有余：
1）语言生态。Dart 语言生态和 JS 相比，有比拟大的差距。而且生态培养过程个别都比拟漫长。
2）动态化能力。Flutter 尚不具备可对标 JS 相干框架的动态化部署机制，实现利用界面 / 业务的动静刷新，而这块又是大多数挪动利用的强诉求。当然，这里有技术的因素，也有非技术的因素综合引起的。
另外一个层面，Flutter 申明式 UI 的设计原则上更偏重灵便组合，裸露了较多的细粒度底层的机制（包含各种细粒度的 Widget, 以及需进一步辨别 Widget 的有状态和无状态等等），而在整体利用开发的简洁天然度方面，则思考的绝对较少。
受到 Flutter 的启发，业界又衍生出了一些新的计划。比方桥接规范的 Web 前端框架到 Flutter，其目标是复用 Web 的生态劣势，以及 Flutter 的高性能跨平台渲染能力。这块的典型代表是阿里巴巴 2021 年开源的 Kraken，以及 2022 年进一步在此基础上演进的 KUN。这种计划有肯定水平的劣势，不过因为它实质上还是桥接转换，另外引入了两种虚拟机（JS 和 Dart），架构上就决定了这种计划在性能和内存体验存在难以解决的缺点。还有 JS 前端框架 + C/C++ 自绘制的计划，比方 Weex2.0，它在肯定水平上较好综合了 JS 层的生态和底层自绘制的劣势，不过在语言运行时，开发的便捷度等方面，还短少实质的改良。
总体而言，基于 Web 或通过 Web 衍生进去的跨平台框架，业界始终在继续的演进，包含 Web API 扩大，对立的继续优化的 Web 引擎，申明式前端框架，Web+Native 的交融，自绘制机制，语言和框架深度交融的架构等等。但这些跨平台框架，离真正意义上的极简开发，极致性能，并可对标原生利用体验的设计方面，还短少系统性的变革和逾越。
**1.2.2 原生利用框架
1.2.2.1 iOS 平台**
iOS 的原生利用框架是 Cocoa Touch，其中的 UI 框架和语言最早别离是 UIKit 和 OC(Objective-C)，提供了传统的命令式（imperative）编程形式。2014 年 Apple 推出了 Swift 语言，在简洁性，安全性，性能等方面都有进一步的晋升。2019 年，在 Swift 语言公布了 5 年之后，Apple 推出了新一代的 UI 框架 – SwiftUI，在开发理念上做了一次全面降级：从命令式编程演进到了简洁天然的申明式（declarative）编程，并通过一套 UI 框架可开发 Apple 生态中的不同 OS 上的利用（iOS/iPadOS/watchOS/macOS 等）。以下是几个比拟重要的演进点：
a. 全面采纳申明式来形容 UI，并且后续的 UI 变更都是通过数据驱动来实现。具体而言，Apple 从新定义了一整套开发范式，涵盖了 UI 的要害组成，UI 和数据的关联等信息。整个 UI 就是一段形容，实质上就是形容界面的一个值，而不是任何实例；另外 UI 变动通过繁多数据源来驱动（Apple 称之为“Single Source of Truth”），而不是像之前命令式编程那样，开发者能够任意获取某个实例，定位到某个节点来进行更改。这跟传统的开发方式，有实质的不同。
b. 简洁天然的开发范式。只管在 SwiftUI 之前也有各种申明式编程框架，但 SwiftUI 在简洁性以及类自然语言的易了解性实现了极大的晋升。具体而言，Apple 通过语言和框架的深度联合，达成了简洁天然的开发体验。Swift 的一些语言个性根本就是为 SwiftUI 服务，比方
1）Property Delegates（属性代理）
属性代理实质上一种语法糖机制，当拜访指定的数据时，包含 Get 或 Set，能够附加插入额定的解决逻辑。这个机制用来实现 @State 这类的装璜器，实现数据和 UI 之间的主动绑定，简化利用开发逻辑。
2）Trailing closure（尾随闭包）
尾随闭包次要用来加强可读性。当一个很长的闭包表达式作为最初一个参数传递给函数时，能够把它放在在函数括号之后。函数反对将其作为最初一个参数来调用。
3）Function Builders（函数结构器）
函数结构器也用来加强可读性，它能够用语句块作为承受参数列表，每行代码返回一个参数。
还有其余一些语法比方链式调用等等，这些独特组成了简洁天然的开发范式。
另外，SwiftUI 中自定义组件的内容，其实是通过 Function Builders 返回的恪守 View 协定的类型组成，这就意味着框架运行时有机会联合编译时的 UI 类型信息做相应优化来实现视图变动的疾速更新。
c. 配套工具反对。在工具层面，除了传统的调试调测等能力，Apple 的 Xcode 围绕 SwiftUI 预览做了比拟重要的加强，简要阐明如下：
1）实时双向预览。UI 代码刷新可实时看到相应的界面成果，同时可实现代码 - 界面的双向预览 – 点击代码可看到的相应的 UI 界面，抉择 UI 界面也可同步显示相应的代码。另外预览能够指定到组件级 – 通过加 @Preview 标签来指定相应组件进行预览
2）自定义预览。预览时可反对参数配置来定义预览的设施型号，暗黑模式，语言地区等上下文，并能够设置页面所依赖的入参等。
3）预览时动静交互，并可反对在预览器上调测。预览时能够实现罕用的动静交互，比方手势、键盘等输出，音量、Home 键、电源键等按键操作，以及网络、文件、多媒体能力反对等
这些预览相干的性能极大晋升了利用的开发效率。实质上，高效的成果统一的预览是须要 SwiftUI 以及相应能力可能间接运行在 PC（Personal Computer）平台上，能力达成较好的成果。
另外，从 2022 年 SwiftUI 4.0 的要害个性来看，Apple 一直加强高级组件，以及自定义等相干能力，继续晋升开发效率。比方更多的高级组件（各类图表，分享组件等），布局类型以及自定义布局能力加强（增加 Grid 网格布局，另外加强了自定义布局的能力，以及布局变动相干的动画）等等。
1.2.2.2 Android 平台
Android 的原生利用框架（Application Framework）次要包含利用治理，View 零碎，后盾服务（Service），内容提供者 (Content Provider)，播送承受机制(Broadcast Receiver) 等。其中 UI 框架和语言最早别离是 Android View 零碎以及 Java，次要也是采纳了命令式的开发模式（其中界面的初始申明能够通过 XML(eXtensible Markup Language)形式来定义，后续的操作则都是通过相应的命令式 API 来实现）。2016 年 JetBrains 公司正式公布 Kotlin 1.0 版本, 它是一种动态类型语言，提供了更加简洁，平安的语法个性（比如说解决 Java 的语法简短以及空指针等问题）。同时，Kotlin 在字节码级别和 Java 兼容。随着 Kotlin 的不断完善，再加上 Java 语言的版权问题等背地的起因，很快，2019 年 Google 发表 Kotlin 为 Android 挪动开发的首选语言。2021 年，Google 公布了基于 Kotlin 的申明式 UI 框架 – Jetpack Compose 1.0 版本。实质上，Jetpack Compose 和 SwiftUI 相似，都是申明式编程，都是繁多可信数据源驱动 UI 变更。不过，也有几点不同：
1）Jetpack Compose 中的界面示意为所有皆为可组合的函数。这些函数通常倡议设计为无附带效应（即不会产生在可组合函数作用域之外的利用状态的变动）。从运行时维度，这些无附带效应的组合函数可并行执行。
2）Jetpack Compose 整体开源，架构上则是提供了多层次的 API，从底往上，提供了运行时，界面，根底，Material 设计零碎的实现，每一层都是基于较低层的公共 API 构建。
3）跨平台能力。在 Google 公布 Jebpack Compose 1.0 版本后，Jetbrains 公司紧接着推出 Compose Multiplatform 我的项目，将 Compose 延长到桌面平台(Windows, macOS, Linux)，同时，配合 Kotlin Multiplatform 我的项目中的跨平台类库（网络、存储等），进一步简化基于 Jetpack Compose 的跨平台利用的开发。
在开发工具层面，Android Studio 反对 Jetpack Compose 实时预览等个性，但目前成熟度绝对弱一些，截至 2022 年，还未反对多设施预览，代码界面的双向预览，预览时调试，以及根底零碎能力（比方网络 / 存储）的模仿等。
Google 在 2022/10/24 给出的 Jetpack Compose 路线图中，Jetpack Compose 接下来重点会围绕性能体验，高级组件，开发工具改良（包含预览和实时编辑），多平台反对（WearOS，大屏设施，主屏幕 Widget）等方面开展。
总体而言，不论是原生框架，还是三方框架，除了性能体验，要害演进方向次要包含以下几点：
1）开发方式从命令式转为申明式；
2）语言和框架和工具联合更加严密；
3）逐渐减少多设施以及跨平台反对。
