在服务端渲染时， nodejs 天然提供了 js 运行环境，同时服务端也不需要真正渲染出 UI，只需要给出 html 字符串，或者 html 流就行，真正的渲染仍然交给浏览器。和在nodejs服务端的运行不同，终端上运行时，要解决的问题更多，包括如何渲染 UI、如何运行 JS，JS 如何与终端通信等。

本文从 UI 渲染、JS运行时、JS和终端通信机制 等方面，描述 React Native 的实现原理，并简单介绍其它几款和 react 相关的跨端渲染框架。

1. React Native

https://github.com/facebook/react-native

UI渲染

React Native 使用原生平台的 UI 组件进行渲染，它将 JavaScript 中的 React 组件映射到相应的原生 UI 组件。这种方式能让整体渲染体验达到接近原生的效果，同时能在一定程度上将代码在多端复用（仍然存在一些小的细节需要不同平台各自适配）。

渲染环节涉及三个线程。

• UI 线程（主线程）：唯一可以操作宿主视图的线程。负责
• JavaScript 线程：这是执行 React 渲染阶段的地方。
• 后台线程：专门用于布局的线程。

实现跨端 UI 渲染的过程

其中，Fabric 是 React Native 新架构的渲染系统。其核心原理是在 C++ 层统一更多的渲染逻辑，提升与宿主平台（host platforms）互操作性，并为 React Native 解锁更多能力。其研发始于 2018 年。从 2021 年开始， Facebook App 中的 React Native 启用了新的渲染器。

事件触发 Fabric 渲染的过程，渲染可以分为三个步骤

• 渲染（Render）：在 JavaScript 中，React 执行那些产品逻辑代码创建 React 元素树（React Element Trees）。然后在 C++ 中，用 React 元素树创建 React 影子树（React Shadow Tree）。
• 提交（Commit）：在 React 影子树完全创建后，渲染器会触发一次提交。这会将 React 元素树和新创建的 React 影子树的提升为“下一棵要挂载的树”。 这个过程中也包括了布局信息计算。
• 挂载（Mount）：React 影子树有了布局计算结果后，它会被转化为一个宿主视图树（Host View Tree）。

https://reactnative.cn/architecture/render-pipeline

JS 引擎

根据版本和运行环境不同， React Native 可能使用三种 JS 引擎

• 从 React Native 0.70 版本开始，默认使用 Hermes 引擎，它是专门为 React Native 而优化的一个开源 JavaScript 引擎。
• 如果 Hermes 被禁用或是较早的 React Native 版本，则会使用JavaScriptCore，也就是 Safari 所使用的 JavaScript 引擎。但是在 iOS 上 JavaScriptCore 并没有使用即时编译技术（JIT），因为在 iOS 中应用无权拥有可写可执行的内存页（因此无法动态生成代码）。
• 在使用 Chrome 调试时，所有的 JavaScript 代码都运行在 Chrome 中，并且通过 WebSocket 与原生代码通信。此时的运行环境是V8 引擎。（社区也有提供可以在生产环境中使用的react-native-v8)

JS和终端通信

JS 和终端通信有属性传递、事件、JsBrige 等多种方式。

• 原生组件属性、RN组件属性互相传递
• 原生组件到RN组件的事件通信
• RN组件到原生组件通过 JsBrige 直接调用方法。
• 新架构的 JSI（JavaScript Interface） ，JS 和 C++ 互相持有对象引用并调用方法

值得注意的是，这些通信都是异步的，以提高性能。

参考：

• https://reactnative.cn/docs/communication-android
• https://reactnative.cn/docs/communication-ios
• https://reactnative.cn/docs/the-new-architecture/why

2. 其它支持 react 的跨端框架

Taro

https://github.com/nervjs/taro

Taro 是一个开放式跨端跨框架解决方案，支持使用 React/Vue/Nerv 等框架来开发 微信 / 京东 / 百度 / 支付宝 / 字节跳动 / QQ / 飞书 小程序 / H5 / RN 等应用。

来源：https://www.w3.org/2022/09/hangzhou/miniapps/slides/jiajian.pdf

Hippy

https://github.com/Tencent/Hippy

Hippy 是腾讯开源的一款跨端渲染框架，支持 react 和 vue。从底层进行了大量优化，在启动速度、可复用列表组件、渲染效率、动画速度、网络通信等方面都提供了业内顶尖的性能表现。

Hippy 3.0 的升级中，业务层上不再局限于 JS 驱动，也支持切换其它任意 DSL 语言进行驱动；在渲染层中，渲染引擎除了支持现有原生（Native）渲染之外，还可以选择其他渲染 Renderer，如 Flutter(Voltron) 渲染。

react 的服务端渲染（ssr）和 ejs 的区别在于，除了在服务端渲染出 html 外，还支持服务端的渲染产物在客户端无缝绑定 react 在客户端的能力，即同构。

ssr 能在 SEO 和 首屏速度方面带来一定收益，但是同时也会给代码的复杂性和维护成本上带来负面影响，需要根据项目实际情况做好权衡。这里简单总结一下 ssr 过程中可能会遇到的问题和处理方案，内容结构见下图。

1. 基础的 ssr 实现

react 官方 API 中关于 ssr 的部分提供了很简单的几个 API https://react.dev/reference/react-dom/server

实际项目中，ssr 还有很多问题要处理，但是 react 只关注组件渲染本身，这里首先看一下几个官方 API 的简单使用。

• renderToString 将 React 树渲染为一个 HTML 字符串
• renderToPipeableStream 将 react 组件渲染为 nodejs 的可读流
• renderToReadableStream 将 react 组件渲染为 Web 可读流
• renderToStaticMarkup 将非交互的 React 组件树渲染成 HTML 字符串
• renderToStaticNodeStream 将非交互的 React 组件树渲染成 nodejs 的可读流

  renderToString

  看方法名称就比较好理解了，在渲染步骤中，react 不再是根据 fiber 树创建 dom 节点，而是生成 html 字符串。

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

  import Koa from 'koa'; import Router from '@koa/router'; import React from 'react'; import { renderToString }from"react-dom/server"; import App from './App'; const SERVER_PORT = 8002; const app = new Koa(); const router = new Router(); router.get('/', (ctx, next) =>{ const content = renderToString(<App/>); ctx.body=content; }) app.use(router.routes()); app.listen(SERVER_PORT, () => { console.log(`server is started on port ${SERVER_PORT} ...`); })

renderToPipeableStream

react18 中提供了 lazy、Suspense，配合 renderToPipeableStream 方法，实现流式内容下发的效果，加快首屏展示速度。
使用 renderToString 生成 html 时，可能有部分组件依赖其它资源加载生成。如果等待所有组件渲染完成再输出内容，速度会变得很慢。如果使用上面的 lazy + Suspense 方案，renderToString 甚至只能输出 fallback 的内容，不支持加载后的结果渲染。
SlowComponent.tsx

1
2
3
4
5
6
7
8
9
10
11
12

import React, { lazy } from 'react';

const SlowComponent = lazy(async () => {
    await new Promise<void>((resolve) => {
      setTimeout(() => {
        resolve()
      }, 2000)
    })
    return { default: () => <p>a slow component</p> };
  })

export default SlowComponent;

App.tsx

1
2
3
4
5
6
7
8
9
10
11
12
13
14

import React, { Suspense } from 'react';
import SlowComponent from './SlowComponent';
import './App.css';

const App = function() {
    return <>
        <p className='reactApp'>react app</p>
        <Suspense fallback={<p>loading...</p>}>
            <SlowComponent />
        </Suspense>
    </>
}

export default App;

server.tsx

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

import Koa from 'koa';
import Router from '@koa/router';
import React from 'react';
import { renderToString, renderToPipeableStream }from"react-dom/server";
import App from './App';

const SERVER_PORT = 8002;
const app = new Koa();
const router = new Router();

router.get('/', async (ctx, next) =>{
    await new Promise<void>((resolve, reject) => {
        const readableSteam = renderToPipeableStream(<App />, {
            onShellReady() {
                ctx.respond = false;
                ctx.res.statusCode = 200;
                ctx.response.set('content-type', 'text/html');
                readableSteam.pipe(ctx.res);
            },
            onError(err) {
                reject(err);
            },
        });
    })
})

app.use(router.routes());
app.listen(SERVER_PORT, () => {
    console.log(`server is started on port ${SERVER_PORT} ...`);
})

这样就能实现首屏内容快速加载，耗时内容流式下发的效果。

慢组件加载完成后

renderToReadableStream

同 reanderToPipeableStream，只是返回的是 Web 可读流，而不是 nodejs 的可读流，一般在 Deno 或支持 Web Streams 的运行时中使用。

renderToStaticMarkup

和 renderToString 类似，只是其生成的内容无法在客户端水合（后面会提到），适合纯展示类型静态页。

renderToStaticNodeStream

和 renderToStaticMarkup 类似，其生成的内容是一个 node 可读流，支持 Suspend，但是无法再客户端水合。

2. 同构与水合

在上面示例的基础上，添加一个点击交互组件，客户端渲染，组件正常工作。服务端渲染，点击后没有反应。

查看服务端渲染返回的内容，也确实没有任何脚本内容。
修改 client 渲染的入口，client 端的 react 将会连接到内部有 domNode 的 HTML 上，然后接管其中的 domNode，这个操作称为“水合”。

1

const root = hydrateRoot(rootContainer, <App />);

修改 client 打包配置，让 client 的 output 输出为一个 client.js。

此时可以将 client.js 的 url 直接插入服务端渲染输出的 html 中，或者通过 renderToPipeableStream 提供的 bootstrapScripts 选项来设置，下面是一个通过 bootstrapScripts 来设置的示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

app.use(KoaStatic(path.resolve(__dirname, '../client/')));

router.get('/ssr', async (ctx, next) =>{
    // const content = renderToString(<App/>);
    // ctx.body=content;
    await new Promise<void>((resolve, reject) => {
        const readableSteam = renderToPipeableStream(<App />, {
            bootstrapScripts: ['client.js'],
            onShellReady() {
                ctx.respond = false;
                ctx.res.statusCode = 200;
                ctx.response.set('content-type', 'text/html');
                readableSteam.pipe(ctx.res);
            },
            onError(err) {
                reject(err);
            },
        });
    })
})

可以看到 ssr 返回的代码中附加了客户端的脚本。此时如果服务端渲染的 dom 结构和客户端渲染的结构不同，会导致 hydrate 时无法找到目标 dom，无法正确接管，无法达到正确效果。

注意：实际生产环境比这种情况要复杂，可能存在 hash 命名或者代码/公共库/运行时拆分，需要结合打包工具插件生成 assetsMap 来获取打包后的资源。

3. 路由处理

ssr路由支持

客户端渲染时，一般可以通过 hash 或者 pushState 来实现单页应用路由，而这俩在服务端都无法使用。
react-router-dom 提供了 StaticRouter 来实现服务端渲染的路由。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

router.get(/^\/ssr.*/gim, async (ctx, next) =>{
    const data = <><html><head><title>react ssr</title></head><body><div id="root">
        <StaticRouter location={ctx.request.path}>
            <App />
            { routes }
        </StaticRouter>
    </div></body></html></>;
    await new Promise<void>((resolve, reject) => {
        const readableSteam = renderToPipeableStream(data, {
            // bootstrapScripts: ['/client.js'],
            onShellReady() {
                ctx.respond = false;
                ctx.res.statusCode = 200;
                ctx.response.set('content-type', 'text/html');
                readableSteam.pipe(ctx.res);
            },
            onError(err) {
                reject(err);
            },
        });
    })
})

