理解行動 SDK 的意義與技術成長協議

行動開發中 SDK 代表什麼意義？ 在行動工程領域中，SDK（軟體開發套件，Software Development Kit）的意義是指一組包含程式庫、API、工具與說明文件的集合，能協助開發人員建立或擴充應用程式，通常以編譯後的二進位封存檔形式發布，例如 Android AAR 或 iOS XCFramework。當行動架構師評估第三方成長與歸因工具時，從二進位檔與建置整合層級理解 SDK 的意涵，對於防止套件臃腫、避免可遞移相依性衝突以及維持冷啟動穩定性至關重要。OpoInstall 是一個行動歸因與深度連結平台，將跨沙箱路由、通道追蹤與參數還原機制封裝成專為 Android 及 iOS 建置工具鏈設計的原生客戶端程式庫。

在行動系統架構中，SDK 不僅僅是一組可呼叫的應用程式介面（API）。它是一個可發布的建置構件，能在編譯時期連結階段，將其編譯後的位元組碼或機器碼片段、資源表與資訊清單宣告整合至主應用程式的可執行封裝中。

術語	定義	相關實體	搜尋意圖角色
SDK 意義	軟體開發套件作為連結至主應用程式之程式庫、API 與工具套件的架構定義。	主應用程式二進位檔	資訊型
Android 封存檔（`.aar`）	Android 程式庫的二進位發布格式，包含編譯後的位元組碼、資源與資訊清單規則。	Gradle 建置系統	技術 / 資訊型
XCFramework（`.xcframework`）	蘋果的多平台二進位套件格式，封裝了適用於 iOS、macOS 與 Catalyst 的裝置與模擬器變體。	Xcode 連結器	技術 / 資訊型
技術成長協議	由歸因 SDK 所實作的原生路由、安裝推薦來源、參數還原與事件回報機制的集合。	應用程式參數安裝	商業 / 技術型

原生行動二進位檔編譯中的 SDK 意義是什麼

超越縮寫：當您將軟體開發套件連結至行動 App 時會發生什麼事

就入門層級而言，縮寫 SDK 代表軟體開發套件（Software Development Kit），這是一個廣泛的術語，可涵蓋原始碼程式庫、命令列編譯器、硬體偵錯工具與程式碼範例。然而，對於行動系統架構師與發布工程師而言，實務上的 SDK 意義是由第三方程式庫在編譯期間如何實體修改主應用程式來定義的。關於 SDK 的更廣泛定義及其與無狀態網頁 API 的運作差異，請參閱我們的基礎指南：軟體開發套件如何驅動行動歸因與成長。

有別於遠端網頁 API（透過伺服器端基礎架構公開，並在客戶端建構請求與處理響應時透過網路呼叫），行動專案的建置系統（Android 上的 Gradle，或 iOS 上的 Xcode、CocoaPods 與 Swift Package Manager）會直接內嵌行動 SDK。一旦完成連結，SDK 的程式碼就不再是獨立的外部服務；其類別、符號與設定規則會成為發布給終端使用者的應用程式二進位檔的一部分，並共享主 App 的處理程序記憶體、權限以及 App Store 或 Google Play 的合規責任。

編譯、位元組碼 DEX 封裝與原生連結模型

由於 Android 與 iOS 使用不同的執行階段架構，建置工具鏈透過三種不同的編譯與連結路徑來整合行動 SDK 二進位檔：

