解析 React Native 的“重排”痛点：Yoga 布局引擎是如何在 C++ 层模拟 Flexbox 的？

解析 React Native 的“重排”痛点：Yoga 布局引擎是如何在 C++ 层模拟 Flexbox 的？

各位技术同仁，大家好！

今天，我们将深入探讨 React Native 应用开发中一个核心但又常被忽视的性能瓶颈——“重排”（re-layout），以及 Facebook 开源的 Yoga 布局引擎如何通过在 C++ 层高效模拟 Flexbox，来缓解这一痛点。作为一名前端开发者，我们习惯了 CSS Flexbox 的便利和强大。但当我们将视线转向跨平台移动开发，尤其是 React Native 时，理解这一布局模型如何在底层被实现，以及它如何影响应用性能，变得至关重要。

一、引言：React Native 布局的挑战与“重排”痛点

React Native 的诞生，旨在让开发者能够使用熟悉的 JavaScript 和 React 范式，构建真正原生的移动应用。其核心理念是将 React 的声明式 UI 描述转换为原生平台的视图组件。这种转换并非一帆而就，其中最复杂、最关键的一环就是布局。

1. 声明式 UI 的优势与挑战

React 的声明式 UI 允许我们描述 UI 的“样子”，而不是“如何变化”。当组件状态改变时，React 会计算出 UI 的最小更新集，并将其应用到实际的 DOM 或原生视图树上。这种模式极大地提高了开发效率和代码的可维护性。

然而，在移动端，原生 UI 渲染与 JavaScript 线程之间存在一道“鸿沟”——桥接（Bridge）。JavaScript 线程负责运行应用逻辑、处理状态更新、计算布局属性，然后将这些指令通过桥接发送给原生 UI 线程。原生 UI 线程则负责根据这些指令创建、更新、布局和绘制实际的原生视图。

2. 什么是“重排” (Layout Thrashing)？

“重排”或“布局抖动”是指浏览器或渲染引擎在短时间内反复进行布局计算的过程。在 Web 开发中，当我们频繁地读取和写入会影响布局的 CSS 属性时，就可能触发布局抖动，导致页面卡顿。

在 React Native 中，情况更为复杂。布局计算主要发生在 JavaScript 线程，然后将计算结果传递给原生 UI 线程进行实际的视图创建和定位。如果布局计算频繁、复杂，或者布局结果的传递效率低下，就会导致原生 UI 线程无法及时更新，表现为 UI 卡顿、动画不流畅，用户体验大打折扣。

3. React Native 的桥接机制

React Native 架构的核心是其异步桥接。JavaScript 线程和原生 UI 线程是两个独立的执行环境，它们之间通过序列化消息进行通信。

• JavaScript 线程： 运行 React 逻辑、业务代码、处理事件、以及——关键的——计算视图的布局属性。
• 原生 UI 线程： 接收来自 JS 线程的指令，创建、更新原生视图，并在屏幕上绘制它们。

当 React 组件的状态更新导致其样式或内容发生变化时，React Native 会在 JavaScript 线程中执行以下步骤：

1. Reconciliation (协调): 比较新旧虚拟 DOM 树，找出需要更新的组件。
2. Layout Calculation (布局计算): 根据组件的样式属性（例如 flexDirection, width, height 等），计算出每个组件最终在屏幕上的位置和尺寸。这一步是今天的主角——由 Yoga 引擎完成。
3. Serialization (序列化): 将布局计算的结果（如 left, top, width, height）以及其他视图属性（如 backgroundColor, text 等）序列化为 JSON 格式的消息。
4. Bridge Communication (桥接通信): 将序列化后的消息通过异步桥接发送到原生 UI 线程。
5. Native View Updates (原生视图更新): 原生 UI 线程接收消息，解析 JSON，然后调用相应的原生 API 来创建、更新或删除原生视图。

这个过程中，布局计算是 CPU 密集型任务，而桥接通信则是 I/O 密集型任务。如果布局计算本身效率低下，或者计算结果需要频繁地通过桥接传输，都会成为性能瓶颈。

二、Flexbox：现代布局的基石

在深入 Yoga 之前，我们必须先回顾一下它所模拟的对象——Flexbox。Flexbox (Flexible Box Layout Module) 是一种一维布局模型，旨在提供一种更有效的方式来布置、对齐和分配容器中项目（item）的空间，即使它们的大小是未知或动态的。

1. Flexbox 的核心思想：一维布局系统

Flexbox 专注于一维布局，这意味着它一次只处理一个方向的布局：要么是行（row），要么是列（column）。这与 CSS Grid 的二维布局有所不同。

• Flex 容器 (Flex Container): 应用 Flexbox 布局的父元素。它通过设置 display: flex 或 display: inline-flex 来创建。
• Flex 项目 (Flex Item): Flex 容器的直接子元素。

