简介：2020 年是 Apache Flink 社区生态加速繁荣的一年。
本文由 Apache Flink 中文社区发起人，阿里云计算平台事业部实时计算与开放平台部门负责人王峰分享，主要介绍 Flink 作为一款统一的流批一体引擎其发展现状及未来规划。大纲如下：
2020：Apache Flink 社区生态加速繁荣的一年
技术创新：Apache Flink 社区发展的核心驱动力
Flink 在阿里巴巴的现状和未来
2020：Apache Flink 社区生态加速繁荣的一年
1.Flink 蝉联 Apache 社区最活跃项目
我们先来介绍一下在 2020 年 Flink 社区生态发展的态势。整体来说，社区处在一个非常健康和高速的发展过程中，尤其是在 2020 年，我们取得了非常好的成果。从 Apache 软件基金会 2020 财年的报告中，可以看到一些很关键的数据：
Flink 用户和开发者邮件列表活跃度 Top1
Github 上 Flink 代码提交次数 Top2
Github 上 Flink 的用户访问量 Top2
综合这几个数据来看，可以认为 Flink 在 Apache 众多的开源项目中名列前茅，是 Apache 最活跃的项目之一。我们在 Github 上 Star 的数量，以及 Flink 贡献者数量的增长趋势也是非常喜人的。最近几年来，我们一直处在一个加速上涨的过程，每年都是平均 30% 以上的数据增长，可以看出 Flink 整个生态的繁荣和高速发展。
2.Apache Flink 年度发布总结
我们再回顾一下 2020 年整个社区在技术上取得的成果。Flink 社区在 2020 年发布了三个大的版本， Flink-1.10，Flink-1.11，以及 12 月最新发布的 Flink-1.12 三大版本。这三个版本相对于去年收官的版本 Flink-1.9 有非常大的进步。
在 Flink-1.9 中，我们完成了将 Blink 代码贡献合并进入 Flink 社区，使得 Flink 流批一体架构正式启动。今年我们又通过 1.10、1.11、1.12 这三个版本对 Flink 流批一体架构做了重要的升级和落地。同时在 Flink SQL 的开发场景下，我们不仅支持了流批一体的 SQL，同时也支持读取数据库 binlog 的
CDC，并且对接了新一代数据湖的架构。Flink 在 AI 场景下的应用也越来越广泛，所以我们在 Python 语言上也提供了大量支持，PyFlink 已经可以完整的支持 Flink 的开发。在 K8s 的生态上，我们也做了很多的工作。
Flink 经过今年三个版本的迭代以后，已经可以完整的以云原生的方式运行在 K8s 的生态之上，去除了对 Hadoop 的依赖。以后在 K8s 生态之上也可以使 Flink 的部署与其他的在线业务进行更好的混布。
3.Apache Flink 中文社区持续火热
在此也跟大家分享一下 Flink 中文社区的发展。
首先，从邮件列表来看，Flink 项目可能是 Apache 顶级项目中唯一一个开通中文用户邮件列表的项目。Apache 作为一个国际化的软件基金会，基本上以英文交流的方式为主，由于 Flink 在中国的活跃度空前，所以我们也开通了中文邮件列表。目前中文邮件列表的活跃度甚至已经超过英文邮件列表，成为全球 Flink 最活跃的地区。
其次，社区也开通了 Flink 的中文社区公众号（上图左侧），每周推送社区资讯、活动信息、最佳实践等内容为开发者提供了解社区进展的窗口，目前超过 3 万名活跃的开发者订阅我们，全年推送超过 200 篇与 Flink 技术，生态以及实践相关的最新资讯。
前段时间，我们还推出了 Flink 社区官方中文学习网站（https://flink-learning.org.cn/），希望帮助更多的开发者方便的学习 Flink 技术，了解 Flink 的行业实践，同时我们的 Flink 社区的钉钉大群也为大家提供了技术交流的平台，欢迎大家加入，进行技术的交流。
4.Apache Flink 成为实时计算事实标准
现在 Flink 已经成为了实时计算事实上的标准，我相信目前国内外各种主流的 IT 或科技驱动的公司，都已采用 Flink 做实时计算。Flink Forward Asia 2020 也邀请到了 40 多家国内外一流公司分享他们的 Flink 的技术和实践，非常感谢这些公司的讲师们、专家们来分享。我相信未来各行各业会有更多的公司采用 Flink
去解决实时数据的问题。
技术创新：Apache Flink社区发展的核心驱动力
1. 流计算引擎的内核技术创新
接下来主要跟大家介绍技术方面 Flink 社区在 2020 年的发展。我们相信技术创新是开源项目、开源社区持续发展的核心驱动力。这部分将分为三个方向来分享，首先介绍一下 Flink 在流计算引擎内核的一些技术创新。
Unaligned Checkpoint - 优化加速
第一个例子是非对齐式的 Checkpoint。Checkpoint 技术需要不断的在实时的数据流中插入 barrier，做定期的 snapshot，这是 Flink 最基本的理念之一。在现有的 Checkpoint 模式下，因为需要对齐 barrier，所以在反压或者数据计算压力非常大的情况下，Checkpoint 有可能是做不出来的。所以我们今年在
Flink 社区里做了一个非对齐的 Checkpoint，使得在反压的情况下，Checkpoint 也能够比较快速的做出来。
非对齐的 Checkpoint 和现有的对齐的 Checkpoint 可以通过设置 alignment timeout 进行自动切换：正常情况下做对齐式 Checkpoint，而在反压的时候切换到非对齐的 Checkpoint。
Approximate Failover – 更加灵活的容错模式
第二个技术创新是在容错方面。众所周知，Flink 的数据是支持强一致性（exactly-once）的。但是为了保证强一致性，其实在整个系统的可用性上有一些 trade off。为了保证数据强一致性，任何一个 Flink 节点的失败都会导致 Flink 全部节点回滚到上一次的 Checkpoint，在这个过程中需要进行整个 DAG
图的重启。在重启的过程中业务会有一个短时间的中断和回滚。其实很多场景对数据的强一致性不是必须的，对于少量数据的损失是可以接受的。对于一些采样数据的统计或者机器学习场景下特征计算，并不是说一条数据都不能丢，这些应用场景反而对数据的可用性有更高的要求。
所以我们在社区里创新做一种新的容错模式，Approximate Failover，一个更加灵活的容错模式，使得任何一个节点失败，只对这个节点本身进行重启和恢复，这样的话整个图不用重启，也就是说整个的数据流程不会中断。
Nexmark - Streaming Benchmark
同时，我们在流计算方向发现缺乏一个比较标准的 Benchmark 工具。在传统的批计算中，有各种 TPC Benchmark 可以比较完善的覆盖传统批计算的场景。而在实时流计算场景下则缺乏标准的 Benchmark。基于 Nexmark 的一篇论文，我们推出了第一版包含 16 个 SQL Query 的 benchmark 工具 Nexmark。Nexmark
有三个特点：
第一， 覆盖场景更全面
基于在线拍卖系统业务模型设计
16 个 Query，全面覆盖常用流计算场景
ANSI SQL，标准化，更容易扩展
第二， 更加方便易用
纯内存数据源生成器，灵活调控负载
无外部系统依赖
性能指标采集自动化
第三，开源，开放
Nexmark 已经开源 https://github.com/nexmark/nexmark，大家如果希望比对不同 Flink 版本之间流引擎的差异，或者对比不同的流计算引擎之间的差异，都可以采用这个工具。
2.Flink 架构的演进
全新的流批一体架构
再介绍一下 Flink 架构的演进，Flink 是一个流计算驱动的引擎，它的核心是 Streaming。但是它可以基于 Streaming 的内核，实现流批一体更全能的架构。
2020 年，Flink 在流批一体上走出了坚实的一步，可以抽象的总结为 Flink 1.10 和 1.11 这两个大的版本，主要是完成 SQL 层的流批一体化和实现生产可用性。我们实现了统一的流批一体的 SQL 和 Table 的表达能力，以及统一的 Query Processor，统一的 Runtime。
在刚发布的 1.12 版本中，我们也对 DataStream API 进行了流批一体化。在 DataStream 原生的流的算子上增加批的算子，也就是说 DataStream 也可以有两种执行模式，批模式和流模式里面也可以混合批算子和流算子。
正在规划的 1.13 的版本中，会彻底实现 DataStream 流批一体化的算子，整个的计算框架和 SQL 一样，完全都是流批一体化的计算能力。这样一来，原来 Flink 中的 DataSet 这套老的 API 就可以去掉，完全实现真正的流批一体的架构。
在全新的流批一体的架构之下，整个 Flink 的机制也更加清晰。我们有两种 API，一个是 Table 或者 SQL 的关系型 API，还有 DataStream 这种可以更灵活控制物理执行的 API。无论是高层的 API（Table 或者 SQL），还是低级的
API（DataStream），都可以实现流批一体的统一表达。我们还可以将用户的需求表达的图转换为一套统一的执行 DAG 图。这套执行 DAG 图中，可以使用 Bounded Stream，也可以使用 Unbounded Stream，也就是有限流和无限流两种模式。我们的 Unified Connector
的框架也是流批一体的统一框架：可以读流式的存储，也可以读批式的存储，整个架构将会把流和批真正融为一体。
在核心的 Runtime 层也实现了流批一体。调度和 Shuffle 是 Runtime 层最核心的两部分。在调度层支持 Pluggable 的插件机制，可以实现不同的调度策略应对流、批、甚至流批混合的场景。在 Shuffle Service 层面，也支持流式和批式的 Shuffle。
同时我们正在做更新一代的 Shuffle Service 的框架：Remote Shuffle Service。Remote Shuffle Service 可以部署到 K8s 里面，实现存储计算的分离。就是说，Flink 的计算层和 Shuffle 类似于一个存储服务层，完全解耦的部署，让 Flink 的运行更加具有灵活性。
TPC-DS Benchmark
批的性能究竟如何是大家比较关心的一个问题。经过三个版本的努力之后，Flink-1.12 比 Flink-1.9（去年的版本）已经有三倍的提升。可以看到，在 10TB 数据量，20 台机器的情况下，我们的 TPC-DS 的运行时间已经收敛到 1 万秒以内了。所以 Flink 的批处理性能已经完全达到生产标准，不亚于任何一个业界目前主流的批处理引擎。
流批一体数据集成
流批一体不只是一个技术上的问题，我想更详细的解释一下流批一体架构到底怎么去改变在不同典型场景下的数据处理的方式和数据分析的架构。
我们先看第一个，在大数据场景下经常需要数据同步或者数据集成，也就是将数据库中的数据同步到大数据的数仓或者其他存储中。上图中的左边是传统的经典数据集成的模式之一，全量的同步和增量的同步实际上是两套技术，我们需要定期将全量同步的数据跟增量同步数据做 merge，不断的迭代来把数据库的数据同步到数据仓库中。
但基于 Flink 流批一体的话，整个数据集成的架构将截然不同。因为 Flink SQL 也支持数据库（像 MySQL 和 PG）的 CDC 语义，所以可以用 Flink SQL 一键同步数据库的数据到 Hive、ClickHouse、TiDB 等开源的数据库或开源的 KV 存储中。在 Flink 流批一体架构的基础上，Flink 的 connector
也是流批混合的，它可以先读取数据库全量数据同步到数仓中，然后自动切换到增量模式，通过 CDC 读 Binlog 进行增量和全量的同步，Flink 内部都可以自动的去协调好，这就是流批一体的价值。
基于 Flink 的流批一体数仓架构
第二个变化，数仓架构。目前主流数仓架构都是一套典型的离线数仓和一套新的实时数仓，但这两套技术栈是分开的。在离线数仓里，大家还是习惯用 Hive 或者 Spark，在实时数仓中用 Flink 加 Kafka。但是这个方案总结下来有三个问题需要解决：
两套开发流程，成本高。
数据链路冗余。数仓的经典架构大家都知道，ODS 层，DWD 层，DWS 层。在 DWD 的明细层可以看到实时数仓和离线数仓经常做的是一模一样的事情，如数据清洗、数据补齐、数据过滤等，两套链路将上面的事情做了两遍。
数据口径的一致性难以保证。实时报表需要实时观看，同时每天晚上会再做一次离线报表用于第二天分析。但是这两份报表的数据在时间的维度上可能是不一致的，因为它是由两套引擎算出来的，可能有两套用户代码，两套 UDF，两套 SQL，两套数仓的构建模型，在业务上造成了巨大的困惑，很难通过资源或人力来弥补。
如果用新的流批一体架构来解决，以上难题将极大降低。
首先，Flink 是一套 Flink SQL 开发，不存在两套开发成本。一个开发团队，一套技术栈，就可以做所有的离线和实时业务统计的问题。
第二，数据链路也不存在冗余，明细层的计算一次即可，不需要离线再算一遍。
第三，数据口径天然一致。无论是离线的流程，还是实时的流程，都是一套引擎，一套 SQL，一套 UDF，一套开发人员，所以它天然是一致的，不存在实时和离线数据口径不一致的问题。
基于 Flink 的流批一体数据湖架构
再往前走一步，我们通常会把数据落到 Hive 存储层，但是当数据规模逐渐的增大，也存在一些瓶颈。比如说数据文件规模增大以后，元数据的管理可能是瓶颈。还有一个很重要的问题，Hive 不支持数据的实时更新。Hive 没有办法实时，或者准实时化地提供数仓能力。现在比较新的数据湖架构，在一定程度上可以解决 Hive
作为数仓的问题。数据湖可以解决这种更具扩展性的元数据的问题，而且数据湖的存储支持数据的更新，是一个流批一体的存储。数据湖存储与 Flink 结合，就可以将实时离线一体化的数仓架构演变成实时离线一体化的数据湖架构。比如：
Flink + Iceberg：
通用化设计，解耦计算引擎，开放数据格式
提供基础 ACID 保证以及 Snapshot 功能
存储流批统一，支持批量和细粒度更新
低成本的元数据管理
0.10 已发布 Flink 实时写入和批量读取分析功能
0.11 规划自动小文件合并和 Upsert 支持。
另外，Flink 跟 Hudi 的整合，我们也在跟 Hudi 社区做比较密切的合作，未来的几个月我们将会推出 Flink 加 Hudi 的完整的解决方案。
Flink + Hudi：
Upsert 功能支持较为成熟
Table 组织方式灵活（根据场景选择 copy on write 还是 merge on read）
Flink 与 Hudi 的集成正在积极对接中
3.大数据与AI一体化
最后一个主流技术方向就是 AI，现在 AI 是非常火的一个场景，同时 AI 对大数据存在着很强的算力需求。接下来跟大家分享 Flink 在 AI 场景下，社区做的一些事情，以及未来的规划。
PyFlink 逐步走向成熟
首先我们看一下语言层，因为 AI 的开发者很喜欢用 Python，所以 Flink 提供了 Python 语言的支持，在 2020 年社区做了很多的工作，我们的 PyFlink 项目也取得了很多的成果。
Python 版本的 Table 和 DataStream API：
Python UDX 支持 logging、metrics 等功能，方便作业调试及监控
用户可以用纯 Python 语言开发 Flink 程序
SQL 中支持 Python UDX：
包括 Python UDF、Python UDTF 以及 Python UDAF
SQL 开发人员也可以直接使用 Python 库
增加 Pandas 类库支持：
支持 Pandas UDF、Pandas UDAF 等功能
支持 Python Table 与 Pandas DataFrame 的互转
用户可以在 Flink 程序中使用 Pandas 类库。
Alink 新增数十个开源算法
在算法层面，阿里巴巴去年（2019）开源了 Alink，一套在 Flink 上的流批一体的传统机器学习算法。今年阿里巴巴的机器学习团队也在 Alink 上继续开源数 10 种新的算法，去解决更多场景下的算法组件的问题，进一步提升机器学习的开发体验。我们希望未来随着 Flink 新的 DataStream 的 API 也支持流批一体的迭代能力，我们会将
Alink 基于新的 DataStream 上面的迭代能力贡献到 Flink 的机器学习中，让标准的 Flink 机器学习能有一个比较大的突破。
大数据与 AI 一体化流程管理
大数据与 AI 一体化是最近很值得探讨的问题之一。大数据和 AI 技术是水乳交融的。通过大数据加 AI 的很多核心技术一体化，去解决整个在线的，比如实时推荐，或者其他的在线机器学习的一套完整流程。在这个过程中，大数据侧重的是数据处理、数据验证、数据分析，而 AI 的技术更侧重于模型的训练、模型的预测等等。
但这一整套的过程，其实要大家合力才能去真正解决业务的问题。阿里巴巴有很强的基因来做这件事情，Flink 最早诞生于搜索推荐场景，所以我们的在线搜索、在线推荐就是用 Flink 加 TensorFlow
的技术来实现的后台机器学习流程。我们也将阿里积累的这套流程做了一个抽象，把业务属性的东西全部去掉，只把开源的纯技术体系留下，它抽象成一套标准的模板，标准的解决方案，并开源出来，叫 Flink AI Extended。这个项目主要由两个部分来组成。
第一，Deep Learning on Flink: Flink 计算引擎和深度学习引擎集成
Tensorflow / PyTorch on Flink
大数据计算任务和机器学习任务无缝对接。
第二， Flink AI Flow: 基于 Flink 的实时机器学习工作流
基于事件的流批混合工作流
大数据与机器学习全链路一体化。
我们希望通过开源主流的大数据加 AI 的技术体系，大家都可以快速的应用到业务场景中，做出来一套在线机器学习业务，比如实时推荐等。这个项目目前也是非常灵活，它可以运行 Standalone 单机版，也可以运行在 Hadoop YARN，或者 Kubernetes 上。
Flink Native on K8S
K8s 是现在标准化的一个行为，云原生。我们相信 K8s 的未来会更加的广阔，起码 Flink 一定要支持在 K8s 之下原生的运行，实现云原生的部署模式。经过今年三个版本的努力，我们已经支持原生的将 Flink 部署到 K8s 里面。Flink 的 job manager 可以跟 K8s 的 master
进行直接通信，动态的申请资源，根据运行的负载动态扩缩容。同时我们完全对接了 K8s 的 HA 方案，也支持 GPU 的调度和 CPU 的调度。所以现在 Flink Native on K8S 这个方案已经非常成熟，如果企业对 Flink 在 K8s 部署上有诉求，可以使用 Flink-1.12 这个版本。
Flink 在阿里巴巴的现状和未来
技术的创新和技术的价值一定要靠业务去检验，业务价值是最终的判定标准。阿里巴巴不仅是 Apache Flink 最大的推动者和支持者，同时也是最大的用户。下面介绍 Flink 在阿里应用的现状以及后续规划。
1.Flink 在阿里巴巴的发展历程
首先看一下 Flink 在阿里巴巴的成长路线，还是非常有节奏的。
2016 年，我们将 Flink 大规模运行在双 11 场景，最早的是在搜索推荐的落地，支持了搜索推荐的全链路实时化，以及在线学习的实时化。
2017 年，我们认定 Flink 作为一个全集团级别的实时数据处理引擎，支持整个阿里巴巴集团的业务。
2018 年，我们开始上云，第一次通过将 Flink 推到云上，去积累技术，服务更多中小企业。
2019 年，我们向国际化迈进了一步，收购了 Flink 的创始公司，阿里巴巴投入了更多的资源和人力去推动 Flink 社区的发展。
到今年，我们已经看到 Flink 成为了一个实时计算事实上的国际的标准。在全球，许多云厂商和大数据的软件厂商都已经将 Flink 内置到他们的产品里，成为标准云产品的形态之一。
2.双十一全链路数据实时化
今年双 11，基于 Flink 的实时计算平台在阿里内部已经完整的支持了所有场景的实时数据的业务。在数据规模上，已经有超过数百万的 CPU Core 在运行。今年在资源基本上没有增加的情况下，计算能力相对去年有一倍的增长。同时，通过技术优化，实现了整个阿里经济体的全链路数据实时化。
3.“全链路数据实时化” to ”实时离线一体化”
全链路数据实时化不是我们的终点，下一步是实现实时离线一体化的诉求。在电商大促的场景下，需要对实时数据与离线数据做对比，如果实时和离线的数据不一致，或者不知道是不是一致的，那就会对业务造成很大的干扰，业务没有办法判断到底是技术上的误差导致的结果不符合预期，还是业务效果真的不符合预期。所以今年双
11，阿里巴巴第一次大规模落地流批一体的场景以及实时离线一体化业务场景。
今年双 11 流批一体的落地场景是天猫的双11营销大屏分析。通过大屏数据分析，可以看到不同的维度的数据，对比双11当天用户的交易量和一个月前、甚至去年双 11，它的增长是否符合预期。我们能确保流批结果是一致的。
此外，我们结合了阿里巴巴自研的 Hologres 流批一体的存储能力，加上 Flink 流批一体的计算能力，实现了全链路的流批一体的数据架构，以及整个业务架构。在此架构下，我们不仅保持数据天然的一致性，业务上没有了干扰，同时我们使淘宝的小二开发数据报表的开发效率提升了 4~10 倍。
另一方面，Flink 的流任务和批任务运行在一个集群里，双11当天巨大的流量到了晚上可能会变成一个波谷，这时我们会运行大量离线的批的分析任务，为第二天的报表做准备。所以削峰填谷的应用使我们的资源节省了一倍，这是一个非常可观的数据。
目前，除了阿里巴巴外，社区上也有诸多合作密切的伙伴如字节跳动、小米、网易、知乎等在探索使用 Flink 做流批一体统一架构的方案。我相信 2020 年是 Flink 新一代数据架构落地的元年，从全链路数据实时化走向实时离线一体化的元年，并且阿里巴巴已经在最核心的双 11 业务场景下进行了落地。
明年，会有更多的企业尝试，并贡献社区完善新架构，推动社区朝着新方向：流批一体化、离线实时一体化、大数据与 AI 一体化演进。真正让技术创新服务好业务，改变大数据处理架构、大数据与 AI 融合的方式，在各行各业释放其价值。
原文链接：https://developer.aliyun.com/article/781348?
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
}