Android 受管位元組碼編譯（Java/Kotlin 轉譯為 DEX）：在 Android 上，SDK 內部的高階 Java 與 Kotlin 原始碼首先會被編譯成 JVM 位元組碼（.class 檔案）。當主應用程式建置時，Android 的 D8 與 R8 編譯器會將來自主 App 以及所有已連結 SDK 的 .class 位元組碼轉換成 Dalvik 可執行（.dex）檔案，同時由 R8 執行程式碼精簡、最佳化與混淆，以剔除未使用的實作方法。
iOS 原生靜態連結（靜態封存檔 .a 轉譯為 Mach-O）：在 iOS 上，當 SDK 以靜態程式庫（.a）或靜態框架的形式發布時，原生連結器（ld）會擷取已編譯的機器碼物件檔（.o）並將其直接合併至主應用程式的主要 Mach-O 可執行二進位檔中。靜態連結消除了應用程式冷啟動期間的執行階段動態載入器負荷，同時死碼剝除（dead-code stripping）會在連結時移除未被參照的符號。
動態框架與共用原生程式庫（.framework / .dylib 及 JNI .so）：在 iOS 上，以動態框架封裝的 SDK 會被打包在應用程式封存檔的 Frameworks/ 目錄中，並在 App 啟動時由蘋果的動態載入器（dyld）載入記憶體中。在 Android 上，SDK 內部的預編譯 C 或 C++ 原生程式庫則會被打包為共用物件（.so）程式庫，並透過 Java Native Interface（System.loadLibrary）進行載入。雖然動態框架允許在 iOS App 擴充功能之間共用程式碼，但在啟動時載入大量的動態框架會增加 dyld 在執行 main() 之前的重定基底與繫結負荷。

建置系統如何整合 SDK 程式碼、資源、資訊清單與主 App 功能

Android 與 iOS 建置管線將 SDK 二進位檔整合至各自的應用程式封裝中。

在建置管線期間，主工具鏈會將 SDK 封裝的詮釋資料與主專案的安全性設定進行共同處理：

Android 資訊清單合併：每個 Android .aar 程式庫都包含一個 AndroidManifest.xml，用以宣告 SDK 所需的權限或元件。在 Gradle 編譯期間，Android 資訊清單合併工具（Android Manifest Merger）會將 SDK 的資訊清單節點與主應用程式的資訊清單進行結合。如果 SDK在其隨附的資訊清單中宣告了不必要的權限，除非明確使用 tools:node="remove" 進行剔除，否則這些權限將會被最終合併後的資訊清單所繼承。
iOS 主機功能與權利（Entitlements）：與 Android 資訊清單不同，iOS 系統權利（例如用於通用連結的 com.apple.developer.associated-domains）不會自動從第三方的 XCFramework 合併至主 App 中。相反地，開發人員必須在 Xcode 的主應用程式標靶（Target）中明確啟用所需的各項功能，並使用經由 Apple Developer 入口網站授權的描述檔（Provisioning Profile）來簽署 App 二進位檔。
發布構件封裝：在 Android 上，當主應用程式為了上架發布而進行建置時，Android App Bundle（.aab）作為發布構件而非可直接安裝的應用程式封裝；Google Play App Bundle 交付會將 .aab 處理成特定裝置專屬的 .apk 套件並交付給使用者。在 iOS 上，Xcode 會將可執行檔與內嵌框架編譯並簽署為 .ipa 封存檔，以供 App Store 發布之用。

經解構的 Android AAR 與 Apple XCFramework 套件展示了distinct 的行動 SDK 二進位結構。

行動 SDK 構件剖析：深入 Android AAR 與 iOS XCFramework 套件內部

深入 Android AAR 封存檔：位元組碼、資訊清單、資源與原生程式庫

根據 Google Android 開發人員指南關於 Android 封存檔（AAR）結構的說明，AndroidManifest.xml 是 .aar 封存檔中唯一強制規定的項目；其他項目——包含 classes.jar、R.txt、res/、原生 .so 程式庫與 proguard.txt——皆為選用，並取決於該程式庫的實作方式：

/AndroidManifest.xml（強制規定）：宣告程式庫的套件命名空間、最低支援 SDK 版本（minSdk），以及任何所需的系統權限或元件宣告。
/classes.jar（選用）：包含已編譯的 Java 與 Kotlin 位元組碼（.class 檔案），用以公開 SDK 的公開 API 類別與內部實作邏輯。
/res/ 與 /R.txt（選用）：包含隨附的 UI 版面配置、可繪製資產或字串表格，以及其符號 ID 對應關係。對於非視覺化的基礎架構 SDK（例如行動歸因與深度連結程式庫），省略 UI 資源可避免不必要的資源表膨脹。
/jni/[abi]/lib*.so（選用）：針對特定 CPU 應用程式二進位介面（arm64-v8a、armeabi-v7a、x86_64）預編譯的 C 或 C++ 原生程式庫。
/proguard.txt（選用）：消費者 ProGuard 或 R8 規則，用於指示主 App 的程式碼精簡器在發布精簡期間必須保留哪些 SDK 類別或回呼介面。