2. Flexbox 主要属性概览

Flexbox 属性可以分为两类：应用于 Flex 容器的属性和应用于 Flex 项目的属性。

应用于 Flex 容器的属性：

属性名称	描述
flex-direction	定义主轴的方向（即 Flex 项目的排列方向）。可选值：row (默认), row-reverse, column, column-reverse。
flex-wrap	定义当 Flex 项目溢出容器时是否换行。可选值：nowrap (默认), wrap, wrap-reverse。
justify-content	定义 Flex 项目在主轴上的对齐方式。可选值：flex-start (默认), flex-end, center, space-between, space-around, space-evenly。
align-items	定义 Flex 项目在交叉轴上的对齐方式（适用于单行）。可选值：stretch (默认), flex-start, flex-end, center, baseline。
align-content	定义多行 Flex 容器中，行与行之间的对齐方式（当 flex-wrap 为 wrap 或 wrap-reverse 且有多行时有效）。可选值：stretch (默认), flex-start, flex-end, center, space-between, space-around, space-evenly。

应用于 Flex 项目的属性：

属性名称	描述
order	定义 Flex 项目的排列顺序。默认值为 0，数值越小越靠前。
flex-grow	定义 Flex 项目在有剩余空间时，是否会增长以及如何增长。默认值为 0 (不增长)。
flex-shrink	定义 Flex 项目在空间不足时，是否会缩小以及如何缩小。默认值为 1 (会缩小)。
flex-basis	定义 Flex 项目在分配剩余空间之前，占据主轴上的初始大小。可以是长度值 (100px) 或百分比 (50%)，或 auto (默认)。
flex	flex-grow, flex-shrink, flex-basis 的简写属性。例如 flex: 1 相当于 flex: 1 1 0%。
align-self	允许单独的 Flex 项目覆盖其父容器的 align-items 属性，定义自己在交叉轴上的对齐方式。可选值与 align-items 相同，加上 auto (默认，继承父级 align-items)。

3. 为什么选择 Flexbox 作为 React Native 的布局模型？

• 与 Web 开发者习惯一致： 大部分 React Native 开发者都有 Web 前端背景，Flexbox 是他们最熟悉的布局模型之一，降低了学习曲线。
• 强大且灵活： Flexbox 能够应对绝大多数复杂的 UI 布局需求，从简单的居中对齐到复杂的响应式网格布局。
• 性能优势： 相较于传统的盒模型（例如 float 或 position）在复杂布局下的计算开销，Flexbox 在设计之初就考虑了性能优化，通常能更高效地完成布局计算。

Flexbox 的这些优点，使其成为 React Native 统一跨平台布局的理想选择。而 Yoga，正是 Flexbox 在 C++ 层面的高效实现。

三、Yoga 布局引擎的诞生与定位

当 Facebook 团队开始构建 React Native 时，他们面临一个关键决策：如何处理不同平台（iOS 的 Auto Layout 和 Android 的布局系统）之间的巨大差异。

1. 为什么不直接使用 WebView 或 Native 布局系统？

• WebView 的性能开销和原生体验差异： 虽然可以将整个 React Native 应用嵌入 WebView 中，但这会带来显著的性能问题，并且无法提供真正的原生 UI 体验和外观。
• 不同平台原生布局系统的差异性与复杂性：
  • iOS 的 Auto Layout： 基于约束的布局系统，强大但学习曲线陡峭，且在运行时可能存在性能开二次计算。
  • Android 的布局系统： 基于 XML 和视图层级，虽然相对直观，但其测量和布局过程也有自己的复杂性。
  • 将 React 的声明式风格映射到这两种截然不同的原生布局系统，将是一个巨大的工程，且难以保持一致的跨平台行为。

为了解决这些问题，Facebook 决定开发一个统一的、高性能、跨平台的布局引擎，它能够理解并执行 Flexbox 布局规则，然后将计算出的最终位置和尺寸传递给原生 UI 线程。这个引擎就是 Yoga。

2. Yoga 的目标：一个高性能、跨平台的 Flexbox 实现

Yoga 的核心设计目标包括：

• C++ 实现： 选择 C++ 是为了极致的性能。布局计算是 CPU 密集型任务，C++ 能够提供对内存和 CPU 的精细控制，确保布局计算尽可能快。
• 平台无关： Yoga 本身不依赖于任何特定的 UI 框架或操作系统。它只是一个纯粹的布局计算库，可以通过 C API 或其他语言绑定集成到任何需要布局计算的环境中，例如 React Native、Android、iOS、甚至 WebAssembly。
• 完整的 Flexbox 标准支持： Yoga 力求实现 W3C Flexbox 规范的绝大部分功能，确保开发者在 React Native 中使用的 Flexbox 属性与 Web 上的行为保持一致。
• 与 React Native 的集成方式： Yoga 被设计为 React Native 架构中的一个关键组成部分。JavaScript 线程将组件的样式属性转换为 Yoga 属性，Yoga 在 C++ 层进行计算，然后将结果返回给 JS 线程，最终通过桥接传递给原生 UI 线程。

