一個小程序的實施技術方案？小程序下線大半年，大部分技術原理也有文章能介紹了，本文嘗試從需求出發(fā)探討一番小程序技術方案的來源，以及最近不刪檔測試的支付寶小程序技術方案的考量。小程序小程序的需求是讓第三方

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

小程序下線大半年，大部分技術原理也有文章能介紹了，本文嘗試從需求出發(fā)探討一番小程序技術方案的來源，以及最近不刪檔測試的支付寶小程序技術方案的考量。

小程序

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

實際上這種簡單點方案沒法滿足用戶的需求，在產(chǎn)品上小程序有另外兩個很重要的是的需求：

管控。充當一個平臺要對接入到的應用有管控能力，要能不要精確控制應用的內(nèi)容和類型，畢竟若又出現(xiàn)非法經(jīng)營應用平臺是要承擔部分責任的，H5的極為自由，開發(fā)者是可以時刻改變整個應用的內(nèi)容，平臺未必能可以檢測到這些改變，根本無法管控。另H5開發(fā)質(zhì)量參差不齊，平臺也根本無法管控，這相對于從來有潔癖的來說都無法接受。

體驗。另外一個“小程序”要讓想體驗逼近原生，而上述像京東購物這些普通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能怎莫寫，結(jié)果能轉(zhuǎn)成什么，該如何執(zhí)行，大都平臺說了算，同樣的也可以不很方便做代碼掃描和審查。

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

這樣的話用一套框架去限制修改開發(fā)，再造一層DSL，以外管控外也有一個好處，那是容易通過針對性優(yōu)化，DSL結(jié)果轉(zhuǎn)成什么，到最后如何負責執(zhí)行渲出都由框架確定，上層不感知，可以可以做成由webview顏色渲染，有條件也這個可以用類似于RN的方案自己利用軟件渲染層。

JS環(huán)境

按照框架限定開發(fā)后，管控上還有個問題，應該是該如何限制修改運用端類JS語言動態(tài)鏈接庫domAPI？小程序跑在webview上，軟件渲染時勢必要實際JS操作dom，假如小程序框架和應用JS代碼應該有權限操作dom，應用很可能會通過各種在下線后繞到檢查，融入JS全局函數(shù)dom接口去如何修改頁面結(jié)構和內(nèi)容，變成跟審核時不一樣的的應用。怎么樣才能能限制應用形式的JS調(diào)用dom的權限？想了個都很創(chuàng)新和改革的解決方案，那就是：JS運行環(huán)境與瀏覽器再分離，不運行在不能的JS引擎上。

逃出了瀏覽器，JS也就沒有dom的動態(tài)鏈接庫權限，任何跟webview界面相關的API都不能拿到。而小程序框架核心JS運行在webview上，也可以神圣你操作dom，按照小程序框架符號表示的機制，應用端按照wxml/wxss定義且固定的3d渲染樣式，JS端只管開口數(shù)據(jù)手機綁定，數(shù)據(jù)也可以實際framework橋梁從JS引擎?zhèn)鬟f到webview，JS端難以做任何顏色渲染相關的你操作，可以對渲出的內(nèi)容有完整的管控權。

的的的JS運行環(huán)境以外滿足的條件管控需求外，也附加給予一些好處和一些壞處，好處本質(zhì)：

多個頁面這個可以寬帶共享一個JS運行環(huán)境，數(shù)據(jù)這個可以很比較方便地網(wǎng)絡共享，整個小程序生命周期里網(wǎng)絡共享同一個上下文，更距離APP的開發(fā)體驗。

JS與頁面顏色渲染分離左行不能執(zhí)行，不會再次出現(xiàn)JS不能執(zhí)行時卡住頁面渲出的情況，提升到渲染性能。

壞處取決于人：

多了數(shù)據(jù)序列化傳輸?shù)拈_銷，數(shù)據(jù)需要從JS傳到webview給視圖層軟件渲染，不需要序列化為字符串格式再接受傳輸。

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

的原因管控需求實在是太剛需，這個方案給予壞處可以不認可。

體驗

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

離線狀態(tài)包：整個小程序打包下發(fā)通知，不必須再打開每個頁面都去只是請求，減少倆次再打開時間以及頁面切換時間。

預加載：預加載多一個wkwebview放后臺，用戶可以打開小程序時會省系統(tǒng)初始化wkwebview時間。別外對于一個小程序內(nèi)的頁面可以切換，得益于框架的設計，是可以做到預軟件渲染模板，切換到時再圖案填充數(shù)據(jù)，加快渲出速度。

