小程式跨平臺開發解決方案探索

微信正式推出微信小程式後，各個大廠陸續釋出了各自的小程式平臺 —— 支付寶小程式、百度小程式、頭條小程式，跨小程式平臺開發也成為了眾多小程式開發者要面臨的問題。

Antmove - 小程式跨平臺解決方案

小程式開發血淚史

小程式發展初期

• 框架不穩定
• 更新頻繁
• bug 眾多

隨著微信小程式的發展，微信小程式以基本不存在上述的問題，而其它新興的小程式廠商則還在此階段，對於小程式開發者來說，如果要接入微信小程式之外的平臺，以上的問題是技術方案評估環境必須要衡量的問題。

小程式發展中期

• 開發體驗提升
• 元件式開發需求
• 與 web 開發技術生態的融合

在這個階段，小程式開發者追求的是開發體驗，在 web 框架蓬勃發展，開發工具生態飛速完善的環境下，槽糕的小程式開發體驗是使用者不能忍受的，這個階段也出現了許多的小程式框架極力的解決這個問題，如 wepy、mpvue、taro 等。

小程式發展成熟期

• 多平臺支援需求
• 包體積
• 效能

到今年以來，除微信小程式平臺外，其它廠商小程式平臺也得到了極大的推動發展，這時小程式跨平臺能力就顯得尤為重要，同時與之相對的包體積控制小程式效能也成為關注點，這也是目前眾多企業和開發者面臨的問題。

小程式跨平臺開發解決方案探索

小程式跨平臺開發，簡單來說就是通過一套解決方案實現開發一次，上線到多個小程式平臺。

解決方案

為滿足多小程式平臺的需求，簡單來說可以有以下的解決方案：

• 各平臺單獨開發
  • 人力成本高
• 開發某一個平臺小程式，通過技術實現到其它平臺的轉換
  • 技術實現成本高，小團隊難以支撐
• 使用支援跨平臺的小程式框架開發，依賴於框架的跨平臺能力，實現跨平臺
  • 引入框架成本

對於第三種方案來說，目前社群中比較熱門的小程式跨平臺開發解決方案有 mpvue、taro、uni-app 等。這些框架不同程度的解決了小程式跨平臺開發的問題，但他們都存在一個飽受詬病的問題，那就是框架之痛。在前端開發的發展過程中，從前端框架出現到百花爭鳴，到現在的三足鼎立（Angular、React、Vue）時代，開發者依然會因如下的 問題而頭疼：

• 是否應該在專案中引入框架？
• 應該選擇什麼樣的框架，更好？更適合？
• 在效能面前，應該選擇框架還是採用原生開發？
• 團隊開發技術棧統一之爭？
• 老專案維護問題，技術升級之痛？
• 該框架的未來發展是怎樣的？

作為小程式的開發者，依然會面臨這樣的問題，而且會更加嚴重，小程式本身就是一個框架（而且小程式框架發展很快，功能也在不斷完善，開發體驗也越來越好），在小程式之上又包一層框架，整個開發流程多了一環，無疑會增加專案的風險。而且小程式框架本身還在不斷的發展，以微信小程式為例，新特性、能力、規範不斷的更新，框架如何短時間的更新適配就成為一個難題。而依賴框架之後，開發者與原生小程式隔離開來，不得不依賴框架方提供解決方案。

除了框架能力的支援適配，引入框架還會使得專案本身變得臃腫、緩慢、約束。

解決方案之 Antmove

在高德小程式開發團隊（阿里系小程式的一員【支付寶小程式、淘寶應用、釘釘應用、天貓精靈等】）的工作中，我們遇到了許多想將微信小程式應用上線到阿里系小程式平臺的客戶，而重新開發一個新平臺的小程式對他們來說又比較耗成本，為了解決這個問題，螞蟻搬家工具應運而生，我們的出發點很簡單，希望能夠通過技術手段將一個微信小程式應用上線到阿里系小程式平臺上。

隨著這個過程的進行，我們發現使用者除了有對阿里系平臺的需求外，還有對其它小程式平臺支援的需求，所以又有了其它廠商小程式平臺的支援。

多小程式平臺支援

目前百度智慧小程式、頭條小程式的支援還在內測，即將可以體驗。

從最初的客戶服務案例到現在的 antmove 開源專案，我們整個團隊考慮過很多，作為一個非 KPI 專案，我們會持續的將它做好，希望能幫助更多的小程式開發者解決他們遇到的問題。

Antmove 不是一個框架，而是一個轉換工具，比如將微信小程式專案轉換為支付寶小程式專案，它更多的還是希望開發者能使用原生的小程式語法去開發小程式，更小、更快、更簡潔。

到目前為止，Antmove 工具已經幫助了眾多的內部使用者和外部小程式開發者實現小程式的轉換遷徙，現在也希望它能夠幫助你解決跨平臺開發的難題。

參考連結

• Antmove - 讓小程式跨平臺開發不再困難