小程式—新移動時代下的風口
小程式這個名詞從 2017 年 1 月出現至今，兩年時間內，這個新技術剛開始從備受爭議、質疑，到現在全面融入生活的各個場景中，其中微信小程式的數量突破了 230 萬個，微信小程式的成功當然有微信自身龐大的使用者量以及其社交屬性的因素，但是也不能否定小程式作為一個新的方向的成功。所以在 2018 年 我們所能夠看到的是越來越多的網際網路巨頭開始涉入小程式這個領域，如支付寶小程式、百度智慧小程式、今日頭條小程式，還有在概念上類似於小程式的快應用、QQ 的輕應用等。
隨著巨頭的入場和未來小程式的開源，大量的頭部 App 都將具備搭載小程式的能力，所以我們有理由相信小程式終將打破 App 所形成的資訊孤島，實現“去中心化”，讓移動網際網路真正地互聯互通，更加開放和包容。
個人認為小程式是在商業化領域一次很成功的探索，小程式這種產品形態所帶來的商業意義遠大於它的技術影響（僅個人愚見）。姑且來一次馬後炮，分析下促使小程式產生的一些因素。
-
網際網路早期人口紅利消失，流量蛋糕被巨頭瓜分
在當前這種網際網路形式下，企業面臨的一個困境是自然增長速度慢，而通過商業流量比如廣告以及活動形式，一個普遍的問題是獲客成本增加且轉化率逐步降低。在這種困境下自然窮則思變，探索新的商業模式，小程式則應運而生。
-
小程式是各大網際網路巨頭佈局全景流量，構建生態閉環的重要一環。
以百度為例，在百度的生態環境中，百度在需求鏈裡扮演的角色往往是需求的“發起者”，人們通過百度搜尋或者地圖服務去搜尋需求相關的資訊，但是之後往往就會脫離百度生態，進入別的 App，這樣對百度而言自然就缺少一個流量轉化的場景。在這種場景下自然很難構成生態閉環，而小程式則是解決流量轉化問題的有效方案。
-
相較傳統 APP，成本更低，使用更加便利。
- 在今年的阿拉丁年會上，阿拉丁創始人&CEO 史文祿的一句話給我留下深刻的印象：“越是經濟下行的時候，我們更應該做小程式，因為小程式相比 App 革命性降低了開發、運營和推廣成本，更縮短商業模式週期。” 相較於傳統的 App，小程式相當於基礎設施已經搭建好，等著商家“拎包入住”，在開發，運營以及推廣上面，平臺提供相關的服務，當然也是需要在平臺的監管和規則下執行。但是相較於自己從 0 到 1 搭建相關基礎設施，成本優勢自然就體現出來了。
- 通過小程式可以方便使用者與線下生活場景進行連線。如在餐飲、零售、工具等場景中一些小程式充分體現了“即用即走”的特點，相比 App 獲客效果更好，其便利性自然更受使用者喜愛，同時也方便一些企業高效搭建會員體系，在經營流量的同時積累自身的使用者。
網上介紹微信小程式的文章有很多，在此我就不再贅述。百度的智慧小程式作為依附於百度 App 這個搶佔了搜尋和資訊流流量入口，日活高達 1.6 億的流量巨頭，自然未來可期，而且目前百度也是在主推智慧小程式，所以這篇文章我還是想著重介紹下百度智慧小程式（畢竟查了好多資料）。
百度智慧小程式帶來的流量之變
相信看到這裡的小夥伴心裡都會有一個疑問，相比於微信和支付寶小程式，百度智慧小程式有什麼優勢呢？下面我就百度小程式自身的流量玩法做下簡單解讀。
-
全域流量開放以及共築策略
為了快速佈局小程式，百度在流量以及資源方面拿出了相當大的誠意，具體體現在以下幾個方面。
- 開放三大流量入口：百度開放三大超級入口，包括搜尋、資訊流、固定入口。
- 為智慧小程式開放千億級別的使用者流量。
- 舉辦系列百度智慧小程式公開課，從產品，運營和技術層面給與詳細講解以及思路啟發（嗯，手把手教學，包教包會~）。
-
需求入口優勢
相較於微信側重於社交，支付寶之於商業與生活服務，百度在搜尋領域作為使用者需求的起點，再結合百度智慧分發的演算法 ，自然就可以與使用者的切實需求相關聯，進而導流到相關小程式中（嗯，重點是導流，導流，導流），這是可以結合百度自身特點來創造一些新的流量玩法，比如說如何在官方規則下獲取更多優質，實惠的流量，如何合理通過運營將公域流量轉化為自身私域流量。
-
開放
百度小程式採用的是全面開源策略，幫助開發者擴充更多百度內外流量，與快手 、B 站、愛奇藝組成 MAU (月活躍使用者人數)高達 30 億（未去重）的開源聯盟，實現一次開發多處使用。在開源這個問題上，正符合網際網路發展中的一貫策略，即第二名和第三名推行開源，聯合起來期求達到彎道超車的做法。百度的這種形式真的很容易聯想到安卓和 iOS 對峙的場景，除卻一些巨頭 App，大多數中小型公司可能並沒有太多的資源和流量去支援自己的小程式，但也捨不得這塊蛋糕，在這樣的場景下加入百度的開源聯盟也不失為一種好的選擇。個人也比較期望未來小程式可以更加的標準化，而不是市場上各種小程式混戰的局面，畢竟相容各個平臺的小程式寫起來真的很累呀~。
小程式商業推廣助力產品營銷
相對傳統廣告推廣，使用者下載 App 進而安裝、註冊、消費的形式，小程式形式的商業推廣能夠有效的減少轉化步驟。並通過訂單訊息推送、小程式歷史訪問記錄、資訊流商品自動推薦等方式可以有效幫助商家提升留存和復購。
根據官方公佈的資料中，通過商業推廣，攜程的智慧小程式訪問深度對比 H5 提升了 150%，小紅書使用者人均沉浸時長對比 H5 提升了 50%；截止 18 年十一月 ，1200 家商家已經接入百度智慧小程式。
付費推廣在我看來是百度智慧小程式相對於其他小程式一些優勢，根據產品的發展給予合適的助力，結合百度的智慧推薦演算法，必然可以大大節約推廣成本。在這種助力下，商家必然會在拉新、轉化和留存等環節得到全面的提升，從而帶給商業推廣全新的想象空間和新的紅利。
開發體驗 && 學習成本 && 開發成本 && 專案遷移難度
-
開發體驗
我是 18 年初的時候開始接觸小程式，剛開始是做 PC 端開發，嗯，後來因為
老大一聲令下業務擴充的關係開始了小程式的漫漫踩坑路，截止到現在小程式也做很多。例如在上家單位開發的企鵝洗衣小程式，還有目前在做的青團社兼職小程式（偷偷打個廣告）的開發。emm,小程式裡面常見的功能基本上都是有過一些瞭解的,怎麼也算是踩坑經驗豐富了吧 ?。言歸正傳，對於開發者而言，開發體驗真的是繞不過去的部分了，總體來說支付寶和微信小程式的開發體驗還是挺好的，除了因為微信小程式後續變更的幾個 API 導致加了幾次班並且順便被測試妹子提了幾個線上 bug，以及糾結了好幾個日夜解決支付寶的表單元件的樣式以及相容性問題（尤其是在華為和小米手機上面，真的是血淚教訓）等等。鑑於單位最近有可能再將業務擴充到百度系小程式這一塊，提前體驗一下百度智慧小程式。
-
IDE 部分
- 編輯器 相信大家都不會使用官方 IDE 自帶的編輯器的，畢竟 vscode 大法好，SWAN 相關的 API 自動補全，語法高亮，程式碼格式化的相關外掛都是可以找到的（嗯，找不到的可以私聊我，包教包會）。
- 新建頁面/元件 順帶一提在 IDE 裡面的右鍵新建頁面/元件功能對於新手來說比較友好，畢竟會自動生成一系列模板檔案。
- APP data 部分 可以顯示頁面中通過 setData 改變 data 的歷史記錄，這個必須好評。微信和支付寶是沒有這個功能的，但是微信是可以直接在除錯工具中修改 data 資料，在開發中很有用（沒用過的同學可以腦補下在 Vue 開發中需要使用 Vue Devtools 直接改變 data 資料的場景）。順帶提一點百度開發者工具更新迭代的很快，希望開發小哥可以儘快支援此項功能 ?。
- 網路部分 百度、支付寶、微信沒有太大差異（畢竟這部分出自同一家）。
- Swan 部分 對應 Chrome 的 Element 部分。 頁面結構部分支援手動修改類名，樣式的動態修改也是支援的。對於元件的支援也不錯，元件結構一目瞭然。目前發現的缺點頁面結構內的文字部分不支援手動增刪。這部分初步體驗感覺與微信不相上下。
-
自定義元件
不支援元件的框架肯定是噩夢（本人有幸經歷過這段黑暗時期，雖然也有一些 trick 可以解決，但是畢竟還是會被噁心到），所幸目前微信、支付寶、百度智慧小程式都是支援元件的，下面介紹下智慧小程式的元件部分：
- 父子元件通訊有 properties， dispatch 和 triggerEvent 三種方式。
- 元件有自己的生命週期，且可以監聽頁面的部分生命週期。
- 支援 slot 語法（見到這個真的是很驚喜，在做微信小程式的時候就總想著要是有 slot 就舒服多了 ?），是設計高可複用元件的基礎之一。
-
其他一些實用/有趣的部分
- Filter 部分 簡要看了下，很實用。對應 Vue 的 Filter 功能。微信小程式也有類似的功能。
- 分包載入 因為小程式限制程式碼包大小，分包相當於為開發者提供更大的發揮空間，而且提高載入速度，優化了效能，目前微信小程式開放了此項功能，支付寶暫不支援。
- 模組化 三方均支援模組化，順帶一提，微信小程式不支援相對路徑引用。
- 檔案作用域 支援區域性定義域。
- 登入流程 在使用者已登入宿主賬號的情況下整個登入流程可以完全靜默完成，不需要使用者手動點選、手動點選、手動點選。
- 遊客賬號 官方對於這一點的解答是這樣的 “在未登入的時候，將資料與使用者的 SwanID 關聯，當使用者登入後，通過 SwanID 找到使用者登入前的資料，然後與 OpenID 關聯，比如常見的場景例如電商類小程式對購物車資料的同步。”。可以方便遊客登入這類功能的實現，即不需要使用者註冊就可以體驗產品功能並且在使用者註冊以後可以繼承遊客 賬號的一些獎勵等，可以減少 在使用者因為牴觸在剛接觸產品時就必須要註冊登入而導致的流失。
-
-
學習成本
對於 vue 熟練使用者，基本上學習成本就是熟悉 API 吧，emmm；對於 react 技術棧的開發者，難度也不是很大，可以採用這種 react 風格的第三方框架，例如 taro； 對於原本就是使用小程式第三方框架開發者（taro/mpvue/Okam 等），就更不用擔心，因為去相容百度小程式是框架開發者需要考慮的事情（逃~）。
-
開發成本
因為小程式本身就在 web 技術體系內，如果之前就有過微信小程式開發經驗，那麼看看文件就可以動手開發了（畢竟 三家小程式的 API 風格極其相似，你懂得），如果沒有小程式開發經驗，問題也不大，畢竟小程式也是採用 html + js + css “三駕馬車”的方式，只不過是需要學習一種新的類 Vue 語法。順帶一提，百度智慧學院裡面還是有不好技術乾貨的，可以幫助剛開始接觸小程式的同學少走不少彎路。
-
專案遷移難度
對於有過微信小程式轉支付寶經歷的人，最討厭的事情莫過於 API 字首的轉換，以及一些語法的轉換（不要問我怎麼知道的 ?）。百度在這點上做的還是比較貼心的，特地提供一個遷移助手幫助開發者解決一些基本的 API 字首以及指令符的轉換，使開發者不必將太多時間花費在這樣繁瑣的事情中，只需要將主要精力放在業務邏輯中。
為什麼是新的創意賽道
結合百度的 AI 能力，打破技術壁壘，重新回到業務的理解和創意的賽道上。
智慧小程式中已經開放包括語音技術、影象技術、人臉和人體識別、AR 與 VR 、視訊內容分析對比技術在內的 20 項 AI 能力且以後會逐步開放更多。
目前，已經有一些比較成功將創意與 AI 有機結合的實踐 ，例如“愛說唱”這款基於百度的語音 AI 技術孵化出來的智慧小程式，可以將使用者朗讀的歌詞自動合成說唱歌曲。對於我五音不全的人感覺像是發現了新大陸[二哈]。還有智慧小程式“AI 分診助手”，使用者只需要新增對自身症狀的描述，小程式就可以使用一系列 AI 功能得到最佳的匹配結果，從而達到智慧分診的效果。
以上的例子都還只是一些 AI 與創意如何結合的探索，百度智慧小程式這個名字中的智慧充分體現對 AI 能力寄於的希望。可以預見的是當每個人都能平等便捷獲取 AI 能力，技術壁壘不復存在時，創意在這樣的環境中必將結出豐碩的果實。
個人認為百度智慧小程式目前是正處於發展的紅利期，這也符合網際網路公司一貫的套路，平臺前期肯定是投入遠大於回報，百度在小程式上目前就是大量投入資源的時期，這個時期搭上百度這艘快艇必然是最好的選擇，大樹底下好乘涼的道理相信大家都懂。
以上都是一些自己的看法，限於個人能力，文中如有錯漏之處，還請大家不吝賜教。