Yoga 的出现，统一了 React Native 的布局模型，极大地简化了跨平台 UI 开发的复杂性，并为高性能布局计算奠定了基础。

四、Yoga 如何在 C++ 层模拟 Flexbox：深入解析

现在，让我们深入 Yoga 的内部，看看它如何在 C++ 层实现 Flexbox 布局算法。

A. 数据结构：布局树与节点表示

Yoga 的核心是其内部的布局树，由一系列 YGNode 节点组成。每个 YGNode 实例代表 React Native 组件树中的一个视图或文本节点，存储了该节点的 Flexbox 样式、布局结果以及与其他节点的关系。

1. YGNode 结构体

一个简化的 YGNode 结构体可能包含以下关键信息：

// 简化版的 YGNode 结构体概念
struct YGNode {
    // 树结构关系
    YGNode* parent;
    std::vector<YGNode*> children;

    // 样式属性 (Flexbox 属性)
    YGStyle style;

    // 布局结果 (计算出的位置和尺寸)
    YGLayout layout;

    // 测量函数 (用于文本或自定义组件的尺寸测量)
    YGMeasureFunc measure;

    // 配置 (全局或节点特有)
    YGConfig* config;

    // 脏节点标记 (性能优化)
    bool isDirty;
    bool has       newLayout; // 是否有新的布局结果
    bool hasMeasuredSizes; // 是否测量过尺寸

    // 其他数据，如上下文指针、调试信息等
    void* context;

    // 构造函数、析构函数等
    YGNode();
    ~YGNode();
};

• parent 和 children： 维护了布局树的层级关系。children 通常是一个 std::vector，用于存储子节点的指针。

• YGStyle： 这是一个关键的子结构体，用于存储所有 Flexbox 相关的样式属性。例如 flexDirection, justifyContent, alignItems, flexGrow, flexShrink, flexBasis, width, height, margin, padding, border 等。这些属性通常以枚举类型（如 YGFlexDirection）和数值（如 YGValue，可以表示像素、百分比或 auto）的形式存储。

  // 简化版的 YGStyle 结构体概念
  struct YGStyle {
      YGFlexDirection flexDirection;
      YGJustify justifyContent;
      YGAlign alignItems;
      YGAlign alignSelf;
      YGFlexWrap flexWrap;
      float flexGrow;
      float flexShrink;
      YGValue flexBasis; // 可能是像素、百分比或 auto
  
      YGValue width;
      YGValue height;
      YGValue minWidth;
      YGValue maxWidth;
      YGValue minHeight;
      YGHeight;
  
      YGValue margin[YGEdgeCount]; // YGEdgeLeft, YGEdgeTop, etc.
      YGValue padding[YGEdgeCount];
      YGValue border[YGEdgeCount];
  
      YGPositionType positionType;
      YGValue position[YGEdgeCount];
  
      // ... 更多 Flexbox 属性
  };

• YGLayout： 存储布局计算的最终结果，即节点在父容器中的相对位置和自身的实际尺寸。

  // 简化版的 YGLayout 结构体概念
  struct YGLayout {
      float left;
      float top;
      float width;
      float height;
  
      float margin[YGEdgeCount];
      float padding[YGEdgeCount];
      float border[YGEdgeCount];
  
      // 记录布局方向 (LTR/RTL)
      YGFlexDirection computedFlexDirection;
  
      // ... 其他内部计算状态
  };

• YGMeasureFunc： 这是 Yoga 处理动态内容尺寸的关键。对于文本节点或图片等内容驱动尺寸的组件，Yoga 无法直接从样式中得知其精确尺寸。YGMeasureFunc 是一个函数指针，允许外部系统（如 React Native）提供一个回调，当 Yoga 需要测量特定节点的内容尺寸时，会调用这个函数。例如，React Native 会在 JavaScript 线程中调用 Text 元素的 measure 方法，计算出文本在给定约束下的宽度和高度，然后将结果返回给 Yoga。

  // 测量函数签名 (简化)
  typedef YGSize (*YGMeasureFunc)(YGNodeRef node,
                                  float width,
                                  YGMeasureMode widthMode,
                                  float height,
                                  YGMeasureMode heightMode);

• YGConfig： 存储全局配置，如是否启用调试日志、是否使用 web-flex-basis 行为等。

• isDirty： 这是一个非常重要的优化标志。当一个节点的样式发生变化时，它会被标记为“脏”，表示其布局可能需要重新计算。Yoga 只会重新计算脏节点及其受影响的子节点，从而避免不必要的全局布局计算。