招贤纳士
我们急需浏览器渲染引擎/Flutter 渲染引擎人才，欢迎大牛们加入我们。
背景
本文作者作为讲师参加了 2020 年上海外滩大会，以下文章来自大会分享内容的整理文稿。
目录
大家早上好，欢迎参加本次分享，今天我的分享主题是《Web 技术发展趋势及 U4 内核技术演进》。
今天主要有三方面的内容：
第一，让我们来看一下 Chromium 近期的重要技术进展；
第二，介绍我们 U4 内核的重要技术优化点；
最后，展望一下浏览器内核的未来发展。
Chromium 重要技术进展
Web 现状
首先我们来看一下这 3 个数字。
不知道大家看到这 3 个数字会有什么样的感受呢？
我最大的感受是：Web 技术的生命力实在是太强大了！在各种新技术层出不穷的今天，Web 经过了 30 多年的发展，除了支撑传统互联网领域的网页搭建，在移动互联网领域也有着非常广泛的应用，比如小程序、信息流、会场这样的业务场景，我们都可以看到 Web 技术的身影。
为什么 Web 能有如此强大的生命力呢？我认为有一点非常重要，就是高度标准化。由于高度标准化，它有着很强的向下兼容性和跨平台兼容性，从而可以非常广泛地应用，而且经久不衰。但是高度标准化也会带来一个问题，就是新特性的落地非常缓慢，一个特性从提出到形成标准，到最终在浏览器中落地，需要经过多年的时间，对于开发者来说，了解浏览器内核的进展更有实际意义。
所以今天我们主要是从浏览器内核的层面，来了解 Web 技术的发展趋势。
全球浏览器内核分布
这里是 statcounter 最近一年对移动端浏览器市场占有率的统计数据。大家可以看到，Chrome 已经遥遥领先，有着超过 60% 的市场占有率。而且这里仅仅是从浏览器维度来统计，如果从内核的维度来看，Opera、UC、QQ 等浏览器都是基于 Chromium 内核，它们总的加起来市场占有率已经超过 70%，可以说 Chromium 已经引领了 Web
技术的发展方向。
接下来我们来看一下 Chromium 的一些重要技术进展。
Chrome 架构优化
首先来了解一下 Chromium 的 3 个大的架构优化：
Onion Soup：它的主要目的是为了解耦 Chromium 内核的组件依赖，使得各种能力可以以服务的方式提供，从而简化复杂的代码结构，提升可扩展性和性能。该项目从 2015 年持续到现在已经有 5 年多的时间，目前还在继续进行中。
Sliming paint：它是渲染流水线的大改造，主要目的是提升渲染正确性和性能，它也经历了 5 年多的时间，目前已经有实验室版本落地，但是正式版还没有发布。
LayoutNG：它是一个新的排版系统，主要是为了抛弃旧排版系统的历史负担，使得新特性的扩展更加容易，而且可以做到可分段 和可中断。LayoutNG 历经 4 年的时间，在去年的 m76 版本已经有第一个版本正式上线。但是从我们的实验室测试数据来看，对比旧的排版系统，它并没有明显的性能优势，这方面 Chrome 也在持续优化中，相信随着版本的迭代，LayoutNG
将会逐渐体现出它的技术优势。
看完 Chromium 大的技术架构优化，我们再来看一下 Chromium 的一些重要的功能特性。
PWA
首先是 PWA。它是 Chromium 近几年提出的一个非常重要的概念，从它的名字（渐进式 Web 应用）可以看出，它的主要目标是使得开发者可以利用 Web 技术，逐渐构建出用户体验可以与 native 应用相媲美的 Web 应用。PWA 是各种技术的整合包装，它包括了几个重要特性：Service Worker 提供了离线化访问的能力、A2HS（Add To
HomeScreen）提供了添加图标到桌面的能力、Web Push 提供消息推送的能力、Notification API 提供触发手机通知的能力。我们可以看到，一个 Web 页面，有了离线化的访问能力，又可以添加图标到桌面，用户点击图标打开一个应用，几乎分辨不出是 Web 实现还是 native 实现，这就是 PWA 想要达到的效果。除了这 4
个，它还包含了其它的一些特性，这里就不再一一介绍。
Device API
我们再来看一个跟 PWA 目的比较接近的特性 Device API。Device API 也是为了增强 Web 的表现力，但是它是通过开放更多的设备能力给开发者来实现。例如 m67 增加了 Sensor API、m81 增加了 Web NFC，而目前正在开发 Web GPU 等新的 Device API。随着 Device API 的不断增加，Web
对硬件的控制力将越来越强，能力也会越来越强。
WebAssembly
我们再来看一个最近比较受关注的特性——WebAssembly，WASM。WASM 是由 Firefox、Chrome、Microsoft Edge、Safari 4 个大浏览器厂商一起提出的新的浏览器语言标准。它以二进制的格式存在，可以直接运行在 JS 引擎上面，而且它是 AOT 编译的，不需要经过复杂的 JIT 编译流水线就可以直接执行，拥有更高的性能。WASM
的另一个特点是可移植，也是它存在的一个主要目的，我们可以通过编译工具，直接将 native 代码编译成 WASM 运行在浏览器上面，节省开发移植的成本。例如，前段时间 bilibili 分享了他们的一个应用，他们将用 C++ 实现的 FFmpeg 音视频解码库直接编译成 WASM，运行在浏览器上面。随着直播、AI、AR、VR 等新的业务场景崛起，WASM
得到越来越多的关注，它的高性能以及可移植可以很好地应用于这些场景。但是 WASM 也存在一些问题，例如不支持多线程、调试不够友好等，目前 Chromium 在持续优化该特性。
Houdini
接下来我们再来看一个大家不太熟悉的项目——Houdini。Houdini 没有像 WebAssembly 那么出名，但是它对开发者来说，也是一个非常重要的项目。简单来说，Houdini 主要是向开发者提供一系列控制排版渲染流水线的 API 和 CSS 特性，使得开发者可以更容易构建效果酷炫的页面。它主要包括了像 Worklets、CSS parse API、CSS
Layout API 等一系列技术标准，目前大部分标准 Chrome 已经支持。例如 CSS Paint API，开发者可以写一段绘制图片的 JS 代码，然后添加到 Worklet 去运行，接下来在 CSS 的 background-image 属性中引用这个 worklet，从而实现用 JS 绘制元素的背景图片。从这个例子我们可以看到，Houdini
的目的是开放出更多浏览器内核能力给开发者，让开发者可以更方便地控制整个排版渲染流水线，从而可以更高效地实现一些复杂的效果，使整个 Web 开发体验更加友好。
Performance API
除了功能和性能方面的优化，我们再来看另外一个重要的特性——Performance API。
Performance API 主要是提供一系列 API 帮助开发者更精确衡量线上页面性能，比如加载时间、事件响应时间、内存占用等等，从而可以更有针对性地做优化，提升线上页面的体验。
Web 技术发展趋势
前面我们了解了 Chrome 近期一些核心的技术演进。从这些技术演进中，我们可以看到 Web 技术的 2 个大的发展趋势，一个是从 Web 应用本身效果来看，Web 的表现力正在越来越接近原生应用，无论是 PWA，还是 Device API，都是在朝着这方面去推进；
第二个是从开发者角度来看，整个 Web 的开发体验也在变得越来越好，无论是 Houdini、Performance API 还是开发者工具平台的完善，都是在使得开发者构建优质的 Web 应用越来越简单高效。
在这 2 个大的发展趋势下面，我们 U4 内核又有着怎样的技术优化呢？接下来我们进入第二部分。
U4 内核技术优化介绍
Ali Web Platform
首先我们来看一下 U4 内核在阿里集团的位置。U4 内核之前主要是通过 UC 浏览器为大家所熟悉，经过这几年的发展，它已经从一个浏览器内核逐渐演变为一个 Web Platform，服务了像支付宝、手淘、天猫、UC、钉钉、飞猪等阿里的大部分 APP，U4 内核是阿里集团中 Web 生态非常重要的组成部分。
我们从一个传统的浏览器内核演变为一个 Web Platform，遇到了那些挑战，又是怎么应对的呢？
Ali Web Platform 遇到的挑战
这个过程我们遇到了 2 个最大的挑战，一个是稳定性、一个是安全性。
稳定性主要体现在 2 个方面：
随着我们的应用场景及机型覆盖面更加广泛，我们遇到的设备及API兼容性问题会更多，导致影响内核的稳定性；
阿里的业务场景非常复杂，对内存、性能提出了更高要求。
安全的挑战主要是跟业务的形态有关，阿里的大部分业务都跟钱有关，例如我们的电商业务、支付业务。跟钱有关，对安全的要求就会非常高。这也对我们 U4 内核也提出了更高的要求。
那么我们是如何应对这 2 个挑战的呢？
U4 内核多进程架构
这里我们做了一件最重要的事情，就是进行进程架构的大改造——从一开始的单进程架构，逐步演进到现在的多进程架构模型。
为什么多进程架构可以应对这 2 个大挑战呢？这里主要体现在3个方面：
多进程架构可以将一些子模块的崩溃隔离到子进程，从而避免影响主进程，引起整个 APP 的崩溃，并且子进程在崩溃后是可以自动恢复的，用户可以在几乎无感知的情况下正常浏览网页；
通过把一些模块放到子进程里，可以有效地缓解主进程虚拟内存空间不足的压力，从而减少 OOM 崩溃。因为对于 32 位应用，Android 每个进程只有 4G 的虚拟内存空间，在复杂的场景下很容易出现虚拟内存空间不足的 OOM 崩溃；
我们做了一个沙箱 Render 进程，沙箱进程是一个权限受限的进程，JS 引擎也是运行在 Render 进程中。通过把 Render 进程隔离到一个权限受限的沙箱进程里面，就算 JS 引擎出现安全漏洞，也可以有效地防止主进程受到攻击，或者核心用户数据遭到窃取。
下面我们来看一下多进程改造后的效果。
首先我们的稳定性有了非常大的提升，主进程崩溃降低 90%+，其中 OOM 更是下降了 97%+。
另外它可以做到子进程崩溃快速自动恢复，使得用户可以在几乎无感知的情况下，恢复页面的浏览。
我们来看一下这个视频。左边是云真机上面运行的支付宝蚂蚁森林，右边是一个命令行终端，我们通过 shell 命令，kill 掉它的 GPU 进程，模拟 GPU 进程发生崩溃的场景。我们可以看到左边的画面，基本看不到任何异常变化。在 GPU 进程被 kill 之后，进程会快速自动恢复，用户在无感知的情况下，继续正常浏览 H5 页面。
打造更好的 Web 平台
解决了稳定性和安全性的 2 大挑战之后，我们就可以成为一个很好的 Web Platform 吗？答案肯定是否定的。
为了打造一个更好的 Web Platform，我们还做了更多的功能优化。首先来看一个我们比较有特色的功能——混合渲染。
混合渲染
混合渲染主要是想解决这样的一个业务痛点：
某些业务之前是用 native 实现的，后面想用 Web 去实现，但是使用的部分第三方组件只有 native 版本。如果使用 Web 重新开发第三方组件，成本会比较高，而且效果也会打个问号。最典型的一个场景就是地图控件。
为了解决这个痛点，我们实现了混合渲染方案。该方案提供了在页面中嵌入 native 组件的能力，将页面和 native 组件无缝地融合起来，并且保证整体效果和交互非常自然，业务不需要做额外的适配。
这里我们来看 2 个视频：第一个是之前支付宝上面的 OFO 单车小程序。它的地图是用 native 实现的，而覆盖在地图上面的小控件和文字，都是用 H5 实现的。我们可以看到，整个交互非常自然，用户完全无法区分哪些是 native 组件，哪些是 H5 组件，实现了 native 与 H5 的完美融合；第二个视频是我们的一个 AR 相机的 DEMO，它的相机画面是用
native 技术呈现的，上面的卡片特效是用 H5 呈现的，这里完美地结合了高性能的 native 相机和高动态化的 H5 卡片，很好地融合了 Web 技术与 native 技术的优点。
混合渲染的应用场景非常多，目前已经广泛应用在小程序和各种业务场景中，成为 U4 内核最重要的一个功能特性。
接下来我们再看另外一个比较有特色的功能：游戏模式。
游戏模式
游戏模式是为了解决 Web 游戏性能偏低的痛点。通过我们的调研发现，目前大部分的游戏引擎，都是使用 Canvas 进行游戏画面的渲染，如果可以提升 Canvas 的渲染效率，整个游戏的性能就可以大幅度提升。因此我们开发了一个游戏模式，让 Canvas 的内容可以通过一个精简的渲染流水线，直接输出到一个独立的 SurfaceView 上面，然后再将 Surface 的内容与
WebView 内容进行合成，形成最终的画面输出到屏幕，这样就可以大幅提升游戏的性能。除了高性能和省电之外，我们的游戏模式适配成本也非常低，只需要业务开发者通过 JS API 设置一个标志位就可以开启，无需修改到游戏引擎。
从实验室的测试数据可以看到，我们的游戏模式的帧率和耗电都是处于一个非常优秀的水平，即兼顾了性能又兼顾了功耗。
直接光栅化&直接合成
游戏模式只是提升了特定场景下的渲染性能，对于通用场景的渲染性能，我们有没有什么办法可以优化呢？
在解答这个问题之前，我们先简单了解一下 Chrome 的渲染架构。这个图对渲染流水线做了一个非常简化的抽象，一个网页从文本的形态，最终输出到屏幕被用户看到，主要经历3个阶段：
Blink 对页面内容做解析，排版、绘制，生成一系列绘制指令，输出到子合成器 Layer Compositor；
Layer Compositor 再将 Layer 进行分块、光栅化和纹理上传，生成 Compositor Frame 输出到它的父合成器 Display Compositor；
最后再由 Display Compositor 将 Compositor Frame 翻译成GL绘制命令，将内容绘制到 Window 对应的 Surface，显示到屏幕上面。
由于 Chrome 除了需要渲染网页内容，它还需要渲染 UI 界面，或者是支持像 offscreen canvas 这样的特性，所以它有多个子合成器，跑在不同的进程里面，例如这里的 UI Compositor。
为了提升网页的渲染性能，以及减少渲染过程的内存消耗，我们对 Chromium 渲染流水线做了大改造，实现了直接光栅化和直接合成。这里主要做了 2 件事情：
我们去掉了Layer Compositor之外的子合成器，简化了合成器架构；
去掉了分块的逻辑，将网页的内容直接光栅化到一个surface上面，这样可以节省分块缓存带来的内存消耗，效率也会更高。
改造后的渲染架构如这幅图所示，我们去掉了不需要的子合成器，去掉了分块逻辑，然后将 Display Compositor 放到了 Render 进程，实现了直接光栅化和直接合成。我们的直接光栅化和直接合成，带来了很多的好处。
第一是节省了GPU内存的消耗，降低了15%+；
第二对于Motion Mark动画及首屏渲染性能，也有了明显的提升。
但是直接光栅化也存在一些问题，由于没有分块缓存，在一些低端机或者特别复杂的场景，页面惯性滚动帧率有轻微下降。为了解决这个问题，我们实现了混合光栅化方案，可以根据业务场景复杂度，内核自动切换异步光栅化或者直接光栅化，更好地兼顾了帧率跟内存。
V8 JS引擎优化
除了渲染引擎的优化，我们还对 V8 JS 引擎做了很多优化，这里列举 3 点比较重要的优化：
我们实现了自己的 V8 code cache，相对官方版本，提升了 code cache 的覆盖面，使得 JS 性能提升了 22%；
我们利用 LLVM 改造了 V8 代码生成后端，使得 JS 整体性能提升 20% 以上；
为了方便集团业务方接入 JS 引擎，我们标准化了 JS 引擎接口，做了一个 JSI SDK 封装，使得 JS 引擎集成效率大幅提升。
U4 配套开发平台
除了引擎层面的优化，我们也在不断完善配套平台与工具，针对开发中、开发后以及线上后 3 个关键节点，做了全流程的工具支持，分别提供了 UC 开发者工具、鲁班尺以及 Web 高可用监控平台，帮助开发者更好地开发出高质量的 Web 应用。
UC 开发者工具是基于 Chrome Remote Inspector 定制优化的开发者工具。我们将 remote inspector 做成了独立桌面应用，除了修正了原生的一些调试问题，我们还增加了特有的调试功能，使得开发者可以通过 UC DevTools 更好地调试我们的 U4 内核；
鲁班尺是及我们基于 Chrome LightHouse 打造的线下自动化诊断平台，可以对开发后的应用做自动化诊断分析，得出评分和优化建议，帮助开发者发现页面问题，协助进行页面优化，非常适合作为发布卡口测试工具；
Web 高可用监控平台是我们与内部 iTrace 平台合作打造的线上问题监控诊断平台。目前类似的 APM 平台非常多，但是我们的 Web 高可用监控平台与内核深度结合，使得监控面更广、数据更加准确，实现了很多有特色的监控项，例如白屏监控。出现问题的时候，我们可以关联加载瀑布流数据、JS
错误信息等，提供有效的数据供开发者分析问题。除了白屏监控，我们还有黑屏监控、内存监控、JS 异常等，有效地帮助业务发现和解决了多个线上重大问题。为了更好地服务 Web 开发者，我们的 Web 高可用监控平台，目前也包装成对外的产品，叫“岳鹰”，大家有兴趣可以了解和接入使用。
未来展望
刚才也说到，浏览器内核已经从传统的浏览器内核，逐步演变为 Web Platform，应用到更多的业务场景。在未来，我认为它将继续往 App Platform 去演进。那么 Web Platform 跟 App Platform 有什么区别呢？
Web Platform 主要是强调它应用的广度，App Platform 除了要有更广的应用，它的体验也要达到可以媲美 native 的水平，无论是在性能体验还是在开发体验。
为了实现打造一个 App Platform 的目标，浏览器内核还需要不断地去做优化，包括架构的优化、性能的优化以及更多新标准的支持，从而去增强 Web 应用的性能体验；另外从开发者的角度，也需要不断去完善开发者工具和平台，开放更多浏览器内核的数据和设备的能力，使得开发者可以更高效地开发出一个高质量的 Web 应用。
我们相信，Web 将是移动互联网领域最重要的技术之一，我们也会持续投入，打造一个更好的 App Platform，我们的目标是 让 Web 无所不能！
以上就是我的分享，谢谢。
U4 内核致力于打造性能最好、最安全的 web 平台，让 web 无所不能。
关注公众号请搜索 U4内核技术，即时获取最新的技术动态
}