前言

微信推出(chu)小(xiao)(xiao)程(cheng)(cheng)序平臺(tai)以(yi)來，國內各(ge)大(da)公司陸續跟進，帶來了小(xiao)(xiao)程(cheng)(cheng)序的(de)繁(fan)榮。從開(kai)發者(zhe)的(de)視角，我們看(kan)到小(xiao)(xiao)程(cheng)(cheng)序開(kai)發者(zhe)變多，各(ge)種小(xiao)(xiao)程(cheng)(cheng)序技術方案不斷出(chu)現。

• 小程序增強型開發框架的出現
• 小程序原生框架能力擴充，典型的有 wepy/mpvue
• 小程序跨端開發框架的出現
  * 通過編寫一套代碼，實現多個小程序平臺運行，典型的有 taro/uniapp
• 小程序與 web/native（app）融合的技術需求出現
  * 因 小程序/web/native 平臺差異較大，雖然有許多框架進行了嘗試，但還處于蠻荒時代，未出現得到一致認可的方案

而這繁榮的(de)背后也顯得雜亂，影響開(kai)發(fa)(fa)者選擇適(shi)合(he)的(de)技術方(fang)案。基于(yu)此，我們(men)做了一次小程序(xu)跨平臺開(kai)發(fa)(fa)方(fang)向(xiang)的(de)調研(yan)，并得出如下(xia)建(jian)議(yi)：

 

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

從我們的了解來看(kan)，目(mu)前(qian)小(xiao)(xiao)程(cheng)(cheng)序市(shi)場(chang)，大部分還是(shi)微(wei)(wei)信(xin)小(xiao)(xiao)程(cheng)(cheng)序應用，其(qi)次是(shi)支付(fu)寶(bao)小(xiao)(xiao)程(cheng)(cheng)序，百度(du)小(xiao)(xiao)程(cheng)(cheng)序。對這(zhe)幾(ji)端的融合也(ye)是(shi)目(mu)前(qian)比較切(qie)合需求場(chang)景的需求。基于(yu)此，我們調研(yan)了從微(wei)(wei)信(xin)小(xiao)(xiao)程(cheng)(cheng)序到(dao)其(qi)它端的轉換的情況，幫助(zhu)大家了解如何(he)快速實現微(wei)(wei)信(xin)小(xiao)(xiao)程(cheng)(cheng)序到(dao)其(qi)它小(xiao)(xiao)程(cheng)(cheng)序的遷徙。

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

Antmove 小程序轉換器

• 官網：ant-move.github.io/guide/
• Github：

Antmove 是目前(qian)小程序(xu)轉(zhuan)(zhuan)換(huan)(huan)(huan)開源解決方案里(li)成熟度最高的，通過 Antmove 轉(zhuan)(zhuan)換(huan)(huan)(huan)器，可以一鍵將微信小程序(xu)轉(zhuan)(zhuan)換(huan)(huan)(huan)為其(qi)(qi)它平臺(tai)(tai)小程序(xu)，也(ye)可以將支付(fu)寶小程序(xu)轉(zhuan)(zhuan)換(huan)(huan)(huan)為其(qi)(qi)它平臺(tai)(tai)小程序(xu)，目前(qian)還在持(chi)續維護更(geng)新。

基于 Antmove 的多端開發相關介紹(shao)可以從這里(li)了解

taro

 介紹：Taro 是一(yi)套遵循 React 語(yu)法規范的 多端開發 解決方案(an)。

Github: 

Taro 本質上是一(yi)套自定義語(yu)法的跨端(duan)開發(fa)方案(an)，但(dan)官方提供了微信(xin)小(xiao)程序轉(zhuan)換為 taro 代(dai)(dai)碼的工具(ju)，基于此，用戶可(ke)以借助于 taro 將微信(xin)小(xiao)程序轉(zhuan)換為 taro 代(dai)(dai)碼，然后再將其轉(zhuan)換為對應平臺的小(xiao)程序代(dai)(dai)碼。

不足

• 需要進行兩(liang)次轉換才能可以得到對應平臺(tai)的代碼(ma)

• 功能支持情(qing)況(kuang)不(bu)是很(hen)理想，如下為(wei)將微(wei)信小(xiao)程序官方 demo 轉換(huan)為(wei) taro，再轉換(huan)其它平臺的測試情(qing)況(kuang)

• 轉支付寶：

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

• 轉百(bai)度小程序(xu)

  • 界面（不支持，需要修改的）
    • flex相關樣式設置失敗
    • button報錯，getLaunchOptionsSync沒有處理
    • map
    • 顯示隱藏指南針
    • 開啟俯視功能
  • 接口（不支持，需要修改的）
    • 登陸
    • 支付
    • 客服消息
    • 生物認證
    • 藍牙
    • iBeacon
    • 搜索WIFI
    • 上傳視頻和圖片
    • 動態加載字體
    • 儲存數據報錯
    • 多線程計算

• 轉(zhuan)頭條小程序

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

注： 目前(qian)轉碼(ma)工具初始(shi)化(hua)微(wei)信小程到(dao)taro代碼(ma)會有圖片路(lu)徑處理(li)錯誤，需要手動修改一下

總結

• 工具整體體驗流暢，其設計核心是用react語法使用工具提供的API和組件完成項目開發，然后一鍵生成多端小程序
• 目前對原生小程序（微信）轉到taro的問題比較多，但是整體能夠完成轉碼，只是轉碼后需要花費一定的精力重新處理各種問題

uniapp