B. 布局算法核心：递归与迭代

Yoga 的布局算法是一个递归过程，它从根节点开始，向下遍历布局树，在每个节点上执行 Flexbox 布局规则，然后将计算结果向上汇总。这个过程通常分为几个主要阶段：

1. 布局计算流程概览

YGLayoutCalculate (或类似名称的函数) 是布局过程的入口。它接收根节点、可用宽度和高度作为输入，并递归地处理整个布局树。

核心思想：

• 自顶向下传递约束： 父节点将自己的可用空间和布局方向等约束信息传递给子节点。
• 自底向上汇总尺寸： 叶子节点（没有子节点的节点）或具有 measure 函数的节点，会根据其内容和约束计算出自己的固有尺寸。这些尺寸再向上汇总到父节点。
• 自顶向下分配位置： 一旦所有节点的尺寸确定，父节点就可以根据 Flexbox 规则（如 justifyContent, alignItems）分配子节点在主轴和交叉轴上的最终位置。

2. Flexbox 算法的关键步骤

Yoga 内部的布局算法是一个高度优化和复杂的实现，但我们可以将其抽象为以下关键步骤：

• 初始化和解析 (Initialization & Resolution):

  • 根据 flex-direction 确定主轴和交叉轴的方向（例如，row 表示主轴是水平的，交叉轴是垂直的）。
  • 解析所有 Flexbox 属性，例如将 flex-basis 的百分比值转换为实际像素值（如果父容器尺寸已知）。
  • 处理 position: absolute：绝对定位的子节点会被从正常的 Flexbox 流中移除，单独进行布局计算。它们的尺寸和位置是相对于最近的定位父元素（position: relative, absolute, fixed）而言的。

• 测量阶段 (Measure Phase):

  • 对于叶子节点或具有 measure 函数的节点（如文本），Yoga 会调用 YGMeasureFunc 来获取其内容的固有尺寸。
  • 对于非叶子节点，如果其 width 或 height 属性是 auto 且没有 flex-grow 或 flex-shrink，它会尝试根据其子节点的尺寸来确定自己的尺寸。

• 主轴尺寸计算 (Main Size Calculation):

  1. 确定初始尺寸：
     • 首先，根据 width/height 或 flex-basis 属性确定每个 Flex 项目在主轴上的初始尺寸。
     • 如果 flex-basis 为 auto，则使用项目的固有内容尺寸（如果已测量）。
  2. 处理 flex-grow (增长):
     • 如果容器在主轴上有剩余空间，且有 Flex 项目设置了 flex-grow，这些剩余空间将按照 flex-grow 的比例分配给这些项目。
     • 例如，两个项目 flex-grow: 1 和 flex-grow: 2 会分别获得剩余空间的 1/3 和 2/3。
  3. 处理 flex-shrink (收缩):
     • 如果容器在主轴上空间不足，且有 Flex 项目设置了 flex-shrink，这些项目将按照 flex-shrink 的比例收缩，以适应容器。收缩的权重通常还考虑了项目的初始尺寸。
  4. 应用 min/max 约束： 任何时候，计算出的尺寸都必须遵守 min-width/max-width/min-height/max-height 的约束。

• 交叉轴尺寸计算 (Cross Size Calculation):

  1. 确定交叉轴可用空间： 如果容器的交叉轴尺寸是固定的，则直接使用。如果是非固定（如 height: auto），则需要根据子节点在交叉轴上的尺寸来确定。
  2. 处理 flex-wrap： 如果 flex-wrap 为 wrap，当主轴空间不足时，Flex 项目会换行。Yoga 会计算出多行的布局，并为每一行分配交叉轴空间。
  3. 应用 align-items 和 align-self：
     • 对于单行布局，align-items 定义了所有项目在交叉轴上的对齐方式。
     • align-self 允许单个项目覆盖 align-items 的设置。
     • stretch 会使项目在交叉轴上拉伸，以填充可用空间（如果未设置 width/height）。

• 位置分配 (Positioning):

  1. 主轴定位： 根据 justify-content 属性，在主轴上分配项目的最终位置。例如 space-between 会将项目均匀分布，首尾项目紧贴容器边缘。
  2. 交叉轴定位：
     • 对于单行，根据 align-items 或 align-self 在交叉轴上分配位置。
     • 对于多行，根据 align-content 在交叉轴上分配行与行之间的空间和位置。
  3. margin, padding, border 的计算： 这些值会影响项目的实际尺寸和在容器中的占据空间，在计算过程中需要精确考虑。auto margin 在 Flexbox 中有特殊作用，可以吸收额外的空间，实现居中或两端对齐。
  4. position: relative： 相对定位的偏移量 (left, top, right, bottom) 会在最终布局结果的基础上进行调整。

