面向万物智联的应用框架的思考和探索（上）

作者：yuzhiqiang

应用框架，是操作系统连接开发者生态，实现用户体验的关键基础设施。其中，开发效率和运行体验是永恒的诉求，业界也在持续不断的发展和演进。

本文重点围绕移动应用框架，梳理其关键发展脉络，并分析其背后的技术演进思路以及目前的局限；同时，进一步结合万物智联的新场景和新生态，围绕相应的应用框架的设计和演进，分享个人在这个领域的思考，实践，以及下一步探索。

“凡是过往，皆为序章”-威廉·莎士比亚

1、应用框架概览

1.1应用，以及应用框架的基本组成

应用是用户使用操作系统/设备的入口，应用框架则是应用开发和运行的基础设施。用户通过各种各样的应用来和操作系统/设备交互，来满足相应的需求。以移动平台为例，一个典型的应用以及相对应的应用框架的基础组成大致如下所示：

Figure1典型的应用结构以及相应的系统运行环境

一个典型的应用结构主要包括以下几个部分:

1）用户界面以及相应的业务处理逻辑。这里主要包括构建用户界面所需的UI（User Interface）组件，布局，动效，事件交互响应处理，所需的资源（图片/字体等），以及结合UI呈现的业务逻辑处理等。从运行时的维度来看，它主要对应了系统运行环境中的UI框架（含语言运行时），以及部分的系统能力API (Application Programming Interface)；

2）共享库。这里主要包括开发者封装好的SDK（Software Development Kit），以及使用的三方库等。从运行时维度来看，它主要对应了系统能力API以及语言运行时，如果共享库涉及UI的话，还对应了UI框架；

3）包清单文件。这里主要包括应用包的结构描述，权限声明等，它主要对应了系统运行环境中的包管理，应用生命周期/权限管理/进程管理等。

其中， UI框架的主要组成如下图所示：

Figure2UI框架的主要组成

开发模型：对开发者提供的开发范式、UI组件/API能力、编程语言等，重点体现的是开发效率与难易程度；

运行框架：UI界面渲染及交互的基础能力框架，将开发者的程序运行在具体系统平台上，包括应用整体渲染处理流程，语言逻辑执行流程，以及平台能力扩展机制，重点体现的是应用运行的性能体验；

平台适配：承载框架的具体操作系统或平台的适配层。

一般而言，应用框架中的包管理、生命周期/权限管理，和具体的操作系统关联较紧，并相对稳定；能力API则是操作系统对设备能力的封装，主要影响应用使用设备的能力。UI框架以及相应的编程语言则是影响用户体验（包括开发和运行体验）的关键要素，尤其随着移动平台的不断普及以及移动设备的差异，移动平台上的UI框架（含编程语言）是业界不断演进的重点领域。

1.2移动平台上应用框架的演进

纵观十年来的发展，总体而言，移动平台上应用框架围绕着原生框架，三方跨平台框架交织发展，并结合相应语言、工具的配套演进。下图描述了其中的关键框架/语言的演进概览。

Figure3 移动平台上关键语言/开发框架/工具演进概览

图中有几个关键节点：

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.2Android平台

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）逐步增加多设备以及跨平台支持。

审核编辑：汤梓红