字节跳动小程序混合渲染架构

如果无法正常显示,请先停止浏览器的去广告插件。
分享至:
1. 字节跳动小程序混合渲染架构 的思考与探索 董岩 字节跳动小程序渲染引擎技术负责人
2. • Content Title 1
3. • 来自字节跳动小程序渲染引擎团队 • 曾就职于阿里淘宝、Intel 等公司 • 在移动端跨平台技术、小程序、Flutter 及浏览器内核 等方向上有过深入研究 • 热爱开源,曾为 WebKit Committer 及 Weex IPMC Member
4. • 小程序技术的背景及演进历程 • 字节跳动小程序面临的挑战与思考 • 混合渲染架构的建设实践 • 未来的工作与展望
5.  小程序技术背景及演进历程
6.  跨端技术演进历程
7.  跨端技术演进历程 浏览器渲染 原生 UI 渲染 自绘渲染 • Platform 层渲染抽象 • 渲染指令 -> 系统 UI • 直接基于 Skia,渲染管线短 • Multi-Pass Layout • 原生化布局 • Single-Pass Layout • 静态 DOM API • Native Component • Repaint & Relayout Boundary • CSS 全集支持 • DSL • Reactive 框架
8.  小程序的成功与困境 小程序技术上的瓶颈 小程序业务上的成功 小程序的行业实现方案趋同,渲染层实现长 期依赖浏览器,享受技术红利的同时也带来 了许多掣肘问题: • 性能持续提升诉求与浏览器沙盒限制的矛 盾(通信瓶颈、全链路加载、渲染与内存 优化) +33.2% +27.3% • DSL 强约束与 CSS 能力无法收敛的矛盾 • 业务场景多元化诉求日益强烈(多端多平 台,卡片)与技术实现手段单一的矛盾 数据来源:QuestMobile TRUTH 中国移动互联网数据库
9.  字节跳动小程序面临的挑战与思考
10.  字节跳动小程序发展现状简介 愿景与使命 重点垂类 • • • • • 本地餐饮 娱乐电影 泛知识 汽车 …… 技术生态 成为优质内容和服务开发者的首选平台 作为更好的“看见并连接”的承载,长期提升抖音对用户的价值 行业合作 • 行业头部 开发者 • 行业 SaaS 解决方案 场景 • • • • • 视频锚点 直播 同城 POI 搜索 …… 中台能力 • • • • 内部宿主支持 SaaS 赋能 内部业务联动分发 重点活动支持 开发者平台,SDK 能力支持,分发支持,生态安全 & 质量管控 +15.1% +669%
11.  业务场景的新趋势 • 视频场景下,如何为小程序提供 多样化的集成入口,更便捷的通 过锚点导流? • 直播、电商场景下,如何复用已 有的业务定制化组件能力,快速 构建业务应用形态? • 应用场景特点日益分化,页面结 构与 CSS 能力要求的差异带来了 技术优化空间
12.  对小程序技术迭代的新要求 卡片 入口 页面 原生化 性能 • 入口卡片隶属小程序 • 原生组件能力复用 • CSS 能力子集 • X 分屏 • 组件标准化 • DSL 约束带来的渲染 • Feeds 流嵌入 • 快速页面搭建 • 多卡片 层内部实现简化的机遇 要满足这些新要求,我们该采用什么样的思路?
13.  多元化场景下的小程序架构思路 Q:如果把小程序定义为一个面向业务域的解决方案,那么: 使用单一渲染技术 通过能力拓展或收敛 来抹平不同场景需求差异 (WebView+同层渲染;WebView 裁剪; 原生渲染能力拓展) vs 包装差异化渲染技术 来分别满足不同场景需求 (混合渲染,不同页面采用不同渲染方案) 哪种思路能更好的解决小程序的场景多元化问题? 我们的答案:让合适的渲染层技术服务适合的业务场景
14.  混合渲染架构的建设实践
15.  小程序混合渲染架构设计 核心思路 • 在小程序框架下容纳异构渲染引擎 关键问题 • 异构渲染引擎接入小程序,打通 JS Context,支持不同渲染引擎渲染不同页面 • 统一容器接入层,统一 API 注入、页面调 度、包管理等基础能力 • 统一前端框架,抹平不同渲染引擎的生命周 期、回调等差异
16.  为什么要引入原生渲染? 意义 • 相对 Web 性能的巨大提升 • 原生组件能力复用 & 标准化 • 易于嵌入原生 UI,适合承载多卡片场景 Lynx:字节跳动的高性能原生渲染引擎
17.  原生 UI 接入混合渲染框架改造 第一步:将原生渲染引擎接入小程序,实现部分页面支持原生化渲染 主要工作 • LynxView 改造,JS Context 通过外部注入 • 小程序编译产物适配 Lynx 页,支持按配置加载 • 抹平生命周期差异,小程序加载逻辑优化 小程序业务代码 JS Framework 容器基础能力(API / Nav / 线程) 关键问题与挑战 • 混合模式下 Lynx JS Context 实例、启动顺序管理 • 对于小程序开发者,如何抹平页面写法和 CSS 能力差异 • DevTool 如何满足外部开发者的调试需求 Shared JS Runtime WebView LynxView
18.  原生渲染是不是银弹? Q:能不能用原生渲染完全替换 Web? NO 劣势 • 使用原生 UI 实现渲染层,必然导致 CSS 能力支持受限(z-index,圆角/阴影,不 规则 clip…) • 写法与默认值与 W3C 标准有区别 • 难以完全抹平双端渲染差异 本质区别在于: 原生渲染重性能,适合服务内部; 小程序服务外部开发者生态,重标准 Q:能不能利用 Flutter 特性弥补原生渲染的短板? 试试看
19.  自绘 UI 渲染引擎 - Flutter 第二步:基于 Flutter widgets 实现小程序渲染层,接入混合渲染模式 方案特点 TTML / TTSS / JS • 使用 Widgets 组合来表达前端 DSL 和 CSS 能力 • 继承了 Flutter 的高性能、跨端一致性好的特点 Virtual • 充分利用了 Flutter 的现有组件生态 Node 主要工作 Template CSS Rules JS SDK StyleSheet JS Runtime Flutter Widgets Elements • 引入 JS 执行环境,支持 Context 注入 • 使用 Dart 实现了响应式框架与 CSS 解析器 • 结构 + CSS Computed Styles -> Flutter Widgets Render Objects Flutter Engine Facilities
20.  自绘 UI 渲染引擎 – 应用 业务应用 • • 飞书应用目录使用小程序 Flutter 原生渲染引擎 CSS 能力支持相对原生渲染提升较大;性能相对 Web 提升有限 问题 • Flutter 基于 Constraints 设计的简化 布局能力,无法完全支持前端需求,需 重新实现 Render Object • CSS 属性的数据绑定更新会带来渲染 树频繁重构,无法完全发挥 widgets 设计优势 • 链路长,JS -> C++ -> Dart -> C++ • 包大小 Q:能否完全使用 C++ 实现一个服务小程序的自绘渲染引擎? 试试看
21.  自绘 UI 渲染引擎 – C++ 第三步:移除 Dart,基于 Flutter Engine 实现 C++ 版渲染引擎 方案特点 • 上层结构(响应式框架、DOM)贴近浏览器设计 • 完全基于小程序能力对 CSS 特性做了限制和简化 • 移除 Dart VM,包大小 & 性能收益 TTML / TTSS / JS JS Framework Template vDOM Diff Runtime DOM 主要工作 JS Oryx Render Objects • 响应式框架下沉至 C++ 层实现 • 精简 DOM、CSS 能力,完全贴合小程序 DSL Painting • Render Objects 在 C++ 层实现,直接对接 Flutter 渲染管线 Layering Animation Events Skia Gestures
22.  自绘 UI 渲染引擎 – C++ C++自绘渲染 原生渲染 Web
23.  自绘 UI 渲染引擎 – C++ 优势 劣势 渲染性能 First Build • • • • 性能 跨端一致性 CSS 支持 多端能力 • 包大小 • 长期维护成本 SetData触发 PageUpdate Tab 切换触发 PageUpdate Reactor Layout Paint Composite iPhone12 1ms 0ms 0ms 0ms Android 中端机 2ms 16ms 0ms 0ms iPhone12 15ms 30ms 0ms 0ms Android 中端机 60ms 110ms 1ms 0ms iPhone12 40ms 5ms 0ms 0ms Android 中端机 50ms 40ms 2ms 0ms 产物大小: Android:3.6M iOS:5.5M(单架构) Q:能否通过裁剪浏览器或拓展原生渲染能力满足目标? 在小程序 DSL 限制下,填补原生渲染和浏览器之间能力与性能洼地, 自绘渲染引擎目前看是最合适的方案 Q:自绘渲染引擎和原生渲染引擎的关系?能否相互替换? 应该其在各自适合的业务场景下发挥作用
24.  小程序前端标准子集 Q:如何在混合渲染框架下统一不同的渲染引擎? 建立小程序标准 CSS 子集 CSS 子集的制定原则: • W3C 标准完全兼容 Web 兼容 自绘模式 常规业务场景 原生模式 重点业务场景 W3C标准规范 • 性能优先 • 保障实现一致性 • 控制实现成本 Web 严格标准子集 高性能 标准子集 能力: • 23 个基础组件(一期) • 盒模型、定位、布局、动画等 100+ CSS 属性 • 支持选择器、组合器、伪类伪元素、继承优先级等 目标: • 编译期检查,渲染引擎无感替换 • 严格标准子集承载 80% 以上的小程序业务
25.  未来的工作与展望
26.  AI / AR 与多端 多端能力 • 泛 IoT 类场景接入(教育、线下) • 通过自绘 UI 实现理想的跨平台一致性 AI / AR能力 • 电商、直播类相关场景的强互动需求 • 3D 自绘能力与基于 GL API 的端推理 能力与算法接入
27.  小程序标准化 核心价值 • 围绕行业标准打造小程序生态 • 降低开发者开发门槛 • 技术打通带来新流量 主要工作 • 标准制定的工作组讨论 • 推动 CSS 子集能力标准化 Working Group Community Group • Lifecycle • Addressing • Manifest • Widget • Packaging
28. 技 尽 其 用  性能的极致追求  标准的持续完善
29.
30. • Content Title 1
31.  关注我们 字节跳动小程序团队招聘! (前端、客户端、服务端、引擎…) 简历请惠赐: dongyan.jonathan@bytedance.com 抖音开放平台

trang chủ - Wiki
Copyright © 2011-2024 iteam. Current version is 2.132.1. UTC+08:00, 2024-09-23 19:14
浙ICP备14020137号-1 $bản đồ khách truy cập$