【微信小程式專案實踐總結】30分鐘從陌生到熟悉

發表於2018-08-13

前言

我們之前對小程式做了基本學習:

1. 微信小程式開發07-列表頁面怎麼做

2. 微信小程式開發06-一個業務頁面的完成

3. 微信小程式開發05-日曆元件的實現

4. 微信小程式開發04-打造自己的UI庫

5. 微信小程式開發03-這是一個元件

6. 微信小程式開發02-小程式基本介紹

7. 微信小程式開發01-小程式的執行流程是怎麼樣的?

閱讀本文之前,如果大家想對小程式有更深入的瞭解,或者一些細節的瞭解可以先閱讀上述文章,本文後面點需要對著程式碼除錯閱讀

對應的github地址是:https://github.com/yexiaochai/wxdemo

首先我們來一言以蔽之,什麼是微信小程式?PS:這個問題問得好像有些扯:)

小程式是一個不需要下載安裝就可使用的應用,它實現了應用觸手可及的夢想,使用者掃一掃或者搜一下即可開啟應用。也體現了用完即走的理念,使用者不用關心是否安裝太多應用的問題。應用將無處不在,隨時可用,但又無需安裝解除安裝。從字面上看小程式具有類似Web應用的熱部署能力,在功能上又接近於原生APP。

所以說,其實微信小程式是一套超級Hybrid的解決方案,現在看來,小程式應該是應用場景最廣,也最為複雜的解決方案了

很多公司都會有自己的Hybrid平臺,我這裡瞭解到比較不錯的是攜程的Hybrid平臺、阿里的Weex、百度的糯米,但是從應用場景來說都沒有微信來得豐富,這裡根本的區別是:

微信小程式是給各個公司開發者接入的,其他公司平臺多是給自己業務團隊使用,這一根本區別,就造就了我們看到的很多小程式不一樣的特性:

① 小程式定義了自己的標籤語言WXML

② 小程式定義了自己的樣式語言WXSS

③ 小程式提供了一套前端框架包括對應Native API

④ 禁用瀏覽器Dom API(這個區別,會影響我們的程式碼方式)

只要瞭解到這些區別就會知道為什麼小程式會這麼設計:

之前我也有一個疑惑為什麼微信小程式會設計自己的標籤語言,也在知乎看到各種各樣的回答,但是如果出於設計層面以及應用層面考慮的話:這樣會有更好的控制,而且我後面發現微信小程式事實上依舊使用的是webview做渲染(這個與我之前認為微信是NativeUI是向左的),但是如果我們使用的微信限制下面的標籤,這個是有限的標籤,後期想要換成NativeUI會變得更加輕易:

另一方面,經過之前的學習,我這邊明確可以得出一個感受:

小程式的頁面核心是標籤,標籤是不可控制的(我暫時沒用到js操作元素的方法),只能按照微信給的玩法玩,標籤控制顯示是我們的view

② 標籤的展示只與data有關聯,和js是隔離的,沒有辦法在標籤中呼叫js的方法

③ 而我們的js的唯一工作便是根據業務改變data,重新引發頁面渲染,以後別想操作DOM,別想操作Window物件了,改變開發方式,改變開發方式,改變開發方式!

然後可以看到這個是一個MVC模型

每個頁面的目錄是這個樣子的:

每個元件的目錄也大概是這個樣子的,大同小異,但是入口是Page層。

小程式打包後的結構(這裡就真的不懂了,引用:小程式底層框架實現原理解析):

所有的小程式基本都最後都被打成上面的結構

1、WAService.js  框架JS庫,提供邏輯層基礎的API能力

2、WAWebview.js 框架JS庫,提供檢視層基礎的API能力

3、WAConsole.js 框架JS庫,控制檯

4、app-config.js 小程式完整的配置,包含我們通過app.json裡的所有配置,綜合了預設配置型

5、app-service.js 我們自己的JS程式碼,全部打包到這個檔案

6、page-frame.html 小程式檢視的模板檔案,所有的頁面都使用此載入渲染,且所有的WXML都拆解為JS實現打包到這裡