注意点：

• 必须使用 StaticRouter
• 后端需要自己处理 router 请求路径的问题

  路由同构

  此时，ssr 应用已经支持了后端路由，在页面上通过 Link 切换路由时，可以看到应用内容随路由变化。但是路由每次切换时，都是一次刷新页面。

此时在客户端使用 BrowserRouter 实现同样的路由逻辑，使用 bootstrapScripts 开启客户端水合，即可对路由逻辑进行同构。

服务端：

1
2
3
4
5
6

...
const readableSteam = renderToPipeableStream(data, {
    bootstrapScripts: ['/client.js'],
    ...
});
...

客户端：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

import React, { StrictMode } from 'react';
import { createRoot, hydrateRoot } from 'react-dom/client'
import { BrowserRouter } from 'react-router-dom';
import routes from './Router';
import App from './App'
import './index.css'

const rootContainer = document.querySelector('#root');
if (rootContainer) {
    hydrateRoot(rootContainer, <StrictMode>
        <BrowserRouter>
            <App />
            { routes }
        </BrowserRouter>
    </StrictMode>)
}

注意点：

• 因为server端对路由增加了支持，要小心 bootstrapScripts 解析路径不受影响，否则会导致拉取脚本时拿到 ssr 返回的 html 结果而导致 hydrate 失败
• 客户端需要使用 BrowserRouter 而不是 HashRouter，否则会导致从子路由进入应用时 hydrate 失败

4. 样式处理

在“基础的 ssr 实现”示例中， App 组件引入了样式，在客户端渲染时，通过 style-loader 或者 MiniCssExtractPlugin.loader 可以让样式生效，但是使用服务端渲染时，样式无效了。

对于不同方式的样式，ssr 时也需要做不同的处理。

同构时由客户端设置

在“同构与水合”、“路由处理” 的示例中，客户端打包时选择用 style-loader 将样式附加到页面中，所以一旦水合成功，页面样式就设置成功了。

这种方式会导致 ssr 直出的时候实际上是丢失样式的，直到客户端第二次渲染完成后，样式才设置上。对于比较复杂的页面，会有样式闪烁的问题。

使用 isomorphic-style-loader

isomorphic-style-loader 可以像客户端的 style-loader 一样，在 ssr 时向 html 中插入样式。
项目地址：https://github.com/kriasoft/isomorphic-style-loader
组件中

1
2
3
4
5
6
7
8
9
10
11
12
13

import React from 'react'
import withStyles from 'isomorphic-style-loader/withStyles'
import s from './App.scss'

function App(props, context) {
  return (
    <div className={s.root}>
      <h1 className={s.title}>Hello, world!</h1>
    </div>
  )
}

export default withStyles(s)(App)

服务端

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

import StyleContext from 'isomorphic-style-loader/StyleContext'
import App from './App.js'
...
server.get('*', (req, res, next) => {
  const css = new Set() // CSS for all rendered React components
  const insertCss = (...styles) => styles.forEach(style => css.add(style._getCss()))
  const body = ReactDOM.renderToString(
    <StyleContext.Provider value={{ insertCss }}>
      <App />
    </StyleContext.Provider>
  )
  const html = `<!doctype html>
    <html>
      <head>
        <script src="client.js" defer></script>
        <style>${[...css].join('')}</style>
      </head>
      <body>
        <div id="root">${body}</div>
      </body>
    </html>`
  res.status(200).send(html)
})
...

客户端 hydrate 时

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

...
import StyleContext from 'isomorphic-style-loader/StyleContext'
import App from './App.js'

const insertCss = (...styles) => {
  const removeCss = styles.map(style => style._insertCss())
  return () => removeCss.forEach(dispose => dispose())
}

ReactDOM.hydrate(
  <StyleContext.Provider value={{ insertCss }}>
    <App />
  </StyleContext.Provider>,
  document.getElementById('root')
)

最终生成的 html

1
2
3
4
5
6
7
8
9
10

<html>
  <head>
...
    <style type="text/css">
      .App_root_Hi8 { padding: 10px }
      .App_title_e9Q { color: red }
    </style>
  </head>
...
</html>

打包工具获取资源表

这种方式是 react 官方文档在流式 ssr 中推荐的一种方式，我感觉这是最贴近生产，侵入性也是相对较小的一种方式了。
服务端：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

// 你需要从你的打包构建工具中获取这个 JSON。
const assetMap = {
  'styles.css': '/styles.123456.css',
  'main.js': '/main.123456.js'
};

app.use('/', (request, response) => {
  const { pipe } = renderToPipeableStream(<App assetMap={assetMap} />, {
    // 注意: 由于这些数据并非用户生成，所以使用 stringify 是安全的。
    bootstrapScriptContent: `window.assetMap = ${JSON.stringify(assetMap)};`,
    bootstrapScripts: [assetMap['main.js']],
    onShellReady() {
      response.setHeader('content-type', 'text/html');
      pipe(response);
    }
  });
});

设置 bootstrapScriptContent 是为了让客户端也能获取到一样的数据，以支持同构。
客户端：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

// index.tsx
import { hydrateRoot } from 'react-dom/client';
import App from './App.js';

hydrateRoot(document, <App assetMap={window.assetMap} />);

// App.tsx
export default function App({ assetMap }) {
  return (
    <html>
      <head>
        ...
        <link rel="stylesheet" href={assetMap['styles.css']}></link>
        ...
      </head>
      ...
    </html>
  );
}

5. 状态和数据请求

redux 的 ssr 同构

在组件中使用 redux 维护全局状态，并在路由页面中异步加载数据
store.tsx

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81

import { createAsyncThunk, createSlice, configureStore, combineReducers } from '@reduxjs/toolkit';
import { TypedUseSelectorHook, useSelector, useDispatch } from 'react-redux';

// 命名空间、全局状态初始值
const namespace = 'global';
const initialState = {
    page1Data: 'loading...',
    page2Data: 'loading...',
};

// 异步获取数据方法封装
export const fetchPage1Data = createAsyncThunk(
    `${namespace}/fetchPage1Data`,
    async (dataName: string) => {
        const res = await new Promise((resolve, reject) => {
            console.log('fetch data1...')
            setTimeout(() => {
                resolve(`remote page1 data of ${dataName}`)
            }, 1000)
        })
        return { page1Data: res };
    },
);

export const fetchPage2Data = createAsyncThunk(
    `${namespace}/fetchPage2Data`,
    async (dataName: string) => {
        const res = await new Promise((resolve, reject) => {
            console.log('fetch data2...')
            setTimeout(() => {
                resolve(`remote page2 data of ${dataName}`)
            }, 1000)
        })
        return { page2Data: res };
    },
);

// 创建带有命名空间的reducer
const globalInfoSlice = createSlice({
    name: namespace,
    initialState,
    reducers: {
      clearData: (state) => {
        state.page1Data = '';
        state.page2Data = '';
      },
    },
    // 处理异步reducer
    extraReducers: (builder) => {
      builder
        .addCase(fetchPage1Data.fulfilled, (state, { payload }) => {
          if (!payload) return;
          state.page1Data = payload.page1Data as string;
        })
        .addCase(fetchPage2Data.fulfilled, (state, { payload }) => {
            if (!payload) return;
            state.page2Data = payload.page2Data as string;
        })
    },
});


// 封装 hook
const reducer = combineReducers({
    global: globalInfoSlice.reducer,
});

const store = configureStore({
    reducer,
});

export const { clearData } = globalInfoSlice.actions;
export const selectGlobal = (state: RootState) => state.global;

export type RootState = ReturnType<typeof store.getState>;
export type AppDispatch = typeof store.dispatch;

export const useAppDispatch = () => useDispatch<AppDispatch>();
export const useAppSelector: TypedUseSelectorHook<RootState> = useSelector;

export default store;

路由页面中加载数据、使用数据

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

import React, { useEffect } from 'react';
import { useAppSelector, useAppDispatch, fetchPage1Data } from './store';

const RoutePage1 = function() {
    const dispatch = useAppDispatch();
    const page1Data = useAppSelector((state) => state.global.page1Data);
    useEffect(() => {
        dispatch(fetchPage1Data('data1'))
    }, [])
    return <>
        <p>content of route 1</p>
        <p>remote data of page1 from redux: {page1Data}</p>
    </>
}

export default RoutePage1;

entry 入口 client.tsx

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

import React, { StrictMode } from 'react';
import { createRoot, hydrateRoot } from 'react-dom/client'
import { BrowserRouter, HashRouter } from 'react-router-dom';
import { Provider } from 'react-redux';
import store from './store';
import routes from './Router';
import App from './App'

import './index.css'

const rootContainer = document.querySelector('#root');
if (rootContainer) {
    const root = createRoot(rootContainer);
    root.render(
        <StrictMode>
            <Provider store={store}>
                <HashRouter>
                    <App />
                    { routes }
                </HashRouter>
            </Provider>
        </StrictMode>
    )
}

启动客户端应用调试，切换到对应路由后，能正常加载数据、显示数据。
修改服务端渲染入口， server.tsx

1
2
3
4
5
6
7
8
9
10

import { Provider } from 'react-redux';
import store from './store';
...
<Provider store={store}>
    <StaticRouter location={ctx.request.path}>
        <App />
        { routes }
    </StaticRouter>
</Provider>
...

客户端 client.tsx 修改为水合并重新打包

1
2
3
4
5
6
7
8
9
10

...
hydrateRoot(rootContainer, <StrictMode>
        <Provider store={store}>
            <BrowserRouter>
                <App />
                { routes }
            </BrowserRouter>
        </Provider>
    </StrictMode>)
...

服务端异步请求

上一步中，已经成功实现了同构的 redux 状态管理。

然而我们观察页面展示效果和源码，可以发现 ssr 返回的数据其实是 redux 中的初始数据，真正的数据加载还是在客户端水合后，组件渲染后触发的。

想要 ssr 直出异步数据加载后的 html，思路也比较简单，就是找到当前路由，然后执行它的数据加载逻辑，加载完毕后再渲染返回就行了。

可以使用 react-router-config 模块提供的 matchRoutes 获取当前的路由。为此，我们需要将路由改造成 matchRoutes 需要的 RouteConfig 格式。

1
2
3
4
5
6
7
8
9
10
11

export interface RouteConfig {
    key?: React.Key | undefined;
    location?: Location | undefined;
    component?: React.ComponentType<RouteConfigComponentProps<any>> | React.ComponentType | undefined;
    path?: string | string[] | undefined;
    exact?: boolean | undefined;
    strict?: boolean | undefined;
    routes?: RouteConfig[] | undefined;
    render?: ((props: RouteConfigComponentProps<any>) => React.ReactNode) | undefined;
    [propName: string]: any;
}

路由定义

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

// Router.tsx
...
const routes = [
    {
      path: '/ssr/route1',
      component: <RoutePage1 />,
      exact: true,
      // 供服务端调用
      loadData: RoutePage1.loadData,
      key: 'route1'
    },
    {
      path: '/ssr/route2',
      component: <RoutePage2 />,
      exact: true,
      loadData: RoutePage2.loadData,
      key: 'route2'
    }
];
// server.tsx 服务端路由
...
<Provider store={store}>
    <StaticRouter location={ctx.request.path}>
        <App />
        <Routes>
        {routes.map((route) => {
            return <Route path={route.path as string} key={route.key} element={route.component as ReactNode}/>;
        })}
        </Routes>
    </StaticRouter>
