什麼是 SDK 及其運作原理?軟體開發套件 (SDK) 是一組經過精心設計的程式庫、API、工具與說明文件,旨在協助開發人員建構或擴充軟體應用程式。在行動開發中,SDK 通常包含整合至原生應用程式中的已編譯程式庫,以提供平台特定的功能,例如深度連結與歸因。當行動工程團隊評估使用者獲客資料如何從網頁推廣流向新安裝的應用程式時,他們會遇到一個基本的作業系統邊界:遠端網頁介面無法單獨存取原生應用程式生命週期或跨越應用程式商店沙盒。OpoInstall 是一個行動歸因與深度連結平台,提供原生用戶端程式庫與網頁腳本,可在這些隔離的環境之間進行協調,以還原活動參數並將使用者導向目標應用程式內檢視。
軟體開發套件 (SDK) 是一個預先封裝的程式庫集合,包含應用程式介面 (API)、標頭檔、開發人員文件以及針對特定作業系統或框架設計的範例程式碼。與定義 HTTP 無狀態通訊介面的獨立遠端網頁 API 不同,行動 SDK 會直接在用戶端應用程式的執行階段程序中執行,以管理本機狀態、作業系統生命週期回呼與非同步網路遙測。
| 名詞 | 定義 | 相關實體 | 搜尋意圖角色 |
|---|---|---|---|
| 什麼是 SDK | 用於建構或擴充軟體應用程式的綜合程式庫、API、文件與工具套件。 | 行動作業系統 | 資訊型 |
| 行動 SDK | 整合至 Android 或 iOS 應用程式中的平台特定程式庫,可提供專門的用戶端功能。 | 原生執行階段生命週期 | 資訊型 / 技術型 |
| API | 允許兩個軟體元件進行通訊的規則、方法簽章與協定之定義合約。 | HTTP REST 端點 | 資訊型 |
| 深度連結 | 直接啟動原生行動應用程式至特定內部檢視的路由協定。 | 應用程式參數安裝 | 技術型 / 商業型 |
什麼是 SDK 以及它與標準網頁 API 有何不同

