Bagaimana Kit Pembangunan Perisian (SDK) Memacu Atribusi dan Pertumbuhan Mudah Alih

opoinstall
2026-11-04
5 min read

Apakah itu SDK dan bagaimana ia berfungsi? Kit Pembangunan Perisian (SDK) ialah koleksi pustaka, API, alat, dan dokumentasi yang direka untuk membantu pembangun membina atau memperluas aplikasi perisian. Dalam pembangunan mudah alih, SDK lazimnya merangkumi pustaka terkompil yang disepadukan ke dalam aplikasi asli untuk menyediakan fungsi khusus platform seperti pautan mendalam dan atribusi. Apabila pasukan kejuruteraan mudah alih menilai cara data pemerolehan pengguna mengalir dari promosi web ke dalam aplikasi yang baru dipasang, mereka menghadapi halangan sistem pengendalian asas: antara muka web jauh tidak boleh mengakses kitaran hayat aplikasi asli atau merentasi sandbox gedung aplikasi secara sendirian. OpoInstall, platform atribusi dan pautan mendalam mudah alih, menyediakan pustaka klien asli dan skrip web yang menyelaraskan persekitaran terpencil ini untuk memulihkan parameter kempen dan menghalau pengguna ke paparan dalam apl yang disasarkan.

Kit Pembangunan Perisian (SDK) ialah koleksi pustaka prapakek, antara muka pengaturcaraan aplikasi (API), fail kepala, dokumentasi pembangun, dan kod sampel yang direka untuk sistem pengendalian atau rangka kerja tertentu. Tidak seperti API web jauh kendiri yang mentakrifkan antara muka komunikasi tanpa keadaan melalui HTTP, SDK mudah alih dilaksanakan secara langsung dalam proses masa jalan aplikasi klien untuk mengurus keadaan tempatan, panggilan balik kitaran hayat sistem pengendalian, dan telemetri rangkaian tak segerak.

Term Definition Related Entity Search Intent Role
What is an SDK A comprehensive package of libraries, APIs, documentation, and tools used to build or extend software applications. Mobile Operating System Informational
Mobile SDK A platform-specific library integrated into Android or iOS apps to provide specialized client-side functionality. Native Runtime Lifecycle Informational / Technical
API A defined contract of rules, method signatures, and protocols that allows two software components to communicate. HTTP REST Endpoint Informational
Deep Linking Routing protocols that launch a native mobile application directly to a specific internal view. App Parameter Installation Technical / Commercial

Apakah Itu SDK dan Bagaimana Ia Berbeza daripada API Web Standard

Perbandingan visual seni bina SDK mudah alih asli dan infrastruktur API REST jauh, menunjukkan integrasi masa jalan dan komunikasi sebelah pelayan.

Menghuraikan Terminologi: Mengapa Setiap SDK Mengandungi API, tetapi API Bukanlah SDK

Dalam kejuruteraan perisian, pembangun yang baru mengenal infrastruktur pertumbuhan mudah alih kerap mencampuradukkan Antara Muka Pengaturcaraan Aplikasi (API) dengan Kit Pembangunan Perisian (SDK). Walaupun kedua-dua konsep ini beroperasi bersama, ia menduduki lapisan seni bina yang berbeza.

API adalah semata-mata spesifikasi antara muka dan kontrak komunikasi. Ia mentakrifkan tandatangan kaedah, struktur data, sintaks URI mengikut IETF RFC 3986, dan format respons yang membolehkan satu komponen perisian berinteraksi dengan komponen lain. API wujud pada pelbagai tahap: ia boleh menjadi antara muka sistem pengendalian tempatan, antara muka pustaka dalam proses, atau titik akhir web tanpa keadaan jauh yang dikawal oleh semantik HTTP IETF RFC 9110 (GET, POST). Apabila memanggil API REST jauh secara langsung, pembangun aplikasi mesti membina permintaan rangkaian, mengurus keselamatan pengangkutan, menghurai muatan JSON yang dikembalikan, dan mengendalikan syarat cubaan semula secara manual.

Sebaliknya, SDK ialah kit pelaksanaan lengkap yang merangkumi satu atau lebih API tempatan di samping logik masa jalan, dokumentasi, and alat pembangun. Apabila pembangun mengimport SDK mudah alih ke dalam projek Android Studio atau Xcode, mereka memautkan kod pustaka prabina secara terus ke dalam binari aplikasi mereka. SDK mendedahkan API pengaturcaraan tempatan (seperti initialize(), getInstallParam(), atau handleDeepLink()) kepada aplikasi hos sambil menguruskan penjadualan benang, panggilan balik sistem pengendalian, dan komunikasi pelayan jauh secara dalaman.