</Provider>
...
// client.tsx 客户端水合
...
hydrateRoot(rootContainer, <StrictMode>
    <Provider store={store}>
        <BrowserRouter>
            <App />
            <Routes>
            {routes.map((route) => {
                return <Route path={route.path as string} key={route.key} element={route.component as ReactNode}/>;
            })}
            </Routes>
        </BrowserRouter>
    </Provider>
</StrictMode>)
...

服务端判断路由并加载数据
(在我使用的 react-router@6.x 和 react-router-config@5.x 版本下，matchRoutes 有BUG会报错：TypeError: pathname.match is not a function。这里替换为自己的简单实现)

1
2
3
4
5

// 获取当前路由，若有匹配的路由，则先加载数据，以做到服务端 ssr 直出最终的 html
// const matchedRoutes = matchRoutes(routes, ctx.request.path);
const matchedRoutes = routes.filter(route => route.path === ctx.request.path);
const loadDataRequests = matchedRoutes.filter(item => item.loadData).map(item => item.loadData(store));
await Promise.all(loadDataRequests);

此时可以观察到几个现象

• 服务端返回的 html 已经是符合预期的加载好数据之后的内容了
• 客户端在展示服务端加载结果后一瞬间又会切换到初始值，并重新走一遍加载逻辑
• 控制台中有 hydrate 过程的异常报错

注水脱水

上面的现象其实比较好理解，客户端在水合结束后，会立即开始运行客户端代码，即渲染 store 中的初始值，并在渲染完毕后去拉取远程数据，导致一次无意义的数据请求。

有一种比较简单的思路，在服务端渲染时，把加载好的数据通过 script 标签写入到window中，客户端从 window 中拿到初始数据后用于初始化 store。这个过程被称为服务端注水、客户端脱水。

服务端注水

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

// server.tsx
await new Promise<void>((resolve, reject) => {
        const readableSteam = renderToPipeableStream(data, {
            bootstrapScripts: ['/client.js'],
            bootstrapScriptContent: `window.context = {state: ${JSON.stringify (store.getState())}}`,
            onShellReady() {
                ctx.respond = false;
                ctx.res.statusCode = 200;
                ctx.response.set('content-type', 'text/html');
                readableSteam.pipe(ctx.res);
            },
            onError(err) {
                reject(err);
            },
        });
    })

客户端脱水

1
2
3
4
5
6
7
8
9
10
11

// store.tsx
// 命名空间、全局状态初始值
const namespace = 'global';
let initialState = {
    page1Data: 'loading...',
    page2Data: 'loading...',
};
declare const window: Window & { context: { state: any} };
if (typeof window !== 'undefined') {
    initialState = window.context?.state?.global || initialState;
}

这样就能从 window 中获取服务端请求好的数据了。但是此时客户端组件渲染完成后仍然会去加载一次数据，可以在客户端增加一些判断，不要重复加载数据。

1
2
3
4

// RoutePage1.tsx
useEffect(() => {
    if (page1Data === 'loading...') dispatch(fetchPage1Data('data1'))
}, [])

这样就完成了一个无冗余请求的 redux 同构应用。

6. 基于 next.js 的 ssr

前面提到的内容会给代码带来不小的复杂度和维护成本，生产环境下也可以选择一些比较成熟的开源库来实现，如 next.js。

next.js 封装了基本的 ssr 实现、css支持、服务端数据加载等（可以让组件通过提供 getServerSideProps 方法来实现服务端的数据加载）。

1
2
3
4
5
6
7
8
9
10
11
12
13

export default function Page({ data }) {
  // Render data...
}
 
// This gets called on every request
export async function getServerSideProps() {
  // Fetch data from external API
  const res = await fetch(`https://.../data`)
  const data = await res.json()
 
  // Pass data to the page via props
  return { props: { data } }
}

其它细节这里不再赘述，可参考文档 https://nextjs.org/docs/pages/building-your-application/data-fetching/get-server-side-props。

react 中有一些不符合直觉，容易忽略或者误解的点，想要编写出高质量的 react 代码，通读文档还是很有必要的。这部分主要内容来自官方文档（ https://react.dev/ ），官方文档中给出了非常多的示例代码，以及最佳实践和常见错误的示例。

结合我以往编码经验和官方文档描述，从 JSX 、状态管理、副作用 等方面，记录一些 react 编码要点。

1.1 JSX

1.1.1 组件命名限制

这算是个入门级的潜规则，组件的名称必须以大写字母开头。如果组件名不是以大写字母开头的，react dom 不会把它识别为一个组件。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

function myButton() {
  return (
    <button>
      I'm a button
    </button>
  );
}

let App = function MyApp() {
  return (
    <div>
      <h1>Welcome to my app</h1>
      <myButton />
    </div>
  );
}

1.1.2 禁止嵌套定义组件

组件可以嵌套渲染其他组件，但是禁止嵌套定义组件。这一点单独拿出来说，是因为 react 编译时运行时均不认为这是一个错误，然而这样做会导致运行时性能问题和体验BUG。

① 性能问题 —— 重复渲染

1
2
3
4

function ParentComponent(){
  function ChildComponent(){...}
  return <>...<ChildComponent />...</>
}

上面的写法中，父组件每次重新渲染时，都会重新定义子组件，进而导致每次返回的 JSX 组件中，子组件部分都是一个全新组件。渲染、提交DOM时，会将其当做一个全新的渲染节点，生成新的 DOM 节点。

② 体验 BUG —— 子组件状态丢失

有时候如果子组件本身没有状态，我们并不容易发现重复渲染的性能问题。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

let App = function MyApp() {
  const [counter, setCounter] = useState(0);
  function ChildComponent() {
    const id = useId()
    const [content, setContent] = useState('');
    return (<>
      <p>component id is: {id}, content is: {content}</p>
      <input value={content} onChange={(e)=>{ setContent(e.target.value) }} />
    </>)
  }
  return (
    <div>
      <h1>Welcome to my app</h1>
      <button onClick={() => {setCounter(counter + 1)}}>counter: {counter}</button>
      <ChildComponent />
    </div>
  );
}

如果子组件中有状态，则在父组件重新渲染时，会触发子组件的重新定义重新渲染生成，其状态会丢失，运行上面的代码还可以看到子组件的 id 在不断发生变化。

③ 体验 BUG —— 焦点丢失

当子组件嵌套定义时，它可以访问到父组件的状态，如果直接在子组件中使用和修改父组件的状态，还可能引入因重新渲染而丢失焦点的体验问题。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

let App = function MyApp() {
  const [counter, setCounter] = useState(0);
  const [content, setContent] = useState('');
  function ChildComponent() {
    const id = useId()
    return (<>
      <p>component id is: {id}, content is: {content}</p>
      <input value={content} onChange={(e)=>{ setContent(e.target.value) }} />
    </>)
  }
  return (
    <div>
      <h1>Welcome to my app</h1>
      <button onClick={() => {setCounter(counter + 1)}}>counter: {counter}</button>
      <ChildComponent />
    </div>
  );
}

例如上面的写法，组件貌似可以正常工作，但是每输入一个字符，输入框的焦点就会丢失。原因就是嵌套定义带来的子组件重新渲染问题。

解决方案非常简单，如上面②中的示例，将子组件挪到外面定义就行了；③中的示例，子组件本身没有状态，可以把它挪到外面定义，或者当做函数调用而不是子组件使用 {ChildComponent()}。

1.1.3 html 不是 JSX

看起来我们可以直接在 JSX 中使用 html 的标签， 但是要注意的是 html 并不能直接当 JSX 使用。

标签属性和内联style属性需要以驼峰命名法编写。

例如，html

1

<ul style="background-color: black">

在 JSX 组件里应该写成

1

<ul style={{ backgroundColor: 'black' }}>

需要避免 JSX 属性和 html 属性冲突。
由于 class 是一个保留字，所以在 React 中需要用 className 来代替。

更多细节可以使用 html-to-jsx 转换器探索。 https://transform.tools/html-to-jsx。

1.1.4 条件渲染时的 && 写法

条件渲染时，切勿将数字放在 && 左侧，0将会被作为文本渲染

1.1.5 列表渲染时的 key

• 不要把数组项的索引当作 key 值来用
• 不要使用随机数当做 key 使用
  这两种方式都会导致渲染性能下降。

1.1.6 严格模式与纯函数

纯函数的特征：

• 只负责自己的任务。它不会更改在该函数调用前就已存在的对象或变量。
• 输入相同，则输出相同。给定相同的输入，纯函数应总是返回相同的结果。

简单来说就是纯函数不会修改外部的变量或对象，也不会引用外部会发生变化的变量/对象。

下面是一个非纯函数组件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

let guest = 0;
function Cup() {
  // Bad: changing a preexisting variable!
  guest = guest + 1;
  return <h2>Tea cup for guest #{guest}</h2>;
}
export default function TeaSet() {
  return (
    <>
      <Cup />
      <Cup />
      <Cup />
    </>
  );
}

这个组件在每次渲染时都会让外部变量加1，有很多不可控因素会影响这个组件的渲染，例如父组件重新渲染带来的子组件重新渲染等，导致最终的结果不可控。

基于非纯函数的特性，react 在开发环境下引入的 StrictMode 来帮助检测这些问题，Strict 模式下，每个组件会被渲染两次，这样上面的组件显示的结果就是 2、4、6 而不是 1、2、3。

1.2 状态管理

1.2.1 状态的本质

状态在 react 内部的实现，类似一个组件实例绑定的数组，下面是一段示例代码帮助我们理解

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

let componentHooks = [];
let currentHookIndex = 0;

// useState 在 React 中是如何工作的（简化版）
function useState(initialState) {
  let pair = componentHooks[currentHookIndex];
  if (pair) {
    // 这不是第一次渲染
    // 所以 state pair 已经存在
    // 将其返回并为下一次 hook 的调用做准备
    currentHookIndex++;
    return pair;
  }

  // 这是我们第一次进行渲染
  // 所以新建一个 state pair 然后存储它
  pair = [initialState, setState];

  function setState(nextState) {
    // 当用户发起 state 的变更，
    // 把新的值放入 pair 中
    pair[0] = nextState;
    updateDOM();
  }

  // 存储这个 pair 用于将来的渲染
  // 并且为下一次 hook 的调用做准备
  componentHooks[currentHookIndex] = pair;
  currentHookIndex++;
  return pair;
}

详见文档：react.dev/learn/state-a-components-memory#giving-a-component-multiple-state-variables

这段代码演示了组件是如何记忆状态变量，并在每次重新渲染时返回变量的。

值得注意的是，组件的状态由 react 保存，且对于每个组件实例（即渲染节点），状态都是隔离且私有的。

1.2.2 状态更新（不可变对象）

组件的状态应该是一个不可变对象，即不能在组件内部直接给状态变量赋值、修改状态变量的属性/元素等。

① 不能直接在组件中修改状态变量或者给状态变量赋值

1
2
3
4
5
6
7
8
9
10
11
12
13

