2018 年 10 月13 日，由又拍雲和知曉雲聯合主辦的 Open Talk 丨2018 小程式開發者沙龍系列活動廣州站拉開帷幕，糗事百科前端負責人宋航在沙龍上做了《更App化的小程式開發》的分享。

“2018 小程式開發者沙龍”是又拍雲 Open Talk 繼“2018 音視訊技術沙龍”後推出的重磅系列活動，與大部分偏重營銷、流量的小程式活動不同，本系列活動更熱衷於分享小程式開發過程的種種有趣經歷和有益的經驗。

宋航目前負責糗事百科的前端、小程式、小遊戲相關的開發工作，對遊戲開發、App 開發、Web 前端開發都有深入研究，追求開發好玩的產品。糗事百科在小程式上除了延伸自家產品製作了“糗事百科+ ”小程式外，還在以好玩、有趣為目標的道路上製作更多優質的小程式，比如在塗鴉方面的“填色心語”等。

宋航認為，小程式肩負著強化 Web 能力、簡化 App 開發的重大責任，同樣是使用 Javascript 開發，很多人把 “Web 頁面開發“的一套東西搬到小程式開發上，因此不得其法。在分享中，宋航介紹了借鑑 App 開發來做小程式的思路和方法，內容主要包括：

• 小程式開發與傳統 Web 頁面開發的區別；
• MVC 模式如何幫助優化小程式開發流程；
• 首屏優化；
• 硬體能力的授權等。

以下是分享整理：

大家下午好，非常開心能在 Open Talk 的活動上給大家分享糗事百科團隊一年多以來的小程式開發經驗。我是來自糗事百科的前端開發負責人宋航，今天分享的主題是“更 App 化的小程式開發”。

在小程式釋出的一年多以來，糗事百科把自家的 App 產品落地到小程式，而且開發了很多比較好玩的小程式。這些小程式不一定是使用者量很高的產品，但是對於大家在小程式開發探索路上會有很大的幫助。

2016 年底微信釋出小程式，那個時候功能相對較少。簡單的說就是 H5 的“微信化”，在微信裡畫了一個 H5 框架。但是今天小程式有更多的硬體能力，所以我今天才會分享《更 App 化的小程式開發》的主題。我的看法是不管是目前還是未來，小程式可以替代很多 App。

小程式的意義：加強能力，簡化開發

大家認為小程式的出現意味著什麼呢？對於開發者來說，我覺得小程式的出現其實“加強了 Web 的能力，簡化了 App 的開發”。

小程式在 Android、iOS 都可以執行，但是它相比於 App 有什麼不同？在開發方面，可能早上有一個想法，晚上就可以開發出一個小程式並且實現上線；而開發 App，不可能早上有一個想法，晚上就完成開發併發布到各種各樣的應用商店。

第一，小程式與 H5 有什麼不一樣？

小程式比 H5 有更多的能力，相容性更好。前端開發者都知道各種瀏覽器的相容是一個痛點，小程式的出現首先解決了相容問題，同樣的執行環境可以遮蔽掉不相容的一些錯誤，讓我們更專心於開發業務邏輯。

第二，小程式有更強的硬體能力。

例如把頁面上的圖片儲存到手機相簿，普通 H5 很難做到。在小程式裡面，微信為了防止小程式濫用硬體能力，引入了一個概念——授權，這個概念在 App 裡面已經有了。為什麼小程式要有授權呢？因為“能力越大，責任越大”，微信可以賦予小程式更強的硬體能力，但是為了避免這種能力被亂用，必須加入授權這一概念。如果 H5 能夠隨便修改相簿、修改聯絡人，那是一種很恐怖的事情。通過微信和授權機制，小程式可以呼叫到手機的各種硬體能力，相比 H5 有更大的想象空間。比如說我們現在做的直播、錄影、拍照的功能都可以用到手機攝像頭、麥克風、相簿等，甚至可以把檔案傳到小程式，這個時候，我們產品可以擁有很大的想象空間。

第三，小程式背靠“微信”的使用者系統、推送、支付，有利於商業運營，讓開發者節省了很多開發工作。H5 沒有推送功能，要重新喚回使用者需要費很多工夫，比如搞活動等。簡單說一下 H5 的主要邏輯，如這張圖：

△ H5 的資料邏輯

H5 的主要邏輯都可以劃分為這個流程，通過請求網路資料、處理資料展示到使用者面前，使用者做出的任何操作，比如點贊、發評論返回到網路，請求回網路之後送回內容。

對比 H5，小程式上有更多的硬體能力，小程式不僅能從網路上獲取資料，還可以從硬體裝置獲取資料。

