如何讓一個(gè)react組件自動(dòng)刷新？簡(jiǎn)單的方法不使用reactnative編譯程序一個(gè)簡(jiǎn)單的應(yīng)用，在見到過問題的時(shí)候，那肯定不需要對(duì)代碼參與系統(tǒng)的調(diào)試。目前reactnative支持什么在Chrome瀏

如何讓一個(gè)react組件自動(dòng)刷新？

簡(jiǎn)單的方法不使用reactnative編譯程序一個(gè)簡(jiǎn)單的應(yīng)用，在見到過問題的時(shí)候，那肯定不需要對(duì)代碼參與系統(tǒng)的調(diào)試。目前reactnative支持什么在Chrome瀏覽器內(nèi)參與系統(tǒng)的調(diào)試。

一個(gè)小程序的實(shí)施技術(shù)方案？

小程序上游戲大半年，大部分技術(shù)原理也有文章介紹了，本文嘗試從需求向東出發(fā)探討一番小程序技術(shù)方案的來源，和最近內(nèi)測(cè)的支付寶小程序技術(shù)方案的考量。

小程序

小程序的需求是讓第三方開發(fā)者也可以接入，也可以不使用的提供給的接口去開發(fā)應(yīng)用貼入在里。這對(duì)這個(gè)需求，最簡(jiǎn)單的實(shí)現(xiàn)方案是：讓外部開發(fā)者開發(fā)純H5應(yīng)用，在的H5容器里再打開，容器能提供接口，就行了。在有小程序之前，早就有很多這樣的業(yè)務(wù)接入，像京東購(gòu)物，錢包里的各種友商大眾點(diǎn)評(píng)/滴滴出行等，都可以不認(rèn)為是一個(gè)“小程序”，內(nèi)嵌在里，能動(dòng)態(tài)鏈接庫(kù)接口，是不是沿著這種模式下去，把或則的接口開放給第三方，再提供個(gè)入口就行了？

只不過這種很簡(jiǎn)單方案沒法滿足自身需求，在產(chǎn)品上小程序有另外兩個(gè)很不重要的需求：

管控。充當(dāng)一個(gè)平臺(tái)需要對(duì)接入到的應(yīng)用有管控能力，可以能不要精確控制應(yīng)用的內(nèi)容和類型，要知道若又出現(xiàn)非法應(yīng)用平臺(tái)是要承擔(dān)責(zé)任的，H5的太過自由，開發(fā)者這個(gè)可以隨時(shí)變化整個(gè)應(yīng)用的內(nèi)容，平臺(tái)沒法怎么檢測(cè)到這些改變，難以管控。別外H5開發(fā)質(zhì)量參差不齊，平臺(tái)也難以管控，這是對(duì)一直都有潔癖的來說難以接受。

體驗(yàn)。充當(dāng)一個(gè)“小程序”要讓體驗(yàn)將近原生，而根據(jù)上述規(guī)定像京東購(gòu)物這些普通H5頁(yè)面的再體驗(yàn)不太行，和起動(dòng)速度/頁(yè)面直接切換流暢度都有吧問題，跟原生體驗(yàn)很難比。

所有小程序的技術(shù)方案也是替這兩個(gè)需求服務(wù)。

管控

為了不滿足管控的需求，技術(shù)上做了兩個(gè)事情：小程序框架和只是分離JS運(yùn)行環(huán)境。

框架/DSL

H5太自由，是需要要做的應(yīng)該是取消它的自由，怎樣才能取消？自然是做個(gè)框架住，讓開發(fā)者沒法按框架的規(guī)則去開發(fā)。那應(yīng)該在用怎樣的框架？

在PCSNS時(shí)代，F(xiàn)acebook做開放平臺(tái)時(shí)有相似的場(chǎng)景，為了第三方開發(fā)者能在Facebook平臺(tái)上開發(fā)完畢，另外又能取消住開發(fā)者的權(quán)限，F(xiàn)acebook要求開發(fā)者不使用自定義的一套DSL(FBML)去開發(fā)，而這個(gè)DSL能怎莫寫，最終能轉(zhuǎn)成什么，要如何負(fù)責(zé)執(zhí)行，大都平臺(tái)說了算，同樣也可以不很方便啊做代碼掃描和審查。

小程序倒是能廣泛借鑒這樣的設(shè)計(jì)思路，界面不使用HTML開發(fā)，反而自定義設(shè)置一套DSL，這樣的就可以不容易對(duì)付審核/代碼掃描/域名限制等系列措施做個(gè)管控，這是小程序這一套框架的來源。這套框架是從wxml去詳細(xì)解釋界面，wxss具體描述樣式，js去去處理邏輯和數(shù)據(jù)，再是從工具一系列處理把這些轉(zhuǎn)為HTML/CSS/JS不顯示在webview上，并如何處理界面交互和數(shù)據(jù)更新。

那樣的話用一套框架去限制下載開發(fā)完畢，再塑一層DSL，除了管控外也有一個(gè)好處，就是容易并且針對(duì)性優(yōu)化，DSL到最后轉(zhuǎn)成什么，最終要如何先執(zhí)行渲出都由框架改變，上層不五感，是可以先做成由webview渲染，有條件也可以不用類似于RN的方案自己實(shí)現(xiàn)顏色渲染層。

