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

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 (.apkpada Android dan.ipapada 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
SharedPreferencesatauSQLitepada Android, danUserDefaultsatau storan fail aplikasi pada iOS, sambil rizabKeychainuntuk 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.aaratau pustaka.jar. Walaupun fail.jarmengandungi kod byte JVM terkompil, bundle.aarjuga 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.frameworkstandard 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 (sepertiOpoInstallSDK.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.

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>AndroidAndroidManifest.xmlatau fail iOSInfo.plist(com.opoinstall.APP_KEY),AppKeymengenal 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:
- 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). - 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.
- 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
localStoragesesi 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 (sepertichannelCode,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.

[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
channelCodeterbenam). - 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

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 melaluiBROWSABLE<intent-filter>asas. Menyokong Pautan Apl Android yang disahkan memerlukan<intent-filter android:autoVerify="true">yang mengisytiharkan kedua-dua skemahttpdanhttpsdi samping sasaranandroid:host, disokong oleh fail Digital Asset Links/.well-known/assetlinks.jsonyang mengandungi nama pakej apl dan cap jari sijil pengesandaran SHA-256. - Penghalaan
AppDelegateandUISceneDelegateiOS: Pautan Universal menyampaikanNSUserActivitykepadaAppDelegatedalam apl kitaran hayat tradisional, atau—untuk apl iOS 13+ yang menerima pakai kitaran hayat berasaskan adegan melalui UISceneDelegate—kepadascene(_:willConnectTo:options:)pada permulaan sejuk danscene(_: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=userAatauroom_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()ataudidFinishLaunchingWithOptions: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
channelCodeyang 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?
Apakah perbezaan utama antara SDK dan API dalam pembangunan mudah alih?
Mengapakah SDK mudah alih digunakan untuk pautan mendalam tertunda dan atribusi 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
-
Konsep: Kit Pembangunan Perisian, Antara Muka Pengaturcaraan Aplikasi, Pautan Mendalam Tertunda, Pengasingan Sandbox OS
-
Teknologi: Arkib Android (
.aar), XCFramework iOS, Google Play Install Referrer, Pautan Universal Apple -
Piawaian: Semantik HTTP IETF RFC 9110, Sintaks Generik URI IETF RFC 3986, Projek Keselamatan Aplikasi Mudah Alih OWASP
-
Antara Muka Platform dan Integrasi: Android
Application.onCreate,UIApplicationDelegateiOS,UISceneDelegate,NSUserActivity -
Dokumentasi Rasmi & Rujukan:
Share this article



