原生小程序跨平臺實現（微信/支付寶/百度）？

前言

微信推出小程序平臺以來，國內各大公司陸續跟進，帶來了小程序的繁榮。從開發者的視角，咱們看到小程序開發者變多，各類小程序技術方案不斷出現。

• 小程序加強型開發框架的出現
• 小程序原生框架能力擴充，典型的有 wepy/mpvue
• 小程序跨端開發框架的出現

* 經過編寫一套代碼，實現多個小程序平臺運行，典型的有 taro/uniapp

• 小程序與 web/native（app）融合的技術需求出現

* 因 小程序/web/native 平臺差別較大，雖然有許多框架進行了嘗試，但還處於蠻荒時代，未出現獲得一致承認的方案

而這繁榮的背後也顯得雜亂，影響開發者選擇適合的技術方案。基於此，咱們作了一次小程序跨平臺開發方向的調研，並得出以下建議：

需求場景	推薦技術方案
只開發微信小程序應用	推薦採用原生小程序開發方式
已有微信小程序項目，當下考慮拓展到支付寶/百度等平臺	1. 推薦使用 Antmove 小程序轉換器，可一鍵轉換到其它小程序平臺 2. 推薦使用 taro，taro 提供了微信小程序到 taro 代碼轉換，再基於 taro 代碼轉換爲其它小程序平臺的能力 3. 推薦使用 uniapp，uniapp 語法與微信較爲接近，須要人工改造爲 uniapp 代碼，而後轉換爲其它平臺小程序代碼
小程序新業務，無跨端需求	推薦採用原生小程序平臺開發
小程序新業務，有跨端需求	推薦採用 taro/uniapp/Antmove

原生小程序如何實現多平臺投放？

從咱們的瞭解來看，目前小程序市場，大部分仍是微信小程序應用，其次是支付寶小程序，百度小程序。對這幾端的融合也是目前比較切合需求場景的需求。基於此，咱們調研了從微信小程序到其它端的轉換的狀況，幫助你們瞭解如何快速實現微信小程序到其它小程序的遷徙。

說明： 如下測試結果基於微信官方微信小程序 demo 調研而得

Antmove 小程序轉換器

• 官網：https://ant-move.github.io/gu...
• Github：https://github.com/ant-move/A...

Antmove 是目前小程序轉換開源解決方案裏成熟度最高的，經過 Antmove 轉換器，能夠一鍵將微信小程序轉換爲其它平臺小程序，也能夠將支付寶小程序轉換爲其它平臺小程序，目前還在持續維護更新。

基於 Antmove 的多端開發相關介紹能夠從這裏瞭解

taro

介紹：Taro 是一套遵循 React 語法規範的 多端開發 解決方案。
Github: https://github.com/NervJS/tar...

Taro 本質上是一套自定義語法的跨端開發方案，但官方提供了微信小程序轉換爲 taro 代碼的工具，基於此，用戶能夠藉助於 taro 將微信小程序轉換爲 taro 代碼，而後再將其轉換爲對應平臺的小程序代碼。

不足

• 須要進行兩次轉換才能能夠獲得對應平臺的代碼
• 功能支持狀況不是很理想，以下爲將微信小程序官方 demo 轉換爲 taro，再轉換其它平臺的測試狀況

• 轉支付寶：

  • 目前轉碼後點擊事件失效，轉碼後框架上函數有報錯，邏輯須要從新寫
  • setData函數運行失敗，項目沒辦法使用

• 轉百度小程序

  • 界面（不支持，須要修改的）

    • flex相關樣式設置失敗
    • button報錯，getLaunchOptionsSync沒有處理
    • map
    • 顯示隱藏指南針
    • 開啓俯視功能

  • 接口（不支持，須要修改的）

    • 登錄
    • 支付
    • 客服消息
    • 生物認證
    • 藍牙
    • iBeacon
    • 搜索WIFI
    • 上傳視頻和圖片
    • 動態加載字體
    • 儲存數據報錯
    • 多線程計算

• 轉頭條小程序

  • 目前轉碼後點擊事件失效，轉碼後框架上函數有報錯，邏輯須要從新寫
  • setData函數運行失敗，項目沒辦法使用

注： 目前轉碼工具初始化微信小程到taro代碼會有圖片路徑處理錯誤，須要手動修改一下

