文章來源：高校微信小程序開發大賽 公眾號
「群影」是一款為微信群聊建立專屬智能相冊的小程序 ，可以通俗地理解為微信群相冊，它有效地解決了群聊中的圖片過期無法加載而丟失的問題，通過流暢的上傳、存儲、查看功能幫助用戶記錄集體記憶。
本次，我們邀請到了「群影」小程序的開發者、微信的開發工程師 guocai 來分享「群影」的開發過程，希望能為正在打磨大賽作品的高校開發者們提供一些啟發。
從生活痛點發現群影開發需求
Q：為什麼會想到要開發這個小程序，是怎麼發現這個需求的？
A：主要是源於生活中自己和同事們使用微信群過程中的一些問題。
每個人的微信裡都有幾個相對固定的群，同學群、工作群、家庭群，有娃的話，還有老師家長群等等。同事一起旅遊，事後會發一些當時的照片到群裡。同樣的，有娃的同事，老師在課堂做了一些活動，拍了照片也會直接發群裡。
但是過了一段時間，大家想找回當時的照片，卻發現找不到了，這時就會覺得很可惜。於是，我們就想能不能解決這個問題，微信群能不能增加一個存儲的能力呢？
2017 年年中，微信小程序 1.4.0 版本增加了一個 open-data 的組件和相關 api，開發者可以獲取到「打開小程序所在微信群」的唯一 id 和群名字。這使得我們可以做到基於群的一個存儲空間，只有加入這個群的成員，才能看到當前群的照片。
群影的誕生，經歷了一步一步的迭代過程
Q：當時的設計思路是怎樣的？
A：開發前期，我先明確了產品的 3 個目標，第一是解決核心問題，為微信群增加存儲能力；第二是要簡單，用戶一進來就知道如何使；最後是效率，讓用戶花費最短時間完成目標
Q：開發過程經歷了幾次迭代？都遇到過哪些問題？
A：第一個迭代，設計了下圖所示的界面，這個整個界面分為三個部分，上面部分是小程序被打開時所在的微信群群名，這個就是使用前面講到的 open-data 拿到的；中間部分是在當前群上傳的照片；下面部分就是一個加號，點擊上傳照片。
整個界面足夠簡單，一眼看過去，除了上滑查看更多照片，就只有下面加號可以點擊，用戶很容易理解它的使用方式。
這裡完成了產品的雛形，那我們可不可以做得更好呢？在使用的過程中，我們會有歸類的需求，比如一起出去旅遊，我們會希望把旅遊的所有照片放在一起，所以我們開始了下一個迭代。
第二個迭代，我們增加了相冊的功能，用戶可以將照片移動到一個相冊裡。比如我把小組同事單車騎行活動放在一個相冊，年會活動放到另一個相冊。
到這裡，對比開始設立的目標，我們已經實現了群相冊存儲功能，界面也設計得足夠簡單，我們開始思考，能不能提升用戶使用群相冊的效率。
我們發現，看照片的人會第一時間去找自己在哪些照片裡，自己好不好看。另外，歸類其實也是有一定的規律，比如，某一次活動的照片對應的地點和時間是相對集中的。所以，我們又開始了下一個迭代。
第三個迭代，我們使用了騰訊優圖人臉識別技術，以人物為維度自動建立個人相冊。如圖所示的，每個人的人臉自動從照片中識別並且截圖顯示、作為個人的相冊封面。
另外，如果用戶上傳的圖片是原圖，那麼我們可以分析原圖中的地理位置信息和時間，做自動歸類，但並非每張照片都是原圖，而且地理位置和時間信息也是一種用戶隱私，保守起見，我們最終沒有上線這個功能。
第四個迭代，上面實現的群相冊在使用中會遇到一個問題，我在一個群裡打開了一次群相冊，後面再想打開，需要再轉發一次到群裡才能打開，這會對正常群聊產生騷擾。
所以，我們在發現的小程序列表打開「群影」的時候，增加了一個所有群相冊的視角，每個群相冊都以第一張照片和群名字做一個明顯的區分。在此基礎上，我們還做了未讀照片的紅點提醒和置頂某個群相冊的操作。
第五個迭代，產品上線後發現，每個群上傳照片的人比較少，看照片的人多，為了激發大家上傳照片的熱情，我們做了一個顏值評分的功能，讓大家都把自己最好的照片都傳上來看看自己的評分。另外，我們也想過，做 P 圖、表情和有聲影集，但是這些功能其實都能單獨做成一個小程序了，不是群相冊的核心能力，所以最後沒有做。
第六個迭代，我們微信內部有個寵物群，他們是群影的第一批用戶，他們反饋，當看到可愛的寵物照片，想說點什麼，卻不能點讚或者評論。
我們這樣思考這個需求，對於點讚，第一，是比較簡單的社交功能，容易實現；第二，通過點讚數量能建立最受歡迎照片的排名，可以讓用戶更快發現最好的照片；第三，點讚時可以推送給上傳圖片的作者，也算是一種上傳照片的激勵手段。所以，我們認為點讚是比較合適的。
對於評論，我們認為這個功能做了也沒有價值。因為用戶習慣是把照片轉發群裡，在群聊裡討論，而不是在一個小程序裡。在小程序裡作評論，相當於和微信群聊「打架」，這是不合理的，所以最終我們沒有選擇做評論功能。
檢驗群影的過程，外部用戶評測
Q：後續又給小程序增加了什麼功能？是在怎麼想到的？
A：「群影」的產品迭代結束後，產品發布，我們把它轉發到微信群裡自發傳播，看外部對我們的評價。然後也找了一些合作的外部用戶去使用，他們都認可群影實用性高、界面簡潔、方便記錄生活。這其實也是我們一開始設立的產品目標。
然後他們認為需要加入自動收集功能。這個我們也想做，上傳照片的過程確實有些長，只能寄望於小程序對於微信生態的進一步開放。照片評論和 p 圖功能也是他們想要的，但是前面解釋過了，這些不是核心功能。
群影開發的技術要點
Q：「群影」小程序的開發過程要哪些要點可以分享的？
A：我們先從「群影」的項目整體結構開始看。
從底層往上，「群影」的項目整體結構分別是微信開放接口服務、開發者伺服器和小程序。「群影」的開發者伺服器下面綠色部分都是使用了微信開放接口服務獲得的微信生態數據，分別是第三方認證登陸、微信用戶信息、群信息和點讚消息推送。
開發者伺服器欄的藍色部分，都是「群影」的業務邏輯，包括了小程序登陸、圖片按群維度的存儲、人臉識別和 CDN。
最上面的小程序，也分了兩層，紫色的是所有頁面通用的自動登錄、全局狀態、後臺 cgi 請求、自定義組件。
自動登錄的意思是相對於傳統 web 登錄過期需要重新輸入密碼而言的，小程序的登錄是一個無需密碼的用戶授權過程，所以為保證體驗，開發者在發現用戶登錄過期的時候，最好為用戶發起一次自動登錄操作。
全局狀態，「群影」主要存放當前打開的群信息。cgi 請求，「群影」主要在小程序提供的 wx.request 和 uploadfile 基礎上，封裝自動帶上登錄態，登錄過期重發，上傳圖片顯示進度，通用的 cgi 請求報錯處理的能力。
自定義組件，主要是封裝了首頁 tab 的切換組件，彈出輸入框兩個控制項。最上面橙色部分是一開始介紹過的業務內容，不再詳細描述。
接下來，我再講一些「群影」小程序開發過程中的細節點：
1.群數據獲取時機
如何實現不同群裡打開小程序，看到是當前群的數據？
打開小程序，app 有 onLaunch
和 onShow 兩個生命周期函數可以監聽。但是 onLaunch 全局只調用一次，而小程序需要在不同群打開，所以 onLaunch 顯然不合適，所以我們在 onShow 發起獲取群數據的請求。
還有一個問題，群數據獲取是異步的，需要群數據獲取後發出一個通知，同時 page onload 在監聽這個通知，收到通知後才能開始渲染頁面，這樣才能避免渲染出一個空的群相冊。
2.列表滑動加載更多的實現
「群影」首頁是個可以不停往上滑動加載更多的頁面。實現起來就是，使用小程序提供的 onReachBottom 事件。事件發生時，向後臺發起請求下一屏照片的數據，數據返回後，追加到原有的照片數組中，然後調用一次 setData 重新渲染。
這裡有些同學可能會有疑問，如果已經加載了 100 張照片，再請求 10 張，那麼相當於要重複渲染之前的 100 張照片，這樣會不會越來越慢呢？
其實不會。因為 wxml 的 for 循環有一個key 屬性，我們可以在 key 屬性填寫一個唯一 id 去標識當前照片，那麼當追加照片後頁面重新渲染的時候，小程序根據 key 屬性會發現前面 100 張照片其實都已經渲染過了，只需要渲染後面追加的 10 張照片即可。
3.其他開發要點
小程序開發還有幾個需要注意的優化點：
第一，多用小程序提供的組件。例如上下滑動的用 scroll-view，左右切換用 swiper，圖片用 image，這些控制項有可能用的原生客戶端實現的，性能和體驗都比 web 好很多，所以在做小程序的時候，先看看小程序組件有沒有滿足需求的，沒有才去做新的組件。
第二，如果一個 view 需要來回切換顯示和隱藏兩種狀態，使用 display:none 而不是 wx:if。因為前者並不會刪除節點，重新顯示的時候不需要重新渲染，而 wx:if 需要重新渲染。
第三，不要頻繁去 setData()。因為每次 setData() 都會觸發一次頁面的渲染，所以同一個方法裡儘量集中一次性 setData()。
基礎入門講解，小程序開發並非難事
Q：對於學生開發小程序，你覺得會是一件很難的事情嗎？
A：小程序的開發門檻是最低的，我簡單講講小程序的入門你們大概就能了解。
如圖所示，我們直觀地看到，一個小程序由 1 個 App 全局定義和多個 Page 定義組成，App 定義有 3 個文件，每個 Page 定義有4 個文件。
app.js 文件提供了 3 個小程序生命周期接口，分別是啟動，顯示和隱藏。一般會在 onLaunch 或者 onShow 做登陸，在 onShow 獲取群消息。
另外，在 app.js 定義的所有數據和方法，將能在所有頁面中訪問到。通常我們會把全局的數據放這裡，例如群影小程序的群名和群 id 都是放在這裡，這樣所有頁面都可以用到這個數據。
app.wxss 定義所有頁面通用的樣式，app.json 定義所有頁面通用的頂部標題欄的樣式。
再看看 page 定義，比 app 多一個 wxml 文件，負責頁面渲染邏輯。 wxml 相當於html+wxml 語法+小程序控制項。 wxml 語法很簡單，整體上只有 if else、for、雙大括號 3 種語法，利用這些簡單的語法就可以容易地做出動態的頁面。小程序為開發者提供了圖片、幻燈片、地圖、滾動列表等等豐富的移動端組件，能夠大大減少開發成本。
page.js 相對於 app.js 看起來複雜，實際上，主要完成一件工作，就是渲染頁面。一般而言，我們會在在 onLoad/onShow 編寫後臺請求代碼，獲取到數據後，調用 setData 接口，setData 會自動通知 page.wxml 渲染新內容，渲染完成後，頁面需要跟用戶交互，例如點擊某個按鈕，輸入框輸入等，這就由小程序定義好的 bindtap、bindinput 事件完成。
小程序一般不只一個頁面，頁面間的跳轉一般使用 navigateTo 就夠了。最後，就是頁面可以調用微信生態 api，這裡我們開發者當然希望越多好，例如 open-data 可以獲取群信息，request-payment 可以拉起微信支付等等。
到此，概括下，一個小程序就是由 1 個 app 定義，多個 page 定義組成， app 負責登錄和全局數據， page 負責渲染單個頁面。
這裡用代碼再講講
wxml 加 setData 的渲染方式。左邊的代碼，是傳統的web代碼，使用了DOM API getElementById 和 innerHTML 去將 Hello world 渲染到頁面上。右邊是小程序代碼，直接將狀態變量 msg 定義在 wxml 中，然後 js 使用 setData 通知 wxml 渲染，非常直觀簡單。
隨著頁面複雜性的增加，後面可能需要對內容增刪，重排序，甚至多種 DOM API 操作的組合，會使得渲染邏輯代碼大幅增加，而小程序的 js 文件只需要關注狀態變量的操作即可，配合 wxml 語法大大降低開發難度。
移動端開發需要考慮不同尺寸屏幕的適配。在小程序裡，這變得很簡單，因為小程序把每塊屏幕都抽象等寬的 750 相對像素 rpx，舉個例子，已知屏幕寬 750，圖片間隔 12，一行放 2 張圖片，求每張圖片的寬度？這是個簡單的數學問題。小程序通過提供 RPX 讓多屏幕適配問題變成了簡單的數學問
通過這個簡短的小程序開發入門，我們會發現，小程序的整體組成簡單，而且使用wxml, setData, wxss又進一步簡化了我們的 web 開發工作。
Q：你前面談到「群影」用到了騰訊優圖的人臉識別技術，如果高校開發者想在小程序中實現某個技術難度比較高的功能，可以用類似的方法嗎？
A：可以的。「群影」是調用了騰訊優圖的 api 接口，人臉識別&截圖顯示和顏值評分功能都是通過騰訊優圖的能力來實現的。
開發者如果要實現某個功能其實也可以合理利用各大網際網路公司免費的 api 接口，功能實現更成熟，相對來說也節省時間。比如說你想實現地圖導航的功能，自己去開發一個就太難了，但是你可以調用騰訊地圖的 api 接口；同樣的，你想做一個音樂或者電影的榜單，可以用 QQ 音樂、豆瓣電影等平臺的api 接口。
校園環境是痛點很多的開發場景
Q：對於學生開發小程序，卻不知道做什麼好，你有什麼建議嗎？比如說怎樣才能發現身邊的痛點？
A：校園生活應該是很容易發現需求的，最直接的，你就從你最想吐槽的地方出發。比如打開水、幫人帶飯、學校的門禁等，這些在校園生活中是很多人的痛點。這次大賽的初衷也是鼓勵大家運用微信生態小程序平臺開發技術解決實際問題。
Q：要做一款小程序，怎樣挖掘核心需求？比如你可能會想要實現很多功能，怎樣判斷這些需求的優先級？
A：要明確小程序的定位，做它的初衷是什麼，真正要解決的用戶痛點是什麼，也就是核心需求。
我在群影開發前期也有很多想法想要實現，包括後來外部評測大家提出的評論和 p 圖功能。然後我用思維腦圖的形式寫下了這些需求，如果不寫下來，這些想法在你腦子裡是平行的，你會覺得什麼都想做，但是思維腦圖有一套邏輯體系，呈現出來後，你就能更明確這裡面的輕重主次。
Q：你怎樣看待有些小程序在某一陣子比較火，之後又歸於沉寂？
A：一款產品能火爆，說明它是解決了用戶的某個需求的，但是做爆款也有很多機遇性的因素。有些產品的用戶量相對較少，也不是很活躍，那可能說明它不是一個常用的產品，但不能說明它不是一個有用的產品。比如群影，你肯定不會每天都用到，但是過半年你再回頭發現以前的一些照片回憶，那時候的感覺是不一樣的。
另外，如果要增加小程序的用戶量，要多關注前期的用戶留存率和用戶分布情況，通過這些數據看產品吸引的用戶是否符合設想的預期，看沒有挖掘到用戶有哪些，能不能繼續挖掘到他們。
群影上線後前兩天的用戶數據是很出乎意料的，我設想的它的受眾是年輕人，但實際留存的以中老年居多。中老年人注重保存回憶，而年輕人可能更傾向於未來。
再就是，要儘可能多的找人試用，驗證小程序是否解決了用戶的真實需求。
Q：在微信中開發小程序與其它產品開發相比，有哪些特別的地方？
A：小程序相較於 web，優點是很多的。小程序天生擁有微信生態，例如微信群，微信支付，做出的 app 能夠通過關係鏈傳播，群影小程序也是這樣傳播出去的。
小程序的學習成本相對於傳統 web 要低，setData wxml 語法簡單，不需要像 web 去寫複雜的 DOM 操作，或者要學習更難一些的 MVVM 框架，而且組件很豐富，足以應付大部分移動場景。小程序有 750rpx 自適應布局，多屏幕適配變得更簡單。
小程序的技術基於 web，但是做了許多優化，體驗接近於原生，而做 web 需要精心設計才有可能做出流暢的體驗。小程序發布後，mp 後臺會有小程序數據統計，pv, uv，用戶畫像，開發可以根據數據做出產品改進的決策。
另外，小程序發布之前是需要經過審核的，所以小程序最好按照迭代開發，並且每次發布前要經過足夠的測試。