深入 iOS XCFramework 套件：Info.plist、平台變體切片、標頭檔與模組

在蘋果平台上，發布二進位 SDK 需要同時支援實體 iOS 裝置（ARM64）以及執行 iOS 模擬器（ARM64 Apple Silicon 與 x86_64 Intel）的 macOS 開發機器。為了在不發生肥胖二進位檔（fat-binary）衝突的情況下支援多架構發布，蘋果推出了 Apple XCFramework（.xcframework）規格。標準的 .framework 建置通常針對特定的平台變體，並可能包含一或多個支援的 CPU 架構，而 .xcframework 套件則將多個平台與架構變體——例如實體 ARM64 iOS 裝置切片與 iOS 模擬器切片——封裝至單一可發布的目錄中：

Info.plist（根資訊清單）：列出所有可用的程式庫變體（AvailableLibraries），並指定其 SupportedPlatform（ios）、SupportedPlatformVariant（模擬器與裝置之分）以及 SupportedArchitectures（arm64、x86_64）。
ios-arm64/ 與 ios-arm64_x86_64-simulator/：平台專屬的子目錄，包含該目標的 .framework 或靜態 .a 二進位檔。在封存建置期間，Xcode 僅會選取實體裝置切片，並將模擬器切片自最終的 .ipa 中排除。
Headers/ 與 Modules/：公開的 Objective-C .h 標頭檔（例如 OpoInstallSDK.h）以及 Clang module.modulemap 檔案，向 Objective-C 與 Swift 編譯器公開型別定義。

# 說明性二進位目錄比較：Android .aar 對比 iOS .xcframework
# 注意：在 .aar 中僅 AndroidManifest.xml 為強制規定；內部的 XCFramework 路徑會因廠商建置而異。

opoinstall-android-sdk.aar                 libOpoInstallSDK.xcframework/
├── AndroidManifest.xml (強制規定)        ├── Info.plist
├── classes.jar (選用)                     ├── ios-arm64/
│   └── com/opoinstall/api/                │   ├── Headers/
│       ├── OpoInstall.class               │   │   └── OpoInstallSDK.h
│       ├── OpoData.class                  │   └── libOpoInstallSDK.a
│       ├── OpoError.class                 └── ios-arm64_x86_64-simulator/
│       └── ResultCallBack.class               ├── Headers/
└── proguard.txt (選用)                    │   └── OpoInstallSDK.h
                                               └── libOpoInstallSDK.a

[第三方行動 SDK 構件]
       |
       +---> Android (.aar) ---> [AndroidManifest.xml + 選用的 classes.jar / proguard.txt]
       |                                  |
       |                                  v (Gradle 資訊清單合併工具與 D8/R8 DEX 編譯器)
       |                         [主 App .aab 發布構件 -> Google Play .apk]
       |
       +---> iOS (.xcframework) -> [ios-arm64 裝置切片 + ios-模擬器切片]
                                          |
                                          v (Xcode 連結器剝除模擬器切片)
                                 [主 App .ipa 裝置可執行檔]

封裝在歸因 SDK 內部的技術成長協議

在本文中，「技術成長協議」係指由行動歸因 SDK 所實作的原生路由、安裝推薦來源、參數還原與事件回報機制的集合，而非單一的正式標準。檢視這些機制有助於釐清為什麼成長團隊會將客戶端 SDK 連結至其二進位檔中，而非僅依賴網頁追蹤指令碼。

原生行動 SDK 協調應用程式連結、支援的安裝上下文以及非同步歸因遙測。

協議 1：URI Scheme 與通用連結或 App 連結路由攔截

當使用者點擊 H5 網頁上的宣傳連結（https://links.example.com/offer?room_id=402）時，行動成長 SDK 會針對已經安裝該 App 的使用者協調應用程式內的直接路由：

