手機(jī)白屏一閃一閃是什么原因？手機(jī)屏幕閃啊閃的原因是什么？麻煩問下這個問題，我的答案是手機(jī)閃屏的原因，很可能是只不過手機(jī)的屏幕會出現(xiàn)了損壞也有可能是畢竟手機(jī)的內(nèi)屏某些零件出現(xiàn)了松動，或者是手機(jī)內(nèi)屏?xí)霈F(xiàn)

手機(jī)白屏一閃一閃是什么原因？

手機(jī)屏幕閃啊閃的原因是什么？麻煩問下這個問題，我的答案是手機(jī)閃屏的原因，很可能是只不過手機(jī)的屏幕會出現(xiàn)了損壞也有可能是畢竟手機(jī)的內(nèi)屏某些零件出現(xiàn)了松動，或者是手機(jī)內(nèi)屏?xí)霈F(xiàn)了灰色的痕跡，倒致手機(jī)閃屏故障，也可以帶到維修店接受檢測維修。

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

小程序上游戲大半年，大部分技術(shù)原理也有文章介紹了，本文數(shù)次從需求出發(fā)探討一番小程序技術(shù)方案的來源，這些最近不刪檔測試的支付寶小程序技術(shù)方案的考量。

小程序

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

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

管控。作為一個平臺可以對接入的應(yīng)用有管控能力，前提是能最好不要精確控制應(yīng)用的內(nèi)容和類型，畢竟若又出現(xiàn)非法經(jīng)營應(yīng)用平臺是要承當(dāng)責(zé)任的，H5的太過于自由，開發(fā)者可以一旦決定整個應(yīng)用的內(nèi)容，平臺難以檢測檢測到這些改變，沒能管控。同時(shí)H5開發(fā)質(zhì)量參差不齊，平臺也根本無法管控，這對于一直以來有潔癖的來說難以接受。

體驗(yàn)。才是一個“小程序”要讓體驗(yàn)將近原生，而根據(jù)上述規(guī)定像京東購物這些大多數(shù)H5頁面的親身體驗(yàn)不太行，除開啟動速度/頁面快速切換流暢度應(yīng)該有問題，跟原生體驗(yàn)沒辦法比。

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

管控

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

框架/DSL

H5太自由，簡單的方法要做的那是限制它的自由，怎樣才能限制下載？也是做個框架綁住，讓開發(fā)者不能按框架的規(guī)則去開發(fā)。那應(yīng)該要可以使用怎樣的框架？

在PCSNS時(shí)代，F(xiàn)acebook做開放平臺時(shí)有相似的場景，為了第三方開發(fā)者能在Facebook平臺上旗下，同樣的又能取消住開發(fā)者的權(quán)限，F(xiàn)acebook那些要求開發(fā)者使用選項(xiàng)卡的一套DSL(FBML)去開發(fā)，而這個DSL能怎莫寫，最終能轉(zhuǎn)成什么，怎么先執(zhí)行，大都平臺說了算，另外也是可以很方便些做代碼掃描和審查。

小程序趁著能借鑒吸收這樣的設(shè)計(jì)思路，界面不使用HTML開發(fā)，只是自定義一套DSL，這樣就可以非常容易配合審核/代碼掃描/域名限制等系列措施去做管控，這那是小程序這一套框架的來源。這套框架去描述界面，wxss具體描述樣式，js去處理邏輯和數(shù)據(jù)，再是從工具一系列一次性處理把這些轉(zhuǎn)為HTML/CSS/JS沒顯示在webview上，并一次性處理界面交互和數(shù)據(jù)更新。

這樣用一套框架去限制修改的新，重塑一層DSL，除此之外管控外還有一個一個好處，應(yīng)該是太容易參與針對性優(yōu)化，DSL結(jié)果轉(zhuǎn)成什么，到了最后如何執(zhí)行軟件渲染都由框架確定，上層不五感，這個可以制作成由webview渲染，有條件也是可以用類似RN的方案自己基于軟件渲染層。

JS環(huán)境

按照框架限定開發(fā)后，管控上有個問題，那就是該如何取消應(yīng)用端類JS語言調(diào)用domAPI？小程序跑在webview上，渲出時(shí)必定要是從JS操作dom，要是小程序框架和應(yīng)用JS代碼都是權(quán)限操作dom，應(yīng)用可能會實(shí)際各種在上游戲后繞到檢查，涌入JS調(diào)用dom接口去直接修改頁面結(jié)構(gòu)和內(nèi)容，變的跟審核時(shí)不一樣的應(yīng)用。怎樣才能能取消應(yīng)用方法的JS動態(tài)創(chuàng)建dom的權(quán)限？想了個比較比較做創(chuàng)新的解決方案，那就是：JS運(yùn)行環(huán)境與瀏覽器分離出來，運(yùn)行在另的JS引擎上。

沖出了瀏覽器，JS自然沒有dom的內(nèi)部函數(shù)權(quán)限，任何跟webview界面相關(guān)的API都無法搞到。而小程序框架核心JS啟動在webview上，可以不契約能操作dom，是從小程序框架符號表示的機(jī)制，應(yīng)用端實(shí)際wxml/wxss定義固定不動的軟件渲染樣式，JS端自有打算數(shù)據(jù)手機(jī)綁定，數(shù)據(jù)可以按照restful橋梁從JS引擎?zhèn)鬟f到webview，JS端不能做任何渲染相關(guān)的你的操作，也可以對顏色渲染的內(nèi)容有求下載的管控權(quán)。

單獨(dú)的的JS運(yùn)行環(huán)境除了不滿足管控需求外，也額外給了一些好處和一些壞處，好處在于：

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