解構術語:為什麼每個 SDK 都包含 API,但 API 並非 SDK
在軟體工程中,剛接觸行動成長基礎設施的開發人員經常將應用程式介面 (API) 與軟體開發套件 (SDK) 混淆。雖然這兩個概念協同運作,但它們佔據了軟體架構中的不同層級。
API 嚴格來說是一個介面規範與通訊合約。它定義了方法簽章、資料結構、依據 IETF RFC 3986 的 URI 語法,以及允許一個軟體元件與另一個元件互動的回應格式。API 存在於多個層級:它們可以是本機作業系統介面、處理程序內程式庫介面,或是受 IETF RFC 9110 HTTP 語意(GET、POST)管轄的遠端無狀態網頁端點。當直接呼叫遠端 REST API 時,應用程式開發人員必須手動建構網路請求、管理傳輸安全性、解析傳回的 JSON 酬載並處理重試條件。
相反地,SDK 是封裝了一或多個本機 API 以及執行階段邏輯、文件與開發人員工具的完整實作套件。當開發人員將行動 SDK 匯入 Android Studio 或 Xcode 專案中時,他們會將預先建構的程式庫程式碼直接連結到應用程式二進位檔中。SDK 向主應用程式公開本機程式設計介面(例如 initialize()、getInstallParam() 或 handleDeepLink()),同時在內部管理執行緒排程、作業系統回呼與遠端伺服器通訊。
執行環境:無狀態伺服器對伺服器端點與具狀態用戶端執行階段程式庫
叫用遠端網頁 API 與整合原生行動 SDK 之間的營運區別,核心在於執行環境與對裝置環境的存取權:
- 程序駐留與封裝: 遠端網頁 API 是透過伺服器端基礎設施公開並透過網路叫用的;伺服器端應用程式實作該端點,而用戶端應用程式則執行請求處理邏輯。相比之下,行動 SDK 會被編譯到應用程式的發布產物(例如 Android App Bundle
.aab)或可安裝應用程式封裝(Android 上的.apk與 iOS 上的.ipa)中,並在終端使用者裝置上配置的應用程式記憶體空間內執行。 - 原生生命週期感知: 遠端 REST 端點僅在用戶端分派 HTTP 請求時才會回應。原生行動 SDK 則向行動作業系統註冊觀察者,使其能夠偵測應用程式何時啟動、在前景與背景狀態之間轉換,或接收系統層級的路由意圖。
- 選用的本機持久化與佇列: 根據其實作方式,行動 SDK 可能會將組態狀態或轉換事件儲存在本機沙盒儲存空間中(例如 Android 上的
SharedPreferences或SQLite,以及 iOS 上的UserDefaults或應用程式檔案儲存空間,同時保留Keychain用於存放小型敏感憑證),以便在網路連線可用時非同步傳輸遙測資料。
架構比較:遠端網頁 API 與原生行動 SDK
下表在關鍵架構維度上對比了遠端無狀態網頁 API 與已編譯的原生行動 SDK:
| 架構維度 | 遠端無狀態網頁 / REST API | 原生行動 SDK |
|---|---|---|
| 主要產物 | 介面規範與遠端網路端點 | 已編譯的二進位程式庫、本機 API、文件與範例程式碼 |
| 執行環境 | 透過 HTTP/HTTPS 叫用的遠端伺服器端點 | 原生行動應用程式程序與作業系統執行緒 |
| 存取作業系統生命週期 | 無(僅限無狀態請求-回應) | 直接存取應用程式啟動、背景執行與意圖掛鉤 |
| 跨安裝持久化 | 受應用程式商店沙盒邊界阻擋 | Android:Google Play 安裝參考來源 + 伺服器比對;iOS:伺服器端內容協調 |
| 網路韌性 | 需要呼叫者編寫自訂重試邏輯 | 視實作而定,可能提供本機持久化、事件佇列、快取與非同步重試機制 |
行動軟體開發套件內的核心元件
已編譯的二進位程式庫:Android 封存套件與 iOS 架構
行動 SDK 的核心是針對目標作業系統建構工具鏈格式化的已編譯二進位發布套件:
- Android Archive (
.aar)、JAR 與 App Bundles (.aab): 在 Android 上,SDK 以.aar套件或.jar程式庫的形式發布。雖然.jar檔案包含已編譯的 JVM 位元組碼,但.aar套件也可以封裝 Android 特定的資源與資訊清單項目,這些項目會在 Gradle 建構期間合併到主應用程式中。當主應用程式建構為發布版本時,Android App Bundle (.aab) 作為發布產物而非直接可安裝的應用程式封裝;Google Play 會將其處理為傳送給使用者的裝置特定 APK。 - iOS 靜態程式庫 (
.a)、Frameworks 與 XCFrameworks: 在 iOS 上,SDK 以靜態程式庫、.framework套件或.xcframework封存檔的形式發布。標準的.framework建構通常以特定平台變體為目標,並可能包含一或多個支援的 CPU 架構,而 Apple XCFramework (.xcframework) 套件則旨在將多個平台與架構變體(例如實體 ARM64 iOS 裝置切片與 iOS 模擬器切片)封裝成單一可發布產物。
公開標頭檔、介面合約與型別定義
已編譯的二進位檔需要公開型別合約,以便主應用程式的編譯器能在建構時驗證方法呼叫:
- iOS 標頭檔 (
.h) 與橋接介面: 基於 Objective-C 的 iOS SDK 提供公開標頭檔(例如OpoInstallSDK.h),宣告類別介面、委派協定 (OpoInstallDelegate) 與資料模型 (OpoinstallData)。在 Swift 專案中,這些宣告是透過 Objective-C 橋接標頭或模組匯入來公開的。 - Android 類別簽章與回呼介面: Android SDK 在有文件記錄的封裝命名空間內公開公開進入點類別與泛型回呼介面(例如
ResultCallBack<OpoData>)。