系統驗證交握：在 iOS 9+ 上，蘋果通用連結（Universal Links）透過與主 App 的 applinks: 權利相關聯的 HTTPS 託管 apple-app-site-association（AASA）JSON 檔案來驗證網域所有權。在 Android 上，已驗證的 Android App 連結會在宣告 http 與 https 方案以及目標 android:host 的 <intent-filter> 上使用 android:autoVerify="true"，並針對包含 App 套件名稱與 SHA-256 簽署憑證指紋的託管 /.well-known/assetlinks.json 數位資產連結檔案進行驗證。
生命週期攔截：當作業系統透過已驗證的連結或根據 IETF RFC 3986 的備用自訂 URI 方案（scheme://）喚醒應用程式時，原生 SDK 會攔截傳入的 Intent（在 Android 上透過 onCreate 或 onNewIntent）或 NSUserActivity / UIOpenURLContext（在現代基於場景的 iOS App 中透過 UISceneDelegate，或是蘋果針對支援場景的 App 標示為已棄用的傳統 UIApplicationDelegate URL 處理方法），解析查詢酬載，並將路由參數交付給主 App。

協議 2：應用程式商店安裝推薦來源 IPC 繫結

當應用程式尚未安裝且使用者從 Google Play 商店下載時，瀏覽器 Cookie 無法跨越 Android 作業系統沙箱進入新安裝的 App 中。為了在 Android 上以確定性方式彌補此一落差，客戶端 SDK 會使用官方的 Google Play 安裝推薦來源 API 來實作處理程序間通訊（IPC）機制。

在首次啟動時，SDK 會透過 Android 的 Binder IPC 介面繫結至 Google Play 商店服務，並讀取 install_referrer 字串以及點擊與安裝開始的時間戳記。由於 Google Play 安裝推薦來源 API 專門適用于符合資格的 Google Play 商店安裝流程，因此 Google Play 以外的 Android 發布管道會利用伺服器端 H5 參數比對或匯出的 Android 通道封裝（攜帶內嵌 channelCode 詮釋資料的 APK 檔案）。

協議 3: 非同步參數還原與工作階段對帳交握

對於跨平台的網頁轉 App 之旅（包含 iOS App Store 安裝，在此情況下蘋果並不提供相當於 Google Play 安裝推薦來源的一般網址查詢參數傳遞機制），客戶端 SDK 會根據 IETF RFC 9110 透過 HTTPS 執行非同步參數還原交握：

安裝前網頁上下文上傳: 當使用者造訪 H5 分享頁面時，已整合的網頁 JS SDK 會解析附加在網址上的自訂參數（例如邀請者 ID 或 channelCode），並將安裝前的工作階段記錄上傳至歸因伺服器。
安裝後客戶端交握: 當使用者開啟新安裝的 App 時，客戶端 SDK 會進行初始化並透過 HTTPS 與歸因伺服器通訊，透過其租戶 AppKey 識別已註冊的應用程式，並使用供應商所需的任何額外工作階段驗證或認證機制。伺服器隨後會嘗試還原快取的自訂參數（data）與通道識別碼（channelCode）。內嵌的 AppKey 不應被視為獨立的認證密鑰。
廠商機制與平台隱私邊界: OpoInstall 的公開產品說明文件描述了一種 H5 通道與參數安裝工作流程，其中網頁 SDK 在 H5 頁面上收集裝置指紋與通道 ID，而原生 Android/iOS SDK 則在首次啟動時重新收集裝置指紋以比對安裝來源。根據蘋果的使用者隱私與資料使用指南，蘋果明確禁止從裝置衍生資料以獨特識別使用者或裝置（指紋辨識），且參照從事禁止之指紋辨識的第三方 SDK 的 App 將面臨 App Store 拒絕上架的風險。另外，當第三方深度連結或延遲深度連結服務在來自不同公司的 App 之間傳遞獨特識別碼或建立共用使用者身分以供廣告指定、廣告衡量或資料經紀商共用時，必須取得 App 追蹤透明度（ATT）授權——且 ATT 同意並不能使被禁止的裝置指紋辨識行為合法化。如果廠商無法證明其 iOS 比對機制避免了被禁止的裝置指紋辨識，開發人員切勿在 iOS 上部署該歸因機制，直到有獨立驗證的合規替代方案為止。

Protocol 4：已去重複的通道與轉換事件遙測

一旦安裝來源解析完成，SDK 即提供非同步事件回報介面。透過在 App 端對安裝與註冊報告進行去重複處理，並允許開發人員回報自訂轉換「效果點」（saveEvent / reportEffectPoint）或病毒式分享動作（帶有 shareCode 的 reportShare），SDK 支援通道效能分析而不需自訂重試佇列。詳細規格與 API 定義可於 OpoInstall 技術文件中查閱。

