给你一个长度为 n 的质数数组 nums 。你的任务是返回一个长度为 n 的数组 ans ，对于每个下标 i ，以下 条件 均成立：

• ans[i] OR (ans[i] + 1) == nums[i]

除此以外，你需要 最小化 结果数组里每一个 ans[i] 。

如果没法找到符合 条件 的 ans[i] ，那么 ans[i] = -1 。

质数 指的是一个大于 1 的自然数，且它只有 1 和自己两个因数。

示例 1：

示例 2：

提示：

• 1 <= nums.length <= 100
• 2 <= nums[i] <= 1000
• nums[i] 是一个质数。

解法一

思路和算法

数组 $\textit{nums}$ 的长度是 $n$。对于 $0 \le i < n$ 的每个下标 $i$，满足 $(\textit{ans}[i] ~|~ (\textit{ans}[i] + 1)) = \textit{nums}[i]$。由于 $\textit{nums}[i]$ 是质数，即 $\textit{nums}[i]$ 至少等于 $2$，因此 $\textit{ans}[i]$ 一定是正整数。

最直观的计算 $\textit{ans}[i]$ 的方法是从小到大遍历每个正整数 $x$，寻找满足 $(x ~|~ (x + 1)) = \textit{nums}[i]$ 的最小正整数 $x$ 填入 $\textit{ans}[i]$，如果不存在符合要求的正整数 $x$ 则 $\textit{ans}[i] = -1$。

根据按位或运算的性质，必有 $(\textit{ans}[i] ~|~ (\textit{ans}[i] + 1)) \ge \textit{ans}[i]$，因此当 $\textit{ans}[i] > \textit{nums}[i]$ 时必有 $(\textit{ans}[i] ~|~ (\textit{ans}[i] + 1)) > \textit{nums}[i]$，计算 $\textit{ans}[i]$ 时只需要遍历不超过 $\textit{nums}[i]$ 的值。

代码

###Java

class Solution {
    public int[] minBitwiseArray(List<Integer> nums) {
        int n = nums.size();
        int[] ans = new int[n];
        for (int i = 0; i < n; i++) {
            ans[i] = find(nums.get(i));
        }
        return ans;
    }

    public int find(int num) {
        for (int i = 1; i <= num; i++) {
            if ((i | (i + 1)) == num) {
                return i;
            }
        }
        return -1;
    }
}

###C#

public class Solution {
    public int[] MinBitwiseArray(IList<int> nums) {
        int n = nums.Count;
        int[] ans = new int[n];
        for (int i = 0; i < n; i++) {
            ans[i] = Find(nums[i]);
        }
        return ans;
    }

    public int Find(int num) {
        for (int i = 1; i <= num; i++) {
            if ((i | (i + 1)) == num) {
                return i;
            }
        }
        return -1;
    }
}

复杂度分析

• 时间复杂度：$O(nm)$，其中 $n$ 是数组 $\textit{nums}$ 的长度，$m$ 是数组 $\textit{nums}$ 中的最大元素。答案数组中的每个元素的计算时间都是 $O(m)$。

• 空间复杂度：$O(1)$。注意返回值不计入空间复杂度。

解法二

思路和算法

当存在正整数 $x$ 满足 $(x ~|~ (x + 1)) = \textit{nums}[i]$ 时，由于 $x$ 和 $x + 1$ 当中一定有一个奇数，因此 $\textit{nums}[i]$ 一定是奇数。如果 $\textit{nums}[i]$ 是偶数，则不存在符合要求的 $x$，对应 $\textit{ans}[i] = -1$。当 $\textit{nums}[i]$ 是奇数时，可以取 $x = \textit{nums}[i] - 1$，则满足 $(x ~|~ (x + 1)) = \textit{nums}[i]$，因此如果 $\textit{nums}[i]$ 是奇数，则一定存在符合要求的 $x$。

由于 $\textit{nums}[i]$ 是质数，唯一的偶质数是 $2$，因此当 $\textit{nums}[i] = 2$ 时 $\textit{ans}[i] = -1$。当 $\textit{nums}[i] > 2$ 时 $\textit{ans}[i] > 0$，需要计算 $\textit{ans}[i]$。

考虑正整数 $x$ 和 $x + 1$ 的二进制表示的如下两种情况。

• 当 $x$ 是偶数时，$x$ 的二进制表示的最低位是 $0$，$x + 1$ 的二进制表示等于 $x$ 的二进制表示的最低位从 $0$ 变成 $1$。

• 当 $x$ 是奇数时，$x$ 的二进制表示最低位有 $k$ 个 $1$ 且从低到高第 $k$ 位等于 $0$（位数从 $0$ 开始计数），其中 $k \ge 1$，$x + 1$ 的二进制表示等于 $x$ 的二进制表示的最低 $k$ 位从 $1$ 变成 $0$ 且从低到高第 $k$ 位从 $0$ 变成 $1$。

因此，$x ~|~ (x + 1)$ 的二进制表示的结果等于 $x$ 的二进制表示的最右边的 $0$ 变成 $1$。

为了使 $\textit{ans}[i]$ 的值最小，需要找到 $\textit{nums}[i]$ 的二进制表示中的可以变成 $0$ 的最左边的 $1$，满足将 $0$ 变成 $1$ 之后在其右侧没有任何 $0$。计算方法如下。

1. 计算 $\textit{nums}[i]$ 的二进制表示的最低连续 $1$ 的最大位数 $k$，满足二进制表示最低位有 $k$ 个 $1$ 且从低到高第 $k$ 位等于 $0$（位数从 $0$ 开始计数）。

2. 计算 $\textit{ans}[i] = \textit{nums}[i] - 2^{k - 1}$。

根据位运算的性质，计算方法如下：计算 $\textit{lowbit} = ((\textit{nums}[i] + 1) ~&~ (-\textit{nums}[i] - 1)) >> 1$，则 $\textit{lowbit}$ 等于上述 $2^{k - 1}$，$\textit{ans}[i] = \textit{nums}[i] - \textit{lowbit}$。

代码

###Java

class Solution {
    public int[] minBitwiseArray(List<Integer> nums) {
        int n = nums.size();
        int[] ans = new int[n];
        for (int i = 0; i < n; i++) {
            ans[i] = find(nums.get(i));
        }
        return ans;
    }

    public int find(int num) {
        if (num % 2 == 0) {
            return -1;
        } else {
            int lowbit = ((num + 1) & (-num - 1)) >> 1;
            return num - lowbit;
        }
    }
}

###C#

public class Solution {
    public int[] MinBitwiseArray(IList<int> nums) {
        int n = nums.Count;
        int[] ans = new int[n];
        for (int i = 0; i < n; i++) {
            ans[i] = Find(nums[i]);
        }
        return ans;
    }

    public int Find(int num) {
        if (num % 2 == 0) {
            return -1;
        } else {
            int lowbit = ((num + 1) & (-num - 1)) >> 1;
            return num - lowbit;
        }
    }
}

复杂度分析

• 时间复杂度：$O(n)$，其中 $n$ 是数组 $\textit{nums}$ 的长度。答案数组中的每个元素的计算时间都是 $O(1)$。

• 空间复杂度：$O(1)$。注意返回值不计入空间复杂度。

本题和 3315. 构造最小位运算数组 II 是一样的，请看 我的题解。

解法：数学

考虑 x or (x + 1) 是一个怎样的数。可以发现，x + 1 的二进制表示和 x 相比，其实就是把 x 从最低位开始的连续 $1$ 都变成 $0$，然后把下一位变成 $1$，更高位都不变。

因此我们找出 nums[i] 从最低位开始的连续 $1$，把连续 $1$ 的最后一位变成 $0$，就是答案。复杂度 $\mathcal{O}(n\log X)$，其中 $X = 10^9$ 是取值范围。

参考代码（c++）

###cpp

class Solution {
public:
    vector<int> minBitwiseArray(vector<int>& nums) {
        vector<int> ans;
        for (int x : nums) {
            if (x == 2) ans.push_back(-1);
            else {
                // 求从最低位开始的连续 1
                int p;
                for (p = 0; x >> p & 1; p++);
                // 把连续 1 的最后一位变成 0
                ans.push_back(x ^ (1 << (p - 1)));
            }
        }
        return ans;
    }
};

React Native之Android端Fabric 架构源码分析（下）

由于单章字数限制，这里将本文拆成上下两篇，上篇《React Native之Android端Fabric 架构源码分析（上）》

Fabric 组件

声明组件

要开发一个Fabric 组件，首先需要在TS代码中声明规范。我们使用npx create-react-native-library@latest创建一个Fabric组件库，然后参考根据官方文档的示例添加如下内容：

import type {
  CodegenTypes,
  HostComponent,
  ViewProps,
} from 'react-native';
import {codegenNativeComponent} from 'react-native';

type WebViewScriptLoadedEvent = {
  result: 'success' | 'error';
};

export interface NativeProps extends ViewProps {
  sourceURL?: string;
  onScriptLoaded?: CodegenTypes.BubblingEventHandler<WebViewScriptLoadedEvent> | null;
}

export default codegenNativeComponent<NativeProps>(
  'CustomWebView',
) as HostComponent<NativeProps>;

这里主要有三部分：

• WebViewScriptLoadedEvent 是一种支持的数据类型，用于存储事件需要从原生代码传递到 JavaScript 的数据。

• NativeProps 定义了可以设置的组件属性。

• codegenNativeComponent 允许我们为自定义组件生成代码，并为组件定义一个与原生实现相匹配的名称。

其中，对codegenNativeComponent函数进行分析，源码react-native/packages/react-native/Libraries/Utilities/codegenNativeComponent.js:

// 如果这个函数运行，说明视图配置没有在构建时通过 `GenerateViewConfigJs.js` 生成。
// 因此我们需要使用 `requireNativeComponent` 从视图管理器获取视图配置。
// `requireNativeComponent` 在 Bridgeless 模式下不可用。
// 例如：如果 `codegenNativeComponent` 不是从以 NativeComponent.js 结尾的文件中调用，
// 这个函数就会在运行时执行。
function codegenNativeComponent<Props: {...}>(
  componentName: string,
  options?: NativeComponentOptions,
): NativeComponentType<Props> {
  if (global.RN$Bridgeless === true && __DEV__) {
    console.warn(
      `Codegen didn't run for ${componentName}. This will be an error in the future. Make sure you are using @react-native/babel-preset when building your JavaScript code.`,
    );
  }
  // 确定基础组件名称
  let componentNameInUse =
    options && options.paperComponentName != null
      ? options.paperComponentName
      : componentName;

  // 省略部分代码......

  return (requireNativeComponent<Props>(
    // $FlowFixMe[incompatible-type]
    componentNameInUse,
  ): HostComponent<Props>);
}

根据注释可知，在新架构中，这个函数几乎没有实际意义，因为新架构是通过GenerateViewConfigJs.js 来生成实际的视图配置。

我们通过搜索codegenNativeComponent字符串，很容易定位到react-native/packages/babel-plugin-codegen/index.js文件，这里babel-plugin-codegen包就是检测codegenNativeComponent调用，解析TypeScript/Flow类型定义的工具包：

module.exports = function ({parse, types: t}) {
  return {
    pre(state) {
      this.code = state.code;
      this.filename = state.opts.filename;
      this.defaultExport = null;
      this.commandsExport = null;
      this.codeInserted = false;
    },

    // 省略部分代码.....
      ExportDefaultDeclaration(path, state) {
        if (isCodegenDeclaration(path.node.declaration)) {
          this.defaultExport = path;
        }
      },

      // 程序退出时进行替换
      Program: {
        exit(path) {
          if (this.defaultExport) {
            // 1. 生成ViewConfig代码
            const viewConfig = generateViewConfig(this.filename, this.code);
            // 2. 解析为AST
            const ast = parse(viewConfig, {
              babelrc: false,
              browserslistConfigFile: false,
              configFile: false,
            });

            // 3. 完全替换原始导出
            this.defaultExport.replaceWithMultiple(ast.program.body);

            if (this.commandsExport != null) {
              this.commandsExport.remove();
            }

            this.codeInserted = true;
          }
        },
      },
    },
  };
};


function generateViewConfig(filename /*: string */, code /*: string */) {
  // 解析TypeScript/Flow类型
  const schema = parseFile(filename, code);
  // 提取组件信息
  const libraryName = basename(filename).replace(
    /NativeComponent\.(js|ts)$/,
    '',
  );
  // 调用Codegen生成器
  return RNCodegen.generateViewConfig({
    libraryName,
    schema,
  });
}

function isCodegenDeclaration(declaration) {
  if (!declaration) {
    return false;
  }

  if (
    declaration.left &&
    declaration.left.left &&
    declaration.left.left.name === 'codegenNativeComponent'
  ) {
    return true;
  } else if (
    declaration.callee &&
    declaration.callee.name &&
    declaration.callee.name === 'codegenNativeComponent'
  ) {
    return true;
  } 
  // 省略......
  return false;
}

继续跟踪RNCodegen.generateViewConfig的实现，源码react-native/packages/react-native-codegen/src/generators/RNCodegen.js：

const generateViewConfigJs = require('./components/GenerateViewConfigJs.js');


module.exports = {
  allGenerators: ALL_GENERATORS,
  // 省略部分代码......
  generateViewConfig({
    libraryName,
    schema,
  }: Pick<LibraryOptions, 'libraryName' | 'schema'>): string {
    schemaValidator.validate(schema);

    const result = generateViewConfigJs
      .generate(libraryName, schema)
      .values()
      .next();

    if (typeof result.value !== 'string') {
      throw new Error(`Failed to generate view config for ${libraryName}`);
    }

    return result.value;
  },
};

最终是调用的GenerateViewConfigJs.js中的generate，源码react-native/packages/react-native-codegen/src/generators/components/GenerateViewConfigJs.js：

