GaiaX（盖亚），是在阿里文娱内广泛使用的 Native 动态化方案，其核心优势是性能、稳定和易用。本系列文章《GaiaX 开源解读》，带大家看看过去三年 GaiaX 的发展过程。
GaiaX 的布局方案 - Flexbox
阿里文娱业务作为一个内容分发、消费综合体，不仅覆盖 Phone 端，在 Pad、OTT、Mac、车机、IOT 带屏设备上都为广大用户提供在线视频媒体服务。GaiaX 作为文娱分发场景的一个重要端渲染解决方案，在进行布局技术方案设计时，必须充分考虑多端、多屏的响应式布局诉求。众所周知，浏览器场景很好的解决了屏幕窗口多尺寸的动态布局问题，其采用的布局方案即为 Flexbox。
移动端原生 Frame 布局是 Native 方案的最优解，因为双端可最大限度的发挥 OS 的渲染特性来保证渲染性能。为了验证 Flexbox 的实测性能，我们针对单层及多层嵌套设计了测试用例，通过数据表现（耗时单位为 ms）来进一步证明 Flexbox 方案是否可以作为 GaiaX 的布局方案。
实验结果的产出，完全打消了我们对 Flexbox 在性能上的顾虑，再加之其符合 W3C 规范、社区丰富、学习复杂度低等优势，最终团队选择 Flexbox 作为 GaiaX 的布局技术方案。
Flexbox 高性能解析方案 - Stretch
为什么选择 Stretch 作为布局基础
在确定了布局方案后，接下来要做的事就是确定解析的技术选型。 社区支持 Flexbox 布局解析的技术方案，最为大家耳熟能详的是 facebook 推出的 yoga，这也是业内的主流技术选型。相对于 yoga 来说，Strectch 具有以下的优势：
● 包大小体积● 支持多线程的局部计算● 支持跨平台的能力（iOS、Andriod、JS 等）● 基于 rust 语言实现，具备高性能，低内存占用等特性
Stretch 的这些的优势是基于 Rust 语言特性所带来的：更安全的内存管理：与 C/C++ 语言相比，使用 Rust 语言来进行程序设计可以有助于从源头预防出现诸如空指针，缓存溢出和内存泄漏的内存问题。更好的运行性能：与 Java/C# 等语言相比，Rust 语言的内存管理不是依靠垃圾回收器机制（ GC ）来实现的。这个设计提高了程序运行的性能。原生支持多线程开发：Rust 语言的所有权机制和内存安全的特性为没有数据竞争的并发提供了语言层面上的原生支持。
网上已经有了很多关于 Rust 性能分析对比的文章，以下就是性能对比结果，性能上可以跟 C++性能不相上下，某些场景下效率甚至优于 C++。
Rust vs C++:
Stretch 入门
由于 Stretch 是采用 Flexbox 布局的方式，在开始介绍 Stretch 核心布局计算逻辑之前，还需要简单了解一下 Flexbox 的基础概念● 采用 Flex 布局的元素，称为 Flex 容器（flex container），简称"容器"。它的所有子元素自动成为容器成员，称为 Flex 项目（flex item）。● 容器默认存在两根轴：○ 水平的主轴（main axis）：主轴的开始位置（与边框的交叉点）叫做 main start，结束位置叫做 main end；○ 垂直的交叉轴（cross axis）：交叉轴的开始位置叫做 cross start，结束位置叫做 cross end。● 项目默认沿主轴排列。单个项目占据的主轴空间叫做 main size，占据的交叉轴空间叫做 cross size。Flexbox 解析布局逻辑流程，实际上就是处理 Flex 容器和 Flex 项目的尺寸、排列方向、对齐方式、比例关系、绝对布局项目的代码逻辑。
Stretch 实现原理
Flexbox 布局解析主链路
核心算法
Stretch 重点剖析
在 Stretch 整个布局算法中，有 9 个主要的环节，接下来我们重点介绍三个重要的环节，● 确定 Flex 项目的基准值（flex_basis）● Flex 项目的主轴尺寸● Flex 项目的交叉轴尺寸
确定 Flex 项目的基准值（flex_basis）
在该阶段，会生成 Flex 项目集合用作逻辑处理，随后会遍历该集合，给每个 Flex 项目的 flex_basis 赋值，Flex 项目有了初始值之后会便于后续主轴和交叉轴的处理。每个 Flex 项目的 flex_basis 的值，主要受到以下几个方面影响：● 如果 flex_basis 已经有值，则直接使用。● 如果 align-items 被设置 stretch，那么 flex 项目的高度会默认被拉伸到最大元素的高度。● 如果有设置 aspect-ratio 值，那么需要根据宽度计算出高度赋给 flex_basis，或者根据高度计算出宽度赋给 flex_basis。
确定 Flex 项目的主轴尺寸
当有了 flex_basis 之后，需要进一步确定 flex 项目主轴尺寸 - target_main_size。首先要确认当前 flex 容器中已经使用的空间，以及当前 Flex 容器中剩余的空间，然后根据 Flex 项目的 Flex 因子来收缩和扩展 Flex 项目的主轴尺寸。所谓 Flex 因子就是 flex_grow 和 flex_shrink。如果使用 flex_grow，需要计算 Flex 项目的增长比例系数，并结合剩余空间计算出 Flex 项目的增长值，加上 Flex 项目的基准值，作为 Flex 项目的主轴尺寸。Flex 项目的增长长度与 flex_grow 数值成正比关系。
if growing { for target in &mut unfrozen { let child: &mut FlexItem = target; if free_space.is_normal() && sum_flex_grow > 0.0 { let grow_after = child.flex_basis + free_space * (self.nodes[child.node].style.flex_grow / sum_flex_grow); child.target_size.set_main(dir, grow_after); } }}
复制代码
如果使用 flex_shrink，需要计算 Flex 项目的收缩比例系数，并结合剩余空间计算出 Flex 项目的收缩值，加上 Flex 项目的基准值，作为 Flex 项目的主轴尺寸。Flex 项目收缩的长度与 flex_shrink 成正比关系。
if shrinking && sum_flex_shrink > 0.0 { let sum_scaled_shrink_factor: f32 = unfrozen .iter() .map(|child: &&mut FlexItem| { let child_style: Style = self.nodes[child.node].style; child.inner_flex_basis * child_style.flex_shrink }) .sum(); for target in &mut unfrozen { let child: &mut FlexItem = target; let scaled_shrink_factor = child.inner_flex_basis * self.nodes[child.node].style.flex_shrink; if free_space.is_normal() && sum_scaled_shrink_factor > 0.0 { let shrink_after = child.flex_basis + free_space * (scaled_shrink_factor / sum_scaled_shrink_factor); child.target_size.set_main(dir, shrink_after) } }}
复制代码
确定 Flex 项目的交叉轴尺寸
交叉轴的尺寸比较复杂一些，其中涉及到三个子环节：● 确定每个 Flex 项目的猜测的交叉轴尺寸。● 确定每行下的 Flex 项目交叉轴尺寸最大的高度。● 根据行的交叉轴高度以及 aspect-ratio、align-self: stretch 等参数，计算出每个 Flex 项目交叉轴的实际宽度。
出现哪些问题，增加哪些新特性
当前 Stretch 也并非完美的，我们在使用的过程中遇到不少问题● iOS 的 symbol 覆盖问题导致 crash● Andriod 端 GC 回收 crash● 多线程布局计算 crash 问题● apsect-ratio 属性重定义● Flex 多层嵌套规则下存在隐藏的问题 （flex-shrink/flex-grow）接下来就针对其中几个问题进行剖析，并给出我们对 Stretch 的改动方案。
iOS 在 32 位机器上 Crash 问题
原因分析
Stretch 库是通过 Rust 实现，并通过 cargo 将 Rust 的运行时和 stretch 跨平台编译 iOS armv7，arm64 等平台的静态库集成到 GaiaX 的项目中，但是我们在测试的过程中发现在 armv7 以及 armv7s（32 位机器）上出现了 crash，crash 在 _modsi3 macros.rs:255 ，经过分析 Rust 运行时代码，这个宏是模运算的功能，在编译 stretch 静态库的时候，会将 Rust 运行时一起打包编译，并将需要的宏展开，覆盖 iOS 动态链接 _modesi3 运算导致异常。
我们查看 rust 的底层库 a%b_modesi3 实现，发现在 a%b，在 b 为空的情况下是种未定义的行为，会导致 program panics 行为，在 iOS 系统表现为 crash 行为。
#[maybe_use_optimized_c_shim]pub extern "C" fn __modsi3(a: i32, b: i32) -> i32 { a.mod_(b)}
trait Mod: Int { /// Returns `a % b` fn mod_(self, other: Self) -> Self { let s = other >> (Self::BITS - 1); // NOTE(wrapping_sub) see comment in the `div` let b = (other ^ s).wrapping_sub(s); let s = self >> (Self::BITS - 1); let a = (self ^ s).wrapping_sub(s); let r = a.unsigned().aborting_rem(b.unsigned()); (Self::from_unsigned(r) ^ s) - s }}
fn aborting_rem(self, other: Self) -> Self { unwrap(<Self>::checked_rem(self, other))}
// 在a或b为none时，unwrap的值为none时会导致program panics，在iOS系统出现crash问题。
复制代码
解决方案
我们将 Stretch 打包生成的静态.a 库，并通过工具将 modis3 的 symbol 进行重命名，然后集成到 GaiaX 库中，在生成的 link map 文件中可以发现重命名的几个 symbol 和 iOS 动态库中的 modis3 符号都已经能够正常 link，。
同时我们也进行大量的机型测试，以及针对性 case 的单元测试来保证其稳定性。
aspect-ratio 问题的修复
aspect-ratio 属性是在 CSS 中用来保持纵横比(width/height 的比率)。
原因分析
Stretch 库的设计是以交叉轴为基准进行处理该属性的，并将其作为 flex_basis 使用，这就导致了如果想要正确的使用这个属性必须做到一下两点：● flex item 必须嵌套在 flex container 中来进行使用。● aspect-ratio 的数值，在 container 的排列方向是竖向时，须写成高宽比；在 container 的排列方向是横向时，须写成宽高比。
随着使用 aspect-ratio 的地方越来越多，我们发现这种需要依赖于 container 的排列方向的计算方式给模板搭建的使用者带来了困惑，同时也降低开发的效率。
解决方案
首先我们对 aspect-ratio 重新的定义，让其变的更加通俗易懂，根据双端讨论约定的如下规则：● aspect-ratio 代表宽高比（width / height）。● 当 flex-item 有确定的宽度时， aspect-ratio 需要以宽度计算出高度。● 当 flex-height 有确定的高度时， aspect-ratio 需要以高度计算出宽度。● aspect-ratio 不再受 flex container 排列方向的影响。由于前期对 Rust 语法不够熟悉，再加上 Flexbox 布局解析逻辑非常复杂，整个工作的难度还是非常高的。采取的策略就是每修改一处逻辑必须通过单元测试保证不会影响到现有逻辑，每增加一处代码都增加相应的测试用例来保证可靠性。
主要针对 Flex 项目初始宽度赋值、主轴计算、交叉轴计算时进行拆解处理，适配 aspec-ratio 的逻辑。例如，在初始宽度赋值时，根据 Flex 项目宽度、高度以及宽高比进行计算赋值：
// fix: aspect_ratio_both_dimensions_defined_columnfn get_aspect_ratio_size(child_style: &Style, target_size: Size<Number>) -> Size<Number> { return Size { width: Forest::get_aspect_ratio_width(child_style, target_size), height: Forest::get_aspect_ratio_height(child_style, target_size), };}
// fix: aspect_ratio_both_dimensions_defined_columnfn get_aspect_ratio_height(child_style: &Style, target_size: Size<Number>) -> Number { // 若有定义宽度，且存在比例关系，那么使用高度计算宽度 if target_size.width.is_defined() && child_style.aspect_ratio.is_defined() { let width = target_size.width.or_else(0.0); let aspect_ratio = child_style.aspect_ratio.or_else(0.0); return Number::Defined(width / aspect_ratio); } return target_size.height;}
fn get_aspect_ratio_width(child_style: &Style, target_size: Size<Number>) -> Number { // 若没有定义宽度，并且有定义高度，且存在比例关系，那么使用高度计算宽度 if !target_size.width.is_defined() && target_size.height.is_defined() && child_style.aspect_ratio.is_defined() { let height = target_size.height.or_else(0.0); let aspect_ratio = child_style.aspect_ratio.or_else(0.0); return Number::Defined(height * aspect_ratio); } return target_size.width;}
复制代码
另外在计算交叉轴尺寸时，同时也需要考虑到很多属性之间（stretch、aspect-ratio、flex-basis、flex-grow、flex-shrink）的关联关系等，争取将影响降到最低。
if is_row && child_style.aspect_ratio.is_defined() && node_size.height.is_defined() && child_style.flex_shrink > 0.0 { let final_cross = child.hypothetical_inner_size.cross(dir).maybe_min(node_size.height); if !child_style.size.width.is_defined() && !child_style.min_size.width.is_defined() && !child_style.max_size.width.is_defined() { // fix: aspect_ratio_height_as_flex_basis // fix: aspect_ratio_flex_shrink let desire_height = child.target_size.width / child_style.aspect_ratio.or_else(0.0); desire_height } else if !child_style.size.width.is_defined() && child_style.min_size.width.is_defined() && !child_style.max_size.width.is_defined() { // fix: aspect_ratio_flex_shrink_2 let desire_height = child.target_size.width / child_style.aspect_ratio.or_else(0.0); final_cross.maybe_min(Number::Defined(desire_height)) } else if child_style.size.width.is_defined() { // fix: aspect_ratio_width_height_flex_grow_row let desire_height = child.target_size.width / child_style.aspect_ratio.or_else(0.0); desire_height } else { final_cross }} else { let final_cross = child.hypothetical_inner_size.cross(dir); final_cross}
复制代码
线程问题
原因分析
由于 Stretch 库的实现是非线程安全的。Nodes 和 Forest 都是通过 Map 以及 Array 进行存储，在多线程情况下动态构建 Forest，以及创建和移除子 Node 节点时候极易出现数据访问安全的问题导致 crash。
//stretch初始化pub fn with_capacity(capacity: usize) -> Self { Self { id: INSTANCE_ALLOCATOR.allocate(), nodes: id::Allocator::new(), nodes_to_ids: crate::sys::new_map_with_capacity(capacity), ids_to_nodes: crate::sys::new_map_with_capacity(capacity), forest: Forest::with_capacity(capacity), }}
//添加子节点pub fn add_child(&mut self, node: Node, child: Node) -> Result<(), Error> { let node_id = self.find_node(node)?; let child_id = self.find_node(child)?;
self.forest.add_child(node_id, child_id); Ok(())}
//移除子节点pub fn remove_child(&mut self, node: Node, child: Node) -> Result<Node, Error> { let node_id = self.find_node(node)?; let child_id = self.find_node(child)?;
let prev_id = unsafe { self.forest.remove_child(node_id, child_id) }; Ok(self.ids_to_nodes[&prev_id])}
复制代码
解决方案
为了避免修改 Stretch 带来其他未知的影响，双端在 Stretch 上层进行单例化，并对所有的节点操作进行加锁访问，以及动态更新 Style 指针的安全访问。
// GXStretch+ (instancetype)stretch{ static GXStretch *stretch = nil; static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ if (nil == stretch) { stretch = [[GXStretch alloc] init]; } }); return stretch;}
//添加child- (void)addChild:(void *)child forNode:(void *)node{ dispatch_semaphore_wait(_semaphore, DISPATCH_TIME_FOREVER); stretch_node_add_child(_stretchptr, node, child); dispatch_semaphore_signal(_semaphore);} //更新rust指针- (void)updateRustPtr{ //先释放原有指针 if ([self isValidPtr:_rustptr]) { _prevRustptr = _rustptr; } //再生成新的指针 _rustptr = stretch_style_create(...);}
//释放上次的rust指针- (void)freePrevRustptr{ if ([self isValidPtr:_prevRustptr]) { stretch_style_free(_prevRustptr); _prevRustptr = NULL; }}
复制代码
问题验证
在对于 Stretch 增加新特性的同时，为了保证代码安全性和可靠性，我们增加了大量的测试用例，覆盖绝大多数的场景对修改点的验证。例如，在交叉轴确定的情况下，来验证通过 apsect-ratio 来计算布局：
#[test]fn aspect_ratio_cross_defined() { let mut stretch = Stretch::new();
let root = stretch.new_node(Style { size: Size { width: Dimension::Points(100.0), height: Dimension::Points(100.0) }, ..Default::default() }, &[]).unwrap();
let root_child0 = stretch.new_node(Style { size: Size { width: Dimension::Points(50.0), ..Default::default() }, aspect_ratio: Number::Defined(1.0), ..Default::default() }, &[]).unwrap();
stretch.add_child(root, root_child0).unwrap();
stretch.compute_layout(root, Size { width: Number::Defined(375.0), height: Number::Defined(1000.0) }).unwrap();
assert_eq!(stretch.layout(root_child0).unwrap().size.width, 50.0); assert_eq!(stretch.layout(root_child0).unwrap().size.height, 50.0);}
复制代码
得益于 Rust 语言的安全性，以及敏捷单元测试和丰富的类型系统和所有权模型，在编译期就能够消除各种各样的错误，也避免了因为不熟悉语法而导致编写错误，在此基础上，能够顺利跑通所有测试用例的代码就能保证在使用期间的可靠性。
总结与展望
Stretch 开源项目原开发团队已不在维护，为了保证 GaiaX 项目的迭代诉求，团队不但 fork 了源码，并自研新增了大量新特性。 在这个过程中，我们不仅对 Stretch 库有了全面的了解，也同时深入到 RUST 语言中，这个过程既痛苦又享受，相信广大开发同学在编程职业生涯中，也有过类似的经历。随着 GaiaX 在阿里文娱业务及开源社区越来越多的应用，双端需要支持的容器及技术能力与诉求也越来越多，仅凭借 GaiaX 团队一己之力，很难快速响应社区开发者及文娱业务本身的双线需求。因此，团队希望通过开源的方式，让更多的开发者参与进来，借助社区力量，让更多有跨端动态化技术诉求的个人和团体在技术上受益。
团队介绍
我们来自 优酷产品技术与创新中心应用技术部 ，从日常工作中真实存在的研发效能及痛点问题出发，我们自研推出了 GaiaX 动态模板技术体系，目标是解决多端卡片化 UI 组件的研发效能问题，帮助提升开发者体验及效率。目前 GaiaX 项目已经在 GitHub 开源 【https://github.com/alibaba/GaiaX】 ，也殷切的希望广大移动端及前端技术爱好者与我们进行技术交流与共建。
系列文章
《GaiaX 开源解读》系列文章预告如下，欢迎持续关注：第一篇：《GaiaX开源解读 | 基于优酷业务特色的跨平台技术》第二篇：《GaiaX开源解读 | 跨端动态化模板引擎详解，看完你也能写一个》第三篇：《GaiaX 开源解读 | 给 Stretch（Rust 编写的 Flexbox 布局引擎）新增特性，我掉了好多头发》第四篇：《GaiaX 开源解读 | 表达式作为逻辑动态化的基础，我们是如何设计的》第五篇：《GaiaX 开源解读 | 向经典致敬 ReactNaitve 与 GaiaX 渲染核心技术分析》第六篇：《GaiaX 开源解读 | 为了保障双端一致性，我们做了哪些努力》第七篇：《GaiaX 开源解读 | 一条龙的模板研发体系，你不来看看么》
评论