△ 小程式的資料邏輯

MVC：“糗百”開發小程式的業務邏輯

糗事百科團隊早期做小程式開發時，由於產品比較廣泛，迭代比較快，所以沒有采用第三方框架，而是採用了官方的開發文件來工作。

△ 糗事百科早期開發小程式的邏輯

官方的小程式開發文件其實很簡單，我們控制對應的 page.js，通過設定 data，渲染到頁面即 wxml，讓它展示 UI 顯示、動畫效果和操作反饋。隨著開發的深入，我們漸漸發現整個程式變得非常臃腫，因為小程式的邏輯程式碼都放在了 page.js 裡面。一些資料裡面提到小程式跟 H5 有一個很大的區別就是在跳轉頁面的時候我們不知道怎麼傳遞資料，因為每一個 page.js 都是孤立的。資料裡面也會教你如何去傳遞資料，但是做起來會非常麻煩，每當你建立一個 page.js，你就需要思考這個資料在下一個頁面會不會用到，這個資料改了以後上一個頁面應該怎麼去重新渲染，當頁面很多的時候就回變得非常複雜，這樣會影響到我們每一次做新頁面的開發。

糗事百科團隊在重構程式碼的時候，沒有采取第三方框架，在原來基礎上把整個 MVC 框架套進去。小程式官方提供的 page.js 可以想象成 MVC 框架下的 Controller ，我們把需要用到的資料抽象成模型，每個模型可以在不同的 page.js 上，通過 page.js 修改 data，最後改到 UI 上。

△ 糗事百科應用 MVC 後開發小程式的邏輯

我們看下每個步驟負責的內容。原來負責所有邏輯的 page.js 現在只需要負責從 Model 接收資料、響應及管理 View 的生命週期。資料模型做的事情比較簡單，處理業務邏輯、提供資料給 page.js、資料持久化。

△ Model 和 Controller 的資料傳輸

資料模型和 Controller 是通過怎麼樣的邏輯進行資料傳輸的呢？這裡運用的是“觀察者模型”和“釋出/訂閱模型”，這兩個模型都可以很好地在 Controller 和 Model 之間傳遞資料。這二者有什麼區別呢？

• 觀察者模型（observer）

“觀察者模型”可以把 model 的屬性，比如文章的點贊功能，是否已經點讚的屬性，與 Controller 中的 data 相互繫結，在修改 model 的時候，直接修改 Controller 裡面的 data，然後執行 setData 方法，讓 UI 上的點贊按鈕被點亮。

△ “點贊”動作的資料傳遞

在 UI 上我們通過繫結事件，讓點贊按鈕與 page.js 的邏輯繫結，當點贊事件發生，文章的例項會改變點讚的屬性，因為雙方是互相繫結的，所以 page.js 裡面的 data 也會改變，從而執行 setData 方法。

“觀察者模型”比較偏向於單個的屬性變化，比如使用者登陸，登陸之後有很多屬性比如名字、頭像、性別都發生改變，如果每一個都用“觀察者模型”，每個屬性變化都要執行 setData，setData 會用得非常頻繁，官方文件是不建議這麼頻繁去調 setData 方法。所以“觀察者模型”比較適用於當資料變化時不會影響到其他改變 UI 資料變化，比如點贊按鈕只會影響點讚的 UI 有沒有被點亮，不會影響其他資料改變，所以沒改變一次，只調用一次 setData 方法，不影響整個程式的效能。要注意的一個地方是“觀察者模型”需要繫結，在 Controller 的生命週期裡要注意它的解綁和繫結。

• 釋出/訂閱模型（Pub-Sub）

“釋出/訂閱模型”在跨頁面傳遞資料的時候用得比較多，比如前面說的使用者登入的例子，使用者登入之後可能涉及到幾個頁面的更新， 如果上個頁面也有使用者資訊的展示也需要更新，如果是大型的軟體可能涉及的更新資料會更多。如果按照官方的說法把整個資料 setData 一遍會顯得太過繁瑣，

“釋出/訂閱模型”適用於跨越多個頁面同時操作 UI 更新，讓互相關聯的 data，在某個時間點下一起更新，不用頻繁的去 setData。比如登陸之後使用者頭像、性別等進行改變，我們只需要一次setDada 就可以。同樣“釋出/訂閱模型”也要需要繫結，繫結的時候也要注意一下解綁，重複繫結。

△ 登陸模型示意圖

上圖是登陸模式示意圖，通過繫結事件，在 Login Event 發生之後，Pub-Sub 推送到每個 page.js ，多個頁面同時更新。

△ model 管理資料