7、pages 所有的頁面,這個不是我們之前的wxml檔案了,主要是處理WXSS轉換,使用js插入到header區域

從設計的角度上說,小程式採用的元件化開發的方案,除了頁面級別的標籤,後面全部是元件,而元件中的標籤view、data、js的關係應該是與page是一致的,這個也是我們平時建議的開發方式,將一根頁面拆分成一個個小的業務元件或者UI元件:

從我寫業務程式碼過程中,覺得整體來說還是比較順暢的,小程式是有自己一套完整的前端框架的,並且釋放給業務程式碼的主要就是page,而page只能使用標籤和元件,所以說框架的對業務的控制力度很好。

最後我們從工程角度來看微信小程式的架構就更加完美了,小程式從三個方面考慮了業務者的感受:

① 開發工具+除錯工具

② 開發基本模型(開發基本標準WXML、WXSS、JS、JSON)

③ 完善的構建(對業務方透明)

④ 自動化上傳離線包(對業務費透明離線包邏輯)

⑤ 監控統計邏輯

所以,微信小程式從架構上和使用場景來說是很令人驚豔的,至少驚豔了我……所以我們接下來在開發層面對他進行更加深入的剖析,我們這邊最近一直在做基礎服務,這一切都是為了完善技術體系,這裡對於前端來說便是我們需要做一個Hybrid體系,如果做App,React Native也是不錯的選擇,但是一定要有完善的分層:

① 底層框架解決開發效率,將複雜的部分做成一個黑匣子,給頁面開發展示的只是固定的三板斧,固定的模式下開發即可

② 工程部門為業務開發者封裝最小化開發環境,最優為瀏覽器,確實不行便為其提供一個類似瀏覽器的除錯環境

如此一來,業務便能快速迭代,因為業務開發者寫的程式碼大同小異,所以底層框架配合工程團隊(一般是同一個團隊),便可以在底層做掉很多效率效能問題。

稍微大點的公司,稍微寬裕的團隊,還會同步做很多後續的效能監控、錯誤日誌工作,如此形成一套文件->開發->除錯->構建->釋出->監控、分析 為一套完善的技術體系

如果形成了這麼一套體系,那麼後續就算是內部框架更改、技術革新,也是在這個體系上改造,這塊微信小程式是做的非常好的。但很可惜,很多其他公司團隊只會在這個路徑上做一部分,後面由於種種原因不在深入,有可能是感覺沒價值,而最恐怖的行為是,自己的體系沒形成就貿然的換基礎框架,戒之慎之啊!好了閒話少說,我們繼續接下來的學習。

我對小程式的理解有限,因為沒有原始碼只能靠驚豔猜測,如果文中有誤,請各位多多提點

文章更多面對初中級選手,如果對各位有用,麻煩點贊喲

微信小程式的執行流程

微信小程式為了對業務方有更強的控制,App層做的工作很有限,我後面寫demo的時候根本沒有用到app.js,所以我這裡認為app.js只是完成了一個路由以及初始化相關的工作,這個是我們看得到的,我們看不到的是底層框架會根據app.json的配置將所有頁面js都準備好。

我這裡要表達的是,我們這裡配置了我們所有的路由:

微信小程式一旦載入,會開3個webview,裝載3個頁面的邏輯,完成基本的例項化工作,只顯示首頁!這個是小程式為了優化頁面開啟速度所做的工作,也勢必會浪費一些資源,所以到底是全部開啟或者預載入幾個,詳細底層Native會根據實際情況動態變化,我們也可以看到,從業務層面來說,要了解小程式的執行流程,其實只要能瞭解Page的流程就好了,關於Page生命週期,除了釋放出來的API:onLoad -> onShow -> onReady -> onHide等,官方還出了一張圖進行說明:

