RN是什么

ReactNative早在2016年的時(shí)候火了，當(dāng)時(shí)只是草草的了解了一下，知道它是個(gè)跨平臺(tái)的移動(dòng)端技術(shù)解決方案，而且支持代碼下發(fā)的方式更新產(chǎn)品，苦于沒(méi)有落地實(shí)踐的機(jī)會(huì)，并沒(méi)有深入了解。自從去年底公司產(chǎn)品日漸成熟，自己有足夠的時(shí)間，于是決定學(xué)習(xí)一下RN并嘗試做了個(gè)Demo。

RN適合前端還是客戶(hù)端？

如果你問(wèn)我，RN到底適合前端開(kāi)發(fā)人員開(kāi)發(fā)還是客戶(hù)端開(kāi)發(fā)者開(kāi)發(fā)？

我的回答是：更適合客戶(hù)端開(kāi)發(fā)者開(kāi)發(fā)。

有的人說(shuō)，不是啊，你看代碼主要是react.js和style，客戶(hù)端只要將代碼打包集成到相應(yīng)的平臺(tái)即可。js和style不是前端開(kāi)發(fā)者的本職工作嘛。

乍一看，上述理解貌似很正確，可以當(dāng)你真正學(xué)習(xí)了RN之后，你會(huì)發(fā)現(xiàn)，其實(shí)RN開(kāi)發(fā)跟移動(dòng)開(kāi)發(fā)過(guò)程沒(méi)什么區(qū)別，我說(shuō)的是開(kāi)發(fā)的思維，比如生命周期，事件的響應(yīng)，頁(yè)面的跳轉(zhuǎn)等等。

如果要說(shuō)區(qū)別只有2個(gè)方面：

1.換了一個(gè)開(kāi)發(fā)語(yǔ)言而已，由原來(lái)的客戶(hù)端Java或OC換成js,這個(gè)學(xué)習(xí)成本并不高，尤其對(duì)一些有過(guò)JS基礎(chǔ)的幾乎可以直接上手。

2.UI布局，如果你是一名iOS開(kāi)發(fā)者，你一定很詬病iOS的布局，因?yàn)閕OS布局只有2種：frame絕對(duì)布局和Autolayout相對(duì)布局。frame布局就不說(shuō)了，面對(duì)眾多手機(jī)尺寸根本無(wú)能為力，缺乏靈活性，在如今的iOS開(kāi)發(fā)中，已經(jīng)處于淘汰的地位；AutoLayout作為iOS6推出的布局技術(shù)，基本上可以很輕松的解決70%的布局，但是，針對(duì)動(dòng)態(tài)內(nèi)容布局，尤其是依賴(lài)的組件需要根據(jù)不同情況展示隱藏等，你要頻繁的移除、添加約束，而變更約束是比較耗性能的操作，從而影響UI的流暢性，另一方面相應(yīng)的代碼邏輯會(huì)變得非常臃腫，簡(jiǎn)直就要瘋。缺乏類(lèi)似前端優(yōu)秀的Flex布局（iOS9新增了UIStackView，終于引入了盒子布局，算是解決了這個(gè)痛點(diǎn)）。所以，對(duì)于iOS開(kāi)發(fā)者，需要轉(zhuǎn)變一下布局思維，由相對(duì)布局到學(xué)習(xí)Flex布局。而flex布局學(xué)習(xí)成本就更低了，我覺(jué)得讀一下阮一峰老師的那篇Flex布局基本上就可以開(kāi)發(fā)了。這里附一下阮一峰老師的那篇地址：阮一峰 Flex布局

除上述說(shuō)到的2個(gè)方面外，ReactNative其實(shí)和客戶(hù)端開(kāi)發(fā)差不多了。

首先，針對(duì)style，其實(shí)，RN支持的style屬性就僅僅是原生組件所支持的所有屬性，原生控件沒(méi)有某個(gè)屬性，style也就用不了，至于前端什么float，margin:auto, 這些根本無(wú)效啊，所以，很多沒(méi)有客戶(hù)端基礎(chǔ)的前端，以為RN的style和H5的style一樣，那你就大錯(cuò)特錯(cuò)了，所以，你說(shuō)客戶(hù)端轉(zhuǎn)RN快，還是H5學(xué)習(xí)RN快呢？

然后，RN中幾乎每個(gè)頁(yè)面都要設(shè)計(jì)安卓iOS不同客戶(hù)端的平臺(tái)的不同特性處理，如果你僅僅是一名H5，不了解2個(gè)平臺(tái)的特性，你會(huì)非常的痛苦，所以很多同學(xué)說(shuō)RN坑很多，是的，坑確實(shí)很多，但是如果你是客戶(hù)端開(kāi)發(fā)者，RN的很多坑都能理解了，對(duì)你填這些坑也有很大幫助。

還有就是，從渲染的角度，RN本質(zhì)也是原生控件渲染出來(lái)了，這跟H5通過(guò)webView渲染有本質(zhì)區(qū)別，所以說(shuō)，RN是原生的。

所以，我認(rèn)為RN更適合客戶(hù)端開(kāi)發(fā)者開(kāi)發(fā)，由于iOS和安卓平臺(tái)的差異，一個(gè)RN項(xiàng)目，應(yīng)該至少配一名iOS和一名安卓RN開(kāi)發(fā)，雖然說(shuō)，RN跨平臺(tái)，但是畢竟iOS開(kāi)發(fā)者不是很了解安卓平臺(tái)，反之亦然，當(dāng)然，如果是一名兼iOS、安卓開(kāi)發(fā)者除外。

由此，RN技術(shù)的使用，并不是為了節(jié)約開(kāi)發(fā)成本的，在我看來(lái)，而是看重了RN的熱更新的能力，眾所周知，蘋(píng)果的審核條條框框限制很多，對(duì)于一個(gè)大型的項(xiàng)目，審核的方面就很多，經(jīng)常會(huì)因?yàn)橐恍?quán)限、政策條款而被拒，又要重新修改提交上架審核，這樣就耽誤了公司層面的運(yùn)營(yíng)時(shí)間，這也是很多大型電商平臺(tái)諸如去哪兒、58同城使用的原因吧。

RN的難點(diǎn)

RN真正的難點(diǎn)不在業(yè)務(wù)的開(kāi)發(fā)，它的難點(diǎn)在于，應(yīng)對(duì)不斷增多的業(yè)務(wù)js文件，由于RN運(yùn)行需要先加載jsbundle文件到內(nèi)存，進(jìn)行解析，最后再渲染到UI層，而jsbundle文件的加載是耗時(shí)的，如何解決初始化頁(yè)面白屏，等待的時(shí)間如何減少才是核心技術(shù)的難點(diǎn)。

曾經(jīng)看到過(guò)一個(gè)關(guān)于58項(xiàng)目RN拆分通用jsbundle，再合并的帖子，能降低70%的js加載時(shí)間。這是很好的例子，希望能有機(jī)會(huì)遇到這樣的性能瓶頸然后去解決這樣的問(wèn)題。