介紹(shao)： uni-app 是一個使用(yong)(yong) Vue.js 開發(fa)所有前端應用(yong)(yong)的框架(jia)，開發(fa)者編寫一套代碼(ma)，可(ke)發(fa)布到iOS、Android、H5、以及(ji)各種小程序(xu)（微信/支付寶/百度/頭條/QQ/釘(ding)釘(ding)）等多個平(ping)臺

Github： 

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

總結

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

mpx

介紹(shao)：相同(tong)風格的(de)(de)語(yu)言開發開發多端小(xiao)程序的(de)(de)開發框架，語(yu)言風格類似小(xiao)程序，支持雙向數據綁定 Github：

結論

• 不同的小程序需要搭建不同的開發環境，并做好相應的配置，
• 不支持原生小程序轉換，但支持使用原生小程序組件/頁面，對于完整的小程序轉換成本較高

說明：除了 Antmove 轉(zhuan)(zhuan)換(huan)器外，其它方案(an)解決方案(an)的初(chu)衷是基于(yu) react/vue 或自定義(yi)語法的角度來實現多(duo)端，所以(yi)(yi)微信小程序(xu)轉(zhuan)(zhuan)換(huan)到多(duo)端這(zhe)一轉(zhuan)(zhuan)換(huan)流程并不包含來這(zhe)些框架的所有能力和優勢，對于(yu)原生小程序(xu)遷移到其它平臺本文調研結果(guo)可(ke)以(yi)(yi)參(can)考。

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

這里主要(yao)指采用(yong)非小(xiao)程(cheng)序(xu)語法開發小(xiao)程(cheng)序(xu)應用(yong)。 非小(xiao)程(cheng)序(xu)語法開發業務代碼(ma)方案已有(you)諸多(duo)的調(diao)研和(he)說明，可參考如下鏈接：

• 小程序開發：用原生還是選框架（wepy/mpvue/uni-app/taro）？
• Chameleon

關于小程序跨平臺開發的看法

存在的問題

從上面我們可(ke)以看到隨著(zhu)小程序的(de)繁榮，跨(kua)(kua)端(duan)融(rong)合(he)這(zhe)個概念被(bei)提得越來越多(duo)，也出(chu)現了許多(duo)解決(jue)該問題的(de)框架。但這(zhe)真的(de)代表著(zhu)跨(kua)(kua)端(duan)開(kai)發的(de)繁榮嗎？

我(wo)覺得還不是，小程序(xu)和 web，小程序(xu)和 native app存在著天然的差異化，這是很(hen)難彌補的，雖然社區上有出(chu)現了很(hen)多的方案，但(dan)都還不能說成熟。

只考(kao)慮小(xiao)程(cheng)序(xu)這(zhe)一平臺，差(cha)異性會(hui)小(xiao)一點，但想做到(dao)完全的一套代碼(ma)，多(duo)個(ge)小(xiao)程(cheng)序(xu)平臺運行還是很難。這(zhe)里有以下幾個(ge)原因(yin)：

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

雖然有(you)如上的(de)差異，但(dan)依然小(xiao)程(cheng)序間的(de)跨(kua)平(ping)臺還是看到了一(yi)定的(de)可能(neng)性，這(zhe)也是目前(qian)小(xiao)程(cheng)序跨(kua)端方案出現這(zhe)么多(duo)的(de)原因。

展望未來

雖然上(shang)面提及了跨平臺開(kai)發(fa)的(de)不足，但其優勢(shi)依然存在，一(yi)套代碼多處(chu)運行(xing)充(chong)滿了誘惑。當我們將全端(duan)的(de)要(yao)求降低，只考(kao)慮某些平臺的(de)情況下(xia)，已(yi)經出現了較為成熟的(de)方案。

大(da)(da)多數(shu)情況下其實我們需(xu)要(yao)的(de)(de)只是(shi)某一端或是(shi)幾端的(de)(de)融合，在 taro 的(de)(de)統計示例中我們可以發現，微(wei)(wei)信小(xiao)程序(xu)應(ying)用占(zhan)比達 90%，即大(da)(da)多數(shu)的(de)(de)應(ying)用只用 taro 開發了(le)微(wei)(wei)信小(xiao)程序(xu)。uniapp 也(ye)提到(dao)絕(jue)大(da)(da)多數(shu)應(ying)用只用其來開發其中一端的(de)(de)應(ying)用。在 Antmove 的(de)(de)統計中，絕(jue)大(da)(da)部分的(de)(de)用戶(hu)也(ye)只是(shi)微(wei)(wei)信小(xiao)程序(xu)和(he)支(zhi)付寶(bao)小(xiao)程序(xu)兩端的(de)(de)融合要(yao)求。

在小程(cheng)序之前，多端(duan)融合就已經被提及(ji)推出，在前端(duan)領域(yu)中，react 在這方面做(zuo)得(de)比較成功。在 react 學習一遍，即可多處編(bian)寫(xie)的(de)理念(nian)下，較低成本(ben)的(de)實現了多端(duan)的(de)需求，如 react-web/react-native/react-sketch 等(deng)，也因此構(gou)建了豐富的(de) react 生態(tai)。

 除(chu)了 react 體(ti)系外，如下的方(fang)案(an)則切實的實現了某些平(ping)臺的跨(kua)端

• flutter - 高性能移動端跨平臺框架
• electron - PC 應用跨平臺開發工具
• QT
• 小程序
  • taro/uniapp/Antmove/rax/mpx/cml

暢想(xiang)未來，設備復(fu)雜化是(shi)個必然的趨勢，而這(zhe)也更(geng)考(kao)驗著跨(kua)端(duan)技(ji)術(shu)方案是(shi)否足夠成熟。