把小程式整合到App中，可能比你想的還要簡單

語言: CN / TW / HK
時間 2023-02-23 10:15:11

theme: juejin highlight: androidstudio

引言

對於 Android 或者 ios 開發同學而言，小程式 這個詞，似乎離我們很遠又很近，或者在 客戶端 的視角下，總是下意識會認為小程式也就那樣。

但隨著大前端、跨平臺、低程式碼 近幾年的火熱，小程式的技術也在飛速迭代。特別是被疫情奪走的這三年，常用的 健康碼、出行碼、打車、外賣小程式 等，已經越來越成為我們日常必不可少的 基礎工具 之一，可以說，小程式的使用程度已經遠遠超過了我們曾經所認為的那樣。

現在，有更多的產品會首選小程式作為快速落地，並以此提升使用者數量，開啟 從0到1 的第一步；從 動態化 的角度而言，小程式相比過去的H5也更受平臺型App的歡迎。

所以如何選擇一個 高效能，低成本 的 小程式框架，又更是每個公司與個人開發者必須要考慮的事情。

故此，本篇我們將使用 小程式 x FinClip 容器框架，並將其快速整合到我們的 App 中，從而以小見大，一瞥其相比H5與原生的差異。

背景

每一項技術，都有其發展歷史與背景，小程式也不例外，在開始本篇之前，我們有必要先聊一聊小程式的歷史。

小程式是什麼？

image-20230216221929723

這裡引用2016年 [微信公開課Pro] 中的一段話：

小程式是一種不需要下載安裝即可使用的應用，它實現了應用“觸手可及”的夢想，使用者掃一掃或者搜一下即可開啟應用。也體現了“用完即走”的理念，使用者不用關心是否安裝太多應用的問題。應用將無處不在，隨時可用，但又無須安裝解除安裝。

記得2017年初，微信小程式正式上線，從開始的不受矚目，到現在的日常基礎使用，再去看上面這段話，正如其意一般，用完即走、快速開啟。

對於業務方而言，這是快速落地的第一步，對於使用者而言，因為依託在 平臺型App 之上，開啟路徑也更加簡單直接。

小程式與原生應用的差異？

通常來說，小程式其實就是一種 輕量級 的應用程式，通常指的微信、支付寶、抖音 等應用內的動態化容器，因為其與傳統應用程式不同，無需安裝，即可以實現類似原生一樣的使用體驗。

  • 從使用上來看：小程式某種程度上是移動應用的一個子集，如果將原生應用比作容器或者畫板，而小程式則是水或者畫筆；
  • 從效能上去看：小程式對硬體的依賴較小，但相應的，也受限於宿主應用的限制，如果業務場景複雜，此時就會遇到效能上的問題；
  • 從開發成本去看：相比原生來說，小程式的開發難度較低，其通常是前端常用的語言，並且高可複用性也是其特點之一；
  • 從業務推廣來看：小程式的渠道較多，比如可以直接在微信、支付寶等平臺快速上線與推廣，並通過分享、搜尋等方式，獲客成本相比原生較低；
  • 從跨平臺能力來看：小程式天然的具備跨平臺的能力，一套程式碼可以在ios、Android等多平臺執行，有些框架更支援將小程式匯出為原生應用；

具體對比如下表所示：

| 特性\平臺 | 原生應用 | 小程式 | H5 | | :----------------: | :------: | :----: | :--: | | 效能 | ⭐️⭐️⭐️ | ⭐️⭐️ | ⭐️ | | 開發成本 | ⭐️ | ⭐️⭐️ | ⭐️⭐️⭐️ | | 支援跨平臺 | ⭐️ | ⭐️⭐️ | ⭐️⭐️⭐️ | | 業務推廣成本 | ⭐️ | ⭐️⭐️ | ⭐️ | | 使用體驗(簡單場景) | ⭐️⭐️⭐️ | ⭐️⭐️⭐️ | ⭐️⭐️ | | 使用體驗(複雜場景) | ⭐️⭐️⭐️ | ⭐️⭐️ | ⭐️ |

⭐️ 越多代表越優秀，反之則是越差。

框架選型

雖然小程式目前仍是一片藍海，但各廠商從17年到現在，也都逐漸築起了自己的平臺，相應的也有一些不同的限制與渲染規則。

如果後續業務越來越複雜，勢必需要 考慮作為其他平臺的引流方，藉此提高體驗。此時如何能快速、低成本進行小程式迭代，又是每個業務方需要考慮的問題。

而 FinClip(凡泰極客) ，正是一個用於應對上述難點的優秀容器框架之一，其具備以下特性：

  • 輕量的小程式SDK；
  • 完善的開發者工具；
  • 面向業務的全生命週期管理；
  • 支援一鍵將小程式轉為原生App*；
  • 相容微信小程式語法與登入體系；
  • 支援在 Android 、ios、鴻蒙、Flutter、windows、車機 等系統中整合；

同時，FinClip 也是一個生態性的協作平臺，使用者可以與企業、SDK外掛提供商、小程式開發運營商、雲平臺SaaS服務商協作，研發個性化的超級App，其具體的平臺組成圖如下：

image-20230217143439169