Native層在載入小程式時候,起了兩個執行緒一個的view Thread一個是AppService Thread,我這邊理解下來應該就是程式邏輯執行與頁面渲染分離,小程式的檢視層目前使用 WebView 作為渲染載體,而邏輯層是由獨立的 JavascriptCore 作為執行環境。在架構上,WebView 和 JavascriptCore 都是獨立的模組,並不具備資料直接共享的通道。當前,檢視層和邏輯層的資料傳輸,實際上通過兩邊提供的 evaluateJavascript 所實現。即使用者傳輸的資料,需要將其轉換為字串形式傳遞,同時把轉換後的資料內容拼接成一份 JS 指令碼,再通過執行 JS 指令碼的形式傳遞到兩邊獨立環境。而 evaluateJavascript 的執行會受很多方面的影響,資料到達檢視層並不是實時的。

因為之前我認為頁面是使用NativeUI做渲染跟Webview沒撒關係,便覺得這個圖有問題,但是後面實際程式碼看到了熟悉的shadow-dom以及Android可以看到哪部分是Web的,其實小程式主體還是使用的瀏覽器渲染的方式,還是webview裝載HTML和CSS的邏輯,最後我發現這張圖是沒有問題的,有問題的是我的理解,哈哈,這裡我們重新解析這張圖:

WXML先會被編譯成JS檔案,引入資料後在WebView中渲染,這裡可以認為微信載入小程式時同時初始化了兩個執行緒,分別執行彼此邏輯:

① WXML&CSS編譯形成的JS View例項化結束,準備結束時向業務執行緒傳送通知

② 業務執行緒中的JS Page部分同步完成例項化結束,這個時候接收到View執行緒部分的等待資料通知,將初始化data資料傳送給View

③ View執行緒接到資料,開始渲染頁面,渲染結束執行通知Page觸發onReady事件

這裡翻開原始碼,可以看到,應該是全域性控制器完成的Page例項化,完成後便會執行onLoad事件,但是在執行前會往頁面發通知:

真實的邏輯是這樣的,全域性控制器會完成頁面例項化,這個是根據app.json中來的,全部完成例項化儲存起來然後選擇第一個page例項執行一些邏輯,然後通知view執行緒,即將執行onLoad事件,因為view執行緒和業務執行緒是兩個執行緒,所以不會造成阻塞,view執行緒根據初始資料完成渲染,而業務執行緒繼續後續邏輯,執行onLoad,如果onLoad中有setData,那麼會進入佇列繼續通知view執行緒更新。

所以我個人感覺微信官網那張圖不太清晰,我這裡重新畫了一個圖:

引用一張其他地方的圖

模擬實現

都這個時候了,不來個簡單的小程式框架實現好像有點不對,我們做小程式實現的主要原因是想做到一端程式碼三端執行:web、小程式、Hybrid甚至Servce端

我們這裡沒有可能實現太複雜的功能,這裡想的是就實現一個基本的頁面展示帶一個最基本的標籤即可,只做Page一塊的簡單實現,讓大家能瞭解到小程式可能的實現,以及如何將小程式直接轉為H5的可能走法

我們直接將小程式這些程式碼拷貝一份到我們的目錄:

我們需要做的就是讓這段程式碼執行起來,而這裡的目錄是我們最終看見的目錄,真實執行的時候可能不是這個樣,執行之前專案會通過我們的工程構建,變成可以直接執行的程式碼,而我這裡思考的可以執行的程式碼事實上是一個模組,所以我們這裡從最終結果反推、分拆到開發結構目錄,我們首先將所有程式碼放到index.html,可能是這樣的:

這段程式碼,非常簡單:

① 設定了一段模板,甚至,我們這裡根本不關係其格式化狀態,直接寫成一行方便處理

② 然後我們將這段模板轉為node節點(這裡可以不用zepto,但是模擬實現怎麼簡單怎麼來吧),然後遍歷處理所有節點,我們就可以處理我們的資料了,最終形成了這個html:

③ 與此同時,我們儲存了一個物件,這個物件包含所有與之相關的節點:

這個物件是所有setData會影響到node的一個對映表,後面呼叫setData的時候,便可以直接操作對應的資料了,這裡我們分拆我們程式碼,形成了幾個關鍵部分,首先是View類,這個對應我們的模板,是核心類:

這個類主要完成的工作是:

