首先感受下效果：

項(xiàng)目地址 https://github.com/dongweiming/weapp-zhihulive

限于公眾號(hào)文章篇幅的限制，只能將具體的小程序代碼實(shí)戰(zhàn)和我的經(jīng)驗(yàn)放在下篇了。今天我先介紹下我對(duì)小程序的一些理解以及用盡量少的篇幅介紹小程序背后的技術(shù)的發(fā)展歷程。

我對(duì)小程序的看法

我一向不喜歡跟風(fēng)。小程序剛出的時(shí)候一大波人吹捧，一個(gè)月后一大堆人看衰，全然忘記曾經(jīng)的話，其實(shí)臉被打的是啪啪啪。

引用我點(diǎn)過贊的一個(gè)對(duì)于小程序發(fā)布一個(gè)月的表現(xiàn)如何的大司馬大將軍的回答：

互聯(lián)網(wǎng)時(shí)代，人們更加沒有耐心——沒耐心到以至于30天時(shí)間，就有人開始對(duì)小程序“蓋棺定論”了。這真是一件讓人悲哀的不知道該說啥的事。

具體的回答內(nèi)容限于篇幅就不展開了。

當(dāng)我真正的用它開發(fā)，實(shí)踐了產(chǎn)品需求。我對(duì)它持觀察態(tài)度：

1. 生態(tài)太過封閉。微信想的是用戶不斷的進(jìn)行「手機(jī)開機(jī) —> 微信 —> （社交+購(gòu)物+吃飯+金融...） —> 手機(jī)關(guān)機(jī)」的循環(huán)，但是別的公司想的是「微信 —> 小程序 —> 獲得粉絲 —> 引流或者引導(dǎo)用戶下載APP感受完整版」，大家各懷鬼胎，但是誰(shuí)都不蠢。

2. 相關(guān)限制太多（分享按鈕、誘導(dǎo)分享）。

3. 入口不好找。

期待小程序的下一步。

頁(yè)面設(shè)計(jì)思路

術(shù)業(yè)有專攻，我有個(gè)缺點(diǎn)，就是設(shè)計(jì)頁(yè)面會(huì)懵... 如果沒有設(shè)計(jì)圖讓我憑空去想我很痛苦，比如這個(gè)小程序，我一開始是按著知乎APP的配色和Live相關(guān)內(nèi)容的布局做的，但是越到后來(lái)越發(fā)現(xiàn)效果我不喜歡。現(xiàn)在的主色、發(fā)現(xiàn)頁(yè)、話題頁(yè)是抄襲了https://github.com/romoo/weapp-demo-breadtrip的感覺，加上了一些我的理解。其他的頁(yè)面是我自己對(duì)Live產(chǎn)品的理解做的。

小程序完成的功能

我之前在我的知乎Live以及回答的一些問題中都提到過，一定要找個(gè)機(jī)會(huì)寫一個(gè)相對(duì)復(fù)雜的項(xiàng)目深入你要學(xué)習(xí)的技術(shù)，只看文章、書、視頻效果其實(shí)是很差的，只有實(shí)踐了才真的能記住和理解。

那對(duì)我來(lái)說，這個(gè)小程序就是學(xué)習(xí)效果的產(chǎn)出，這也是我平時(shí)學(xué)習(xí)東西的方式。在一開始的時(shí)候我就基于對(duì)知乎Live的理解，給自己列出了小程序要完成的功能：

1. 發(fā)現(xiàn)頁(yè)。用戶一登錄就看到的頁(yè)面，展示了一些基于我的理解的算法排序的Live。

2. 7/30天最受歡迎的Live。知乎也有，但是我對(duì)它那個(gè)順序不太滿意：小眾的Live太難上榜，評(píng)分低但是收入高的Live排的靠前。在豆瓣，要是國(guó)產(chǎn)電影3-4分但是由于票房很高就排得很高，你們想想我們會(huì)被怎么罵。

3. 熱門話題頁(yè)面/話題篩選。我開始有這個(gè)小程序的想法的時(shí)候，知乎還不能基于分類去篩選Live，不方便。

4. 搜索。當(dāng)時(shí)還沒有搜索，現(xiàn)在的搜索也比較雞肋吧，就是個(gè)簡(jiǎn)單的關(guān)鍵詞匹配，都不能模糊查詢（比如搜索pythno就找不到符合的Live）。

5. 個(gè)人頁(yè)面，社交必備元素了，包含個(gè)人信息以及其主講的Live列表。

6. 基于多種條件對(duì)主講人排序。