module.exports = {
  generate(libraryName: string, schema: SchemaType): FilesOutput {
    try {
      const fileName = `${libraryName}NativeViewConfig.js`;
      const imports: Set<string> = new Set();

      const moduleResults = Object.keys(schema.modules)
        .map(moduleName => {
          const module = schema.modules[moduleName];
          if (module.type !== 'Component') {
            return;
          }

          const {components} = module;

          return Object.keys(components)
            .map((componentName: string) => {
              const component = components[componentName];

              if (component.paperComponentNameDeprecated) {
                imports.add(UIMANAGER_IMPORT);
              }

              const replacedTemplate = ComponentTemplate({
                componentName,
                paperComponentName: component.paperComponentName,
                paperComponentNameDeprecated:
                  component.paperComponentNameDeprecated,
              });
      // 省略部分代码...... 

      return new Map([[fileName, replacedTemplate]]);
    } catch (error) {
      console.error(`\nError parsing schema for ${libraryName}\n`);
      console.error(JSON.stringify(schema));
      throw error;
    }
  },
};

这里我们根据ComponentTemplate中的模板，大概就能还原出生成的代码是什么样子：

// 输入：
// libraryName: "MyComponent"
// schema: { 解析后的TypeScript/Flow类型信息 }

// 输出：完整的JavaScript代码字符串


'use strict';

const {UIManager} = require("react-native")

let nativeComponentName = 'MyComponent';

export const __INTERNAL_VIEW_CONFIG = {
  uiViewClassName: 'MyComponent',
  bubblingEventTypes: {},
  directEventTypes: {},
  validAttributes: {
    opacity: true,
    backgroundColor: { process: require('react-native/Libraries/StyleSheet/processColor').default },
    // ... 其他属性
  }
};

export default NativeComponentRegistry.get(nativeComponentName, () => __INTERNAL_VIEW_CONFIG);

这里最关键的就是最后一行，它将开发者编写的Fabric 组件规范进行了代码替换：

// 开发者编写
const CustomView = codegenNativeComponent<Props>('CustomView');

// Babel插件替换后
const CustomView = NativeComponentRegistry.get('CustomView', () => __INTERNAL_VIEW_CONFIG);

需要注意，babel-plugin-codegen工具并不像Codegen工具，会生成实际的代码文件。它是对AST语法树进行的动态修改和替换，也就是说它修改的是内存中的语法树，并不会写文件。

现在来重点追踪NativeComponentRegistry.get的实现，首先是导出位置react-native/packages/react-native/index.js：

  get NativeComponentRegistry() {
    return require('./Libraries/NativeComponent/NativeComponentRegistry');
  },

定位到方法实现react-native/packages/react-native/Libraries/NativeComponent/NativeComponentRegistry.js：

/**
 * 获取一个可以被 React Native 渲染的 `NativeComponent`。
 *
 * 提供的 `viewConfigProvider` 可能会被调用和使用，也可能不会，
 * 这取决于 `setRuntimeConfigProvider` 是如何配置的。
 */
export function get<Config: {...}>(
  name: string,
  viewConfigProvider: () => PartialViewConfig,
): HostComponent<Config> {
  // 注册ViewConfig到全局注册表
  ReactNativeViewConfigRegistry.register(name, () => {
    // 这里的回调函数会在React需要组件配置时被调用
    const {native, verify} = getRuntimeConfig?.(name) ?? {
      native: !global.RN$Bridgeless,   // 关键：新架构检测
      verify: false,
    };

    let viewConfig: ViewConfig;
    if (native) {
      // 旧架构：原生ViewManager
      viewConfig =
        getNativeComponentAttributes(name) ??
        createViewConfig(viewConfigProvider());
    } else {
      // 新架构：优先静态ViewConfig
      viewConfig =
        createViewConfig(viewConfigProvider()) ??
        getNativeComponentAttributes(name);
    }
    // 省略部分代码......
    return viewConfig;
  });

  // $FlowFixMe[incompatible-type] `NativeComponent` 实际上是字符串!
  return name;
}

继续跟踪ReactNativeViewConfigRegistry.register实现。源码react-native/packages/react-native/Libraries/Renderer/shims/ReactNativeViewConfigRegistry.js：

const viewConfigCallbacks = new Map<string, ?() => ViewConfig>();


export function register(name: string, callback: () => ViewConfig): string {
  // 省略部分代码......
  viewConfigCallbacks.set(name, callback);
  return name;
}

这里基本上就是将返回ViewConfig的闭包给存了起来。

查找组件

JS层

在前面启动渲染一节我们知道了启动渲染的最终调用是JS层的AppRegistry.runApplication方法。沿着这条线，我们来分析一下JS层的组件加载与处理流程。源码react-native/packages/react-native/Libraries/ReactNative/AppRegistry.js：

import * as AppRegistry from './AppRegistryImpl';

// 省略部分代码......
global.RN$AppRegistry = AppRegistry;

registerCallableModule('AppRegistry', AppRegistry);

export {AppRegistry};

继续跟踪源码react-native/packages/react-native/Libraries/ReactNative/AppRegistryImpl.js：

const runnables: Runnables = {};


/**
 * Loads the JavaScript bundle and runs the app.
 *
 * See https://reactnative.dev/docs/appregistry#runapplication
 */
export function runApplication(
  appKey: string,
  appParameters: AppParameters,
  displayMode?: number,
): void {
  if (appKey !== 'LogBox') {
    const logParams = __DEV__ ? ` with ${JSON.stringify(appParameters)}` : '';
    const msg = `Running "${appKey}"${logParams}`;
    console.log(msg);
  }

  SceneTracker.setActiveScene({name: appKey});
  runnables[appKey](appParameters, coerceDisplayMode(displayMode));
}


/**
 * Registers an app's root component.
 *
 * See https://reactnative.dev/docs/appregistry#registercomponent
 */
export function registerComponent(
  appKey: string,
  componentProvider: ComponentProvider,
  section?: boolean,
): string {
  const scopedPerformanceLogger = createPerformanceLogger();
  runnables[appKey] = (appParameters, displayMode) => {
    const renderApplication = require('./renderApplication').default;
    renderApplication(
      componentProviderInstrumentationHook(
        componentProvider,
        scopedPerformanceLogger,
      ),
      appParameters.initialProps,
      appParameters.rootTag,
      wrapperComponentProvider && wrapperComponentProvider(appParameters),
      rootViewStyleProvider && rootViewStyleProvider(appParameters),
      appParameters.fabric,
      scopedPerformanceLogger,
      appKey === 'LogBox', // is logbox
      appKey,
      displayMode,
    );
  };
  if (section) {
    sections[appKey] = runnables[appKey];
  }
  return appKey;
}

可以看到，runApplication调用的是runnables对象中注册的闭包。而在我们React Native JS层的Bundle包中，首先就需要调用AppRegistry.registerComponent(appName, () => App)完成最根组件的注册。所以runApplication方法中调用的闭包，就是在registerComponent中注册的闭包。

继续跟踪renderApplication方法的实现，源码react-native/packages/react-native/Libraries/ReactNative/renderApplication.js：

export default function renderApplication<Props: Object>(
  RootComponent: React.ComponentType<Props>,
  initialProps: Props,
  rootTag: any,
  WrapperComponent?: ?React.ComponentType<any>,
  rootViewStyle?: ?ViewStyleProp,
  fabric?: boolean,
  scopedPerformanceLogger?: IPerformanceLogger,
  isLogBox?: boolean,
  debugName?: string,
  displayMode?: ?DisplayModeType,
  useOffscreen?: boolean,
) {

  const performanceLogger = scopedPerformanceLogger ?? GlobalPerformanceLogger;

  // 构建React元素树
  // 外层：PerformanceLoggerContext.Provider - 提供性能监控上下文
  // 中层：AppContainer - React Native的根容器组件
  // 内层：RootComponent - 用户注册的应用组件（如App.js）
  let renderable: React.MixedElement = (
    <PerformanceLoggerContext.Provider value={performanceLogger}>
      <AppContainer
        rootTag={rootTag}
        fabric={fabric}
        WrapperComponent={WrapperComponent}
        rootViewStyle={rootViewStyle}
        initialProps={initialProps ?? Object.freeze({})}
        internal_excludeLogBox={isLogBox}>
        <RootComponent {...initialProps} rootTag={rootTag} />
      </AppContainer>
    </PerformanceLoggerContext.Provider>
  );

  // 开发模式调试包装
  if (__DEV__ && debugName) {
    const RootComponentWithMeaningfulName = getCachedComponentWithDebugName(
      `${debugName}(RootComponent)`,
    );
    renderable = (
      <RootComponentWithMeaningfulName>
        {renderable}
      </RootComponentWithMeaningfulName>
    );
  }

  //  实验性离屏渲染支持
  if (useOffscreen && displayMode != null) {
    // $FlowFixMe[incompatible-type]
    // $FlowFixMe[prop-missing]
    // $FlowFixMe[missing-export]
    const Activity: ActivityType = React.unstable_Activity;

    renderable = (
      <Activity
        mode={displayMode === DisplayMode.VISIBLE ? 'visible' : 'hidden'}>
        {renderable}
      </Activity>
    );
  }

  // 我们希望在使用 Fabric 时始终启用 concurrentRoot 功能
  const useConcurrentRoot = Boolean(fabric);

  // 省略部分性能日志打印......

  // 进入React渲染系统
  Renderer.renderElement({
    element: renderable,
    rootTag,
    useFabric: Boolean(fabric),
    useConcurrentRoot,
  });
}

继续跟踪Renderer.renderElement方法实现。源码react-native/packages/react-native/Libraries/ReactNative/RendererImplementation.js：

export function renderElement({
  element,
  rootTag,
  useFabric,
  useConcurrentRoot,
}: {
  element: React.MixedElement,
  rootTag: number,
  useFabric: boolean,
  useConcurrentRoot: boolean,
}): void {
  if (useFabric) {
    if (cachedFabricRender == null) {
      // 获取实际渲染器
      cachedFabricRender = getFabricRenderer().render;
    }

    cachedFabricRender(element, rootTag, null, useConcurrentRoot, {
      onCaughtError,
      onUncaughtError,
      onRecoverableError,
    });
  } else {
    // 省略旧架构......
  }
}

function getFabricRenderer(): ReactFabricType {
  if (cachedFabricRenderer == null) {
    cachedFabricRenderer = require('../Renderer/shims/ReactFabric').default;
  }
  return cachedFabricRenderer;
}

继续跟踪react-native/packages/react-native/Libraries/Renderer/shims/ReactFabric.js：

import {BatchedBridge} from 'react-native/Libraries/ReactPrivate/ReactNativePrivateInterface';

import type {ReactFabricType} from './ReactNativeTypes';

let ReactFabric: ReactFabricType;

if (__DEV__) {
  ReactFabric = require('../implementations/ReactFabric-dev');
} else {
  ReactFabric = require('../implementations/ReactFabric-prod');
}

global.RN$stopSurface = ReactFabric.stopSurface;

if (global.RN$Bridgeless !== true) {
  BatchedBridge.registerCallableModule('ReactFabric', ReactFabric);
}

export default ReactFabric;

这里根据开发环境选择了不同的渲染器。开发环境的渲染器体积更大，包含了许多调试、性能日志等信息，而生产环境的移除了注释和空白，变量名被压缩代码经过优化，减少包体积。

继续跟踪生产环境的渲染器，因为代码更加简洁，可更好的聚焦于调用的链路和流程。源码react-native/packages/react-native/Libraries/Renderer/implementations/ReactFabric-prod.js：

exports.render = function (
  element,
  containerTag,
  callback,
  concurrentRoot,
  options
) {
  var root = roots.get(containerTag);
  if (!root) {
    // 创建新的FiberRootNode
    // 省略部分代码......

    initializeUpdateQueue(concurrentRoot);
    roots.set(containerTag, root);
  }
  // 启动渲染 
  updateContainer(element, root, null, callback);
  // 返回渲染后的公共实例引用
  a: if (((element = root.current), element.child))
    switch (element.child.tag) {
      case 27:
      case 5:
        element = getPublicInstance(element.child.stateNode);
        break a;
      default:
        element = element.child.stateNode;
    }
  else element = null;
  return element;
};

function updateContainer(element, container, parentComponent, callback) {
  parentComponent = container.current;
  // / 获取更新优先级
  var lane = requestUpdateLane(parentComponent);
  null === container.context
    ? (container.context = emptyContextObject)
    : (container.pendingContext = emptyContextObject);

  // 创建更新对象
  container = createUpdate(lane);
  container.payload = { element: element };
  callback = void 0 === callback ? null : callback;
  null !== callback && (container.callback = callback);

  // 将更新加入队列
  element = enqueueUpdate(parentComponent, container, lane);

  // 调度更新
  null !== element &&
    (scheduleUpdateOnFiber(element, parentComponent, lane),
    entangleTransitions(element, parentComponent, lane));
  return lane;
}

以上调用都比较简单，这里的核心是scheduleUpdateOnFiber方法，它负责调度更新。由于代码量较大，我们后面只追求核心逻辑，将省略大部分代码：

function scheduleUpdateOnFiber(root, fiber, lane) {
  // 省略......

  // 标记更新并触发调度
  markRootUpdated$1(root, lane);
  if (/* 不在渲染中 */) {
      ensureRootIsScheduled(root);                    // 确保根节点被调度
      if (/* 同步更新 */) {
        flushSyncWorkAcrossRoots_impl(0, !0);         // 立即执行同步工作
      }
   }
}


function flushSyncWorkAcrossRoots_impl(syncTransitionLanes, onlyLegacy) {
  if (!isFlushingWork && mightHavePendingSyncWork) {
    isFlushingWork = !0;
    do {
      var didPerformSomeWork = !1;
      // 遍历所有根节点执行同步工作
      for (var root = firstScheduledRoot; null !== root; ) {
        if (!onlyLegacy || 0 === root.tag)
          //省略......
          // 常规同步更新 
          performSyncWorkOnRoot(root, JSCompiler_inline_result));

        root = root.next;
      }
    } while (didPerformSomeWork);
    isFlushingWork = !1;
  }
}


function performSyncWorkOnRoot(root, lanes) {
  if (flushPendingEffects()) return null;
  performWorkOnRoot(root, lanes, !0);
}


function performWorkOnRoot(root$jscomp$0, lanes, forceSync) {
   // 选择同步或并发渲染
   var shouldTimeSlice = (!forceSync && /* 条件判断 */);
   var exitStatus = shouldTimeSlice
      ? renderRootConcurrent(root, lanes)            // 并发渲染
      : renderRootSync(root, lanes, !0);             // 同步渲染

   // 省略......
}

继续追踪同步渲染renderRootSync方法实现：

function renderRootSync(root, lanes, shouldYieldForPrerendering) {
   // 省略......

   // 同步工作循环
   workLoopSync();
   // 省略......
}


function workLoopSync() {
  for (; null !== workInProgress; ) performUnitOfWork(workInProgress);
}


function performUnitOfWork(unitOfWork) {
  // 处理单个Fiber节点
  var next = beginWork(unitOfWork.alternate, unitOfWork, entangledRenderLanes);
  unitOfWork.memoizedProps = unitOfWork.pendingProps;
  null === next ? completeUnitOfWork(unitOfWork) : (workInProgress = next);
}


function completeUnitOfWork(unitOfWork) {
  var completedWork = unitOfWork;
  do {
    // 省略......
    unitOfWork = completedWork.return;
    var next = completeWork(
      completedWork.alternate,
      completedWork,
      entangledRenderLanes
    );
    if (null !== next) {
      workInProgress = next;
      return;
    }
    completedWork = completedWork.sibling;
    if (null !== completedWork) {
      workInProgress = completedWork;
      return;
    }
    workInProgress = completedWork = unitOfWork;
  } while (null !== completedWork);
  0 === workInProgressRootExitStatus && (workInProgressRootExitStatus = 5);
}

最终是调用的completeWork方法完成渲染工作：

function completeWork(current, workInProgress, renderLanes) {
  var newProps = workInProgress.pendingProps;
  switch (workInProgress.tag) {
    case 28:
    case 16:
    case 15:
    case 0:
    case 11:
    case 7:
    case 8:
    case 12:
    case 9:
    case 14:
      return bubbleProperties(workInProgress), null;
    case 1:
      return bubbleProperties(workInProgress), null;
    case 3:
      // 省略......
      // return  
    case 26:
    case 27:
    case 5:
      popHostContext(workInProgress);
      var type = workInProgress.type;
      if (null !== current && null != workInProgress.stateNode)
        // 省略......
      else {
        // 首次挂载
        if (!newProps) {  
          if (null === workInProgress.stateNode)
            throw Error(
              "We must have new props for new mounts. This error is likely caused by a bug in React. Please file an issue."
            );
          bubbleProperties(workInProgress);
          return null;
        }
        current = rootInstanceStackCursor.current;
        renderLanes = nextReactTag;
        nextReactTag += 2;
        // 获取ViewConfig
        type = getViewConfigForType(type);
        var updatePayload = ReactNativePrivateInterface.createAttributePayload(
          newProps,
          type.validAttributes
        );
        // 创建原生节点
        current = {
          node: createNode(
            renderLanes,
            type.uiViewClassName,  //  使用ViewConfig中的原生类名
            current.containerTag,
            updatePayload,
            workInProgress
          ),
          canonical: {
            nativeTag: renderLanes,
            viewConfig: type,       // 保存ViewConfig引用
            currentProps: newProps,
            internalInstanceHandle: workInProgress,
            publicInstance: null,
            publicRootInstance: current.publicInstance
          }
        };
        workInProgress.flags |= 8;
        appendAllChildren(current, workInProgress, !1, !1);
        workInProgress.stateNode = current;
      }
      bubbleProperties(workInProgress);
      workInProgress.flags &= -16777217;
      return null;
    // 省略部分代码......
  }
}

此方法中的case都是整数，为了弄清楚其含义，我们可以查看React 仓库中的Tag定义。源码位于 ReactWorkTags.js：

export const FunctionComponent = 0;
export const ClassComponent = 1;
export const HostRoot = 3; // 宿主树的根节点。它可以嵌套在另一个节点内部
export const HostPortal = 4; // 一个子树。它可以是通往不同渲染器的入口点
export const HostComponent = 5;
// 省略......

很显然，我们需要查看的是React Native的Tag类型，也就是HostComponent，它的值是5，因此对应到completeWork中的处理代码就是我截取的这部分。这段代码中有一个关键的方法，就是getViewConfigForType，查看其定义，显示为getViewConfigForType = ReactNativePrivateInterface.ReactNativeViewConfigRegistry.get

可看到，这里就完全与前面声明组件一节最后分析到的ReactNativeViewConfigRegistry.js对应上了，我们前面分析的是ViewConfig的注册，现在来看一下get方法：

/**
 * 获取指定视图的配置。如果这是第一次使用该视图，此配置将从UIManager延迟加载
 */
export function get(name: string): ViewConfig {
  // 从viewConfigs Map中查找已缓存的ViewConfig
  let viewConfig = viewConfigs.get(name);
  if (viewConfig == null) {
    // 获取该组件的配置生成回调函数
    const callback = viewConfigCallbacks.get(name);
    if (typeof callback !== 'function') {
      // 省略日志......
    }
    viewConfig = callback();
    invariant(viewConfig, 'View config not found for component `%s`', name);

    processEventTypes(viewConfig);
    viewConfigs.set(name, viewConfig);

    // 配置设置后清除回调，这样我们就不会在注册过程中掩盖任何错误。
    viewConfigCallbacks.set(name, null);
  }
  return viewConfig;
}

通过ViewConfig，可以得到uiViewClassName，也就是声明的组件名称，我们继续查看原生节点创建的方法：

var _nativeFabricUIManage = nativeFabricUIManager,
  createNode = _nativeFabricUIManage.createNode,          


 createNode(
   renderLanes,
   type.uiViewClassName,  //  使用ViewConfig中的原生类名
   current.containerTag,
   updatePayload,
   workInProgress
 )

createNode方法来自于全局对象nativeFabricUIManager，通过变量名就知道，这个应该是来自于JSI定义的对象，代码不在JS层。

C++ 层

继续在C++中搜索nativeFabricUIManager，定位到源码react-native/packages/react-native/ReactCommon/react/renderer/uimanager/UIManagerBinding.cpp：

void UIManagerBinding::createAndInstallIfNeeded(
    jsi::Runtime& runtime,
    const std::shared_ptr<UIManager>& uiManager) {
  auto uiManagerModuleName = "nativeFabricUIManager";

  auto uiManagerValue =
      runtime.global().getProperty(runtime, uiManagerModuleName);
  if (uiManagerValue.isUndefined()) {
    // 全局命名空间中没有该绑定的实例；我们需要创建、安装并返回它
    auto uiManagerBinding = std::make_shared<UIManagerBinding>(uiManager);
    auto object = jsi::Object::createFromHostObject(runtime, uiManagerBinding);
    runtime.global().setProperty(
        runtime, uiManagerModuleName, std::move(object));
  }
}

可见这里的nativeFabricUIManager是一个jsi::HostObject对象，我们要查找其createNode方法，直接查看UIManagerBinding的get方法：

jsi::Value UIManagerBinding::get(
    jsi::Runtime& runtime,
    const jsi::PropNameID& name) {
  auto methodName = name.utf8(runtime);

  // 将 shared_ptr<UIManager> 转换为原始指针
  // 为什么这样做？原因如下：
  // 1) UIManagerBinding 强引用（strongly retains）UIManager。
  //    JS VM 通过 JSI 强引用 UIManagerBinding。
  //    这些函数是 JSI 函数，只能通过 JS VM 调用；如果 JS VM 被销毁，
  //    这些函数无法执行，这些 lambda 也不会执行。
  // 2) UIManager 只有在所有对它的引用都被释放后才会被析构，包括
  //    UIManagerBinding。这只有在 JS VM 被析构时才会发生。因此，原始指针是安全的。
  //
  // 即使这样做是安全的，为什么不直接使用 shared_ptr 作为额外的保险呢？
  // 1) 在不需要的情况下使用 shared_ptr 或 weak_ptr
  // 是一种性能劣化（pessimisation）。
  //    在这种情况下，它会执行更多指令，但不会带来任何额外价值。
  // 2) 这些 lambda 的确切释放时机和方式很复杂。向它们添加 shared_ptr 会导致
  //    UIManager 可能存活更长时间，这是不必要的、复杂的认知负担。
  // 3) 有强烈怀疑认为，从这些 C++ lambda 中保留 UIManager（这些 lambda 被
  //    JSI 持有的对象所保留），在 Scheduler 和 JS VM 析构时导致了一些崩溃。
  //    如果 C++ 语义导致这些 lambda 在 JS VM 被析构后一个 CPU
  //    时钟周期（或更久） 才被释放，就可能发生这种情况。
  UIManager* uiManager = uiManager_.get();

  // Semantic: Creates a new node with given pieces.
  if (methodName == "createNode") {
    auto paramCount = 5;
    return jsi::Function::createFromHostFunction(
        runtime,
        name,
        paramCount,
        [uiManager, methodName, paramCount](
            jsi::Runtime& runtime,
            const jsi::Value& /*thisValue*/,
            const jsi::Value* arguments,
            size_t count) -> jsi::Value {
          try {
            validateArgumentCount(runtime, methodName, paramCount, count);

            auto instanceHandle =
                instanceHandleFromValue(runtime, arguments[4], arguments[0]);
            if (!instanceHandle) {
              react_native_assert(false);
              return jsi::Value::undefined();
            }

            return valueFromShadowNode(
                runtime,
                uiManager->createNode(
                    tagFromValue(arguments[0]),
                    stringFromValue(runtime, arguments[1]),
                    surfaceIdFromValue(runtime, arguments[2]),
                    RawProps(runtime, arguments[3]),
                    std::move(instanceHandle)),
                true);
          } catch (const std::logic_error& ex) {
            LOG(FATAL) << "logic_error in createNode: " << ex.what();
          }
        });
  }
  // 省略部分代码......

  return jsi::Value::undefined();
}

继续跟踪react-native/packages/react-native/ReactCommon/react/renderer/uimanager/UIManager.cpp中的createNode实现：

std::shared_ptr<ShadowNode> UIManager::createNode(
    Tag tag,                  // 节点标签
    const std::string& name,  // 组件名称
    SurfaceId surfaceId,
    RawProps rawProps,        // 原始属性
    InstanceHandle::Shared instanceHandle) const {
  TraceSection s("UIManager::createNode", "componentName", name);

  // 根据组件名称获取对应的ComponentDescriptor
  auto& componentDescriptor = componentDescriptorRegistry_->at(name);
  auto fallbackDescriptor =
      componentDescriptorRegistry_->getFallbackComponentDescriptor();

  PropsParserContext propsParserContext{surfaceId, *contextContainer_};

  // 创建ShadowNodeFamily，用于管理同一组件的不同实例
  auto family = componentDescriptor.createFamily(
      {.tag = tag,
       .surfaceId = surfaceId,
       .instanceHandle = std::move(instanceHandle)});

  // 解析和克隆属性
  const auto props = componentDescriptor.cloneProps(
      propsParserContext, nullptr, std::move(rawProps));
  // 创建初始状态
  const auto state = componentDescriptor.createInitialState(props, family);

  // 创建ShadowNode
  auto shadowNode = componentDescriptor.createShadowNode(
      ShadowNodeFragment{
          .props = fallbackDescriptor != nullptr &&
                  fallbackDescriptor->getComponentHandle() ==
                      componentDescriptor.getComponentHandle()
              ? componentDescriptor.cloneProps(
                    propsParserContext,
                    props,
                    RawProps(folly::dynamic::object("name", name)))
              : props,
          .children = ShadowNodeFragment::childrenPlaceholder(),
          .state = state,
      },
      family);

  if (delegate_ != nullptr) {
    delegate_->uiManagerDidCreateShadowNode(*shadowNode);
  }
  if (leakChecker_) {
    leakChecker_->uiManagerDidCreateShadowNodeFamily(family);
  }

  return shadowNode;
}

可以看到，这里通过componentDescriptorRegistry_来查找Fabric 组件描述对象，至于注册的地方，下一节注册组件会专门分析。

这里还有一点要注意，createShadowNode方法只是创建了虚拟的ShadowNode，并没有创建真正的原生视图。ShadowNode是Fabric中的虚拟DOM节点，用于布局计算。也就是说当完成布局和diff计算后，会生成MountItem指令。

Kotlin层

在前面启动渲染一节中，我们有分析到createViewUnsafe方法，回顾一下安卓原生组件的查找：

ViewManager viewManager = mViewManagerRegistry.get(componentName);

跟踪源码react-native/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/uimanager/ViewManagerRegistry.kt：

  @Synchronized
  public fun get(className: String): ViewManager<*, *> {
    // 1. Try to get the manager without the prefix.
    viewManagersMap[className]?.let {
      return it
    }

    // 2. Try to get the manager with the RCT prefix.
    val rctViewManagerName = "RCT$className"
    viewManagersMap[rctViewManagerName]?.let {
      return it
    }

    if (viewManagerResolver != null) {

      // 1. Try to get the manager without the prefix.
      val resolvedManager = getViewManagerFromResolver(className)
      if (resolvedManager != null) {
        return resolvedManager
      }

      // 2. Try to get the manager with the RCT prefix.
      val rctResolvedManager = getViewManagerFromResolver(rctViewManagerName)
      if (rctResolvedManager != null) {
        return rctResolvedManager
      }

      throw IllegalViewOperationException(
          "Can't find ViewManager '$className' nor '$rctViewManagerName' in ViewManagerRegistry, " +
              "existing names are: ${viewManagerResolver.getViewManagerNames()}"
      )
    }

    throw IllegalViewOperationException("No ViewManager found for class $className")
  }

  private fun getViewManagerFromResolver(className: String): ViewManager<*, *>? {
    val viewManager = viewManagerResolver?.getViewManager(className)
    if (viewManager != null) {
      viewManagersMap[className] = viewManager
    }
    return viewManager
  }

新架构的情况下，是通过getViewManagerFromResolver方法来查找，其中viewManagerResolver的类型是BridgelessViewManagerResolver，它是一个内部类，定义在ReactInstance.kt文件中：

private class BridgelessViewManagerResolver(
      private val reactPackages: List<ReactPackage>,
      private val context: BridgelessReactContext,
  ) : ViewManagerResolver {
    private val lazyViewManagerMap: MutableMap<String, ViewManager<*, *>> = HashMap()

    override fun getViewManager(viewManagerName: String): ViewManager<*, *>? {
      // 从懒加载包中查找
      val viewManager = getLazyViewManager(viewManagerName)
      if (viewManager != null) {
        return viewManager
      }
      // 如果通过延迟加载在所有 React 包中都找不到视图管理器，则回退到默认实现：立即初始化所有视图管理器
      return eagerViewManagerMap[viewManagerName]
    }

    private lateinit var _eagerViewManagerMap: Map<String, ViewManager<*, *>>

    @get:Synchronized
    val eagerViewManagerMap: Map<String, ViewManager<*, *>>
      get() {
        if (::_eagerViewManagerMap.isInitialized) {
          return _eagerViewManagerMap
        }

        val viewManagerMap: MutableMap<String, ViewManager<*, *>> = HashMap()
        for (reactPackage in reactPackages) {
          if (reactPackage is ViewManagerOnDemandReactPackage) {
            continue
          }

          val viewManagersInPackage = reactPackage.createViewManagers(context)
          for (viewManager in viewManagersInPackage) {
            // TODO(T173624687): Should we throw/warn when the same view manager name is registered
            // twice?
            viewManagerMap[viewManager.name] = viewManager
          }
        }

        _eagerViewManagerMap = viewManagerMap
        return viewManagerMap
      }

    @Synchronized
    fun getLazyViewManager(viewManagerName: String): ViewManager<*, *>? {
      // 先查缓存 
      if (lazyViewManagerMap.containsKey(viewManagerName)) {
        return lazyViewManagerMap[viewManagerName]
      }

      // 缓存未命中则遍历所有 reactPackages，调用 createViewManager(name) 创建
      for (reactPackage in reactPackages) {
        if (reactPackage is ViewManagerOnDemandReactPackage) {
          val viewManager = reactPackage.createViewManager(context, viewManagerName)
          if (viewManager != null) {
            // TODO(T173624687): Should we throw/warn when the same view manager name is registered
            // twice?
            lazyViewManagerMap[viewManagerName] = viewManager
            return viewManager
          }
        }
      }

      return null
    }

    // 省略部分代码......
  }

注册组件

JS工具

React Native新架构使用了很多代码生成工具，以致于成了黑箱操作，这对于Turbo Module和Fabric组件的注册流程造成了理解上的困难。为此，我们不得不研究这些CLI工具。首先研究@react-native-community/cli工具，源码 cli。这里我们使用的版本是v20.0.2。

查看源码cli/packages/cli-config-android/src/config/index.ts：

export function dependencyConfig(
  root: string,
  userConfig: AndroidDependencyParams | null = {},
): AndroidDependencyConfig | null {
  if (userConfig === null) {
    return null;
  }

  const src = userConfig.sourceDir || findAndroidDir(root);

  if (!src) {
    return null;
  }

  const sourceDir = path.join(root, src);
  const manifestPath = userConfig.manifestPath
    ? path.join(sourceDir, userConfig.manifestPath)
    : findManifest(sourceDir);
  const buildGradlePath = findBuildGradle(sourceDir, '');
  const isPureCxxDependency =
    userConfig.cxxModuleCMakeListsModuleName != null &&
    userConfig.cxxModuleCMakeListsPath != null &&
    userConfig.cxxModuleHeaderName != null &&
    !manifestPath &&
    !buildGradlePath;

  if (!manifestPath && !buildGradlePath && !isPureCxxDependency) {
    return null;
  }

  let packageImportPath = null,
    packageInstance = null;

  if (!isPureCxxDependency) {
    const packageName =
      userConfig.packageName || getPackageName(manifestPath, buildGradlePath);
    const packageClassName = findPackageClassName(sourceDir);

    /**
     * This module has no package to export
     */
    if (!packageClassName) {
      return null;
    }

    packageImportPath =
      userConfig.packageImportPath ||
      `import ${packageName}.${packageClassName};`;

    packageInstance = userConfig.packageInstance || `new ${packageClassName}()`;
  }

  const buildTypes = userConfig.buildTypes || [];
  const dependencyConfiguration = userConfig.dependencyConfiguration;
  const libraryName =
    userConfig.libraryName || findLibraryName(root, sourceDir);
  const componentDescriptors =
    userConfig.componentDescriptors || findComponentDescriptors(root);
  let cmakeListsPath = userConfig.cmakeListsPath
    ? path.join(sourceDir, userConfig.cmakeListsPath)
    : path.join(sourceDir, 'build/generated/source/codegen/jni/CMakeLists.txt');
  const cxxModuleCMakeListsModuleName =
    userConfig.cxxModuleCMakeListsModuleName || null;
  const cxxModuleHeaderName = userConfig.cxxModuleHeaderName || null;
  let cxxModuleCMakeListsPath = userConfig.cxxModuleCMakeListsPath
    ? path.join(sourceDir, userConfig.cxxModuleCMakeListsPath)
    : null;

  if (process.platform === 'win32') {
    cmakeListsPath = cmakeListsPath.replace(/\\/g, '/');
    if (cxxModuleCMakeListsPath) {
      cxxModuleCMakeListsPath = cxxModuleCMakeListsPath.replace(/\\/g, '/');
    }
  }

  return {
    sourceDir,
    packageImportPath,
    packageInstance,
    buildTypes,
    dependencyConfiguration,
    libraryName,
    componentDescriptors,
    cmakeListsPath,
    cxxModuleCMakeListsModuleName,
    cxxModuleCMakeListsPath,
    cxxModuleHeaderName,
    isPureCxxDependency,
  };
}

此dependencyConfig函数非常重要，它主要用于生成example/android/build/generated/autolinking/autolinking.json文件。autolinking.json文件我们在前面的TurboModule的文章已经介绍过了，其中的信息是指导代码生成的关键。这里重点关注componentDescriptors字段的生成，因为它是Fabric组件代码生成的起始。

组件开发者通常并不会在react-native.config.js文件中主动配置componentDescriptors字段，一般都是默认值，那么就要查看一下findComponentDescriptors函数的实现逻辑了，源码cli/packages/cli-config-android/src/config/findComponentDescriptors.ts：

export function findComponentDescriptors(packageRoot: string) {
  let jsSrcsDir = null;
  try {
    const packageJson = fs.readFileSync(
      path.join(packageRoot, 'package.json'),
      'utf8',
    );
    jsSrcsDir = JSON.parse(packageJson).codegenConfig.jsSrcsDir;
  } catch (error) {
    // no jsSrcsDir, continue with default glob pattern
  }
  const globPattern = jsSrcsDir
    ? `${jsSrcsDir}/**/*{.js,.jsx,.ts,.tsx}`
    : '**/*{.js,.jsx,.ts,.tsx}';
  const files = glob.sync(globPattern, {
    cwd: unixifyPaths(packageRoot),
    onlyFiles: true,
    ignore: ['**/node_modules/**'],
  });
  const codegenComponent = files
    .map((filePath) =>
      fs.readFileSync(path.join(packageRoot, filePath), 'utf8'),
    )
    .map(extractComponentDescriptors)
    .filter(Boolean);

  // Filter out duplicates as it happens that libraries contain multiple outputs due to package publishing.
  // TODO: consider using "codegenConfig" to avoid this.
  return Array.from(new Set(codegenComponent as string[]));
}

这里主要逻辑其实是从package.json中获取到jsSrcsDir配置，从而定位到源码所在目录。我们关注的是codegenComponent的生成，此处是通过读取每个源文件内容，然后调用 extractComponentDescriptors 提取组件描述符。继续查看cli/packages/cli-config-android/src/config/extractComponentDescriptors.ts：

const CODEGEN_NATIVE_COMPONENT_REGEX =
  /codegenNativeComponent(<.*>)?\s*\(\s*["'`](\w+)["'`](,?[\s\S]+interfaceOnly:\s*(\w+))?/m;

export function extractComponentDescriptors(contents: string) {
  const match = contents.match(CODEGEN_NATIVE_COMPONENT_REGEX);
  if (!(match?.[4] === 'true') && match?.[2]) {
    return `${match[2]}ComponentDescriptor`;
  }
  return null;
}

到这里就很清楚了，扫描所有源码，使用正则找到我们在声明组件一节中提到的export default codegenNativeComponent<NativeProps>('CustomviewView');这行代码，这里的正则就是匹配关键字codegenNativeComponent。这里的match?.[2]就是提前出组件名，也就是我们示例中的CustomviewView。最终返回的字符串是拼接后的，这里就是CustomviewViewComponentDescriptor。也就是说componentDescriptors字段的默认值是CustomviewViewComponentDescriptor。

接下来我们回顾前文《Android端TurboModule分析》，其中提到但略过的React Gradle脚本的configureCodegen方法：

  private fun configureCodegen(
      project: Project,
      localExtension: ReactExtension,
      rootExtension: PrivateReactExtension,
      isLibrary: Boolean,
  ) {
    // 首先，我们需要设置 Codegen 的输出目录
    val generatedSrcDir: Provider<Directory> =
        project.layout.buildDirectory.dir("generated/source/codegen")

    // 我们为 jsRootDir（JS根目录）指定默认值（约定）。
    // 对于 App 来说是根文件夹（即 Gradle 项目的 ../../）
    // 对于 Library 来说是包文件夹（即 Gradle 项目的 ../）
    if (isLibrary) {
      localExtension.jsRootDir.convention(project.layout.projectDirectory.dir("../"))
    } else {
      localExtension.jsRootDir.convention(localExtension.root)
    }

    // 我们创建任务以从 JS 文件生成 Schema
    val generateCodegenSchemaTask =
        project.tasks.register(
            "generateCodegenSchemaFromJavaScript",
            GenerateCodegenSchemaTask::class.java,
        ) { it ->
          it.nodeExecutableAndArgs.set(rootExtension.nodeExecutableAndArgs)
          it.codegenDir.set(rootExtension.codegenDir)
          it.generatedSrcDir.set(generatedSrcDir)
          it.nodeWorkingDir.set(project.layout.projectDirectory.asFile.absolutePath)

          // 我们在配置阶段读取 package.json，以便正确地填充此任务的 `jsRootDir` @Input 属性
          // 以及 onlyIf 条件。因此，parsePackageJson 应该在这个 lambda 表达式内部被调用。
          val packageJson = findPackageJsonFile(project, rootExtension.root)
          val parsedPackageJson = packageJson?.let { JsonUtils.fromPackageJson(it) }

          val jsSrcsDirInPackageJson = parsedPackageJson?.codegenConfig?.jsSrcsDir
          val includesGeneratedCode =
              parsedPackageJson?.codegenConfig?.includesGeneratedCode ?: false
          if (jsSrcsDirInPackageJson != null) {
            it.jsRootDir.set(File(packageJson.parentFile, jsSrcsDirInPackageJson))
          } else {
            it.jsRootDir.set(localExtension.jsRootDir)
          }
          it.jsInputFiles.set(
              project.fileTree(it.jsRootDir) { tree ->
                tree.include("**/*.js")
                tree.include("**/*.jsx")
                tree.include("**/*.ts")
                tree.include("**/*.tsx")

                tree.exclude("node_modules/**/*")
                tree.exclude("**/*.d.ts")
                // 我们希望排除 build 目录，以避免在执行规避检查时选中它们
                tree.exclude("**/build/**/*")
              }
          )

          val needsCodegenFromPackageJson = project.needsCodegenFromPackageJson(rootExtension.root)
          it.onlyIf { (isLibrary || needsCodegenFromPackageJson) && !includesGeneratedCode }
        }

    // 我们创建任务以从 Schema 生成 Java 代码
    val generateCodegenArtifactsTask =
        project.tasks.register(
            "generateCodegenArtifactsFromSchema",
            GenerateCodegenArtifactsTask::class.java,
        ) { task ->
          task.dependsOn(generateCodegenSchemaTask)
          task.reactNativeDir.set(rootExtension.reactNativeDir)
          task.nodeExecutableAndArgs.set(rootExtension.nodeExecutableAndArgs)
          task.generatedSrcDir.set(generatedSrcDir)
          task.packageJsonFile.set(findPackageJsonFile(project, rootExtension.root))
          task.codegenJavaPackageName.set(localExtension.codegenJavaPackageName)
          task.libraryName.set(localExtension.libraryName)
          task.nodeWorkingDir.set(project.layout.projectDirectory.asFile.absolutePath)

          // 请注意，appNeedsCodegen 会触发在配置阶段读取 package.json，
          // 因为我们需要填充此任务的 onlyIf 条件。
          // 因此，appNeedsCodegen 需要在这个 lambda 表达式内部被调用
          val needsCodegenFromPackageJson = project.needsCodegenFromPackageJson(rootExtension.root)
          val packageJson = findPackageJsonFile(project, rootExtension.root)
          val parsedPackageJson = packageJson?.let { JsonUtils.fromPackageJson(it) }
          val includesGeneratedCode =
              parsedPackageJson?.codegenConfig?.includesGeneratedCode ?: false
          task.onlyIf { (isLibrary || needsCodegenFromPackageJson) && !includesGeneratedCode }
        }

    // 我们更新 Android 配置以包含生成的源码
    // 这相当于以下的 DSL：
    //
    // android { sourceSets { main { java { srcDirs += "$generatedSrcDir/java" } } } }
    if (isLibrary) {
      project.extensions.getByType(LibraryAndroidComponentsExtension::class.java).finalizeDsl { ext
        ->
        ext.sourceSets.getByName("main").java.srcDir(generatedSrcDir.get().dir("java").asFile)
      }
    } else {
      project.extensions.getByType(ApplicationAndroidComponentsExtension::class.java).finalizeDsl {
          ext ->
        ext.sourceSets.getByName("main").java.srcDir(generatedSrcDir.get().dir("java").asFile)
      }
    }

    // `preBuild` 是 AGP 自动注册的基础任务之一
    // 这将在编译整个项目之前调用 Codegen
    project.tasks.named("preBuild", Task::class.java).dependsOn(generateCodegenArtifactsTask)
  }

configureCodegen 是 React Native Gradle 插件的核心方法，负责配置 Fabric/TurboModule 新架构的代码生成（Codegen）流程。该方法在 Gradle 配置阶段执行，设置两个关键任务和 Android 源码集集成。

其流程可以分为五个阶段：

1. 设置输出目录和 JS 根目录

2. 创建 Schema 生成任务

3. 创建代码生成任务

4. 集成到 Android 构建系统

5. 挂载到构建生命周期

这里概括一下整个流程：

1. Gradle 配置阶段
   ├─> 设置 generatedSrcDir = "build/generated/source/codegen"
   ├─> 设置 jsRootDir 默认值（Library: "../", App: root）
   ├─> 读取 package.json（配置阶段）
   │   ├─> 检查 codegenConfig.jsSrcsDir
   │   └─> 检查 codegenConfig.includesGeneratedCode
   ├─> 注册 generateCodegenSchemaTask
   │   ├─> 配置 Node.js 环境
   │   ├─> 设置 JS 输入文件（**/*.{js,jsx,ts,tsx}）
   │   └─> 设置 onlyIf 条件
   ├─> 注册 generateCodegenArtifactsTask
   │   ├─> 依赖 generateCodegenSchemaTask
   │   └─> 设置 onlyIf 条件
   ├─> 配置 Android SourceSets
   │   └─> 添加 generatedSrcDir/java 到 main SourceSet
   └─> 建立 preBuild 依赖关系

2. Gradle 执行阶段（运行 ./gradlew build）
   ├─> preBuild 任务执行
   │   └─> generateCodegenArtifactsTask 执行
   │         ├─> generateCodegenSchemaTask 执行
   │         │     ├─> 扫描 JS/TS 文件
   │         │     └─> 生成 schema.json
   │         └─> 根据 schema.json 生成 Java/C++ 代码
   └─> compileJava 编译生成的代码

这里的两个关键任务分别是generateCodegenSchemaFromJavaScript和generateCodegenArtifactsFromSchema。前者从 JS/TS 生成 Schema JSON文件，后者从 Schema 生成 Java/C++ 代码。

Schema JSON主要是JS/TS的接口描述，生成路径是Your Project/node_modules/Third-party Lib/android/build/generated/source/codegen/schema.json，可以自行查看，这里我们重点关注generateCodegenArtifactsFromSchema，源码react-native/packages/gradle-plugin/react-native-gradle-plugin/src/main/kotlin/com/facebook/react/tasks/GenerateCodegenArtifactsTask.kt：

abstract class GenerateCodegenArtifactsTask : Exec() {
  @get:Internal abstract val reactNativeDir: DirectoryProperty
  @get:Internal abstract val generatedSrcDir: DirectoryProperty
  @get:InputFile abstract val packageJsonFile: RegularFileProperty   // package.json 文件路径
  @get:Input abstract val nodeWorkingDir: Property<String>
  @get:Input abstract val nodeExecutableAndArgs: ListProperty<String>
  @get:Input abstract val codegenJavaPackageName: Property<String>
  @get:Input abstract val libraryName: Property<String>

  @get:InputFile
  val generatedSchemaFile: Provider<RegularFile> = generatedSrcDir.file("schema.json")

  @get:OutputDirectory val generatedJavaFiles: Provider<Directory> = generatedSrcDir.dir("java")
  @get:OutputDirectory val generatedJniFiles: Provider<Directory> = generatedSrcDir.dir("jni")

  override fun exec() {
    val (resolvedLibraryName, resolvedCodegenJavaPackageName) = resolveTaskParameters()
    setupCommandLine(resolvedLibraryName, resolvedCodegenJavaPackageName)
    super.exec()
  }

  internal fun resolveTaskParameters(): Pair<String, String> {
    val parsedPackageJson =
        if (packageJsonFile.isPresent && packageJsonFile.get().asFile.exists()) {
          JsonUtils.fromPackageJson(packageJsonFile.get().asFile)
        } else {
          null
        }
    val resolvedLibraryName = parsedPackageJson?.codegenConfig?.name ?: libraryName.get()
    val resolvedCodegenJavaPackageName =
        parsedPackageJson?.codegenConfig?.android?.javaPackageName ?: codegenJavaPackageName.get()
    return resolvedLibraryName to resolvedCodegenJavaPackageName
  }

  internal fun setupCommandLine(libraryName: String, codegenJavaPackageName: String) {
    val workingDir = File(nodeWorkingDir.get())
    commandLine(
        windowsAwareCommandLine(
            *nodeExecutableAndArgs.get().toTypedArray(),
            reactNativeDir.file("scripts/generate-specs-cli.js").get().asFile.cliPath(workingDir),
            "--platform",
            "android",
            "--schemaPath",
            generatedSchemaFile.get().asFile.cliPath(workingDir),
            "--outputDir",
            generatedSrcDir.get().asFile.cliPath(workingDir),
            "--libraryName",
            libraryName,
            "--javaPackageName",
            codegenJavaPackageName,
        )
    )
  }
}

该类主要用于执行外部 Node.js 命令，依据 schema.json文件，生成 Java/JNI 代码。需要注意一下，这里libraryName和codegenJavaPackageName的取值，代码中是通过resolveTaskParameters方法提取出来的。回顾一下package.json文件的配置，大概是以下结构：

{
  "codegenConfig": {
    "name": "MyLibrary",
    "android": {
      "javaPackageName": "com.example.mylibrary"
    }
  }
}

那么libraryName就是"MyLibrary"，codegenJavaPackageName就是"com.example.mylibrary"。

现在再还原一下命令，其实就是以下形式：

node <reactNativeDir>/scripts/generate-specs-cli.js \
  --platform android \
  --schemaPath <generatedSrcDir>/schema.json \
  --outputDir <generatedSrcDir> \
  --libraryName <resolvedLibraryName> \
  --javaPackageName <resolvedCodegenJavaPackageName>

我们定位到该js文件react-native/packages/react-native/scripts/generate-specs-cli.js：

const executor = require('./codegen/generate-specs-cli-executor');
// 省略......

function main() {
  executor.execute(
    // $FlowFixMe[prop-missing]
    argv.platform,
    // $FlowFixMe[prop-missing]
    argv.schemaPath,
    // $FlowFixMe[prop-missing]
    argv.outputDir,
    // $FlowFixMe[prop-missing]
    argv.libraryName,
    // $FlowFixMe[prop-missing]
    argv.javaPackageName,
    // $FlowFixMe[prop-missing]
    argv.libraryType,
  );
}

main();

继续跟踪react-native/packages/react-native/scripts/codegen/generate-specs-cli-executor.js

const utils = require('./codegen-utils');

const GENERATORS /*: {[string]: {[string]: $ReadOnlyArray<string>}} */ = {
  all: {
    android: ['componentsAndroid', 'modulesAndroid', 'modulesCxx'],
    ios: ['componentsIOS', 'modulesIOS', 'modulesCxx'],
  },
  components: {
    android: ['componentsAndroid'],
    ios: ['componentsIOS'],
  },
  modules: {
    android: ['modulesAndroid', 'modulesCxx'],
    ios: ['modulesIOS', 'modulesCxx'],
  },
};

function generateSpecFromInMemorySchema(
  platform /*: string */,
  schema /*: string */,
  outputDirectory /*: string */,
  libraryName /*: string */,
  packageName /*: string */,
  libraryType /*: string */,
  useLocalIncludePaths /*: boolean */,
) {
  validateLibraryType(libraryType);
  createOutputDirectoryIfNeeded(outputDirectory, libraryName);
  const includeGetDebugPropsImplementation =
    libraryName.includes('FBReactNativeSpec'); //only generate getDebugString for React Native Core Components
  utils.getCodegen().generate(
    {
      libraryName,
      schema,
      outputDirectory,
      packageName,
      assumeNonnull: platform === 'ios',
      useLocalIncludePaths,
      includeGetDebugPropsImplementation,
    },
    {
      generators: GENERATORS[libraryType][platform],
    },
  );

  if (platform === 'android') {
    // Move all components C++ files to a structured jni folder for now.
    // Note: this should've been done by RNCodegen's generators, but:
    // * the generators don't support platform option yet
    // * this subdir structure is Android-only, not applicable to iOS
    const files = fs.readdirSync(outputDirectory);
    const jniOutputDirectory = `${outputDirectory}/jni/react/renderer/components/${libraryName}`;
    fs.mkdirSync(jniOutputDirectory, {recursive: true});
    files
      .filter(f => f.endsWith('.h') || f.endsWith('.cpp'))
      .forEach(f => {
        fs.renameSync(`${outputDirectory}/${f}`, `${jniOutputDirectory}/${f}`);
      });
  }
}

这里核心是调用utils.getCodegen().generate来执行代码生成逻辑，但是这里有一个传参需要注意一下，generators: GENERATORS[libraryType][platform],我们观察GENERATORS的定义就会发现，这里的参数配置正好对应package.json中的codegen配置，由于我们现在研究的是Fabric组件注册，那么这里的参数应该是componentsAndroid。

继续查找generate方法的实现，源码react-native/packages/react-native/scripts/codegen/codegen-utils.js：

/**
* 用于抽象实际代码生成过程的包装器。 
* 之所以需要这个包装器，是因为在 Sandcastle 中运行测试时，并非所有环境都像通常那样设置。 
* 例如，`@react-native/codegen` 库就不存在。 
*
* 借助这个包装器，我们可以模拟代码生成器的 getter 方法，使其返回一个自定义对象，该对象模拟了 Codegen 接口。 
*
* @return 一个可以为新架构生成代码的对象。 
*/
function getCodegen() /*: $FlowFixMe */ {
  let RNCodegen;
  try {
    // $FlowFixMe[cannot-resolve-module]
    RNCodegen = require('../../packages/react-native-codegen/lib/generators/RNCodegen.js');
  } catch (e) {
    // $FlowFixMe[cannot-resolve-module]
    RNCodegen = require('@react-native/codegen/lib/generators/RNCodegen.js');
  }
  if (!RNCodegen) {
    throw new Error('RNCodegen not found.');
  }
  return RNCodegen;
}

继续跟踪react-native/packages/react-native-codegen/lib/generators/RNCodegen.js：

const LIBRARY_GENERATORS = {
  descriptors: [
    generateComponentDescriptorCpp.generate,
    generateComponentDescriptorH.generate,
  ],
  events: [generateEventEmitterCpp.generate, generateEventEmitterH.generate],
  states: [generateStateCpp.generate, generateStateH.generate],
  props: [
    generateComponentHObjCpp.generate,
    generatePropsCpp.generate,
    generatePropsH.generate,
    generatePropsJavaInterface.generate,
    generatePropsJavaDelegate.generate,
  ],
  // TODO: Refactor this to consolidate various C++ output variation instead of forking per platform.
  componentsAndroid: [
    // JNI/C++ files
    generateComponentDescriptorH.generate,
    generateComponentDescriptorCpp.generate,
    generateEventEmitterCpp.generate,
    generateEventEmitterH.generate,
    generatePropsCpp.generate,
    generatePropsH.generate,
    generateStateCpp.generate,
    generateStateH.generate,
    generateShadowNodeCpp.generate,
    generateShadowNodeH.generate,
    // Java files
    generatePropsJavaInterface.generate,
    generatePropsJavaDelegate.generate,
  ],
  componentsIOS: [
    generateComponentDescriptorH.generate,
    generateComponentDescriptorCpp.generate,
    generateEventEmitterCpp.generate,
    generateEventEmitterH.generate,
    generateComponentHObjCpp.generate,
    generatePropsCpp.generate,
    generatePropsH.generate,
    generateStateCpp.generate,
    generateStateH.generate,
    generateShadowNodeCpp.generate,
    generateShadowNodeH.generate,
  ],
  modulesAndroid: [
    generateModuleJniCpp.generate,
    generateModuleJniH.generate,
    generateModuleJavaSpec.generate,
  ],
  modulesCxx: [generateModuleH.generate],
  modulesIOS: [generateModuleObjCpp.generate],
  tests: [generateTests.generate],
  'shadow-nodes': [
    generateShadowNodeCpp.generate,
    generateShadowNodeH.generate,
  ],
};


module.exports = {
  allGenerators: ALL_GENERATORS,
  generate(
    {
      libraryName,
      schema,
      outputDirectory,
      packageName,
      assumeNonnull,
      useLocalIncludePaths,
      includeGetDebugPropsImplementation = false,
      libraryGenerators = LIBRARY_GENERATORS,
    },
    {generators, test},
  ) {
    schemaValidator.validate(schema);
    const defaultHeaderPrefix = 'react/renderer/components';
    const headerPrefix =
      useLocalIncludePaths === true
        ? ''
        : `${defaultHeaderPrefix}/${libraryName}/`;
    function composePath(intermediate) {
      return path.join(outputDirectory, intermediate, libraryName);
    }
    const componentIOSOutput = composePath(
      useLocalIncludePaths === true ? '' : defaultHeaderPrefix,
    );
    const modulesIOSOutput = composePath('./');
    const outputFoldersForGenerators = {
      componentsIOS: componentIOSOutput,
      modulesIOS: modulesIOSOutput,
      descriptors: outputDirectory,
      events: outputDirectory,
      props: outputDirectory,
      states: outputDirectory,
      componentsAndroid: outputDirectory,
      modulesAndroid: outputDirectory,
      modulesCxx: outputDirectory,
      tests: outputDirectory,
      'shadow-nodes': outputDirectory,
    };
    const generatedFiles = [];
    for (const name of generators) {
      for (const generator of libraryGenerators[name]) {
        generator(
          libraryName,
          schema,
          packageName,
          assumeNonnull,
          headerPrefix,
          includeGetDebugPropsImplementation,
        ).forEach((contents, fileName) => {
          generatedFiles.push({
            name: fileName,
            content: contents,
            outputDir: outputFoldersForGenerators[name],
          });
        });
      }
    }
    return checkOrWriteFiles(generatedFiles, test);
  },
  // 省略......
};

可以看到，这里for (const name of generators)遍历的generators就是我们前面强调过的GENERATORS参数处理。那么此时name的值就是componentsAndroid。

既然确定了参数，那么从libraryGenerators中遍历出来的generator就是以下这些生成器：

  componentsAndroid: [
    // JNI/C++ files
    generateComponentDescriptorH.generate,
    generateComponentDescriptorCpp.generate,
    generateEventEmitterCpp.generate,
    generateEventEmitterH.generate,
    generatePropsCpp.generate,
    generatePropsH.generate,
    generateStateCpp.generate,
    generateStateH.generate,
    generateShadowNodeCpp.generate,
    generateShadowNodeH.generate,
    // Java files
    generatePropsJavaInterface.generate,
    generatePropsJavaDelegate.generate,
  ],

这里先研究一下generateComponentDescriptorH.generate和generateComponentDescriptorCpp.generate。

源码react-native/packages/react-native-codegen/src/generators/components/GenerateComponentDescriptorH.js：

const FileTemplate = ({
  libraryName,
  componentDefinitions,
  headerPrefix,
}: {
  libraryName: string,
  componentDefinitions: string,
  headerPrefix: string,
}) => `
/**
 * This code was generated by [react-native-codegen](https://www.npmjs.com/package/react-native-codegen).
 *
 * Do not edit this file as changes may cause incorrect behavior and will be lost
 * once the code is regenerated.
 *
 * ${'@'}generated by codegen project: GenerateComponentDescriptorH.js
 */

#pragma once

${IncludeTemplate({headerPrefix, file: 'ShadowNodes.h'})}
#include <react/renderer/core/ConcreteComponentDescriptor.h>
#include <react/renderer/componentregistry/ComponentDescriptorProviderRegistry.h>

namespace facebook::react {

${componentDefinitions}

void ${libraryName}_registerComponentDescriptorsFromCodegen(
  std::shared_ptr<const ComponentDescriptorProviderRegistry> registry);

} // namespace facebook::react
`;

const ComponentDefinitionTemplate = ({className}: {className: string}) =>
  `
using ${className}ComponentDescriptor = ConcreteComponentDescriptor<${className}ShadowNode>;
`.trim();

// 省略部分代码......

这里我们只简单看一下用于头文件生成的字符串模版。libraryName参数取值我们上面已经分析过了，来自package.json中的配置项。那么还有一个关键参数className的取值需要弄清楚。实际上这里的componentDefinitions和className都来自于schema.json。具体看一下className生成逻辑：

    const componentDefinitions = Object.keys(schema.modules)
      .map(moduleName => {
        const module = schema.modules[moduleName];
        if (module.type !== 'Component') {
          return;
        }

        const {components} = module;
        // No components in this module
        if (components == null) {
          return null;
        }

        return Object.keys(components)
          .map(componentName => {
            if (components[componentName].interfaceOnly === true) {
              return;
            }

            return ComponentDefinitionTemplate({className: componentName});
          })
          .join('\n');
      })
      .filter(Boolean)
      .join('\n');

    const replacedTemplate = FileTemplate({
      libraryName,
      componentDefinitions,
      headerPrefix: headerPrefix ?? '',
    });

可以看到，实际上是在遍历schema.json中的components字段。在声明组件一节已经创建了Demo工程，现在构建项目生成schema.json，查看相关内容：

{
  "libraryName": "",
  "modules": {
    "CustomWebView": {
      "type": "Component",
      "components": {
        "CustomWebView": {
          "extendsProps": [
            {
              "type": "ReactNativeBuiltInType",
              "knownTypeName": "ReactNativeCoreViewProps"
            }
          ],
          "events": [省略......],
          "props": [省略......],
          "commands": []
        }
      }
    }
  }
}

那么className就是componentName，也就是自定义的组件名CustomWebView。

C++ 层

弄清楚代码生成的逻辑之后，接下来我们可以直接查看生成的文件内容，主要是ComponentDescriptors.h

#pragma once

#include <react/renderer/components/CustomviewViewSpec/ShadowNodes.h>
#include <react/renderer/core/ConcreteComponentDescriptor.h>
#include <react/renderer/componentregistry/ComponentDescriptorProviderRegistry.h>

namespace facebook::react {

using CustomWebViewComponentDescriptor = ConcreteComponentDescriptor<CustomWebViewShadowNode>;

void CustomviewViewSpec_registerComponentDescriptorsFromCodegen(
  std::shared_ptr<const ComponentDescriptorProviderRegistry> registry);
}

ComponentDescriptors.cpp

#include <react/renderer/components/CustomviewViewSpec/ComponentDescriptors.h>
#include <react/renderer/core/ConcreteComponentDescriptor.h>
#include <react/renderer/componentregistry/ComponentDescriptorProviderRegistry.h>

namespace facebook::react {

void CustomviewViewSpec_registerComponentDescriptorsFromCodegen(
  std::shared_ptr<const ComponentDescriptorProviderRegistry> registry) {
registry->add(concreteComponentDescriptorProvider<CustomWebViewComponentDescriptor>());
}

}

头文件定义了一个类型别名CustomWebViewComponentDescriptor，然后在实现文件中注册了这个Provider。我们看一下concreteComponentDescriptorProvider函数的实现，源码react-native/packages/react-native/ReactCommon/react/renderer/componentregistry/ComponentDescriptorProvider.h:

/*
* 为给定的 `ComponentDescriptor` 类创建一个 `ComponentDescriptorProvider`
*/
template <typename ComponentDescriptorT>
ComponentDescriptorProvider concreteComponentDescriptorProvider()
{
  static_assert(
      std::is_base_of<ComponentDescriptor, ComponentDescriptorT>::value,
      "ComponentDescriptorT must be a descendant of ComponentDescriptor");

  return {
      ComponentDescriptorT::ConcreteShadowNode::Handle(),
      ComponentDescriptorT::ConcreteShadowNode::Name(),
      nullptr,
      &concreteComponentDescriptorConstructor<ComponentDescriptorT>};
}

返回值是一个ComponentDescriptorProvider类型实例，继续跟踪一下类定义：

/*
 * 提供了一种统一的方式来构造特定存储的 `ComponentDescriptor` 类的实例。 
 * C++ 不允许创建指向构造函数的指针，因此我们必须使用这样的数据结构来操作一组类。
 *
 * 注意：某些组件的 `handle` 和 `name` 的实际值取决于 `flavor`。 
 * 如果使用给定的 `flavor` 通过 `constructor` 对象实例化后，
 * Provider暴露的 `handle` 和 `name` 值与预期值相同，则该提供者有效。 
 */
class ComponentDescriptorProvider final {
 public:
  ComponentHandle handle;
  ComponentName name;
  ComponentDescriptor::Flavor flavor;
  ComponentDescriptorConstructor *constructor;
};

这里大量使用了C++模版，要想查看真正的handle和name值，需要当实际的模版类型中查找。这里先查看源码react-native/packages/react-native/ReactCommon/react/renderer/core/ConcreteComponentDescriptor.h：

namespace facebook::react {

/*
 * Default template-based implementation of ComponentDescriptor.
 * Use your `ShadowNode` type as a template argument and override any methods
 * if necessary.
 */
template <typename ShadowNodeT>
class ConcreteComponentDescriptor : public ComponentDescriptor {
  static_assert(std::is_base_of<ShadowNode, ShadowNodeT>::value, "ShadowNodeT must be a descendant of ShadowNode");

  using SharedShadowNodeT = std::shared_ptr<const ShadowNodeT>;

 public:
  using ConcreteShadowNode = ShadowNodeT;

  // 省略代码......
} // namespace facebook::react

可以看到，ConcreteShadowNode实际上只是一个类型别名，具体的要看模版的实际参数，那么ConcreteShadowNode::Handle就相当于CustomWebViewShadowNode::Handle。这里CustomWebViewShadowNode也是自动生成的代码，我们直接查看android/app/build/generated/source/codegen/jni/react/renderer/components/CustomviewViewSpec/ShadowNodes.h：

/*
 * `ShadowNode` for <CustomWebView> component.
 */
using CustomWebViewShadowNode = ConcreteViewShadowNode<
    CustomWebViewComponentName,
    CustomWebViewProps,
    CustomWebViewEventEmitter,
    CustomWebViewState>;

继续查看android/app/build/generated/source/codegen/jni/react/renderer/components/CustomviewViewSpec/ShadowNodes.cpp：

#include <react/renderer/components/CustomviewViewSpec/ShadowNodes.h>

namespace facebook::react {

extern const char CustomWebViewComponentName[] = "CustomWebView";

} 

现在跟踪一下react-native/packages/react-native/ReactCommon/react/renderer/components/view/ConcreteViewShadowNode.h：

namespace facebook::react {

/*
 * Template for all <View>-like classes (classes which have all same props
 * as <View> and similar basic behaviour).
 * For example: <Paragraph>, <Image>, but not <Text>, <RawText>.
 */
template <
    const char *concreteComponentName,
    typename ViewPropsT = ViewProps,
    typename ViewEventEmitterT = ViewEventEmitter,
    typename StateDataT = StateData>
  requires(std::is_base_of_v<ViewProps, ViewPropsT>)
class ConcreteViewShadowNode : public ConcreteShadowNode<
                                   concreteComponentName,
                                   YogaLayoutableShadowNode,
                                   ViewPropsT,
                                   ViewEventEmitterT,
                                   StateDataT> {
  // 省略代码......
};

} // namespace facebook::react

ConcreteViewShadowNode类中并未实现Handle和Name方法，继续查看父类react-native/packages/react-native/ReactCommon/react/renderer/core/ConcreteShadowNode.h

namespace facebook::react {

/*
 * Base templace class for all `ShadowNode`s which connects exact `ShadowNode`
 * type with exact `Props` type.
 * `ConcreteShadowNode` is a default implementation of `ShadowNode` interface
 * with many handy features.
 */
template <
    ComponentName concreteComponentName,
    typename BaseShadowNodeT,
    typename PropsT,
    typename EventEmitterT = EventEmitter,
    typename StateDataT = StateData>
class ConcreteShadowNode : public BaseShadowNodeT {

 protected:
  using ShadowNode::props_;
  using ShadowNode::state_;

 public:
  using BaseShadowNodeT::BaseShadowNodeT;
  // 省略......

  static ComponentName Name()
  {
    return ComponentName(concreteComponentName);
  }

  static ComponentHandle Handle()
  {
    return ComponentHandle(concreteComponentName);
  }

  // 省略......
};

} // namespace facebook::react

到这里就很清晰了，Name和Handle方法返回值内部是持有的相同的concreteComponentName，而这个模版参数，根据前面的传参，实际是就是

CustomWebViewComponentName，也就是"CustomWebView"。

扫描Fabric 组件库，生成代码的逻辑其实已经很清楚了，最后只剩下一个问题，真正调用注册的代码在哪里？事实上，安卓中并未真正通过CustomviewViewSpec_registerComponentDescriptorsFromCodegen函数去注册，而是使用了autolinking机制。这部分在《Android端TurboModule分析》一文有详细介绍了，可以去回顾一下GenerateAutolinkingNewArchitecturesFileTask脚本的分析，其中生成的信息源就来自我们前面费了半天劲分析的autolinking.json中的

现在来看一下Gradle脚本生成的autolinking.cpp：

#include "autolinking.h"
#include <CustomviewViewSpec.h>
#include <react/renderer/components/CustomviewViewSpec/ComponentDescriptors.h>

namespace facebook {
namespace react {

std::shared_ptr<TurboModule> autolinking_ModuleProvider(const std::string moduleName, const JavaTurboModule::InitParams &params) {
auto module_CustomviewViewSpec = CustomviewViewSpec_ModuleProvider(moduleName, params);
if (module_CustomviewViewSpec != nullptr) {
return module_CustomviewViewSpec;
}
  return nullptr;
}

std::shared_ptr<TurboModule> autolinking_cxxModuleProvider(const std::string moduleName, const std::shared_ptr<CallInvoker>& jsInvoker) {

  return nullptr;
}

void autolinking_registerProviders(std::shared_ptr<ComponentDescriptorProviderRegistry const> providerRegistry) {
providerRegistry->add(concreteComponentDescriptorProvider<CustomWebViewComponentDescriptor>());
  return;
}

} // namespace react
} // namespace facebook

这里生成了autolinking_registerProviders方法，这才是真正注册组件的地方。而此处的代码是由Gradle脚本生成，其中的关键信息就来自autolinking.json中的componentDescriptors字段，也就是前面我们费了半天劲才分析出该字段的默认值的地方。整个React Native的代码生成其实是有些混乱的，会生成一些并不会使用的代码，对理解产生干扰。

关于autolinking_registerProviders函数的调用链，在前面的文章也分析涉及过，这里再回顾一下调用流程，源码react-native/packages/react-native/ReactAndroid/cmake-utils/default-app-setup/OnLoad.cpp：

namespace facebook::react {

void registerComponents(
    std::shared_ptr<const ComponentDescriptorProviderRegistry> registry) {
  // 自定义 Fabric 组件放在这里。您可以在此处注册来自您的应用程序或第三方库的自定义组件
  // providerRegistry->add(concreteComponentDescriptorProvider<
  //        MyComponentDescriptor>());

  // We link app local components if available
#ifdef REACT_NATIVE_APP_COMPONENT_REGISTRATION
  REACT_NATIVE_APP_COMPONENT_REGISTRATION(registry);
#endif

  // And we fallback to the components autolinked
  autolinking_registerProviders(registry);
}

// 省略部分代码......

} // namespace facebook::react

JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM* vm, void*) {
  return facebook::jni::initialize(vm, [] {
    facebook::react::DefaultTurboModuleManagerDelegate::cxxModuleProvider =
        &facebook::react::cxxModuleProvider;
    facebook::react::DefaultTurboModuleManagerDelegate::javaModuleProvider =
        &facebook::react::javaModuleProvider;
    facebook::react::DefaultComponentsRegistry::
        registerComponentDescriptorsFromEntryPoint =
            &facebook::react::registerComponents;
  });
}

可见，注册的起点也是JNI_OnLoad函数。

Kotlin层

使用npx create-react-native-library@latest工具创建一个Fabric组件库时，会生成一些模版代码，其中包括我们上面提到的CustomWebViewManager类，现在我们来看一下CustomWebViewPackage类：

class CustomWebViewPackage : ReactPackage {
  override fun createViewManagers(reactContext: ReactApplicationContext): List<ViewManager<*, *>> {
    val viewManagers: MutableList<ViewManager<*, *>> = ArrayList()
    viewManagers.add(CustomWebViewManager())
    return viewManagers
  }

  override fun createNativeModules(reactContext: ReactApplicationContext): List<NativeModule> {
    return emptyList()
  }
}

这里createViewManagers方法会返回一个ViewManager的实例列表。根据我们在《ReactNative新架构之Android端TurboModule机制完全解析》一文中分析GeneratePackageListTask任务的结果，我们知道最终会生成一个PackageList文件，其中会注入每个三方TurboModule或Fabric组件包中的ReactPackage实现类。

现在来查看一下我们示例工程生成的example/android/app/build/generated/autolinking/src/main/java/com/facebook/react/PackageList.java文件：

public class PackageList {
  private Application application;
  private ReactNativeHost reactNativeHost;
  private MainPackageConfig mConfig;

  // 省略部分代码......

  public ArrayList<ReactPackage> getPackages() {
    return new ArrayList<>(Arrays.<ReactPackage>asList(
      new MainReactPackage(mConfig),
      new CustomWebViewPackage()
    ));
  }
}

回顾一下本文开头的初始化部分，我们提到过以下代码

fabricUIManager =
    FabricUIManager(context, ViewManagerRegistry(viewManagerResolver), eventBeatManager)

现在回顾一下《React Native新架构之Android端初始化源码分析》一文，在ReactInstance类构造时，有如下初始化逻辑：

    viewManagerResolver = BridgelessViewManagerResolver(reactPackages, context)

    ComponentNameResolverBinding.install(
        unbufferedRuntimeExecutor,
        object : ComponentNameResolver {
          override val componentNames: Array<String>
            get() {
              val viewManagerNames = viewManagerResolver.getViewManagerNames()
              if (viewManagerNames.isEmpty()) {
                FLog.e(TAG, "No ViewManager names found")
                return arrayOf()
              }
              return viewManagerNames.toTypedArray<String>()
            }
        },
    )

结合上一节查找组件 kotlin层实现的分析，整个流程都十分清晰了。

大家好，我是前端架构师，关注微信公众号【@程序员大卫】免费领取前端精品资料。

前言

有时候在调试老项目时，仍然需要使用 IE11 浏览器。但在 Windows 11 中，直接打开 IE 时，系统通常会自动跳转到 Microsoft Edge，导致无法真正进入 IE11。

下面教你一种简单、有效的方法，在 Win11 中直接打开 IE11。

1. 搜索并打开 cmd

在开始菜单中搜索 cmd，然后点击打开。

2. 粘贴并执行下面的脚本

将以下命令粘贴到 cmd 中并回车执行：

powershell -command "$pf86=[Environment]::GetFolderPath('ProgramFilesX86');$s=New-Object -ComObject WScript.Shell;$sc=$s.CreateShortcut(\"$env:USERPROFILE\Desktop\Internet Explorer.lnk\");$sc.TargetPath=\"$pf86\Internet Explorer\iexplore.exe\";$sc.Arguments='about:blank -Embedding';$sc.IconLocation=\"$pf86\Internet Explorer\iexplore.exe, 0\";$sc.Save()"

这段脚本会在桌面创建一个 IE 浏览器的快捷方式。

3. 双击桌面的 IE 图标即可打开

执行完成后，桌面会出现一个 Internet Explorer 图标，双击它即可成功打开 IE11 浏览器。

React Native之Android端Fabric 架构源码分析（上）

前言

Fabric 是 React Native 新架构的 UI 渲染系统，现在我们就来深入分析其源码。

本文基于React Native 0.83版本源码进行分析。

初始化

在《React Native新架构之Android端初始化源码分析》一文已经提过Fabric的初始化部分，现在回顾一下：

 // ReactInstance.kt   


    val eventBeatManager = EventBeatManager()
    fabricUIManager =
        FabricUIManager(context, ViewManagerRegistry(viewManagerResolver), eventBeatManager)

    // 在 Fabric 初始化之前需要完成的其他初始化操作。
    DisplayMetricsHolder.initDisplayMetricsIfNotInitialized(context)

    val binding = FabricUIManagerBinding()
    binding.register(
        getBufferedRuntimeExecutor(),
        getRuntimeScheduler(),
        fabricUIManager,
        eventBeatManager,
        componentFactory,
    )

    // 初始化 FabricUIManager
    fabricUIManager.initialize()

这里EventBeatManager 是 一个基于观察者模式的 Fabric 架构的 "节拍控制器"，它利用 Android 原生的帧回调机制，协调并驱动 C++ 层的事件向 JS 层高效、有序地流动。

现在重点看一FabricUIManager的构造方法做了什么react-native/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/fabric/FabricUIManager.java：

  public FabricUIManager(
      ReactApplicationContext reactContext,
      ViewManagerRegistry viewManagerRegistry,
      BatchEventDispatchedListener batchEventDispatchedListener) {
    // 初始化帧回调 
    mDispatchUIFrameCallback = new DispatchUIFrameCallback(reactContext);
    mReactApplicationContext = reactContext;
    // 初始化挂载管理器 
    mMountingManager = new MountingManager(viewManagerRegistry, mMountItemExecutor);
    // 初始化挂载指令调度器 
    mMountItemDispatcher =
        new MountItemDispatcher(mMountingManager, new MountItemDispatchListener());
    // 初始化事件分发器 
    mEventDispatcher = new FabricEventDispatcher(reactContext, new FabricEventEmitter(this));
    // 持有批处理事件监听器
    mBatchEventDispatchedListener = batchEventDispatchedListener;
    // 注册生命周期监听
    mReactApplicationContext.addLifecycleEventListener(this);
    // 注册组件回调 
    mViewManagerRegistry = viewManagerRegistry;
    mReactApplicationContext.registerComponentCallbacks(viewManagerRegistry);
  }

这段代码，首先创建一个派生自 Choreographer.FrameCallback的回调，这是 Fabric 渲染的“心脏”。它会注册到 Android 的 Choreographer，在每一帧垂直同步（VSync）信号到来时被调用。它负责驱动 MountItemDispatcher 来执行挂载操作（即实际的 View 更新）。

随后创建了一个挂载管理器MountingManager，它是实际操作 Android View 的管理者（执行 createView, updateProps 等）。接着创建了挂载指令调度器MountItemDispatcher，它负责管理挂载指令（MountItem）的队列，决定它们是在当前线程同步执行还是推入队列等待下一帧执行。当一批指令分发完成后，它会收到回调。这主要用于通知监听器，告诉它们“UI 已经更新了，你们可以进行下一帧动画计算了”。

接下来又创建了事件分发器FabricEventDispatcher，它负责将 Android 原生事件（如 Touch, Scroll）发送给 JavaScript。它的参数FabricEventEmitter是一个实现了 RCTEventEmitter 接口的类，它内部持有 C++ 层的引用（通过 JNI），是 Java 事件通往 C++ Fabric 核心的入口。

以上这写类基本上构成了一套UI系统的核心处理。如果大家需要更深入分析React Native UI系统，那么这些类就是研究的重点。在构造方法的最后，注册了生命周期监听，这是为了让 FabricUIManager 能够感知 Activity/Host 的 onResume, onPause, onDestroy。尤其是在 onHostResume 时恢复 UI 挂载循环，在 onHostPause 时暂停，以节省资源并避免在后台更新 UI。

最后注册组件回调，主要是用于当系统内存不足时，ViewManagerRegistry 可以收到通知并释放缓存。

现在继续分析初始化流程FabricUIManagerBinding的创建，源码react-native/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/fabric/FabricUIManagerBinding.kt：

@DoNotStrip
@SuppressLint("MissingNativeLoadLibrary")
internal class FabricUIManagerBinding : HybridClassBase() {
  init {
    initHybrid()
  }

  private external fun initHybrid()

  external fun setPixelDensity(pointScaleFactor: Float)

  private external fun installFabricUIManager(
      runtimeExecutor: RuntimeExecutor,
      runtimeScheduler: RuntimeScheduler,
      uiManager: FabricUIManager,
      eventBeatManager: EventBeatManager,
      componentsRegistry: ComponentFactory,
  )


  fun register(
      runtimeExecutor: RuntimeExecutor,
      runtimeScheduler: RuntimeScheduler,
      fabricUIManager: FabricUIManager,
      eventBeatManager: EventBeatManager,
      componentFactory: ComponentFactory,
  ) {
    fabricUIManager.setBinding(this)
    installFabricUIManager(
        runtimeExecutor,
        runtimeScheduler,
        fabricUIManager,
        eventBeatManager,
        componentFactory,
    )
    setPixelDensity(getDisplayMetricDensity())
  }

  // 省略部分代码......
}

该对象的构造，主要是调用initHybrid方法。关于initHybrid的机制，我们在前面的文章已经做了详细分析，这里就不再重复解释。

这里的FabricUIManagerBinding是 React Native Fabric 架构在 Android 端的 "核心启动器" 和 "跨语言胶水层"。它的主要作用是初始化 Fabric 的 C++ 核心组件，并建立 Java、C++ 和 JavaScript 三者之间的通信桥梁。当该对象被创建时，立即调用了其register方法。在这个方法中，主要是调用了installFabricUIManager，它将 C++ 层的 Fabric API 绑定到 JavaScript 运行时（Runtime）。这使得 JavaScript 可以直接通过 JSI 调用 C++ 接口（如 createNode, cloneNode, appendChild），实现同步且高效的 UI 操作。这里还有一个重要的操作，即setPixelDensity，将 Android 设备的屏幕像素密度（Density）传递给 React Native 的 C++ 核心层（Fabric/Yoga），用于统一布局单位。

最后，分析一下FabricUIManager的initialize做了什么事：

  public void initialize() {
    // 注册事件批处理监听
    mEventDispatcher.addBatchEventDispatchedListener(mBatchEventDispatchedListener);

    // 启用 Fabric 日志与性能监控
    if (ReactNativeFeatureFlags.enableFabricLogs()) {
      mDevToolsReactPerfLogger = new DevToolsReactPerfLogger();
      mDevToolsReactPerfLogger.addDevToolsReactPerfLoggerListener(FABRIC_PERF_LOGGER);

      ReactMarker.addFabricListener(mDevToolsReactPerfLogger);
    }

    // 启用新旧架构互操作
    if (ReactNativeNewArchitectureFeatureFlags.useFabricInterop()) {
      InteropEventEmitter interopEventEmitter = new InteropEventEmitter(mReactApplicationContext);
      mReactApplicationContext.internal_registerInteropModule(
          RCTEventEmitter.class, interopEventEmitter);
    }
  }

这里首先是将 mBatchEventDispatchedListener（即 EventBeatManager）注册到事件分发器中。这是 “心跳” 连接的关键一步。当 Android 原生事件（如 Touch）被成批分发时，会通知 EventBeatManager，进而触发 C++ 层的 tick()，驱动 Fabric 渲染管线刷新。没有这一步，JavaScript 可能永远收不到事件更新。

接下来是性能监控相关的处理，开启需依赖enableFabricLogs的值，这是排查 Fabric 性能问题（如掉帧、白屏）和调试渲染流程的“开关”。

最后是启用新旧架构互操作的处理，这是 React Native 平滑迁移到新架构的重要兼容层，确保老代码在新架构下也能工作。

C++层

以上FabricUIManagerBinding提供了很多Native方法，我们在此重点分析一下installFabricUIManager。源码react-native/packages/react-native/ReactAndroid/src/main/jni/react/fabric/FabricUIManagerBinding.cpp：

void FabricUIManagerBinding::installFabricUIManager(
    jni::alias_ref<JRuntimeExecutor::javaobject> runtimeExecutorHolder,
    jni::alias_ref<JRuntimeScheduler::javaobject> runtimeSchedulerHolder,
    jni::alias_ref<JFabricUIManager::javaobject> javaUIManager,
    EventBeatManager* eventBeatManager,
    ComponentFactory* componentsRegistry) {
  TraceSection s("FabricUIManagerBinding::installFabricUIManager");

  enableFabricLogs_ = ReactNativeFeatureFlags::enableFabricLogs();

  if (enableFabricLogs_) {
    LOG(WARNING)
        << "FabricUIManagerBinding::installFabricUIManager() was called (address: "
        << this << ").";
  }

  std::unique_lock lock(installMutex_);

  // 创建 C++ MountingManager (
  auto globalJavaUiManager = make_global(javaUIManager);
  mountingManager_ =
      std::make_shared<FabricMountingManager>(globalJavaUiManager);

  std::shared_ptr<const ContextContainer> contextContainer =
      std::make_shared<ContextContainer>();

  auto runtimeExecutor = runtimeExecutorHolder->cthis()->get();

  auto runtimeScheduler = runtimeSchedulerHolder->cthis()->get().lock();
  // 如果存在 RuntimeScheduler（通常都存在），则包装 runtimeExecutor。
  // 这意味着所有通过此 executor 提交的 JS 任务都会经过 RuntimeScheduler 调度，从而支持优先级和任务取消。
  if (runtimeScheduler) {
    runtimeExecutor =
        [runtimeScheduler](
            std::function<void(jsi::Runtime & runtime)>&& callback) {
          runtimeScheduler->scheduleWork(std::move(callback));
        };
    contextContainer->insert(
        RuntimeSchedulerKey, std::weak_ptr<RuntimeScheduler>(runtimeScheduler));
  }

  // 创建 EventBeat 工厂 
  EventBeat::Factory eventBeatFactory =
      [eventBeatManager, &runtimeScheduler, globalJavaUiManager](
          std::shared_ptr<EventBeat::OwnerBox> ownerBox)
      -> std::unique_ptr<EventBeat> {
    return std::make_unique<AndroidEventBeat>(
        std::move(ownerBox),
        eventBeatManager,
        *runtimeScheduler,
        globalJavaUiManager);
  };

  contextContainer->insert("FabricUIManager", globalJavaUiManager);

  // 组装 Scheduler 工具箱
  auto toolbox = SchedulerToolbox{};
  toolbox.contextContainer = contextContainer;
  toolbox.componentRegistryFactory = componentsRegistry->buildRegistryFunction;

  // TODO: (T132338609) runtimeExecutor 应该在主 bundle eval 之后执行 lambda 表达式，
  // 而 bindingsInstallExecutor 应该在之前执行。
  toolbox.bridgelessBindingsExecutor = std::nullopt;
  toolbox.runtimeExecutor = runtimeExecutor;

  toolbox.eventBeatFactory = eventBeatFactory;

  // 启动 Fabric 核心
  animationDriver_ = std::make_shared<LayoutAnimationDriver>(
      runtimeExecutor, contextContainer, this);
  scheduler_ =
      std::make_shared<Scheduler>(toolbox, animationDriver_.get(), this);
}

这个方法是一个 "组装车间"：

1. 它接收来自 Android (Java) 的原材料（UIManager, EventBeatManager）。

2. 它接收来自 JS Runtime 的驱动器（RuntimeExecutor）。

3. 它将这些零件组装成 C++ 的核心部件（MountingManager, AndroidEventBeat）。

4. 最后，它启动了 Fabric 的引擎 —— Scheduler。

总结

下面是对整个初始化流程的概述

ReactInstance 初始化
           │
           │
           └─► Fabric 初始化
                    │
                    ├─► ViewManagerResolver 创建 (收集 ReactPackage 中的 ViewManager)
                    │
                    ├─► ViewManagerRegistry 创建
                    │
                    ├─► FabricUIManager 创建
                    │
                    ├─► FabricUIManagerBinding 创建
                    │
                    └─► binding.register() ──► 触发 C++ 层初始化

启动渲染

回顾一下Android 的初始化流程一文：

// ReactInstance.kt


 /**
   * 渲染一个 React Native surface.
   *
   * @param surface 要渲染的 [com.facebook.react.interfaces.fabric.ReactSurface] 对象
   */
  @ThreadConfined("ReactHost")
  fun startSurface(surface: ReactSurfaceImpl) {
    // 省略部分代码......
    val view = surface.view

    if (surface.isRunning) {
      // Surface 已经在运行（预渲染过），只需附加 View
      fabricUIManager.attachRootView(surface.surfaceHandler, view)
    } else {
      fabricUIManager.startSurface(surface.surfaceHandler, surface.context, view)
    }
  }

之前并未深入fabricUIManager.startSurface方法的调用，现在来分析一下：

// FabricUIManager.java

  public void startSurface(
      final SurfaceHandlerBinding surfaceHandler,
      final Context context,
      final @Nullable View rootView) {
    final int rootTag =
        rootView instanceof ReactRoot
            ? ((ReactRoot) rootView).getRootViewTag()
            : ReactRootViewTagGenerator.getNextRootViewTag();

    ThemedReactContext reactContext =
        new ThemedReactContext(
            mReactApplicationContext, context, surfaceHandler.getModuleName(), rootTag);
    mMountingManager.startSurface(rootTag, reactContext, rootView);
    Assertions.assertNotNull(mBinding, "Binding in FabricUIManager is null");
    mBinding.startSurfaceWithSurfaceHandler(rootTag, surfaceHandler, rootView != null);
  }

此方法主要做了两件事，首先是调用MountingManager的startSurface启动 Surface，接着调用了FabricUIManagerBinding的Native方法startSurfaceWithSurfaceHandler在C++层启动 Surface。先查看react-native/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/fabric/mounting/MountingManager.kt：

  /**
    * 启动 Surface 但不附加视图。对该 Surface 执行的所有视图操作都将被排队，直到视图被附加为止。
    */
  @AnyThread
  fun startSurface(
      surfaceId: Int,
      reactContext: ThemedReactContext?,
      rootView: View?,
  ): SurfaceMountingManager {
    // 创建一个新的 SurfaceMountingManager 实例，负责管理特定 Surface 的视图挂载操作
    val surfaceMountingManager =
        SurfaceMountingManager(
            surfaceId,
            jsResponderHandler,  // JS 响应处理器（处理触摸事件响应）
            viewManagerRegistry,
            rootViewManager,
            mountItemExecutor,   // 挂载项执行器
            checkNotNull(reactContext),
        )

    // 理论上这里可能存在竞态条件，如果 addRootView 从不同线程被调用两次，
    // 虽然这种情况（可能）极不可能发生，而且很可能是一个错误。
    // 这个防止竞态条件的逻辑是从旧代码继承而来的，我们不知道在实际中是否真的会发生
    // 所以，我们现在记录软异常。这在调试模式下会崩溃，但在生产环境中不会。
    surfaceIdToManager.putIfAbsent(surfaceId, surfaceMountingManager)
    if (surfaceIdToManager[surfaceId] !== surfaceMountingManager) {
      logSoftException(
          TAG,
          IllegalStateException(
              "Called startSurface more than once for the SurfaceId [$surfaceId]"
          ),
      )
    }

    mostRecentSurfaceMountingManager = surfaceIdToManager[surfaceId]

    if (rootView != null) {
      surfaceMountingManager.attachRootView(rootView, reactContext)
    }

    return surfaceMountingManager
  }

此方法主要内容是创建SurfaceMountingManager，然后调用attachRootView方法。现在继续跟踪attachRootView方法，源码react-native/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/fabric/mounting/SurfaceMountingManager.java：

  public void attachRootView(View rootView, ThemedReactContext themedReactContext) {
    mThemedReactContext = themedReactContext;
    addRootView(rootView);
  }

  private void addRootView(@NonNull final View rootView) {
    if (isStopped()) {
      return;  // 检查 Surface 是否已停止
    }

    mTagToViewState.put(mSurfaceId, new ViewState(mSurfaceId, rootView, mRootViewManager, true));

    // 在 UI 线程上执行根视图设置
    Runnable runnable =
        new GuardedRunnable(Assertions.assertNotNull(mThemedReactContext)) {
          @Override
          public void runGuarded() {
            // 自从调用`addRootView`以来，CPU 一直在运行，因此从理论上讲，界面可能已经在此处停止渲染了。
            if (isStopped()) {
              return;
            }
            // 省略部分日志打印......

            // 设置根视图 ID 
            rootView.setId(mSurfaceId);

            if (rootView instanceof ReactRoot) {
              ((ReactRoot) rootView).setRootViewTag(mSurfaceId);
            }

            executeMountItemsOnViewAttach();

            // 通过在调用 `executeMountItemsOnViewAttach` 之后执行此操作，
            // 我们可以确保在处理此队列时安排的任何操作也会被添加到队列中，
            // 而不是通过 `MountItemDispatcher` 中的队列立即进行处理。
            mRootViewAttached = true;
          }
        };

    // 确保在 UI 线程执行
    if (UiThreadUtil.isOnUiThread()) {
      runnable.run();
    } else {
      UiThreadUtil.runOnUiThread(runnable);
    }
  }

这里的实现核心是封装了一个Runnable，即一个任务，且这个任务必须在安卓的UI线程执行。继续跟踪executeMountItemsOnViewAttach方法，查看任务的内容：

  private final Queue<MountItem> mOnViewAttachMountItems = new ArrayDeque<>();


  @UiThread
  @ThreadConfined(UI)
  private void executeMountItemsOnViewAttach() {
    mMountItemExecutor.executeItems(mOnViewAttachMountItems);
  }

可以看到，该方法就是在调用挂载项执行器不断的执行挂载项队列。这里的挂载项执行器是在创建MountingManager时传入的，回到FabricUIManager源码查看实现：

  private final MountingManager.MountItemExecutor mMountItemExecutor =
      new MountingManager.MountItemExecutor() {
        @Override
        public void executeItems(Queue<MountItem> items) {
          // 从技术上讲，在调度程序创建之前就可以访问这个执行器，但如果真的发生这种情况，那就说明出了非常严重的问题。
          mMountItemDispatcher.dispatchMountItems(items);
        }
      };

继续跟踪react-native/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/fabric/mounting/MountItemDispatcher.kt中的实现：

  @UiThread
  @ThreadConfined(UI)
  fun dispatchMountItems(mountItems: Queue<MountItem?>) {
    while (!mountItems.isEmpty()) {
      val item = requireNotNull(mountItems.poll()) { "MountItem should not be null" }
      try {
        item.execute(mountingManager)
      } catch (e: RetryableMountingLayerException) {
        // 省略已弃用的逻辑......
      }
    }
  }

此处核心逻辑是从队列取出一个 MountItem并执行它的execute方法。至于MountItem接口，它有许多实现类，其中最核心的是IntBufferBatchMountItem实现，我们可以大致浏览一下它的execute方法主要做些什么。源码react-native/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/fabric/mounting/mountitems/IntBufferBatchMountItem.kt：

  override fun execute(mountingManager: MountingManager) {
    val surfaceMountingManager = mountingManager.getSurfaceManager(surfaceId)
    if (surfaceMountingManager == null) {
      return
    }
    if (surfaceMountingManager.isStopped) {
      return
    }
    if (ReactNativeFeatureFlags.enableFabricLogs()) {
      FLog.d(TAG, "Executing IntBufferBatchMountItem on surface [%d]", surfaceId)
    }

    beginMarkers("mountViews")
    var i = 0
    var j = 0
    while (i < intBufferLen) {
      val rawType = intBuffer[i++]
      val type = rawType and INSTRUCTION_FLAG_MULTIPLE.inv()
      val numInstructions =
          (if ((rawType and INSTRUCTION_FLAG_MULTIPLE) != 0) intBuffer[i++] else 1)

      val args = arrayOf("numInstructions", numInstructions.toString())

      for (k in 0 until numInstructions) {
        when (type) {
          INSTRUCTION_CREATE -> {    
            val componentName = (objBuffer[j++] as String?).orEmpty()
            val fabricComponentName =
                FabricNameComponentMapping.getFabricComponentName(componentName)
            // 创建视图
            surfaceMountingManager.createView(
                fabricComponentName,
                intBuffer[i++],
                objBuffer[j++] as ReadableMap?,
                objBuffer[j++] as StateWrapper?,
                objBuffer[j++] as EventEmitterWrapper?,
                intBuffer[i++] == 1,
            )
          }
          // 删除视图
          INSTRUCTION_DELETE -> surfaceMountingManager.deleteView(intBuffer[i++]) 
          INSTRUCTION_INSERT -> {
            val tag = intBuffer[i++]
            val parentTag = intBuffer[i++]
            // 插入视图到父视图
            surfaceMountingManager.addViewAt(parentTag, tag, intBuffer[i++])
          }
          // 从父视图移除
          INSTRUCTION_REMOVE ->
              surfaceMountingManager.removeViewAt(intBuffer[i++], intBuffer[i++], intBuffer[i++])
           // 更新属性
          INSTRUCTION_UPDATE_PROPS ->
              surfaceMountingManager.updateProps(intBuffer[i++], objBuffer[j++] as ReadableMap?)
          // 更新状态
          INSTRUCTION_UPDATE_STATE ->
              surfaceMountingManager.updateState(intBuffer[i++], objBuffer[j++] as StateWrapper?)

          // 更新布局
          INSTRUCTION_UPDATE_LAYOUT -> {
            val reactTag = intBuffer[i++]
            val parentTag = intBuffer[i++]
            val x = intBuffer[i++]
            val y = intBuffer[i++]
            val width = intBuffer[i++]
            val height = intBuffer[i++]
            val displayType = intBuffer[i++]
            val layoutDirection = intBuffer[i++]
            surfaceMountingManager.updateLayout(
                reactTag,
                parentTag,
                x,
                y,
                width,
                height,
                displayType,
                layoutDirection,
            )
          }
          // 省略部分代码......
          else -> {
            throw IllegalArgumentException(
                "Invalid type argument to IntBufferBatchMountItem: $type at index: $i"
            )
          }
        }
      }
    }
    endMarkers()
  }

可以看到，IntBufferBatchMountItem包含批量视图操作指令，它使用 int 数组和 object 数组优化性能，减少 JNI 调用，并且支持多种视图操作：创建、删除、插入、移除、更新属性/状态/布局等。

接下来我们跟踪一下surfaceMountingManager.createView的实现，源码react-native/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/fabric/mounting/SurfaceMountingManager.java：

 @UiThread
  public void createView(
      @NonNull String componentName,
      int reactTag,
      @Nullable ReadableMap props,
      @Nullable StateWrapper stateWrapper,
      @Nullable EventEmitterWrapper eventEmitterWrapper,
      boolean isLayoutable) {
    if (isStopped()) {
      return;
    }
    ViewState viewState = getNullableViewState(reactTag);
    if (viewState != null && viewState.mView != null) {
      return;
    }

    createViewUnsafe(
        componentName, reactTag, props, stateWrapper, eventEmitterWrapper, isLayoutable);
  }

  /**
   * 执行视图创建操作，但不进行任何安全检查。您必须在调用此方法之前确保安全性（参见现有调用位置）
   */
  @UiThread
public void createViewUnsafe(
      @NonNull String componentName,
      int reactTag,
      @Nullable ReadableMap props,
      @Nullable StateWrapper stateWrapper,
      @Nullable EventEmitterWrapper eventEmitterWrapper,
      boolean isLayoutable) {
    Systrace.beginSection(
        Systrace.TRACE_TAG_REACT,
        "SurfaceMountingManager::createViewUnsafe(" + componentName + ")");
    try {
      ReactStylesDiffMap propMap = new ReactStylesDiffMap(props);

      ViewState viewState = new ViewState(reactTag);
      viewState.mCurrentProps = propMap;
      viewState.mStateWrapper = stateWrapper;
      viewState.mEventEmitter = eventEmitterWrapper;
      mTagToViewState.put(reactTag, viewState);

      if (isLayoutable) {
        ViewManager viewManager = mViewManagerRegistry.get(componentName);
        // View Managers are responsible for dealing with inital state and props.
        viewState.mView =
            viewManager.createView(
                reactTag, mThemedReactContext, propMap, stateWrapper, mJSResponderHandler);
        viewState.mViewManager = viewManager;
      }
    } finally {
      Systrace.endSection(Systrace.TRACE_TAG_REACT);
    }
  }

这里是根据组件名通过mViewManagerRegistry来查找ViewManager。具体注册逻辑，我们在后面的注册组件一节分析。

继续跟踪一下viewManager.createView方法的实现，源码react-native/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/uimanager/ViewManager.java：

  /** 创建一个了解 props 和 state 的视图。 */
  public @NonNull T createView(
      int reactTag,
      @NonNull ThemedReactContext reactContext,
      @Nullable ReactStylesDiffMap props,
      @Nullable StateWrapper stateWrapper,
      JSResponderHandler jsResponderHandler) {
    T view = createViewInstance(reactTag, reactContext, props, stateWrapper);
    if (view instanceof ReactInterceptingViewGroup) {
      ((ReactInterceptingViewGroup) view).setOnInterceptTouchEventListener(jsResponderHandler);
    }
    return view;
  }

  /**
   * 子类应该返回一个适当类型的新 View 实例。这是一个可选方法，它会为您调用 createViewInstance。
   * 如果您需要在创建视图时使用 props 或 state，请重写它。
   *
   * 如果您重写此方法，您*必须*确保正确处理 updateProperties、view.setId、
   * addEventEmitters 和 updateState/updateExtraData！
   *
   * @param reactTag 应该设置为视图实例 ID 的 reactTag
   * @param reactContext 用于初始化视图实例的 ReactContext
   * @param initialProps 视图实例的初始 props
   * @param stateWrapper 视图实例的初始 state
   */
  protected @NonNull T createViewInstance(
      int reactTag,
      @NonNull ThemedReactContext reactContext,
      @Nullable ReactStylesDiffMap initialProps,
      @Nullable StateWrapper stateWrapper) {
    T view = null;
    @Nullable Stack<T> recyclableViews = getRecyclableViewStack(reactContext.getSurfaceId(), true);
    if (recyclableViews != null && !recyclableViews.empty()) {
      T recyclableView = recyclableViews.pop();

      // 当视图回收未对所有组件启用时，可回收视图仍可能附加到不可回收视图。
      // 这保证了回收视图已从其父视图中移除。
      if (ReactNativeFeatureFlags.enableViewRecycling() && recyclableView.getParent() != null) {
        ((ViewGroup) recyclableView.getParent()).removeView(recyclableView);
      }

      view = recycleView(reactContext, recyclableView);
    } else {
      view = createViewInstance(reactContext);
    }
    view.setId(reactTag);
    addEventEmitters(reactContext, view);
    if (initialProps != null) {
      updateProperties(view, initialProps);
    }
    // 仅在 Fabric 架构中存在；但在 Fabric 中始终存在。
    if (stateWrapper != null) {
      Object extraData = updateState(view, initialProps, stateWrapper);
      if (extraData != null) {
        updateExtraData(view, extraData);
      }
    }
    return view;
  }

 /**
   * 子类应该返回一个适当类型的新 View 实例。
   */
  protected abstract @NonNull T createViewInstance(@NonNull ThemedReactContext reactContext);

   /**
   * 子类可以重写此方法以在给定 View 上安装自定义事件发射器。
   * 如果您的视图需要向 JS 发送除基本触摸事件之外的事件（例如滚动事件），
   * 您可能想要重写此方法。
   */
  protected void addEventEmitters(@NonNull ThemedReactContext reactContext, @NonNull T view) {}

 /**
   * 子类可以实现此方法以接收从 {@link ReactShadowNode#onCollectExtraUpdates} 中
   * 相应 {@link ReactShadowNode} 实例排队的可选额外数据。
   *
   * 由于 CSS 布局步骤和 UI 更新可以在设置 x/y/width/height 之外的单独线程中执行，
   * 这是从 CSS 节点向原生视图对应部分传递额外数据的推荐且线程安全的方式。
   *
   * <p>TODO T7247021: Replace updateExtraData with generic update props mechanism after D2086999
   */
  public abstract void updateExtraData(@NonNull T view, Object extraData);

 /**
   * 子类可以实现此方法以接收在此组件类型的所有实例之间共享的状态更新。
   */
  public @Nullable Object updateState(
      @NonNull T view, ReactStylesDiffMap props, StateWrapper stateWrapper) {
    return null;
  }

这里比较重要的是createViewInstance方法，子类必须重写它，用于创建自定义View。现在查看一下我们创建的自定义Fabric 组件包中自动生成的模版代码：

@ReactModule(name = CustomWebViewManager.NAME)
class CustomWebViewManager : SimpleViewManager<CustomWebView>(),
  CustomWebViewManagerInterface<CustomWebView> {
  private val mDelegate: ViewManagerDelegate<CustomWebView>

  init {
    mDelegate = CustomWebViewManagerDelegate(this)
  }

  override fun getDelegate(): ViewManagerDelegate<CustomWebView>? {
    return mDelegate
  }

  override fun getName(): String {
    return NAME
  }

  public override fun createViewInstance(context: ThemedReactContext): CustomWebView {
    return CustomWebView(context)
  }

  @ReactProp(name = "sourceURL")
  override fun setSourceURL(view: CustomWebView?, sourceURL: String?) {
    // Implement the logic to handle the sourceURL property
  }

  companion object {
    const val NAME = "CustomWebView"
  }
}

可以看到，CustomWebViewManager实际上就是ViewManager的子孙类，其实现了createViewInstance方法，返回自定义的View实例。

这条线的跟踪已经足够深入了，关于原生UI组件的具体布局渲染就不继续了，先到此为止。

C++ 层

FabricUIManager的startSurface方法中还有一个Native方法mBinding.startSurfaceWithSurfaceHandler未分析，源码react-native/packages/react-native/ReactAndroid/src/main/jni/react/fabric/FabricUIManagerBinding.cpp：

void FabricUIManagerBinding::startSurfaceWithSurfaceHandler(
    jint surfaceId,
    jni::alias_ref<SurfaceHandlerBinding::jhybridobject> surfaceHandlerBinding,
    jboolean isMountable) {

  // SurfaceHandler配置 
  // 从JNI包装中提取C++ SurfaceHandler对象
  const auto& surfaceHandler =
      surfaceHandlerBinding->cthis()->getSurfaceHandler();
  surfaceHandler.setSurfaceId(surfaceId);
  // 根据是否有View设置显示模式
  surfaceHandler.setDisplayMode(
      isMountable != 0 ? DisplayMode::Visible : DisplayMode::Suspended);

  // 获取Fabric调度器
  auto scheduler = getScheduler();
  if (!scheduler) {
    LOG(ERROR)
        << "FabricUIManagerBinding::startSurfaceWithSurfaceHandler: scheduler disappeared";
    return;
  }

  // 将SurfaceHandler注册到调度器中。调度器负责管理渲染和布局
  scheduler->registerSurface(surfaceHandler);

  auto mountingManager = getMountingManager("startSurfaceWithSurfaceHandler");
  if (mountingManager != nullptr) {
    // 通知MountingManager, Surface开始启动
    // MountingManager负责将C++的UI操作转换为Android原生View操作
    mountingManager->onSurfaceStart(surfaceId);
  }

  // 启动SurfaceHandler 
  surfaceHandler.start();

  // 如果启用布局动画，设置动画驱动器
  if (ReactNativeFeatureFlags::enableLayoutAnimationsOnAndroid()) {
    surfaceHandler.getMountingCoordinator()->setMountingOverrideDelegate(
        animationDriver_);
  }

  {
    std::unique_lock lock(surfaceHandlerRegistryMutex_);
    // 将SurfaceHandler添加到注册表中，便于后续管理（停止、更新等）
    surfaceHandlerRegistry_.emplace(
        surfaceId, jni::make_weak(surfaceHandlerBinding));
  }
}

这个方法是新架构Surface启动的关键桥梁，它体现了新架构的核心特点：通过JSI直接从C++调用JS。

• 向上：接收Java层的启动请求

• 向下：触发C++层的Surface启动流程

• 横向：协调Scheduler、MountingManager等各个子系统

这里重点关注一下surfaceHandler.start()的实现，源码react-native/packages/react-native/ReactCommon/react/renderer/scheduler/SurfaceHandler.cpp:

void SurfaceHandler::start() const noexcept {
  std::unique_lock lock(linkMutex_);
  // 省略断言......

  auto parameters = Parameters{};
  {
    std::shared_lock parametersLock(parametersMutex_);
    parameters = parameters_;
  }

  // 创建ShadowTree 
  auto shadowTree = std::make_unique<ShadowTree>(
      parameters.surfaceId,
      parameters.layoutConstraints,
      parameters.layoutContext,
      *link_.uiManager,
      *parameters.contextContainer);

  // 将ShadowTree指针保存到link_中，供后续操作使用
  link_.shadowTree = shadowTree.get();

  if (!parameters.moduleName.empty()) {
    // 启动Surface
    link_.uiManager->startSurface(
        std::move(shadowTree),
        parameters.moduleName,
        parameters.props,
        parameters_.displayMode);
  } else {
    // 创建空Surface，仅用于预渲染
    link_.uiManager->startEmptySurface(std::move(shadowTree));
  }
  // 将状态从Registered更新为Running
  link_.status = Status::Running;
  // 应用显示模式
  applyDisplayMode(parameters.displayMode);
}

此方法是Fabric架构中渲染流程的起点，负责创建ShadowTree并启动UI渲染流程。这里的ShadowTree就是Fabric中的虚拟DOM树，用于布局计算和渲染。

继续跟踪uiManager->startSurface的实现，源码react-native/packages/react-native/ReactCommon/react/renderer/uimanager/UIManager.cpp:

void UIManager::startSurface(
    ShadowTree::Unique&& shadowTree,
    const std::string& moduleName,
    const folly::dynamic& props,
    DisplayMode displayMode) const noexcept {
  TraceSection s("UIManager::startSurface");

  // ShadowTree注册 
  auto surfaceId = shadowTree->getSurfaceId();
  shadowTreeRegistry_.add(std::move(shadowTree));

  // 委托通知
  // 使用访问者模式安全访问已注册的ShadowTree
  shadowTreeRegistry_.visit(
      surfaceId, [delegate = delegate_](const ShadowTree& shadowTree) {
        if (delegate != nullptr) {
          // 通知UIManager的委托对象Surface已启动
          delegate->uiManagerDidStartSurface(shadowTree);
        }
      });

  // 异步调用JS层
  runtimeExecutor_([=](jsi::Runtime& runtime) {
    TraceSection s("UIManager::startSurface::onRuntime");
    // 在JS线程上异步执行
    AppRegistryBinding::startSurface(
        runtime, surfaceId, moduleName, props, displayMode);
  });
}

此方法是Fabric架构中连接C++渲染系统和JS应用层的关键桥梁方法，负责注册ShadowTree并触发JS应用启动。

继续跟踪AppRegistryBinding::startSurface。源码react-native/packages/react-native/ReactCommon/react/renderer/uimanager/AppRegistryBinding.cpp:

/* static */ void AppRegistryBinding::startSurface(
    jsi::Runtime& runtime,
    SurfaceId surfaceId,
    const std::string& moduleName,
    const folly::dynamic& initialProps,
    DisplayMode displayMode) {
  TraceSection s("AppRegistryBinding::startSurface");

  // 构建参数对象
  jsi::Object parameters(runtime);
  parameters.setProperty(runtime, "rootTag", surfaceId);
  parameters.setProperty(
      runtime, "initialProps", jsi::valueFromDynamic(runtime, initialProps));
  parameters.setProperty(runtime, "fabric", true);

  // 获取全局AppRegistry 
  // 访问JS全局对象
  auto global = runtime.global();
  // 查找RN$AppRegistry（在AppRegistry.js中设置）
  auto registry = global.getProperty(runtime, "RN$AppRegistry");
  if (!registry.isObject()) {
    throw std::runtime_error(
        "AppRegistryBinding::startSurface failed. Global was not installed.");
  }

  // 获取runApplication方法对象
  auto method = std::move(registry).asObject(runtime).getPropertyAsFunction(
      runtime, "runApplication");

  // 调用JS方法：runApplication
  method.call(
      runtime,
      {jsi::String::createFromUtf8(runtime, moduleName),
       std::move(parameters),
       jsi::Value(runtime, displayModeToInt(displayMode))});
}

这里的重点是就是JS层的runApplication方法调用，可以说这就是JS层的入口方法。此处的JSI C++调用等价于以下JS代码：

AppRegistry.runApplication(
  "RNTesterApp",           // moduleName
  {
    rootTag: 1,            // surfaceId
    initialProps: {...},   // 初始属性
    fabric: true           // 新架构标记
  },
  0                        // displayMode
);

AppRegistryBinding::startSurface方法是新架构调用链的终点，负责通过JSI直接调用JS层的AppRegistry.runApplication，启动React Native应用。

渲染调度

接下来我们探索一下前面提到的mOnViewAttachMountItems队列：

// SurfaceMountingManager.java

  @UiThread
  @ThreadConfined(UI)
  public void scheduleMountItemOnViewAttach(MountItem item) {
    mOnViewAttachMountItems.add(item);
  }

经过搜索，可以定位到scheduleMountItemOnViewAttach调用处：

// MountItemDispatcher.kt

  private fun getAndResetViewCommandMountItems(): List<DispatchCommandMountItem>? =
      drainConcurrentItemQueue(viewCommandMountItems)

  private fun getAndResetMountItems(): List<MountItem>? = drainConcurrentItemQueue(mountItems)

  private fun getAndResetPreMountItems(): List<MountItem>? = drainConcurrentItemQueue(preMountItems)

  private fun executeOrEnqueue(item: MountItem) {
    if (mountingManager.isWaitingForViewAttach(item.getSurfaceId())) {
      // Surface 还未准备好，将任务加入等待队列
      val surfaceMountingManager: SurfaceMountingManager =
          mountingManager.getSurfaceManagerEnforced(
              item.getSurfaceId(),
              "MountItemDispatcher::executeOrEnqueue",
          )
      surfaceMountingManager.scheduleMountItemOnViewAttach(item)
    } else {
      // Surface 已准备好，直接执行
      item.execute(mountingManager)
    }
  }


  /*
   * 按以下顺序执行视图命令、预挂载项和挂载项：
   * 1. 视图命令
   * 2. 预挂载项  
   * 3. 常规挂载项
   *
   * 如果 `viewCommandMountItemsToDispatch` 和 `mountItemsToDispatch` 都为空，则不执行任何操作。
   * 除了 `tryDispatchMountItems` 之外，任何地方都不应直接调用此方法。
   */
  @UiThread
  @ThreadConfined(UI)
  private fun dispatchMountItems() {
    batchedExecutionTime = 0
    runStartTime = SystemClock.uptimeMillis()
    // 初始化和获取待分发项
    val viewCommandMountItemsToDispatch = getAndResetViewCommandMountItems()
    val mountItemsToDispatch = getAndResetMountItems()

    if (mountItemsToDispatch == null && viewCommandMountItemsToDispatch == null) {
      return
    }

    itemDispatchListener.willMountItems(mountItemsToDispatch)

    // 定义视图命令分发函数
    val dispatchViewCommand: (command: DispatchCommandMountItem) -> Unit = { command ->
      if (ReactNativeFeatureFlags.enableFabricLogs()) {
        printMountItem(command, "dispatchMountItems: Executing viewCommandMountItem")
      }
      try {
        executeOrEnqueue(command)
      } catch (e: RetryableMountingLayerException) {
        // 省略......
      } catch (e: Throwable) {
        // 省略......
      }
    }

    // 执行ViewCommand

    // 作为优化，首先执行所有 ViewCommand
    // 这应该是：
    // 1) 高性能的：ViewCommand 通常是 SetNativeProps 的替代品，我们一直希望它尽可能"同步"。
    // 2) 更安全的：ViewCommand 本质上与树提交/差异/挂载过程断开连接。
    // JS 令式地排队这些命令。
    //    如果 JS 已经排队了一个命令，可以合理地假设时间过得越久， 视图消失的可能性就越大。
    //    因此，通过提前执行 ViewCommand，我们实际上应该避免一类错误/故障。
    viewCommandMountItemsToDispatch?.let { commands ->
      for (command in commands) {
        dispatchViewCommand(command)
      }

      Systrace.endSection(Systrace.TRACE_TAG_REACT)
    }

    // 执行PreMountItem
    // 如果有 MountItem 要分发，我们确保所有"预挂载项"首先执行
    getAndResetPreMountItems()?.let { preMountItems ->
      for (preMountItem in preMountItems) {
        if (ReactNativeFeatureFlags.enableFabricLogs()) {
          printMountItem(preMountItem, "dispatchMountItems: Executing preMountItem")
        }
        executeOrEnqueue(preMountItem)
      }
      Systrace.endSection(Systrace.TRACE_TAG_REACT)
    }

    // 执行常规 MountItem 
    mountItemsToDispatch?.let { items ->
      val batchedExecutionStartTime = SystemClock.uptimeMillis()

      for (mountItem in items) {
        if (ReactNativeFeatureFlags.enableFabricLogs()) {
          printMountItem(mountItem, "dispatchMountItems: Executing mountItem")
        }

        val command = mountItem as? DispatchCommandMountItem
        if (command != null) {
          dispatchViewCommand(command)
          continue
        }

        try {
          executeOrEnqueue(mountItem)
        } catch (e: Throwable) {
          // 省略......
        }
      }
      batchedExecutionTime += SystemClock.uptimeMillis() - batchedExecutionStartTime
    }

    itemDispatchListener.didMountItems(mountItemsToDispatch)
  }

 /**
  * 尝试分发 MountItems。如果出现异常，我们将重试 10 次后放弃。
  */
  fun tryDispatchMountItems() {
    // 如果我们已经在分发中，不要重入。在 Android 的 Fabric 中可能经常发生重入，
    // 因为来自挂载层的 `updateState` 会导致挂载项被同步分发。我们想要 
    //    1)确保在这些情况下不重入，但 2)仍然同步执行这些排队的指令。
    // 这是一个相当粗暴的工具，但我们可能没有更好的选择，因为我们真的不想执行任何乱序的操作。
    if (inDispatch) {
      return
    }

    inDispatch = true

    try {
      dispatchMountItems()
    } finally {
      // 即使抛出异常也要在运行 dispatchMountItems 后清理
      inDispatch = false
    }

    // 无论我们是否实际分发了任何内容，我们都会调用 didDispatchMountItems，
    // 因为 NativeAnimatedModule 依赖于此来执行可能已调度的任何动画
    itemDispatchListener.didDispatchMountItems()
  }

可以看到，scheduleMountItemOnViewAttach仅被executeOrEnqueue方法调用。只有在Surface 还未准备好时，才将任务加入等待队列。否则，直接在executeOrEnqueue中执行挂载项。

这里executeOrEnqueue方法在dispatchMountItems方法中有三次调用，分别对应着三个队列。这三个队列存在执行顺序：

1. ViewCommand 优先执行：提高性能和安全性（存储视图命令，如 scrollTo、focus等，这些是来自 JS 的命令式调用，与视图树的提交/差异/挂载过程分离）

2. PreMountItem 次之：为后续挂载做准备（存储预挂载项，主要是视图预分配操作。这是性能优化，尽可能提前完成工作）

3. 常规 MountItem 最后：执行实际的视图操作（存储常规挂载项，包含主要的视图操作。这是视图树更新的核心操作）

有个地方需要注意，就是drainConcurrentItemQueue方法。此方法是一次性清空队列，将结果转为一个List。之所以这样做，是为了将累积的所有挂载项一次性取出进行批处理，避免在执行过程中队列继续增长导致的不一致性。这里的三个队列都调用了此方法返回列表。

接下来，根据注释可知，dispatchMountItems方法只应该被tryDispatchMountItems调用。而tryDispatchMountItems方法主要做了一个防止重入的处理。继续搜索该方法，发现只有两处调用，且都在FabricUIManager.java中：

private class DispatchUIFrameCallback extends GuardedFrameCallback {
    private volatile boolean mIsMountingEnabled = true;
    @ThreadConfined(UI)
    private boolean mShouldSchedule = false;
    @ThreadConfined(UI)
    private boolean mIsScheduled = false;

    private DispatchUIFrameCallback(ReactContext reactContext) {
      super(reactContext);
    }

    @UiThread
    @ThreadConfined(UI)
    private void schedule() {
      if (!mIsScheduled && mShouldSchedule) {
        mIsScheduled = true;
        ReactChoreographer.getInstance()
            .postFrameCallback(ReactChoreographer.CallbackType.DISPATCH_UI, this);
      }
    }
    // 省略部分代码......

    @Override
    @UiThread
    @ThreadConfined(UI)
    public void doFrameGuarded(long frameTimeNanos) {
      mIsScheduled = false;
      if (!mIsMountingEnabled) {
        return;
      }

      if (mDestroyed) {
        return;
      }

      // 通过 C++ 驱动所有动画。
      // 这里存在获取/设置 `mDriveCxxAnimations` 的竞态条件，但这应该无关紧要；
      // 调用 mBinding 方法是安全的，除非 mBinding 对象已被销毁。
      if ((mDriveCxxAnimations || ReactNativeFeatureFlags.cxxNativeAnimatedEnabled())
          && mBinding != null) {
        mBinding.driveCxxAnimations();
      }

      if (mBinding != null) {
        mBinding.drainPreallocateViewsQueue();
      }

      try {
        // 首先，在 frameTimeNanos 时间内执行尽可能多的预挂载项。
        // 如果不是所有预挂载项都被执行，可能发生以下情况：
        //   1. 如果 MountItemDispatcher 中有视图命令或挂载项：执行剩余的预挂载项。
        //   2. 如果没有视图命令或挂载项，等待下一帧。
        mMountItemDispatcher.dispatchPreMountItems(frameTimeNanos);
        mMountItemDispatcher.tryDispatchMountItems();
      } catch (Exception ex) {
        FLog.e(TAG, "Exception thrown when executing UIFrameGuarded", ex);
        mIsMountingEnabled = false;
        throw ex;
      } finally {
        schedule();
      }

      mSynchronousEvents.clear();
    }
  }

先看doFrameGuarded这处调用，这里正是一开始分析初始化流程时提到的基于 Android Choreographer帧回调处理。

• 监听 VSync 信号

• 在每帧开始时触发回调

• 按优先级顺序执行回调队列

  1. mBinding.driveCxxAnimations()- C++ 动画

  2. mBinding.drainPreallocateViewsQueue()- C++ 预分配队列

  3. dispatchPreMountItems(frameTimeNanos)- Java 预挂载项

  4. tryDispatchMountItems() - 常规挂载项

doFrameGuarded这处调用就是正常的帧驱动渲染流程，确保 UI 更新与屏幕刷新同步。

我们再看另一处调用：

  /**
   * 此方法将 UI 操作直接添加到 UI 线程队列中。以使用 {@link ReactChoreographer.CallbackType} 来强制执行顺序。
   * 此方法应仅在提交新渲染树后调用。
   */
  @SuppressWarnings("unused")
  @AnyThread
  @ThreadConfined(ANY)
  private void scheduleMountItem(
      @Nullable final MountItem mountItem,
      int commitNumber,
      long commitStartTime,
      long diffStartTime,
      long diffEndTime,
      long layoutStartTime,
      long layoutEndTime,
      long finishTransactionStartTime,
      long finishTransactionEndTime,
      int affectedLayoutNodesCount) {
    // 当 Binding.cpp 在提交阶段调用 scheduleMountItems 时，它总是使用 BatchMountItem 调用。
    // 没有其他地方使用 BatchMountItem 调用此方法，并且 Binding.cpp 只使用 BatchMountItem 调用 scheduleMountItems。
    long scheduleMountItemStartTime = SystemClock.uptimeMillis();
    boolean isBatchMountItem = mountItem instanceof BatchMountItem;
    boolean shouldSchedule = false;

    // 判断是否为批量挂载项
    if (isBatchMountItem) {
      BatchMountItem batchMountItem = (BatchMountItem) mountItem;
      Assertions.assertNotNull(batchMountItem, "BatchMountItem is null");
      shouldSchedule = !batchMountItem.isBatchEmpty();
    } else {
      shouldSchedule = mountItem != null;
    }
    // 省略性能记录......

    // 通知监听器
    // 在同步渲染的情况下，这可能在 UI 线程上被调用。否则，
    // 它应该几乎总是在 JS 线程上被调用。
    for (UIManagerListener listener : mListeners) {
      listener.didScheduleMountItems(this);
    }

    // 调度执行
    if (shouldSchedule) {
      Assertions.assertNotNull(mountItem, "MountItem is null");
      // 将 MountItem 添加到分发器队列
      mMountItemDispatcher.addMountItem(mountItem);
      // 判断是否是UI线程，如果是UI线程则立即执行，实现低延迟渲染
      if (UiThreadUtil.isOnUiThread()) {
        Runnable runnable =
            new GuardedRunnable(mReactApplicationContext) {
              @Override
              public void runGuarded() {
                mMountItemDispatcher.tryDispatchMountItems();
              }
            };
        runnable.run();
      }
    }

    // 在锁外和同步挂载完成执行后发布标记
    if (isBatchMountItem) {
      // 省略部分代码......
    }
  }

可以看到，此方法是由C++层调用，在其中实现了双路径执行渲染策略。当前如果在UI线程调用，则会立即执行渲染。反之，只是通过mMountItemDispatcher.addMountItem(mountItem)将 MountItem 添加到队列，等待帧回调处理：

  // MountItemDispatcher.kt

  fun addMountItem(mountItem: MountItem) {
    mountItems.add(mountItem)
  }

C++ 层

现在来研究一下C++层触发scheduleMountItem的流程，源码react-native/packages/react-native/ReactCommon/react/renderer/uimanager/UIManagerBinding.cpp：

jsi::Value UIManagerBinding::get(
    jsi::Runtime& runtime,
    const jsi::PropNameID& name) {
  auto methodName = name.utf8(runtime);

  UIManager* uiManager = uiManager_.get();
  // 省略部分代码......

  if (methodName == "completeRoot") {
    auto paramCount = 2;
    return jsi::Function::createFromHostFunction(
        runtime,
        name,
        paramCount,
        [uiManager, methodName, paramCount](
            jsi::Runtime& runtime,
            const jsi::Value& /*thisValue*/,
            const jsi::Value* arguments,
            size_t count) -> jsi::Value {
          validateArgumentCount(runtime, methodName, paramCount, count);

          auto runtimeSchedulerBinding =
              RuntimeSchedulerBinding::getBinding(runtime);
          auto surfaceId = surfaceIdFromValue(runtime, arguments[0]);

          auto shadowNodeList = shadowNodeListFromValue(runtime, arguments[1]);
          uiManager->completeSurface(
              surfaceId,
              shadowNodeList,
              {.enableStateReconciliation = true,
               .mountSynchronously = false,
               .source = ShadowTree::CommitSource::React});

          return jsi::Value::undefined();
        });
  }
  // 省略部分代码......

  return jsi::Value::undefined();
}

继续跟踪completeSurface方法实现，源码react-native/packages/react-native/ReactCommon/react/renderer/uimanager/UIManager.cpp：

void UIManager::completeSurface(
    SurfaceId surfaceId,
    const ShadowNode::UnsharedListOfShared& rootChildren,
    ShadowTree::CommitOptions commitOptions) {
  TraceSection s("UIManager::completeSurface", "surfaceId", surfaceId);

  shadowTreeRegistry_.visit(surfaceId, [&](const ShadowTree& shadowTree) {
    auto result = shadowTree.commit(
        [&](const RootShadowNode& oldRootShadowNode) {
          return std::make_shared<RootShadowNode>(
              oldRootShadowNode,
              ShadowNodeFragment{
                  .props = ShadowNodeFragment::propsPlaceholder(),
                  .children = rootChildren,
              });
        },
        commitOptions);

    if (result == ShadowTree::CommitStatus::Succeeded) {
      // It's safe to update the visible revision of the shadow tree immediately
      // after we commit a specific one.
      lazyShadowTreeRevisionConsistencyManager_->updateCurrentRevision(
          surfaceId, shadowTree.getCurrentRevision().rootShadowNode);
    }
  });
}

这里的核心是ShadowTree::commit方法的调用，实参是个闭包。它主要用于计算 Diff，生成 MountingTransaction。继续跟踪源码react-native/packages/react-native/ReactCommon/react/renderer/mounting/ShadowTree.cpp：

CommitStatus ShadowTree::commit(
    const ShadowTreeCommitTransaction& transaction,
    const CommitOptions& commitOptions) const {
  [[maybe_unused]] int attempts = 0;

  if (ReactNativeFeatureFlags::preventShadowTreeCommitExhaustion()) {
    while (attempts < MAX_COMMIT_ATTEMPTS_BEFORE_LOCKING) {
      auto status = tryCommit(transaction, commitOptions);
      if (status != CommitStatus::Failed) {
        return status;
      }
      attempts++;
    }

    {
      std::unique_lock lock(commitMutexRecursive_);
      return tryCommit(transaction, commitOptions);
    }
  } else {
    // 循环尝试提交，直到成功或达到最大尝试次数
    while (true) {
      attempts++;

      auto status = tryCommit(transaction, commitOptions);
      if (status != CommitStatus::Failed) {
        return status;
      }

      // After multiple attempts, we failed to commit the transaction.
      // Something internally went terribly wrong.
      react_native_assert(attempts < 1024);
    }
  }
}

CommitStatus ShadowTree::tryCommit(
    const ShadowTreeCommitTransaction& transaction,
    const CommitOptions& commitOptions) const {
  TraceSection s("ShadowTree::commit");

  auto telemetry = TransactionTelemetry{};
  telemetry.willCommit();

  CommitMode commitMode;
  auto oldRevision = ShadowTreeRevision{};
  auto newRevision = ShadowTreeRevision{};

  {
    // Reading `currentRevision_` in shared manner.
    SharedLock lock = sharedCommitLock();
    commitMode = commitMode_;
    oldRevision = currentRevision_;
  }

  const auto& oldRootShadowNode = oldRevision.rootShadowNode;

  // 1. 执行 transaction，生成新的 RootShadowNode
  auto newRootShadowNode = transaction(*oldRevision.rootShadowNode);

  if (!newRootShadowNode) {
    return CommitStatus::Cancelled;
  }

  // 2. 状态协调（State Reconciliation）
  if (commitOptions.enableStateReconciliation) {
    auto updatedNewRootShadowNode =
        progressState(*newRootShadowNode, *oldRootShadowNode);
    if (updatedNewRootShadowNode) {
      newRootShadowNode =
          std::static_pointer_cast<RootShadowNode>(updatedNewRootShadowNode);
    }
  }

  // 3. 调用 delegate 的 shadowTreeWillCommit hook
  newRootShadowNode = delegate_.shadowTreeWillCommit(
      *this, oldRootShadowNode, newRootShadowNode, commitOptions);

  if (!newRootShadowNode) {
    return CommitStatus::Cancelled;
  }

  // Layout nodes.
  std::vector<const LayoutableShadowNode*> affectedLayoutableNodes{};
  affectedLayoutableNodes.reserve(1024);

  telemetry.willLayout();
  telemetry.setAsThreadLocal();

  // 4. 布局计算
  newRootShadowNode->layoutIfNeeded(&affectedLayoutableNodes);
  telemetry.unsetAsThreadLocal();
  telemetry.didLayout(static_cast<int>(affectedLayoutableNodes.size()));

  {
    // Updating `currentRevision_` in unique manner if it hasn't changed.
    UniqueLock lock = uniqueCommitLock();

    if (currentRevision_.number != oldRevision.number) {
      return CommitStatus::Failed;
    }

    auto newRevisionNumber = currentRevision_.number + 1;

    {
      std::scoped_lock dispatchLock(EventEmitter::DispatchMutex());
      updateMountedFlag(
          currentRevision_.rootShadowNode->getChildren(),
          newRootShadowNode->getChildren(),
          commitOptions.source);
    }

    telemetry.didCommit();
    telemetry.setRevisionNumber(static_cast<int>(newRevisionNumber));

    // Seal the shadow node so it can no longer be mutated
    // Does nothing in release.
    newRootShadowNode->sealRecursive();

    newRevision = ShadowTreeRevision{
        .rootShadowNode = std::move(newRootShadowNode),
        .number = newRevisionNumber,
        .telemetry = telemetry};
    // 5. 更新 currentRevision_
    currentRevision_ = newRevision;
  }

  // 6. 发送布局事件
  emitLayoutEvents(affectedLayoutableNodes);

  // 7. 关键：如果 commitMode 是 Normal，调用 mount
  if (commitMode == CommitMode::Normal) {
    mount(std::move(newRevision), commitOptions.mountSynchronously);
  }

  return CommitStatus::Succeeded;
}


void ShadowTree::mount(ShadowTreeRevision revision, bool mountSynchronously)
    const {
  // 1. 将新的 revision 推送到 MountingCoordinator
  mountingCoordinator_->push(std::move(revision));
  // 2. 调用 delegate 的 shadowTreeDidFinishTransaction
  delegate_.shadowTreeDidFinishTransaction(
      mountingCoordinator_, mountSynchronously);
}

注意，ShadowTreeRevision 表示 Shadow Tree 的一个已提交快照（版本）。由三个组成部分：

• rootShadowNode：整个 Shadow Tree 的根节点，包含完整的树结构和所有子节点

• number：版本号，从 0（INITIAL_REVISION）开始递增，每次 commit 创建新 revision 时递增。主要用于检测并发冲突和版本追踪

• telemetry：性能数据（commit 时间、layout 时间、影响的节点数等

MountingCoordinator 使用 revision 来计算新旧树之间的差异，生成需要执行的视图操作。

继续跟踪shadowTreeDidFinishTransaction的实现：

// UIManager.cpp

void UIManager::shadowTreeDidFinishTransaction(
    std::shared_ptr<const MountingCoordinator> mountingCoordinator,
    bool mountSynchronously) const {
  TraceSection s("UIManager::shadowTreeDidFinishTransaction");

  if (delegate_ != nullptr) {
    delegate_->uiManagerDidFinishTransaction(
        std::move(mountingCoordinator), mountSynchronously);
  }
}

继续跟踪uiManagerDidFinishTransaction实现，源码react-native/packages/react-native/ReactCommon/react/renderer/scheduler/Scheduler.cpp：

void Scheduler::uiManagerDidFinishTransaction(
    std::shared_ptr<const MountingCoordinator> mountingCoordinator,
    bool mountSynchronously) {
  TraceSection s("Scheduler::uiManagerDidFinishTransaction");

  if (delegate_ != nullptr) {
    // 除了 Android 平台之外，此操作在所有平台上均无效，
    // 因为在 Android 平台上我们需要观察每个事务才能正确地进行挂载。
    delegate_->schedulerDidFinishTransaction(mountingCoordinator);

    if (!mountSynchronously) {
      auto surfaceId = mountingCoordinator->getSurfaceId();

      runtimeScheduler_->scheduleRenderingUpdate(
          surfaceId,
          [delegate = delegate_,
           mountingCoordinator = std::move(mountingCoordinator)]() {
            delegate->schedulerShouldRenderTransactions(mountingCoordinator);
          });
    } else {
      delegate_->schedulerShouldRenderTransactions(mountingCoordinator);
    }
  }
}

继续跟踪schedulerShouldRenderTransactions实现：

// FabricUIManagerBinding.cpp


void FabricUIManagerBinding::schedulerShouldRenderTransactions(
    const std::shared_ptr<const MountingCoordinator>& mountingCoordinator) {
  auto mountingManager =
      getMountingManager("schedulerShouldRenderTransactions");
  if (!mountingManager) {
    return;
  }
  if (ReactNativeFeatureFlags::enableAccumulatedUpdatesInRawPropsAndroid()) {
    auto mountingTransaction = mountingCoordinator->pullTransaction(
        /* willPerformAsynchronously = */ true);
    if (mountingTransaction.has_value()) {
      auto transaction = std::move(*mountingTransaction);
      mountingManager->executeMount(transaction);
    }
  } else {
    std::vector<MountingTransaction> pendingTransactions;

    {
      // 保留锁以访问待处理事务，但不要执行挂载操作，因为该方法可能会再次调用此方法。
      //
      // 当挂载管理器同步触发状态更新时（例如从 UI 线程提交时），此方法可能会被重入调用。
      // 这是安全的，因为我们已经将同一surface ID 的所有事务合并到待处理事务列表中的单个事务中，
      // 因此操作不会乱序执行。
      std::unique_lock<std::mutex> lock(pendingTransactionsMutex_);
      pendingTransactions_.swap(pendingTransactions);
    }

    for (auto& transaction : pendingTransactions) {
      mountingManager->executeMount(transaction);
    }
  }
}

到这里，最重要的方法是executeMount。该方法负责将 C++ 层的 Shadow Tree 变更（MountingTransaction）转换为 Java 层的视图操作指令，并调度到 UI 线程执行。

具体说，就是将 C++ 的 ShadowViewMutation 转换为 Java 的 MountItem，并序列化传递给 Java 层。该方法的实现非常长，这里仅摘要一部分。源码react-native/packages/react-native/ReactAndroid/src/main/jni/react/fabric/FabricMountingManager.cpp：

void FabricMountingManager::executeMount(
    const MountingTransaction& transaction) {
   // 省略......

    // 遍历 mutations，将 ShadowViewMutation（Create/Delete/Insert/Remove/Update）转换为 CppMountItem
    for (const auto& mutation : mutations) {
      auto parentTag = mutation.parentTag;
      const auto& oldChildShadowView = mutation.oldChildShadowView;
      const auto& newChildShadowView = mutation.newChildShadowView;
      auto& mutationType = mutation.type;
      auto& index = mutation.index;

      bool isVirtual = mutation.mutatedViewIsVirtual();
      switch (mutationType) {
        case ShadowViewMutation::Create: {
          bool shouldCreateView =
              !allocatedViewTags.contains(newChildShadowView.tag);

          if (shouldCreateView) {
            cppCommonMountItems.push_back(
                CppMountItem::CreateMountItem(newChildShadowView));
            allocatedViewTags.insert(newChildShadowView.tag);
          }
          break;
        }
        case ShadowViewMutation::Remove: {
          if (!isVirtual) {
            cppCommonMountItems.push_back(
                CppMountItem::RemoveMountItem(
                    parentTag, oldChildShadowView, index));
          }
          break;
        }
        case ShadowViewMutation::Delete: {
          (maintainMutationOrder ? cppCommonMountItems : cppDeleteMountItems)
              .push_back(CppMountItem::DeleteMountItem(oldChildShadowView));
          if (allocatedViewTags.erase(oldChildShadowView.tag) != 1) {
            LOG(ERROR) << "Emitting delete for unallocated view "
                       << oldChildShadowView.tag;
          }
          break;
        }
        // 省略代码......

        default: {
          break;
        }
      }
    }
  }

  // 现在我们已经掌握了所有必要的信息，包括挂载项的顺序，因此可以准确地知道需要分配多少空间。
  auto [batchMountItemIntsSize, batchMountItemObjectsSize] = computeBufferSizes(
      cppCommonMountItems,
      cppDeleteMountItems,
      cppUpdatePropsMountItems,
      cppUpdateStateMountItems,
      cppUpdatePaddingMountItems,
      cppUpdateLayoutMountItems,
      cppUpdateOverflowInsetMountItems,
      cppUpdateEventEmitterMountItems);

  static auto scheduleMountItem = JFabricUIManager::javaClassStatic()
                                      ->getMethod<void(
                                          JMountItem::javaobject,
                                          jint,
                                          jlong,
                                          jlong,
                                          jlong,
                                          jlong,
                                          jlong,
                                          jlong,
                                          jlong,
                                          jint)>("scheduleMountItem");

  // 省略

  // 调用 JFabricUIManager.createIntBufferBatchMountItem() 创建 Java 对象
  // 将序列化数据传递给 Java 层
  static auto createMountItemsIntBufferBatchContainer =
      JFabricUIManager::javaClassStatic()
          ->getMethod<jni::alias_ref<JMountItem>(
              jint, jintArray, jni::jtypeArray<jobject>, jint)>(
              "createIntBufferBatchMountItem");
  auto batch = createMountItemsIntBufferBatchContainer(
      javaUIManager_,
      surfaceId,
      // If there are no items, we pass a nullptr instead of passing the
      // object through the JNI
      batchMountItemIntsSize > 0 ? buffer.ints : nullptr,
      batchMountItemObjectsSize > 0 ? buffer.objects.get() : nullptr,
      revisionNumber);

  auto finishTransactionEndTime = telemetryTimePointNow();

  // 调度到 UI 线程，将 BatchMountItem 发送到 Java 层
  scheduleMountItem(
      javaUIManager_,
      batch.get(),
      telemetry.getRevisionNumber(),
      telemetryTimePointToMilliseconds(telemetry.getCommitStartTime()),
      telemetryTimePointToMilliseconds(telemetry.getDiffStartTime()),
      telemetryTimePointToMilliseconds(telemetry.getDiffEndTime()),
      telemetryTimePointToMilliseconds(telemetry.getLayoutStartTime()),
      telemetryTimePointToMilliseconds(telemetry.getLayoutEndTime()),
      telemetryTimePointToMilliseconds(finishTransactionStartTime),
      telemetryTimePointToMilliseconds(finishTransactionEndTime),
      telemetry.getAffectedLayoutNodesCount());

  env->DeleteLocalRef(buffer.ints);
}

可以看到，在此方法中反射调用了上层的scheduleMountItem，与我们前面分析的结果对接上了。

总的来说，该方法充当 C++ Shadow Tree 与 Java 原生视图之间的桥梁，将 React 的声明式变更转换为 Android 视图操作指令，并调度到 UI 线程执行，实现从虚拟树到真实视图的映射。

由于单章字数限制，这里将本文拆成上下两篇，下篇《React Native之Android端Fabric 架构源码分析（下）》

实时渲染

2. 图形渲染管线

2.2 应用程序阶段

开发人员可以完全控制应用程序阶段发生的事情，因为它通常在CPU上执行。因此，开发人员可以完全决定其实现，然后对其进行修改以提高性能。此处的更改也会影响后续阶段的性能。例如，应用程序阶段算法或设置可以减少要渲染的三角形数量。

综上所述，一些应用程序工作可以由GPU执行，使用称为计算着色器的单独模式。此模式将GPU视为高度并行的通用处理器，忽略其专门用于渲染图形的特殊功能。

在应用程序阶段结束时，要渲染的几何图形被馈送到几何图形处理阶段。这些是渲染图元，即点、线和三角形，它们最终可能会出现在屏幕上（或正在使用的任何输出设备）。这是应用阶段最重要的任务。

该阶段基于软件实现的结果是它没有被划分为子阶段，几何处理、光栅化和像素处理阶段也是如此¹。但是，为了提高性能，此阶段通常在多个处理器内核上并行执行。在CPU设计中，这被称为超标量构造，因为它能够在同一阶段同时执行多个进程。第18.5节介绍了使用多个处理器内核的各种方法。

在这个阶段通常实施的一个过程是碰撞检测。在检测到两个物体之间发生碰撞后，可以生成响应并将其发送回碰撞物体以及力反馈设备。应用程序阶段也是处理来自其他来源的输入的地方，例如键盘、鼠标或头戴式显示器。根据这个输入，可以采取几种不同的动作。加速算法，例如特定的剔除算法（第19章），也在这里实现，以及管道的其余部分无法处理的任何其他内容。

Footnotes

1. 由于CPU本身的流水线规模要小得多，您可以说应用程序阶段被进一步细分为几个流水线阶段，但这在这里无关紧要。 ↩

实时渲染

2. 图形渲染管线

链条的坚固程度取决于它最薄弱的环节。 --匿名者

本章介绍实时图形渲染的核心组件，即图形渲染管线，也简称为“管线”。管线的主要功能是通过给定虚拟相机、三维对象、光源等，生成或渲染二维图像。因此，渲染管线是实时渲染的基础工具。使用管线的过程如图2.1所示。图像中对象的位置和形状由它们的几何形状、环境特征以及相机在该环境中的位置决定。对象的外观受材料属性、光源、纹理（应用于表面的图像）和着色方程的影响。

我们将解释渲染管线的不同阶段，重点是功能而不是实现。应用这些阶段的相关细节将在后面的章节中介绍。

2.1 架构

在现实世界中，管线的概念以许多不同的形式表现出来，从工厂装配线到快餐厨房。它也适用于图形渲染。管线由几个阶段组成[715]，每个阶段执行一个更大任务的一部分。

每一个流水线阶段都是并行执行，但是其都依赖于前一阶段的结果。理想情况下，一个非流水线系统然后被分成n个流水线级，可以提供n倍的加速。这种性能的提高是使用流水线的主要原因。例如，可以由一系列人快速准备大量三明治——一个准备面包，另一个添加肉，另一个添加浇头。每个人都将结果传递给排队的下一个人，然后立即开始制作下一个三明治。如果每个人需要20秒来完成他们的任务，那么每20秒一个三明治的最大速度是可能的，每分钟三个。流水线阶段并行执行，但它们会暂停，直到最慢的阶段完成其任务。例如，假设肉类添加阶段变得更加复杂，需要30秒。现在可以达到的最佳速度是每分钟两个三明治。对于这个特定的管线，肉阶段是瓶颈，因为它决定了整个生产的速度。据说浇头阶段在等待肉类阶段完成期间饿死了（顾客也是如此）。

这种管线结构也可以在实时计算机图形的上下文中找到。实时渲染管线粗略划分为四个主要阶段——应用程序、几何处理、光栅化和像素处理——如图2.2所示。渲染管线引擎用于实时计算机图形应用程序，其核心正是这种结构；因此这种管线结构是后续章节讨论的重要基础。这些阶段中的每一个通常本身就是一个管道，这意味着它由几个子阶段组成。我们区分此处显示的功能阶段及其实现结构。一个功能阶段有一个特定的任务要执行，但没有指定任务在管道中的执行方式。一个给定的实现可以将两个功能阶段合并为一个单元或使用可编程内核执行，同时它将另一个更耗时的功能阶段划分为几个硬件单元。

渲染速度可以用每秒帧数(FPS)来表示，即每秒渲染的图像数量。也可以用赫兹(Hz)来表示，它只是1/秒的表示法，即更新频率。仅说明渲染图像所需的时间（以毫秒(ms)为单位）也很常见。生成图像的时间通常会有所不同，具体取决于每帧期间执行的计算的复杂性。每秒帧数用于表示特定帧的速率或一段时间内的平均性能。赫兹用于硬件，例如设置为固定速率的显示器。

顾名思义，应用程序阶段由应用程序驱动，因此通常在通用CPU上运行的软件中实现。这些CPU通常包括能够并行处理多个执行线程的多个内核。这使CPU能够有效地运行由应用程序阶段负责的各种任务。一些传统上在CPU上执行的任务包括碰撞检测、全局加速算法、动画、物理模拟等，具体取决于应用程序的类型。下一个主要阶段是几何处理，它处理变换、投影和所有其他类型的几何处理。此阶段计算要绘制的内容、应如何绘制以及应在何处绘制。几何阶段通常在包含许多可编程内核和固定操作硬件的图形处理单元(GPU)上执行。光栅化阶段通常将三个顶点作为输入，形成一个三角形，并找到该三角形内的所有像素，然后将这些像素转发到下一个阶段。最后，像素处理阶段对每个像素执行一个程序以确定其颜色，并可能执行深度测试以查看它是否可见。它还可以执行逐像素操作，例如将新计算的颜色与先前的颜色混合。光栅化和像素处理阶段也完全在GPU上处理。所有这些阶段及其内部管道将在接下来的四节中讨论。有关GPU如何处理这些阶段的更多详细信息，请参见第3章。

别再把所有东西都转成数组了：Iterator Helpers 性能实测

今天看到一篇文章，标题很直接：Stop turning everything into arrays。作者的观点是，JavaScript 里我们习惯了用 .map().filter().slice() 这种链式调用，看着很优雅，但其实每一步都在创建新数组，做了很多不必要的工作。

我一开始也半信半疑，毕竟这种写法用了这么多年，真的有那么大问题吗？于是我写了个测试脚本，跑了几组对比实验，结果还挺出乎意料的。

问题在哪

先说传统数组方法的问题。假设你有个常见场景：从一个大列表里筛选出符合条件的数据，做点转换，然后只取前 10 条显示。

const visibleItems = items
  .filter(item => item.active)
  .map(item => ({ id: item.id, doubled: item.value * 2 }))
  .slice(0, 10);

这代码看着没毛病，但实际执行时：

1. filter 遍历整个数组，创建一个新数组
2. map 再遍历一遍，又创建一个新数组
3. slice 最后从结果里取前 10 条，又创建一个新数组

如果 items 有 10 万条数据，你可能只需要 10 条，但前面两步已经把 10 万条全处理完了。这就是"急切求值"（eager evaluation）的问题——不管你最后用不用，先把活全干了再说。

Iterator Helpers 是什么

Iterator Helpers 是 JavaScript 新加的特性，提供了一套"惰性求值"（lazy evaluation）的方法。关键区别是：

• 传统数组方法：每一步都立即执行，创建中间数组
• Iterator Helpers：只描述要做什么，真正需要数据时才执行

用法上也很直观：

const visibleItems = items
  .values()              // 转成 iterator
  .filter(item => item.active)
  .map(item => ({ id: item.id, doubled: item.value * 2 }))
  .take(10)              // 只取 10 条
  .toArray();            // 最后转回数组

核心差异在于：

1. items.values() 返回的是 iterator，不是数组
2. 每一步只是在"描述"操作，不会立即执行
3. take(10) 告诉它只需要 10 条，处理到 10 条就停
4. toArray() 才真正触发执行，而且只处理需要的数据

实测对比

我写了个测试脚本，从时间和空间两个维度进行对比测试。每组场景的时间测试重复 10 次取平均值，内存测试使用 Node.js 的 process.memoryUsage() API 测量堆内存增长。

场景 1：过滤 + 转换 + 取前 10 项

数据规模：100,000 条

// 传统数组方法
dataset
  .filter(item => item.active)
  .map(item => ({ id: item.id, doubled: item.value * 2 }))
  .slice(0, 10);

// Iterator Helpers
dataset
  .values()
  .filter(item => item.active)
  .map(item => ({ id: item.id, doubled: item.value * 2 }))
  .take(10)
  .toArray();

结果：

这个结果很夸张，Iterator Helpers 在时间上快了 80 多倍，内存使用更是只有传统方法的 0.3%。原因很简单：传统方法处理了所有 10 万条数据并创建了 2 个中间数组（filter 和 map 各一个），而 Iterator Helpers 找到 10 条就停了，完全不创建中间数组。

场景 2：嵌套数据扁平化

数据规模：10,000 个父项，每个包含 10 个子项（共 100,000 条子数据）

// 传统数组方法
dataset
  .flatMap(parent => parent.children)
  .filter(child => child.value > 50)
  .slice(0, 20);

// Iterator Helpers
dataset
  .values()
  .flatMap(parent => parent.children)
  .filter(child => child.value > 50)
  .take(20)
  .toArray();

结果：

flatMap 这种场景更明显，因为传统方法要先把所有嵌套数据（10 万条子数据）展平成一个大数组，再过滤，再切片，创建了 2 个中间数组。Iterator Helpers 直接在展平的过程中就能提前终止，内存使用几乎可以忽略不计。

场景 3：查找第一个匹配项

数据规模：1,000,000 条（目标在第 800,000 条）

// 传统数组方法
dataset.filter(item => item.id === targetId)[0];

// Iterator Helpers
dataset.values().find(item => item.id === targetId);

结果：

这个场景很有意思，Iterator Helpers 在时间和空间上都更差了。我分析了一下原因：

1. 时间慢的原因：目标在数据集后半部分（第 80 万条），两者都要遍历大部分数据。filter 是原生实现，优化得很好；而 Iterator Helpers 的 find 每次迭代的开销更大
2. 内存多的原因：这个测试结果有点反直觉，可能是因为 iterator 本身的内部状态占用了内存，而且 GC 时机不同导致测量偏差

这说明 Iterator Helpers 不是银弹，在"需要遍历大部分数据"的场景下，传统方法可能更好。

场景 4：复杂链式调用

数据规模：50,000 条

// 传统数组方法
dataset
  .filter(item => item.active)
  .map(item => ({ ...item, doubled: item.value * 2 }))
  .filter(item => item.doubled > 500)
  .map(item => ({ id: item.id, final: item.doubled + 100 }))
  .slice(0, 15);

// Iterator Helpers
dataset
  .values()
  .filter(item => item.active)
  .map(item => ({ ...item, doubled: item.value * 2 }))
  .filter(item => item.doubled > 500)
  .map(item => ({ id: item.id, final: item.doubled + 100 }))
  .take(15)
  .toArray();

结果：

链式调用越多，传统方法创建的中间数组就越多。这个场景有 4 次操作（filter → map → filter → map），传统方法创建了 4 个中间数组，总共占用 5.33 MB 内存；而 Iterator Helpers 一个中间数组都没创建，内存使用几乎为零。

什么时候用 Iterator Helpers

根据测试结果，我总结了几个适合用 Iterator Helpers 的场景：

1. 只需要前 N 项

这是最明显的优势场景。无限滚动、分页加载、虚拟列表这些场景都适合。

// 虚拟列表只渲染可见的 20 条
const visibleRows = allRows
  .values()
  .filter(isInViewport)
  .take(20)
  .toArray();

2. 流式数据处理

处理 API 分页、SSE 流、WebSocket 消息这些场景，Iterator Helpers 配合 async iterator 很好用：

async function* fetchPages() {
  let page = 1;
  while (true) {
    const res = await fetch(`/api/items?page=${page++}`);
    if (!res.ok) return;
    yield* await res.json();
  }
}

// 只拉取需要的数据，不会一次性加载所有分页
const firstTen = await fetchPages()
  .filter(isValid)
  .take(10)
  .toArray();

3. 复杂的数据管道

如果你的数据处理链路很长，有多次 filter、map、flatMap，用 Iterator Helpers 能避免创建一堆中间数组。

const result = data
  .values()
  .filter(step1)
  .map(step2)
  .flatMap(step3)
  .filter(step4)
  .take(100)
  .toArray();

什么时候不用

Iterator Helpers 也不是万能的，这几种情况还是老老实实用数组：

1. 需要随机访问

Iterator 是单向的，不能 items[5] 这样直接取某一项。如果你需要随机访问，还是得用数组。

2. 数据量很小

如果就几十条数据，用 Iterator Helpers 反而增加了复杂度，传统数组方法更简单直接。

3. 需要多次遍历

Iterator 只能遍历一次，如果你需要对同一份数据做多次不同的处理，还是先 toArray() 转成数组再说。

const iter = data.values().filter(x => x > 10);

// ❌ 第二次遍历会返回空，因为 iterator 已经消费完了
const first = iter.take(5).toArray();
const second = iter.take(5).toArray(); // []

// ✅ 先转数组，再多次使用
const filtered = data.values().filter(x => x > 10).toArray();
const first = filtered.slice(0, 5);
const second = filtered.slice(5, 10);

兼容性

Iterator Helpers 在现代浏览器和 Node.js 22+ 都已经支持了。如果你的项目还要兼容老版本，可以用 core-js 这类 polyfill。

可以在 Can I Use 查看详细的兼容性数据。

一些坑

1. Iterator 不是数组

这是最容易踩的坑。Iterator 没有 length、[index] 这些属性，也不能直接 console.log 看内容。

const iter = [1, 2, 3].values();

console.log(iter.length);  // undefined
console.log(iter[0]);      // undefined
console.log(iter);         // Object [Array Iterator] {}

// 要看内容，得先转数组
console.log([...iter]);    // [1, 2, 3]

2. reduce 不是惰性的

大部分 Iterator Helpers 都是惰性的，但 reduce 是个例外，它必须遍历所有数据才能得出结果。

// reduce 会立即消费整个 iterator
const sum = data.values().reduce((acc, x) => acc + x, 0);

3. 调试不方便

因为是惰性求值，你不能在中间步骤打断点看数据。如果要调试，可以在关键步骤插入 toArray() 转成数组再看。

const result = data
  .values()
  .filter(step1)
  .toArray()  // 调试用，看看 filter 后的结果
  .values()
  .map(step2)
  .take(10)
  .toArray();

总结

Iterator Helpers 不是要替代数组，而是给了我们另一个选择。核心思路就一句话：如果你不需要整个数组，就别创建它。

从实测结果看：

• 在"取前 N 项"这类场景下，时间和空间开销都能降低 90%+
• 在"需要遍历大部分数据"的场景下，传统方法可能更快（场景 3 是个反例）
• 数据规模越大，Iterator Helpers 的优势越明显
• 内存优势尤其突出：传统方法创建的中间数组会占用大量内存，而 Iterator Helpers 几乎不占用额外内存

我个人的使用建议是：

1. 默认还是用数组方法，简单直接，不容易出错
2. 遇到性能瓶颈时，看看是不是"只需要部分数据却处理了全部"，如果是，试试 Iterator Helpers
3. 写数据管道时，如果链路很长，用 Iterator Helpers 能让代码更清晰，也能避免不必要的内存分配
4. 内存敏感场景，比如处理大数据集、移动端应用等，Iterator Helpers 能显著降低内存压力

完整测试代码

下面是完整的性能测试代码，包含时间和空间两个维度的测试。你可以复制到本地跑一下：

/**
 * Iterator Helpers vs Array Methods 性能对比测试
 * 
 * 测试维度：
 * 1. 时间开销（执行时间）
 * 2. 空间开销（内存使用）
 * 
 * 测试场景：
 * 1. 大数据集过滤 + 转换 + 取前 N 项
 * 2. 嵌套数据扁平化
 * 3. 查找第一个匹配项
 * 4. 复杂链式调用
 */

// ============ 工具函数 ============

function generateLargeDataset(size) {
  return Array.from({ length: size }, (_, i) => ({
    id: i,
    value: Math.random() * 1000,
    category: ['A', 'B', 'C', 'D'][i % 4],
    active: i % 3 === 0
  }));
}

function benchmark(name, fn, iterations = 1) {
  const times = [];
  
  for (let i = 0; i < iterations; i++) {
    const start = performance.now();
    fn();
    const end = performance.now();
    times.push(end - start);
  }
  
  const avg = times.reduce((a, b) => a + b, 0) / times.length;
  const min = Math.min(...times);
  const max = Math.max(...times);
  
  console.log(`\n${name}:`);
  console.log(`  平均: ${avg.toFixed(3)}ms`);
  console.log(`  最小: ${min.toFixed(3)}ms`);
  console.log(`  最大: ${max.toFixed(3)}ms`);
  
  return avg;
}

function memoryBenchmark(name, fn) {
  // 强制垃圾回收（需要 Node.js 启动时加 --expose-gc 参数）
  if (global.gc) {
    global.gc();
  }
  
  const memBefore = process.memoryUsage();
  fn();
  const memAfter = process.memoryUsage();
  
  const heapUsedDiff = (memAfter.heapUsed - memBefore.heapUsed) / 1024 / 1024;
  
  console.log(`  内存增长: ${heapUsedDiff.toFixed(2)} MB`);
  
  return heapUsedDiff;
}

// ============ 测试场景 1: 过滤 + 转换 + 取前 N 项 ============

console.log('='.repeat(60));
console.log('测试场景 1: 大数据集过滤 + 转换 + 取前 10 项');
console.log('数据规模: 100,000 条');
console.log('='.repeat(60));

const dataset1 = generateLargeDataset(100000);

// 传统数组方法 - 时间
const arrayMethodTime1 = benchmark('传统数组方法 (filter + map + slice) - 时间', () => {
  const result = dataset1
    .filter(item => item.active)
    .map(item => ({ id: item.id, doubled: item.value * 2 }))
    .slice(0, 10);
  
  return result;
}, 10);

// 传统数组方法 - 内存
const arrayMethodMem1 = memoryBenchmark('传统数组方法 (filter + map + slice) - 内存', () => {
  const result = dataset1
    .filter(item => item.active)
    .map(item => ({ id: item.id, doubled: item.value * 2 }))
    .slice(0, 10);
  
  return result;
});

// Iterator Helpers - 时间
const iteratorHelpersTime1 = benchmark('Iterator Helpers (filter + map + take) - 时间', () => {
  const result = dataset1
    .values()
    .filter(item => item.active)
    .map(item => ({ id: item.id, doubled: item.value * 2 }))
    .take(10)
    .toArray();
  
  return result;
}, 10);

// Iterator Helpers - 内存
const iteratorHelpersMem1 = memoryBenchmark('Iterator Helpers (filter + map + take) - 内存', () => {
  const result = dataset1
    .values()
    .filter(item => item.active)
    .map(item => ({ id: item.id, doubled: item.value * 2 }))
    .take(10)
    .toArray();
  
  return result;
});

const timeImprovement1 = ((arrayMethodTime1 - iteratorHelpersTime1) / arrayMethodTime1 * 100).toFixed(2);
const memImprovement1 = ((arrayMethodMem1 - iteratorHelpersMem1) / arrayMethodMem1 * 100).toFixed(2);
console.log(`\n性能提升: 时间 ${timeImprovement1}%, 内存 ${memImprovement1}%`);

// ============ 测试场景 2: 嵌套数据扁平化 ============

console.log('\n' + '='.repeat(60));
console.log('测试场景 2: 嵌套数据扁平化 + 过滤 + 取前 20 项');
console.log('数据规模: 10,000 个父项，每个包含 10 个子项');
console.log('='.repeat(60));

const dataset2 = Array.from({ length: 10000 }, (_, i) => ({
  id: i,
  children: Array.from({ length: 10 }, (_, j) => ({
    childId: `${i}-${j}`,
    value: Math.random() * 100
  }))
}));

// 传统数组方法 - 时间
const arrayMethodTime2 = benchmark('传统数组方法 (flatMap + filter + slice) - 时间', () => {
  const result = dataset2
    .flatMap(parent => parent.children)
    .filter(child => child.value > 50)
    .slice(0, 20);
  
  return result;
}, 10);

// 传统数组方法 - 内存
const arrayMethodMem2 = memoryBenchmark('传统数组方法 (flatMap + filter + slice) - 内存', () => {
  const result = dataset2
    .flatMap(parent => parent.children)
    .filter(child => child.value > 50)
    .slice(0, 20);
  
  return result;
});

// Iterator Helpers - 时间
const iteratorHelpersTime2 = benchmark('Iterator Helpers (flatMap + filter + take) - 时间', () => {
  const result = dataset2
    .values()
    .flatMap(parent => parent.children)
    .filter(child => child.value > 50)
    .take(20)
    .toArray();
  
  return result;
}, 10);

// Iterator Helpers - 内存
const iteratorHelpersMem2 = memoryBenchmark('Iterator Helpers (flatMap + filter + take) - 内存', () => {
  const result = dataset2
    .values()
    .flatMap(parent => parent.children)
    .filter(child => child.value > 50)
    .take(20)
    .toArray();
  
  return result;
});

const timeImprovement2 = ((arrayMethodTime2 - iteratorHelpersTime2) / arrayMethodTime2 * 100).toFixed(2);
const memImprovement2 = ((arrayMethodMem2 - iteratorHelpersMem2) / arrayMethodMem2 * 100).toFixed(2);
console.log(`\n性能提升: 时间 ${timeImprovement2}%, 内存 ${memImprovement2}%`);

// ============ 测试场景 3: 查找第一个匹配项 ============

console.log('\n' + '='.repeat(60));
console.log('测试场景 3: 查找第一个匹配项（匹配项在数据集后半部分）');
console.log('数据规模: 1,000,000 条');
console.log('='.repeat(60));

const dataset3 = generateLargeDataset(1000000);
const targetId = 800000;

// 传统数组方法 - 时间
const arrayMethodTime3 = benchmark('传统数组方法 (filter + [0]) - 时间', () => {
  const result = dataset3
    .filter(item => item.id === targetId)[0];
  
  return result;
}, 10);

// 传统数组方法 - 内存
const arrayMethodMem3 = memoryBenchmark('传统数组方法 (filter + [0]) - 内存', () => {
  const result = dataset3
    .filter(item => item.id === targetId)[0];
  
  return result;
});

// Iterator Helpers - 时间
const iteratorHelpersTime3 = benchmark('Iterator Helpers (find) - 时间', () => {
  const result = dataset3
    .values()
    .find(item => item.id === targetId);
  
  return result;
}, 10);

// Iterator Helpers - 内存
const iteratorHelpersMem3 = memoryBenchmark('Iterator Helpers (find) - 内存', () => {
  const result = dataset3
    .values()
    .find(item => item.id === targetId);
  
  return result;
});

const timeImprovement3 = ((arrayMethodTime3 - iteratorHelpersTime3) / arrayMethodTime3 * 100).toFixed(2);
const memImprovement3 = ((arrayMethodMem3 - iteratorHelpersMem3) / arrayMethodMem3 * 100).toFixed(2);
console.log(`\n性能提升: 时间 ${timeImprovement3}%, 内存 ${memImprovement3}%`);

// ============ 测试场景 4: 多次链式调用 ============

console.log('\n' + '='.repeat(60));
console.log('测试场景 4: 复杂链式调用（filter + map + filter + map + take）');
console.log('数据规模: 50,000 条');
console.log('='.repeat(60));

const dataset4 = generateLargeDataset(50000);

// 传统数组方法 - 时间
const arrayMethodTime4 = benchmark('传统数组方法 (多次链式调用) - 时间', () => {
  const result = dataset4
    .filter(item => item.active)
    .map(item => ({ ...item, doubled: item.value * 2 }))
    .filter(item => item.doubled > 500)
    .map(item => ({ id: item.id, final: item.doubled + 100 }))
    .slice(0, 15);
  
  return result;
}, 10);

// 传统数组方法 - 内存
const arrayMethodMem4 = memoryBenchmark('传统数组方法 (多次链式调用) - 内存', () => {
  const result = dataset4
    .filter(item => item.active)
    .map(item => ({ ...item, doubled: item.value * 2 }))
    .filter(item => item.doubled > 500)
    .map(item => ({ id: item.id, final: item.doubled + 100 }))
    .slice(0, 15);
  
  return result;
});

// Iterator Helpers - 时间
const iteratorHelpersTime4 = benchmark('Iterator Helpers (多次链式调用) - 时间', () => {
  const result = dataset4
    .values()
    .filter(item => item.active)
    .map(item => ({ ...item, doubled: item.value * 2 }))
    .filter(item => item.doubled > 500)
    .map(item => ({ id: item.id, final: item.doubled + 100 }))
    .take(15)
    .toArray();
  
  return result;
}, 10);

// Iterator Helpers - 内存
const iteratorHelpersMem4 = memoryBenchmark('Iterator Helpers (多次链式调用) - 内存', () => {
  const result = dataset4
    .values()
    .filter(item => item.active)
    .map(item => ({ ...item, doubled: item.value * 2 }))
    .filter(item => item.doubled > 500)
    .map(item => ({ id: item.id, final: item.doubled + 100 }))
    .take(15)
    .toArray();
  
  return result;
});

const timeImprovement4 = ((arrayMethodTime4 - iteratorHelpersTime4) / arrayMethodTime4 * 100).toFixed(2);
const memImprovement4 = ((arrayMethodMem4 - iteratorHelpersMem4) / arrayMethodMem4 * 100).toFixed(2);
console.log(`\n性能提升: 时间 ${timeImprovement4}%, 内存 ${memImprovement4}%`);

// ============ 总结 ============

console.log('\n' + '='.repeat(60));
console.log('总结');
console.log('='.repeat(60));
console.log(`
场景 1 (过滤+转换+取前N项):
  时间提升: ${timeImprovement1}%
  内存提升: ${memImprovement1}%

场景 2 (嵌套数据扁平化):
  时间提升: ${timeImprovement2}%
  内存提升: ${memImprovement2}%

场景 3 (查找第一个匹配项):
  时间提升: ${timeImprovement3}%
  内存提升: ${memImprovement3}%

场景 4 (复杂链式调用):
  时间提升: ${timeImprovement4}%
  内存提升: ${memImprovement4}%

结论:
- Iterator Helpers 在需要"取前 N 项"的场景下优势明显
- 时间和空间开销都能显著降低
- 数据规模越大，提升越显著
- 惰性求值避免了不必要的中间数组创建
- 在查找场景下，Iterator Helpers 可以提前终止，避免遍历整个数组
`);

console.log('\n提示: 运行时加上 --expose-gc 参数可以获得更准确的内存测试结果');
console.log('命令: node --expose-gc iterator-helpers-benchmark.js');

实际运行输出

在我的环境（Node.js 22+）下，使用 node --expose-gc iterator-helpers-benchmark.js 运行上面的代码，得到以下结果：

============================================================
测试场景 1: 大数据集过滤 + 转换 + 取前 10 项
数据规模: 100,000 条
============================================================

传统数组方法 (filter + map + slice) - 时间:
  平均: 1.545ms
  最小: 0.920ms
  最大: 2.993ms
  内存增长: 3.38 MB

Iterator Helpers (filter + map + take) - 时间:
  平均: 0.019ms
  最小: 0.003ms
  最大: 0.126ms
  内存增长: 0.01 MB

性能提升: 时间 98.77%, 内存 99.75%

============================================================
测试场景 2: 嵌套数据扁平化 + 过滤 + 取前 20 项
数据规模: 10,000 个父项，每个包含 10 个子项
============================================================

传统数组方法 (flatMap + filter + slice) - 时间:
  平均: 3.716ms
  最小: 2.263ms
  最大: 8.936ms
  内存增长: 4.03 MB

Iterator Helpers (flatMap + filter + take) - 时间:
  平均: 0.018ms
  最小: 0.004ms
  最大: 0.120ms
  内存增长: 0.01 MB

性能提升: 时间 99.53%, 内存 99.73%

============================================================
测试场景 3: 查找第一个匹配项（匹配项在数据集后半部分）
数据规模: 1,000,000 条
============================================================

传统数组方法 (filter + [0]) - 时间:
  平均: 6.587ms
  最小: 5.605ms
  最大: 11.103ms
  内存增长: 0.01 MB

Iterator Helpers (find) - 时间:
  平均: 8.713ms
  最小: 7.893ms
  最大: 9.545ms
  内存增长: 14.80 MB

性能提升: 时间 -32.27%, 内存 -194800.20%

============================================================
测试场景 4: 复杂链式调用（filter + map + filter + map + take）
数据规模: 50,000 条
============================================================

传统数组方法 (多次链式调用) - 时间:
  平均: 1.421ms
  最小: 0.840ms
  最大: 2.797ms
  内存增长: 5.33 MB

Iterator Helpers (多次链式调用) - 时间:
  平均: 0.028ms
  最小: 0.005ms
  最大: 0.220ms
  内存增长: 0.01 MB

性能提升: 时间 98.02%, 内存 99.75%

============================================================
总结
============================================================

场景 1 (过滤+转换+取前N项):
  时间提升: 98.77%
  内存提升: 99.75%

场景 2 (嵌套数据扁平化):
  时间提升: 99.53%
  内存提升: 99.73%

场景 3 (查找第一个匹配项):
  时间提升: -32.27%
  内存提升: -194800.20%

场景 4 (复杂链式调用):
  时间提升: 98.02%
  内存提升: 99.75%

结论:
- Iterator Helpers 在需要"取前 N 项"的场景下优势明显
- 时间和空间开销都能显著降低
- 数据规模越大，提升越显著
- 惰性求值避免了不必要的中间数组创建
- 在查找场景下，Iterator Helpers 可以提前终止，避免遍历整个数组

提示: 运行时加上 --expose-gc 参数可以获得更准确的内存测试结果
命令: node --expose-gc iterator-helpers-benchmark.js

从输出可以看到：

场景 1-2、4（"取前 N 项"类场景）：

• 时间提升：98%+
• 内存提升：99%+
• Iterator Helpers 在时间和空间上都有压倒性优势

场景 3（查找匹配项）：

• 时间下降：32%（Iterator Helpers 更慢）
• 内存异常：这个结果看起来有问题，可能是 GC 时机导致的测量误差
• 这个场景不适合用 Iterator Helpers

关键发现：

1. 内存优势极其明显：在适合的场景下，Iterator Helpers 的内存使用只有传统方法的 0.3%
2. 中间数组是大头：场景 4 创建了 4 个中间数组，占用 5.33 MB；Iterator Helpers 几乎为零
3. 不是所有场景都适用：场景 3 证明了 Iterator Helpers 不是银弹

如果你觉得这篇文章有帮助，欢迎关注我的 GitHub，下面是我的一些开源项目：

Claude Code Skills（按需加载，意图自动识别，不浪费 token，介绍文章）：

• code-review-skill - 代码审查技能，覆盖 React 19、Vue 3、TypeScript、Rust 等约 9000 行规则（详细介绍）
• 5-whys-skill - 5 Whys 根因分析，说"找根因"自动激活
• first-principles-skill - 第一性原理思考，适合架构设计和技术选型

qwen/gemini/claude - cli 原理学习网站：

• coding-cli-guide（学习网站）- 学习 qwen-cli 时整理的笔记，40+ 交互式动画演示 AI CLI 内部机制

全栈项目（适合学习现代技术栈）：

• prompt-vault - Prompt 管理器，用的都是最新的技术栈，适合用来学习了解最新的前端全栈开发范式：Next.js 15 + React 19 + tRPC 11 + Supabase 全栈示例，clone 下来配个免费 Supabase 就能跑
• chat_edit - 双模式 AI 应用（聊天+富文本编辑），Vue 3.5 + TypeScript + Vite 5 + Quill 2.0 + IndexedDB

VS Code 插件：

• vscode-ai-commit - 一键生成 commit message，支持 Conventional Commits，兼容任何 OpenAI 格式接口

回溯算法：选→钻→退→删，掌握穷举的艺术

回溯算法是算法领域的核心思想之一，尤其在处理「穷举所有可能解」的问题时堪称"神器"。本文将从核心思路出发，通过"选一个数→钻到底→退回来→删掉这个数→选下一个数→再钻到底"这个固定节奏，带你彻底掌握回溯算法。

一、回溯核心原理：选→钻→退→删的固定节奏

一句话记牢回溯的执行过程

选一个数→钻到底→退回来→删掉这个数→选下一个数→再钻到底，直到所有数都试完，最后收集所有符合条件的路径。

选了就往下钻，走不通就退回来擦脚印，换条路再试。很多人一开始都会被递归的多层调用绕晕，但只要抓住 push（选数）→ 递归（钻深层）→ pop（擦脚印） 这个固定节奏，再结合剪枝提前止损，所有回溯题都能套模板解决～

核心四要素

任何回溯问题都能拆解为以下4个核心部分：

关键理解

• 递归是"往下钻"：每选一个数，就递归调用backtrack，相当于"往下走一步"
• return 是"往回退"：触发终止条件（找到解/和超了），就结束当前递归，回到上一层
• pop 是"擦脚印"：回到上一层后，必须执行path.pop()，把刚才选的数删掉，才能"换另一个数选"
• for 循环是"选岔路"：每一层的 for 循环，就是在当前位置选不同的数（岔路），试完一条再试下一条

通用模板

// 回溯核心函数
function backtrack(路径, 选择列表, 其他参数) {
  // 1. 终止条件：找到解，记录结果并返回
  if (满足终止条件) {
    结果列表.push(路径的拷贝); // 注意：要拷贝，否则会被后续修改
    return;
  }

  // 2. 遍历所有可选选项
  for (const 选项 of 选择列表) {
    // 剪枝：提前排除无效选项（关键优化）
    if (选项无效) continue;

    // 3. 做选择：把当前选项加入路径（选数）
    路径.push(选项);

    // 4. 递归探索：基于当前选择，继续往下走（钻到底）
    backtrack(路径, 新的选择列表, 其他参数);

    // 5. 撤销选择（回溯核心）：回到上一步，换选项（退回来→删掉这个数）
    路径.pop();
  }
}

// 主函数
function solveProblem(参数) {
  const 结果列表 = []; // 存储所有符合条件的解
  backtrack([], 初始选择列表, 初始参数); // 初始路径为空
  return 结果列表;
}

二、入门示例：组合总和（可视化理解）

为了让你快速理解回溯的核心节奏，我们先从组合总和这个经典入门题入手，通过可视化打印完整展示「选→探→撤」的全过程。

题目描述

给定一个无重复元素的数组 candidates 和一个目标数 target，找出 candidates 中所有可以使数字和为 target 的组合（数字可以无限制重复被选取）。

• 示例：输入 candidates = [2,3,7]，target = 7，输出 [[2,2,3],[7]]。

完整代码实现

/**
 * 组合总和：找所有和为目标值的组合（可视化打印版）
 * @param {number[]} candidates - 候选数组
 * @param {number} target - 目标和
 * @returns {number[][]} - 所有符合条件的组合
 */
function combinationSum(candidates, target) {
  const result = []; // 存储最终结果
  candidates.sort((a, b) => a - b); // 排序便于剪枝
  let recursionLevel = 0; // 标记递归层级，用于可视化缩进

  // 回溯函数：path=当前路径，sum=当前路径和，start=起始索引（避免重复组合）
  function backtrack(path, sum, start) {
    // 层级+1，生成缩进（每级2个空格）
    recursionLevel++;
    const indent = '  '.repeat(recursionLevel - 1);
    const levelTag = `【层级${recursionLevel}】`;

    // 🟢 调用阶段：打印当前层级初始状态
    console.log(
      `${indent}🟢 ${levelTag} 调用阶段 → path=${JSON.stringify(path)}, sum=${sum}, start=${start}`
    );

    // 终止条件1：路径和等于目标值，记录结果
    if (sum === target) {
      result.push([...path]); // 拷贝路径，避免后续修改
      console.log(
        `${indent}✅ ${levelTag} 找到有效组合 → ${JSON.stringify(path)}，result=${JSON.stringify(result)}`
      );
      // 层级-1，准备返回
      recursionLevel--;
      console.log(`${indent}🔴 ${levelTag} 返回阶段 → 找到解，回到上一层`);
      return;
    }
    // 终止条件2：路径和超过目标值，直接返回（剪枝）
    if (sum > target) {
      console.log(`${indent}🚫 ${levelTag} 剪枝 → sum=${sum} > target=${target}，直接返回`);
      recursionLevel--;
      console.log(`${indent}🔴 ${levelTag} 返回阶段 → 剪枝返回，回到上一层`);
      return;
    }

    // 遍历选择列表（从start开始，避免重复组合）
    for (let i = start; i < candidates.length; i++) {
      const num = candidates[i];
      console.log(`${indent}🔍 ${levelTag} 遍历i=${i} → 尝试选数字${num}，当前sum=${sum}`);

      // 排序剪枝：当前数+已选和>目标值，后续数更大，无需继续
      if (sum + num > target) {
        console.log(
          `${indent}🚫 ${levelTag} 排序剪枝 → ${sum}+${num}=${sum + num} > ${target}，break循环`
        );
        break;
      }

      // 做选择：加入当前数（选数）
      path.push(num);
      console.log(
        `${indent}✅ ${levelTag} 选数字${num} → path=${JSON.stringify(path)}, sum=${sum + num}`
      );

      // 🟡 暂停阶段：调用下一层，当前层级暂停
      console.log(`${indent}🟡 ${levelTag} 暂停阶段 → 调用下一层backtrack，等待返回`);
      // 递归探索：数字可重复选，所以start仍为i（钻到底）
      backtrack(path, sum + num, i);
      console.log(`${indent}🔴 ${levelTag} 返回阶段 → 从下一层返回，继续执行`);

      // 撤销选择：回溯核心（退回来→删掉这个数）
      path.pop();
      console.log(
        `${indent}🔵 ${levelTag} 撤销阶段 → 撤销数字${num} → path=${JSON.stringify(path)}, sum=${sum}`
      );
    }

    // 层级-1，准备返回
    recursionLevel--;
    console.log(`${indent}🔴 ${levelTag} 返回阶段 → for循环结束，回到上一层`);
  }

  // 初始调用：空路径、和为0、从索引0开始
  console.log('========== 开始执行组合总和 ==========');
  backtrack([], 0, 0);
  console.log('========== 执行结束 ==========');
  return result;
}

// 测试：输入 [2,3,7], 7 → 输出 [[2,2,3],[7]]
console.log('最终结果：', combinationSum([2, 3, 7], 7));

各个图标的含义：

• 🟢 调用阶段：进入递归时的状态
• 🔍 遍历阶段：尝试选择数字
• ✅ 选择阶段：成功选择数字
• 🟡 暂停阶段：调用下一层递归
• 🔴 返回阶段：从下一层返回
• 🔵 撤销阶段：删除数字（擦脚印）
• 🚫 剪枝阶段：提前终止无效路径

控制台输出示例：

========== 开始执行组合总和 ==========
🟢 【层级1】 调用阶段 → path=[], sum=0, start=0
🔍 【层级1】 遍历i=0 → 尝试选数字2，当前sum=0
✅ 【层级1】 选数字2 → path=[2], sum=2
🟡 【层级1】 暂停阶段 → 调用下一层backtrack，等待返回
  🟢 【层级2】 调用阶段 → path=[2], sum=2, start=0
  🔍 【层级2】 遍历i=0 → 尝试选数字2，当前sum=2
  ✅ 【层级2】 选数字2 → path=[2,2], sum=4
  🟡 【层级2】 暂停阶段 → 调用下一层backtrack，等待返回
    🟢 【层级3】 调用阶段 → path=[2,2], sum=4, start=0
    🔍 【层级3】 遍历i=0 → 尝试选数字2，当前sum=4
    ✅ 【层级3】 选数字2 → path=[2,2,2], sum=6
    🟡 【层级3】 暂停阶段 → 调用下一层backtrack，等待返回
      🟢 【层级4】 调用阶段 → path=[2,2,2], sum=6, start=0
      🔍 【层级4】 遍历i=0 → 尝试选数字2，当前sum=6
      🚫 【层级4】 排序剪枝 → 6+2=8 > 7，break循环
      🔴 【层级4】 返回阶段 → for循环结束，回到上一层
    🔴 【层级3】 返回阶段 → 从下一层返回，继续执行
    🔵 【层级3】 撤销阶段 → 撤销数字2 → path=[2,2], sum=4
    🔍 【层级3】 遍历i=1 → 尝试选数字3，当前sum=4
    ✅ 【层级3】 选数字3 → path=[2,2,3], sum=7
    🟡 【层级3】 暂停阶段 → 调用下一层backtrack，等待返回
      🟢 【层级4】 调用阶段 → path=[2,2,3], sum=7, start=1
      ✅ 【层级4】 找到有效组合 → [2,2,3]，result=[[2,2,3]]
      🔴 【层级4】 返回阶段 → 找到解，回到上一层
    🔴 【层级3】 返回阶段 → 从下一层返回，继续执行
    🔵 【层级3】 撤销阶段 → 撤销数字3 → path=[2,2], sum=4
    🔍 【层级3】 遍历i=2 → 尝试选数字7，当前sum=4
    🚫 【层级3】 排序剪枝 → 4+7=11 > 7，break循环
    🔴 【层级3】 返回阶段 → for循环结束，回到上一层
  🔴 【层级2】 返回阶段 → 从下一层返回，继续执行
  🔵 【层级2】 撤销阶段 → 撤销数字2 → path=[2], sum=2
  🔍 【层级2】 遍历i=1 → 尝试选数字3，当前sum=2
  ✅ 【层级2】 选数字3 → path=[2,3], sum=5
  🟡 【层级2】 暂停阶段 → 调用下一层backtrack，等待返回
    🟢 【层级3】 调用阶段 → path=[2,3], sum=5, start=1
    🔍 【层级3】 遍历i=1 → 尝试选数字3，当前sum=5
    🚫 【层级3】 排序剪枝 → 5+3=8 > 7，break循环
    🔴 【层级3】 返回阶段 → for循环结束，回到上一层
  🔴 【层级2】 返回阶段 → 从下一层返回，继续执行
  🔵 【层级2】 撤销阶段 → 撤销数字3 → path=[2], sum=2
  🔍 【层级2】 遍历i=2 → 尝试选数字7，当前sum=2
  🚫 【层级2】 排序剪枝 → 2+7=9 > 7，break循环
  🔴 【层级2】 返回阶段 → for循环结束，回到上一层
🔴 【层级1】 返回阶段 → 从下一层返回，继续执行
🔵 【层级1】 撤销阶段 → 撤销数字2 → path=[], sum=0
🔍 【层级1】 遍历i=1 → 尝试选数字3，当前sum=0
✅ 【层级1】 选数字3 → path=[3], sum=3
🟡 【层级1】 暂停阶段 → 调用下一层backtrack，等待返回
  🟢 【层级2】 调用阶段 → path=[3], sum=3, start=1
  🔍 【层级2】 遍历i=1 → 尝试选数字3，当前sum=3
  ✅ 【层级2】 选数字3 → path=[3,3], sum=6
  🟡 【层级2】 暂停阶段 → 调用下一层backtrack，等待返回
    🟢 【层级3】 调用阶段 → path=[3,3], sum=6, start=1
    🔍 【层级3】 遍历i=1 → 尝试选数字3，当前sum=6
    🚫 【层级3】 排序剪枝 → 6+3=9 > 7，break循环
    🔴 【层级3】 返回阶段 → for循环结束，回到上一层
  🔴 【层级2】 返回阶段 → 从下一层返回，继续执行
  🔵 【层级2】 撤销阶段 → 撤销数字3 → path=[3], sum=3
  🔍 【层级2】 遍历i=2 → 尝试选数字7，当前sum=3
  🚫 【层级2】 排序剪枝 → 3+7=10 > 7，break循环
  🔴 【层级2】 返回阶段 → for循环结束，回到上一层
🔴 【层级1】 返回阶段 → 从下一层返回，继续执行
🔵 【层级1】 撤销阶段 → 撤销数字3 → path=[], sum=0
🔍 【层级1】 遍历i=2 → 尝试选数字7，当前sum=0
✅ 【层级1】 选数字7 → path=[7], sum=7
🟡 【层级1】 暂停阶段 → 调用下一层backtrack，等待返回
  🟢 【层级2】 调用阶段 → path=[7], sum=7, start=2
  ✅ 【层级2】 找到有效组合 → [7]，result=[[2,2,3],[7]]
  🔴 【层级2】 返回阶段 → 找到解，回到上一层
🔴 【层级1】 返回阶段 → 从下一层返回，继续执行
🔵 【层级1】 撤销阶段 → 撤销数字7 → path=[], sum=0
🔴 【层级1】 返回阶段 → for循环结束，回到上一层
========== 执行结束 ==========
最终结果： [ [ 2, 2, 3 ], [ 7 ] ]

执行流程解析

以 candidates = [2,3,7], target = 7 为例：

1. 选2 → path=[2], sum=2 → 钻到底（递归）
2. 选2 → path=[2,2], sum=4 → 钻到底（递归）
3. 选2 → path=[2,2,2], sum=6 → 钻到底（递归）
4. 选2 → sum=8 > 7，剪枝，退回来
5. 删掉2 → path=[2,2], sum=6 → 选下一个数3
6. 选3 → path=[2,2,3], sum=7 ✅ 找到解，退回来
7. 删掉3 → path=[2,2], sum=6 → 选下一个数7
8. 剪枝，退回来 → path=[2], sum=2 → 继续尝试...
9. 最终收集到 [[2,2,3],[7]]

三、回溯算法常见题型及解题方法

1. 组合问题

核心特征

• 不考虑元素顺序，每个组合唯一（如[2,3]和[3,2]算同一个）
• 用start参数控制"不回头选"，避免生成重复组合
• 数字可重复选（组合总和）/不可重复选（组合），仅需调整start参数（重复选传i，不重复选传i+1）

LeetCode 题目详解

39. 组合总和

题目描述：

给定一个无重复元素的整数数组 candidates 和一个目标整数 target，找出 candidates 中可以使数字和为目标数 target 的所有不同组合，并以列表形式返回。你可以按任意顺序返回这些组合。

candidates 中的同一个数字可以无限制重复被选取。如果至少一个数字的被选数量不同，则两种组合是不同的。

示例 1：

输入：candidates = [2,3,6,7], target = 7
输出：[[2,2,3],[7]]
解释：
2 和 3 可以形成一组候选，2 + 2 + 3 = 7。注意 2 可以使用多次。
7 也是一个候选， 7 = 7。
所以这两种组合是唯一的答案。

示例 2：

输入: candidates = [2,3,5], target = 8
输出: [[2,2,2,2],[2,3,3],[3,5]]

解决方案：

/**
 * 39. 组合总和
 * @param {number[]} candidates - 无重复元素的候选数组
 * @param {number} target - 目标和
 * @returns {number[][]} 所有符合条件的组合
 */
function combinationSum(candidates, target) {
  const res = [];
  candidates.sort((a, b) => a - b); // 排序便于剪枝

  function backtrack(path, sum, start) {
    // 终止条件：找到有效解
    if (sum === target) {
      res.push([...path]);
      return;
    }
    // 剪枝：和超过目标值
    if (sum > target) return;

    for (let i = start; i < candidates.length; i++) {
      const num = candidates[i];
      // 排序剪枝：后续数更大，无需继续
      if (sum + num > target) break;

      // 选数
      path.push(num);
      // 钻到底：数字可重复选，所以start仍为i
      backtrack(path, sum + num, i);
      // 退回来→删掉这个数
      path.pop();
    }
  }

  backtrack([], 0, 0);
  return res;
}

易错点：

• 忘记排序导致剪枝失效
• start参数传错（重复选传i，不重复选传i+1）
• 忘记拷贝路径（[...path]）

40. 组合总和 II

题目描述：

给定一个候选人编号的集合 candidates 和一个目标数 target，找出 candidates 中所有可以使数字和为 target 的组合。

candidates 中的每个数字在每个组合中只能使用一次。

**注意：**解集不能包含重复的组合。

示例 1：

输入: candidates = [10,1,2,7,6,1,5], target = 8,
输出:
[
[1,1,6],
[1,2,5],
[1,7],
[2,6]
]

解决方案：

/**
 * 40. 组合总和 II
 * @param {number[]} candidates - 可能包含重复元素的候选数组
 * @param {number} target - 目标和
 * @returns {number[][]} 所有符合条件的组合（不重复）
 */
function combinationSum2(candidates, target) {
  const res = [];
  candidates.sort((a, b) => a - b); // 排序便于剪枝和去重

  function backtrack(path, sum, start) {
    // 终止条件：找到有效解
    if (sum === target) {
      res.push([...path]);
      return;
    }
    // 剪枝：和超过目标值
    if (sum > target) return;

    for (let i = start; i < candidates.length; i++) {
      const num = candidates[i];

      // 去重剪枝：跳过重复元素（关键！）
      // i > start 确保同一层不选重复数字，但不同层可以选
      if (i > start && candidates[i] === candidates[i - 1]) {
        continue;
      }

      // 排序剪枝
      if (sum + num > target) break;

      // 选数
      path.push(num);
      // 钻到底：数字不可重复选，所以start传i+1
      backtrack(path, sum + num, i + 1);
      // 退回来→删掉这个数
      path.pop();
    }
  }

  backtrack([], 0, 0);
  return res;
}

易错点：

• 去重逻辑错误：应该是i > start而不是i > 0（允许不同层选相同数字）
• 忘记排序导致去重失效

77. 组合

题目描述：

给定两个整数 n 和 k，返回范围 [1, n] 中所有可能的 k 个数的组合。

你可以按任何顺序返回答案。

示例 1：

输入：n = 4, k = 2
输出：
[
  [2,4],
  [3,4],
  [2,3],
  [1,2],
  [1,3],
  [1,4],
]

解决方案：

/**
 * 77. 组合
 * @param {number} n - 范围 [1, n]
 * @param {number} k - 组合长度
 * @returns {number[][]} 所有可能的k个数的组合
 */
function combine(n, k) {
  const res = [];

  function backtrack(path, start) {
    // 终止条件：路径长度等于k
    if (path.length === k) {
      res.push([...path]);
      return;
    }

    // 剪枝：剩余可选数字不够
    // 还需要选 k - path.length 个数，从start到n还有 n - start + 1 个数
    // 如果 n - start + 1 < k - path.length，则无法凑够k个数
    if (n - start + 1 < k - path.length) return;

    for (let i = start; i <= n; i++) {
      // 选数
      path.push(i);
      // 钻到底：不重复选，所以start传i+1
      backtrack(path, i + 1);
      // 退回来→删掉这个数
      path.pop();
    }
  }

  backtrack([], 1);
  return res;
}

易错点：

• 范围错误：应该是[1, n]，循环条件是i <= n而不是i < n
• 忘记剪枝优化导致超时

216. 组合总和 III

题目描述：

找出所有相加之和为 n 的 k 个数的组合，且满足下列条件：

• 只使用数字1到9
• 每个数字最多使用一次

返回所有可能的有效组合的列表。该列表不能包含相同的组合两次，组合可以以任何顺序返回。

示例 1：

输入: k = 3, n = 7
输出: [[1,2,4]]
解释:
1 + 2 + 4 = 7
没有其他符合的组合了。

解决方案：

/**
 * 216. 组合总和 III
 * @param {number} k - 组合长度
 * @param {number} n - 目标和
 * @returns {number[][]} 所有符合条件的组合
 */
function combinationSum3(k, n) {
  const res = [];

  function backtrack(path, sum, start) {
    // 终止条件1：找到有效解（长度和和都满足）
    if (path.length === k && sum === n) {
      res.push([...path]);
      return;
    }
    // 终止条件2：长度已满但和不满足，或和已超
    if (path.length === k || sum >= n) return;

    // 剪枝：剩余可选数字不够
    if (9 - start + 1 < k - path.length) return;

    for (let i = start; i <= 9; i++) {
      // 剪枝：当前数加上已选和超过目标值
      if (sum + i > n) break;

      // 选数
      path.push(i);
      // 钻到底：数字不可重复选，所以start传i+1
      backtrack(path, sum + i, i + 1);
      // 退回来→删掉这个数
      path.pop();
    }
  }

  backtrack([], 0, 1);
  return res;
}

2. 排列问题

核心特征

• 考虑元素顺序，每个排列唯一（如[1,2]和[2,1]算不同排列）
• 用used数组控制"不重复选"，循环从0开始（允许选任意未选过的数字）
• 含重复数字的排列（全排列II）需增加"去重剪枝"

LeetCode 题目详解

46. 全排列

题目描述：

给定一个不含重复数字的数组 nums，返回其所有可能的全排列。你可以按任意顺序返回答案。

示例 1：

输入：nums = [1,2,3]
输出：[[1,2,3],[1,3,2],[2,1,3],[2,3,1],[3,1,2],[3,2,1]]

解决方案：

/**
 * 46. 全排列
 * @param {number[]} nums - 不含重复数字的数组
 * @returns {number[][]} 所有全排列
 */
function permute(nums) {
  const res = [];
  const len = nums.length;
  const used = new Array(len).fill(false); // 标记哪些数字已使用

  function backtrack(path) {
    // 终止条件：路径长度等于数组长度
    if (path.length === len) {
      res.push([...path]);
      return;
    }

    // 遍历所有可选数字（排列从0开始，允许选任意未选过的数字）
    for (let i = 0; i < len; i++) {
      // 剪枝：跳过已选数字
      if (used[i]) continue;

      // 选数
      used[i] = true;
      path.push(nums[i]);

      // 钻到底
      backtrack(path);

      // 退回来→删掉这个数
      path.pop();
      used[i] = false;
    }
  }

  backtrack([]);
  return res;
}

易错点：

• 忘记使用used数组导致重复选同一个数字
• 循环应该从0开始，不是从start开始（排列需要考虑所有位置）

47. 全排列 II

题目描述：

给定一个可包含重复数字的序列 nums，按任意顺序返回所有不重复的全排列。

示例 1：

输入：nums = [1,1,2]
输出：
[[1,1,2],
 [1,2,1],
 [2,1,1]]

解决方案：

/**
 * 47. 全排列 II
 * @param {number[]} nums - 可能包含重复数字的数组
 * @returns {number[][]} 所有不重复的全排列
 */
function permuteUnique(nums) {
  const res = [];
  const len = nums.length;
  const used = new Array(len).fill(false);
  nums.sort((a, b) => a - b); // 排序便于去重

  function backtrack(path) {
    // 终止条件：路径长度等于数组长度
    if (path.length === len) {
      res.push([...path]);
      return;
    }

    for (let i = 0; i < len; i++) {
      // 剪枝1：跳过已选数字
      if (used[i]) continue;

      // 剪枝2：去重（关键！）
      // 如果当前数字和前一个数字相同，且前一个数字未被使用，则跳过
      // 这确保相同数字按顺序使用，避免重复排列
      if (i > 0 && nums[i] === nums[i - 1] && !used[i - 1]) {
        continue;
      }

      // 选数
      used[i] = true;
      path.push(nums[i]);

      // 钻到底
      backtrack(path);

      // 退回来→删掉这个数
      path.pop();
      used[i] = false;
    }
  }

  backtrack([]);
  return res;
}

易错点：

• 去重逻辑错误：应该是!used[i - 1]而不是used[i - 1]
  • !used[i - 1]：前一个相同数字未被使用，说明我们在同一层尝试重复数字，应该跳过
  • used[i - 1]：前一个相同数字已被使用，说明我们在不同层，可以使用

3. 子集问题

核心特征

• 找出所有可能的子集（包括空集）
• 用start参数控制不回头选，无需严格终止条件（每次递归都记录路径）
• 含重复数字的子集（子集II）需增加"去重剪枝"

LeetCode 题目详解

78. 子集

题目描述：

给你一个整数数组 nums，数组中的元素互不相同。返回该数组所有可能的子集（幂集）。

解集不能包含重复的子集。你可以按任意顺序返回解集。

示例 1：

输入：nums = [1,2,3]
输出：[[],[1],[2],[1,2],[3],[1,3],[2,3],[1,2,3]]

解决方案：

/**
 * 78. 子集
 * @param {number[]} nums - 不含重复元素的数组
 * @returns {number[][]} 所有子集
 */
function subsets(nums) {
  const res = [];

  function backtrack(path, start) {
    // 每次递归都记录路径（无需严格终止条件）
    res.push([...path]);

    for (let i = start; i < nums.length; i++) {
      // 选数
      path.push(nums[i]);

      // 钻到底：不重复选，所以start传i+1
      backtrack(path, i + 1);

      // 退回来→删掉这个数
      path.pop();
    }
  }

  backtrack([], 0);
  return res;
}

易错点：

• 忘记在每次递归开始时记录路径（子集问题需要在每个节点都记录，不只是叶子节点）

90. 子集 II

题目描述：

给你一个整数数组 nums，其中可能包含重复元素，请你返回该数组所有可能的子集（幂集）。

解集不能包含重复的子集。返回的解集中，子集可以按任意顺序排列。

示例 1：

输入：nums = [1,2,2]
输出：[[],[1],[1,2],[1,2,2],[2],[2,2]]

解决方案：

/**
 * 90. 子集 II
 * @param {number[]} nums - 可能包含重复元素的数组
 * @returns {number[][]} 所有不重复的子集
 */
function subsetsWithDup(nums) {
  const res = [];
  nums.sort((a, b) => a - b); // 排序便于去重

  function backtrack(path, start) {
    // 每次递归都记录路径
    res.push([...path]);

    for (let i = start; i < nums.length; i++) {
      // 去重剪枝：跳过重复元素（关键！）
      // i > start 确保同一层不选重复数字，但不同层可以选
      if (i > start && nums[i] === nums[i - 1]) {
        continue;
      }

      // 选数
      path.push(nums[i]);

      // 钻到底：不重复选，所以start传i+1
      backtrack(path, i + 1);

      // 退回来→删掉这个数
      path.pop();
    }
  }

  backtrack([], 0);
  return res;
}

易错点：

• 去重逻辑和组合总和II相同，但容易忘记排序

四、回溯算法核心优化：剪枝

剪枝是提升回溯效率的关键，常见剪枝策略：

1. 提前终止：如组合总和中"路径和超过目标值直接返回"
2. 排序剪枝：先排序候选数组，遇到"当前值+已选和>目标值"时，后续值更大，直接break
3. 重复剪枝：如子集II/全排列II中，跳过重复元素（if (i > start && nums[i] === nums[i-1]) continue）
4. 约束剪枝：如N皇后中，提前判断位置是否合法，不合法则跳过
5. 数量剪枝：如组合问题中，剩余可选数字不够时直接返回

五、总结

1. 核心思想：回溯 = 深度优先遍历 + 状态回退 + 剪枝，核心是"选→探→撤"
2. 固定节奏：push（选数）→ 递归（钻深层）→ pop（擦脚印），抓住这个节奏就能解决所有回溯题
3. 模板复用：
   • 组合/子集：用start参数避免重复，循环从start开始
   • 排列：用used数组避免重复选，循环从0开始
4. 优化关键：剪枝是减少无效递归的核心，能让回溯效率提升一个量级

回溯算法看似复杂，但只要抓住"选→钻→退→删"这个固定节奏和"剪枝优化"这个核心，就能轻松应对各类回溯问题。建议从简单的组合问题入手，逐步过渡到排列、子集问题，多写多练就能融会贯通。

unplugin-auto-import 完整配置指南

目录

• 简介
• 安装
• 核心配置选项
  • imports - 自动导入库的 API
  • dirs - 自动导入自定义目录
  • resolvers - 动态解析器
  • include - 包含文件
  • exclude - 排除文件
  • dts - 类型声明文件
  • eslintrc - ESLint 配置
  • defaultExportByFilename - 按文件名导入
  • vueTemplate - Vue 模板支持
  • injectAtEnd - 注入位置
• 完整配置示例
• 常见问题

简介

unplugin-auto-import 是一个 Vite/Webpack/Rollup 插件，用于自动导入 API，无需手动编写 import 语句。支持 Vue、Vue Router、Pinia 等库，以及自定义工具函数。

主要优势：

• ✅ 减少重复代码，无需手动导入
• ✅ 提升开发效率
• ✅ 支持 TypeScript 类型提示
• ✅ 支持 ESLint 配置

安装

npm install -D unplugin-auto-import
# 或
yarn add -D unplugin-auto-import
# 或
pnpm add -D unplugin-auto-import

核心配置选项

1. imports - 自动导入库的 API

作用： 指定要自动导入的库或包的 API。

案例 1.1：字符串形式（最简单）

AutoImport({
  imports: [
    'vue',           // 自动导入 ref, computed, onMounted 等
    'vue-router',    // 自动导入 useRoute, useRouter 等
    'pinia',         // 自动导入 defineStore, storeToRefs 等
  ],
})

使用效果：

<script setup>
// 不需要 import，直接使用
const count = ref(0)
const route = useRoute()
const store = defineStore('user', { ... })
</script>

案例 1.2：对象形式（精确控制）

AutoImport({
  imports: [
    'vue',
    // 只导入指定的 API
    {
      'vue-router': ['useRoute', 'useRouter'], // 只导入这两个
    },
    {
      '@vueuse/core': [
        'useMouse',
        'useFetch',
        'useLocalStorage',
      ],
    },
    {
      'axios': [
        ['default', 'axios'], // 导入默认导出并重命名为 axios
      ],
    },
    {
      'lodash-es': [
        'debounce',
        'throttle',
        ['default', '_'], // 默认导出重命名为 _
      ],
    },
  ],
})

使用效果：

<script setup>
// 自动导入指定的 API
const { x, y } = useMouse()
const { data } = useFetch('/api/data')
const debouncedFn = debounce(() => {}, 300)
const throttledFn = throttle(() => {}, 300)
</script>

案例 1.3：带别名的导入

AutoImport({
  imports: [
    {
      'vue': [
        'ref',
        ['computed', 'computedRef'], // 导入 computed 并重命名为 computedRef
        ['onMounted', 'onComponentMount'], // 导入 onMounted 并重命名
      ],
    },
  ],
})

使用效果：

<script setup>
const count = ref(0)
const double = computedRef(() => count.value * 2) // 使用别名
onComponentMount(() => { // 使用别名
  console.log('mounted')
})
</script>

2. dirs - 自动导入自定义目录

作用： 自动导入项目内部目录下的模块（工具函数、composables 等）。

案例 2.1：基本用法

AutoImport({
  dirs: [
    './src/utils',        // 导入 utils 目录下的所有导出
    './src/composables',  // 导入 composables 目录下的所有导出
  ],
})

项目结构：

src/
  utils/
    format.js      // export const formatDate = ...
    validate.js    // export const validateEmail = ...
  composables/
    useAuth.js     // export const useAuth = ...
    useTable.js    // export const useTable = ...

使用效果：

<script setup>
// 自动从 utils 和 composables 导入
const formatted = formatDate(new Date())
const isValid = validateEmail('test@example.com')
const { user, login } = useAuth()
const { data, loading } = useTable()
</script>

案例 2.2：使用 Glob 模式（支持子目录）

AutoImport({
  dirs: [
    './src/utils/**',           // 包含所有子目录
    './src/composables/**',     // 包含所有子目录
    './src/hooks/**/*.ts',      // 只匹配 .ts 文件
  ],
})

案例 2.3：带配置的对象形式

AutoImport({
  dirs: [
    './src/utils',
    {
      // 指定目录
      dir: './src/composables',
      // 是否生成类型声明（默认 true）
      types: true,
      // 文件匹配模式
      pattern: ['**/*.{ts,js}'],
      // 排除某些文件
      ignore: ['**/*.test.ts', '**/*.spec.ts'],
    },
  ],
})

案例 2.4：只导入特定文件

AutoImport({
  dirs: [
    './src/utils/format.js',    // 只导入这个文件
    './src/utils/validate.js', // 只导入这个文件
  ],
})

⚠️ 注意事项：

• dirs 只能自动导入命名导出（export const、export function）
• 不能导入默认导出（export default），除非使用 defaultExportByFilename

3. resolvers - 动态解析器

作用： 动态判断某些标识符应该从哪个模块导入（常用于 UI 库）。

案例 3.1：使用 Element Plus Resolver

import { ElementPlusResolver } from 'unplugin-vue-components/resolvers'

AutoImport({
  resolvers: [
    ElementPlusResolver({
      // 自动导入样式
      importStyle: 'sass', // 或 'css', false
    }),
  ],
})

使用效果：

<script setup>
// 自动导入 ElMessage, ElMessageBox 等
ElMessage.success('成功')
ElMessageBox.confirm('确定？')
</script>

案例 3.2：使用 Vant Resolver

import { VantResolver } from 'unplugin-vue-components/resolvers'

AutoImport({
  resolvers: [
    VantResolver(),
  ],
})

使用效果：

<script setup>
// 自动导入 Vant 的函数式 API
showToast('提示')
showDialog({ message: '内容' })
showNotify({ message: '通知' })
</script>

案例 3.3：自定义 Resolver

AutoImport({
  resolvers: [
    // 自定义 resolver 函数
    (name) => {
      // 如果函数名以 use 开头，从 @/composables 导入
      if (name.startsWith('use')) {
        return {
          name: name,
          from: `@/composables/${name}`,
        }
      }
      // 如果函数名以 $ 开头，从 @/utils 导入
      if (name.startsWith('$')) {
        return {
          name: name.slice(1), // 去掉 $ 前缀
          from: `@/utils/${name.slice(1)}`,
        }
      }
    },
  ],
})

使用效果：

<script setup>
// useAuth 会自动从 @/composables/useAuth 导入
const { user } = useAuth()

// $format 会自动从 @/utils/format 导入（实际导入的是 format）
const date = $format(new Date())
</script>

案例 3.4：多个 Resolver 组合

import { ElementPlusResolver } from 'unplugin-vue-components/resolvers'
import { AntDesignVueResolver } from 'unplugin-vue-components/resolvers'

AutoImport({
  resolvers: [
    ElementPlusResolver(),
    AntDesignVueResolver(),
    // 自定义 resolver
    (name) => {
      if (name === 'myCustomFunction') {
        return { name, from: '@/utils/custom' }
      }
    },
  ],
})

4. include - 包含文件

作用： 指定哪些文件会被插件处理。

案例 4.1：基本用法

AutoImport({
  include: [
    /\.[tj]sx?$/,     // .ts, .tsx, .js, .jsx
    /\.vue$/,         // .vue
    /\.vue\?vue/,     // .vue?vue (SFC)
  ],
})

案例 4.2：只处理特定文件

AutoImport({
  include: [
    /\.vue$/,                    // 只处理 .vue 文件
    /src\/views\/.*\.ts$/,       // 只处理 views 目录下的 .ts 文件
  ],
})

案例 4.3：排除测试文件

AutoImport({
  include: [
    /\.[tj]sx?$/,
    /\.vue$/,
  ],
  exclude: [
    /\.test\.[tj]sx?$/,  // 排除测试文件
    /\.spec\.[tj]sx?$/,  // 排除测试文件
    /node_modules/,      // 排除 node_modules
  ],
})

5. exclude - 排除文件

作用： 排除不需要处理的文件。

案例 5.1：排除特定文件

AutoImport({
  exclude: [
    /node_modules/,           // 排除 node_modules
    /\.test\.[tj]sx?$/,      // 排除测试文件
    /\.spec\.[tj]sx?$/,      // 排除测试文件
    /dist/,                  // 排除构建目录
    /\.d\.ts$/,              // 排除类型声明文件
  ],
})

案例 5.2：排除特定目录

AutoImport({
  exclude: [
    /node_modules/,
    /src\/components\/legacy/, // 排除旧组件目录
    /src\/utils\/deprecated/,  // 排除废弃工具目录
  ],
})

6. dts - 类型声明文件

作用： 生成 TypeScript 类型声明文件，提供类型提示。

案例 6.1：启用类型声明（默认位置）

AutoImport({
  dts: true, // 默认生成到根目录的 auto-imports.d.ts
})

案例 6.2：指定类型声明文件路径

AutoImport({
  dts: './src/auto-imports.d.ts', // 指定生成位置
})

案例 6.3：禁用类型声明

AutoImport({
  dts: false, // 不生成类型声明文件
})

生成的文件示例：

/* eslint-disable */
/* prettier-ignore */
// Generated by unplugin-auto-import
export {}
declare global {
  const ElMessage: typeof import('element-plus')['ElMessage']
  const computed: typeof import('vue')['computed']
  const onMounted: typeof import('vue')['onMounted']
  const ref: typeof import('vue')['ref']
  const useRoute: typeof import('vue-router')['useRoute']
  // ...
}

在 tsconfig.json 中引入：

{
  "include": [
    "src/auto-imports.d.ts"
  ]
}

7. eslintrc - ESLint 配置

作用： 生成 ESLint 全局变量配置，避免 no-undef 错误。

案例 7.1：基本配置

AutoImport({
  eslintrc: {
    enabled: true,                              // 启用
    filepath: './.eslintrc-auto-import.json',  // 生成文件路径
    globalsPropValue: true,                     // 设置为全局变量
  },
})

生成的 .eslintrc-auto-import.json：

{
  "globals": {
    "ElMessage": "readonly",
    "computed": "readonly",
    "onMounted": "readonly",
    "ref": "readonly",
    "useRoute": "readonly"
  }
}

在 .eslintrc.js 中引入：

module.exports = {
  extends: [
    './.eslintrc-auto-import.json', // 引入自动生成的配置
  ],
}

案例 7.2：自定义配置

AutoImport({
  eslintrc: {
    enabled: true,
    filepath: './.eslintrc-auto-import.json',
    globalsPropValue: 'readonly', // 或 'writable'
  },
})

8. defaultExportByFilename - 按文件名导入

作用： 如果目录下的文件是默认导出，按文件名自动导入。

案例 8.1：启用按文件名导入

AutoImport({
  dirs: ['./src/composables'],
  defaultExportByFilename: true, // 启用
})

文件结构：

src/composables/
  useAuth.js      // export default function useAuth() {}
  useTable.js     // export default function useTable() {}

使用效果：

<script setup>
// 自动从文件名推断导入
const { user } = useAuth()    // 从 useAuth.js 导入
const { data } = useTable()   // 从 useTable.js 导入
</script>

9. vueTemplate - Vue 模板支持

作用： 在 Vue 模板中也能使用自动导入的 API（实验性功能）。

案例 9.1：启用模板支持

AutoImport({
  vueTemplate: true, // 在模板中也能使用自动导入的函数
})

使用效果：

<template>
  <!-- 在模板中直接使用 -->
  <div>{{ formatDate(date) }}</div>
  <button @click="showMessage('Hello')">点击</button>
</template>

10. injectAtEnd - 注入位置

作用： 控制自动导入语句的注入位置。

案例 10.1：在文件末尾注入

AutoImport({
  injectAtEnd: true, // 在文件末尾注入 import（默认 false，在文件开头）
})

完整配置示例

Vite 配置示例

import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'
import AutoImport from 'unplugin-auto-import/vite'
import { ElementPlusResolver } from 'unplugin-vue-components/resolvers'
import path from 'path'

export default defineConfig({
  plugins: [
    vue(),
    AutoImport({
      // 1. 自动导入库的 API
      imports: [
        'vue',
        'vue-router',
        'pinia',
        {
          '@vueuse/core': ['useMouse', 'useFetch'],
          'lodash-es': ['debounce', 'throttle'],
        },
      ],
      
      // 2. 自动导入自定义目录
      dirs: [
        './src/utils/**',
        './src/composables/**',
      ],
      
      // 3. 动态解析器
      resolvers: [
        ElementPlusResolver({
          importStyle: 'sass',
        }),
        // 自定义 resolver
        (name) => {
          if (name.startsWith('use')) {
            return { name, from: `@/composables/${name}` }
          }
        },
      ],
      
      // 4. 包含的文件
      include: [
        /\.[tj]sx?$/,
        /\.vue$/,
        /\.vue\?vue/,
      ],
      
      // 5. 排除的文件
      exclude: [
        /node_modules/,
        /\.test\.[tj]sx?$/,
        /\.spec\.[tj]sx?$/,
      ],
      
      // 6. 类型声明文件
      dts: './src/auto-imports.d.ts',
      
      // 7. ESLint 配置
      eslintrc: {
        enabled: true,
        filepath: './.eslintrc-auto-import.json',
        globalsPropValue: true,
      },
      
      // 8. 按文件名默认导出
      defaultExportByFilename: false,
      
      // 9. Vue 模板支持（实验性）
      vueTemplate: false,
      
      // 10. 注入位置
      injectAtEnd: false,
    }),
  ],
  resolve: {
    alias: {
      '@': path.resolve(__dirname, './src'),
    },
  },
})

Webpack 配置示例

const AutoImport = require('unplugin-auto-import/webpack')

module.exports = {
  plugins: [
    AutoImport({
      imports: ['vue', 'vue-router'],
      dts: true,
    }),
  ],
}

配置选项总结表

常见问题

Q1: 为什么我的自定义函数没有被自动导入？

A: 检查以下几点：

1. 确保函数是命名导出（export const 或 export function），不是默认导出
2. 检查 dirs 配置的路径是否正确
3. 确保文件在 include 范围内，不在 exclude 范围内
4. 如果使用默认导出，启用 defaultExportByFilename: true

Q2: TypeScript 类型提示不工作？

A:

1. 确保 dts 配置已启用
2. 在 tsconfig.json 的 include 中添加生成的类型声明文件
3. 重启 IDE/编辑器

Q3: ESLint 报 no-undef 错误？

A:

1. 启用 eslintrc.enabled: true
2. 在 .eslintrc.js 中引入生成的配置文件
3. 重启 ESLint 服务

Q4: 如何只导入部分 API？

A: 使用对象形式的 imports 配置：

imports: [
  {
    'vue': ['ref', 'computed'], // 只导入这两个
  },
]

Q5: 如何排除某些文件不被处理？

A: 使用 exclude 配置：

exclude: [
  /\.test\.[tj]sx?$/,  // 排除测试文件
  /node_modules/,      // 排除 node_modules
]

Q6: 自定义工具函数如何自动导入？

A:

1. 将函数改为命名导出
2. 配置 dirs 指向函数所在目录
3. 使用 Glob 模式支持子目录：'./src/utils/**'

最佳实践

1. 命名导出优先：自定义函数使用命名导出，便于自动导入
2. 类型声明文件：始终启用 dts，提供类型提示
3. ESLint 配置：启用 eslintrc，避免 no-undef 错误
4. 精确导入：使用对象形式的 imports，只导入需要的 API
5. 目录结构：合理组织 utils、composables 等目录
6. 性能优化：使用 include 和 exclude 限制处理范围

相关链接

• GitHub 仓库
• 官方文档
• unplugin-vue-components（组件自动导入）

更新日志

• v0.16.0+: 支持 defaultExportByFilename 选项
• v0.15.0+: 改进 dirs 的 Glob 模式支持
• v0.10.0+: 添加 vueTemplate 实验性功能

文档版本： 1.0.0
最后更新： 2024年

问题描述

因公司需要，使用的环境是ruyi的前端部分，采用vue2+element-ui

1.当以开发环境进入页面时，第一次正常，在刷新后会白屏，或者卡在加载页面，控制台抛出错误 2.关于样式异常问题

Uncaught SyntaxError: Unexpected token '<'

但进入生产环境访问，一切正常，刷新后也依然正常。

原因

问题就出在Uncaught SyntaxError上，这是js的语法错误。例如

const 

上面代码会抛出

const 
      

SyntaxError: Unexpected end of input

当点击抛出部分进入具体错误地方，会进入html页面，错误就出在这。

graph TD
浏览器请求获取html页面 --> 浏览器解析html -->解析script与link标签

问题就出在解析解析script与link标签上

总所周知道script的标签使用

<script src="xxxx">

这时候浏览器发请求拿取到js问题，但如果拿取到的并非js文件，那自然会有SyntaxError错，本人就遇到这种情况。生产正常的原因在于ng配置对了，开发环境配置错了。因为开发环境也有类似于 try_files $uri$uriuri/ /xxx/index.html;的配置逻辑，既无论请求什么如果请求不到了就返回/xxx/index.html 但js文件和css文件是实际存在的，是请求的到的，理论上是不应该返回html

本人具体前端错误配置了啥忘了，因为vue-cli在配置文件中需要重启才生效，

export default new Router({
  mode: 'history', // 去掉url中的#
  scrollBehavior: () => ({ y: 0 }),
  routes: constantRoutes,
  base: '/yyy', // 当路由配置base 到时候进入http://xxx:xx/yyy才会展示页面。http://xxx:xx会空白
  
  
  
  对应的vite/vue-cli都得配置
  publicPath: process.env.NODE_ENV === "production" ? "/yyy/" : "/",
  既生产环境需要添加nbbz 开发环境不需要添加，如果生产不编写/yyy/会导致生产上有问题
})

关于样式问题

在ruyi样式问题当中/srccomponents/ThemePicker 这个文件当中的有个setTheme函数，当中的

   if (!this.chalk) {
        const url = `${process.env.VUE_APP_BASE_URL}/styles/theme-chalk/index.css`
        await this.getCSSString(url, 'chalk')
      }