總結

• 工具總體體驗流暢，其設計核心是用react語法使用工具提供的API和組件完成項目開發，而後一鍵生成多端小程序
• 目前對原生小程序（微信）轉到taro的問題比較多，可是總體可以完成轉碼，只是轉碼後須要花費必定的精力從新處理各類問題

uniapp

介紹： uni-app 是一個使用 Vue.js 開發全部前端應用的框架，開發者編寫一套代碼，可發佈到iOS、Android、H五、以及各類小程序（微信/支付寶/百度/頭條/QQ/釘釘）等多個平臺
Github： https://github.com/dcloudio/u...

微信小程序轉換 uniapp 代碼指南

官方轉換遷徙指南說明

總結

• 須要手工將微信小程序改形成 uniapp 應用
• 非官方版本有一個轉換工具，但轉換不理想，測試微信官方 demo 轉換報錯
• 單純開發多端小程序這個框架仍是比較好用的，可是轉碼微信小程序沒有一鍵轉碼功能，須要手動配置大量的文件，其開發成本比較高

mpx

介紹：相同風格的語言開發開發多端小程序的開發框架，語言風格相似小程序，支持雙向數據綁定
Github：https://github.com/didi/mpx.git

結論

• 不一樣的小程序須要搭建不一樣的開發環境，並作好相應的配置，
• 不支持原生小程序轉換，但支持使用原生小程序組件/頁面，對於完整的小程序轉換成本較高

說明：除了 Antmove 轉換器外，其它方案解決方案的初衷是基於 react/vue 或自定義語法的角度來實現多端，因此微信小程序轉換到多端這一轉換流程並不包含來這些框架的全部能力和優點，對於原生小程序遷移到其它平臺本文調研結果能夠參考。

非小程序語法多端方案對比

這裏主要指採用非小程序語法開發小程序應用。
非小程序語法開發業務代碼方案已有諸多的調研和說明，可參考以下連接：

• 小程序開發：用原生仍是選框架（wepy/mpvue/uni-app/taro）？
• Chameleon
• 深刻測試一週，主流多端框架大比武~by DCloud

關於小程序跨平臺開發的見解

存在的問題

從上面咱們能夠看到隨着小程序的繁榮，跨端融合這個概念被提得愈來愈多，也出現了許多解決該問題的框架。但這真的表明着跨端開發的繁榮嗎？

我以爲還不是，小程序和 web，小程序和 native app存在着自然的差別化，這是很難彌補的，雖然社區上有出現了不少的方案，但都還不能說成熟。

只考慮小程序這一平臺，差別性會小一點，但想作到徹底的一套代碼，多個小程序平臺運行仍是很難。這裏有如下幾個緣由：

• 各大廠商採用本身的小程序技術框架，難以進行標準化
• 小程序會自帶廠商基因，能力差別化

雖然有如上的差別，但依然小程序間的跨平臺仍是看到了必定的可能性，這也是目前小程序跨端方案出現這麼多的緣由。

依然美好

雖然上面說起了跨平臺開發的不足，但其優點依然存在，一套代碼多處運行充滿了誘惑。當咱們將全端的要求下降，只考慮某些平臺的狀況下，已經出現了較爲成熟的方案。

大多數狀況下其實咱們須要的只是某一端或是幾端的融合，在 taro 的統計示例中咱們能夠發現，微信小程序應用佔比達 90%，即大多數的應用只用 taro 開發了微信小程序。uniapp 也提到絕大多數應用只用其來開發其中一端的應用。在 Antmove 的統計中，絕大部分的用戶也只是微信小程序和支付寶小程序兩端的融合要求。

在小程序以前，多端融合就已經被說起推出，在前端領域中，react 在這方面作得比較成功。在 react 學習一遍，便可多處編寫的理念下，較低成本的實現了多端的需求，如 react-web/react-native/react-sketch 等，也所以構建了豐富的 react 生態。

除了 react 體系外，以下的方案則切實的實現了某些平臺的跨端

• flutter - 高性能移動端跨平臺框架
• electron - PC 應用跨平臺開發工具
• QT

• 小程序

  • taro/uniapp/Antmove/rax/mpx/cml

暢想將來，設備複雜化是個必然的趨勢，而這也更考驗着跨端技術方案是否足夠成熟。