• 递归处理子节点： 对每个子节点，Yoga 会以父节点计算出的可用空间作为约束，递归地调用布局算法。

代码示例：简化 C++ 布局函数片段

// 核心布局计算函数 (简化版，实际 Yoga 代码远比这复杂)
static void calculateLayoutInternal(YGNodeRef node,
                                    float availableWidth,
                                    float availableHeight,
                                    YGMeasureMode widthMode,
                                    YGMeasureMode heightMode,
                                    YGConfigRef config) {
    if (!node->isDirty && node->hasMeasuredSizes) {
        // 如果节点不脏且已测量过尺寸，直接返回缓存结果
        // 实际情况更复杂，会检查父级约束是否改变
        return;
    }

    // 1. 解析样式，确定主轴和交叉轴
    YGFlexDirection flexDirection = YGResolveFlexDirection(node->style.flexDirection, node->style.direction);
    bool isRow = YGFlexDirectionIsRow(flexDirection);

    // 2. 处理绝对定位的子节点 (在主要布局流之外单独处理)
    // ...

    // 3. 测量子节点的固有尺寸 (递归调用或 measureFunc)
    // 这一步通常会递归调用 calculateLayoutInternal
    // 或者调用 YGMeasureFunc 来测量文本、图片等内容
    for (YGNodeRef child : node->children) {
        if (child->style.positionType != YGPositionTypeAbsolute) {
            // 假设这里会递归调用，并获取子节点的初步尺寸
            // 实际参数会更复杂，包含可用空间和测量模式
            calculateLayoutInternal(child, availableWidth, availableHeight, ...);
        }
    }

    // 4. 计算主轴和交叉轴的初始尺寸和剩余空间
    //    根据 flex-basis, width/height, content size...
    // ...

    // 5. 分配主轴空间 (flex-grow, flex-shrink)
    //    遍历所有子节点，计算它们的伸缩因子，分配或收缩空间
    // ...

    // 6. 确定交叉轴尺寸和多行处理 (flex-wrap, align-content)
    // ...

    // 7. 分配交叉轴位置 (align-items, align-self)
    // ...

    // 8. 最终位置和尺寸的确定 (left, top, width, height)
    //    应用 justify-content, margin, padding, border, relative position offsets
    // node->layout.left = ...
    // node->layout.top = ...
    // node->layout.width = ...
    // node->layout.height = ...

    // 9. 标记节点为已计算
    node->isDirty = false;
    node->hasNewLayout = true;
    node->hasMeasuredSizes = true; // 如果它是一个叶子节点或者内容尺寸已确定
}

// 外部调用的入口函数
void YGLayoutNode(YGNodeRef node, float availableWidth, float availableHeight, YGDirection direction) {
    // 设置根节点的初始方向和可用空间
    node->style.direction = direction;
    // 标记所有节点为脏 (如果需要全局重新布局)
    // ...
    calculateLayoutInternal(node, availableWidth, availableHeight, YGMeasureModeExactly, YGMeasureModeExactly, node->config);
}

C. 性能优化策略

Yoga 的高性能不仅依赖于 C++ 的原生速度，还在于其内部精妙的优化策略。

• 脏节点标记 (Dirty Node Marking): 这是最重要的优化之一。当一个节点的样式发生变化时，它及其所有祖先节点都会被标记为“脏”。在下一次布局计算时，Yoga 只会从最近的脏祖先节点开始，向下重新计算受影响的子节点。未被标记为脏的节点，其布局结果可以直接复用。这避免了对整个布局树进行不必要的全面遍历和计算。

  // 示例：当一个节点的样式发生变化时
  void YGNodeStyleSetWidth(YGNodeRef node, float width) {
      if (node->style.width.value != width) {
          node->style.width = {width, YGUnitPoint};
          YGMarkNodeDirty(node); // 标记此节点为脏
      }
  }
  
  void YGMarkNodeDirty(YGNodeRef node) {
      if (node->isDirty) return; // 已经脏了，无需重复标记
      node->isDirty = true;
      node->hasNewLayout = false; // 布局结果已过时
  
      // 向上冒泡，标记所有祖先节点为脏，因为子节点的变化会影响父节点的布局
      if (node->parent != nullptr) {
          YGMarkNodeDirty(node->parent);
      }
  }

• 缓存 (Caching): Yoga 会缓存布局计算的结果。如果一个节点的样式和其父容器的可用空间等约束没有改变，并且它没有被标记为脏，Yoga 会直接返回缓存的布局结果，避免重复计算。这包括布局结果的缓存和 YGMeasureFunc 测量结果的缓存。

