我自認為對新技術還是比較有熱情的,可對於小程式這個“新技術”,我卻完全是被動的。去年9月份的時候,微信小程式開始內測,瞬間引爆朋友圈、知乎等一眾分享平臺。當時我大概瞭解了一下,覺得從技術角度上來說沒啥新意,也完全沒有get到網上那些人激動的點在哪裡,於是也就沒有花很多精力去深入瞭解和學習相關知識。到 ...
我自認為對新技術還是比較有熱情的,可對於小程式這個“新技術”,我卻完全是被動的。去年9月份的時候,微信小程式開始內測,瞬間引爆朋友圈、知乎等一眾分享平臺。當時我大概瞭解了一下,覺得從技術角度上來說沒啥新意,也完全沒有get到網上那些人激動的點在哪裡,於是也就沒有花很多精力去深入瞭解和學習相關知識。到了11月份,我和幾個小伙伴去北京參加CSDN 舉辦的 SDCC,我特意去聽了微信專場,滴滴團隊的小程式經驗分享乾貨十足,卻依然讓我覺得這個“新技術”無論是從技術角度還是從用戶場景角度,都沒什麼吸引人的地方。今年1月9日,小程式正式發佈,一下子又引爆了一眾網路媒體,連我身邊很多非IT圈的人都在找我瞭解討論小程式的事情。這次我再也坐不住了,畢竟雷布斯說過“只要站在風口豬也能飛起來”,更何況背靠騰訊的張小龍,颳起的很可能是龍卷風。於是我向公司提出申請,註冊了一個小程式賬號,開始嘗試開發一個給公司員工使用的辦公助手。接著我就遇到了一些列問題。
-
程式大小限制
剛剛開始研究不久我就發現,每次預覽的時候,微信開發者工具都會提示你編譯包的大小是多少。因為微信小程式要求編譯包的大小不能超過1MB,1MB大概有多少呢,我給大家舉個例子,我們之前用 Vue 開發過一個 OA 系統的手機版,不包括任何第三方依賴,所有代碼 zip 壓縮之後是400KB。我們的這個手機版 OA 實現了大概 10 個的功能,只有PC版的1/6不到,沒有用任何圖片資源,所有的圖標都是用 font-face 實現的。小程式這個 1MB 的大小限制就註定了你的程式只能是一個簡化版,大家可以去看看現在已經上線的微信小程式,如滴滴出行、京東購物、捲皮折扣等等,全都是簡化版。
-
沒有消息推送
我們面對的第二個問題就是,微信小程式不能主動進行消息推送。雖說現在很多 app 沒事推送各種廣告確實挺讓人神煩,但是完全不能做任何消息推送也不行啊,畢竟這可是剛性需求。比如我們準備做的 OA 系統,沒有消息推送弊端真的非常多,比如,有會議待開,有審批單待簽,有論壇帖子@到,所有這些東西都完全無法通知用戶了,那麼作為一個 OA 系統,連提醒功能都沒有,做手機版的意義就已經大打折扣了。同樣的,社交類 APP,購物類 APP 都有很多對消息推送存在剛需的場景,小程式裡面,這些都實現不了了。
-
不完善的語法
其實微信小程式的語法和 Vue 是非常相似的,以至於小程式剛剛內測的時候,有人還去知乎上提問說小程式的底層是不是 Vue 實現的。可是,實際看了小程式的開發文檔之後你就會發現,小程式的指令實在是太簡單了,目前除了數據綁定、條件渲染、列表、模板、事件、引用 之外基本上沒有其他的功能了。而反觀 Vue 的開發文檔,你會發現兩者是天壤之別。API 太過繁雜會增加了很多學習成本也不是好事。可是像小程式這麼簡單的 API,提供的功能肯定是非常有限的,自然也帶來了很多開發上的不便。比如,在 Vue 裡面,你可以用很多不同的變數往同一個元素上面綁定很多不同的 class,在小程式上就沒這麼簡單了。
-
沒新意的架構
其實沒有新意的架構並不能算小程式的缺點,只是模仿優秀者,而且模仿的還很像,這並不是很麽壞事。可是,作為騰訊的力推產品,大家自然對它各個方面的期待都更高一些,就好像蘋果公司這幾年的發佈會,雖然也在一隻推陳出新,可是畢竟都不是什麼劃時代的設計或功能,於是大家紛紛表示蘋果已經不是原來那個蘋果了。對前端開發來說,如果小程式的架構和 Vue、React 都類似,那麼我們又為什麼要從 Vue 和 React 轉來用小程式呢?
-
不突出的性能
小程式剛剛開始內測的時候,很多人猜測小程式是不是和 ReactNative 以及 Weex 一樣把類似 HTML 的各種標簽渲染成了手機端原生組件,從而使程式的運行流暢度大大提高。然後目前來看,事實並不是這樣,在 Android 手機的開發選項中開啟“顯示佈局邊界”之後,你就可以發現,其實小程式說白了還是一個 webview,而且很多人在體驗過小程式之後也發現,界面的流暢度和瀏覽器相比並沒有什麼明顯的提高。
-
更封閉的體系
小程式的整個體系是封閉的,從代碼編輯器到調試環境到運行環境,全都是騰訊出的,而且目前來看全是閉源方案。包括後期的上線審核,可搜索的關鍵字設置等等方面,全都是騰訊一家說了算,頗有蘋果的作風。做過 iOS APP 的同學應該是對蘋果的行事風格有體會的,說要下架你的 APP 就下架,招呼都不打,你想去找他溝通,幾天沒人理你。
上面這些都是我從開發的角度去看小程式的問題。可能很多人會覺得不服,認為光有程式員思維是不行的,很多事情並不僅僅是技術那麼簡單。那下麵我就從運營的角度來說說小程式還有哪些問題。
-
流量不足
小程式剛剛提出的時候,很多人覺得機會來了,一個很重要的原因就是大家都覺得有微信這個超級流量平臺,小程式的流量肯定會非常可觀,可是結果大家都看到了。小程式不能在朋友圈分享,只能在聊天場景分享,可是大家回憶一下,一般人在聊天的時候會經常給別人分享 APP 麽?另外,小程式沒有所謂的應用市場,也就沒有排名和榜單,只能搜索,而且除了個別非常知名的 APP 或品牌名稱,比如京東,其他的 APP 只能精確搜索。另外,所謂的線下掃描二維碼進入小程式,老實說,我想不出來有什麼線下場景一定要用戶掃描一個二維碼進入小程式才能進行下去。如果只是付款,完全可以直接掃碼支付,如果是註冊會員,完全可以掃碼之後只顯示一個註冊頁面。小程式的入口就是這麼模糊。
-
功能太弱
就算有些用戶經過重重阻礙,終於掃面二維碼進入了小程式,他接著就會發現,小程式的功能由於其編譯包大小的限制,往往顯得有點力不從心。對比一下京東的原生 APP 和京東的微信小程式,我們不難發現,京東的微信小程式版基本上把京東 APP 裡面 80% 的功能都看掉了。如果你是個技術男現在只是想買一條手機數據線,你可能可以在小程式上搜索數據線,查看某條搜索結果的詳情,感覺不錯就買了。可是如果你要是個妹紙想買條裙子,小程式顯然不能滿足你反覆比較挑選的需求。
微信小程式剛剛推出的時候,有人說微信除了小程式,很多 APP 都可以卸載掉了,還舉例說比如天氣 APP 和計算器 APP。可在我看來,這兩個 APP 都不可能被小程式取代。天氣 APP 最重要的就是天氣信息的主屏幕提醒,小程式做不到。計算器都是各個手機系統自帶的功能,小程式更沒有機會。就算手機系統不自帶計算器,用戶是希望在主屏幕上點一下打開,還是希望先打開微信,然後切換到發現選項卡,再進入小程式欄目,最後選擇計算器功能?
-
“用完即走”
微信小程式提出了一個概念叫“用完即走”。這個想法聽起來好像很人性化很替用戶著想,可事實上這個需求是非常“小眾”的需求,甚至可以說是偽需求。用戶只對一些低使用頻率,又非用不可的 APP 才有這種需求,比如旅游類 APP。首先旅游類 APP 的使用頻率低,用戶不太可能每個星期去旅游,另外你不用好像也確實不方便。再比如某些酒店的會員 APP,你在住酒店的時候用它可以帶來很多切實的方便和優惠。可大家在深入想想,我們出去旅游的時候,旅游類 APP 是只用一次還是在一小段時間內頻繁使用?顯然是後者,那我們為什麼不在這一小段時間內安裝一個旅游的 APP,過了這一段時間之後再刪掉?畢竟全功能的 APP 在各個方面來說都更好用。
我覺得,小程式其實從一開始就沒有打算去取代現有的原生 APP,它只是對現有 APP 生態的一個補充和完善,可以說是一個面向小眾細分市場的產品。同時,對張小龍和騰訊來說,微信小程式可能更是微信對生態圈建設的一次嘗試。