在移动浏览器中反应性能 [英] React performance in mobile browser

问题描述

我有一个组件(表)，其中包含许多行数据编辑，掩码为 contenteditable 形式，可以选择所有字段并同时更改所有行时间.

I have a component (table) that contains many lines with data editing in them, with masks in the form of contenteditable, it is possible to select all fields and change all the lines at the same time.

在桌面上它运行得非常快，但在 iPhone 6 上我有不真实的滞后，Safari 每次操作都会挂起 20 秒.

On desktop it works pretty fast, but on iPhone 6 I have unreal lagging, with Safari hanging for 20 seconds for each action.

我完成了提高 React 性能的建议:防止协调、纯组件等......

I completed the recommendations to improve performance from React: prevent reconciliation, pure components, etc ...

有没有办法提高性能?我是否有必要考虑在移动设备上进行功能更改以提高性能?

Are there ways to improve performance? Is it necessary for me to ponder a functionality change on a mobile device, in favor of performance?

推荐答案

除了上述答案之外，您还应该使用 react-perf 模块来准确验证是否有任何更改实际上带来了性能提升.

Adding to above answer, you should use react-perf module to exactly validate if any change actually made a performance gain.

https://github.com/crysislinux/chrome-react-perf

使用此扩展程序可以准确查看页面上每个组件实际呈现的次数，当您进行有问题/缓慢的用户交互时

use this extension to exactly see how many times, each component on your page actually rendered, when you did your problematic/slow user interaction

1. 尝试减少数量.每个组件的渲染.也减少没有.在每次此类交互上呈现的组件数量.
2. 尽量减少每个组件花费的时间.您可以按时间排序并专注于最昂贵的组件.首先避免在层次结构中渲染更高的组件.要查找组件呈现背后的确切原因，请使用以下方法.

暂时放置 componentWillUpdate 生命周期挂钩，并区分上一个和下一个道具/状态.有了这个，您将获得渲染背后的确切道具罪魁祸首.不必要的道具更改可能在以下情况下:

Put componentWillUpdate lifecycle hook, temporarily, and diff previous and next props/states. With this you would get the exact prop culprit behind a rendering. Unneccessary prop change might be in following scenarios:

1. 当 prop 只是一个由于绑定"用法或箭头函数用法而发生变化的函数时，它每次都会更改函数引用，因此每次都会导致新的渲染.
2. 可能有一个 prop 被初始化为 new Object() 或 {} 符号，每次都被认为是新对象，因此是新的渲染.这可以通过 const READ_ONLY_OBJECT = {} 并在每次变量需要初始化时使用 READ_ONLY_OBJECT 来避免.
3. 您可能会不必要地改变对象类型道具并在 componentWillRecieveProps 中进行差异化.

1. When prop is just a function which is changing because of 'bind' usage or arrow-function usage, which changes the function reference everytime, and with that, causing new renders, everytime.
2. There might be a prop being initialised with new Object() or {} notation, which is considered new object everytime and hence new rendering. This can be avoided by a const READ_ONLY_OBJECT = {} and using READ_ONLY_OBJECT everytime a variable needs initialization.
3. You might be unnecessarily mutating object-type props and doing diffs in componentWillRecieveProps.

我们不想要渲染的原因可能有很多，但它发生的原因是 react 的工作方式.只要看到道具不会发生不必要的变化.此外，不要进行不必要的 componentWillRecieveProps/shouldCompoentUpdate 检查，因为它会对性能产生负面影响.此外，在使用这些时，请尽可能在层次结构中使用它们.

There can be more reasons to where we dont want a render but it happens because of the ways react works. Just see that props dont change unnecessarily. Also, dont put unnecssary componentWillRecieveProps/shouldCompoentUpdate checks as it can impact performance negatively. Also when using these, use these as higher in heirarchy as possible.

一些使用技巧

1. 尽量避免使用在每次渲染时运行的 React 生命周期钩子.
2. 尝试减少在每次渲染时运行的任何脚本.
3. 使用componentWillReieveProps，但前提是你获得了，否则第1点也可以减少收益.此外，经常使用它会导致不可维护的代码.在进行与优化相关的更改之前，始终使用 react-perf 工具验证收益.
4. 在 chrome-dev-tools 中使用限制来创建慢速设备环境，使用 javascript 分析来查看哪些 javascript 方法花费的时间最多.
5. 尝试使用 redux 和 react 来管理状态.Redux 还为连接的组件实现了 componentWillReieveProps 东西.因此，使用 redux 会有所帮助.
6. 使用 redux 时，请使用适当的批处理策略.您还可以在 redux 中使用 批处理中间件.

7. 同样，在 react 中尝试以批处理方式执行事件，以减少在 react 渲染和差异算法上花费的时间.尝试在 react 中使用 setState 或在 redux 中使用 action 以减少 react 脚本时间.

1. try to avoid using react lifecycle hooks which run on each render.
2. try reducing any scripts runing on every render.
3. use componentWillReieveProps, but only if you gain, else point 1 can reduce gains also. Also, using this often can lead to non-maintainable code. Always validate the gains with react-perf tools, before making changes related to optimizations.
4. use throttling in chrome-dev-tools to create slow device enviroments, use javascript profiling to see which javascript methods took most time.
5. Try using redux with react, to manage state. Redux also has componentWillReieveProps thing implemented for connected components. So, using redux will help.
6. When using redux use an appropriate batching stategy. You can also use batch middleware in redux.

7. Also, similarly, in react try to do events in batched manner so as to reduce amount of time spent in react's renderings and diffing algorithms. Try clubing setStates in react or actions in redux to reduce react scripting time.

在实施输入控制时始终使用适当的节流/去抖动技术，以获得即时响应.如果您的业务逻辑允许，您还可以使用不受控制的组件来获得即时响应.想法是在用户以任何方式键入或与您的页面交互时不要运行任何 javascript，否则他会注意到设备中的卡顿，计算能力特别差.

Always use appropriate throttling/debouncing techniques while implementing input controls, to get immediate response. You can also use uncontrolled components to have immediate response, if your business logic allows. Idea is to not to run any javascript when user is typing or interacting with your page in any way, else he would notice the jank in devices particularly bad in computing power.

您的操作处理程序不应冗长.如果冗长，请尝试分块、异步、使用 redux-actions 或仅使用 promise.

Your action handlers should not be lengthy. If lengthy, try to do them in chunks, asynchronously, with redux-actions or with just promises.

这个列表还有更多，但问题是，作为框架反应很容易开始工作，最初，但迟早，任何中型反应应用程序都会遇到这些性能问题，因为反应的差异和渲染逻辑在坏设备上会导致很多性能损失，一旦应用程序的大小增长，唯一的选择就是尽快将反应性能工具也加入到构建过程中.这将让您验证和衡量您的改进.

There is more to this list, but the problem is, react as a framewaork is pretty easy to get to work, initially, but sooner or later, any medium sized react app will run into these performance problems, as react's diffing and rendering logic incurs a lot of performance penalties in bad devices, as soon as app grows in size, only option is to get react-performance tools, also, into the build process, asap. This will let you validate and measure your improvements.

这篇关于在移动浏览器中反应性能的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！