資訊專欄INFORMATION COLUMN
摘要：整個小程序所有分包大小不超過單個分包主包大小不能超過微信小程序主流框架對比應該算是最早發布的小程序開發框架，提供了類的語法風格和特性，現階段應該也是應用最廣泛的框架吧。不過微信官方為了防止下載離線包的時間過程，也嚴格限制了小程序包的體積。
那些年我們踩過的坑
css樣式不能引用本地圖片資源，只能引用線上資源(background-image)，引用本地圖片資源只能用
{{}}不能執行函數方法，{{}}只支持基本的簡單運算和ES6拓展運算符。如價格格式化這種常用的處理，只能在js代碼中處理好然后再模板中渲染。
this.setData({ price: this.formatPrice(this.data.price)})
可以通過wxs模塊解決{{}}中不能執行函數的問題。可以做到模擬vue.js中過濾器的功能。
// wxs模塊var formatPrice = function (price){ price = price >> 0; return Number(price / 100).toFixed(2);}module.exports = { formatPrice}
小程序不支持分享鏈接到朋友圈，暫時的通用做法是生成保存有頁面小程序嗎的圖片到本地相冊。又用戶自行發朋友圈轉發。前端可以利用canvas來實現，減輕服務端壓力。但是會有圖片鋸齒不清晰的問題。建議預覽圖和保存到真機的圖片采用不同的尺寸。保存在真機的圖片按照750的寬度實現。相比于預覽圖要大一些，這樣保存到手機的圖片會清晰很多。
小程序布局采用rpx單位，UI稿按照750的寬度出圖。可直接使用UI稿的尺寸。但是在某些機型上1rpx會無法顯示。可以用H5的方式實現1px效果。
iphoneX吸底按鈕的適配，可以用媒體查詢獲取wx.getSystemInfo獲取機型。參考
@media only screen and (device-width : 375px) and (device-height : 812px) and (-webkit-device-pixel-ratio : 3) { }
頁面A -> 頁面B，頁面B的操作觸發了頁面A的數據更新。返回更新頁面A的數據，通常有兩種方式來實現(我司采用了方案二)：
在頁面A監聽onShow事件，在onShow事件觸發時無腦更新頁面數據。
通過EventBus來實現跨頁面通信。
復雜組件的開發，省市區三級聯動選擇器的開發，獲取微信地址庫的地址的編碼和業務采用的省市區編碼對不上。
頁面路徑的層級，最大不能超過10層。
小程序小程序分包加載，微信對小程序包的大小有如下限制。
整個小程序所有分包大小不超過 8M
單個分包/主包大小不能超過 2M
微信小程序主流框架對比
wepy
mpvue
Taro
wepywepy應該算是最早發布的小程序開發框架，提供了類vue.js的語法風格和特性，現階段應該也是應用最廣泛的框架吧。我開發的幾個小程序也都是采用了wepy這個框架。我先來說說當初為什么選擇這個框架的原因吧。
類Vue.js的語法風格，適合我們團隊原有的的技術棧
支持組件化（當時微信官方的API還不支持組件化）
支持加載外部npm包
支持ES6的寫法
前期使用wepy的過程中，wepy自帶bug。不過好在開發者響應及時，基本上都能覆蓋大部分場景。
但是有個最大的坑點就是，wepy組件的實現方式。組件使用的是靜態編譯組件，即組件是在編譯階段編譯進頁面的，每個組件都是唯一的一個實例。 多個組件共享同一個數據。并且靜態編譯組件。導致組件A，在頁面A和頁面B被引用，會copy兩份代碼到頁面A和頁面B內部。導致拆分組件并沒有對包的體積有任何減少。后期微信官方API支持組件化編程后，我們逐步把一些比較核心，體積較大的組件用原聲API重構了。
mpvue由美團團隊開發，mpvue和wepy一樣也是在小程序上提供了類vue.js的開發體驗。作為后來者，搶占了很多wepy的市場份額（ps：我們團隊近期也在考慮從wepy遷移到mpvue）。這個框架的原理相比wepy要更加復雜一點，mpvue 修改了 Vue.js 的 runtime 和 compiler 實現，提供了更加接近于vue.js的開發體驗。
TaroTaro是由京東團隊開源的一套遵循 React 語法規范的多端開發解決方案。本身我對React和Taro都不是很了解，就不多解釋了。具體可以看開發團隊的博客和代碼了解更多細節多端統一開發框架 - Taro
我看小程序我想從技術的角度來談談我對微信小程序的理解，我覺得小程序本身是一個非常優秀的Hybrid App的技術方案。有很多值得學的地方，可以應用到我們Hybrid App的技術方案設計中來。了解和學習小程序技術原理也能更好的優化我們的代碼。
渲染層和邏輯層分離
相比于之前常見的Hybrid的方案，小程序使用了雙線程模型：小程序的渲染層和邏輯層是是分開的，邏輯層通過JSCore來解析和執行，渲染層是通過webview來渲染。之前的常見Hybrid離線包的方案大多使用webview同時實現頁面的渲染和js的解析。這樣做的的結果就是隔離了js的runtime，在js代碼中無法操作webview中的DOM對象和BOM對象。Js無法做任何和頁面渲染有關的操作。只能通過setData把數據從JsCore傳遞到webview。
獨立的JS運行環境，相比于webview同時處理頁面的渲染和JS的執行帶來了一些好處：
js無法動態的在頁面插入節點和干預頁面的渲染，解決了安全和管控的問題，否則小程序的上線審核就變得毫無意義。
渲染層和邏輯層的分離，減輕了webview的壓力，js的執行和頁面的渲染可以并行，不會出現js執行卡主頁面渲染的情況。
多個頁面可以共享一個JS運行環境，數據很方便的共享，整個小程序的生命周期共享同一個上下文，接近App的體驗。
壞處在于：
多了很多webview和JSCore數據傳輸的消耗，數據需要序列化成字符串格式進行傳輸。
離線包加載離線包加載，常見的Hybrid App通過webview加載H5頁面，前端頁面都是放在服務器端。雖說保證了靈活性。但是加載性能收網速影響大。頁面切換白屏時間長。小程序離線包的加載方式。一次性加載所有的前端資源到本地再解壓。大大提升了用戶體驗。不過微信官方為了防止下載離線包的時間過程，也嚴格限制了小程序包的體積。（分包加載情況下子包大小不能超過2M，也就是初次打開加載的資源不能超過2M）
多webview架構多webview的頁面架構，小程序每新開一個頁面，都會用一個新的webview來渲染。為了防止webview對內存的消耗。小程序限制層級不能超過10層。
預加載webview預加載webview，微信會預加載多一個wkwebview(ios平臺)放后臺，用戶打開小程序時省去初始化wkwebview時間。
更多技術資訊可關注：gzitcast
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/116369.html
摘要：框架這部分是小程序開發的核心，小程序采用視圖和邏輯層代碼相分離的結構，如果你用過這部分也不難理解，但是也有一些區別。工具這部分沒有什么好說的，微信開發開始還是用微信自己的開發工具比較方便。 小程序開發文檔使用說明 小程序的文檔分為 簡易教程、框架、組件、API?、工具https://developers.weixin.qq.... 簡易教程---介紹小程序開發的一些基本情況 開發方式...
摘要：和都是輔助小程序開發的開源庫，本文對兩者做個對比。微信的這種限制決定了小程序一般只是用于實現核心功能，不會用作復雜功能。在筆者了解的很多小程序，甚至大都是用原生開發的。 grace和wepy都是輔助小程序開發的開源庫，本文對兩者做個對比。 注：本文是作者本人的一些拙見，純粹的技術討論，不想引起技術信仰之爭，歡迎積極、正向的討論及建議。 如果你還不了解Grace, 請參考：微信小程序開發...
摘要：微信小程序應用號開發資源匯總文檔工具教程代碼插件組件文檔從搭建一個微信小程序開始小程序開發文檔小程序設計指南工具小程序開發者工具官方支持微信小程序實時預覽的支持的微信小程序組件化開發框架轉在線工具小程序云端增強社區微信小程序 微信(小程序or應用號)開發資源匯總-文檔-工具-教程-代碼-插件-組件 文檔 從搭建一個微信小程序開始 小程序開發文檔 小程序設計指南 工具 小程序開發者...
摘要：官方資料微信公眾平臺注冊小程序。官網開發文檔社區開發工具部署微信小程序微信小程序本身不需要部署，在微信開發工具中直接上傳代碼就行。 為什么 學習 Java 三年，目前已經工作了2年，因為自學，基礎差，所以打算年末總結一下常見的基礎知識和面試點； 也可以通過獨立做一個項目整合自己工作期間學習的知識，加深印象。 但是想著回家或是平時手機用的多，做一款APP和小程序很方便查看。 項目展示 本...
閱讀 3040·2021-11-22 09:34
閱讀 2513·2021-09-30 09:47
閱讀 1445·2021-09-03 10:32
閱讀 3713·2021-08-16 10:49
閱讀 1790·2019-08-30 15:55
閱讀 2460·2019-08-30 15:52
閱讀 3323·2019-08-30 15:44
閱讀 1353·2019-08-30 15:44