我以前說過，我不反對(duì)造輪子，關(guān)鍵是造的得有意義。就是你要造的東西能解決你的痛點(diǎn)，比如我這個(gè)就是由于知乎提供的功能不滿足我的需求（比如當(dāng)時(shí)想找個(gè)某關(guān)鍵詞的相關(guān)Live，只能用「site:zhihu.com live python」這樣的方式Google），以及它提供的排序價(jià)值觀我不太認(rèn)同。作為工程師最大的好處（其實(shí)是會(huì)寫爬蟲的工程師），不滿意我就寫一個(gè)。不過這個(gè)小程序只能平靜的躺在本來(lái)開發(fā)環(huán)境里面。

要不然造輪子，造著造著容易棄坑

基于上面說的需求，我不斷的更新這個(gè)專題直到今天（昨天的MVVM都是給今天做鋪墊）。

組件化思想

關(guān)于「組件化」網(wǎng)上有很多寫的很不錯(cuò)的文章，推薦大家去看看。我特別喜歡美團(tuán)點(diǎn)評(píng)團(tuán)隊(duì)的博客中提到的下面這句話：

Controlling complexity is the essence of computer programming.

隨著前端開發(fā)復(fù)雜度的日益提升，組件化開發(fā)應(yīng)運(yùn)而生，并隨著React等優(yōu)秀框架的出現(xiàn)遍地開花。大家都在各種嘗試努力的「Controlling complexity」。

我試著介紹下組件化發(fā)展的歷史（去掉一些已經(jīng)夭折、不看好的部分，只保留相關(guān)的主流）。

我們先討論什么是組件？其實(shí)我們?nèi)粘ｉ_發(fā)（尤其是前端開發(fā)）接觸到的component、widget、module、plugin就是組件，缺點(diǎn)是大家實(shí)現(xiàn)不統(tǒng)一，使用方式也不統(tǒng)一。到了2011年，Alex Russell提出了「Web Component」：

1. Custom Element: 自定義HTML元素

2. shadow DOM: 封裝

3. HTML Imports: 打包一切

4. HTML Template: Lazy的DOM模板

JavaScript本來(lái)是一門作為瀏覽器上的腳本語(yǔ)言出身，并不適合于大規(guī)模開發(fā)。同年Google提出的MDV（Model-Driven Views）框架，提出了我們也需要像對(duì)待后端系統(tǒng)一樣對(duì)前端邏輯進(jìn)行統(tǒng)一管理、分層(表現(xiàn)邏輯、viewmodel、視圖)。所以Backbone、AngularJS、Ember之類的數(shù)據(jù)綁定框架橫空出世了，力求給我們帶來(lái)代碼的模塊管理、數(shù)據(jù)、視圖的分離，他們以他們不同的方式解決共同的問題：

1.如何更好地模塊化開發(fā) 2.業(yè)務(wù)數(shù)據(jù)如何組織 3.界面和業(yè)務(wù)數(shù)據(jù)，業(yè)務(wù)邏輯的分離

與此同時(shí)為了用戶體驗(yàn)的要求，HTML5和ECMAScript也在快速的推進(jìn)。2013年，Google推出了新的UI框架Polymer，它的實(shí)現(xiàn)使用了WebComponent標(biāo)準(zhǔn)，并且Polymer可保證針對(duì)包含各種平臺(tái)的Web Component規(guī)范本地實(shí)現(xiàn)的瀏覽器、庫(kù)和組件的使用效果完全相同。它代表了下一代的web組件方向：一切皆組件、盡量減少代碼量、盡量減少框架限制。

同年，React并沒有采用Web Components的方案，以高性能虛擬Dom為切入點(diǎn)，在Facebook的造勢(shì)下，社區(qū)得到了大力發(fā)展。官方說React傾向于做傳統(tǒng)MVC架構(gòu)中的View層。不同于AngularJS，所以用起來(lái)很自由（可以在大項(xiàng)目中的一個(gè)小組件上使用）。

我在工作中多次用到React。其實(shí)一開始有種顛覆前端開發(fā)的感覺，熟悉后感覺卻覺得這種方式非常舒服。

說了這么多，什么是組件化呢？

我還是引用張?jiān)讫埨蠋煹睦斫猓˙TW，他的博客真得好好看看呢，最后的參考資料有）：

1. 頁(yè)面上的每個(gè)獨(dú)立的可視/可交互區(qū)域視為一個(gè)組件；

2. 每個(gè)組件對(duì)應(yīng)一個(gè)工程目錄，組件所需的各種資源都在這個(gè)目錄下就近維護(hù)；

3. 由于組件具有獨(dú)立性，因此組件與組件之間可以自由組合；

4. 頁(yè)面只不過是組件的容器，負(fù)責(zé)組合組件形成功能完整的界面；