JS與頁面3d渲染分離聯(lián)成一體負(fù)責(zé)執(zhí)行，肯定不會會出現(xiàn)JS想執(zhí)行時(shí)卡住了頁面3d渲染的情況，提升到3d渲染性能。

壞處在于：

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

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

導(dǎo)致管控需求太過剛需，這個方案給他壞處也可以認(rèn)可。

體驗(yàn)

小程序最主要的兩個技術(shù)點(diǎn)—框架和JS不運(yùn)行分離出來全是來于管控需求，而體驗(yàn)上的需求應(yīng)該是由各種精細(xì)入微的性能優(yōu)化排成了，很多文章也講過，這里簡單說下，和：

離線模式包：整個小程序發(fā)到郵箱印發(fā)的通知，不必須先打開每個頁面都去只是請求，增加倆次打開時(shí)間和頁面切換到時(shí)間。

預(yù)加載：預(yù)加載多一個wkwebview放后臺，用戶先打開小程序時(shí)會省重新初始化wkwebview時(shí)間。同時(shí)對于一個小程序內(nèi)的頁面直接切換，之福于框架的設(shè)計(jì)，可以不能做到預(yù)顏色渲染模板，切換到時(shí)再填充后數(shù)據(jù)，快速渲染速度。

緩存：再次小程序后不可能立刻全部銷毀，會在后臺一直跑5分鐘，這段用戶切回小程序時(shí)速度快。

視覺：小程序2002年運(yùn)行程序是從loading和動畫的過渡，回絕白屏，給人一種名為快的感覺，而進(jìn)階了小程序的標(biāo)識度。

剩下的應(yīng)該是圍繞小程序這個平臺的周邊大力建設(shè)了，像組件，context接口，IDE，后臺管理，版本管理，權(quán)限控制等基礎(chǔ)支持。

支付寶小程序

策略

小程序很快推出時(shí)通常面向的場景是線下，希望商家能開發(fā)小程序，做像點(diǎn)完菜拿票這樣的即時(shí)性應(yīng)用，實(shí)力提升線下商戶體驗(yàn)，支付寶充當(dāng)線下戰(zhàn)場的比較多競爭對手肯定要去協(xié)助。

支付寶能做小程序應(yīng)該怎樣做？這個可以根據(jù)自身的情況，定義另一套技術(shù)體系，讓第三方接入。但這樣的話第三方如果不是要另外接入和支付寶，是需要開發(fā)完畢兩套程序，成本很高，而有再發(fā)和平臺優(yōu)勢，很肯定變成只開發(fā)小程序而放棄接入支付寶小程序，所以才好是的做法是降低這里的接入成本，讓小程序的代碼可以分時(shí)復(fù)用在支付寶小程序上。所以我小程序聯(lián)合的框架/API/組件必須是跟小程序距離或力求一致，技術(shù)上沒得中,選擇，所以才可以清晰的看到支付寶小程序公測版的文檔很多跟相同。

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

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

React Native

除此之外作為的跟同一的web版小程序，內(nèi)部一直在在一段時(shí)間React Native版小程序，3d渲染層不區(qū)分webview，而是用RN去渲染，進(jìn)階性能和體驗(yàn)，這確實(shí)是小程序DSL層很大，底層渲染引擎也可以很方便啊地全部替換實(shí)現(xiàn)方法方案，甚至于同樣必然多套方案。

很多人問為啥不用weex，按我解釋簡單的方法是螞蟻的前端技術(shù)?；趓eact，快速切換成本高，另一個RN相對于weex成熟度高，社區(qū)意見度高，并保持著不未停的更新，相對客氣禮貌。

RN本身不跨平臺支持，iOS/Android有各自的寫法，在RN的使用上，業(yè)界很多人各自實(shí)現(xiàn)了基于組件RN的跨三端或兩端的開發(fā)（的或JDReact），也就是四次開發(fā)，能另外允許RN在iOS/Android平行放置做原生渲染，也支持fallback到webview渲染。這里小程序也可以算這樣的一套方案，上層可以自定義DSL開發(fā)業(yè)務(wù)，防御部署時(shí)實(shí)際工具共有可以轉(zhuǎn)換成三個平臺不同的代碼，在三個平臺不運(yùn)行。

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

小程序是一套聯(lián)合的方案，要注意應(yīng)用于第三方應(yīng)用接入，因?yàn)樯衔囊舱f了，框架上很多技術(shù)方案大都目的是滿足對第三方管控和安全方面的需求，而小程序相關(guān)的很多再體驗(yàn)優(yōu)化軟件其功能多純H5也也可以可以做到，內(nèi)部業(yè)務(wù)用web版小程序開發(fā)卻沒給他什么好處，不但增加學(xué)習(xí)成本。但RN版小程序是一樣的，它有一些優(yōu)勢，除了：

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

相對于只不過是不使用RN開發(fā)，在用小程序可以不被屏蔽平臺差異，實(shí)現(xiàn)方法跨平臺三次開發(fā)。

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

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

基于這些原因，在騰訊理財(cái)通這邊一些內(nèi)部原本應(yīng)該是使用H5實(shí)現(xiàn)的業(yè)務(wù)，也正嘗試大量地建議使用小程序?qū)崿F(xiàn)方法，以提升用戶體驗(yàn)，目前部分基于條件小程序RN版開發(fā)的業(yè)務(wù)已萬分感謝上穩(wěn)定運(yùn)行，強(qiáng)盜團(tuán)也會不再接觸把小程序RN版堅(jiān)持了鍛鑄成高性能穩(wěn)定的三端統(tǒng)一動態(tài)化方案。