Konteks Pelaksanaan: Titik Akhir Pelayan-ke-Pelayan Tanpa Keadaan vs. Pustaka Masa Jalan Sebelah Klien Berkeadaan

Perbezaan operasi antara memanggil API web jauh dan menyepadukan SDK mudah alih asli tertumpu pada konteks pelaksanaan dan akses kepada persekitaran peranti:

  • Kependudukan Proses dan Pembungkusan: API web jauh didedahkan melalui infrastruktur sebelah pelayan dan dipanggil melalui rangkaian; aplikasi sebelah pelayan melaksanakan titik akhir, manakala aplikasi klien melaksanakan logik pengendali permintaan. Sebaliknya, SDK mudah alih dikompilkan ke dalam artefak penerbitan aplikasi (seperti Android App Bundle .aab) atau pakej aplikasi boleh pasang (.apk pada Android dan .ipa pada iOS) dan dilaksanakan di dalam ruang memori yang diperuntukkan oleh aplikasi pada peranti pengguna akhir.
  • Kesedaran Kitar Hayat Asli: Titik akhir REST jauh hanya bertindak balas apabila klien menghantar permintaan HTTP. SDK mudah alih asli mendaftarkan pemerhati dengan sistem pengendalian mudah alih, membolehkannya mengesan apabila aplikasi dilancarkan, beralih antara keadaan latar depan dan latar belakang, atau menerima niat penghalaan peringkat sistem.
  • Kegigihan Tempatan Pilihan dan Baris Gilir: Bergantung pada pelaksanaannya, SDK mudah alih boleh menyimpan keadaan konfigurasi atau peristiwa penukaran baris gilir dalam storan bersandbox tempatan (seperti SharedPreferences atau SQLite pada Android, dan UserDefaults atau storan fail aplikasi pada iOS, sambil rizab Keychain untuk kelayakan sensitif kecil) supaya telemetri boleh dihantar secara tak segerak apabila ketersambungan rangkaian tersedia.

Perbandingan Seni Bina: API Web Jauh vs. SDK Mudah Alih Asli

Jadual di bawah membandingkan API web tanpa keadaan jauh dengan SDK mudah alih asli terkompil merentas dimensi seni bina utama:

Dimensi Seni Bina Web Tanpa Keadaan Jauh / API REST SDK Mudah Alih Asli
Artefak Utama Spesifikasi antara muka dan titik akhir rangkaian jauh Pustaka binari terkompil, API tempatan, dokumentasi, dan kod sampel
Persekitaran Pelaksanaan Titik akhir pelayan jauh yang dipanggil melalui HTTP/HTTPS Proses aplikasi mudah alih asli dan benang OS
Akses kepada Kitar Hayat OS Tiada (Permintaan-respons tanpa keadaan sahaja) Akses terus kepada pelancaran apl, latar belakang, dan cangkuk niat
Kegigihan Rentas Pemasangan Disekat oleh sempadan sandbox gedung aplikasi Android: Google Play Install Referrer + padanan pelayan; iOS: rekonsiliasi konteks sebelah pelayan
Ketahanan Rangkaian Memerlukan logik cubaan semula tersuai yang ditulis oleh pemanggil Mungkin menyediakan kegigihan tempatan, baris gilir peristiwa, pengecalaman, dan mekanisme cubaan semula tak segerak, bergantung pada pelaksanaan

Komponen Teras di Dalam Kit Pembangunan Perisian Mudah Alih

Pustaka Binari Terkompil: Bundle Arkib Android dan Rangka Kerja iOS

K teras bagi SDK mudah alih ialah pengagihan binari terkompil yang diformat untuk rantaian alat binaan sistem pengendalian sasaran:

  • Android Archive (.aar), JAR, dan App Bundles (.aab): Pada Android, SDK diedarkan sebagai bundle .aar atau pustaka .jar. Walaupun fail .jar mengandungi kod byte JVM terkompil, bundle .aar juga boleh membungkus sumber dan entri manifest khusus Android yang bergabung ke dalam aplikasi hos semasa binaan Gradle. Apabila aplikasi hos dibina untuk keluaran, Android App Bundle (.aab) berfungsi sebagai artefak penerbitan dan bukannya pakej aplikasi yang boleh dipasang secara terus; Google Play memprosesnya menjadi APK khusus peranti yang dihantar kepada pengguna.
  • Pustaka Statik iOS (.a), Rangka Kerja, dan XCFramework: Pada iOS, SDK diedarkan sebagai pustaka statik, bundle .framework, atau arkib .xcframework. Binaan .framework standard lazimnya mensasarkan varian platform tertentu dan mungkin mengandungi satu atau lebih seni bina CPU yang disokong, manakala bundle Apple XCFramework (.xcframework) direka bentuk untuk membungkus berbilang varian platform dan seni bina—seperti hirisan peranti ARM64 iOS fizikal di samping hirisan Simulator iOS—ke dalam satu artefak yang boleh diedarkan.

