我在小程序工程化方面的一些實踐

早期做小程序時，還是原始時代，項目結構混亂，各種冗余代碼，每次迭代時由于高昂的維護成本，極為頭疼。遂在一次次的更迭中完成了基礎組件的初版，極為酸爽。從此之后在當時的情況下只需要關注于業務，對于通用的該封裝封裝，該分層分層，該解耦解耦，也出了一款獨立于業務之外的基礎組件。洋洋自得。

后來入職新公司，遇到的問題也是同樣的，在工作之余計劃將此前抽象的基礎組件集成進來，發現了不少問題，其中之一就是上手極為不易，在這個過程中又有一些改進。

更迭

此前公司的小程序開發模式是：

此前的問題對于頁面的創建是極為的不便，對于代碼的調試也不方便，代碼結構也沒有進行分層。

接入基礎組件之后，目前的小程序優化為以下結構：

相比之前添加了一層隔離層，好處與未來的規劃可以下圖解釋：

當前小程序此前就采用glup進行構建的，于是我在這個基礎之上添加了一些任務，使用工具自動引入基礎組件，而對編寫上層業務代碼來說是無感知、無侵入的，還可以按照之前的原生方式寫，這是它的一大優勢。

目前還有的問題是頁面之間的Intent通信耦合還是很嚴重，解決思路為可以提供一個中介者來完成，不過這個對目前來說問題不大。

目前已經完成的功能有：

• 開發者模式，可以用來切換環境，目前有生產，預發，測試。
• 對App的注冊進行了代理，可以在基礎層完成一些初始化工作。目前有監控的初始化。
• 對每個Page的生命周期與setData方法做了代理，setData在編譯時替換為了setMFData。
• setMFData目前對setData的調用做了節流。可以提升頁面的渲染性能。
• 將運行時環境所提供的方法掛載到了每個頁面實例下。不需要再通過wx.xx調用，可直接通過this.xx調用。這樣的好處在于使業務代碼與運行時api進行了隔離，也方便使用。
• 對此前的網絡層再做了一層隔離，這一層只是用來承載網絡訪問，并橋接了網絡監控的能力。而上層會做更多的業務處理。

將來可以做的事：

• 可以采用類vue的編寫方式，將4個文件合并至一個文件，擴展名可以為*.mp。
• 可以寫一個腳手架用來創建*.mp文件。
• 需要寫一個mp-loader將*.mp轉換為對應的微信文件。
• 可以寫一個轉換工具將之前的代碼合并至一個*.mp文件中。

*.mp文件的結構可以如下：

// *.mp // <!-- wxml內容 --> <template><view id="page"></view> </template>// <!-- js內容 --> <script>Page({data: {},onLoad() { },reload() {},onUnload() {}}) </script>// <!-- css內容 --> <style>#page {padding: 40rpx 50rpx;text-align: center;} </style>// <!-- 小程序特有的配置 --> <config>{"navigationBarTitleText": "小程序開發者"} </config>

---

以上就是我目前可以根據當前的一些問題進行的一些探索，這也是一個循序漸進的過程，將來在業務需要時也會催生出更好的方案，權當給大家分享一個實踐的思路。

總結

以上是生活随笔為你收集整理的我在小程序工程化方面的一些实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。