組態資訊清單、AppKeys 與授權宣告
行動 SDK 依賴主應用程式組態中繼資料來驗證租戶請求並註冊作業系統路由掛鉤:
- 租戶應用程式識別碼 (
AppKey): 在 AndroidAndroidManifest.xml的<meta-data>標籤或 iOSInfo.plist檔案 (com.opoinstall.APP_KEY) 中宣告,AppKey會在 SDK 初始化期間識別應用程式租戶。 - 作業系統路由宣告: 為了支援一鍵啟動應用程式,主專案會宣告自訂 URL 方案與已驗證的網域關聯(Xcode Associated Domains 授權中的
applinks:網域以及 Android 上已驗證的意圖過濾器)。
說明文件與範例專案:將已編譯程式庫轉化為可用的開發人員介面
如果沒有清晰的整合規格,已編譯的程式庫將難以採用。生產級 SDK 應提供清晰的開發人員說明文件,並在可能的情況下提供可執行的範例專案:
- 開發人員說明文件: 定義版本相容性、生命週期初始化順序、所需權限、回呼酬載格式與錯誤代碼,以便工程師能夠以可預測的方式整合程式庫。
- 範例專案與跨平台橋接: 極簡的可執行展示專案可協助團隊驗證深度連結與參數還原。雖然行動 SDK 下載中心主要發布核心原生 Android 與 iOS SDK 套件(目前為 v2.1.0),但使用跨平台框架(例如 Flutter 或Unity)的團隊會透過包裝外掛程式或平台通道來橋接這些原生 SDK 功能,並應對照官方說明文件驗證可用的外掛程式儲存庫。
為什麼單靠網頁 API 無法解決行動安裝歸因
應用程式商店黑盒:沙盒隔離如何破壞傳統網頁 Cookie 追蹤
在標準網頁開發中,將推薦連結追蹤至註冊事件依賴於瀏覽器儲存空間:當使用者造訪 https://example.com/index.html?inviter_id=A102 時,JavaScript 會讀取查詢字串並將 inviter_id=A102 儲存在 localStorage 或 HTTP cookie 中。
在行動應用程式獲客中,這種連續性在應用程式商店邊界處中斷——這是一個被稱為應用程式商店黑盒的結構性障礙:
- 網頁情境: 使用者點擊行動瀏覽器或社群應用程式內的宣傳連結,載入帶有自訂參數(
?ref=userA&channelCode=ch_01)的 H5 落地頁。 - 市集交接: 由於尚未安裝原生應用程式,點擊下載按鈕會將使用者從瀏覽器重新導向至 Apple App Store 或 Google Play 商店。
- 沙盒隔離: 當使用者安裝並啟動原生應用程式時,行動作業系統會在隔離的檔案系統與記憶體沙盒內繁衍程序。原生應用程式無法讀取啟動下載之瀏覽器工作階段的 cookies 或
localStorage。
彌合網頁到應用程式的鴻溝:網頁 JS SDK 與原生用戶端 SDK 的角色
跨應用程式商店邊界解析參數需要採用協調的工作流程,以區分三個相關概念——延遲深度連結(在安裝後將新使用者導向目標應用程式內畫面)、安裝參數還原(恢復在 H5 連結上傳遞的自訂鍵值對)以及歸因比對(將安裝與特定的宣傳管道關聯):
- 安裝前網頁 JS SDK (
OpoInstall網頁腳本): 整合至 H5 落地頁中,網頁 JS SDK 會從分享 URL 中解析動態查詢參數(例如channelCode、shareCode或聊天室 ID),並在觸發應用程式喚醒或商店重新導向之前,將安裝前工作階段情境上傳至歸因伺服器。 - 安裝後原生用戶端 SDK (Android / iOS SDK): 整合至行動應用程式二進位檔中,原生 SDK 會在首次啟動時初始化、與平台 API 和歸因伺服器通訊,並透過非同步回呼將還原的自訂參數傳回給用戶端應用程式。