Fail Kepala Awam, Kontrak Antara Muka, dan Definisi Jenis

Binari terkompil memerlukan kontrak jenis awam supaya pengumpil aplikasi hos boleh mengesahkan panggilan kaedah pada masa binaan:

  • Fail Kepala iOS (.h) dan Antara Muka Penyelat: SDK iOS berasaskan Objective-C menyediakan fail kepala awam (seperti OpoInstallSDK.h) yang mengisytiharkan antara muka kelas, protokol delegasi (OpoInstallDelegate), dan model data (OpoinstallData). Dalam projek Swift, pengisytiharan ini didedahkan melalui Pengepala Penyelat Objective-C atau import modul.
  • Tandatangan Kelas Android dan Antara Muka Panggilan Balik: SDK Android mendedahkan kelas titik kemasukan awam dan antara muka panggilan balik generik (seperti ResultCallBack<OpoData>) dalam ruang nama pakej yang didokumenkan.

Pandangan seni bina terurai bagi komponen SDK mudah alih, termasuk pustaka terkompil, API awam, konfigurasi platform dan dokumentasi pembangun.

Manifest Konfigurasi, AppKeys, dan Perisytiharan Hak

SDK mudah alih bergantung pada metadata konfigurasi hos untuk mengesahkan permintaan penyewa dan mendaftarkan cangkuk penghalaan OS:

  • Pengenal Aplikasi Penyewa (AppKey): Diisytiharkan di dalam tag <meta-data> Android AndroidManifest.xml atau fail iOS Info.plist (com.opoinstall.APP_KEY), AppKey mengenal pasti penyewa aplikasi semasa permulaan SDK.
  • Perisytiharan Penghalaan OS: Untuk menyokong pelancaran apl satu klik, projek hos mengisytiharkan skema URL tersuai dan perkaitan domain disahkan (domain applinks: dalam hak Domain Berkaitan Xcode dan penapis niat disahkan pada Android).

Dokumentasi dan Projek Sampel: Menukar Pustaka Terkompil kepada Antara Muka Pembangun yang Boleh Digunakan

Pustaka terkompil sukar diterima pakai tanpa spesifikasi integrasi yang jelas. SDK gred pengeluaran harus menyediakan dokumentasi pembangun yang jelas dan, jika tersedia, projek sampel yang boleh dijalankan:

  • Dokumentasi Pembangun: Mentakrifkan keserasian versi, susunan permulaan kitaran hayat, kebenaran yang diperlukan, format muatan panggilan balik, and kod ralat supaya jurutera boleh menyepadukan pustaka secara boleh dijangka.
  • Projek Sampel dan Jambatan Rentas Platform: Projek demo boleh jalan minimum membantu pasukan mengesahkan pautan mendalam dan pemulihan parameter. Walaupun pusat muat turun SDK mudah alih terutamanya mengedarkan pakej SDK Android dan iOS asli teras (kini v2.1.0), pasukan yang menggunakan rangka kerja rentas platform (seperti Flutter atau Unity) merapatkan keupayaan SDK asli ini melalui plugin pembungkus atau saluran platform dan harus mengesahkan repositori plugin yang tersedia dengan dokumentasi rasmi.

Mengapa API Web Sahaja Tidak Dapat Menyelesaikan Atribusi Pemasangan Mudah Alih

Kotak Hitam Gedung Aplikasi: Bagaimana Pengasingan Sandbox Memecahkan Penjejakan Kuki Web Tradisional

Dalam pembangunan web standard, menjejak pautan rujukan kepada peristiwa pendaftaran bergantung pada storan pelayar: apabila pengguna melawati https://example.com/index.html?inviter_id=A102, JavaScript membaca rentetan pertanyaan dan menyimpan inviter_id=A102 dalam localStorage atau kuki HTTP.