緩存：退出小程序后不會立馬全部銷毀，會在后臺再跑5分鐘，期間用戶切回小程序時速度快。

視覺：小程序榜首次打開程序按照loading和動畫的過渡，回絕白屏，給人種快的感覺，同樣提升到了小程序的標識度。

只剩的應該是不斷小程序這個平臺的周邊建設和發(fā)展了，像組件，native接口，IDE，后臺管理，版本管理，權限控制等基礎支持。

支付寶小程序

策略

小程序會推出時主要注意面向的場景是線下，如果能商家能開發(fā)小程序，做像服務員上菜去買票這樣的即時性應用，提升線下商戶體驗，支付寶作為線下戰(zhàn)場的要注意競爭對手也就要再跟蹤。

支付寶去做小程序應該怎樣做？可以據(jù)自身的情況，定義另一套技術體系，讓第三方接入。但這樣的話第三方如果沒有要同樣接入和支付寶，需要變更土地性質(zhì)兩套程序，成本很高，而有去發(fā)和平臺優(yōu)勢，很可能會變得只變更土地性質(zhì)小程序而放棄你接入支付寶小程序，所以建議的做法是降低這里的接入成本，讓小程序的代碼是可以并行化在支付寶小程序上。所以小程序接合的框架/API/組件要是跟小程序逼近或追求精益求精一致，技術上沒得你選，因為看的到支付寶小程序公測版的文檔很多跟一致。

基于

支付寶小程序框架正式接口是跟一樣的，又畢竟同樣有管控/安全和想體驗的需求，有些策略是相似的，像相當于JS環(huán)境，不聯(lián)網(wǎng)包，緩存策略等，但在小程序框架的實現(xiàn)上就跟徹底不一樣。小程序框架才是一層屏蔽了基于細節(jié)的DSL層，最終實際什么技術手段實現(xiàn)程序都是可以是由框架底層自由設計定制的，這邊技術底層基于組件螞蟻前端團隊多年的積累，到了最后web版小程序是以react為基礎實現(xiàn)方法。

React Native

除了作為的跟完全不同的web版小程序，內(nèi)部總是在一段時間React Native版小程序，軟件渲染層不可以參照webview，只是用RN去顏色渲染，提升性能和體驗，這都是小程序DSL層用處，底層渲染引擎這個可以很方便啊地替換實現(xiàn)方法方案，甚至同時存在多套方案。

很多人問為么用不著weex，按我再理解簡單的方法是螞蟻的前端技術?；跅l件react，直接切換成本高，一個RN相對weex成熟度高，社區(qū)允許度高，并保持著不間斷的更新，相對于敵視。

RN本身不基于瀏覽器，iOS/Android有各自的寫法，在RN的使用上，業(yè)界很多人各自實現(xiàn)方法了實現(xiàn)RN的跨三端或兩端的開發(fā)（的或JDReact），也就是第二次開發(fā)，能另外接受RN在iOS/Android平行放置做原生軟件渲染，也支持什么fallback到webview3d渲染。這里小程序也算得這樣的話一套方案，上層實際自定義設置DSL開發(fā)業(yè)務，作戰(zhàn)部署時通過工具分別轉(zhuǎn)換的成三個平臺相同的代碼，在三個平臺運行。

內(nèi)部應用

小程序是一套聯(lián)合的方案，要注意應用于第三方應用接入，畢竟上文也說了，框架上很多技術方案也是是為滿足對第三方管控和安全方面的需求，而小程序相關的很多親身體驗系統(tǒng)優(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)部不使用的技術體系，如此大減低技術成本。

基于條件這些原因，在騰訊理財通這邊一些內(nèi)部此刻估計可以使用H5實現(xiàn)程序的業(yè)務，也正一段時間更多地可以使用小程序?qū)崿F(xiàn)程序，以提升用戶體驗，目前部分設計和實現(xiàn)小程序RN版開發(fā)的業(yè)務已大俠幫幫忙上穩(wěn)定運行，情報營也會再繼續(xù)接觸把小程序RN版堅持了打造成高性能穩(wěn)定的三端統(tǒng)一動態(tài)化方案。

JavaScript、nodejs和reactjs以及react、react native是什么關系？

Javascript是電腦語言。

node.js是這個可以在服務器上在用javascript的開發(fā)環(huán)境，設計和實現(xiàn)google的v8,用c寫的。

React.js是一個前端的模板(也不是庫)用javascript寫的，可在遊覽器和node.js下不運行。

NativeScript是在手機上可以用Javascript做APP開發(fā)，由幾種相同語言書寫(看運行平臺)Java,Objective C,swiftetc.