5. 當(dāng)不需要某個(gè)組件，或者想要替換組件時(shí)，可以整個(gè)目錄刪除/替換。

RN/Weex/小程序

隨著移動(dòng)設(shè)備類型的變多，操作系統(tǒng)的變多，用戶需求的增加，對(duì)于每個(gè)項(xiàng)目啟動(dòng)前，大家都會(huì)考慮到的成本，團(tuán)隊(duì)成員，技術(shù)成熟度，時(shí)間，項(xiàng)目需求等一堆的因素。因此，開發(fā)App的方案已經(jīng)變得越來(lái)越多了。曾經(jīng)有一段HTML5的小浪潮，無(wú)數(shù)的人參與或者看到過一個(gè)討論：原生（Native App）開發(fā)還是混合（Hybrid App）開發(fā)？原生開發(fā)顯然是最可靠的方案。但是學(xué)習(xí)成本，人才成本，開發(fā)效率以及照顧不同平臺(tái)的特性去考慮，都成為了開發(fā)人員心目中的一道坎。

混合開發(fā)的直白的解釋是 Native 和 Web 技術(shù)都要用，兼具「Native App 良好用戶交互體驗(yàn)的優(yōu)勢(shì)」和「Web App 跨平臺(tái)開發(fā)的優(yōu)勢(shì)」。促使開發(fā)者在移動(dòng)開發(fā)中使用 Web 技術(shù)主要?jiǎng)恿υ谟冢啾扔?Native 技術(shù)，Web 技術(shù)具有諸多優(yōu)勢(shì)：

1. HTML，CSS，JavaScript 的組合被證明在用戶界面開發(fā)方面具有很高的效率。

2. 統(tǒng)一的瀏覽器內(nèi)核標(biāo)準(zhǔn)，使得 Web 技術(shù)具有跨平臺(tái)特性。iOS 和 Android 可以使用一套代碼。

3. 可越過發(fā)布渠道自主更新應(yīng)用。

豆瓣為此也有了一些混合開發(fā)實(shí)踐，有興趣的可以看最后的文章。

早期的混合開發(fā)有一些缺點(diǎn)：

1. 受限于Webview（手機(jī)中內(nèi)置的瀏覽器控件）的性能限制, 相比原生而言有不少損耗, 體驗(yàn)無(wú)法和原生相比

2. 不適用于交互性較強(qiáng)的app

RN(React Native)是Facebook在React.js Conf 2015上推出的一個(gè)框架，結(jié)合了 Web 應(yīng)用和 Native 應(yīng)用的優(yōu)勢(shì)，可以使用 JavaScript 來(lái)開發(fā) iOS 和 Android 原生應(yīng)用。在 JavaScript 中用 React 抽象操作系統(tǒng)原生的 UI 組件，代替 DOM 元素來(lái)渲染等。它給我的感覺是不同于HTML5，也不同于原生，更像是用JS寫出原生應(yīng)用。它的優(yōu)點(diǎn)很多：

1. 雖然說開發(fā)成本大于Hybrid模式，但是小于原生模式，大部分代碼可復(fù)用

2. 性能體驗(yàn)高于Hybrid,不遜色于原生

3. 開發(fā)人員單一技術(shù)棧，一次學(xué)習(xí)，跨平臺(tái)開發(fā)

4. 社區(qū)繁榮，遇到問題容易解決

那一天，我發(fā)了個(gè)QQ狀態(tài)：感覺JS要一統(tǒng)江湖了。

Vue（view的法語(yǔ)）于2014年2月對(duì)外發(fā)布，它采用MVVM數(shù)據(jù)綁定，有著簡(jiǎn)潔的API，是一個(gè)用于構(gòu)建Web界面的庫(kù)。我們可以用 Vue 擴(kuò)展出來(lái)的ViewModel子類當(dāng)做可復(fù)用的組件。這在概念上與Web Components非常相似，但是帶了數(shù)據(jù)綁定、動(dòng)畫系統(tǒng)等上層功能。Vue和Polymer在功能上和API上比較相似，不同之處在于Vue的組件無(wú)需(IE9+)任何polyfill（描述復(fù)制缺少的API和API功能的行為，可以使用它編寫單獨(dú)應(yīng)用的代碼而不用擔(dān)心其他瀏覽器原生是不是支持）。

2016年6月，阿里無(wú)線前端開源了無(wú)線電商動(dòng)態(tài)化解決方案Weex，特點(diǎn)是輕量級(jí)，性能很高，官方給出的口號(hào)是 “Write Once Run Everywhere”。由于這個(gè)輪子太像Vue + React-Native（可以稱為Vue-Native），后來(lái)Vue作者尤雨溪加盟Weex項(xiàng)目擔(dān)任技術(shù)顧問...