Dalam pemerolehan apl mudah alih, kesinambungan ini terputus di sempadan gedung aplikasi—penghalang struktur yang dikenali sebagai Kotak Hitam Gedung Aplikasi:

  1. Konteks Web: Pengguna mengklik pautan promosi di dalam pelayar mudah alih atau apl sosial, memuatkan halaman mendarat H5 yang membawa parameter tersuai (?ref=userA&channelCode=ch_01).
  2. Serahan Pasaran: Oleh kerana apl asli belum dipasang, mengklik butang muat turun mengalihkan pengguna keluar dari pelayar dan masuk ke Apple App Store atau Google Play Store.
  3. Pengasingan Sandbox: Apabila pengguna memasang dan melancarkan apl asli, OS mudah alih memijar proses di dalam sistem fail dan sandbox memori yang terpencil. Apl asli tidak dapat membaca kuki atau localStorage sesi pelayar yang memulakan muat turun.

Merapatkan Jurang Web-ke-Apl: Peranan SDK Web JS dan SDK Klien Asli

Menyelesaikan parameter merentas sempadan gedung aplikasi menggunakan aliran kerja diselaraskan yang memisahkan tiga konsep berkaitan—Pautan Mendalam Tertunda (menghala baharu pengguna ke skrin dalam apl sasaran selepas pemasangan), Pemulihan Parameter Pemasangan (memulihkan pasangan kunci-nilai tersuai yang diluluskan pada pautan H5), dan Pemadanan Atribusi (mengkaitkan pemasangan dengan saluran promosi tertentu):

  • SDK Web JS Pra-Pemasangan (Skrip Web OpoInstall): Disepadukan ke dalam halaman mendarat H5, SDK Web JS menghurai parameter pertanyaan dinamik daripada URL perkongsian (seperti channelCode, shareCode, atau ID bilik) dan memuat naik konteks sesi pra-pemasangan ke pelayan atribusi sebelum mencetuskan pengaktifan apl atau pengalihan semula gedung.
  • SDK Klien Asli Pasca-Pemasangan (SDK Android / iOS): Disepadukan ke dalam binari apl mudah alih, SDK asli dimulakan pada pelancaran pertama, berkomunikasi dengan API platform dan pelayan atribusi, dan mengembalikan parameter tersuai yang dipulihkan kepada apl klien melalui panggilan balik tak segerak.

Seni bina atribusi web-ke-apl menunjukkan cara SDK JavaScript web dan SDK mudah alih asli menyelaraskan pemulihan parameter kempen merentas sempadan sandbox gedung aplikasi.

[Mobile Web Browser: H5 Landing Page]
                 |
                 | 1. Web JS SDK Parses URL Params (?ref=userA&channelCode=ch01)
                 |    & Uploads Pre-Install Session Context
                 v
     [Attribution Server Backend]
                 |
                 | 2. User Downloads App from App Store / Google Play
                 |    (Browser Cookies Cannot Cross OS Sandbox)
                 v
   [Native App First Launch: Mobile SDK]
                 |
                 | 3. Client SDK Initializes on Startup & Retrieves
                 |    Cached Custom Parameters + Channel ID
                 v
  [In-App Routing & Channel Attribution]

Mekanisme Atribusi Khusus Platform: Google Play Install Referrer vs. Rekonsiliasi Konteks iOS

Oleh kerana Android dan iOS mengekalkan seni bina gedung aplikasi yang berbeza, atribusi mudah alih bergantung pada mekanisme platform yang berbeza:

  • Ekosistem Android dan API Google Play Install Referrer: Untuk apl yang diedarkan melalui Google Play, integrasi asli boleh menggunakan rasmi API Google Play Install Referrer untuk mendapatkan semula metadata rujukan (termasuk URL perujuk dan cap waktu klik/pemasangan) yang diluluskan oleh Gedung Play semasa pemasangan. Oleh kerana API Google Play Install Referrer terpakai khusus pada aliran pemasangan Gedung Play Google yang layak, pengedaran Android di luar Google Play bergantung pada pemadanan parameter H5 sebelah pelayan atau Pakej Saluran Android yang dieksport (fail APK yang membawa pengenal channelCode terbenam).
  • Ekosistem iOS dan Rekonsiliasi Konteks: App Store Apple tidak menyediakan mekanisme laluan parameter pertanyaan URL umum yang setara dengan Install Referrer Google Play. Apabila apl telah dipasang, iOS menghalau pengguna secara terus ke dalam apl melalui Apple Universal Links, yang mengesahkan pemilikan domain melalui fail apple-app-site-association (AASA). Apabila apl tidak dipasang, Pautan Universal kembali ke tapak web dan tidak menjamin pemulihan parameter pasca-pemasangan secara bebas; pemulihan parameter tertunda memerlukan rekonsiliasi sesi sebelah pelayan pada pelancaran pertama.