• 批处理 (Batching): 虽然 Yoga 本身是同步计算的，但 React Native 框架在调用 Yoga 之前，会将多个 UI 更新操作（例如多次 setState 导致多个组件样式改变）批处理为一次。这意味着 Yoga 会一次性处理一个批次的所有布局计算，然后将最终的、完整的布局结果通过桥接发送给原生 UI 线程。这样可以减少桥接的通信开销。

• 避免布局抖动 (Layout Thrashing): React Native 的调度器与 Yoga 协同工作，尽量在 JavaScript 线程的单次事件循环中完成所有布局计算，并只进行一次桥接通信。这避免了 Web 中常见的“读-写-读-写”模式导致的布局抖动。

D. C++ 接口与 JavaScript 桥接

Yoga 是一个纯 C++ 库，它提供了一套 C 风格的 API，允许其他语言（如 Objective-C、Java、JavaScript）通过 FFI (Foreign Function Interface) 或特定绑定来调用它。

1. Yoga 的 C API 示例

// 创建一个 Yoga 节点
YGNodeRef node = YGNodeNew();

// 设置样式属性
YGNodeStyleSetWidth(node, 100);
YGNodeStyleSetHeight(node, 50);
YGNodeStyleSetFlexDirection(node, YGFlexDirectionRow);
YGNodeStyleSetJustifyContent(node, YGJustifyCenter);

// 添加子节点
YGNodeRef child1 = YGNodeNew();
YGNodeStyleSetWidth(child1, 20);
YGNodeStyleSetHeight(child1, 20);
YGNodeInsertChild(node, child1, 0);

// 计算布局
YGNodeCalculateLayout(node, YGUndefined, YGUndefined, YGDirectionLTR);

// 获取布局结果
float left = YGNodeLayoutGetLeft(child1);
float top = YGNodeLayoutGetTop(child1);
float width = YGNodeLayoutGetWidth(child1);
float height = YGNodeLayoutGetHeight(child1);

printf("Child 1 layout: left=%.1f, top=%.1f, width=%.1f, height=%.1fn", left, top, width, height);

// 释放节点
YGNodeFree(child1);
YGNodeFree(node);

2. JavaScript 桥接机制

在 React Native 中，JavaScript 代码无法直接调用 C++ 函数。它需要通过桥接机制。

• 旧架构 (Bridge): 在旧的 React Native 架构中，JavaScript 线程与原生线程之间通过 JSON 序列化的消息进行通信。当 React 组件的样式属性发生变化时：

  1. React Native 的 JS 侧会遍历虚拟 DOM 树，提取出 style 属性（如 flexDirection: 'row', width: 100）。
  2. 这些属性被转换为 Yoga 期望的格式（例如，row 转换为 YGFlexDirectionRow 枚举值）。
  3. 一个 JavaScript 层面的 Yoga 绑定（例如 yoga-layout npm 包的 C++ FFI 封装）被调用，它会将这些属性传递给 C++ 的 Yoga 引擎。
  4. C++ 的 Yoga 引擎进行布局计算。
  5. 计算完成后，Yoga 将结果（left, top, width, height 等）返回给 JavaScript 线程。
  6. JavaScript 线程将这些最终的布局结果以及其他视图属性序列化为 JSON 消息。
  7. 通过异步桥接，将 JSON 消息发送到原生 UI 线程。
  8. 原生 UI 线程解析 JSON，并根据指令调用平台特定的 UI API（如 iOS 的 [UIView setFrame:] 或 Android 的 view.setLayoutParams()）来更新视图。

• 新架构 (Fabric with JSI): 随着 React Native 新架构 Fabric 的引入，桥接的性能瓶颈得到了显著改善。JSI (JavaScript Interface) 允许 JavaScript 直接持有 C++ Host Object 的引用，并同步调用其方法，而无需序列化/反序列化。

  • 在 Fabric 中，Yoga 节点可以直接在 C++ 层创建和维护。
  • JavaScript 层的 React Reconciliation 过程可以直接通过 JSI 同步调用 C++ Yoga 节点的方法来设置样式属性。
  • 布局计算仍然在 C++ Yoga 中进行。
  • 布局结果可以直接被原生 UI 线程读取，或者同步反馈给 JavaScript 线程。
  • 这种同步且直接的调用机制，大大减少了桥接的开销，使得布局计算和视图更新更加流畅。

五、React Native 中的“重排”痛点与 Yoga 的作用

尽管 Yoga 在 C++ 层提供了极高的布局计算效率，但在 React Native 的整体架构中，“重排”的痛点依然存在，并且 Yoga 只能缓解而不能完全消除它们。

A. JavaScript 线程的瓶颈