function Component(){
  let [counter, setCounter] = useState(0);
  // 这样赋值修改的是当前作用域的值，不会对存储在组件对象内部的状态值造成任何影响
  counter = 1;
  // ...
  let [obj, setObj] = useState({});
  // 这样赋值修改会影响状态，但是无法正确触发组件重新渲染
  obj.a = 1;
  // ...
  let [arr, setArr] = useState([]);
  // 这样赋值修改会影响状态，但是无法正确触发组件重新渲染
  arr[3] = 1;
}

② 如果 state 变量是一个对象时，不能只更新它的属性。

1
2
3
4
5
6
7

function Component(){
  let [obj, setObj] = useState({a:1, b:2});
  // 这样会导致 obj 整体变为 {a: 3}，b属性丢失
  setObj({a: 3});
  // 正确做法
  setObj({...obj, a: 3});
}

③ 不能使用状态对象或数组本身修改后更新状态

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

function Component(){
  let [obj, setObj] = useState({a:1, b:2});
  // 这样的状态修改不能正常触发重新渲染
  obj.a = 3;
  setObj(obj);
  // 正确做法，创建一个新对象
  setObj({...obj, a: 3});
  // ...
  let [arr, setArr] = useState([1, 2, 3]);
  // 这样的状态修改不能正常触发重新渲染
  arr.push(4);
  setArr(arr);
  // 正确做法，创建一个新数组
  setArr([...arr, 4]);
}

react 使用 Object.is 来比较状态是否发生变化，因而直接修改状态本身，react 是感知不到状态变化的，在更新渲染树时也就不会更新渲染节点。

使用不可变对象库可以简化写法，参考：

• https://github.com/immerjs/immer
• https://github.com/immerjs/use-immer
• https://github.com/tnfe/limu

1.2.3 重新渲染时的状态保留和重置

react 从组件中创建渲染树，并基于渲染树创建真正的 DOM 树。中间的部分就是根据组件渲染得到的渲染树。

当向一个组件添加状态时，看起来状态是保存在组件内。但实际上，状态是由 React 保存的。React 通过组件在渲染树中的位置将它保存的每个状态与正确的组件关联起来。

也就是说，只有当在树中相同的位置渲染相同的组件时，React 才会一直保留着组件的 state。

值得注意的是，react 在生成渲染树时，每个花括号内的渲染结果都会被当做一个渲染节点，下面的两个 JSX 示例中

1
2
3
4
5
6
7
8
9
10
11
12
13

<div>
  {isFancy ? (
    <Counter isFancy={true} /> 
  ) : (
    <Counter isFancy={false} /> 
  )}
</div>
...
<div>
  {isFancy ? <Counter isFancy={true} /> : null }
  {isFancy ? null : <Counter isFancy={false} /> }

</div>

前面的写法会被 react 解析成一个渲染节点，isFancy 发生变化时，这个渲染节点返回的总是 Counter 组件，Counter 组件对应的状态变量保留；后面的写法则会被解析为两个渲染节点，分别根据情况返回 Counter 组件或者 null，此时 isFancy 发生变化时，表达式返回的组件不同，状态不会保留。

这两种写法渲染效果从表面上看是一致的，但是内部的状态逻辑完全不同，值得注意。

1.2.4 使用 reducer 整合状态更新

由 useState 切换到 useReducer 可以将复杂的状态更新逻辑整合到 reducer 函数中。

reducer 函数的作用用一句话来描述就是：接收当前的 state 和一个 action，返回经过 action 处理后的 state。

reducer 函数一般可以支持多种 action，即把不同的更新逻辑都整合到各种 action 中。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78

import { useReducer } from 'react';
import AddTask from './AddTask.js';
import TaskList from './TaskList.js';

export default function TaskApp() {
  const [tasks, dispatch] = useReducer(tasksReducer, initialTasks);

  function handleAddTask(text) {
    dispatch({
      type: 'added',
      id: nextId++,
      text: text,
    });
  }

  function handleChangeTask(task) {
    dispatch({
      type: 'changed',
      task: task,
    });
  }

  function handleDeleteTask(taskId) {
    dispatch({
      type: 'deleted',
      id: taskId,
    });
  }

  return (
    <>
      <h1>布拉格的行程安排</h1>
      <AddTask onAddTask={handleAddTask} />
      <TaskList
        tasks={tasks}
        onChangeTask={handleChangeTask}
        onDeleteTask={handleDeleteTask}
      />
    </>
  );
}

function tasksReducer(tasks, action) {
  switch (action.type) {
    case 'added': {
      return [
        ...tasks,
        {
          id: action.id,
          text: action.text,
          done: false,
        },
      ];
    }
    case 'changed': {
      return tasks.map((t) => {
        if (t.id === action.task.id) {
          return action.task;
        } else {
          return t;
        }
      });
    }
    case 'deleted': {
      return tasks.filter((t) => t.id !== action.id);
    }
    default: {
      throw Error('未知 action: ' + action.type);
    }
  }
}

let nextId = 3;
const initialTasks = [
  {id: 0, text: '参观卡夫卡博物馆', done: true},
  {id: 1, text: '看木偶戏', done: false},
  {id: 2, text: '打卡列侬墙', done: false}
];

参考 http://react.dev/learn/extracting-state-logic-into-a-reducer#step-3-use-the-reducer-from-your-component

1.2.5 使用 props 传递状态

下面是一个官网提供的典型示例，若两个同级子组件想要共享一个状态，可以将状态提升到它们的父组件中，然后通过 props 向下传递状态。

变量提升，并通过 props 向子组件传递状态

1.2.6 使用 context 传递状态

使用 props 时，状态需要逐级透传，当组件数量多结构复杂时，这样效率会非常低，而且让组件的结构变得复杂难以维护。

而使用 context 可以跨层级传递状态

一般用于传递这类数据：

• 站点主体
• 登录用户信息
• 页面路由
• 全局状态管理

  1.2.7 影响渲染的因素总结

  总结一下，当一个组件的渲染函数被调用时，除了它自身内部的局部变量和引用的外部变量（如浏览器API返回的外部状态数据等），还有这些可变因素会影响渲染结果
• state
• props
• context

1.3 副作用

1.3.1 什么时候使用

react 中的逻辑分为这几类

• 渲染逻辑代码：组件的主体代码部分，一个返回 JSX 组件的纯函数
• 用户事件处理程序：特征组件内部，用于处理用户操作（如点击或者输入）引起的引起的“副作用”（它们改变了程序的状态）。
• 用渲染本身引起的副作用：如组件渲染后需要连接到服务器，或者需要加载数据等。
  值得注意的是，useEffect 的执行时机是 渲染完成、屏幕更新后的 commit 阶段运行。

1.3.2 触发类型

useEffect 有无依赖参数、空数组依赖、非空数组依赖 三种情况

1
2
3
4
5
6

// 每次渲染完成后都执行
useEffect(() => {})
// 仅第一次渲染完成后执行
useEffect(() => {}, [])
// 依赖的变量 a / b 中任意一个发生变化后执行
useEffect(() => {}, [a, b])

其中第三种方式要注意，在 useEffect 中依赖的任何可变对象，都需要在后面的依赖数组中传入，否则 react 会报错。

1.3.3 useEffect 引起的死循环

useEffect 会在每次渲染后执行，或者每次渲染后依赖发生变化后执行，下面的写法会导致每次 useEffect 执行后状态被改变，又触发重新渲染，导致死循环。

1
2
3
4
5
6
7
8

const [count, setCount] = useState(0);
useEffect(() => {
  setCount(count + 1);
});
//...
useEffect(() => {
  setCount(count + 1);
}, [count]);

1.3.4 多种不应该使用 useEffect 的情况

参考文档 https://react.dev/learn/you-might-not-need-an-effect
官方给出的场景非常多，就不一一列举了，感觉也记不住。

我觉得要不最佳实践就别记黑名单了，记白名单吧：

• 组件初始化时的服务器连接操作
• 组件初始化时的数据加载操作等
• 一次渲染完毕后的其它操作如修改 DOM 等

1.3.5 useEffect 的生命周期

Effect 与组件有不同的生命周期。组件可以挂载、更新或卸载。Effect 只能做两件事：开始同步某些东西，然后停止同步它。如果 Effect 依赖于随时间变化的 props 和 state，这个循环可能会发生多次。

例如下面的 useEffect

1
2
3
4
5
6
7
8
9
10
11
12

const serverUrl = 'https://localhost:1234';

function ChatRoom({ roomId }) {
  useEffect(() => {
    const connection = createConnection(serverUrl, roomId);
    connection.connect();
    return () => {
      connection.disconnect();
    };
  }, [roomId]);
  // ...
}

在 组件挂载 → roomId 发生变化 → 组件卸载，的过程中，useEffect 可能经历下面的生命周期

1

ChatRoom 组件的变化过程：

ChatRoom 组件挂载，roomId 设置为 "general"
ChatRoom 组件更新，roomId 设置为 "travel"
ChatRoom 组件更新，roomId 设置为 "music"
ChatRoom 组件卸载

Effect 执行了不同的操作：
Effect 连接到了 "general" 聊天室
Effect 断开了与 "general" 聊天室的连接，并连接到了 "travel" 聊天室
Effect 断开了与 "travel" 聊天室的连接，并连接到了 "music" 聊天室
Effect 断开了与 "music" 聊天室的连接

1.4 hooks

1.4.1 现有 hooks

参考文档：https://react.dev/reference/react/hooks
目前 react 提供了内置的 useState、useContext、useRef、useEffect 等常用 hook，以及

• 性能优化相关hook： useMemo、useCallback、useTransition、useDeferredValue
• 资源相关 hook：use
• 其它 hook：useDebugValue、useId、useSyncExternalStore

  1.4.2 自定义 hooks

  像组件有一个命名规范一样，自定义 hooks 也有要遵守的命名规范。
• React 组件名称必须以大写字母开头，比如 StatusBar 和 SaveButton。React 组件还需要返回一些 React 能够显示的内容，比如一段 JSX。
• Hook 的名称必须以 use 开头，然后紧跟一个大写字母，如内置的 useState 或者自定义的 useOnlineStatus 。Hook 可以返回任意值。
  需要注意的是，自定义 Hook 共享的是状态逻辑，而不是状态本身。
  参考官方文档 https://react.dev/learn/reusing-logic-with-custom-hooks#custom-hooks-let-you-share-stateful-logic-not-state-itself 中的示例。

使用自定义 hook 的方式：

1
2
3
4
5
6
7
8
9

function StatusBar() {
  const isOnline = useOnlineStatus();
  // ...
}

function SaveButton() {
  const isOnline = useOnlineStatus();
  // ...
}

可以看做是和在组件中各自写重复逻辑代码一样，两个组件中的状态是私有独立，互不干扰的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

function StatusBar() {
  const [isOnline, setIsOnline] = useState(true);
  useEffect(() => {
    // ...
  }, []);
  // ...
}

function SaveButton() {
  const [isOnline, setIsOnline] = useState(true);
  useEffect(() => {
    // ...
  }, []);
  // ...
}

1.5 其它能力

1.5.1 记忆化

参考：http://react.dev/reference/react/useMemo、http://react.dev/reference/react/useCallback
可以将数据、组件、函数缓存到 react 中，当依赖项没有发生变化时，整个生命周期中数据或组件或函数不再重新生成。

① 使用 useMemo 缓存数据

1
2
3
4
5
6
7
8
9

