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

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

核心功能展示：

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

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

版本迭代

關于 1.0

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

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

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

下面就開始來講 2.0 的整個開發過程。

技術選型

后端

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

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

前端（小程序端）

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

開發

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

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

• Websocket

• 輪詢

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

相比而言，Websocket肯定是更優選擇，但是考慮到小程序入口在微信內部的，聊天時一定要退出小程序，并且很少人會使用小程序置頂的功能，所以如果使用 Websocket 就需要經常重復建立 Websocket 連接。

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

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

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

最后的頁面結構如下圖所示：

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

接下來的一個問題，就是關于 request 的登錄態的問題。由于小程序是沒有 cookie 的，于是我們普通設計 ajax 的登錄態 token 不能放在 cookie 上了，于是便考慮將 token 放在 headers 里。在用戶首次登陸的時候將登錄態的 token 放在本地的 Storage 里，并在每個請求發起的時候自定義了一個請求頭，手動帶上 token。

示意圖如下：

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

體驗優化

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

還有一些已經去外地實習的同學跟我吐槽說，樹洞的使用體驗不如在校內使用時那么流暢。

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

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

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

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

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

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

未經加速直連源站各運營商監測數據：

加速后各運營商監測數據：

未經加速直連源站各省份監測數據：

加速后各省份監測數據：

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

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

以上，希望我分享的內容能幫到大家。