https://juejin.cn/post/7104436526494253087#heading-7
memo
const MyComponent = React.memo(function MyComponent(props) {
/* 使用 props 渲染 */
});
React.memo 为高阶组件。 如果你的组件在相同 props 的情况下渲染相同的结果，那么你可以通过将其包装在 React.memo 中调用，以此通过记忆组件渲染结果的方式来提高组件的性能表现。这意味着在这种情况下，React 将跳过渲染组件的操作并直接复用最近一次渲染的结果。
useMemo
const memoizedValue = useMemo(() => computeExpensiveValue(a, b), [a, b]);
把待执行函数和依赖项数组作为参数传入 useMemo，返回一个 memoized值。它仅会在某个依赖项改变时才重新计算 memoized 值。这种优化有助于避免在每次渲染时都进行高开销的计算。
如果没有提供依赖项数组，useMemo 在每次渲染时都会计算新的值。
useCallback
const memoizedCallback = useCallback(
() => {
doSomething(a, b);
},
[a, b],
);
把回调函数及依赖项数组作为参数传入 useCallback，它将返回该回调函数的 memoized 版本，该回调函数仅在某个依赖项改变时才会更新。
当你把回调函数传递给经过优化的并使用引用相等性去避免非必要渲染（例如 shouldComponentUpdate）的子组件时，它将非常有用。
useCallback(fn, deps) 相当于 useMemo(() => fn, deps)。
为什么React不直接默认实现缓存呢
看起来啊，这两个 Hooks 确实是可以通过避免非必要渲染，减少我们页面的重绘，从而提高性能
网上有很多 React 的教程，其中提到性能优化时，也都会告诉你，用 React 开发者工具检测什么组件出现了太多次的渲染，以及是什么导致的，那就在那上面包裹一个 useMemo
但有没有想过一个问题：这种特性，为什么 React 不直接在所有相关的东西里面都内部 实现呢？或者说为什么不把他们搞成 default 呢？
不要把它当做语义上的保证
官方文档说：
你可以把useMemo作为性能优化的手段，但不要把它当做与以上的保证。将来，React可能会选择“遗忘”以前的一些memoized值，并在下次渲染时重新计算它们，比如为离屏组件释放内存。先编写在没有useMemo的情况下也可以执行的代码--之后再在你的代码中添加useMemo，以达到优化性能的目的。
为什么可能会更糟糕
比如现在有一个方法
const edit = id => {
setList(list => list.filter(idx => idx !== id))
}
我们“常规”地用 useCallback 优化一下
const edit = useCallback(id => {
setList(list => list.filter(idx => idx !== id))
}, [])
每行代码的成本
实际上，上面优化后的代码实际上就相当于这样：
const edit = id => {
setList(list => list.filter(idx => idx !== id))
}
const memorizedEdit = useCallback(edit, []) // 多了这一行
可以看作是多了一些东西：
一个数组：deps
调用 useCallback
定义多一个函数，Javascript 在每次渲染的时候都会给函数定义分配内存，并且 useCallback 这个方法会让其需要更多的内存分配
啊，当然里面这个 deps 数组可以用 useMemo 将其 memorize ，但是~ 这会导致到处都是useMemo，以及 useMemo 也会像上面 useCallback 一样带来一些新的东西...
deps空间成本以及其带来的时间成本
前面说到了使用这些肯定会带有dependency list，它是一个数组，当然有空间成本。除此之外，每次render时自然还要将数组中的每一个值进行一个比对的行为，检查是否有新的变化 遍历数组，这也是一个时间复杂度为O(N)的过程~
成本和收获相近时
实际上，哪怕成本和收获相近，那不就是他们其实啥也没干？ 但你的代码大小、复杂度等等却是实实在在的增加了~ 甚至会进一步导致更容易写出糟糕的代码
日常开发的“性能优化”
现在大部分日常项目中的“计算”，对于现代浏览器、电脑硬件等，都是非常微乎其微的。实际上，你可能并不需要这些“优化”。所以我建议大部分时候，先让能达成最终需求效果的代码跑成功了，遇到性能瓶颈了再添加这些优化的手段
小结
也就是说，性能优化并不是 完全免费 的，这是绝对有成本的，甚至有时带来的好处不能抵消成本。所以你需要做的是负责任地进行优化
网友评论