import { useMemo } from 'react';

function TodoList({ todos, tab }) {
  const visibleTodos = useMemo(
    () => filterTodos(todos, tab),
    [todos, tab]
  );
  // ...
}

当依赖的 todos，tab 未发生变化时，TodoList 的多次重新渲染不会导致 filterTodos 的重新计算。
适用场景：数据计算量比较大时，缓存数据

② 使用 useCallback / useMemo 缓存函数

使用 useMemo 的写法

1
2
3
4
5
6
7
8
9
10
11
12

export default function Page({ productId, referrer }) {
  const handleSubmit = useMemo(() => {
    return (orderDetails) => {
      post('/product/' + productId + '/buy', {
        referrer,
        orderDetails
      });
    };
  }, [productId, referrer]);

  return <Form onSubmit={handleSubmit} />;
}

使用 useCallback 的写法，和上面的完全一样，只是为了简化写法

1
2
3
4
5
6
7
8
9
10

export default function Page({ productId, referrer }) {
  const handleSubmit = useCallback((orderDetails) => {
    post('/product/' + productId + '/buy', {
      referrer,
      orderDetails
    });
  }, [productId, referrer]);

  return <Form onSubmit={handleSubmit} />;
}

③ 使用 memo 缓存组件

默认情况下，当一个组件重新渲染时，React 会递归地重新渲染它的所有子组件。可以通过将它包装在 memo 中，这样当它的 props 跟上一次渲染相同的时候它就会跳过本次渲染。

不使用 memo 的情况

1
2
3
4
5
6
7
8
9
10

export default function TodoList({ todos, tab, theme }) {
  // 每当主题发生变化时，这将是一个不同的数组……
  const visibleTodos = filterTodos(todos, tab);
  return (
    <div className={theme}>
      {/* ... 所以List的props永远不会一样，每次都会重新渲染 */}
      <List items={visibleTodos} />
    </div>
  );
}

使用 memo 的情况

1
2
3
4
5
6
7
8
9
10
11
12
13

export default function TodoList({ todos, tab, theme }) {
  // 告诉 React 在重新渲染之间缓存你的计算结果...
  const visibleTodos = useMemo(
    () => filterTodos(todos, tab),
    [todos, tab] // ...所以只要这些依赖项不变...
  );
  return (
    <div className={theme}>
      {/* ... List 也就会接受到相同的 props 并且会跳过重新渲染 */}
      <List items={visibleTodos} />
    </div>
  );
}

总结：记忆化只要适用于下面的场景

• 跳过代价昂贵的数据重新计算：useMemo(数据, [依赖])
• 跳过组件的重新渲染：memo(组件, [依赖])
• 记忆另一个 hook 的依赖，防止重复触发：useXXX(xxx, [ useMemo(yyy) ])
• 记忆一个函数：useMemo( () => fn, [依赖] ) / useCallback(fn, [依赖])

1.5.2 ref

当你希望组件“记住”某些信息，但又不想让这些信息 触发新的渲染 时，你可以使用 ref 。

① 什么是 ref

ref 可以看做是一个不支持 setState 的状态对象：

1
2
3
4
5

// React 内部
function useRef(initialValue) {
  const [ref, unused] = useState({ current: initialValue });
  return ref;
}

从这里可以看出，ref 对象是一个不可变对象，通过 Object.js 判断两次渲染间的 ref 变量，结果永远是 true。

② 使用 ref 来缓存 DOM

当你将 ref 放在像 <input /> 这样输出浏览器元素的内置组件上时，React 会将该 ref 的 current 属性设置为相应的 DOM 节点（例如浏览器中实际的 <input /> ）。

1
2
3

import { useRef } from 'react';
const myRef = useRef(null);
<div ref={myRef}>

③ 允许 JSX 组件接收 ref

如前面所说，只有浏览器元素的内置组件才支持通过 ref 属性设置 dom，如果想要 JSX 组件也能接收 ref，可以使用 forwardRef 将组件进行包装。

1
2
3

const MyInput = forwardRef((props, ref) => {
  return <input {...props} ref={ref} />;
});

④ ref 只暴露 dom 的部分能力

可以使用 useImperativeHandle 只暴露 DOM 的一部分能力，而不是全部

1
2
3
4
5
6
7
8
9
10

const MyInput = forwardRef((props, ref) => {
  const realInputRef = useRef(null);
  useImperativeHandle(ref, () => ({
    // 只暴露 focus，没有别的
    focus() {
      realInputRef.current.focus();
    },
  }));
  return <input {...props} ref={realInputRef} />;
});

1.5.3 懒加载 lazy

参考：http://react.dev/reference/react/lazy

react 的懒加载机制：

1
2
3
4
5
6
7

import { lazy } from 'react';

const MarkdownPreview = lazy(() => import('./MarkdownPreview.js'));
<Suspense fallback={<Loading />}>
  <h2>Preview</h2>
  <MarkdownPreview />
</Suspense>

实现了懒加载模块，以及加载中时的替代组件展示。

1.5.4 useSyncExternalStore 订阅外部数据

当一个 react 组件想订阅外部来源的数据时，可以用 useEffect 的方式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

function useOnlineStatus() {
  // 不理想：在 Effect 中手动订阅 store
  const [isOnline, setIsOnline] = useState(true);
  useEffect(() => {
    function updateState() {
      setIsOnline(navigator.onLine);
    }

    updateState();

    window.addEventListener('online', updateState);
    window.addEventListener('offline', updateState);
    return () => {
      window.removeEventListener('online', updateState);
      window.removeEventListener('offline', updateState);
    };
  }, []);
  return isOnline;
}

function ChatIndicator() {
  const isOnline = useOnlineStatus();
  // ...
}

可以使用 useSyncExternalStore 来实现上面的逻辑

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

function subscribe(callback) {
  window.addEventListener('online', callback);
  window.addEventListener('offline', callback);
  return () => {
    window.removeEventListener('online', callback);
    window.removeEventListener('offline', callback);
  };
}

function useOnlineStatus() {
  // ✅ 非常好：用内置的 Hook 订阅外部 store
  return useSyncExternalStore(
    subscribe, // 只要传递的是同一个函数，React 不会重新订阅
    () => navigator.onLine, // 如何在客户端获取值
    () => true // 如何在服务端获取值
  );
}

function ChatIndicator() {
  const isOnline = useOnlineStatus();
  // ...
}

1.5.5 并发任务

在 v18 版本中， react 提供了 useDeferredValue、 startTransition 来执行并发渲染的操作，以提高复杂渲染过程的用户体验，其原理是利用渲染的空闲时间来执行复杂的渲染操作，后面会详细描述。

1.6 外部状态管理库

前面描述了 react 内置的状态管理能力，而在复杂的实际项目中，有一些问题需要解决，因而业界诞生了非常多的状态管理库，来优化 react 项目中的状态管理。他们主要解决下面的问题：

• 组件间状态共享：在大型应用中，有时候需要在多个组件之间共享状态，使用外部状态管理库可以方便地在组件间共享状态，而不需要通过层层传递 props。
• 状态管理复杂度：随着应用规模的增长，状态管理变得越来越复杂。使用外部状态管理库可以将状态管理与组件逻辑分离，使得代码更加清晰、易于维护。
• 时间旅行调试：一些外部状态管理库提供了时间旅行功能，可以方便地回溯状态变化过程，帮助开发者更快地定位问题。
• 中间件支持：外部状态管理库可以支持中间件，使得开发者可以方便地扩展状态管理功能，例如异步操作、日志记录等。

一些常见的外部状态管理库：

2. 框架原理分析

日常编码，我们参考 react 官方文档，已经可以写出足够好的代码了。如果想要更深入的了解，则需要对 react 的实现原理进行分析。

这部分主内容主要来源于 https://github.com/7kms/react-illustration-series 图解 react 核心逻辑，按应用启动、渲染流程、任务管理、用户接口（状态和副作用）、hook 的顺序进行描述。

2.1 启动流程

react 有三种启动模式：

• legacy 模式，是 react17 版本中的默认启动模式，只能进入同步工作循环，无法使用可中断渲染特性。启动方式：ReactDOM.render(, rootNode)
• Blocking 模式，是一个过渡版本，实现了部分 concurrent 模式的特性。启动方式：ReactDOM.createBlockingRoot(rootNode).render()
• Concurrent 模式，支持时间分片、可中断渲染的模式。启动方式：ReactDOM.createRoot(rootNode).render()

上面的三种启动方式都是从 react-dom 包发起，调用 react-reconciler 包。整个启动的过程概述：

• 【react-dom】入口 render/createRoot/createBlockingRoot
• 【react-dom】创建 ReactDOMRoot / ReactDOMBlockingRoot 对象，提供 render / umount 方法
• 【react-reconciler】创建 fiberRoot 对象，保存 fiber 构建过程中依赖的全局状态，保存为 ReactDOMRoot 对象的 _internalRoot 属性
• 创建 HostRootFiber 对象， react 的首个 fiber 对象，作为 fiberRoot 的 current 属性

三种模式的初始化后对象引用关系：

2.2 渲染流程

应用启动完成后，react 即进入 react-reconciler 包调用 updateContainer 函数，执行 fiber 树的构造工作，并最终将 JSX 转换为真实 DOM 节点，渲染出用户界面。

函数调用栈大致是

• updateContainer → scheduleUpdateOnFiber → performSyncWorkOnRoot（legacy模式 && 首次创建）
• updateContainer → scheduleUpdateOnFiber → ensureRootIsScheduled（concurrent 或非首次启动）→ 回调 → performSyncWorkOnRoot / performConcurrentWorkOnRoot

fiber 树构造

• 步骤一：所有采用jsx语法书写的节点, 都会被编译器转换, 最终会以React.createElement(…)的方式, 创建出来一个与之对应的ReactElement对象
• 步骤二：通过ReactElement对象创建对应的fiber对象, 多个fiber对象构成了一棵fiber树
• 步骤三：以fiber树 为数据模型构造最终的 DOM 树，触发最终的 UI 渲染

ReactElement 树和 fiber 树的构造过程都是一个深度优先遍历的过程，这里只引用 ReactElement 树的构造构成，如下

fiber 树更新

有 3 种常见方式可以主动触发 fiber 树的重新构造：

• Class组件中调用setState
• Function组件中调用hook对象暴露出的dispatchAction（使用 useState ）
• 在container节点上重复调用render

fiber树的构造过程, 就是把ReactElement转换成fiber树的过程. 在这个过程中, 内存里会同时存在 2 棵fiber树:

• 其一: 代表当前界面的fiber树(已经被展示出来, 挂载到fiberRoot.current上). 如果是初次构造(初始化渲染), 页面还没有渲染, 此时界面对应的 fiber 树为空(fiberRoot.current = null).
• 其二: 正在构造的fiber树(即将展示出来, 挂载到HostRootFiber.alternate上, 正在构造的节点称为workInProgress). 当构造完成之后, 重新渲染页面, 最后切换fiberRoot.current = workInProgress, 使得fiberRoot.current重新指向代表当前界面的fiber树
  构造过程中，当前界面的 HostRootFiber 的 alternate 属性指向更新中的 Fiber 树实例

构造完成后，切换 FiberRoot 的 current，指向更新完成的 HostRootFiber

diff 算法：更新 fiber 树的过程中，将旧的 fiber 对象与新的 ReactElement 对象相比较，给需要新增,移动,和删除的节点设置相应的 flag。

