React移动Web极致优化
最近一个季度，我们都在为手Q家校群做重构优化，将原有那套问题不断的框架换掉。经过一些推敲，决定使用react进行重构。选择react，其实也主要是由于它具有下面的3大特性。
React的特性arnonce,writeanywhere
学习React的好处就是，学了1遍以后，能够写web,node直出，和native，能够适应各种纷纷复杂的业务。需要轻量快捷的，直接可以用Reactjs；需要提升首屏时间的，可以结合ReactServerRender；需要更好的性能的，可以上ReactNative。
但是，这其实暗示学习的曲线非常峻峭。单单是Webpack+React+Redux就已够一个入门者够戗，更何况还要统筹直出和客户端。不是常人能hold住所有端。
rtualDom
VirtualDom（下称vd）算是React的一个重大的特点，由于Facebook宣称由于vd的帮助，React能够到达很好的性能。是的，Facebook说的没错，但只说了一半，它说漏的一半是：“除非你能正确的采取一系列优化手段”。
3.组件化
另一个被大家所推重的React优势在于，它能令到你的代码组织更清晰，保护起来更容易。我们在写的时候也有同感，但那是直到我们踩了一些坑，并且渐渐熟习React+Redux所推重的那套代码组织规范以后。
那末...
上面的描写不免有些先扬后抑的感觉，那是由于常常作为React的刚入门者，都会像我们初入的时候一样，对React满怀希望，指意它帮我们做好一切，但随着了解的深入，发现需要做一些额外的事情来到达我们的期待。
对React的期待初学者对React可能满怀期待，觉得React可能完爆其它一切框架，乃至不切实际地认为React可能连原生的渲染都能完爆——对框架的狂热确切会出现这样的不切实际的期待。让我们来看看React的官方是怎样说的。React官方文档在AdvancedPerformanec这一节，这样写道：
OneofthefirstquestionspeopleaskwhenconsideringReactforaprojectiswhethertheirapplicationwillbeasfastandresponsiveasanequivalentnon-Reactversion.
明显React自己也其实只是想尽量到达跟非React版本相若的性能。React在减少重复渲染方面确切是有一套独特的处理办法，那就是vd，但显示在首次渲染的时候React绝无可能超出原生的速度，或一定能将其它的框架比下去。因此，我们在做优化的时候，可的期待的东西有：
首屏时间可能会比较原生的慢一些，但可以尝试用ReactServerRender(又称Isomorphic)去提高效率
用户进行交互的时候，有可能会比原生的响应快一些，条件是你做了一些优化避免了浪费性能的重复渲染。
以手Q家校群功能页React重构优化为例手Q家校群功能页主要由三个页面构成，分别是列表页、布置页和详情页。列表页已重构完成并已发布，布置页已重构终了准备提测，详情页正在重构。与此同时我们已完成对列表页的同构直出优化，并已正在做ReactNative优化的铺垫。
这三个页面的重构其实覆盖了很多页面的案例，所以还是蛮有代表性的，我们会将重构当中遇到的一些经验穿插在文章里论述。
在手Q家校群重构之前，其实我们已做了1版PC家校群。当时将native的页面全部web化，直接就采取了React比较经常使用的全家桶套装：
构建工具=gulp+webpack
开发效力提升=redux-dev-tools+hot-reload
统一数据管理=redux
性能提升=immutable+purerender
路由控制器=react-router(手Q暂时没采取)
为何我们在优化的时候主要讲手Q呢？毕竟PC的性能在大部分情况下已很好，在PC上一些存在的问题都被PC良好的性能掩盖下去。的性能不如PC，因此有更多有价值的东西深挖。开发的时候我就跟同事开玩笑说：“没做过web优化的都真不好意思说自己做过性能优化啊"。
构建针对React做的优化我在《性能优化三部曲之一——构建篇》提出，“通过构建，我们可以达成开发效力的提升，和对项目最基本的优化”。在进行React重构优化的进程中，构建对项目的优化作用必不可少。在本文暂时不赘述，我另外开辟了一篇《webpack使用优化（react篇）》进行具体论述。
开发效力提升工具在PC端使用Redux的时候，我们都很喜欢使用Redux-Devtools来查看Redux触发的action，和对应的数据变化。PC端使用的时候，我们习惯摆在右侧。但移动端的屏幕较少，因此家校群项目使用的时候放在底部，而且由于性能问题，我们在constant里设一个debug参数，然后在chrome调试时打开，移动端非必须的时候关闭。否则，它会致使移动web的渲染比较低下。
数据管理及性能优化Redux统一管理数据
这1部分算是重头戏吧。React作为View层的框架，已通过vd帮助我们解决重复渲染的问题。但vd是通过看数据的前后差异去判断是不是要重复渲染的，但React并没有帮助我们去做这层比较。因此我们需要使用一整套数据管理工具及对应的优化方法去达成。在这方法，我们选择了Redux。
Redux全部数据流大体可以用下图来描写：
Redux这个框架的好处在于能够统一在自己定义的reducer函数里面去进行数据处理，在View层中只需要通过事件去处触发一些action就可以改变地应的数据，这样能够使数据处理和dom渲染更好地分离，而避免手动地去设置state。
在重构的时候，我们倾向于将功能类似的数据归类到一起，并建立对应的reducer文件对数据进行处理。如下图，是手Q家校群布置页的数据结构。有些大型的SPA项目可能会将初始数据分开在不同的reducer文件里，但这里我们倾向于归到一个store文件，这样能够清晰地知道全部文件的数据结构，也符合Redux想统一管理数据的想法。然后数据的每一个层级与reducer文件都是逐一对应的关系。
重复渲染致使卡顿这套React+Redux的东西在PC家校群页面上用得很欢乐，以至于不用怎样写shouldComponentUpdate都没遇到过甚么性能问题。但放到移动端上，我们在列表页重构的时候就马上遇到卡顿的问题了。
甚么缘由呢？是重复渲染致使的！！！！！！
说好的Reactvd可以减少重复渲染呢？！！！
请别忘记前提条件！！！！
你可以在每一个
中科UM-D中科白癜风医院微信