通過抽象的一個 model，整個程式變得很簡單，小程式不僅僅能從網路獲取資料，還可以從硬體裝置比如說儲存空間裡面獲取資料。前面我們說過把 page.js 裡面的 data 抽象成一個 model，每次拿資料會經過上圖的三個步驟：首先查記憶體是否有這個資料，如果沒有可以從本地快取查詢，最後我們再從網路/ 硬體裝置去查詢，這些操作都可以封裝會 model 裡面，這樣調 model 的時候很簡單地調一個屬性，它底層就已經經過三層查詢，這樣不僅基於我們的網路請求，還可以很很簡單利用小程式提供的快取空間和檔案系統空間

MVC 框架在開發上對我們有很大的幫助，讓資料流脫離出 page.js，不用再去考慮各種資料的傳遞，微信在跳轉頁面的時候只允許在 URL 上攜帶一定的字串，通過這樣的方式傳遞到下一個頁面，導致物件型別很難去傳遞了。

小程式的“首屏優化”

如何讓小程式更快地展示出內容給使用者？這個是在做網頁的時候經常遇到的問題，網頁載入慢1秒就可能損失大量的使用者，做小程式也是如此。

第一步把小程式程式碼量儘可能壓縮資源。很多人剛做小程式的時候，認為可以讀本地資源的圖片，不用從網路載入，把本地資源的圖片塞在小程式裡，其實這並不是一個很明智的方法，很多圖片可以放到網路上，不一定塞到小程式包裡面。

第二步是分包。這有點像做 H5 的時候，把 JS 包劃分出來，我們可以把訪問頻率比較低的頁面分到分包裡。現在小程式是 4M 的主包加 2M 的分包，我們可以把訪問頻率很低的頁面比如設定頁面、使用者須知頁面，塞到分包，這樣整個小程式包變得比較小，主包變小下載速度比較快。

這個時候我們可以很快進入第二階段，就執行我們的業務邏輯。

△ 小程式的首屏優化

小程式一開啟執行的業務邏輯是訪問網路，並不一定要等到進到相應的 page.js 才把資料請求出來。每次訪問小程式頁面的時候，都在讀取 model 裡面的資料，model 裡面數分成 3 層。我們可以把使用者上一次退出小程式的狀態儲存到快取，等我們再進去的時候就可以看到資料了，並不是每次進去都是一個白屏 loading。

渲染內容要注意的一點是“首次渲染”可以渲染出比較簡單的東西，隨著頁面寫得越來越深入，wxml 內的邏輯層級會比較複雜，這時候可以用小程式提供的元件或者模版，把每個部分封裝成元件，每個元件渲染的時候內部會進行資料的優化，不會影響整個頁面的複雜度，渲染起來比較簡單快捷。

善用微信賦予小程式的硬體能力

對於小程式，“能力越大，責任越大”。一個小程式擁有硬體能力時需要注意的是什麼呢？微信給與了小程式呼叫硬體能力的授權，但是我看到很多小程式在授權上都做得很差，比如一進去點了拒絕，找不到重新授權，點了拒絕不會再出現授權了。

小程式在獲取一些隱私的東西的時候，比如手機號碼、使用者資訊等，以前做 Web 端可能沒有注意到這方面的安全性。微信提供的手機號碼是加密的資料，很多人拿到資料後臺解密，然後明文傳輸給前臺，這種做法是不理智的，我們在資料傳輸上要注意加密的資訊。

在授權上，使用小程式給我們提供的 Api 介面來授權，一旦拒絕就不會出現提示，現在普遍的做法是使用按鈕，按鈕來喚醒授權，即使點拒絕了，重新用按鈕點選授權還是會彈窗，所以最理想的情況是有一個頁面讓使用者清楚知道自己在哪一方面授了權，這就是我們在擁有了這些能力之後要給使用者一個明確的反饋。

善用微信提供的能力，微信提供給我們有很多東西。比如我們之前做一個電商平臺，寫了半天使用者填寫資訊的框架，後來發現微信已經給我們提供了一個地址選擇的功能，包括卡包功能，微信都已經內建在裡面。當然微信的 Api 上內容比較多，大家每次開發的時候都需要看一下，我每次看它的開發文件，它擁有的新功能是很多的。

我們在小程式上還能獲取到各種各樣的網路狀態，比如在做一些視訊播放類小程式，或者大流量的應用，可以利用這些網路狀態來提示使用者是否選擇開啟一些功能。這些都是小程式賦予我們硬體能力之後，我們能夠改善小程式使用者體驗的地方。

推薦閱讀（演講視訊及ppt）：更 App 化的小程式開發 - 又拍雲