最近一个季度，我们都在为手Q家校群做重构优化，将原有那套问题不断的框架换掉。经过一些斟酌，决定使用Ract进行重构。选择Ract，其实也主要是因为它具有下面的三大特性。
1Ract的特性
1.Larnonc,writanywhr
学习Ract的好处就是，学了一遍之后，能够写wb,nod直出，以及nativ，能够适应各种纷繁复杂的业务。需要轻量快捷的，直接可以用Ractjs；需要提升首屏时间的，可以结合RactSrvrRndr；需要更好的性能的，可以上RactNativ。
但是，这其实暗示学习的曲线非常陡峭。单单是Wbpack+Ract+Rdux就已够一个入门者够呛，更何况还要兼顾直出和手机客户端。不是一般人能hold住所有端。
2.VirtualDom
VirtualDom（下称vd）算是Ract的一个重大的特色，因为Facbook宣称由于vd的帮助，Ract能够达到很好的性能。是的，Facbook说的没错，但只说了一半，它说漏的一半是：“除非你能正确的采用一系列优化手段”。
3.组件化
另一个被大家所推崇的Ract优势在于，它能令到你的代码组织更清晰，维护起来更容易。我们在写的时候也有同感，但那是直到我们踩了一些坑，并且渐渐熟悉Ract+Rdux所推崇的那套代码组织规范之后。
那么？
上面的描述不免有些先扬后抑的感觉，那是因为往往作为Ract的刚入门者，都会像我们初入的时候一样，对Ract满怀希望，指意它帮我们做好一切，但随着了解的深入，发现需要做一些额外的事情来达到我们的期待。
2对Ract的期待
初学者对Ract可能满怀期待，觉得Ract可能完爆其它一切框架，甚至不切实际地认为Ract可能连原生的渲染都能完爆——对框架的狂热确实会出现这样的不切实际的期待。让我们来看看Ract的官方是怎么说的。Ract官方文档在AdvancdPrformanc这一节，这样写道：
OnofthfirstqustionspoplaskwhnconsidringRactforaprojctiswhthrthirapplicationwillbasfastandrsponsivasanquivalntnon-Ractvrsion
显然Ract自己也其实只是想尽量达到跟非Ract版本相若的性能。Ract在减少重复渲染方面确实是有一套独特的处理办法，那就是vd，但显示在首次渲染的时候Ract绝无可能超越原生的速度，或者一定能将其它的框架比下去。因此，我们在做优化的时候，可的期待的东西有：
首屏时间可能会比较原生的慢一些，但可以尝试用RactSrvrRndr(又称Isomorphic)去提高效率
用户进行交互的时候，有可能会比原生的响应快一些，前提是你做了一些优化避免了浪费性能的重复渲染。
3以手Q家校群功能页Ract重构优化为例
手Q家校群功能页主要由三个页面构成，分别是列表页、布置页和详情页。列表页已经重构完成并已发布，布置页已重构完毕准备提测，详情页正在重构。与此同时我们已完成对列表页的同构直出优化，并已正在做RactNativ优化的铺垫。
这三个页面的重构其实覆盖了不少页面的案例，所以还是蛮有代表性的，我们会将重构之中遇到的一些经验穿插在文章里论述。
在手Q家校群重构之前，其实我们已经做了一版PC家校群。当时将nativ的页面全部wb化，直接就采用了Ract比较常用的全家桶套装：
构建工具=gulp+wbpack
开发效率提升=rdux-dv-tools+hot-rload
统一数据管理=rdux
性能提升=immutabl+purrndr
路由控制器=ract-routr(手Q暂时没采用)
为什么我们在优化的时候主要讲手Q呢？毕竟PC的性能在大部份情况下已经很好，在PC上一些存在的问题都被PC良好的性能掩盖下去。手机的性能不如PC，因此有更多有价值的东西深挖。开发的时候我就跟同事开玩笑说：“没做过手机wb优化的都真不好意思说自己做过性能优化啊“。
4构建针对Ract做的优化
我在《性能优化三部曲之一——构建篇》提出，“通过构建，我们可以达成开发效率的提升，以及对项目最基本的优化”。在进行Ract重构优化的过程中，构建对项目的优化作用必不可少。在本文暂时不赘述，我另外开辟了一篇《wbpack使用优化（ract篇）》（