深大的樹洞（以下簡稱樹洞）是面向深大學(xué)生的一款小程序，同學(xué)們可以在這里分享新鮮事，吐槽生活中不爽，訴說碰到的委屈。

樹洞也是自微信小程序公測以來上線較早的一批小程序，上線之后獲得了深大同學(xué)們的廣泛好評，平臺也一直保持著較高的活躍度。

核心功能展示：

產(chǎn)品核心邏輯較為簡單，用戶進入小程序之后在首頁可以瀏覽用戶已發(fā)布的內(nèi)容，支持點贊和評論，用戶同時能在底部TAB 欄進入消息頁查看和回復(fù)相關(guān)評論信息。

點擊屏幕右下角的懸浮按鈕可以進入發(fā)布頁面，內(nèi)容支持文字和配圖，并提供定位功能，用戶如果選擇實名發(fā)布信息的話，會獲取用戶的微信昵稱和頭像以供主頁顯示。

版本迭代

關(guān)于 1.0

大概是今年的 2 月份，當(dāng)時小程序正式上線了，自己用了一圈，體驗上總體來說還是比網(wǎng)頁要出色一些。然后我也一直有開發(fā)一款樹洞類應(yīng)用的想法，于是就著手開始做一款樹洞小程序。

當(dāng)時為了趕在 2.14 情人節(jié)上線，整個開發(fā)周期基本就只有不到一周的時間，包括前后端的開發(fā)，十分的緊迫。1.0 的技術(shù)選型階段，后端采用 Node.js + MySQL 的架構(gòu)，而前端小程序方面，為了使用 ES6 和 Less 進行開發(fā)，選用了 Labrador 框架。

但是后來發(fā)現(xiàn) Labrador 也有問題，首先就是狀態(tài)的綁定分為了 props 和 state ，綁定的時候增加了復(fù)雜度，其次就是對于組件的支持并不是特別的舒服，沒有 Vue 單文件來的好用。

下面就開始來講 2.0 的整個開發(fā)過程。

技術(shù)選型

后端

后端沒有推倒重來，在 1.0 的基礎(chǔ)上增加了 /v2 的后綴，并且復(fù)用了一些 1.0 版本的 API。一方面是考慮到某些 API 的數(shù)據(jù)結(jié)構(gòu)已經(jīng)比較完善了，而且暫時沒有更好的設(shè)計；另一方面是考慮到這樣可以節(jié)省一點開發(fā)的工作，也可以兼容低版本。

對于數(shù)據(jù)的設(shè)計，也沒有推倒重來，只添加了廣告和通知兩個數(shù)據(jù)庫。

前端（小程序端）

在 1.0 發(fā)布之后，無意之間發(fā)現(xiàn)了 WePY 這個框架，發(fā)現(xiàn)這個框架借鑒了 Vue 的單文件組件的開發(fā)模式，而且一些 API 的使用也更加貼近原生的 Vue，另外在框架層面也實現(xiàn)了數(shù)據(jù)的臟檢查，可以摒棄原生小程序的setData,于是決定采用 WePY。

開發(fā)

考慮到 2.0 版本要加入評論回復(fù)的提醒，那么如何展示通知就是一個大問題。原因是因為小程序沒有提供跨出小程序通知的能力，那么我們就只能在小程序內(nèi)考慮通知的提示。

而在對后端的通知 API 設(shè)計的時候，考慮了兩種方案：

• Websocket

• 輪詢

Websocket 是基于 TCP 的全雙工通信，可以實現(xiàn)服務(wù)端推送信息，微信的 Web 端也是采用 Websocket 來實現(xiàn)通信的，而輪詢則是客戶端定時請求服務(wù)端來查詢有無通知。

相比而言，Websocket肯定是更優(yōu)選擇，但是考慮到小程序入口在微信內(nèi)部的，聊天時一定要退出小程序，并且很少人會使用小程序置頂?shù)墓δ?，所以如果使?Websocket 就需要經(jīng)常重復(fù)建立 Websocket 連接。

并且考慮到很少有人會開著樹洞等回復(fù)，所以實時的通知對用戶體驗的提升不大，于是我采用了輪詢來實現(xiàn)，這也是技術(shù)上比較簡單的實現(xiàn)方式。

