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

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

核心功能展示：

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

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

版本迭代

關(guān)于 1.0

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

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

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

下面就開(kāi)始來(lái)講 2.0 的整個(gè)開(kāi)發(fā)過(guò)程。

技術(shù)選型

后端

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

對(duì)于數(shù)據(jù)的設(shè)計(jì)，也沒(méi)有推倒重來(lái)，只添加了廣告和通知兩個(gè)數(shù)據(jù)庫(kù)。

前端（小程序端）

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

開(kāi)發(fā)

考慮到 2.0 版本要加入評(píng)論回復(fù)的提醒，那么如何展示通知就是一個(gè)大問(wèn)題。原因是因?yàn)樾〕绦驔](méi)有提供跨出小程序通知的能力，那么我們就只能在小程序內(nèi)考慮通知的提示。

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

• Websocket

• 輪詢

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

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

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

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

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

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

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

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

示意圖如下：

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

體驗(yàn)優(yōu)化

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

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

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

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

接入過(guò)程也十分簡(jiǎn)單，填寫加速域名和IP，然后過(guò)大概5分鐘OK了：

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

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

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

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

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

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

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

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

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

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