如果你的 App 要實現一個功能，你最先考慮的承載方式是什麼？

原生？H5？

之前我們要在 App 實現一個功能的時候，一般是優先考慮把功能放在 H5 裡實現，如果不行的時候再考慮用客戶端來實現。

之所以按這個優先順序來做決策，是因為客戶端和 H5 相比起來劣勢太多了。

隨便舉幾個例子。

增大安裝包體積。安裝包體積增加有不少弊端，首先就是頻寬成本高。每次發版都消耗你一大推的流量。還有就是拉新困難，在推廣的時候，你讓使用者下載十分鐘，使用者直接就點取消就走了。
升級版本困難。用 H5 開發一個新功能，一發布，全網就都生效了。而用客戶端，你等去吧，沒個幾個月根本就覆蓋不全。
多次開發。在一家公司裡，往往 iOS 和 Android 都是不同的團隊。一旦放在客戶端，就意味著得實現兩遍。雖然現在有了 Flutter，但是覆蓋還是全。

但是有些功能又必須得放在客戶端裡實現，比如需要很強的快取能力、需要訪問通訊錄、呼叫硬體、訪問藍芽啥的，再或者比如想要流暢的體驗。這些功能 H5 都是無法支援的。

碰著這些情況，功能就必須得放在客戶端組去搞。即使是有上述困難也得硬著頭皮上。

再來說下我們團隊之前遇到的現實問題。

由於眾多的原因，一直以來我們的功能都攪在客戶端裡實現，經常被領導說發版太慢（關鍵我們也根本快不了啊），每次發版還得把多個團隊的功能合併進來，你也不知道哪個組的程式碼有問題，所以測試得非常嚴謹才行。

不光是測試，還得經過過各種小流量的灰度。根本不敢快，否則一旦有問題的包放出去，收都收不回來。

後面組裡的一位大神提到：這種問題在伺服器端也曾經存在，這個問題的根源就是軟體行業工程裡面的“高耦合”。過多的功能都耦合在一個 App 裡出現各種各樣的問題是必然的。在過去伺服器端也是所有功能都用單體的方式來實現，也是大量的功能都耦合在一起。一旦某個程式碼有問題，可能全網就都崩潰了。但現在已經很好地解決了。

早在十多年前，騰訊內部就秉承大服務小做的方式來對服務進行拆分。在今天，更是有了微服務以及各種配套的基礎設施來對伺服器端進行解耦。所以現在伺服器端無論是發版速度，還是穩定程度都比十年前要好了很多。

整個團隊瞬間就被點醒。

在客戶端上，這個問題確實不好解決。但是忽然轉念一想，哎，迭代頻率特別高的功能是不是用小程式就能實現呀？像微信支付寶那樣，把各種外圍的功能都以小程式的方式來提供。

一部分是穩定的、最常用的、也是久經考驗的功能，其他功能可以是敏捷變化的小程式。小程式可以由不同的團隊獨立開發，自由釋出，不會影響核心功能

這樣，就既能享受客戶端的高許可權，就又能擁有快速的發版速度。但仔細一想，這個思路挺不錯，但是想實現一個小程式平臺，估計投入不少，價效比太低了。

後面經過技術調研，其實業界早就有例如 FinClip 這樣的產品做了小程式容器，也就是透過整合 SDK 的方式讓 App 擁有小程式執行能力。

方案部署了以後，確實新功能的發版的速度有了明顯提升。

一來大量外圍的功能都可以小程式化了，不再需要等待主版發版。

第二就是天然支援 iOS、Android、Windows、Mac多個平臺，一次開發，四處部署。

而且還有個優點，天然相容微信小程式，這樣公司客戶的微信小程式也都能遷移過來，幫助加強 App 的能力。

小程式容器（沙箱）是否可以解決App頻繁發版問題？

相關文章