上述平臺組成圖中，細分概念如下：

雲端：指的是為使用者使用的管理後臺，比如開發者可以在這裡進行小程式管理，設定小程式所要訪問域名等；

端側：由小程式SDK組成，用於提供執行小程式所必要的基礎環境，同時又包含 執行小程式的安全沙箱、程式碼直譯器、渲染引擎；

開發者工具：主要由 IDE 與 App 組成，這也是離我們開發者最近的地方，用於小程式的程式碼開發及除錯，並支援一鍵將程式碼上傳至雲端稽核，以及在本地對小程式的預覽與管理操作等，具體如下圖所示：

image-20230217150833705

整合步驟

當我們在雲端配置好小程式並上線，且與我們的 宿主App 中關聯之後，就可以在原生應用整合小程式sdk了。

這裡以 IDE 中預設的小程式示例作為測試程式碼，整合方式以 FinClip 的 AndroidSdk 為例，其他端可以參照官方文件。

具體教程如下：

gradle配置

build.gradle || settings.gradle(如果已遷移新版依賴方式)

```groovy // 方式1. build.gradle allprojects { repositories { maven { url "http://gradle.finogeeks.club/repository/applet/" credentials { username "applet" password "123321" } } } }

// 方式2. settings.gradle dependencyResolutionManagement { ... repositories { ... maven { url "http://gradle.finogeeks.club/repository/applet/" credentials { username "applet" password "123321" } }

}

} ```

整合kotlin外掛

```groovy // 方式1 classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:1.7.21"

// 方式2 plugins { id 'org.jetbrains.kotlin.android' version '1.7.21' apply false } ```

引入sdk依賴，處理配置

```groovy android{ packagingOptions { // libsdkcore.so、libfin-yuvutil.so是被加固過的，不能被壓縮，否則載入動態庫時會報錯 doNotStrip "/x86/libsdkcore.so" doNotStrip "/x86_64/libsdkcore.so" doNotStrip "/armeabi/libsdkcore.so" doNotStrip "/armeabi-v7a/libsdkcore.so" doNotStrip "*/arm64-v8a/libsdkcore.so"

    doNotStrip "*/x86/libfin-yuvutil.so"
    doNotStrip "*/x86_64/libfin-yuvutil.so"
    doNotStrip "*/armeabi/libfin-yuvutil.so"
    doNotStrip "*/armeabi-v7a/libfin-yuvutil.so"
    doNotStrip "*/arm64-v8a/libfin-yuvutil.so"
}

dependencies {
     implementation 'com.finogeeks.lib:finapplet:2.39.7'
     implementation "org.jetbrains.kotlin:kotlin-stdlib:1.7.21"
}

} ```

處理混淆

properties -keep class com.finogeeks.** {*;}

程式碼配置

Application

```kotlin override fun onCreate() { super.onCreate() if (FinAppClient.isFinAppProcess(this)) return val config = FinAppConfig.Builder() .setSdkKey("M8j6KLAGGce/g0XJB8hlqUnu5dv6R/kwAxPre2U3SJc=") // SDK Key .setSdkSecret("335d2c668af0ddeb") // SDK Secret .setApiUrl("http://api.finclip.com") // 伺服器地址 .setApiPrefix("/api/v1/mop/") // 伺服器介面請求路由字首 .build() val initCallback = object : FinCallback { override fun onSuccess(result: Any?) { Log.e("petterp", "init success") }

        override fun onProgress(status: Int, info: String?) {
        }

        override fun onError(code: Int, error: String?) {
            Log.e("petterp", "init error:$error")
        }
    }
    FinAppClient.init(this, config, initCallback)
    // 啟動小程式
    FinAppClient.appletApiManager.startApplet(this, "63ee4c259261fa0001202d60")

} ```

效果展示

| 90_1676605720 | 90_1676605720 | 91_1676614660 | | :----------------------------------------------------------: | :----------------------------------------------------------: | :----------------------------------------------------------: |

總結

在本篇，我們選擇使用 FinClip 框架，並將其整合到現有的 App 中，從而感受小程式與原生應用的差距。

在技術迭代的現在，相對於原生應用而言，小程式具有輕量化、無需安裝、開發門檻低、跨平臺、生態豐富等優勢，對於一些簡單的應用場景和快速開發，小程式是一種不錯的選擇。同時，隨著小程式的不斷髮展和完善，它的應用範圍和開發者群體也將會逐漸擴大。

從各平臺App去看，無論是支付寶、抖音、微信，也都選擇小程式作為動態化的關鍵容器。

從移動端的技術變更去看，在跨平臺百花齊放的現在，無論是 Flutter、React Native，還是後來者 Compose 與 KMM ，每一項技術在各自領域也都有其存在的意義。但如果要談到快速落地，並與現有業務進行結合，大多數時候，我們仍然還是會回到 更成熟 的H5，那此時不妨也試試將 小程式 整合到 App 中，其也許會是更好的選擇。

參照

關於我

我是 Petterp ,一個 Android工程師 ，如果本文對你有所幫助，歡迎 點贊、評論、收藏，你的支援是我持續創作的最大鼓勵！

「」
「」