• 组件树的创建与更新： React Reconciliation 过程本身需要时间来比较虚拟 DOM 树，构建新的 UI 树。对于大型或复杂的组件树，即使没有样式变化，这个过程也可能消耗大量 JS 线程时间。
• 将 React 元素的属性转换为 Yoga 属性的开销： React Native 需要将 JavaScript 对象中的样式属性（如 flexDirection: 'row') 转换为 Yoga C++ 引擎能够理解的枚举值和数据结构。这个转换过程虽然不复杂，但频繁进行也会积累开销。
• 布局计算本身在 Yoga 中很快，但数据传输和 JS 侧的协调仍是瓶颈： 即使 Yoga 可以在毫秒级完成布局计算，但如果每次布局都需要 JS 线程频繁地创建 Yoga 节点、设置属性、调用计算，再接收结果，这些 JS 侧的协调和数据传输仍然会占用宝贵的 JS 线程时间。

B. 桥接开销 (Bridge Overhead)

在旧架构中，无论 Yoga 计算多快，最终的布局结果都需要通过异步桥接以 JSON 消息的形式发送到原生 UI 线程。

• 序列化/反序列化： 将布局数据从 JS 对象转换为 JSON 字符串，再从 JSON 字符串解析为原生对象，这个过程有显著的 CPU 和内存开销。
• 消息传递延迟： 桥接通信是异步的，存在固有的延迟。如果 JS 线程频繁发送布局更新，或者消息队列堆积，就会导致 UI 线程更新不及时，产生卡顿。

C. 测量与布局的异步性

在某些情况下，React Native 组件的精确尺寸无法在第一次渲染时确定。例如：

• 文本内容的尺寸： 文本的实际宽度和高度取决于其内容、字体、字号、以及给定的最大宽度约束。Yoga 无法直接知道这些，需要通过 YGMeasureFunc 回调到 JS 线程，在 JS 线程中进行原生文本测量，然后将结果返回给 Yoga。
• onLayout 事件： onLayout 事件在组件被原生视图系统实际布局并绘制到屏幕上之后才触发。这意味着如果我们需要根据一个组件的实际布局尺寸来调整另一个组件的布局，可能需要经历“渲染 -> 获取 onLayout -> 重新计算布局 -> 再次渲染”的循环，这会引入视觉上的延迟或“闪烁”。

D. Yoga 如何缓解但不能完全消除痛点

• 缓解：
  • 极致的计算性能： C++ 实现确保布局计算本身的速度最快，将纯布局算法的时间开销降到最低。
  • 脏节点标记和缓存： 避免了不必要的重复布局计算，只处理真正发生变化的子树，显著减少了总体的布局工作量。
  • 统一的布局模型： 避免了原生平台特定布局系统的复杂性和不一致性，降低了开发者心智负担，也减少了在不同平台间适配布局的潜在性能问题。
• 不能完全消除：
  • Yoga 优化的是布局计算的速度，但它无法消除 JavaScript 线程本身的计算开销、桥接的序列化/反序列化开销、以及异步通信的固有延迟。
  • 在旧架构中，布局计算结果的传递仍然是异步的，可能导致“重排”的感知延迟。

六、实践中的优化策略

理解 Yoga 的工作原理，能帮助我们更好地优化 React Native 应用的性能。

• 扁平化组件树： 减少组件的嵌套层级直接对应着减少 Yoga 节点的数量和布局树的深度。更扁平的树意味着更少的节点需要遍历和计算，从而提高 Yoga 的效率。例如，避免使用过多的 View 组件来仅仅包裹其他组件，除非它们确实需要独立的布局行为。

  // 不推荐：过多嵌套
  <View style={{flexDirection: 'row'}}>
    <View style={{flex: 1}}>
      <View style={{padding: 10}}>
        <Text>Item 1</Text>
      </View>
    </View>
    <View style={{flex: 1}}>
      <View style={{padding: 10}}>
        <Text>Item 2</Text>
      </View>
    </View>
  </View>
  
  // 推荐：扁平化
  <View style={{flexDirection: 'row'}}>
    <View style={{flex: 1, padding: 10}}>
      <Text>Item 1</Text>
    </View>
    <View style={{flex: 1, padding: 10}}>
      <Text>Item 2</Text>
    </View>
  </View>

• 避免不必要的布局更新： 使用 shouldComponentUpdate、React.memo 或 useMemo/useCallback Hooks 来阻止组件在 props 或 state 未改变时进行不必要的重新渲染。这可以减少 React Reconciliation 的工作量，进而减少 Yoga 的布局计算。

  // 使用 React.memo 避免不必要的子组件渲染
  const MyItem = React.memo(({ title, onPress }) => {
    console.log('MyItem rendered');
    return (
      <TouchableOpacity onPress={onPress}>
        <Text>{title}</Text>
      </TouchableOpacity>
    );
  });
  
  function ParentComponent() {
    const [count, setCount] = useState(0);
    const handlePress = useCallback(() => { /* ... */ }, []);
  
    return (
      <View>
        <Text>{count}</Text>
        <Button title="Increment" onPress={() => setCount(c => c + 1)} />
        <MyItem title="Memoized Item" onPress={handlePress} /> {/* 只有当 title 或 onPress 改变时才渲染 */}
      </View>
    );
  }

