微信小程序是一種全新的連接用戶與服務的方式，它可以在微信內被便捷地獲取和傳播，同時具有出色的使用體驗。
小程序提供了一個簡單、高效的應用開發框架和豐富的組件及API，幫助開發者在微信中開發具有原生 APP 體驗的服務。
基於微信小程序輕快的特點，小程序擬定了小程序界面設計指南和建議。 設計指南建立在充分尊重用戶知情權與操作權的基礎之上。旨在微信生態體系內，建立友好、高效、一致的用戶體驗，同時最大程度適應和支持不同需求，實現用戶與小程序服務方的共贏。
源文：https://www.yuque.com/jingwhale/spec/fom05c
一、小程序概述
一個小程序頁面組成，如下：
為了方便開發者減少配置項，描述頁面的四個文件必須具有相同的路徑與文件名。
1.1、小程序的工作原理
首先，我們來簡單了解下小程序的運行環境。小程序的運行環境分成渲染層和邏輯層，其中 WXML 模板和 WXSS 樣式工作在渲染層，JS 腳本工作在邏輯層。
小程序的渲染層和邏輯層分別由2個線程管理：渲染層的界面使用了WebView 進行渲染；邏輯層采用JsCore線程運行JS腳本。一個小程序存在多個界面，所以渲染層存在多個WebView線程，這兩個線程的通信會經由微信客戶端（下文中也會采用Native來代指微信客戶端）做中轉，邏輯層發送網絡請求也經由Native轉發，小程序的通信模型下圖所示。
1.2、小程序的本質
所以，小程序的編碼方式實際上是使用前端的語言進行編寫的。從理解的角度，小程序可以認為是運行在微信的瀏覽器容器中，遵從了一套從設計到組件的WeUI規范，的Web程序。
我們稱微信客戶端給小程序所提供的環境為宿主環境。小程序借助宿主環境提供的能力，可以完成許多普通網頁無法完成的功能。為了讓開發者可以很方便的調起微信提供的能力，例如獲取用戶信息、微信支付等等，小程序提供了很多 API 給開發者去使用。需要注意的是：多數 API 的回調都是異步，你需要處理好代碼邏輯的異步問題。
1.3、WeUI頁面元素所屬層級、層級順序及組合規范
WeUI頁面元素所屬層級、層級順序及組合規范（低到高）：Content、Navigation、Mask、Popout四層。
1）、Content
內容層，承載頁面主要內容。
2）、Navigation
導航層，位於內容層之上，在用戶滑動內容層時可保持位置不動，通常用於承載導航欄等需要固定在頁面的元素。
3）、Mask
蒙層，配合Popout層使用，用於鎖定內容層和導航層操作，不單獨使用。
4）、Popout
彈出層，作為內容層和導航層的補充，用於承載彈窗通知、操作菜單、菜單、成功或加載中等狀態的Toast，表單報錯提示等彈出內容。
1.4、小程序運行機制
1）、小程序啟動
小程序啟動會有兩種情況，一種是「冷啟動」，一種是「熱啟動」。
熱啟動：假如用戶已經打開過某小程序，然后在一定時間內再次打開該小程序，此時無需重新啟動，只需將后台態的小程序切換到前台，這個過程就是熱啟動；
冷啟動：用戶首次打開或小程序被微信主動銷毀后再次打開的情況，此時小程序需要重新加載啟動，即冷啟動。
小程序沒有重啟的概念。
2）、前台/后台狀態
當用戶點擊右上角膠囊按鈕關閉小程序，或者按了設備 Home 鍵離開微信時，小程序並沒有直接銷毀，而是進入了后台狀態；
當用戶再次進入微信或再次打開小程序，小程序又會從后台進入前台。
3）、小程序銷毀
需要注意的是：只有當小程序進入后台一定時間，或者系統資源占用過高，才會被真正的銷毀。
- 當小程序進入后台，客戶端會維持一段時間的運行狀態，超過一定時間后（目前是5分鍾）小程序會被微信主動銷毀。
- 當小程序占用系統資源過高，可能會被系統銷毀或被微信客戶端主動回收。
在 iOS 上，當微信客戶端在一定時間間隔內（目前是 5 秒）連續收到兩次及以上系統內存告警時，會主動進行小 程序的銷毀，並提示用戶 「該小程序可能導致微信響應變慢被終止」。 建議小程序在必要時使用 wx.onMemoryWarning 監聽內存告警事件，進行必要的內存清理。
1.5、小程序更新機制
1）、未啟動時更新
開發者在管理后台發布新版本的小程序之后，如果某個用戶本地有小程序的歷史版本，此時打開的可能還是舊版本。微信客戶端會有若干個時機去檢查本地緩存的小程序有沒有更新版本，如果有則會靜默更新到新版本。總的來說，開發者在后台發布新版本之后，無法立刻影響到所有現網用戶，但最差情況下，也在發布之后 24 小時之內下發新版本信息到用戶。用戶下次打開時會先更新最新版本再打開。
2）、啟動時更新
小程序每次冷啟動時，都會檢查是否有更新版本，如果發現有新版本，將會異步下載新版本的代碼包，並同時用客戶端本地的包進行啟動，即新版本的小程序需要等下一次冷啟動才會應用上。
如果需要馬上應用最新版本，可以使用 wx.getUpdateManager API 進行處理。
1.6、插件
1.7、小程序成員管理
不同項目成員擁有不同的權限，從而保證小程序開發安全有序。
二、開放接口與設備
開放接口：https://developers.weixin.qq.com/miniprogram/dev/api/open-api/login/wx.login.html
設備：https://developers.weixin.qq.com/miniprogram/dev/api/device/ibeacon/wx.stopBeaconDiscovery.html
三、小程序設計規范
小程序設計規范：https://developers.weixin.qq.com/miniprogram/design/
設計文件下載：https://developers.weixin.qq.com/miniprogram/design/#%E5%9B%BE%E6%A0%87
四、小程序基礎設計
4.1、小程序菜單深淺配色方案（iOS和Android）
開發者可在滿足可用性的前提下，從微信提供的深淺兩套配色的小程序菜單中選擇合適的方案，以適應小程序頁面設計風格。
4.2、小程序菜單
小程序的所有頁面，包括小程序內嵌網頁和插件，微信都會在其右上角放置官方小程序菜單，樣式如圖。開發者不可對其內容自定義，但可選擇深淺兩種基本配色以適應頁面設計風格。 官方小程序菜單將放置在界面固定位置，開發者在設計界面時請預留出該區域空間，若需要在此區域附近放置可交互元素，要特別注意交互事件是否會沖突，操作是否容易被使用。
4.3、品牌標志（Logo）設計
小程序啟動頁是小程序在微信內一定程度上展現品牌特征的頁面之一。本頁面將突出展示小程序品牌特征和加載狀態。啟動頁除品牌標志（Logo）展示外，頁面上的其他所有元素如加載進度指示，均由微信統一提供且不能更改，無需開發者開發。
五、小程序導航與布局設計
5.1、導航區域與標題區域
開發者可根據自身功能設計需要在頁面內添加自有導航。並保持不同頁面間導航一致，指向清晰，有路可退。受限於手機屏幕尺寸的限制，小程序頁面的導航應盡量簡單。建議開發者設計的自有導航樣式與微信官方小程序菜單樣式保持一定差異，以便區分。
5.2、標簽分頁（Tab）導航
開發者可為小程序頁面添加標簽分頁（Tab）導航。標簽分頁欄可固定在頁面頂部或者底部，便於用戶在不同的分頁間做切換。標簽數量不得少於2個，最多不得超過5個，為確保點擊區域，建議標簽數量不超過4項。一個頁面也不應出現一組以上的標簽分頁欄。
首頁原生底部標簽
其中小程序首頁可選擇微信提供的原生底部標簽分頁樣式，該樣式僅供小程序首頁使用。開發時可自定義圖標樣式、標簽文案以及文案顏色等，具體設置項如圖標尺寸等參考可參考開發文檔和WeUI基礎控件庫。
頂部標簽
頂部標簽分頁欄顏色可自定義。在自定義顏色選擇中，務必注意保持分頁欄標簽的可用性、可視性和可操作性。
5.3、頁腳（Footer組件）
六、小程序頁面加載設計
加載反饋注意事項
若載入時間較長,應提供取消操作,並使用進度條顯示載入的進度。 載入過程中,應保持動畫效果 ; 無動畫效果的加載很容易讓人產生該界面已經卡死的錯覺。 不要在同一個頁面同時使用超過1個加載動畫。
結果反饋
除了在用戶等待的過程中需予以及時反饋外，對操作的結果也需要予以明確反饋。根據實際情況，可選擇不同的結果反饋樣式。對於頁面局部的操作，可在操作區域予以直接反饋，對於頁面級操作結果，可使用彈出式提示、模態對話框或結果頁面展示。對於常用控件，微信設計中心將提供控件庫，其中的控件都已提供完整操作反饋。
6.1、啟動頁加載
小程序啟動頁是小程序在微信內一定程度上展現品牌特征的頁面之一。本頁面將突出展示小程序品牌特征和加載狀態。頁面上的其他所有元素如加載進度指示，均由微信統一提供。
6.2、頁面下拉刷新加載
在微信小程序內，微信提供標准的頁面下拉刷新加載能力和樣式，開發者無需自行開發。
6.3、全局加載反饋
6.3.1、使用標題欄提示加載小程序頁面內容的過程
開發者可以參考圖中樣式，使用標題欄提示加載小程序頁面內容的過程。例如：
6.3.2、模態加載
模態的加載樣式將覆蓋整個頁面的，由於無法明確告知具體加載的位置或內容將可能引起用戶的焦慮感，因此應謹慎使用。除了在某些全局性操作下不要使用模態的加載。
6.3.3、自定義頁面內容的加載樣式
開發者可在小程序里自定義頁面內容的加載樣式。建議不管是使用在局部還是全局加載，自定義加載樣式都應該盡可能簡潔，並使用簡單動畫告知用戶加載過程。
6.3.4、Loadmore組件
6.4、局部加載
局部加載反饋即只在觸發加載的頁面局部進行反饋，這樣的反饋機制更加有針對性，頁面跳動小，是微信推薦的反饋方式。例如：
七、小程序頁面Content設計
小程序頁面Content設計，實際上就是依據我們的業務設計，將小程序組件和我們自己設計的組件，按照小程序設計規范與視覺規范有序的組合和排版的過程。
7.1、小程序組件庫
設計組件庫：https://weui.io/
開發組件庫：https://developers.weixin.qq.com/miniprogram/dev/component/
7.2、小程序視覺規范
7.2.1、字體
微信內字體的使用與所運行的系統字體保持一致，常用字號為20, 18, 17, 16,14 13, 11(pt)，使用場景具體如下：
7.2.2、字體顏色
1）、主要顏色：
#09BB07 #353535 #888888 #576b95 #e64340 RGB(9,187,7) RGB(53,53,53) RGB(136,136,136) RGB(87,107,149) RGB(230,67,64)
2）、主內容 Black 黑色，次要內容 Grey 灰色；時間戳與表單缺省值 Light 灰色；大段的說明內容而且屬於主要內容用 Semi 黑。
Light Gray Semi Black #b2b2b2 #888888 #353535 #000000
3）、藍色為鏈接用色，綠色為完成字樣色，紅色為出錯用色 Press 與 Disable 狀態分別降低透明度為20%與10%。
Naormal Press（20%） Disabled（10%） #576b95 #09BB07 #e64340
4）、列表
5）、表單
6）、按鈕
7）、圖標
尺寸：100*100 pX
般用於結果頁面狀態提示，根據結果的情況選擇對應的 icon。
視覺設計規范：https://developers.weixin.qq.com/miniprogram/design/#%E5%AD%97%E4%BD%93
八、反饋設計-Popout
8.1、操作反饋
1）、圖標型彈出提示
圖標型彈出提示適用於輕量級的成功提示，1.5秒后自動消失，並不打斷流程，對用戶影響較小，適用於不需要強調的操作提醒，例如成功提示。特別注意該形式不適用於錯誤提示，因為錯誤提示需明確告知用戶，因而不適合使用一閃而過的彈出式提示。
2)、文字型彈出提示
文字型彈出提示適用於需要輕量化地用文字解釋當前狀態或提醒不嚴重的錯誤。1.5秒后自動消失，不打斷流程，對用戶影響較小。
3）、模態對話框
對於需要用戶明確知曉的操作結果狀態可通過模態對話框來提示，並可附帶下一步操作指引。
4）、結果頁（非Popout）
對於操作結果已經是當前流程的終結的情況，可使用操作結果頁來反饋。這種方式最為強烈和明確的告知用戶操作已經完成，並可根據實際情況給出下一步操作的指引。
5）、異常狀態——表單出錯（非Popout）
表單報錯，在表單頂部告知錯誤原因，並標識出錯誤字段提示用戶修改。
8.2、足不出戶
1）、模態對話框
2）、ActionSheet
3）Half-screen Dialog
4）Picker
5）、Toast
九、雲開發
開發者可以使用雲開發開發微信小程序、小游戲，無需搭建服務器，即可使用雲端能力。
雲開發為開發者提供完整的原生雲端支持和微信服務支持，弱化后端和運維概念，無需搭建服務器，使用平台提供的 API 進行核心業務開發，即可實現快速上線和迭代，同時這一能力，同開發者已經使用的雲服務相互兼容，並不互斥。
雲開發提供了幾大基礎能力支持：
| 能力 | 作用 | 說明 |
| 雲函數 | 無需自建服務器 | 在雲端運行的代碼，微信私有協議天然鑒權，開發者只需編寫自身業務邏輯代碼 |
| 數據庫 | 無需自建數據庫 | 一個既可在小程序前端操作，也能在雲函數中讀寫的 JSON 數據庫 |
| 存儲 | 無需自建存儲和 CDN | 在小程序前端直接上傳/下載雲端文件，在雲開發控制台可視化管理 |
| 雲調用 | 原生微信服務集成 | 基於雲函數免鑒權使用小程序開放接口的能力，包括服務端調用、獲取開放數據等能力 |
十、拓展
小程序開源了，weui-wxss、weui.js和react-weui等，可以使用他們進行Web頁面的設計與開發，它可以運行在任何瀏覽器中。
weui：https://github.com/Tencent/weui
關注微信公眾號獲得及時推送
