使用小程序框架(Taro)進行多端開發的實踐

前言

小程序是一種基於App微信的web化解決方案，規範由微信開發團隊定製

h5是指基於HTML5標準的技術，依賴於ECMAScript與w3c規範

請不要將h5和小程序混爲一談

僅僅從開發者的角度來看，小程序把web社區的各類成果和標準私有化，是違反發展趨勢的

背景

雖然使用Taro進行多端開發，可是本文與taro關係不大，主要探究小程序與h5的差別化，還有先後端配合上的須要注意的事項

小程序與h5原理的不一樣

渲染方式不一樣

h5的加載徹底受限於網絡，加載不出來就會出現長時間白屏的狀況

小程序使用的是雙線程模式，一個線程處理頁面，一個線程處理數據，因此在網絡很差的狀況下，也能很快的顯示出頁面，後面再逐漸完成數據的請求，具體請看渲染層和邏輯層

運行環境的不一樣

H5的運行環境是瀏覽器，包括webview，而微信小程序的運行環境並不是完整的瀏覽器，由於小程序的開發過程當中只用到一部分H5技術。

小程序的運行環境是微信開發團隊基於瀏覽器內核徹底重構的一個內置解析器，針對性作了優化，配合本身定義的開發語言標準，提高了小程序的性能。

官方文檔代表腳本內沒法使用瀏覽器中經常使用的window對象和document對象，因此dom操做類框架都沒法在小程序類使用(例如jquery)

開發成本不一樣

H5 的開發，涉及開發工具（vscode、Atom等）、前端框架（Vue、react等）、模塊管理工具（Webpack 、Browserify 等）、任務管理工具（Grunt、Gulp等），還有UI庫選擇、接口調用工具（ajax、Fetch Api等）、瀏覽器兼容性等等。這方面須要考慮的比小程序須要考慮的多得多

而微信小程序開發，因爲微信團隊提供了開發者工具，而且規範了開發標準，則簡單得多。

前端常見的HTML、CSS變成了微信自定義的WXML、WXSS，WXML，官方文檔中都有明確的使用介紹

須要調用後端接口時，調用發起請求API；

須要上傳下載時，調用上傳下載API；

須要數據緩存時，調用本地存儲API；

引入地圖、使用羅盤、調用支付、調用掃碼等等功能均可以直接使用；

UI庫方面，框架帶有自家weui庫加成。

而且在使用這些API時，不用考慮瀏覽器兼容性，不用擔憂出現BUG，只須要考慮對手機不一樣型號的適配，顯而易見微信小程序的開發成本相對較低。

小程序與h5開發上的不一樣

開發工具不一樣

h5的開發工具無要求+瀏覽器調試工具便可

小程序有本身獨有的開發工具，對於調試，編譯，預覽，上傳，發佈都有本身的一套方案

開發語言不一樣

h5端爲 HTML+CSS+JavaScript

小程序端爲 WXML + WXSS + ECMAScript(不包含BOM，DOM)

組件封裝不一樣

h5全部的組件，例如，底部下拉框，導航欄，全部視圖相關都是須要寫，或者使用開源產品

小程序自帶不少APP組件，就例如h5的alert，可是小程序封裝了不少，例如picker(底部彈出框)，swiper(輪播圖)，showModal(彈窗)，等等

標籤寫法不一樣

h5端依照html5規範 爲div span p input img 等等

小程序是自身設計的一套標籤語言 爲 view text input image等高級組件，標籤與html不徹底相同

相信到這裏，明顯能夠感受到，小程序與h5看似是一個東西，可是具體上存在巨大的差別，基本至關於

h5 與 android的關係

路由配置不一樣

h5端對於路由無任何限制，不使用任何框架的傳統網頁只要資源存在都是能夠跳轉過去

小程序須要根目錄下的 app.json 文件用來對微信小程序進行全局配置，決定頁面文件的路徑、窗口表現、設置網絡超時時間、設置多 tab 等。

