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

如何讓一個react組件自動刷新？

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

一個小程序的實施技術方案？

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

小程序

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

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

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

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

所有小程序的技術方案也是替這兩個需求服務。

管控

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

框架/DSL

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

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

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

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

JS環(huán)境

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

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

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

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

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

壞處只在于：

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

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

導致管控需求實在是太剛需，這個方案受到壞處可以給予。

體驗

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

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

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

緩存：退出小程序后絕對不會立即完全銷毀，會在后臺一直跑5分鐘，期間用戶切回小程序時速度快。

視覺：小程序2002年運行程序通過loading和動畫的過渡，婉拒白屏，給人一種快的感覺，另外修為提升了小程序的標識度。

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

支付寶小程序

策略

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

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

實現(xiàn)方法

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

React Native

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

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

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

內(nèi)部應用

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

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

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

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

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

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