各位下午好！欢迎来到这场关于“如何在树莓派 Zero 2 上优雅地运行 React 18”的讲座。
咱们先别急着敲代码，咱们得先聊聊这个“尴尬”的现实。想象一下，你刚拿到一个新项目：老板想在一个工业控制终端上跑一个炫酷的实时监控仪表盘。这个终端的配置大概是这样：一颗 1GHz 的单核处理器，512MB 的内存，运行的是精简版的 Linux。
而你的技术栈是：React 18, TypeScript, Tailwind CSS, 还加上了一大堆图表库。
这就像是你想开着法拉利去泥地里玩越野，还非要开到最高时速。你还没出发，发动机可能就已经冒烟了。React 虽然是个好孩子，但它默认配置下是个“胖子”。它的虚拟 DOM 机制、它的并发特性、它的庞大的生态系统，对于这种低性能硬件来说，简直就是一场灾难。
所以，今天我们要干的事儿，就是给 React 来一场“外科手术式的减肥”，同时还要教会它“深呼吸”，控制它的渲染频率。
准备好了吗？咱们开始。
第一部分：打包器的整容手术——从 Babel 到 Rspack
首先，我们要解决的是“起步难”的问题。React 的编译过程通常是性能杀手。
1. Babel 是个慢吞吞的翻译员
还记得以前我们怎么写 React 代码吗？.jsx 文件扔给 Babel，Babel 把它转成 .js，然后扔给 Webpack。Babel 是用 JavaScript 写的，它是解释型语言，处理几万行代码时，它的速度慢得就像蜗牛在爬。
在低性能设备上，构建速度慢一点没关系，运行速度慢才是要命的。
解决方案：拥抱 Rust
咱们得用 Rust 写的工具。Rust 的编译器编译速度极快，而且内存占用极低。
- Swc (Speedy Web Compiler)：这是 Babel 的 Rust 替代品，转换速度是 Babel 的 20 倍。
- Rspack：这是字节跳动开源的打包工具，基于 Rust，它的兼容性比 Webpack 好，速度是 Webpack 的 10 倍以上。
实战代码：配置 Rspack
别再用 Webpack 了，咱们换 Rspack，顺便把 Babel 换成 Swc。
// rspack.config.js
const rspack = require("@rspack/core");
module.exports = {
entry: "./src/index.js",
output: {
path: path.resolve(__dirname, "dist"),
filename: "bundle.js",
},
module: {
rules: [
{
test: /.jsx?$/,
use: {
loader: "@rspack/plugin-rust-jsx",
options: {
// 这里你可以配置 React 的版本和 JSX 转换选项
runtime: "automatic",
},
},
},
{
test: /.tsx?$/,
use: [
{
loader: "swc-loader",
options: {
jsc: {
parser: {
syntax: "typescript",
tsx: true,
},
transform: {
react: {
runtime: "automatic",
},
},
},
},
},
],
},
],
},
// 极度重要的优化配置
optimization: {
minimize: true,
minimizer: [
new TerserPlugin({
terserOptions: {
compress: {
drop_console: true, // 生产环境去掉 console
drop_debugger: true,
},
},
}),
],
},
};你看，这配置简单多了，而且跑得飞快。咱们把 drop_console 打开，这能帮你砍掉大概 5%-10% 的体积，而且能防止你那些烦人的 console.log 在嵌入式设备上疯狂刷屏，吓坏用户。
2. 代码分割与懒加载
嵌入式设备的内存是有限的。你不能把所有的图表组件、所有的工具函数都打包进一个 bundle.js 里。那文件可能会达到 5MB，你的终端可能连解压都解压不完。
解决方案：按需加载
React 的 React.lazy 和 Suspense 是个好东西，但要注意，Suspense 在某些旧浏览器或者特定场景下会有兼容性问题。更稳妥的做法是手动动态导入。
实战代码：懒加载图表组件
假设你有三个图表组件：CPU 监控、内存监控、温度监控。
// 普通的加载方式（不要这样！）
import CPUChart from './components/CPUChart';
import MemChart from './components/MemChart';
import TempChart from './components/TempChart';
function Dashboard() {
return (
<div>
<CPUChart />
<MemChart />
<TempChart />
</div>
);
}
// 嵌入式优化方式（推荐）
function Dashboard() {
const [activeTab, setActiveTab] = useState('cpu');
// 动态导入，只有在用户点击 Tab 时才会下载对应的 JS 文件
const ActiveChart = React.lazy(() => import(`./components/${activeTab}Chart`));
return (
<div>
<button onClick={() => setActiveTab('cpu')}>CPU</button>
<button onClick={() => setActiveTab('mem')}>Memory</button>
<Suspense fallback={<div>Loading...</div>}>
<ActiveChart />
</Suspense>
</div>
);
}这样，用户第一次打开页面时，只需要加载主逻辑和 CPU 监控的代码。当用户切换到 Memory 监控时，才会去下载那个几百 KB 的 JS 文件。这就像你出门旅游，不是把整个衣柜都背在身上，而是到了目的地再换衣服。
第二部分：渲染频率控制——给屏幕“深呼吸”
现在，假设你的应用已经打包好了，体积也控制住了。但是，当你打开仪表盘，数据在疯狂跳动。
React 默认是 60fps 的渲染频率。也就是说，每秒 60 次。对于普通的网页，这没问题。但对于低性能设备，这就像你每秒钟都要重新粉刷一次房子。如果你每秒重绘 60 次图表，CPU 就得忙着计算差异、更新 DOM、重排、重绘。结果就是风扇狂转，手机发烫，电量耗尽。
核心原则：按需渲染
嵌入式仪表盘不需要 60fps。它只需要在数据变化时更新即可。如果数据是每秒变化一次，你每秒重绘一次就行了。如果数据是每 100ms 变化一次，你每 100ms 重绘一次就够了。
1. 避免无意义的重渲染
React 的核心是 shouldComponentUpdate (类组件) 和 React.memo (函数组件)。这是性能优化的第一道防线。
但是！注意了，这是一个陷阱。不要滥用 React.memo 和 useMemo。
React.memo 会进行浅比较，这本身就有性能开销。如果你在一个组件里用它包裹了 50 个子组件，而且每个子组件都变了，那这个比较的开销可能比重绘还大。
实战代码：精准的 React.memo
只对那些数据量大或者计算复杂的组件使用记忆化。
// 普通按钮，不需要 memo
const Button = ({ onClick, label }) => (
<button onClick={onClick}>{label}</button>
);
// 耗能大户：复杂图表
const HeavyChart = React.memo(({ data }) => {
console.log("Chart rendering..."); // 只有 props 变了才会打印
// 这里画图逻辑很复杂
return <canvas>...</canvas>;
});2. 节流渲染
这是嵌入式开发的大杀器。我们不需要每帧都渲染。我们可以使用 requestAnimationFrame 或者自定义的节流函数，把渲染频率限制在 10fps 甚至更低。
实战代码：自定义 Hook 节流渲染
import { useEffect, useRef, useState } from 'react';
// 一个简单的节流 Hook
function useThrottleRender(renderInterval = 1000) {
const lastRenderTime = useRef(0);
const [, forceUpdate] = useState({});
return (data) => {
const now = Date.now();
if (now - lastRenderTime.current >= renderInterval) {
lastRenderTime.current = now;
forceUpdate({});
}
// 注意：这里我们只更新状态，不直接渲染
// 实际渲染由 React 的状态更新周期控制
};
}
// 使用示例
function DataMonitor() {
const [sensorData, setSensorData] = useState(null);
const throttleRender = useThrottleRender(500); // 限制在 500ms 更新一次
useEffect(() => {
const interval = setInterval(() => {
// 模拟获取传感器数据
const newData = { value: Math.random() * 100 };
// 更新状态（触发 React 的批处理）
setSensorData(newData);
// 调用我们的节流渲染函数
throttleRender(newData);
}, 100); // 数据源每 100ms 变化一次
return () => clearInterval(interval);
}, [throttleRender]);
return (
<div>
<h1>Current Value: {sensorData?.value.toFixed(2)}</h1>
{/* 这里我们没有直接用 throttleRender，而是通过 setSensorData 触发 */}
</div>
);
}上面的代码演示了一个概念：数据流与渲染流的分离。数据流可以是高频的（比如每秒 20 次网络请求），但渲染流必须是低频的（比如每秒 2 次）。这样可以极大地降低 CPU 负载。
第三部分：DOM 的重负——用 Canvas 替代 DOM
这是最残酷的真相：在嵌入式设备上，操作 DOM 是昂贵的。
React 的虚拟 DOM 虽然很强大，但它最终还是要把指令发给浏览器去操作真实的 DOM 节点。如果你有一个包含 5000 个数据点的折线图，React 试图用虚拟 DOM 去管理这 5000 个 <div>，浏览器会累死。
解决方案：Canvas
对于图表和可视化数据，直接使用 HTML5 Canvas API，然后由 React 只负责“调用”画图函数，而不是“管理”画图元素。Canvas 是离屏渲染，性能极高。
实战代码：React 封装的轻量级 Canvas 组件
我们写一个组件，它只接收数据，不进行 Diff 计算。
import React, { useRef, useEffect, memo } from 'react';
const LineChart = memo(({ data, color = '#00ff00' }) => {
const canvasRef = useRef(null);
useEffect(() => {
const canvas = canvasRef.current;
const ctx = canvas.getContext('2d');
const width = canvas.width;
const height = canvas.height;
// 清空画布
ctx.clearRect(0, 0, width, height);
if (!data || data.length === 0) return;
// 计算比例尺
const maxVal = Math.max(...data);
const minVal = Math.min(...data);
const range = maxVal - minVal || 1;
// 绘制逻辑（纯数学计算，不涉及 DOM 操作）
ctx.beginPath();
ctx.strokeStyle = color;
ctx.lineWidth = 2;
const stepX = width / (data.length - 1);
data.forEach((val, index) => {
const x = index * stepX;
// Y 轴翻转，因为 Canvas 坐标系原点在左上角
const y = height - ((val - minVal) / range) * height;
if (index === 0) {
ctx.moveTo(x, y);
} else {
ctx.lineTo(x, y);
}
});
ctx.stroke();
}, [data, color]); // 只有 data 或 color 变了才重绘
return <canvas ref={canvasRef} width={300} height={150} />;
});
export default LineChart;看到了吗？这个组件没有任何 useMemo，没有任何 useCallback，甚至没有 React.memo（虽然我加了 memo）。它就像一个原始人，直接把笔（Canvas API）扔在纸上画画。它没有任何开销。
如果你的图表里有动画，不要用 CSS 动画，要在 requestAnimationFrame 循环里手动计算 Canvas 的坐标。CSS 动画依然在操作 DOM，依然慢。
第四部分：内存管理——别让冰箱满了
嵌入式设备的内存（RAM）通常是 512MB 甚至更少。如果你的应用占用了 100MB，那你就只剩 400MB 给操作系统和硬件驱动了。这时候，内存稍微泄漏一点，系统就会崩溃。
1. 避免闭包陷阱
在 React 中，我们经常使用 useEffect 来处理事件监听。如果你在 useEffect 里定义了一个函数，并且这个函数引用了组件的 state，那么这个闭包会一直存在，直到组件卸载。
如果这个函数又被保存到了全局变量或者父组件的 state 里，那这个闭包就“泄漏”了，state 也无法被垃圾回收。
实战代码：正确的清理
function SensorComponent() {
const [value, setValue] = useState(0);
useEffect(() => {
// 错误示例：这会创建一个永远无法释放的闭包
// const handleData = () => {
// setValue(value + 1); // value 永远是初始化时的 0
// };
// 正确示例：依赖项数组要包含所有用到的变量
const handleData = () => {
setValue(prev => prev + 1);
};
const interval = setInterval(handleData, 1000);
// 必须返回清理函数！
return () => {
clearInterval(interval);
// handleData 会被垃圾回收，因为 useEffect 已经结束了
};
}, []); // 依赖项为空，表示只在挂载时运行一次
}2. 手动清理定时器
在嵌入式应用中，定时器是内存杀手。如果你在组件里开了 10 个 setInterval，然后忘了关，那你的应用每秒都在跑死循环，内存占用会像坐火箭一样飙升。
最佳实践： 在组件卸载时，务必清理所有的定时器、WebSocket 连接、监听器。
第五部分：CSS 的陷阱——内联样式是王道
CSS-in-JS 库（如 Styled-components, Emotion）虽然写起来爽，但它们会在运行时动态生成 CSS 规则。对于低性能设备，这简直是灾难。每次渲染都要去拼接字符串，生成类名，更新 DOM。
解决方案：CSS Modules 或 纯内联样式
React 18 支持 style 属性接收对象。
// 不要用 styled-components
// import styled from 'styled-components';
// const Container = styled.div`...`;
// 用这个
const DashboardContainer = {
display: 'flex',
flexDirection: 'column',
backgroundColor: '#1a1a1a',
color: '#ffffff',
padding: '10px',
fontFamily: 'monospace',
};
function App() {
return <div style={DashboardContainer}>Hello World</div>;
}内联样式不需要额外的 HTTP 请求，不需要解析 CSS，浏览器渲染引擎对内联样式的处理比 <style> 标签里的 CSS 要快一些（虽然差距在变大，但在嵌入式设备上，每一点优化都很重要）。
第六部分：Web Workers——把计算丢到后台去
如果你的仪表盘需要处理大量的数据，比如从传感器读取 1000 个点的数据并进行 FFT（快速傅里叶变换）计算，千万不要在主线程（UI 线程）做这个事。
如果你在主线程做数学运算，UI 就会卡死，按钮点不动，屏幕会冻结。
解决方案：Web Workers
Web Worker 允许你在后台线程运行代码。React 无法直接在 Worker 里渲染 UI（除非用极其复杂的技巧），但 Worker 可以计算数据，然后把计算好的结果传回主线程。
实战代码：Worker 消息传递
1. 创建 Worker 文件 (worker.js)
// worker.js
self.onmessage = function(e) {
const data = e.data;
// 模拟一个耗时的计算任务
let result = 0;
for (let i = 0; i < data.length; i++) {
result += Math.sqrt(data[i]);
}
// 把结果传回主线程
self.postMessage(result);
};2. 在 React 中使用
function DataProcessor() {
const [result, setResult] = useState(null);
useEffect(() => {
const worker = new Worker(new URL('./worker.js', import.meta.url));
worker.onmessage = (e) => {
setResult(e.data);
};
// 发送数据给 Worker
const dataToSend = Array.from({ length: 10000 }, () => Math.random() * 100);
worker.postMessage(dataToSend);
// 组件卸载时关闭 Worker
return () => {
worker.terminate();
};
}, []);
return (
<div>
<p>Processing...</p>
<h2>Result: {result}</h2>
</div>
);
}注意：Worker 的代码不能直接使用 React 的 API。它必须是一个纯 JS 文件。这增加了代码的复杂度，但在嵌入式设备上，这是保证 UI 流畅的唯一办法。
第七部分：终极优化——Tree Shaking 与 Scope Hoisting
我们在第一部分提到了打包，现在我们来深挖一下。
1. Tree Shaking（摇树）
Webpack/Rspack 默认会做 Tree Shaking，但你需要确保你的代码是“纯函数”的。
- 错误示例：
import { myUtil } from './utils';然后myUtil.doSomething();。Webpack 无法确定myUtil是否被使用，它会把整个文件打包进去。 - 正确示例：
import { doSomething } from './utils';然后doSomething();。Webpack 就知道myUtil没用，直接把它摇掉。
2. Scope Hoisting（作用域提升）
这能减少函数的声明和作用域链的查找。
在 Rspack 配置里，这通常是默认开启的，但你可以确保你的配置里没有禁用它。
module.exports = {
// ... 其他配置
optimization: {
concatenateModules: true, // 启用 Scope Hoisting
},
};第八部分：实战案例——一个“呼吸”的仪表盘
好了，理论讲得够多了，咱们来综合运用一下。
我们要做一个温度监控仪表盘。数据每秒更新一次。硬件性能一般。
代码结构：
- 主组件：负责布局，不负责渲染图表。
- 数据层：使用 Web Worker 获取数据。
- 渲染层：使用 Canvas 绘制，使用
useThrottleRender限制渲染频率。
// App.js
import React, { useState, useEffect, useCallback, memo } from 'react';
import LineChart from './components/LineChart';
// 1. 定义数据 Worker (在浏览器中运行)
const workerCode = `
self.onmessage = function(e) {
const { startTime } = e.data;
// 模拟从传感器获取数据
const now = Date.now();
const temp = 20 + Math.sin((now - startTime) / 1000) * 5 + Math.random() * 2;
self.postMessage({ temp, time: now });
};
`;
// 2. 创建 Worker Blob URL
const workerBlob = new Blob([workerCode], { type: 'application/javascript' });
const workerUrl = URL.createObjectURL(workerBlob);
// 3. 节流 Hook
const useThrottle = (fn, delay) => {
const lastRun = useRef(0);
return (...args) => {
const now = Date.now();
if (now - lastRun.current >= delay) {
fn(...args);
lastRun.current = now;
}
};
};
function App() {
const [history, setHistory] = useState([]);
const [worker, setWorker] = useState(null);
// 初始化 Worker
useEffect(() => {
const w = new Worker(workerUrl);
w.postMessage({ startTime: Date.now() });
w.onmessage = (e) => {
setHistory(prev => {
// 只保留最近 100 个点，防止内存爆炸
const next = [...prev, e.data];
if (next.length > 100) next.shift();
return next;
});
};
setWorker(w);
return () => w.terminate();
}, []);
// 限制渲染频率：每 500ms 更新一次 UI
const throttledSetHistory = useThrottle((data) => {
setHistory(prev => {
const next = [...prev, data];
if (next.length > 100) next.shift();
return next;
});
}, 500);
// 监听 Worker 数据并节流
useEffect(() => {
if (!worker) return;
const handler = (e) => throttledSetHistory(e.data);
worker.onmessage = handler;
return () => worker.removeEventListener('message', handler);
}, [worker, throttledSetHistory]);
return (
<div style={{ padding: '20px', fontFamily: 'monospace' }}>
<h1>嵌入式 React 仪表盘</h1>
<div style={{ border: '1px solid #ccc', padding: '10px' }}>
<LineChart data={history} />
</div>
<p>渲染频率限制：500ms</p>
</div>
);
}
export default App;在这个例子中：
- Worker 处理了数据的生成，不阻塞主线程。
- useThrottle 限制了数据进入 React 状态树的频率。
- LineChart 使用 Canvas 进行绘制，没有 DOM 操作。
- History 数组被限制在 100 个长度，防止内存溢出。
总结与最后的话
好了，朋友们，今天的讲座接近尾声。
我们讨论了如何把 React 这个“大胖子”塞进“小衣服”里。我们用了 Rspack 和 Swc 来给它瘦身；我们用了懒加载和 Tree Shaking 来剔除多余的脂肪；我们用了 Canvas 和 Web Workers 来减轻心脏的负担；我们用了 useThrottle 来控制它的呼吸频率。
记住，性能优化没有银弹。在嵌入式设备上，每一行代码、每一个 DOM 节点、每一个定时器都是宝贵的资源。
不要盲目地使用 React.memo 和 useMemo，它们有时候比带来的性能提升还要重。要像外科医生一样精准地找到性能瓶颈。
如果你在开发嵌入式应用时感到迷茫，就去看看 Chrome DevTools 的 Performance 面板，或者用 react-devtools 看看你的组件渲染了多久。数据不会撒谎。
最后，祝你的 React 应用在低性能硬件上跑得飞快，风扇不转，电量持久，老板满意！
谢谢大家！