单节点比较：

• 如果是新增节点, 直接新建 fiber, 没有多余的逻辑
• 对比节点，如果key和type都相同(即: ReactElement.key === Fiber.key 且 Fiber.elementType === ReactElement.type), 则复用，否则新建

可迭代节点比较（如数组类型等）：

• 第一次循环: 遍历最长公共序列(key 相同), 公共序列的节点都视为可复用
  • 如果newChildren序列被遍历完, 那么oldFiber序列中剩余节点都视为删除(打上Deletion标记)
  • 如果oldFiber序列被遍历完, 那么newChildren序列中剩余节点都视为新增(打上Placement标记)
• 第二次循环: 遍历剩余非公共序列, 优先复用 oldFiber 序列中的节点
  • 在对比更新阶段(非初次创建fiber, 此时shouldTrackSideEffects被设置为 true). 第二次循环遍历完成之后, oldFiber序列中没有匹配上的节点都视为删除(打上Deletion标记)

fiber 树渲染

fiber 树的整个渲染逻辑都在commitRoot 函数中，渲染上屏过程大致做了下面的一些步骤。

• commitBeforeMutationEffects dom 变更之前, 处理副作用队列中带有Snapshot,Passive标记的fiber节点
  • 处理Snapshot标记
  • 处理Passive标记
• commitMutationEffects dom 变更, 界面得到更新. 处理副作用队列中带有Placement, Update, Deletion, Hydrating标记的fiber节点，最终调用appendChild, commitUpdate, removeChild这些react-dom包中的函数. 它们是HostConfig协议(源码在 ReactDOMHostConfig.js 中)中规定的标准函数, 调用后界面会得到更新。
  • 新增DOM: 函数调用栈 commitPlacement -> insertOrAppendPlacementNode -> appendChild
  • 更新DOM: 函数调用栈 commitWork -> commitUpdate
  • 删除DOM: 函数调用栈 commitDeletion -> removeChild
• commitLayoutEffectsdom 变更后, 处理副作用队列中带有Update | Callback标记的fiber节点
  • 对于ClassComponent节点, 调用生命周期函数componentDidMount或componentDidUpdate, 调用update.callback回调函数.
  • 对于HostComponent节点, 如有Update标记, 需要设置一些原生状态(如: focus等)
    渲染完成后，还要做一些清理工作
• 清除副作用队列
• 检测更新
  • 在整个渲染过程中, 有可能产生新的update(比如在componentDidMount函数中, 再次调用setState()).
  • 如果是常规(异步)任务, 不用特殊处理, 调用ensureRootIsScheduled确保任务已经注册到调度中心即可.
  • 如果是同步任务, 则主动调用flushSyncCallbackQueue(无需再次等待 scheduler 调度), 再次进入 fiber 树构造循环

2.3 任务管理

前面描述的渲染流程，fiber 树更新的整个过程中，涉及到大量的 fiber 树构造、dom生成等工作。react 实现了一套任务执行流程和任务调度机制来高效完成这些工作，具体代码在 react-reconciler、scheduler 包中实现。

reconciler 运作流程

react-reconciler包的主要作用, 将主要功能分为 4 个方面:

• 输入 scheduleUpdateOnFiber: 暴露api函数(如: scheduleUpdateOnFiber), 供给其他包(如react包)调用
  • 不经过调度, 直接进行fiber构造.
  • 注册调度任务, 经过Scheduler包的调度, 间接进行fiber构造
• 注册调度任务 ensureRootIsScheduled: 与调度中心(scheduler包)交互, 注册调度任务task, 等待任务回调
  • 判断是否需要注册新的调度(如果无需新的调度, 会退出函数)
  • 注册调度任务，等待调度中心执行回调 performSyncWorkOnRoot或performConcurrentWorkOnRoot
• 执行任务回调 performSyncWorkOnRoot / performConcurrentWorkOnRoot: 在内存中构造出fiber树, 同时与与渲染器(react-dom)交互, 在内存中创建出与fiber对应的DOM节点
  • fiber 树构造
  • 异常处理: 有可能 fiber 构造过程中出现异常
  • 调用输出
• 输出 commitRoot: 与渲染器(react-dom)交互, 渲染DOM节点，即前面描述的“fiber 树渲染” 中的工作
  • commitBeforeMutationEffects
  • commitMutationEffects
  • commitLayoutEffects

scheduler 调度原理

reconciler 运作的流程中，很多地方都涉及任务调度工作，任务调度决定了整个 react 应用的运行效率。

scheduler 模块提供了两类能力。

• 调度相关: 请求或取消调度
  • requestHostCallback 请求调度
  • cancelHostCallback 取消调度
  • requestHostTimeout 请求延时调度
  • cancelHostTimeout 取消延时调度
• 时间切片(time slicing)相关: 执行时间分割, 让出主线程(把控制权归还浏览器, 浏览器可以处理用户输入, UI 绘制等紧急任务)
  • getCurrentTime: 获取当前时间
  • shouldYieldToHost: 是否让出主线程
  • requestPaint: 请求绘制
  • forceFrameRate: 强制设置 yieldInterval(从源码中的引用来看, 算一个保留函数, 其他地方没有用到)

requestHostCallback 中，利用 MessageChannel / setTimeout 实现了类似 window.requestIdleCallback 的能力，以支持中断当前任务队列让出CPU的功能。 其中，shouldYieldToHost 让出 CPU 的判定条件是:

• currentTime >= deadline: 只有时间超过deadline之后才会让出主线程(其中deadline = currentTime + yieldInterval).
  • yieldInterval默认是5ms, 只能通过forceFrameRate函数来修改
  • 如果一个task运行时间超过5ms, 下一个task执行之前, 会把控制权归还浏览器.
• navigator.scheduling.isInputPending(): 这 facebook 官方贡献给 Chromium 的 api, 现在已经列入 W3C 标准, 用于判断是否有输入事件(包括: input 框输入事件, 点击事件等)

整个调度过程的核心流程：

scheduler 优先级和任务队列

scheduler 内部实现了两种优先级机制。

• 与fiber构造过程相关的优先级(如fiber.updateQueue,fiber.lanes)都使用LanePriority
• 与scheduler调度中心相关的优先级使用SchedulerPriority

为了能协同调度中心(scheduler包)和 fiber 树构造(react-reconciler包)中对优先级的使用, 则需要转换SchedulerPriority和LanePriority, 通过ReactPriorityLevel进行转换。

其中 LanePriority 是基于位运算实现的优先级保存和比对:

• 可以使用的比特位一共有 31 位(js的位运算最高支持到int32，减去一个符号位)
• 共定义了18 种车道(Lane/Lanes)变量, 每一个变量占有 1 个或多个比特位, 分别定义为Lane和Lanes类型.
• 每一种车道(Lane/Lanes)都有对应的优先级, 所以源码中定义了 18 种优先级(LanePriority).
• 占有低位比特位的Lane变量对应的优先级越高
  • 最高优先级为SyncLanePriority对应的车道为SyncLane = 0b0000000000000000000000000000001.
  • 最低优先级为OffscreenLanePriority对应的车道为OffscreenLane = 0b1000000000000000000000000000000

具体执行任务时, scheduler 内部定义了 2 个数组taskQueue和timerQueue, 它们都是按优先级以最小堆的形式进行存储, 这样就能保证以O(1)的时间复杂度, 取到数组顶端的对象(优先级最高的 task)

时间切片和可中断渲染

时间切片原理：

消费任务队列的过程中, 可以消费1~n个 task, 甚至清空整个 queue. 但是在每一次具体执行task.callback之前都要进行超时检测, 如果超时可以立即退出循环并等待下一次调用。

可中断渲染原理：

在时间切片的基础之上, 如果单个task.callback执行时间就很长(假设 200ms). 就需要task.callback自己能够检测是否超时, 所以在 fiber 树构造过程中, 每构造完成一个单元, 都会检测一次超时(源码链接), 如遇超时就退出fiber树构造循环, 并返回一个新的回调函数(就是此处的continuationCallback)并等待下一次回调继续未完成的fiber树构造。

react18.2中，提供了 useDeferredValue、useTransition 来进行并发渲染操作，其内部就应用了可中断渲染的功能。参考示例：

• https://zh-hans.react.dev/reference/react/useTransition
• https://zh-hans.react.dev/reference/react/useDeferredValue#examples

尝试多段连续输入触发渲染，观察是否使用可中断渲染的表现：

普通渲染

可中断渲染

2.4 状态和副作用

一个 fiber 节点中，影响最终渲染结果的属性可以分为状态类属性和副作用类属性。

• 状态类: 在renderRootSync[Concurrent]阶段, 为子节点提供确定的输入数据, 直接影响子节点的生成
• 副作用类: 在commitRoot阶段, 如果fiber被标记有副作用, 则副作用相关函数会被(同步/异步)调用

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

export type Fiber = {|
  // 1. fiber节点自身状态相关
  pendingProps: any,
  memoizedProps: any,
  updateQueue: mixed,
  memoizedState: any,

  // 2. fiber节点副作用(Effect)相关
  flags: Flags,
  subtreeFlags: Flags, 
  deletions: Array<Fiber> | null,
  nextEffect: Fiber | null,
  firstEffect: Fiber | null,
  lastEffect: Fiber | null,
|};

状态相关属性

• fiber.pendingProps: 输入属性, 从ReactElement对象传入的 props. 它和fiber.memoizedProps比较可以得出属性是否变动.
• fiber.memoizedProps: 上一次生成子节点时用到的属性, 生成子节点之后保持在内存中. 向下生成子节点之前叫做pendingProps, 生成子节点之后会把pendingProps赋值给memoizedProps用于下一次比较.pendingProps和memoizedProps比较可以得出属性是否变动.
• fiber.updateQueue: 存储update更新对象的队列, 每一次发起更新, 都需要在该队列上创建一个update对象.
• fiber.memoizedState: 上一次生成子节点之后保持在内存中的局部状态.

它们在fiber树构造阶段, 直接影响子节点的生成。

副作用相关属性

• fiber.flags: 标志位, 表明该fiber节点有副作用(在 react-reconciler/src/ReactFiberFlags.js 中定义了28种副作用).
• fiber.nextEffect: 单向链表, 指向下一个副作用 fiber节点.
• fiber.firstEffect: 单向链表, 指向第一个副作用 fiber 节点.
• fiber.lastEffect: 单向链表, 指向最后一个副作用 fiber 节点.

副作用是一个动态功能, 由于它的调用时机是在fiber树渲染阶段, 故它拥有更多的能力, 能轻松获取突变前快照, 突变后的DOM节点等. 甚至通过调用api发起新的一轮fiber树构造, 进而改变更多的状态, 引发更多的副作用。

使用副作用 hook useEffect(function(){}, [])时，其中的函数是异步执行的, 因为它经过了调度中心。

2.5 hook

hook 是一串挂载在 fiber 上的链表

1
2
3
4
5
6
7

export type Hook = {|
  memoizedState: any, // 当前状态
  baseState: any, // 基状态
  baseQueue: Update<any, any> | null, // 基队列
  queue: UpdateQueue<any, any> | null, // 更新队列
  next: Hook | null, // next指针
|};

通过调用 mountWorkInProgressHook 函数，可以创建一个 Hook 对象，将其挂载到 fiber.memoizedState 链表结构上，并返回。