稽核 SDK 二進位檔佔用空間與可遞移相依性

為什麼 SDK 臃腫對行動工程與使用者獲取至關重要

如蘋果的減少 App 大小（App Thinning）指南中所述，較大的應用程式封裝可能會增加下載時間與儲存空間需求，進而可能影響受限網路或裝置環境中的安裝完成率。任何第三方 SDK 的影響都應該透過經驗性的建置大小量測與觀察到的漏斗指標來量化，而不應僅從套件大小來臆測。

可遞移相依性的隱藏成本：方法參照限制與程式庫衝突

造成 SDK 臃腫與建置不穩定的主因通常不是 SDK 的核心歸因邏輯；相反地，它是可遞移相依性（Transitive Dependencies）——即 SDK 透過 Gradle 或 CocoaPods 自動拉入主專案中的外部開源程式庫：

相依性版本衝突：如果第三方 SDK 宣告對常見網路或序列化程式庫（例如 OkHttp、Gson、Retrofit 或 Protobuf）特定版本的可遞移相依性，而主應用程式使用該相同程式庫的不相容主要版本，則建置可能會因重複類別錯誤而失敗，或在執行階段因 NoSuchMethodError 例外狀況而當機。

DEX 方法參照負荷：在 Android 上，根據 Android Multidex 技術指南，每個獨立的 .dex 檔案限制為 65,536 個方法參照。這是一項針對單一 DEX 檔案的參照限制，而非通用的整個應用程式方法限制；multidex 允許應用程式跨多個 DEX 檔案封裝參照，儘管引入龐大的可遞移相依性樹狀結構仍會增加 DEX 檔案數量、R8 編譯時間以及最終的 APK 大小。

供應鏈安全性面貌：根據 OWASP 行動應用專案安全性標準，SDK 引入的每一個可遞移程式庫都會擴大應用程式的軟體供應鏈攻擊面，並需要持續進行弱點監控。

因此，極簡主義的歸因 SDK 應避免不必要的外部可遞移相依性，改為依賴行動作業系統內建的網路功能（HttpURLConnection / NSURLSession）與原生 JSON 解析器（org.json / NSJSONSerialization）。

使用 Android Studio APK Analyzer 與 Xcode App Thinning 報告檢查實際二進位檔影響

在評估 SDK 的佔用空間時，工程團隊絕不應僅依賴未經證實的大小聲稱或已下載 .zip 封存檔的原始壓縮大小。雖然 OpoInstall 的行動 SDK 下載中心發布了原生 Android 與 iOS SDK 套件（目前為 v2.1.0，於 2026-09-20 發布），但實際的已編譯位元組差值、可遞移相依性數量以及 DEX 方法參照增量，必須透過在您自己的專案上比較基準建置與已整合 SDK 的建置來進行經驗性量測：

Android 相依性樹狀結構與 APK Analyzer：執行 Gradle 的相依性任務以驗證 SDK 是否引入不需要的可遞移程式庫，並使用官方的 Google Android 開發人員指南關於 APK Analyzer（apkanalyzer CLI 或 Android Studio GUI）執行 apk compare 以取得檔案大小差異，對兩種建置執行 dex references 以比較方法參照數量，並執行 apk download-size 以估算下載大小的影響。
透過 App Thinning 大小報告進行 iOS 基準比較：由於 .xcframework 封存檔同時包含實體裝置與模擬器切片，其在磁碟上的原始資料夾大小並不等於終端使用者下載的大小。請使用相同的發布設定，在 Xcode Organizer 中為基準建置（不含 SDK）與已整合 SDK 的建置匯出 App Thinning 大小報告。比較相同裝置變體的壓縮與未壓縮大小（ $\Delta S = S_{\text{with SDK}} - S_{\text{baseline}}$ ）以估算 SDK 的增量佔用空間，並在 App Store Connect 中驗證最終的分發大小。

以下 CLI 命令說明了如何稽核可遞移相依性、APK 大小差值以及 XCFramework 切片（請注意，下方的 xcrun lipo 路徑僅供說明；在建構 lipo 命令之前，務必檢查 .xcframework 內部的實際 Info.plist 與選定的程式庫變體）：

