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

手機白屏一閃一閃是什么原因？

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

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

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

小程序

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

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

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

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

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

管控

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

框架/DSL

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

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

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

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

JS環(huán)境

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

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

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

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

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

壞處在于：

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

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

導致管控需求太過剛需，這個方案給他壞處也可以認可。

體驗

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

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

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

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

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

剩下的應該是圍繞小程序這個平臺的周邊大力建設了，像組件，context接口，IDE，后臺管理，版本管理，權限控制等基礎支持。

支付寶小程序

策略

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

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

實現(xiàn)方法

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

React Native

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

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

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

內部應用

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

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

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

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

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

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