大眾點(diǎn)評微信小程序開發(fā)談小程序開發(fā)步驟

小程序開發(fā)步驟已經(jīng)是當(dāng)下最熱門的話題，下面將從多方面來談?wù)劥蟊婞c(diǎn)評微信小程序開發(fā)相關(guān)的內(nèi)容。

小程序以上特征要求我們只為用戶提供核心服務(wù)，且從產(chǎn)品到技術(shù)，都必須圍繞「簡約」二字做文章。因此，結(jié)合大眾點(diǎn)評業(yè)務(wù)場景，最終在「大眾點(diǎn)評+」中，我們主要提供以下兩種基礎(chǔ)服務(wù)：

1. 快速找店：通過搜索、分類列表和推薦三種形式，讓用戶快速找到商戶，并提供包括定位、電話、點(diǎn)評、菜品等商戶信息，幫助用戶做出決策
2. 購買團(tuán)購：為用戶推薦團(tuán)購商品并實(shí)現(xiàn)交易閉環(huán)，幫助用戶獲得實(shí)惠

產(chǎn)品層面足夠精簡，我們再來看看技術(shù)層面如何做到簡約。

我們先看下項(xiàng)目之初開發(fā)同學(xué)的困惑：

• 小程序是個新鮮事物，參與開發(fā)的同事普遍對開發(fā)流程和運(yùn)行原理知之甚少
• 在不知道小程序有多少坑的前提下，我們還是要保證在小程序開放前完成全部基礎(chǔ)功能的開發(fā)，存在著不少風(fēng)險(xiǎn)
• 小程序的接口穩(wěn)定性和豐富程度、安全性、連接速度等究竟如何

對于任何新生的應(yīng)用場景，開發(fā)環(huán)境、工具和框架不夠完善都可以理解，但如何才能既保證開發(fā)過程的簡單又提供一定的規(guī)范和工程化能力?為此，在遵從小程序基本框架的前提下，我們做了如下技術(shù)選型和簡單封裝：

1. 項(xiàng)目區(qū)分開發(fā)目錄和構(gòu)建目錄，在開發(fā)目錄中進(jìn)行開發(fā)，再通過 gulp 對開發(fā)目錄進(jìn)行構(gòu)建(主要處理壓縮等基本功能)，構(gòu)建目錄才是小程序真正的運(yùn)行代碼
2. 引入 npm 的 package.json，解決開發(fā)依賴的管理、請求接口的版本化管理，但不使用任何 npm 包(只復(fù)制一份 promise 實(shí)現(xiàn))
3. 只使用 ES6 語法，配合 eslint，快速檢查基本 JS 錯誤，(現(xiàn)階段小程序報(bào)錯提示不夠友好，部分錯誤由 JS 語法錯誤引起)
4. 對小程序提供的 JS-API 進(jìn)行 promise 封裝，代碼以 promise 風(fēng)格書寫，以便 catch 各種運(yùn)行時的錯誤

開發(fā)過程中的「坑小程序平臺差異

• 小程序會在開發(fā)者工具、iOS 設(shè)備和 Android 設(shè)備運(yùn)行，不同平臺可能存在實(shí)現(xiàn)上的差異，從而導(dǎo)致少許的展現(xiàn)不一致。不過總體來說，兼容問題比起之前的開發(fā)方式減少很多，期望小程序團(tuán)隊(duì)進(jìn)一步做好底層兼容，為前端程序員造福。

開發(fā)思維和技術(shù)限制

• 沒有 BOM\DOM 操作，只能通過數(shù)據(jù)改變視圖
• 再次強(qiáng)調(diào)小程序最多支持5級頁面
• 開發(fā)代碼 + 小程序編譯封裝的代碼 = 最終的編譯包 < 1M

針對上面提到的問題，我們通過自己的實(shí)踐總結(jié)了一套解決方案，這里也與開發(fā)者一起分享討論：

在開發(fā)過程中，我們肯定以開發(fā)者工具為主完成開發(fā)及調(diào)試，但這不代表在真機(jī)能獲得與預(yù)期完全一致的展現(xiàn)。在過往開發(fā) hybrid 框架的經(jīng)歷中，我們也總會遇到 iOS、Android、H5 表現(xiàn)不一致的問題，這里既涉及到底層實(shí)現(xiàn)的差異，也涉及到不同開發(fā)團(tuán)隊(duì)的溝通問題，這個問題很難一勞永逸地被完美解決。

web 服務(wù)支持

web 接口版本化

開發(fā)思維的轉(zhuǎn)變

因此，有些常見方案的實(shí)現(xiàn)思路就要發(fā)生轉(zhuǎn)變，包括但不局限于以下的操作：

• 類似微信通訊錄的錨點(diǎn)切換(可以使用微信的 scroll-view 實(shí)現(xiàn))
• 計(jì)算內(nèi)容的高度決定截行 + 顯示「展開/收起」開關(guān)

解決這個問題，其實(shí)大致有三種思路：

• 優(yōu)化產(chǎn)品交互流程，盡量簡化產(chǎn)品流程直到少于5級
• redirectTo 思路，在頁面達(dá)到第五級之后，后續(xù)所有頁面打開都通過redirectTo方式。帶來的問題也顯而易見，如果用戶在第N個頁面點(diǎn)擊返回，他只能看到第四個頁面，中間的 N-5 個頁面都不見了，適用于特定場景
• goBack 的思路，采用技術(shù)手段保證主流程只有5級(在我們的實(shí)現(xiàn)中，既有把搜索功能作為頁面的一個狀態(tài)而非頁面的方式，也有把訂單提交后以 redirectTo 的方式銷毀當(dāng)前頁面的辦法)，之后通過統(tǒng)一封裝頁面路由的方式，采用 getCurrentPages 接口判斷當(dāng)前頁面是否在歷史堆棧中，沒有則通過 navigateTo 接口打開，有則通過 goBack 的方式返回，在頁面?zhèn)?onShow 事件中去讀取最新的參數(shù)信息，完成頁面的更新動作

最后，我們單獨(dú)來聊一聊代碼體積優(yōu)化的問題。

雖然現(xiàn)階段大眾點(diǎn)評+僅提供了找店和團(tuán)購兩個主要功能，但 1M 的代碼量畢竟太小，為了在 1M 的體積下把更多的功能和更好的體驗(yàn)帶給用戶，并未為以后的擴(kuò)展預(yù)留足夠的空間，這就要求我們在代碼的體積控制上必須「斤斤計(jì)較」。

會把我們項(xiàng)目的 json、wxml、wxss、js 全部轉(zhuǎn)化為 js，合并成一個文件上傳到微信云服務(wù)器。當(dāng)用戶第一次打開小程序時再從服務(wù)中下載并解析。以我們的項(xiàng)目為例，通過工具的壓縮和統(tǒng)計(jì)，在我們計(jì)算出項(xiàng)目體積達(dá)到了~370K，經(jīng)過微信編譯上傳，在手機(jī)端預(yù)覽下載時，下載的文件達(dá)到了~540K，這正是開發(fā)者工具顯示告訴我們的編譯包大小。

開發(fā)層面：

• <span style="font-size: 16px; font-family: " microsoft="" yahei";"="" yahei";="" line-height:="" 2;"="" line-height:2;font-size:16px;"="">精簡 wxml，我們發(fā)現(xiàn)當(dāng) wxml 被編譯成 js 后會占用非常大的體積(減少一個壓縮后 4K 的 wxml，可以減少編譯包 9K)