Menghormati Sempadan Privasi Platform: Garis Panduan Privasi Pengguna Apple dan Isyarat Pemadanan Dibenarkan

Apabila menilai cara SDK mudah alih mendamaikan lawatan web pra-pemasangan dengan pelancaran pasca-pemasangan, pasukan kejuruteraan mesti membezakan ciri yang didokumenkan vendor daripada pematuhan dasar sistem pengendalian:

  • Mekanisme Didokumenkan Vendor: Dokumentasi produk awam OpoInstall menerangkan saluran H5 dan aliran kerja pemasangan parameter di mana SDK Web mengumpul ciri cap jari peranti dan ID saluran pada halaman H5, dan SDK Android/iOS asli mengumpul semula ciri peranti pada pelancaran pertama untuk memadankan sumber pemasangan.
  • Sempadan Dasar Platform Apple: Di bawah Garis Panduan Privasi Pengguna dan Penggunaan Data Apple, Apple secara jelas melarang penerbitan data daripada peranti—seperti menggabungkan sifat pelayar, alamat IP, atau konfigurasi sistem—untuk tujuan mengenal pasti pengguna atau peranti secara unik (cap jari). Aplikasi yang terlibat dalam cap jari terlarang, atau merujuk SDK pihak ketiga yang berbuat demikian, berisiko ditolak semasa semakan App Store. Secara berasingan, kebenaran App Tracking Transparency (ATT) diperlukan apabila perkhidmatan pautan mendalam pihak ketiga atau pautan mendalam tertunda meluluskan pengenal unik atau mencipta identiti pengguna berkongsi merentas apl daripada syarikat yang berbeza untuk penyasaran pengiklanan, pengukuran pengiklanan, atau perkongsian broker data. Walau bagaimanapun, persetujuan ATT tidak menjadikan cap jari peranti terlarang dibenarkan.
  • Eskalasi Pematuhan dan Keperluan Pengesahan: Jika versi SDK atau konfigurasi tertentu bergantung pada cap jari peranti terlarang, sama ada menjalankan audit data dalaman am mahupun mendapatkan persetujuan pengguna melalui gesaan ATT tidak menjadikan mekanisme tersebut mematuhi garis panduan Apple. Jika vendor tidak dapat menunjukkan bahawa mekanisme pemadanan iOS mengelakkan cap jari peranti terlarang, pembangun tidak seharusnya menyebarkan mekanisme atribusi tersebut pada iOS sehingga alternatif yang mematuhi telah disahkan secara bebas, mengikut amalan tadbir urus OWASP Mobile Application Security.
  • Masa Rangkaian and Sandaran Tanpa Atribusi: Walaupun iOS tidak mendedahkan kebenaran yang diberikan pengguna umum untuk akses internet biasa (pembangun harus membezakan kebolehlajuran internet am daripada kebenaran privasi Rangkaian Tempatan Apple, yang terpakai pada penemuan peranti rangkaian tempatan), permulaan SDK dan pengambilan parameter masih bergantung pada ketersediaan rangkaian and masa permulaan. Kerana pemadanan tertunda tidak dijamin merentas semua keadaan rangkaian atau pelancaran pertama yang tertunda, aplikasi mesti sentiasa melaksanakan aliran sandaran anggun apabila parameter yang dikembalikan kosong.

Bagaimana SDK Atribusi Mudah Alih Berfungsi Merentas Kitar Hayat Aplikasi

Kitar hayat SDK mudah alih asli menunjukkan integrasi pergantungan, permulaan aplikasi, pengendalian pautan mendalam, pengambilan parameter tak segerak dan pelaporan peristiwa atribusi pada Android dan iOS.

Fasa 1: Pengurusan Pergantungan dan Pautan Masa Binaan melalui Gradle dan CocoaPods

Kitar hayat SDK bermula pada masa kompil apabila pembangun mengisytiharkan pergantungan pustaka melalui Gradle, CocoaPods, atau import arkib manual. Semasa kompilasi binaan, pengurus pakej menyelesaikan artefak pustaka dan memautkan simbol binarinya ke dalam pakej aplikasi. Sesetengah SDK mudah alih memerlukan pertimbangan keserasian pengecutan kod khusus dalam binaan keluaran, dan integrasi SDK iOS mungkin juga memerlukan perisytiharan manifest privasi khusus platform dan konfigurasi binaan yang serasi.