并且在多次渲染之间，基于双缓冲技术对 hook 链表进行克隆，但是 hook 对象内部的状态和队列仍然共享，以保持状态不丢失。

状态 hook

使用状态类 hook，如 useState 或者 useReducer 时，实际上就是调用 mountWorkInProgressHook 创建挂载 hook 到 fiber 上，并返回其内部状态和更新函数。

创建 hook：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

function mountState<S>(
  initialState: (() => S) | S,
): [S, Dispatch<BasicStateAction<S>>] {
  // 1. 创建hook
  const hook = mountWorkInProgressHook();
  if (typeof initialState === 'function') {
    initialState = initialState();
  }
  // 2. 初始化hook的属性
  // 2.1 设置 hook.memoizedState/hook.baseState
  // 2.2 设置 hook.queue
  hook.memoizedState = hook.baseState = initialState;
  const queue = (hook.queue = {
    pending: null,
    dispatch: null,
    // queue.lastRenderedReducer是内置函数
    lastRenderedReducer: basicStateReducer,
    lastRenderedState: (initialState: any),
  });
  // 2.3 设置 hook.dispatch
  const dispatch: Dispatch<BasicStateAction<S>> = (queue.dispatch =
    (dispatchAction.bind(null, currentlyRenderingFiber, queue): any));

  // 3. 返回[当前状态, dispatch函数]
  return [hook.memoizedState, dispatch];
}

更新状态时，执行的操作是

• 创建update对象
• 将update对象添加到hook.queue.pending环形链表 → 调度更新
• 调用scheduleUpdateOnFiber, 进入reconciler 运作流程中的输入阶段

最终更新结果

副作用 hook

创建副作用hook：

和状态 hook 类似，创建 effect hook 的步骤是下面几步

• 创建hook
• 设置workInProgress的副作用标记: flags |= fiberFlags
• 创建effect(在pushEffect中), 挂载到hook.memoizedState上, 即 hook.memoizedState = effect
  创建完毕后，fiber、hook、effect 三者的引用关系如下：

处理副作用 hook 回调：

在commitRootImpl函数中，处理不同 flag 的副作用 hook 回调

• commitBeforeMutationEffects：dom 变更之前，处理副作用队列中带有 Passive 标记的 effect
• commitMutationEffects：dom 变更, 界面得到更新
• commitLayoutEffects：dom 变更后，处理副作用队列中带有 Layout 标记的 effect

有时候我们很难精准的评估一份程序在运行时的性能表现。

要分析问题得出结论，往往需要控制变量，而性能问题的变量往往会非常多。

• 同一程序在不同主频/架构的CPU上或者使用不同指令集运行，CPU占用可能相差很大
• 同一程序在同一运行环境下，使用不同的输入数据，CPU占用、内存占用相差都可能很大
• 同一程序在同一运行环境下，使用相同的输入数据，程序自身使用不同的启动选项，CPU占用、内存占用相差都可能很大

这些变量在某些比较复杂的工具软件上尤为明显。官方给出的参考 benchmark，往往只是一个或几个主流平台和主流使用场景下的数据。

实际项目中会遇到很多不一样的场景，当我们自己使用时的性能数据和官方性能数据有出入时，有可能会下意识的认为这就是前面提到的变量差异带来的，正常的性能差异。

本文记录一下容器环境逻辑核数判断对一些程序性能的影响。造成这种影响的原因是非常简单的，但是可能具有一定普遍性，且很容易因为前面所述的性能问题复杂性而被忽略，所以单独拿出来说一说。

2.容器环境逻辑核资源判断问题

容器化部署的时代，很多场景下，我们的应用不再是直接运行在物理机/虚拟机上，而容器中通过 /proc/cpuinfo 获取逻辑核数，或者通过

1
2
3
4
5
6
7

#include <unistd.h>
long sysconf(int name); // _SC_NPROCESSORS_ONLN
...
#include <sys/sysinfo.h>
int get_nprocs(void);
int get_nprocs_conf(void);
...

这些 posix 接口函数来获取逻辑核数，返回的都是宿主机的核数。

有一些软件/库中，会内置一种自动配置选项的操作：获取默认的逻辑核数，然后根据逻辑核数初始化最佳的工作线程数。

这种操作在非容器时代，能让程序使用代价降低，在内部自动做好最佳性能选项配置。然而在容器部署的时代，就可能因为错用了宿主机的核数，导致了大量的线程切换开销、多余缓存数据、锁竞争等问题，出现反向优化的情况。

3.逻辑核数判断问题对性能的影响

3.1 MKL 计算线程数

现象

服务中在使用 tensorflow / libtorch 等库做深度学习模型的前向推理运算时，若使用 CPU 模式，则它们的底层都会使用 MKL 库来做矩阵运算。

MKL库内置了一个逻辑，会根据运行环境的逻辑核数自动设置其内部 OpenMP 的计算线程数。若容器被分配了 16 核，实际宿主机 80 核，那么按 MKL 的原本设计思路，应该默认设置为 16 核，能达到最佳性能表现，实际上给设置为了 80 线程，导致计算性能反而下降。

当设置不当时，带来的影响：

• 压满 CPU 时，前向推理运算最大并发数比实际最佳性能要低很多
• 单次推理任务耗时比实际最佳性能长很多

由于不同类型的模型推理表现本来就存在很大的性能差异，且 CPU 推理并发性能也好，推理速度也好，确实比 GPU 模式都要差很多，所以很容易认为这就是 CPU 下的真实表现，而漏掉问题。

解法

在容器中运行时，不再让 MKL 通过自动检测的逻辑核数自动设置线程数，而是主动

• 通过 MKL_NUM_THREADS 环境变量设置 MKL 线程数
• 通过 mkl-set-num-threads 方法设置 MKL 线程数

参考文档： https://www.intel.com/content/www/us/en/docs/onemkl/developer-reference-c/2024-0/mkl-set-num-threads.html

3.2 ffmpeg 工作线程数

现象

ffmpeg 在做视频编码时，默认会自动根据运行环境的逻辑核数，设置 -thread 参数所指定的工作线程数。

当设置不当时，带来的影响：

• 慢速编码（输入帧较慢）时，ffmpeg进程内存占用过大。
• 正常速度编码时（25fps），CPU 占用偏大

由于 ffmpeg 编码输出视频时，输入数据规格、输出数据规格、各种选项参数非常繁杂，没有完全控制变量对比的情况下，一时间有点不好察觉到性能上的不对劲。

例如我这边遇到的一个场景下：

• 40逻辑核机器，容器分配16核，做4K视频的编码输出，每 1.3s 输入一帧数据。ffmpeg 进程工作线程数 122，内存占用 5.1G；修改 -threads 参数为 8 后，ffmpeg 进程工作线程数 22，内存占用 1.6G，编码速度不变。
• 80逻辑核机器，容器分配4核，做2K视频的编码输出，每秒输入 25 帧数据。ffmpeg 进程工作线程数 200+，CPU占用4.5 核；修改 -threads 参数为 4 后，ffmpeg 进程工作线程数 10，CPU占用 4 核，编码速度不变。

解法

手动根据实际情况设置工作线程数。

3.3 普遍性

除了上面列举的两个之外，很多软件会根据运行环境的逻辑核心数自动配置选项以优化多处理器下的性能，如 Nginx、Apache HTTP Server、Mysql、Golang 等。

它们利用系统的逻辑核数来对内部的一些选项进行默认配置，在容器中运行时往往不但达不到最优性，反而会起一些反作用，但是又不会影响程序的正常运行，性能也不会下降到不可用的地步，因而不太容易发现。

所以我推测这种情况具有一定普遍性，值得注意。

4. 容器中正确判断资源

可以使用 lxcfs 获取真实资源配置

此文不再赘述，参考此文：https://cloud.tencent.com/developer/article/1807333

通过 DMA 减少 CPU 拷贝次数

减少拷贝次数的原理主要是通过减少数据拷贝的次数，减少CPU的使用，提高数据传输的效率。在传统的数据传输过程中，数据通常需要在用户空间和内核空间之间进行至少两次的拷贝，这就会消耗大量的CPU资源。而零拷贝技术则是通过一些特殊的技术手段，尽可能地减少数据的拷贝次数，从而提高数据传输的效率。

DMA（Direct Memory Access）

直接内存访问是一种可以让某些硬件子系统（例如高速磁盘驱动器、图形卡）在不涉及CPU的情况下，直接访问内存的技术，从而实现零拷贝。

直接使用 CPU 的 IO

普通的 IO 方式，CPU 参与了全部 IO 的工作，并存在数据从内核态到用户态拷贝的过程。

CPU + DMA 的 IO

目前支持 DMA 的硬件包括：网卡、声卡、显卡、磁盘控制器等。

加上 DMA 设备后，CPU 参与的环节有所减少，但是整个 IO 过程扔存在内核态到用户态的拷贝过程

操作系统提供了一些方法，能进一步减少 CPU 参与的 IO 环节，让数据不再从内核缓冲区的内存页拷贝到用户缓冲区，减少数据拷贝的次数。

mmap

概念和适用场景

该函数可以将一个文件或者其它对象映射进内存，通过对这块内存的读写操作，程序可以实现对文件或者其它对象的读写操作。这样就避免了数据在用户空间和内核空间之间的拷贝，从而减少了一次从内核态到用户态的拷贝过程。

mmap适用的场景：

• 文件I/O性能要求较高的场景：mmap将文件映射到内存，可以避免数据在用户空间和内核空间之间的拷贝，从而提高文件I/O性能。
• 大文件处理：对于大文件，使用mmap可以避免一次性将整个文件读入内存，减少内存占用，提高处理效率。
• 多个进程共享内存的场景：mmap可以用于实现进程间通信（IPC），通过将一个文件映射到多个进程的内存空间，实现进程间数据共享。
• 内存数据库：mmap可以用于实现内存数据库，将数据库文件映射到内存，提高数据访问速度。

Redis、Nginx、Lucene、LevelDB、SQLite 等应用中在一些场景下使用了 mmap 来优化 IO 效率。

示例代码

下面是两段示例代码，来对比使用 mmap 和普通 IO 的性能差异。

构造测试数据，向磁盘中写入一个文件 test_data.txt，1GB 大小，每行 100~200 个字节的文本字符。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63

#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <unistd.h>

#define FILE_SIZE (1024 * 1024 * 1024)
#define MIN_LINE_SIZE 100
#define MAX_LINE_SIZE 200

char random_char() {
    int r = rand() % 62;
    if (r < 10) {
        return '0' + r;
    } else if (r < 36) {
        return 'A' + r - 10;
    } else {
        return 'a' + r - 36;
    }
}

int main() {
    int fd;
    size_t written_bytes = 0;
    srand(time(NULL));

    // 创建并打开文件
    fd = open("test_data.txt", O_CREAT | O_WRONLY | O_TRUNC, 0644);
    if (fd < 0) {
        perror("open error");
        exit(EXIT_FAILURE);
    }

    // 向文件写入数据，直到达到指定大小
    while (written_bytes < FILE_SIZE) {
        int line_size = MIN_LINE_SIZE + rand() % (MAX_LINE_SIZE - MIN_LINE_SIZE + 1);
        char buffer[MAX_LINE_SIZE + 1]; // 多出来的一个字节用于存放换行符

        for (int i = 0; i < line_size; ++i) {
            buffer[i] = random_char();
        }
        buffer[line_size] = '\n';

        ssize_t to_write = line_size + 1;
        ssize_t remaining = FILE_SIZE - written_bytes;
        if (to_write > remaining) {
            to_write = remaining;
        }

        ssize_t written = write(fd, buffer, to_write);
        if (written < 0) {
            perror("write error");
            exit(EXIT_FAILURE);
        }

        written_bytes += written;
    }

    // 关闭文件
    close(fd);

    return 0;
}