JS環(huán)境

框架限定開發(fā)后，管控上有個(gè)問題，就是如何能沒限制應(yīng)用到端類JS語言調(diào)用domAPI？小程序跑在webview上，3d渲染時(shí)必然要通過JS操作dom，如果小程序框架和應(yīng)用JS代碼都有吧權(quán)限操作dom，應(yīng)用可能會(huì)會(huì)各種在上不了線后繞到檢查，注入JS動(dòng)態(tài)鏈接庫(kù)dom接口去如何修改頁(yè)面結(jié)構(gòu)和內(nèi)容，轉(zhuǎn)成跟審核時(shí)不一樣的的應(yīng)用。怎樣能限制修改應(yīng)用的JS內(nèi)部函數(shù)dom的權(quán)限？想了個(gè)都很持續(xù)創(chuàng)新的解決方案，那就是：JS運(yùn)行環(huán)境與瀏覽器再分離，啟動(dòng)在分開來的JS引擎上。

沖破了瀏覽器，JS恐怕沒有dom的全局函數(shù)權(quán)限，任何跟webview界面相關(guān)的API都不能搞到。而小程序框架核心JS啟動(dòng)在webview上，是可以光明操作dom，按照小程序框架定義法的機(jī)制，應(yīng)用端實(shí)際wxml/wxss定義且固定的渲染樣式，JS端老老實(shí)實(shí)數(shù)據(jù)沒綁定，數(shù)據(jù)可以不按照context橋梁從JS引擎?zhèn)鬟f到webview，JS端難以做任何顏色渲染相關(guān)的操作，也可以對(duì)渲出的內(nèi)容有求下載的管控權(quán)。

相當(dāng)于的JS運(yùn)行環(huán)境除開柯西-黎曼方程管控需求外，也增加給予一些好處和一些壞處，好處只是相對(duì)而言：

多個(gè)頁(yè)面是可以網(wǎng)絡(luò)共享一個(gè)JS運(yùn)行環(huán)境，數(shù)據(jù)可以很更方便地鏈接共享，整個(gè)小程序生命周期里互相訪問同一個(gè)上下文，更接近APP的開發(fā)體驗(yàn)。

JS與頁(yè)面顏色渲染分離的過程并行不能執(zhí)行，肯定不會(huì)會(huì)出現(xiàn)JS不能執(zhí)行時(shí)卡住頁(yè)面渲染的情況，實(shí)力提升軟件渲染性能。

壞處只在于：

多了數(shù)據(jù)序列化傳輸?shù)拈_銷，數(shù)據(jù)是需要從JS傳到webview給視圖層3d渲染，是需要序列化為字符串格式再通過傳輸。

iOS上WKWebview的JS引擎比JavaScriptCore多了JIT優(yōu)化，執(zhí)行速度快很多倍，小程序的JS不運(yùn)行在JavaScriptCore上不能享不享受到這個(gè)360優(yōu)化。

導(dǎo)致管控需求實(shí)在是太剛需，這個(gè)方案受到壞處可以給予。

體驗(yàn)

小程序最主要的兩個(gè)技術(shù)點(diǎn)—框架和JS運(yùn)行分離是源于管控需求，而體驗(yàn)上的需求那是由各種極細(xì)致的性能優(yōu)化分成了，很多文章也總結(jié)過，這里簡(jiǎn)單的說下，以及：

離線包：整個(gè)小程序發(fā)我下發(fā)文件，不必須再打開每個(gè)頁(yè)面都去請(qǐng)求，減少第二次再打開時(shí)間和頁(yè)面可以切換時(shí)間。

預(yù)加載：預(yù)加載多一個(gè)wkwebview放后臺(tái)，用戶可以打開小程序時(shí)省掉初始化設(shè)置wkwebview時(shí)間。另是對(duì)一個(gè)小程序內(nèi)的頁(yè)面切換到，均沾于框架的設(shè)計(jì)，這個(gè)可以能做到預(yù)軟件渲染模板，切換到時(shí)再填充數(shù)據(jù)，減緩顏色渲染速度。

緩存：退出小程序后絕對(duì)不會(huì)立即完全銷毀，會(huì)在后臺(tái)一直跑5分鐘，期間用戶切回小程序時(shí)速度快。

視覺：小程序2002年運(yùn)行程序通過loading和動(dòng)畫的過渡，婉拒白屏，給人一種快的感覺，另外修為提升了小程序的標(biāo)識(shí)度。

剩下的就是環(huán)繞小程序這個(gè)平臺(tái)的周邊建設(shè)了，像組件，restful接口，IDE，后臺(tái)管理，版本管理，權(quán)限控制等基礎(chǔ)支持。

支付寶小程序

策略

小程序所推出時(shí)通常面向的場(chǎng)景是線下，希望商家能開發(fā)小程序，做像上菜買票這樣的即時(shí)性應(yīng)用，進(jìn)階線下商戶體驗(yàn)，支付寶以及線下戰(zhàn)場(chǎng)的主要競(jìng)爭(zhēng)對(duì)手自然要跟進(jìn)。