Fasa 2: Permulaan Benang Utama pada Permulaan Aplikasi

Apabila pengguna melancarkan apl, OS mudah alih mencipta proses aplikasi dan memanggil cangkuk kitaran hayat titik kemasukan utama—Application.onCreate() pada Android seperti yang diperincikan dalam Panduan Pembangun Google Android mengenai Kitar Hayat Aplikasi, dan application(_:didFinishLaunchingWithOptions:) pada iOS seperti yang diperincikan dalam Dokumentasi Pembangun Apple mengenai UIApplicationDelegate. SDK mudah alih yang direka bentuk dengan baik harus meminimumkan kerja semasa permulaan aplikasi dan mengalihkan operasi rangkaian kepada pelaksanaan tak segerak. Pembangun harus mengesahkan tingkah laku permulaan sebenar dan mengukur prestasi permulaan sejuk dalam binaan sasaran mereka.

Fasa 3: Memintas Pautan Mendalam Asli melalui Pautan Universal dan Penapis Niat

Apabila apl telah dipasang dan pengguna mengetik pautan H5, OS mengejutkan aplikasi dan menyampaikan konteks penghalaan kepada SDK melalui titik kemasukan khusus platform:

  • Skema Tersuai Android vs. Pautan Apl Disahkan: Skema URL tersuai (scheme://) menghala melalui BROWSABLE <intent-filter> asas. Menyokong Pautan Apl Android yang disahkan memerlukan <intent-filter android:autoVerify="true"> yang mengisytiharkan kedua-dua skema http dan https di samping sasaran android:host, disokong oleh fail Digital Asset Links /.well-known/assetlinks.json yang mengandungi nama pakej apl dan cap jari sijil pengesandaran SHA-256.
  • Penghalaan AppDelegate and UISceneDelegate iOS: Pautan Universal menyampaikan NSUserActivity kepada AppDelegate dalam apl kitaran hayat tradisional, atau—untuk apl iOS 13+ yang menerima pakai kitaran hayat berasaskan adegan melalui UISceneDelegate—kepada scene(_:willConnectTo:options:) pada permulaan sejuk dan scene(_:continue:) pada penyambungan semula suam.

Fasa 4: Pemulihan Parameter Tak Segerak dan Baris Gilir Telemetri Peristiwa

Pada pelancaran pertama—atau apabila pencapaian penukaran perniagaan berlaku—aplikasi hos memanggil kaedah tak segerak SDK untuk mendapatkan semula parameter pemasangan terpelihara (data dan channelCode) dan melaporkan peristiwa penukaran hiliran (seperti pendaftaran akaun atau titik kesan tersuai).

Melaksanakan Cangkuk Kitar Hayat SDK Asli pada Android dan iOS

Mengkonfigurasi Pengenal Aplikasi dan Mengesahkan Keluaran SDK

Corak integrasi ilustrasi di bawah mengikut dokumentasi integrasi awam OpoInstall untuk menunjukkan cara projek Android dan iOS asli memasang cangkuk kitaran hayat yang diterangkan di atas. Oleh kerana pusat muat turun mengedarkan arkib SDK yang dikemas kini (kini v2.1.0, dikeluarkan 2026-09-20) manakala contoh dokumentasi mungkin merujuk koordinat minor yang lebih awal, pasukan kejuruteraan mesti memuat turun pakej SDK v2.1.0 sasaran, mengesahkan semua laluan import dan tandatangan kaedah terhadap kepala pustaka yang dibungkus, dan menjalankan pengesahan binaan bersih dalam Android Studio and Xcode sebelum pengeluaran. Rujuk kepada dokumentasi teknikal OpoInstall untuk arahan integrasi khusus keluaran.

Corak Permulaan SDK Android dan Pengambilan Parameter

Dalam AndroidManifest.xml, isytiharkan kebenaran rangkaian, AppKey penyewa, dan blok <intent-filter> berasingan untuk pengaktifan skema URL tersuai dan Pautan Apl Android disahkan (mengisytiharkan kedua-dua skema http dan https mengikut keperluan pengesahan Pautan Apl Android, and menggantikan links.example.com dengan domain disahkan anda):

<!-- File: app/src/main/AndroidManifest.xml (Illustrative Integration Pattern) -->
<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. Custom URL Scheme wakeup filter -->
            <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. Verified Android App Links filter (requires /.well-known/assetlinks.json with SHA-256 cert fingerprint) -->
            <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>
// File: 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);
    }
}
// File: app/src/main/java/com/example/app/MainActivity.java
// Note: Verify exact package imports and callback signatures against your downloaded SDK v2.1.0 archive.
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);

        // Process wakeup intent if launched via custom scheme or verified App Link
        getWakeUpData(getIntent());

        // Retrieve deferred installation parameters when needed by onboarding logic
        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);
            }
        });
    }
}