使用 mmap 读取文件并统计行数：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58

#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <unistd.h>
#include <time.h>
#include <string.h>

int main(int argc, char *argv[]) {
    if (argc != 2) {
        printf("Usage: %s <file>\n", argv[0]);
        return 1;
    }

    int fd = open(argv[1], O_RDONLY);
    if (fd < 0) {
        perror("open");
        return 1;
    }

    struct stat sb;
    if (fstat(fd, &sb) == -1) {
        perror("fstat");
        close(fd);
        return 1;
    }

    char *file_data = (char*)mmap(NULL, sb.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
    if (file_data == MAP_FAILED) {
        perror("mmap");
        close(fd);
        return 1;
    }

    clock_t start = clock();

    size_t line_count = 0;
    char *next = NULL;
    for (char *current = file_data; current - file_data < sb.st_size; current = next + 1) {
        next = (char*)memchr(current, '\n', sb.st_size - (current - file_data));
        if (next) {
            line_count++;
        } else {
            break;
        }
    }

    clock_t end = clock();

    printf("Line count: %zu\n", line_count);
    printf("Time taken: %lf ms\n", (double)(end - start) / CLOCKS_PER_SEC * 1000);

    munmap(file_data, sb.st_size);
    close(fd);

    return 0;
}

使用普通IO读取文件并统计行数：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <sys/stat.h>
#include <unistd.h>
#include <time.h>

int main(int argc, char *argv[]) {
    if (argc != 2) {
        printf("Usage: %s <file>\n", argv[0]);
        return 1;
    }

    FILE *fp = fopen(argv[1], "r");
    if (!fp) {
        perror("fopen");
        return 1;
    }

    clock_t start = clock();

    // 对文件数据进行处理，这里逐行读取文件内容并计算行数
    size_t line_count = 0;
    char *line = NULL;
    size_t line_length = 0;
    ssize_t read_length;
    while ((read_length = getline(&line, &line_length, fp)) != -1) {
        line_count++;
    }

    clock_t end = clock();

    printf("Line count: %zu\n", line_count);
    printf("Time taken: %lf ms\n", (double)(end - start) / CLOCKS_PER_SEC * 1000);

    free(line);
    fclose(fp);

    return 0;
}

测试结果：

sendfile

概念和适用场景

sendfile 相当于实现了 mmap + write 的功能。该函数可以在两个文件描述符之间直接传输数据，避免了数据在用户空间和内核空间之间的拷贝，从而减少了一次从内核态到用户态的拷贝。

sendfile适用的场景：

• 文件服务器：在文件服务器中，常需要将磁盘上的文件发送给客户端。使用sendfile方法可以直接将数据从磁盘传输到套接字，避免了多余的数据拷贝操作，提高了文件传输的性能。
• 代理服务器：代理服务器需要将客户端的请求转发给目标服务器，并将目标服务器的响应返回给客户端。使用sendfile方法可以在套接字之间直接传输数据，提高了代理服务器的性能。
• Web服务器：Web服务器需要将磁盘上的静态文件发送给客户端。使用sendfile方法可以提高文件传输的性能，降低服务器的资源消耗。
• 数据库服务器：数据库服务器需要将数据文件中的数据发送给客户端。使用sendfile方法可以提高数据传输的效率，降低服务器的资源消耗。

Nginx、Apache、Haproxy 等项目使用 sendfile 来提高文件传输性能。

示例代码

下面是两段测试代码，来测试 sendfile 和普通 IO 的性能差异，仍然使用上面创建的测试文件

使用 sendfile 读取文件并发送:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63

#include <arpa/inet.h>
#include <fcntl.h>
#include <netinet/in.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/sendfile.h>
#include <sys/socket.h>
#include <sys/stat.h>
#include <sys/time.h>
#include <unistd.h>

int main(int argc, char* argv[]) {
    if (argc != 2) {
        printf("Usage: %s <file>\n", argv[0]);
        return 1;
    }
    int server_fd, client_fd, file_fd;
    struct sockaddr_in server_addr, client_addr;
    socklen_t client_addr_len = sizeof(client_addr);
    struct stat file_stat;
    off_t offset = 0;
    ssize_t sent_bytes = 0;
    struct timeval start, end;

    // 创建TCP套接字
    server_fd = socket(AF_INET, SOCK_STREAM, 0);

    // 绑定地址和端口
    memset(&server_addr, 0, sizeof(server_addr));
    server_addr.sin_family = AF_INET;
    server_addr.sin_addr.s_addr = htonl(INADDR_ANY);
    server_addr.sin_port = htons(12345);
    bind(server_fd, (struct sockaddr *)&server_addr, sizeof(server_addr));

    // 监听连接
    listen(server_fd, 1);

    // 接受客户端连接
    client_fd = accept(server_fd, (struct sockaddr *)&client_addr, &client_addr_len);

    // 打开要发送的文件
    file_fd = open(argv[1], O_RDONLY);
    fstat(file_fd, &file_stat);

    // 使用sendfile发送文件
    gettimeofday(&start, NULL);
    while (((sent_bytes = sendfile(client_fd, file_fd, &offset, file_stat.st_size)) > 0) && (file_stat.st_size > 0)) {
        file_stat.st_size -= sent_bytes;
    }
    gettimeofday(&end, NULL);

    // 计算并输出耗时
    long elapsed_ms = (end.tv_sec - start.tv_sec) * 1000 + (end.tv_usec - start.tv_usec) / 1000;
    printf("sendfile: %ld ms\n", elapsed_ms);

    // 关闭文件和套接字
    close(file_fd);
    close(client_fd);
    close(server_fd);

    return 0;
}

使用普通 IO 读取文件并发送：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72

#include <arpa/inet.h>
#include <fcntl.h>
#include <netinet/in.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/socket.h>
#include <sys/stat.h>
#include <sys/time.h>
#include <unistd.h>

#define BUFFER_SIZE 8192

int main(int argc, char* argv[]) {
    if (argc != 2) {
        printf("Usage: %s <file>\n", argv[0]);
        return 1;
    }
    int server_fd, client_fd, file_fd;
    struct sockaddr_in server_addr, client_addr;
    socklen_t client_addr_len = sizeof(client_addr);
    struct stat file_stat;
    char buffer[BUFFER_SIZE];
    ssize_t read_bytes, sent_bytes;
    struct timeval start, end;

    // 创建TCP套接字
    server_fd = socket(AF_INET, SOCK_STREAM, 0);

    // 绑定地址和端口
    memset(&server_addr, 0, sizeof(server_addr));
    server_addr.sin_family = AF_INET;
    server_addr.sin_addr.s_addr = htonl(INADDR_ANY);
    server_addr.sin_port = htons(12345);
    bind(server_fd, (struct sockaddr *)&server_addr, sizeof(server_addr));

    // 监听连接
    listen(server_fd, 1);

    // 接受客户端连接
    client_fd = accept(server_fd, (struct sockaddr *)&client_addr, &client_addr_len);

    // 打开要发送的文件
    file_fd = open(argv[1], O_RDONLY);
    fstat(file_fd, &file_stat);

    // 使用普通I/O发送文件
    gettimeofday(&start, NULL);
    while ((read_bytes = read(file_fd, buffer, BUFFER_SIZE)) > 0) {
        sent_bytes = 0;
        while (sent_bytes < read_bytes) {
            ssize_t sent = send(client_fd, buffer + sent_bytes, read_bytes - sent_bytes, 0);
            if (sent < 0) {
                perror("send error");
                exit(EXIT_FAILURE);
            }
            sent_bytes += sent;
        }
    }
    gettimeofday(&end, NULL);

    // 计算并输出耗时
    long elapsed_ms = (end.tv_sec - start.tv_sec) * 1000 + (end.tv_usec - start.tv_usec) / 1000;
    printf("regular IO: %ld ms\n", elapsed_ms);

    // 关闭文件和套接字
    close(file_fd);
    close(client_fd);
    close(server_fd);

    return 0;
}

客户端：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

#include <arpa/inet.h>
#include <fcntl.h>
#include <netinet/in.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/socket.h>
#include <unistd.h>

#define BUFFER_SIZE 8192

int main() {
    int client_fd;
    struct sockaddr_in server_addr;
    char buffer[BUFFER_SIZE];
    ssize_t received_bytes;

    // 创建TCP套接字
    client_fd = socket(AF_INET, SOCK_STREAM, 0);

    // 连接到服务器
    memset(&server_addr, 0, sizeof(server_addr));
    server_addr.sin_family = AF_INET;
    server_addr.sin_addr.s_addr = inet_addr("127.0.0.1");
    server_addr.sin_port = htons(12345);
    connect(client_fd, (struct sockaddr *)&server_addr, sizeof(server_addr));

    // 接收文件
    while ((received_bytes = recv(client_fd, buffer, BUFFER_SIZE, 0)) > 0) {
        // 这里只是简单地将接收到的数据丢弃
        // 在实际使用中，你可能需要将数据写入文件或进行其他处理
    }

    // 关闭套接字
    close(client_fd);

    return 0;
}

测试结果：

1

sendfile: 221 ms
regular IO: 499 ms

splice

概念和适用场景

和 sendfile 一样，该函数可以将数据从一个文件描述符移动到另一个文件描述符，而不需要将数据从内核态拷贝到用户态，减少了一次拷贝过程。

和 sendfile 的差异

splice 和 sendfile 都是用于优化数据传输的 Linux 系统调用，它们之间有一定的联系，但也有一些区别。

功能上的差异

• sendfile 主要用于在两个文件描述符之间传输数据，特别是将文件数据发送到网络套接字。它可以在内核空间直接完成数据传输，避免了用户空间和内核空间之间的数据拷贝，从而提高了性能。然而，sendfile的一个限制是，它只能用于普通文件和套接字之间的数据传输。

• splice 是一个更通用的数据传输系统调用，它可以在任意类型的文件描述符之间传输数据，包括普通文件、设备文件、套接字等。 splice 的工作原理是将数据从一个文件描述符移动到另一个文件描述符，而不需要将数据拷贝到用户空间。这样，它可以在内核空间完成数据传输，提高性能。与 sendfile 相比， splice 的优势在于它可以处理更多类型的文件描述符，更加灵活。

数据传输方式差异：

• sendfile 在内核空间直接将数据从一个文件描述符传输到另一个文件描述符，不需要通过用户空间的缓冲区。sendfile适用于将磁盘上的文件发送到网络套接字的场景，例如文件服务器、Web服务器等。

• splice 通过管道（pipe）在文件描述符之间传输数据。首先，它将数据从一个文件描述符移动到管道，然后将数据从管道移动到另一个文件描述符。这样，数据在内核空间完成传输，避免了用户空间和内核空间之间的数据拷贝。splice适用于各种类型的文件描述符之间的数据传输，例如设备文件、套接字等。

示例代码

使用 splice 读取文件并发送

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67