写点什么

面向万物智联的应用框架的思考和探索(中)

  • 2023-05-05
    上海
  • 本文字数:3751 字

    阅读完需:约 12 分钟

面向万物智联的应用框架的思考和探索(中)

原文: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 大小),以及上述提到的平台一致化渲染能力等。



用户头像

每一位开发者都是华为要汇聚的星星之火 2021-10-15 加入

提供HarmonyOS关键技术解析、版本更新、开发者实践和活动资讯,欢迎各位开发者加入HarmonyOS生态,一起创造无限可能!

评论

发布
暂无评论
面向万物智联的应用框架的思考和探索(中)_HarmonyOS开发者_InfoQ写作社区