等等........................

其餘細節請看文檔說明小程序與普通網頁開發的區別

先後端交互上與h5的不一樣(重點)

先後端交互主要在於對請求方面的h5與小程序api的分析

這方面文檔並無進行詳細說明，如下資料爲收集與實踐得出

小程序全部請求的api都不支持cookie機制

這個觀點很是遺憾在官方文檔裏面怎麼也找不到相關說明，只能看到小程序登陸裏面手動把自定義請求頭帶給了後臺，從而推論出小程序不支持cookie機制，這也是與h5第一個比較的大的差別，就像登陸必須用戶手動觸發同樣，這一系列規範開發者沒法控制

小程序request與h5(xhr請求)獲取的請求頭不一致

小程序的請求中不會處理後端返回的response header裏面的信息

能夠明顯看到獲取到了後端返回到的全部response header，這一點與w3c規範徹底不相同

咱們再看看相同的接口，在h5裏面返回的信息

h5的請求中嚴格按照w3c規範，對response header的信息進行了嚴格的控制，經過查閱資料瞭解到如下規範

1. 按照 W3C 規範，H5 端沒法獲取 response header 中 Set-Cookie、Set-Cookie2 這2個字段，對於跨域請求，容許獲取的 response header 字段只限於「simple response header」和「Access-Control-Expose-Headers」**（詳情）

2. 在使用CORS解決跨域的請求中，默認只能取到

   Content-Language Content-Type Expires Last-Modified Pragma 五個reponse header 值。

   若是想獲取到其餘的值，須要服務器在header中設置

   Access-Control-Expose-Headers : sessionID ， key1 ， key2

爲何上面h5的請求中存在session呢?

由於在後端的請求頭裏面加了Access-Control-Expose-Headers : session

只有這樣前端h5才能在使用cors解決跨域的狀況下獲取到後端的請求頭裏面的參數，不然h5這邊是沒法獲取到response header裏面的信息

這一點實踐了，fetch，axios，這樣最主流的請求方式與請求庫

也實踐了jquery的**$ajax**，由於他們在瀏覽器環境遵循w3c標準，因此得出的結果與以上理論一致

能夠看到並不存在set-cookie的請求頭

因此爲了同時知足h5與小程序的多端開發，就須要各方面向下兼容

1. 不使用w3c的cookie的方式，使用小程序的手動帶給後端
2. 不使用小程序返回的response header，由於須要兼容h5使用xhr的規範

從而獲得當前階段或許是最好的解決方案 自定義一個token，並設置Access-Control-Expose-Headers : token，這樣就同時保證了h5與小程序，並統一了開發流程

上傳文件上h5與小程序的不一樣

先後端分離的狀況下 h5 使用xhr請求，定義請求頭爲multipart/form-data，便可上傳文件到服務端

小程序使用的是wx.uploadFile，無其餘參數設置

可是，這兩個上傳文件獲取的結果卻不一樣

h5

小程序

這裏h5與微信小程序的api存在差別，因此後端須要在上傳文件這個api須要按照微信這種方式來進行接口開發

開發細節上的不一樣

使用taro編譯成h5以後，h5不存在頭部導航欄

解決方案爲自定義頭部導航欄 這一點uniapp彷佛作得好一點

小程序的主頁面視口與h5不同

小程序主頁面的可操做區域不包含頭部，底部導航欄

可是h5不論什麼頁面可操做區域是包含頭部，底部導航欄，這一點開發中須要作平臺代碼判斷，以避免出現頁面錯亂的狀況

​ 由於就像最開始的那句話，微信未遵循w3c定製的規範，而是用web領域多年的發展自成體系並商業化，因此出現了這種看似與h5一致，實際上存在不少規範不同的的狀況，做爲開發者，若是須要同時徹底雙端的任務，最好的解決辦法就是取其交集，這樣才能保證任務的同時，還不影響開發進度