① 接受傳入的template字串(直接由index.wxml讀出)

② 解析template模板,生成字串和兼職與node對映表,方便後期setData導致的改變

③ 渲染和再次渲染工作

然後就是我們的Page類的實現了,這裡反而比較簡單(當然這裡的實現是不完善的):

現在輪著我們實際呼叫方,Page方法出場了:

基本上什麼都沒有乾的感覺,呼叫層程式碼這樣寫:

於是,我們可以看到頁面的變化,由開始的初始化頁面到執行onLoad時候的變化:

這裡是最終完整的程式碼:

我們簡單的模擬便先到此結束,這裡結束的比較倉促有一些原因:

① 這段程式碼可以是最終打包構建形成的程式碼,但是我這裡的完成度只有百分之一,後續需要大量的構建相關介入

② 這篇文章目的還是接受開發基礎,而本章模擬實現太過複雜,如果篇幅大了會主旨不清

③ 這個是最重要的點,我一時也寫不出來啊!!!,所以各位等下個長篇,小程式前端框架模擬實現吧

④ 如果繼續實現,這裡馬上要遇到元件處理、事件模型、分檔案構建等高階知識,時間會拉得很長

所以我們繼續下章吧……

小程式中的Page的封裝

小程式的Page類是這樣寫的:

傳入的是一個物件,顯然,我們為了更好的拆分頁面邏輯,前面我們介紹了小程式是採用元件化開發的方式,這裡的說法可以更進一步,小程式是採用標籤化的方式開發,而標籤對應的控制器js只會改變資料影響標籤顯示,所以某種程度小程式開發的特點是:先標籤後js,我們構建一個頁面,首先就應該思考這個頁面有哪些標籤,哪些標籤是公共的標籤,然後設計好標籤再做實現。

比如我們一個頁面中有比較複雜的日曆相關模組,事實上這個日曆模組也就是在操作日曆標籤的資料以及設定點選回撥,那麼我們就需要將頁面分開

比如這裡的業務日曆模組僅僅是index的一部分(其他頁面也可能用得到),所以我們實現了一個頁面共用的記錄,便與我們更好的分拆頁面:

其中頁面會用到的一塊核心就是:

呼叫方式是:

可以看到,其他元件,如這裡的日曆模組只是一個物件而已:

但是在程式碼層面卻幫我們做到了更好的封裝,這個基類裡面還包括我們自定義的常用元件,loading、toast等等:

page是最值得封裝的部分,這裡是基本page的封裝,事實上,列表頁是常用的一種業務頁面,雖然各種列表頁的篩選條件不一樣,但是主體功能無非都是:

① 列表渲染

② 滾動載入

③ 條件篩選、重新渲染

所以說我們其實可以將其做成一個頁面基類,跟abstract-page一個意思,這裡留待我們下次來處理吧

小程式中的元件

請大家對著github中的程式碼除錯閱讀這裡

前面已經說了,小程式的開發重點是一個個的標籤的實現,我們這裡將業務元件設定成了一個個mod,UI元件設定成了真正的標籤,比如我們頁面會有很多非業務類的UI元件:

① alert類彈出層

② loading類彈出層

③ 日曆元件

④ toast&message類提示彈出元件

⑤ 容器類元件

⑥ ……

這些都可以我們自己去實現,但是微信其實提供給我們了系統級別的元件:

這裡要不要用就看實際業務需求了,一般來說還是建議用的,我們這裡為了幫助各位更好的瞭解小程式元件,特別實現了一個較為複雜,而小程式又沒有提供的元件日曆元件,首先我們這裡先建立一個日曆元件目錄:

其次我們這裡先做最簡單實現:

日曆結構部分程式碼

這個是非常簡陋的日曆雛形,在程式碼過程中有以下幾點比較痛苦:

① WXML與js間應該只有資料傳遞,根本不能傳遞方法,應該是兩個webview的通訊,而日曆元件這裡在WXML層由不得不寫一點邏輯

② 本來在WXML中寫邏輯已經非常費勁了,而我們引入的WXS,使用與HTML中的js片段也有很大的不同,主要體現在日期操作