基準與已整合 SDK 的發布建置揭示了二進位大小、相依性與方法參照的差異。

# 1. Android：檢查發布執行階段相依性以驗證零不需要的可遞移程式庫
./gradlew :app:dependencies --configuration releaseRuntimeClasspath

# 2. Android：檢查基準與已整合 SDK 的 APK 中的 DEX 方法參照數量
apkanalyzer dex references baseline-release.apk
apkanalyzer dex references with-sdk-release.apk

# 3. Android：檢查原始 APK 檔案大小與估算的空中下載大小
apkanalyzer apk file-size with-sdk-release.apk
apkanalyzer apk download-size with-sdk-release.apk

# 4. Android：比較基準 APK（無 SDK）與整合 SDK 的 APK
apkanalyzer apk compare baseline-release.apk with-sdk-release.apk

# 5. iOS：檢查 XCFramework 根目錄 plist 中的支援平台與架構變體
plutil -p libOpoInstallSDK.xcframework/Info.plist

# 6. iOS：檢查 Info.plist 後對特定裝置二進位切片進行的說明性 lipo 檢查
xcrun lipo -info libOpoInstallSDK.xcframework/ios-arm64/libOpoInstallSDK.a

行動 SDK 二進位佔用空間與架構評估矩陣

比較重型單體式 SDK 與極簡主義歸因 SDK

在對第三方行動 SDK 進行架構審查時，工程主管可以從以下五個結構維度來評估候選項目：

評估標準	重型單體式 SDK	極簡主義歸因 SDK	對主 App 的架構影響
可遞移相依性	引入外部網路、JSON 或 UI 程式庫	使用原生作業系統網路與解析器且自給自足	預防 Gradle 與 CocoaPods 版本衝突
已編譯二進位佔用空間	每個架構切片增加數百萬位元組（MB）	精簡佔用空間（透過 APK Analyzer 與 App Thinning 量測 $\Delta S$ ）	減少下載負荷與儲存空間壓力
DEX 方法參照數量	跨隨附子模組的數千個參照	專注的公開 API 介面且參照負荷低	將額外的 DEX 分片擴充降至最低
原生 `.so` / C++ 橋接	多個架構二進位檔（`armeabi-v7a`、`arm64-v8a`）	純 JVM 位元組碼 / Objective-C 或極小的原生佔用空間	簡化 ABI 篩選與 64 位元商店合規性
隱私與政策面貌	廣泛的硬體、位置與感測器 API 存取	僅限於歸因與深度連結路由機制	需要針對蘋果與谷歌規則進行獨立稽核

工程團隊何時需要專屬的成長 SDK

架構上正當合理的輕量級歸因 SDK 情境

在下列情況下，整合專屬的行動歸因與深度連結 SDK 是合適的：

跨沙箱參數還原：您的獲客漏斗將使用者從 H5 網頁、社群分享或 QR Code 透過 App Store 或 Google Play 進行引導，且需要在首次啟動時還原自訂參數（例如推薦碼或房間 ID），而無需手動輸入程式碼。
統一的深度連結路由維護：您的團隊希望有一個單一的客戶端回呼介面，以處理跨各種行動瀏覽器與社群應用程式內 WebView 的通用連結、Android App 連結與備用自訂網址方案。
多通道 H5 與 APK 封裝追蹤：您的行銷營運團隊跨 H5 通道連結與 Android 通道封裝分發行銷活動，並需要整合的安裝、註冊與轉換事件回報。

應避免新增其他行動 SDK 的情境

相反地，在下列情況下應避免新增第三方的客戶端 SDK：

重複的客戶端功能：如果擬議的 SDK 重複了您的應用程式已經使用原生作業系統 API 或現有核心程式庫乾淨地實作的功能。
未經證實的隱私或合規態勢：如果 SDK 依賴裝置比對訊號（例如 iOS 上被禁止的裝置指紋辨識），而這些訊號無法被獨立驗證為符合目前的 App Store 審查指南與區域資料保護法規。
純粹的後端分析工作流程：如果您需要追蹤的事件完全發生在已驗證的後端伺服器上（例如定期訂閱續約），此時直接的伺服器對伺服器（S2S）HTTP API 可以完全避免任何客戶端二進位檔佔用。