支付寶去做小程序應(yīng)該怎么做？也可以依據(jù)什么自身的情況，定義另一套技術(shù)體系，讓第三方接入。但這樣的話第三方如果不是要同樣接入和支付寶，需要旗下兩套程序，成本很高，而有再發(fā)和平臺(tái)優(yōu)勢(shì)，很肯定變得只開發(fā)完畢小程序而徹底放棄接入支付寶小程序，所以才最好的做法是降底這里的接入成本，讓小程序的代碼這個(gè)可以并行化在支付寶小程序上。所以小程序正式的框架/API/組件要是跟小程序距離或少而精一致，技術(shù)上沒得選擇類型，所以可以看到支付寶小程序公測(cè)版的文檔很多跟同一。

實(shí)現(xiàn)方法

支付寶小程序框架組織接口是跟差不多，又因?yàn)橥瑯佑泄芸?安全和親身體驗(yàn)的需求，有些策略是帶有的，像的的JS環(huán)境，自動(dòng)更新包，緩存策略等，但在小程序框架的實(shí)現(xiàn)上就跟幾乎是一樣的。小程序框架作為一層蔽屏了實(shí)現(xiàn)方法細(xì)節(jié)的DSL層，到了最后按照什么技術(shù)手段實(shí)現(xiàn)都也可以是由框架底層自由定制的，這邊底層技術(shù)基于組件螞蟻前端團(tuán)隊(duì)多年的積累，結(jié)果web版小程序是以react為基礎(chǔ)基于。

React Native

除開作為的跟完全不同的web版小程序，內(nèi)部總是在一段時(shí)間React Native版小程序，顏色渲染層不區(qū)分webview，而是用RN去渲染，提升性能和體驗(yàn)，這也小程序DSL層幫助，底層渲染引擎是可以很比較方便地替換后實(shí)現(xiàn)方法方案，甚至還另外必然多套方案。

很多人問為啥你不weex，按我解釋首先是螞蟻的前端技術(shù)?；诮M件react，直接切換成本高，一個(gè)RN低些weex成熟度高，社區(qū)意見度高，并盡量著不間斷的更新，總體敵視。

RN本身不跨平臺(tái)操作，iOS/Android有各自的寫法，在RN的使用上，業(yè)界很多人各自實(shí)現(xiàn)了基于RN的跨三端或兩端的開發(fā)（或者JDReact），也就是第二次開發(fā)，能而意見RN在iOS/Android平行放置做原生渲染，也支持fallback到webview渲出。這里小程序也也算這樣的一套方案，上層實(shí)際選項(xiàng)卡DSL開發(fā)業(yè)務(wù)，作戰(zhàn)部署時(shí)工具分別可以轉(zhuǎn)換成三個(gè)平臺(tái)有所不同的代碼，在三個(gè)平臺(tái)啟動(dòng)。

內(nèi)部應(yīng)用

小程序是一套作為的方案，主要注意主要是用于第三方應(yīng)用接入，只不過上文也說了，框架上很多技術(shù)方案是替滿足的條件對(duì)第三方管控和安全方面的需求，而小程序相關(guān)的很多親身體驗(yàn)360優(yōu)化其功能多純H5也可以能夠做到，內(nèi)部業(yè)務(wù)用web版小程序開發(fā)并沒有什么給予什么好處，反倒減少去學(xué)習(xí)成本。但RN版小程序是一樣的，它有一些優(yōu)勢(shì)，和：

RN總體webview性能優(yōu)勢(shì)明顯，秒開率高，交互也更流暢的體驗(yàn)。

比起如果說不使用RN開發(fā)，不使用小程序是可以屏閉平臺(tái)差異，實(shí)現(xiàn)跨平臺(tái)一次開發(fā)。

小程序有對(duì)應(yīng)的開發(fā)環(huán)境/IDE/包管理等基礎(chǔ)設(shè)施支持什么，不需要再再重復(fù)一遍建設(shè)。

這對(duì)業(yè)務(wù)開發(fā)者，小程序也不是全新的一套開發(fā)，在業(yè)界可復(fù)用，對(duì)于框架利用者，RN都是業(yè)界很流行開源方案，有強(qiáng)橫的社區(qū)支持。對(duì)內(nèi)對(duì)外都盡量減少了另外創(chuàng)建一套只有在內(nèi)部建議使用的技術(shù)體系，如此大降低技術(shù)成本。

實(shí)現(xiàn)這些原因，在螞蟻財(cái)富這邊一些內(nèi)部雖然肯定不使用H5實(shí)現(xiàn)程序的業(yè)務(wù)，也正嘗試更多地建議使用小程序?qū)崿F(xiàn)，以提升用戶體驗(yàn)，目前部分設(shè)計(jì)和實(shí)現(xiàn)小程序RN版開發(fā)的業(yè)務(wù)已大俠幫幫忙上穩(wěn)定運(yùn)行，妖軍也會(huì)不再試圖把小程序RN版減弱百煉成高性能穩(wěn)定的三端統(tǒng)一動(dòng)態(tài)化方案。