這些問題,一度讓程式碼變得複雜,而可以看到一個簡單的元件,還沒有複雜功能,涉及到的檔案都太多了,這裡頁面呼叫層引入標籤後:

日曆的基本頁面就出來了:

這個日曆元件應該是在小程式中寫的最複雜的元件了,尤其是很多邏輯判斷的程式碼都放在了WXML裡面,根據之前的瞭解,小程式渲染在一個webview中,js邏輯在一個webview中,他這樣做的目的可能是想讓效能更好,這種UI元件使用的方式一般是直接使用,但是如果涉及到了頁面業務,便需要獨立出一個mod小模組去操作對應元件的資料,如圖我們這裡的日曆元件一般

於是程式碼便非常好拆分了,這裡請各位對比著github中的程式碼閱讀,最終使用效果:

小程式中的資料請求與快取

小程式使用這個介面請求資料,這裡需要設定域名白名單:

可以看到資料請求已經回來了,但是我們一般來說一個介面不止會用於一個地方,每次重新寫好像有些費事,加之我這裡想將重複的請求快取起來,所以我們這裡封裝一套資料訪問層出來

之前在瀏覽器中,我們一般使用localstorage儲存一些不太更改的資料,微信裡面提供了介面處理這一切:

我們這裡需要對其進行簡單封裝,便與後面更好的使用,一般來說有快取就一定要有過期,所以我們動態給每個快取物件增加一個過期時間:

這個類的使用也非常簡單,這裡舉個例子:

這個時候我們開始寫我們資料請求的類:

首先還是實現了一個抽象類和一個業務基類,然後開始在業務層請求資料:

這裡是業務基類的使用辦法:

接下來是實際呼叫程式碼:

資料便請求結束了,有了這個類我們可以做非常多的工作,比如:

① 前端設定統一的錯誤碼處理邏輯

② 前端打點,統計所有的介面響應狀態

③ 每次請求相同引數做資料快取

④ 這個對於錯誤處理很關鍵,一般來說前端出錯很大可能都是後端資料介面欄位有變化,而這種錯誤是比較難尋找的,如果我這裡做一個統一的收口,每次資料返回記錄所有的返回欄位的標誌上報呢,就以這個城市資料為例,我們可以這樣做:

這裡就會輸出以下資訊:

如果對資料要求非常嚴苛,對某些介面做到欄位層面的驗證,那麼加一個Validates驗證即可,這樣對介面的控制會最大化,就算哪次出問題,也能很好從資料分析系統之中可以檢視到問題所在,如果我現在想要一個更為具體的功能呢?我想要首次請求一個介面時便將其資料記錄下來,第二次便不再請求呢,這個時候我們之前設計的資料持久層便派上了用處:

這個時候第二次請求時候便會直接讀取快取了

結語

如果讀到這裡,我相信大家應該清楚了,30分鐘當然是騙人的啦。。。。。。別說三十分鐘了,三個小時這些東西都讀不完,對於初學者的同學建議把程式碼下載下來一邊除錯一邊對著這裡的文章做思考,這樣3天左右便可以吸收很多微信小程式的知識

寫這篇文章說實話還比較辛苦,近期小釵這邊工作繁忙,有幾段都是在和老闆開會的時候偷偷寫的……,所以各位如果覺得文章還行麻煩幫忙點個贊

總結起來基本還是那句話,微信小程式從架構工程層面十分值得學習,而我這邊不出意外時間允許會深入的探索前端框架的實現,爭取實現一套能相容小程式和web同時執行的程式碼

我們實際工作中會直接使用上面的程式碼,也會使用一些比較成熟的框架比如:https://tencent.github.io/wepy/,用什麼,怎麼做單看自己團隊專案的需求

我們在學習過程中做了一個實際的專案,完成度有60%,實際工作中便只需要完善細節即可,我這裡便沒有再加強,一來是時間不足,二來是純粹業務程式碼只會讓學習的程式碼變得複雜,沒什麼太大的必要,希望對初學者有一定幫助:

相關文章