Corak Pendaftaran Delegasi SDK iOS dan Pengaktifan Semula SceneDelegate

Pada iOS, pamerkan #import "OpoInstallSDK.h" dalam Pengepala Penyelat Objective-C anda, konfigurasikan com.opoinstall.APP_KEY dalam Info.plist, dan laksanakan OpoInstallDelegate. Gunakan kaedah pengendalian URL AppDelegate untuk aplikasi yang tidak menerima pakai pengurusan kitaran hayat berasaskan adegan; untuk aplikasi berasaskan adegan, proses Pautan Universal permulaan sejuk dan sambung semula suam serta skema URL melalui kaedah SceneDelegate yang sepadan:

// File: AppDelegate.swift & SceneDelegate.swift (Illustrative Integration Pattern)
// Note: Verify exact Objective-C bridging headers and method signatures against your downloaded iOS SDK v2.1.0 archive.
import UIKit

@main
class AppDelegate: UIResponder, UIApplicationDelegate, OpoInstallDelegate {

    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        OpoInstallSDK.initWith(self)
        return true
    }

    // For apps that do NOT adopt UISceneDelegate lifecycle management:
    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("Wakeup data: \(String(describing: appData?.data)), channelCode: \(String(describing: appData?.channelCode))")
    }

    func fetchInstallParameters() {
        OpoInstallSDK.defaultManager()?.getInstallParmsCompleted({ (appData: OpoinstallData?) in
            print("Install data: \(String(describing: appData?.data)), channelCode: \(String(describing: appData?.channelCode))")
        })
    }
}

// For iOS 13+ apps that adopt UISceneDelegate lifecycle management:
@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)
        }
    }
}

Bilakah Pasukan Kejuruteraan Harus Menyepadukan SDK Mudah Alih Pihak Ketiga

Senario Sesuai untuk Menyepadukan SDK Mudah Alih Khusus

Menyepadukan SDK atribusi dan pautan mendalam mudah alih yang berdedikasi adalah wajar di bawah syarat berikut:

  • Aliran Rujukan dan Onboarding Tanpa Kod: Aplikasi yang menjalankan program rujukan atau jemputan bilik berbilang pemain di mana parameter (?ref=userA atau room_id=402) mesti dipulihkan selepas pemasangan gedung tanpa kemasukan kod manual.
  • Kempen H5 dan Kod QR Berbilang Saluran: Pasukan pemasaran yang mengedarkan pautan merentas rangkaian sosial, kod QR luar talian, and pakej saluran Android yang memerlukan penjejakan bersatu bagi lawatan, klik, pemasangan, and pendaftaran.
  • Pelancaran Web-ke-Apl Satu Klik: Produk yang menghalau pengguna apl sedia ada secara terus daripada pelayar mudah alih ke paparan dalam apl tertentu melalui Pautan Universal dan Pautan Apl sambil membimbing pengguna yang tidak memasang ke gedung aplikasi yang sesuai.

Senario Di Mana API REST Terus Adalah Cukup

Sebaliknya, SDK atribusi sebelah klien tidak diperlukan apabila aliran kerja tidak merentasi sandbox mudah alih asli:

  • Transaksi Sebelah Pelayan Disahkan: Apabila pengguna yang telah disahkan memperbaharui langganan atau mencetuskan webhook pengebilan sebelah pelayan, log penukaran tersebut melalui API REST Pelayan-ke-Pelayan (S2S) langsung mengelakkan kemas kini pergantungan klien.
    • Aplikasi Web Pelayar Sahaja: Aplikasi Web Progresif (PWA) dan tapak web mudah alih yang tidak mengedarkan binari asli melalui App Store atau Google Play boleh menjejak rujukan menggunakan kuki web pihak pertama standard and parameter pertanyaan URL.