• 使用 useWindowDimensions / Dimensions 预计算： 对于依赖屏幕尺寸的布局，尽量使用 Dimensions API 或 useWindowDimensions Hook 在 JS 线程中预先计算好尺寸，而不是依赖 onLayout 事件。onLayout 会引入额外的渲染周期和桥接开销。

  import { useWindowDimensions } from 'react-native';
  
  function ResponsiveComponent() {
    const { width } = useWindowDimensions();
    const itemWidth = (width - 40) / 2; // 预计算两个项目的宽度
  
    return (
      <View style={{ flexDirection: 'row', padding: 20 }}>
        <View style={{ width: itemWidth, height: 100, backgroundColor: 'red' }} />
        <View style={{ width: itemWidth, height: 100, backgroundColor: 'blue', marginLeft: 10 }} />
      </View>
    );
  }

• Native 模块的介入： 对于极其复杂且性能敏感的布局（例如，高性能的列表视图或自定义图表），如果 Flexbox 无法满足性能要求，可以考虑使用 Native UI 组件或将部分布局逻辑直接实现在原生模块中，以绕过桥接和 JS 线程的开销。例如，FlashList 等高性能列表库就大量使用了原生能力。

• LayoutAnimation / Animated API： 在进行动画时，尽量使用 Animated API 或 LayoutAnimation。它们可以在原生 UI 线程上直接执行动画，而无需每次更新都通过桥接。特别是 LayoutAnimation，它允许你声明式地定义布局变化时的动画效果，由原生平台自动处理，减少了 JS 线程的负担和布局抖动。

  import { LayoutAnimation, UIManager, Platform, View, Button, StyleSheet } from 'react-native';
  
  if (Platform.OS === 'android') {
    if (UIManager.setLayoutAnimationEnabledExperimental) {
      UIManager.setLayoutAnimationEnabledExperimental(true);
    }
  }
  
  function LayoutAnimatedBox() {
    const [boxWidth, setBoxWidth] = useState(100);
  
    const changeSize = () => {
      LayoutAnimation.spring(); // 使用弹簧动画
      setBoxWidth(boxWidth === 100 ? 200 : 100);
    };
  
    return (
      <View style={styles.container}>
        <View style={[styles.box, { width: boxWidth }]} />
        <Button title="Change Size" onPress={changeSize} />
      </View>
    );
  }
  
  const styles = StyleSheet.create({
    container: { flex: 1, justifyContent: 'center', alignItems: 'center' },
    box: { height: 100, backgroundColor: 'red' },
  });

• 新架构 (Fabric) 的展望： React Native 的新架构 Fabric 通过 JSI 提供了同步、直接的 JS-Native 通信。这意味着 JavaScript 可以直接调用 C++ 的 Yoga 布局引擎，获取布局结果，并且原生 UI 线程也可以直接读取这些结果来更新视图。这大大减少了桥接的开销和布局更新的延迟，使“重排”更加流畅。虽然它并不能完全消除布局计算本身的开销，但显著优化了数据传输效率和同步性。

七、展望未来

Yoga 作为 React Native 布局的核心，其持续演进是不可避免的。随着 React Native 新架构 Fabric 的推广，Yoga 将与 JSI 更紧密地集成，实现真正的同步布局。这意味着 React 的 render 阶段将能够直接在 JavaScript 线程中调用 C++ 的 Yoga，获取布局结果，并直接构建原生 Shadow Tree，最终一次性提交到原生 UI 线程进行绘制，大大减少了异步桥接带来的延迟和上下文切换开销。这种同步布局能力将是未来 React Native 性能飞跃的关键。Yoga 自身也会继续优化算法，支持更高级的布局特性，并进一步提升计算效率。

八、理解底层，赋能开发

Yoga 布局引擎是 React Native 实现高性能跨平台 UI 的基石。它在 C++ 层高效地模拟了 Flexbox 规范，解决了原生平台布局系统不一致的问题，并通过脏节点标记、缓存等策略大幅提升了布局计算的效率。然而，React Native 的“重排”痛点并非完全由 Yoga 引起，JavaScript 线程的负载、桥接的开销以及异步通信的本质仍然是需要关注的方面。

作为 React Native 开发者，深入理解 Yoga 的工作原理，不仅能帮助我们更好地诊断和解决性能问题，更能指导我们编写出更高效、更具响应性的 UI 代码。性能优化是一个持续的过程，需要我们不断探索和理解底层机制。