学react相关时间不长，有一个还不明白。
react组件的ui是state驱动的，大致流程是:
setState或props改动 --> 生成虚拟DOM --> DOM diff --> ui render
如果state改动很小，那么也要走这个流程。
如果在一个相对复杂的网页中，仅仅为了改其中一个很小的标识(如改一个图标或文本), 就要: 生成虚拟DOM并执行DOM Diff. 这个在效率上会不会有问题？？
redux更进一步，将react组件的状态管理起来，使用store.
一个组件树共用一个store. 相当于用store驱动UI, 这样的话，如果action导致了store有很小的变化，也要执行大量reducers内部逻辑，虽然最终导致的dom操作很少.
DOM diff算法确实减小了真实的DOM操作，提升效率. 问题是： state到生成虚拟dom，虚拟dom diff这两步足够高效吗？ 如果频率调用setState,或触发redux的action, 会不会导致cpu占用过大?
基于还有这些问题, 我现在的做法是:
避免过多调用setState, 在componentDidMount中使用zepto.js.
将app分成多个子app, 每个子app对应一个redux实例.
但是这样的话，感觉react与redux的特长没有充分发挥。
大家有什么可以教我，谢谢！
如果在一个相对复杂的网页中，仅仅为了改其中一个很小的标识(如改一个图标或文本), 就要: 生成虚拟DOM并执行DOM Diff. 这个在效率上会不会有问题？？
不会。
一个组件树共用一个store. 相当于用store驱动UI, 这样的话，如果action导致了store有很小的变化，也要执行大量reducers内部逻辑，虽然最终导致的dom操作很少.
可以使用immutable.js，Reselect，PureRenderMixin等优化。
state到生成虚拟dom，虚拟dom diff这两步足够高效吗？ 如果频率调用setState,或触发redux的action, 会不会导致cpu占用过大?
足够高，不会。
避免过多调用setState, 在componentDidMount中使用zepto.js.将app分成多个子app, 每个子app对应一个redux实例.
不要这么做。