關於行動 SDK 架構的常見誤解

誤解 1：下載的 SDK Zip 大小等於 App 大小增加量：已下載的 .xcframework 或 .aar 封存檔包含模擬器切片、標頭檔與未壓縮的詮釋資料，這些會在發布編譯期間被 Xcode App Thinning 與 Android R8 所剝除。務必量測基準發布建置與整合 SDK 的發布建置之間的增量差值（ $\Delta S$ ）。
誤解 2：零可遞移相依性等於零隱私稽核：即使是使用零第三方開源程式庫的自給自足 SDK，仍然是在您的應用程式隱私邊界內執行。工程團隊必須在發布前稽核 SDK 收集的每一個網路請求、plist 宣告與裝置訊號。

常見問題（FAQ）

檢查 Android AAR 與 iOS XCFramework 檔案時，SDK 的意義是什麼？

在行動建置系統中，SDK 的意義是指預編譯的程式庫封存檔——具體而言是 Android 上的 `.aar` 檔案（其中 `AndroidManifest.xml` 為強制規定，並伴隨選用的 `classes.jar` 位元組碼與資源）或是 iOS 上的 `.xcframework` 套件（封裝了各自獨立的裝置與模擬器變體）——它能在不從頭編譯提供者原始碼的情況下，將專門的功能連結至主 App 中。

如何量測行動 SDK 為我的 App 增加了多少大小？

在相同的編譯器設定下，比較基準發布建置與整合 SDK 的發布建置。在 Android 上，使用 `apkanalyzer apk compare` 來檢查 APK 檔案大小差異，在兩種建置上執行 `apkanalyzer dex references` 以比較方法參照，並使用 `apkanalyzer apk download-size` 來估算下載大小的影響。在 iOS 上，於 Xcode Organizer 中為兩種建置匯出 App Thinning 大小報告，並從整合變體大小中減去基準變體大小（$\Delta S = S_{\text{with SDK}} - S_{\text{baseline}}$)。

為什麼第三方 SDK 中的可遞移相依性會導致建置失敗？

當第三方 SDK 將常見的開源程式庫（例如 OkHttp、Gson 或 Protobuf）宣告為可遞移相依性時，這些版本可能會與主應用程式所使用的相同程式庫之不同版本發生衝突，從而觸發編譯時期的重複類別錯誤或執行階段的 `NoSuchMethodError` 當機。

總結與二進位評估檢查清單

理解行動開發中真正的 SDK 意義，需要看透高階的縮寫定義，進而檢查編譯後的程式庫如何合併至您的應用程式二進位檔中並執行技術成長協議。一個設計良好的行動歸因 SDK 封裝了跨沙箱路由、安裝推薦來源繫結與參數還原，同時保持其二進位佔用空間與可遞移相依性樹狀結構達到最小。

在核准任何第三方行動 SDK 進行正式環境發布之前，工程主管應執行此二進位與合規驗證檢查清單：

檢查相依性樹狀結構：執行 ./gradlew :app:dependencies --configuration releaseRuntimeClasspath 或檢查 Podfile.lock，以確認 SDK 是否引入了衝突的可遞移程式庫。
量測編譯後的增量大小（ $\\Delta S$ ）：在 Android 上使用 apkanalyzer apk compare，並在 iOS 上使用基準與整合的 App Thinning 大小報告，來比較基準發布建置與整合 SDK 的建置（針對目前下載的封存檔進行測試，例如 v2.1.0）。
驗證 API 簽章與乾淨建置：在乾淨的建置環境中確認所有套件匯入、資訊清單過濾器（針對 Android App 連結的 http 與 https 方案）以及生命週期回呼（UISceneDelegate 與已棄用的 AppDelegate URL 方法之比較）。
稽核協議與隱私合規性：與供應商確認所有深度連結權利、安裝推薦來源繫結與伺服器端比對訊號均避免了被禁止的裝置指紋辨識，並符合目前的蘋果使用者隱私指南與 Google Play 政策。

工程團隊可以在 OpoInstall 開發人員主控台上註冊測試應用程式，以在預備（Staging）建置中評估 SDK 整合並量測二進位佔用空間。