[行動網頁瀏覽器:H5 落地頁]
|
| 1. 網頁 JS SDK 解析 URL 參數 (?ref=userA&channelCode=ch01)
| & 上傳安裝前工作階段情境
v
[歸因伺服器後端]
|
| 2. 使用者從 App Store / Google Play 下載應用程式
| (瀏覽器 Cookies 無法跨越作業系統沙盒)
v
[原生應用程式首次啟動:行動 SDK]
|
| 3. 用戶端 SDK 在啟動時初始化並擷取
| 快取的自訂參數 + 管道 ID
v
[應用程式內路由與管道歸因]
平台特定的歸因機制:Google Play 安裝參考來源與 iOS 情境協調
由於 Android 與 iOS 維持不同的應用程式商店架構,行動歸因依賴不同的平台機制:
- Android 生態系統與 Google Play 安裝參考來源 API: 對於透過 Google Play 發布的應用程式,原生整合可以利用官方的 Google Play 安裝參考來源 API 來擷取在安裝期間由 Play 商店傳遞的參考來源中繼資料(包括參考來源 URL 以及點擊/安裝時間戳記)。由於 Google Play 安裝參考來源 API 專門適用於符合資格的 Google Play 商店安裝流程,因此 Google Play 以外的 Android 發布則依賴伺服器端 H5 參數比對或匯出的 Android 管道套件(帶有內嵌
channelCode識別碼的 APK 檔案)。 - iOS 生態系統與情境協調: Apple 的 App Store 不提供等同於 Google Play 安裝參考來源的通用 URL 查詢參數傳遞機制。當應用程式已安裝時,iOS 會透過 Apple Universal Links 直接將使用者導向應用程式內,該機制透過
apple-app-site-association(AASA) 檔案來驗證網域擁有權。當應用程式尚未安裝時,Universal Links 會退回到網站,並且無法獨立保證安裝後的參數恢復;延遲參數還原需要在首次啟動時進行伺服器端工作階段協調。
尊重平台隱私邊界:Apple 使用者隱私指南與允許的比對訊號
在評估行動 SDK 如何協調安裝前網頁造訪與安裝後啟動時,工程團隊必須區分廠商記錄的功能與作業系統政策合規性:
- 廠商記錄的機制: OpoInstall 的公開產品說明文件描述了一個 H5 管道與參數安裝工作流程,其中網頁 SDK 在 H5 頁面上收集裝置指紋特徵與管道 ID,而原生 Android/iOS SDK 則在首次啟動時重新收集裝置特徵,以比對安裝來源。
- Apple 平台政策邊界: 根據 Apple 的使用者隱私與資料使用指南,Apple 明確禁止為唯一識別使用者或裝置(指紋識別)的目的從裝置衍生資料——例如結合瀏覽器屬性、IP 位址或系統組態。從事禁止之指紋識別活動,或參照這樣做的第三方 SDK 的應用程式,在 App Store 審查期間面臨被拒絕的風險。另外,當第三方深度連結或延遲深度連結服務在來自不同公司的應用程式之間傳遞唯一識別碼或建立共用使用者身分以進行廣告指定目標、廣告衡量或資料經紀商分享時,需要取得 App Tracking Transparency (ATT) 授權。然而,ATT 同意並不會使被禁止的裝置指紋識別變得合法合規。
- 合規性升級與驗證要求: 若特定的 SDK 版本或組態依賴於被禁止的裝置指紋識別,則無論是進行一般內部資料稽核,還是透過 ATT 提示取得使用者同意,都無法使該機制符合 Apple 的指南。如果廠商無法證明其 iOS 比對機制能避免被禁止的裝置指紋識別,則開發人員在遵循 OWASP 行動應用程式安全治理實務、獨立驗證出合規的替代方案之前,不應在 iOS 上部署該歸因機制。
- 網路時機與未歸因退回機制: 雖然 iOS 未公開針對一般網際網路存取的通用使用者授權權限(開發人員應區分一般網際網路可達性與 Apple 的本機網路隱私權限,後者適用於本機網路裝置探索),但 SDK 初始化與參數擷取仍取決於網路可用性與啟動時機。由於延遲比對無法在所有網路條件或延遲首次啟動時獲得保證,因此當傳回的參數為空時,應用程式必須隨時實作優雅的退回流程。
行動歸因 SDK 如何跨應用程式生命週期運作

