最近在看小程序相關,從技術角度來看小程序在Hybrid的優化過程有不少值得咱們學習的地方,因此我想在學習的同時也能有所輸出,在這個系列我不會講怎麼去申請一個小程序,怎麼去開發一個程序,而是講從小程序咱們能學到什麼,儘管它如今還存在不少問題,但大範圍的使用會推進小程序將微信技術生態作到極致,使用到Hybrid技術的公司很是多,但願個人系列文章能對你們有所幫助。javascript
從技術的角度來看,其實微信的頁面技術是小程序的前身,以下圖。css
在微信裏面的網頁,能夠經過JS-SDK來調用微信native,讓開發者使用到微信的原生能力,當JS-SDK公佈後受到不少開發者的歡迎,但隨着普遍的使用,開發者們又遇到了不少問題。html
用戶在手機訪問微信的一個h5,因爲移動設備的限制和網絡速度,都會有一個明顯的白屏。
微信團隊用了不少精力來解決這個問題,就出現了後面的JS-SDK加強版,這裏面有個比較重要的功能就是:離線存儲。 離線存儲簡單的理解就是從本地加載web資源而再也不從服務端拉取,從而避免網絡速度的瓶頸。
離線存儲下降了網絡延時大大提升了h5的用戶體驗,但在一些複雜的頁面依然會有白屏的問題,這裏主要是js和css的複雜性會佔用大量的UI線程而影響WebView的渲染。
其實目前大部分公司使用的是相似JS-SDK方案:靈活的網頁開發+ 豐富的原生功能 + 離線存儲。前端
有些團隊使用SPA框架來模擬native的原生頁面切換,但SPA也有本身的弊端,隨着業務的複雜,頗有可能讓WebView的負擔愈來愈大,並且作到這一點須要開發者有足夠的時間和精力。java
對攻擊防不勝防,瀏覽器下的js是很是靈活,能夠對Dom和Bom隨意操做,能夠隨意跳轉,能夠動態執行等等。web
因此,微信可否解決之上的問題呢,微信的頁面是否能作到如下:小程序
這就是小程序。api
小程序若是想解決以前純網頁技術的一些問題,必需要作一些新的嘗試瀏覽器
要達到快速的加載和流暢的體驗,是否是直接基於微信的客戶端開發就Ok了呢?但這有個問題,這麼作意味着小程序的代碼須要和微信客戶端代碼一塊兒發佈,這種節奏確定沒法知足的。安全
RN雖然用javascript解釋執行,但渲染方面仍是Native渲染,其實RN能解決加載和渲染的問題,但它也仍然有些不足,這裏引用微信官方給的緣由
純h5有不少弊端,純Native又不可能知足發版的需求,RN又不是很成熟,因此最終微信在面對本身的技術生態下對小程序的選型仍是Hybrid,界面由成熟的Web技術渲染,邏輯由成熟的Js解析和執行,再加上微信Native提供的原生能力。但要實現之上所說的需求,小程序仍是須要基於Hybrid作突破。
雙線程:小程序的邏輯層與渲染層是分開兩個線程, 邏輯層的js用到Native自身的JSCore來解析和執行,而界面仍是經過WebView來渲染。通訊過程以下圖(圖片來自微信官方文檔,侵刪):
通常的Hybrid技術,WebView既作js解析和執行,還要渲染html和css,當頁面比較複雜時,頗有可能出現界面的渲染等待JS的執行從而形成白屏現象,咱們用雙線程能夠下降Webview的負擔,在複雜的頁面交互裏能夠並行js執行與界面渲染。 另外Native的Jscore僅僅只是實現了ECMAScript標準,它不像瀏覽器還須要實現DOM與BOM,因此在小程序裏經過js沒法操做dom,沒法使用BOM,這也在必定程度上解決了安全和管控的問題。
如上所說,小程序的javascript是由JSCore來實現ECMAScript,除了這個以外小程序還提供了一個框架和一系列api,這些底層的升級是與微信客戶端的升級同步的。
(圖片來自微信官方文檔,侵刪):
總結
微信頁面以及小程序的技術體系其實與大多數公司一致,但微信作爲一個平臺會將安全與性能作到極致,雖然大部分公司不須要作到微信這種平臺體量,但它的技術演進仍是能給咱們不少借鑑,好比咱們能夠也用多個WebView嗎?咱們也能夠用雙線程嗎?咱們也能夠作WebView預加載嗎?咱們也能作微信開發者工具嗎?接下來咱們也會漸漸結合咱們自身的業務場景繼續和你們分享。
因爲第一篇爲了給後面的知識內容作些準備,因此用到了微信官網的一些內容和圖片,特此說明,侵刪。
參考文獻:小程序開發指南
如想閱讀更多文章,能夠關注咱們的微信公衆號:大前端工程師