在開發(fā)通知頁面的時候，我還發(fā)現(xiàn)了一個問題，就是微信小程序的 request API 還不支持 PATCH 請求，便暫用 PUT請求作為替代。

通知方面，由于通知只能在小程序內(nèi)部進行顯示。于是我打算使用 Tab 欄來提示，隨之而來的第二個問題就是，小程序提供了一個展示 Tab 欄的能力，但是只能自定義 icon 和文字，并且只能在配置文件里配置，等于說完全失去了對 Tab 欄編程能力，于是我拋棄了原生的 Tab 實現(xiàn)，使用 WePY 提供的組件系統(tǒng)自己實現(xiàn)了一個 Tab 欄。

最后的頁面結(jié)構(gòu)如下圖所示：

基于此，首頁、通知、用戶三個頁面不再是 page，而是 component，所以開發(fā)的時候 class 應(yīng)該繼承的是 wepy.component 這個類。而其他頁面層級的頁面的類，則應(yīng)該繼承 wepy.page。也正是由于這種情況，組件是沒有生命周期的函數(shù)的，所以需要在 index.wpy 上面手動觸發(fā)組件內(nèi)的函數(shù)，來模擬生命周期函數(shù)的調(diào)用。

接下來的一個問題，就是關(guān)于 request 的登錄態(tài)的問題。由于小程序是沒有 cookie 的，于是我們普通設(shè)計 ajax 的登錄態(tài) token 不能放在 cookie 上了，于是便考慮將 token 放在 headers 里。在用戶首次登陸的時候?qū)⒌卿洃B(tài)的 token 放在本地的 Storage 里，并在每個請求發(fā)起的時候自定義了一個請求頭，手動帶上 token。

示意圖如下：

關(guān)于樹洞開發(fā)的一些問題和解決方案就基本記錄到這里了。

體驗優(yōu)化

隨著樹洞用戶量的逐漸增加，部分用戶反饋在夜間高峰期樹洞首頁數(shù)據(jù)刷新緩慢甚至經(jīng)常刷不出數(shù)據(jù)。

還有一些已經(jīng)去外地實習(xí)的同學(xué)跟我吐槽說，樹洞的使用體驗不如在校內(nèi)使用時那么流暢。

我對以上問題進行反思，先考慮從小程序的代碼層面進行優(yōu)化，但是折騰一番后發(fā)現(xiàn)在基于微信提供的框架上進行開發(fā)后，自己能做的事情十分有限，便作罷。

然后開始從用戶請求與服務(wù)器端通信的過程入手分析問題，這時正巧看到騰訊云動態(tài)加速新品內(nèi)測，我嘗試申請了一下竟然很快就通過了，于是遍想通過接入動態(tài)加速，看看問題是否出在網(wǎng)絡(luò)傳輸過程中。

接入過程也十分簡單，填寫加速域名和IP，然后過大概5分鐘OK了：

在接入動態(tài)加速之后的一個星期的時間，我每天跟蹤了之前曾經(jīng)跟我反饋過問題的同學(xué)們的樹洞使用體驗，發(fā)現(xiàn)他們基本沒有再跟我吐槽過卡頓、數(shù)據(jù)丟失等問題，使用高峰期間的用戶體驗得到了很大的提高。

然后我使用聽云測試了一下騰訊云動態(tài)加速的加速效果：

• 源站所在地：廣州
• 檢測數(shù)據(jù)時間段：2017年07月24日 16:30 - 2017年07月25日 16:30
• 測試條件：10 M大小文件下載

未經(jīng)加速直連源站各運營商監(jiān)測數(shù)據(jù)：

加速后各運營商監(jiān)測數(shù)據(jù)：

未經(jīng)加速直連源站各省份監(jiān)測數(shù)據(jù)：

加速后各省份監(jiān)測數(shù)據(jù)：

相比之下，加速后性能提升近50%，可用性也有所提高，效果還是相當(dāng)明顯的。

雖然加速效果很明顯，但是我發(fā)現(xiàn)截止發(fā)文時間為止，騰訊云動態(tài)加速控制臺的統(tǒng)計分析模塊所提供的統(tǒng)計維度還是太少，對于樹洞這類運營需求比較強的產(chǎn)品來說，顯得有些美中不足，希望他們正式上線之后，能加入更豐富的統(tǒng)計功能。

以上，希望我分享的內(nèi)容能幫到大家。