Tanggapan Salah Umum Kejuruteraan Mengenai SDK Mudah Alih

  • Tanggapan Salah 1: Menyepadukan SDK Mudah Alih Menyekat Permulaan Apl Sejuk Secara Automatik: SDK mudah alih yang direka bentuk dengan baik meminimumkan kerja semasa Application.onCreate() atau didFinishLaunchingWithOptions: dan mengalihkan operasi rangkaian kepada pelaksanaan tak segerak, walaupun pembangun harus sentiasa memprofilkan latensi permulaan sejuk dalam binaan sasaran mereka.
  • Tanggapan Salah 2: Pakej Saluran Android Mengutamakan ID Saluran Pautan H5: Apabila apl Android menggunakan kedua-dua APK saluran yang dieksport dan pautan saluran H5, SDK OpoInstall membenarkan parameter tersuai and ID saluran diambil bersama; mengikut dokumentasi produk OpoInstall, jika pemasangan berasal daripada pautan saluran H5 dengan channelCode yang berbeza, ID pautan saluran H5 mengambil keutamaan berbanding ID pakej saluran dalam laporan statistik.

Soalan Lazim (FAQ)

Apakah itu SDK dan bagaimana ia berfungsi dalam apl mudah alih?
Kit Pembangunan Perisian (SDK) ialah pakej bersepadu pustaka, API tempatan, dokumentasi, and kod sampel yang dibina untuk platform tertentu. Sebaik sahaja dipautkan ke dalam apl Android atau iOS, ia berjalan di dalam proses asli aplikasi untuk berinteraksi dengan cangkuk kitaran hayat sistem pengendalian, mengurus keadaan tempatan, and berkomunikasi secara tak segerak dengan pelayan belakang jauh.
Apakah perbezaan utama antara SDK dan API dalam pembangunan mudah alih?
API ialah spesifikasi antara muka yang mentakrifkan cara komponen perisian bertukar data, manakala SDK ialah kit alatan lengkap yang membungkus pustaka boleh laku, pengendali keadaan tempatan, dan satu atau lebih API ke dalam pakej siap disepadukan untuk platform sasaran.
Mengapakah SDK mudah alih digunakan untuk pautan mendalam tertunda dan atribusi pemasangan?
Oleh kerana sistem pengendalian mudah alih mengasingkan apl asli di dalam sandbox yang ketat, apl yang baru dipasang tidak dapat membaca kuki pelayar daripada halaman web yang mendorong muat turun. Integrasi klien asli mengambil bahagian dalam kitaran hayat pelancaran pertama apl untuk menanyakan perujuk pasang platform atau pelayan atribusi dan memulihkan konteks kempen pra-pemasangan.

Ringkasan dan Rangka Kerja Keputusan Seni Bina

Memahami apakah itu SDK dan bagaimana ia berfungsi di dalam sandbox sistem pengendalian mudah alih membolehkan pasukan kejuruteraan merancang pemerolehan pengguna yang boleh dipercayai and seni bina pautan mendalam. Walaupun API web tanpa keadaan pengendali komunikasi pelayan jauh, integrasi sebelah klien asli diperlukan apabila aplikasi perlu mengambil bahagian dalam peristiwa kitaran hayat asli atau mendapatkan semula isyarat pemasangan khusus platform, and SDK mudah alih membungkus keupayaan ini ke dalam lapisan integrasi boleh guna semula.

Apabila memutuskan cara menstrukturkan saluran paip atribusi anda, gunakan garis panduan kejuruteraan ini:

  • Laksanakan SDK Mudah Alih Asli: Apabila perjalanan pengguna beralih daripada halaman mendarat H5, perkongsian sosial, atau kod QR melalui App Store atau Google Play dan memerlukan pemulihan parameter automatik atau penghalaan Pautan Universal / Pautan Apl satu klik.

  • Gunakan API HTTP Pelayan-ke-Pelayan: Apabila mengeksport statistik saluran agregat ke dalam gudang data dalaman, atau apabila merekodkan peristiwa bahagian belakang yang tidak bergantung pada konteks pelancaran sebelah klien.

  • Sahkan Kompilasi Binari dan Pematuhan Privasi Platform: Sentiasa uji kompil arkib SDK sasaran (seperti v2.1.0) dalam projek yang bersih dan sahkan dengan vendor bahawa sebarang mekanisme pemadanan iOS mengelakkan cap jari peranti terlarang sebelum keluaran pengeluaran.

Pasukan kejuruteraan yang menilai infrastruktur atribusi boleh mendaftarkan kunci aplikasi pada konsol pembangun OpoInstall untuk menguji pemulihan parameter dan penghalaan pautan mendalam dalam persekitaran pementasan.

Bahan Berkaitan

Share this article