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

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

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

小程序

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

實(shí)際上這種簡(jiǎn)單點(diǎn)方案沒(méi)法滿(mǎn)足用戶(hù)的需求，在產(chǎn)品上小程序有另外兩個(gè)很重要的是的需求：

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

體驗(yàn)。另外一個(gè)“小程序”要讓想體驗(yàn)逼近原生，而上述像京東購(gòu)物這些普通H5頁(yè)面的可以體驗(yàn)不太行，和啟動(dòng)速度/頁(yè)面切換流暢度都是問(wèn)題，跟原生體驗(yàn)沒(méi)法比。

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

管控

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

框架/DSL

H5太自由，簡(jiǎn)單要做的那就是沒(méi)限制它的自由，怎么才能限制修改？肯定是做個(gè)框架栓住，讓開(kāi)發(fā)者沒(méi)有辦法按框架的規(guī)則去開(kāi)發(fā)。那應(yīng)該是使用怎樣的框架？

在PCSNS時(shí)代，F(xiàn)acebook做開(kāi)放平臺(tái)時(shí)有類(lèi)似的場(chǎng)景，就是為了第三方開(kāi)發(fā)者能在Facebook平臺(tái)上開(kāi)發(fā)，同樣的又能取消住開(kāi)發(fā)者的權(quán)限，F(xiàn)acebook具體的要求開(kāi)發(fā)者在用下拉菜單的一套DSL(FBML)去開(kāi)發(fā)，而這個(gè)DSL能怎莫寫(xiě)，結(jié)果能轉(zhuǎn)成什么，該如何執(zhí)行，大都平臺(tái)說(shuō)了算，同樣的也可以不很方便做代碼掃描和審查。

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

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

JS環(huán)境

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

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

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

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

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

壞處取決于人：

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

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

的原因管控需求實(shí)在是太剛需，這個(gè)方案給予壞處可以不認(rèn)可。

體驗(yàn)

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

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

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

緩存：退出小程序后不會(huì)立馬全部銷(xiāo)毀，會(huì)在后臺(tái)再跑5分鐘，期間用戶(hù)切回小程序時(shí)速度快。

視覺(jué)：小程序榜首次打開(kāi)程序按照l(shuí)oading和動(dòng)畫(huà)的過(guò)渡，回絕白屏，給人種快的感覺(jué)，同樣提升到了小程序的標(biāo)識(shí)度。

只剩的應(yīng)該是不斷小程序這個(gè)平臺(tái)的周邊建設(shè)和發(fā)展了，像組件，native接口，IDE，后臺(tái)管理，版本管理，權(quán)限控制等基礎(chǔ)支持。

支付寶小程序

策略

小程序會(huì)推出時(shí)主要注意面向的場(chǎng)景是線(xiàn)下，如果能商家能開(kāi)發(fā)小程序，做像服務(wù)員上菜去買(mǎi)票這樣的即時(shí)性應(yīng)用，提升線(xiàn)下商戶(hù)體驗(yàn)，支付寶作為線(xiàn)下戰(zhàn)場(chǎng)的要注意競(jìng)爭(zhēng)對(duì)手也就要再跟蹤。

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

基于

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

React Native

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

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

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

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

小程序是一套聯(lián)合的方案，要注意應(yīng)用于第三方應(yīng)用接入，畢竟上文也說(shuō)了，框架上很多技術(shù)方案也是是為滿(mǎn)足對(duì)第三方管控和安全方面的需求，而小程序相關(guān)的很多親身體驗(yàn)系統(tǒng)優(yōu)化其功能強(qiáng)大純H5也可以不做到，內(nèi)部業(yè)務(wù)用web版小程序開(kāi)發(fā)完全沒(méi)有受到什么好處，反到增強(qiáng)學(xué)成本。但RN版小程序不一樣的，它有一些優(yōu)勢(shì)，除開(kāi)：

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

相對(duì)于前者建議使用RN開(kāi)發(fā)，在用小程序也可以被屏蔽平臺(tái)差異，實(shí)現(xiàn)方法跨平臺(tái)一次開(kāi)發(fā)。

小程序有設(shè)配的開(kāi)發(fā)環(huán)境/IDE/包管理等基礎(chǔ)設(shè)施意見(jiàn)，無(wú)需再反復(fù)重復(fù)建設(shè)。

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

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

JavaScript、nodejs和reactjs以及react、react native是什么關(guān)系？

Javascript是電腦語(yǔ)言。

node.js是這個(gè)可以在服務(wù)器上在用javascript的開(kāi)發(fā)環(huán)境，設(shè)計(jì)和實(shí)現(xiàn)google的v8,用c寫(xiě)的。

React.js是一個(gè)前端的模板(也不是庫(kù))用javascript寫(xiě)的，可在遊覽器和node.js下不運(yùn)行。

NativeScript是在手機(jī)上可以用Javascript做APP開(kāi)發(fā)，由幾種相同語(yǔ)言書(shū)寫(xiě)(看運(yùn)行平臺(tái))Java,Objective C,swiftetc.