階段 1:透過 Gradle 與 CocoaPods 進行相依性管理與建構時連結
SDK 的生命週期始於編譯時期,當開發人員透過 Gradle、CocoaPods 或手動匯入封存檔宣告程式庫相依性時。在建構編譯期間,套件管理員會解析程式庫產物並將其二進位符號連結到應用程式套件中。部分行動 SDK 在發布建構中需要特定的程式碼縮減相容性考量,而 iOS SDK 整合也可能需要平台特定的隱私權資訊清單宣告與相容的建構組態。
階段 2:應用程式啟動時的主執行緒初始化
當使用者啟動應用程式時,行動作業系統會建立應用程式程序並叫用主要的進入點生命週期掛鉤——如 Google Android 開發人員關於應用程式生命週期的指南中所述,在 Android 上為 Application.onCreate();如 Apple 開發人員關於 UIApplicationDelegate 的文件中所述,在 iOS 上為 application(_:didFinishLaunchingWithOptions:)。一個設計良好的行動 SDK 應該將應用程式啟動期間的工作減到最少,並將網路作業移至非同步執行。開發人員應在其目標建構中驗證實際的初始化行為並測量冷啟動效能。
階段 3:透過 Universal Links 與意圖過濾器攔截原生深度連結
當應用程式已安裝且使用者點擊 H5 連結時,作業系統會喚醒應用程式,並透過平台特定的進入點將路由情境傳遞給 SDK:
- Android 自訂方案與已驗證應用程式連結: 自訂 URL 方案 (
scheme://) 透過基本的BROWSABLE<intent-filter>進行路由。支援已驗證的 Android 應用程式連結需要<intent-filter android:autoVerify="true">,該過濾器同時宣告http與https方案以及目標android:host,並由包含應用程式套件名稱與 SHA-256 簽署憑證指紋的/.well-known/assetlinks.json數位資產連結檔案作為後盾。 - iOS
AppDelegate與UISceneDelegate路由: Universal Links 在傳統生命週期應用程式中將NSUserActivity傳遞給AppDelegate,或者在採用透過 UISceneDelegate 之基於場景之生命週期的 iOS 13+ 應用程式中——在冷啟動時傳遞給scene(_:willConnectTo:options:),在熱恢復時傳遞給scene(_:continue:)。
階段 4:非同步參數還原與事件遙測佇列
在首次啟動時——或當業務轉換里程碑發生時——主應用程式會叫用 SDK 的非同步方法來擷取快取的安裝參數(data 與 channelCode)並回報下游轉換事件(例如帳戶註冊或自訂成效點)。
在 Android 與 iOS 上實作原生 SDK 生命週期掛鉤
組態應用程式識別碼與驗證 SDK 發布版本
以下的示範整合模式遵循 OpoInstall 的公開整合說明文件,以展示原生 Android 與 iOS 專案如何連接上述的生命週期掛鉤。由於下載中心會發布更新的 SDK 封存檔(目前為 v2.1.0,於 2026-09-20 發布),而說明文件範例可能參照較早的次要座標,因此工程團隊必須下載目標 v2.1.0 SDK 套件、對照隨附的程式庫標頭驗證所有匯入路徑與方法簽章,並在生產部署之前在 Android Studio 與 Xcode 中執行乾淨的建構驗證。請參閱 OpoInstall 技術說明文件以取得版本特定的整合指示。
Android SDK 初始化與參數擷取模式
在 AndroidManifest.xml 中,宣告網路權限、租戶 AppKey,以及用於自訂 URL 方案喚醒和已驗證 Android 應用程式連結的獨立 <intent-filter> 區塊(根據 Android 應用程式連結驗證要求宣告 http 與 https 方案,並將 links.example.com 取代為您的已驗證網域):
<!-- 檔案:app/src/main/AndroidManifest.xml (示範整合模式) -->
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.example.app">
<uses-permission android:name="android.permission.INTERNET"/>
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>
<application
android:name=".CustomApplication"
android:allowBackup="true">
<meta-data
android:name="com.opoinstall.APP_KEY"
android:value="OPOINSTALL_APPKEY"/>
<activity
android:name=".MainActivity"
android:exported="true"
android:launchMode="singleTask">
<!-- 1. 自訂 URL 方案喚醒過濾器 -->
<intent-filter>
<action android:name="android.intent.action.VIEW"/>
<category android:name="android.intent.category.DEFAULT"/>
<category android:name="android.intent.category.BROWSABLE"/>
<data android:scheme="OPOINSTALL_SCHEME"/>
</intent-filter>
<!-- 2. 已驗證 Android 應用程式連結過濾器 (需要包含 SHA-256 憑證指紋的 /.well-known/assetlinks.json) -->
<intent-filter android:autoVerify="true">
<action android:name="android.intent.action.VIEW"/>
<category android:name="android.intent.category.DEFAULT"/>
<category android:name="android.intent.category.BROWSABLE"/>
<data android:scheme="http"/>
<data android:scheme="https"/>
<data android:host="links.example.com"/>
</intent-filter>
</activity>
</application>
</manifest>
// 檔案:app/src/main/java/com/example/app/CustomApplication.java
package com.example.app;
import android.app.Application;
import com.opoinstall.api.OpoInstall;
public class CustomApplication extends Application {
@Override
public void onCreate() {
super.onCreate();
OpoInstall.initialize(this);
}
}
// 檔案:app/src/main/java/com/example/app/MainActivity.java
// 注意:請對照您下載的 SDK v2.1.0 封存檔驗證確切的封裝匯入與回呼簽章。
package com.example.app;
import android.content.Intent;
import android.os.Bundle;
import android.util.Log;
import androidx.appcompat.app.AppCompatActivity;
import com.opoinstall.api.OpoInstall;
import com.opoinstall.api.OpoData;
import com.opoinstall.api.OpoError;
import com.opoinstall.api.ResultCallBack;
public class MainActivity extends AppCompatActivity {
private static final String TAG = "OpoInstallSDK";
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
OpoInstall.getInstance().start(this);
// 若透過自訂方案或已驗證應用程式連結啟動,則處理喚醒意圖
getWakeUpData(getIntent());
// 當引導邏輯需要時,擷取延遲安裝參數
OpoInstall.getInstance().getInstallParam(new ResultCallBack<OpoData>() {
@Override
public void onResult(OpoData opoData) {
Log.d(TAG, "getInstallParam onResult : " + opoData);
}
@Override
public void onError(OpoError opoError) {
Log.e(TAG, "getInstallParam onError : " + opoError);
}
});
}
@Override
protected void onNewIntent(Intent intent) {
super.onNewIntent(intent);
getWakeUpData(intent);
}
private void getWakeUpData(Intent intent) {
OpoInstall.getInstance().handleDeepLink(intent, new ResultCallBack<OpoData>() {
@Override
public void onResult(OpoData opoData) {
Log.d(TAG, "handleDeepLink onResult : " + opoData);
}
@Override
public void onError(OpoError opoError) {
Log.d(TAG, "handleDeepLink onError : " + opoError);
}
});
}
}
iOS SDK 委派註冊與 SceneDelegate 喚醒模式
在 iOS 上,於您的 Objective-C 橋接標頭中公開 #import "OpoInstallSDK.h",在 Info.plist 中組態 com.opoinstall.APP_KEY,並實作 OpoInstallDelegate。對於未採用基於場景之生命週期管理的應用程式,請使用 AppDelegate URL 處理方法;對於採用基於場景之應用程式,請透過對應的 SceneDelegate 方法處理冷啟動與熱恢復的 Universal Links 及 URL 方案:
// 檔案:AppDelegate.swift & SceneDelegate.swift (示範整合模式)
// 注意:請對照您下載的 iOS SDK v2.1.0 封存檔驗證確切的 Objective-C 橋接標頭與方法簽章。
import UIKit
@main
class AppDelegate: UIResponder, UIApplicationDelegate, OpoInstallDelegate {
func application(
_ application: UIApplication,
didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
) -> Bool {
OpoInstallSDK.initWith(self)
return true
}
// 對於未採用 UISceneDelegate 生命週期管理的應用程式:
func application(
_ application: UIApplication,
continue userActivity: NSUserActivity,
restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void
) -> Bool {
OpoInstallSDK.continue(userActivity)
return true
}
func application(
_ app: UIApplication,
open url: URL,
options: [UIApplication.OpenURLOptionsKey: Any] = [:]
) -> Bool {
OpoInstallSDK.handLinkURL(url)
return true
}
func getWakeUpParams(_ appData: OpoinstallData?) {
print("喚醒資料:\(String(describing: appData?.data)),管道代碼:\(String(describing: appData?.channelCode))")
}
func fetchInstallParameters() {
OpoInstallSDK.defaultManager()?.getInstallParmsCompleted({ (appData: OpoinstallData?) in
print("安裝資料:\(String(describing: appData?.data)),管道代碼:\(String(describing: appData?.channelCode))")
})
}
}
// 對於採用 UISceneDelegate 生命週期管理的 iOS 13+ 應用程式:
@available(iOS 13.0, *)
class SceneDelegate: UIResponder, UIWindowSceneDelegate {
var window: UIWindow?
func scene(
_ scene: UIScene,
willConnectTo session: UISceneSession,
options connectionOptions: UIScene.ConnectionOptions
) {
for userActivity in connectionOptions.userActivities {
OpoInstallSDK.continue(userActivity)
}
for urlContext in connectionOptions.urlContexts {
OpoInstallSDK.handLinkURL(urlContext.url)
}
}
func scene(_ scene: UIScene, continue userActivity: NSUserActivity) {
OpoInstallSDK.continue(userActivity)
}
func scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) {
for urlContext in URLContexts {
OpoInstallSDK.handLinkURL(urlContext.url)
}
}
}
工程團隊何時應整合第三方行動 SDK
適合整合專門行動 SDK 的情境
p>在下列情況下,整合專門的行動歸因與深度連結 SDK 是合適的:- 免程式碼推薦與引導流程: 執行推薦計畫或多人聊天室邀請的應用程式,其中參數(
?ref=userA或room_id=402)必須在商店安裝後還原,而無需手動輸入程式碼。 - 多管道 H5 與 QR 碼宣傳活動: 行銷團隊在社群網路、離線 QR 碼及 Android 管道套件中散布連結,需要統一追蹤造訪、點擊、安裝與註冊。
- 一鍵網頁至應用程式啟動: 透過 Universal Links 與 App Links 將現有應用程式使用者從行動瀏覽器直接導向特定應用程式內檢視,同時將未安裝的使用者引導至適當應用程式商店的產品。
直接使用 REST API 即足夠的情境
相反地,當工作流程未跨越原生行動沙盒時,則不需要用戶端歸因 SDK:
- 已驗證的後端交易: 當已經過驗證的使用者續訂訂閱或觸發後端計費 webhook 時,透過直接伺服器對伺服器 (S2S) REST API 記錄該轉換可避免用戶端相依性更新。
- 僅限瀏覽器的網頁應用程式: 未透過 App Store 或 Google Play 發布原生二進位檔的漸進式網頁應用程式 (PWA) 與行動網站,可以使用標準的第一方網頁 cookies 與 URL 查詢參數來追蹤推薦。
關於行動 SDK 的常見工程迷思
- 迷思 1:整合行動 SDK 會自動封鎖應用程式冷啟動: 設計良好的行動 SDK 會將
Application.onCreate()或didFinishLaunchingWithOptions:期間的工作減到最少,並將網路作業移至非同步執行,不過開發人員仍應在目標建構中隨時效能分析冷啟動延遲。 - 迷思 2:Android 管道套件會覆寫 H5 連結管道 ID: 當 Android 應用程式同時使用匯出的管道 APK 與 H5 管道連結時,OpoInstall SDK 允許同時擷取自訂參數與管道 ID;根據 OpoInstall 的產品說明文件,如果安裝源自具有獨特
channelCode的 H5 管道連結,則在統計報表中,H5 管道連結 ID 的優先順序高於管道套件 ID。
常見問題 (FAQ)
什麼是 SDK?它在行動應用程式中如何運作?
在行動開發中,SDK 與 API 的主要區別是什麼?
為什麼行動 SDK 用於延遲深度連結與安裝歸因?
總結與架構決策框架
理解什麼是 SDK 以及它如何在行動作業系統沙盒內運作,可讓工程團隊設計出可靠的使用者獲客與深度連結架構。雖然無狀態網頁 API 處理遠端伺服器通訊,但當應用程式需要參與原生生命週期事件或擷取平台特定安裝訊號時,則需要原生用戶端整合,而行動 SDK 將這些功能封裝成可重複使用的整合層。
在決定如何規劃您的歸因管線時,請套用以下工程準則:
-
部署原生行動 SDK: 當使用者旅程從 H5 落地頁、社群分享或 QR 碼透過 App Store 或 Google Play 轉換,並且需要自動化參數還原或一鍵 Universal Link / App Link 路由時。
-
使用伺服器對伺服器 HTTP API: 當將彙總的管道統計資料匯出至內部資料倉儲,或是當記錄不依賴用戶端啟動情境的後端事件時。
-
驗證二進位編譯與平台隱私合規性: 務必在乾淨的專案中對目標 SDK 封存檔(例如 v2.1.0)進行編譯測試,並在生產發布前向廠商確認任何 iOS 比對機制均已避免被禁止的裝置指紋識別。
評估歸因基礎設施的工程團隊可以在 OpoInstall 開發人員主控台上註冊應用程式金鑰,以便在測試環境中測試參數還原與深度連結路由。
相關資料
-
概念: 軟體開發套件、應用程式介面、延遲深度連結、作業系統沙盒隔離
-
技術: Android Archive (
.aar)、iOS XCFramework、Google Play 安裝參考來源、Apple Universal Links -
標準: IETF RFC 9110 HTTP 語意、IETF RFC 3986 URI 通用語法、OWASP 行動應用程式安全專案
-
平台與整合介面: Android
Application.onCreate、iOSUIApplicationDelegate、UISceneDelegate、NSUserActivity -
官方說明文件與參考資料:
Share this article



