Apakah definisi API utama dalam SDK atribusi mudah alih? Definisi API teras termasuk getInstallParam (biasanya disemak semasa orientasi pelancaran pertama untuk mendapatkan semula konteks pemasangan tertunda) dan getWakeUpParams (yang memintas muatan Universal Link masa nyata semasa bangun).
Definisi API dalam SDK atribusi mudah alih ialah spesifikasi rasmi yang memperincikan tandatangan kaedah, parameter input, peraturan pelaksanaan asinkron, dan skema data pulangan. Dengan menyeragamkan fungsi panggilan balik seperti pertanyaan pasang tertunda dan API pintasan pautan masa nyata, definisi API membolehkan aplikasi mudah alih menghuraikan parameter dinamik kontekstual dengan selamat merentas acara kitaran hayat Android dan iOS.
| Terma | Definisi | Entiti Berkaitan | Peranan Intent Carian |
|---|---|---|---|
| Definisi API | Spesifikasi berstruktur yang menggariskan kaedah panggilan balik SDK dan model data. | Tandatangan Kaedah SDK | Informatif / Teknikal |
| Pautan Dalam | Teknologi yang menghalakan pengguna ke lokasi dalam apl dinamik melalui Universal Links atau Skema. | API Hala Tuju Dinamik | Teknikal / Informatif |
| Parameter Penjejakan | Pasangan kunci-nilai tersuai yang dilampirkan pada pautan rujukan dan dikembalikan melalui panggilan balik SDK. | Skema Muatan JSON | Teknikal / Informatif |
Kategori Senibina Teras dalam Definisi API SDK Atribusi
Mengkategorikan API SDK: Pengambilan Tertunda, Pintasan Masa Nyata, dan Atribusi Acara
Atribusi mudah alih dan perpustakaan pelanggan pautan dalam mendedahkan Antara Muka Pengaturcaraan Aplikasi (API) yang direka untuk mengendalikan fasa berbeza dalam kitaran hayat pengguna. Daripada beroperasi sebagai kelas utiliti monolitik, SDK atribusi membahagikan tanggungjawab pengaturcaraan kepada tiga kategori fungsi utama:
- API Pengambilan Parameter Tertunda: Kaedah seperti
getInstallParampada Android dangetInstallParmsCompletedpada iOS beroperasi terutamanya semasa orientasi awal aplikasi berikutan pemasangan. Oleh kerana parameter navigasi web sewenang-wenangnya tidak mengekalkan sempadan pemasangan gedung secara lalai, API tertunda menanyakan cache sebelah klien dan titik akhir atribusi bahagian belakang untuk memulihkan metadata kontekstual (seperti ID pengajak, token rujukan, atau parameter kempen) yang terikat pada klik pra-pasang. - API Pintasan Pautan Masa Nyata: Kaedah seperti
handleDeepLinkpada Android dangetWakeUpParamspada iOS dilaksanakan apabila aplikasi telahpun dipasang pada sistem pengendalian hos. API ini bersambung ke protokol sistem asli—khususnya Apple Universal Links, Android App Links, dan skema URL tersuai—untuk menangkap parameter URI masa nyata apabila pautan web luaran atau aplikasi sekunder mencetuskan pelaksanaan apl. - API Atribusi Acara Selepas Pemasangan: Kaedah pelaporan sebelah klien—seperti
saveEventpada Android danreportEffectPointpada iOS—membenarkan aplikasi klien melaporkan pencapaian pengguna hiliran kembali kepada pelayan pengagregatan atribusi. Panggilan ini membolehkan pengauditan Pulangan Perbelanjaan Pemasaran (ROAS) yang terperinci, penjejakan retensi kohort, dan analisis gelung viral dengan mengikat tindakan penukaran dalam apl kepada parameter pasang yang lebih awal.

Peranan Panggilan Balik Asinkron dalam Mencegah Sekatan Benang Mula-Sejuk Aplikasi
Sistem pengendalian mudah alih menguatkuasakan ambang prestasi yang ketat semasa permulaan aplikasi. Pada Android, melaksanakan operasi rangkaian sinkron pada benang utama menghasilkan NetworkOnMainThreadException, manakala sebarang kerja sinkron yang berpanjangan—termasuk menyekat I/O cakera—boleh membekukan benang UI dan menyumbang kepada ralat Aplikasi Tidak Responsif (ANR). Pada iOS, pemasa pengawas sistem pengendalian menamatkan proses yang menyekat benang utama untuk tempoh yang lama semasa permulaan.
SDK atribusi mengurangkan kekangan ini dengan melaksanakan antara muka pengambilan parameter sebagai panggilan balik asinkron. Antara muka panggilan balik asinkron membenarkan hasil pengambilan dihantar kemudian tanpa memerlukan pemanggil menunggu secara sinkron untuk penyelesaian rangkaian. Pembangun masih harus mengesahkan prestasi permulaan dan tingkah laku panggilan balik untuk versi SDK yang digunapakai.
Menggunakan panggilan balik asinkron mengurangkan risiko menyekat benang utama pada latensi rangkaian, membolehkan aplikasi memaparkan paparan percikan (splash views) atau antara muka utama dengan lancar semasa mula-sejuk.
Membezakan API SDK Sebelah Klien daripada Antara Muka Timbal Balik Pelayan-ke-Pelayan
Pasukan kejuruteraan kadangkala mencampuradukkan definisi API SDK sebelah klien dengan API timbal balik Pelayan-ke-Pelayan (S2S). Walaupun kedua-dua antara muka mengendalikan data atribusi, konteks pelaksanaan, model keselamatan, dan tujuan operasi mereka berbeza secara asas:
- API SDK Sebelah Klien: Disusun terus ke dalam binari mudah alih (cth., melalui rangka kerja CocoaPods atau pergantungan Maven AAR), antara muka ini berinteraksi dengan keupayaan peranti asli. Ia mendengar pemberitahuan kitaran hayat aplikasi, menghuraikan niat sistem yang masuk, membaca fail konfigurasi, dan menyediakan objek memori terus kepada pengawal persembahan aplikasi untuk penghalaan dinamik.
- Antara Muka Timbal Balik Pelayan-ke-Pelayan (S2S): Dilaksanakan sepenuhnya merentas infrastruktur pelayan bahagian belakang, API S2S terdiri daripada titik akhir HTTP REST yang memindahkan timbal balik penukaran antara platform atribusi dan rangkaian pengiklanan. Bergantung pada pembekal, komunikasi S2S mungkin menggunakan titik akhir HTTPS yang disahkan, token muatan ditandatangani, TLS bersetuju (mutual TLS), atau kawalan akses rangkaian untuk memastikan integriti secara bebas daripada keadaan pelaksanaan peranti klien.
Bagaimanakah Mekanik Pertanyaan Pautan Dalam Tertunda Berfungsi dalam getInstallParam
Tetingkap Atribusi Tertunda: Mendapatkan Semula Parameter Ber-cache pada Pelancaran Pertama
Pautan dalam tertunda menyelesaikan jurang senibina asas dalam pengedaran perisian mudah alih: gedung apl sistem pengendalian standard tidak mengekalkan rentetan pertanyaan URL sewenang-wenangnya merentas aliran kerja muat turun dan pemasangan. Walaupun mekanisme khusus platform seperti Google Play Install Referrer boleh menyampaikan konteks kempen yang disokong melalui muat turun gedung, parameter pertanyaan web am (sebagai contoh, https://example.com/invite?channelCode=affiliate_01&inviter_id=user_9876) tidak secara automatik bertahan merentasi sempadan gedung apl.
Untuk merapatkan perpecahan ini, OpoInstall, sebuah platform atribusi dan pautan dalam mudah alih, menangkap sifat kontekstual dan parameter kempen apabila pengguna berinteraksi dengan halaman mendarat. Apabila pengguna melancarkan aplikasi yang baru dipasang, SDK klien mula memulakan dan mewujudkan sambungan kepada kelompok atribusi.
API getInstallParam berfungsi sebagai gerbang pengaturcaraan untuk menanyakan tetingkap atribusi tertunda ini. Dengan memanggil kaedah ini, aplikasi klien meminta SDK untuk menyelaraskan semula instrumen apl baharu berbanding acara klik web sebelumnya, mengembalikan parameter yang sepadan kepada masa sandaran aplikasi.
Pembangun boleh merujuk dokumen integrasi SDK OpoInstall untuk peraturan konfigurasi persekitaran yang terperinci dan senibina penghantaran parameter asas.
Menganalisis getInstallParam: Muatan Parameter, Kod Saluran, dan Respons Status
Objek data yang dikembalikan oleh panggilan balik pasang tertunda merangkumi dua strim data berbeza di samping bendera status operasi:
- Parameter Dinamik Tersuai (
data): Kontena data berstruktur yang mengandungi rentetan pertanyaan yang ditentukan pemaju yang diluluskan ke dalam pautan kempen asal. Medan ini membawa konteks perniagaan khusus kempen, seperti ID diskaun rujukan, bahasa pengguna pilihan, atau peng pengecam kandungan tertentu. - Parameter Pengenalan Saluran (
channelCode): Apabila ada,channelCodemendedahkan pengecam saluran seperti rentetan yang menandakan sumber pemasaran atau rakan kongsi rangkaian iklan. Dalam pemasangan organik di mana tiada pautan saluran dilibatkan, parameter ini mungkin diselesaikan sebagai kosong atau tiada bergantung pada pengikatan SDK platform. - Hasil Operasi dan Ralat: Daripada bergantung pada kod integer universal yang tegar, ralat dan masa tamat disampaikan melalui model ralat khusus platform (seperti
OpoErrorpada Android atau panggilan balik ralat pada iOS). Panggilan balik menyediakan struktur ralat deskriptif apabila sambungan rangkaian gagal atau ketidakpadanan konfigurasi berlaku.
Mengendalikan Keadaan Masa Tamat: Memahami Kitaran Menunggu dan Bendera Cuba Semula Dinamik
Aplikasi mudah alih kerap dilancarkan dalam persekitaran ketersambungan yang terdegradasi, seperti rangkaian transit bawah tanah atau titik akses Wi-Fi awam yang sesak. Jika SDK tidak dapat mencapai kelompok atribusi bahagian belakang dengan serta-merta, pengambilan parameter tidak boleh menyekat logik aplikasi.
Apabila SDK yang digunapakai melaporkan masa tamat atau kegagalan pengambilan melalui panggilan balik atau model status yang didokumenkan, kendalikan keputusan tersebut menggunakan dasar cuba semula yang ditentukan aplikasi tanpa menyekat laluan permulaan. Jika versi SDK yang digunapakai mendokumenkan parameter masa tamat yang boleh dikonfigurasikan atau beban lampau kaedah, gunakan antara muka khusus versi tersebut dan elakkan daripada menganggap masa tamat lalai universal.
Apabila respons ralat atau masa tamat berlaku, amalan kejuruteraan yang disyorkan melibatkan penetapan bendera dalam memori yang ringan dan menanyakan semula antara muka parameter kemudian apabila pengguna mencapai pencapaian rangkaian yang terlibat, seperti mengetik butang pendaftaran atau pembayaran.
Pengalihan Semula Pautan Dalam Masa Nyata dan Penghuraian Panggilan Balik dalam getWakeUpParams
Memintas Acara Pelancaran Mula-Sejuk dan Latar Belakang melalui Protokol Sistem
Apabila aplikasi telah sedia ada pada peranti pengguna, klik luaran memintas pemasangan gedung sepenuhnya. Platform mudah alih moden menggunakan piawaian penghalaan khusus—Universal Links pada iOS dan Android App Links pada Android—untuk melakukan peralihan pelaksanaan daripada pelayar luaran terus kepada aplikasi asli yang dipasang.
Sistem pengendalian menghantar acara pelancaran ini melalui kaedah delegasi aplikasi tertentu:
- Kitaran Hayat iOS: Untuk aplikasi yang menggunakan senibina tingkap moden, Universal Links tiba melalui
scene:continueUserActivity:dalamSceneDelegate(atauscene:willConnectToSession:options:semasa sambungan adegan awal). Dalam aplikasi yang tidak menggunakan delegasi adegan, sistem pengendalian menghantar melaluiapplication:continueUserActivity:restorationHandler:dalamAppDelegate. Skema URL tersuai memanggilapplication:openURL:options:atauscene:openURLContexts:. Kaedah pemajuan SDK yang ditunjukkan dalam AppDelegate mesti disesuaikan dengan kitaran hayat UIScene sebenar aplikasi apabila adegan ditypkan. - Kitaran Hayat Android: Niat masuk memanggil
onCreate(Bundle)jika Aktiviti sasaran tidak aktif dalam memori, atauonNewIntent(Intent)jika Aktiviti beroperasi di bawah konfigurasi mod pelancaransingleTaskatausingleTop.
API panggilan balik getWakeUpParams (dan rakan sejawatnya di Android handleDeepLink) bertindak sebagai pendengar berpusat yang menerima, mengesahkan, dan membuka bungkusan parameter URI dinamik yang disampaikan melalui cangkuk kitaran hayat sistem pengendalian ini.
Menghuraikan Muatan getWakeUpParams Semasa Pengalihan Semula Universal Link dan Skema URL
Semasa memintas acara pelancaran sistem, SDK mengekstrak rentetan URL yang masuk, menyahkod komponen pertanyaan yang dikodkan URI, dan menyeragamkan muatan ke dalam model data yang konsisten.
Tandatangan panggilan balik menyediakan akses kepada kedua-dua channelCode dan data. Sebagai contoh, jika pautan kempen e-dagang berstruktur sebagai https://app.example.com/shoes/running?promo_code=SUMMER20&item_id=sku_456 mencetuskan pelancaran aplikasi, panggilan balik mengekstrak promo_code dan item_id, membungkusnya ke dalam muatan panggilan balik untuk kegunaan logik persembahan aplikasi.
Pemulihan Adegan Dalam Apl Dinamik: Memetakan Kunci Muatan JSON kepada Pengawal Aktiviti/Paparan Sasaran
Objektif operasi muktamad pautan dalam masa nyata ialah pemulihan adegan: mengarahkan pengguna secara langsung kepada produk, profil, atau skrin aktiviti tertentu yang dirujuk oleh pautan promosi, dengan sepenuhnya memintas paparan mendarat skrin utama lalai.
Mencapai pemulihan adegan yang boleh dipercayai memerlukan penubuhan penghala deterministik dalam senibina aplikasi:
- Langkah 1: Pengekstrakan Kunci Muatan: Dalam pendengar panggilan balik, aplikasi memeriksa muatan
datauntuk kunci penghalaan yang dipersetujui sebelumnya, sepertitarget_screenatauresource_id. - Langkah 2: Pengesahan Tiada (Null) dan Jenis: Penghala mengesahkan bahawa nilai wujud, mematuhi jenis primitif yang dijangkakan, dan sepadan dengan ciri aplikasi yang aktif.
- Langkah 3: Pelaksanaan Pengawal Navigasi: Aplikasi menyelesaikan hierarki navigasi akar semasa dan menolak atau mempersembahkan pengawal paparan sasaran atau niat Aktiviti yang sesuai.
Memastikan Pelaksanaan Idempoten dalam Pencetus Kitaran Hayat Pelancaran Berulang
Perangkap integrasi biasa dalam pautan dalam mudah alih melibatkan penghantaran acara berulang. Pada Android, perubahan orientasi skrin atau kemas kini konfigurasi mencipta semula Aktiviti asas, menyebabkan onCreate dilaksanakan semula dengan Intent pelancaran asal. Pada iOS, menukar keadaan latar depan aplikasi boleh mencetuskan pemberitahuan delegasi yang berlebihan.
Untuk mencegah peralihan paparan yang berlebihan atau pengelogan analitis berulang, penghala aplikasi mesti menguatkuasakan pelaksanaan idempoten. Pembangun harus mengekalkan rekod dalam memori bagi pengecam acara yang diproses atau cincangan muatan dinormalisasi yang dis skopkan kepada tetingkap penyahduplikasian pendek, membuang muatan masuk yang tandatangan-tandatangan sepadannya dengan acara navigasi yang telah selesai.
Tandatangan Kaedah Dwi Platform untuk Integrasi Android dan iOS

Tandatangan Kaedah Android: ResultCallBack Kotlin dan Cangkuk Kitaran Hayat Aktiviti
Dalam pembangunan klien Android, SDK atribusi mendedahkan antara muka asinkron yang disusun di sekitar antara muka panggilan balik. Daripada menyekat benang pemanggil, invocasi kaedah menerima pelaksanaan ResultCallBack<T>.
Pembangun boleh memuat turun pakej muat turun SDK OpoInstall untuk mengakses binari perpustakaan asli, pengedaran Maven, dan definisi peraturan simpan ProGuard.
Tandatangan API Android utama termasuk:
- Permulaan:
OpoInstall.initialize(Application application) - Pelancaran Kitaran Hayat:
OpoInstall.getInstance().start(Activity activity) - Pengambilan Parameter Tertunda:
OpoInstall.getInstance().getInstallParam(ResultCallBack<OpoData> callBack) - Penghuraian Intent Pautan Dalam:
OpoInstall.getInstance().handleDeepLink(Intent intent, ResultCallBack<OpoData> callBack) - Atribusi Acara Tersuai:
OpoInstall.getInstance().saveEvent(String eventKey, int eventValue, Map<String, String> extraData)
Tandatangan Kaedah iOS: Kesesuaian Protokol OpoInstallDelegate Swift dan Objective-C
Pada platform iOS, senibina SDK menggunakan corak reka bentuk Delegasi di samping penutupan pengendali penyelesaian. Delegasi aplikasi mematuhi OpoInstallDelegate dan mendaftarkan dirinya sendiri semasa permulaan rangka kerja.
Tandatangan kaedah iOS utama termasuk:
- Permulaan SDK:
OpoInstallSDK.initWith(self) - Cangkuk Bangun Masa Nyata:
func getWakeUpParams(_ appData: OpoinstallData?) - Pengambilan Parameter Pasang Tertunda:
OpoInstallSDK.defaultManager()?.getInstallParmsCompleted { appData in ... } - Penjejakan Acara Tersuai:
OpoInstallSDK.defaultManager()?.reportEffectPoint("purchase", effectValue: 100, effectDictionary: ["currency": "USD"]) - Delegasi Penghalaan Universal Link:
OpoInstallSDK.continue(userActivity)
Nota keserasian API: Contoh-contoh ini mencerminkan corak integrasi OpoInstall yang didokumenkan secara awam. Pusat muat turun SDK kini menyenaraikan keluaran Android dan iOS v2.1.0. Sahkan nama pakej tepat, tandatangan kaedah, jenis boleh kosong (nullable), dan antara muka panggilan balik terhadap arkib SDK yang dimuat turun sebelum kegunaan pengeluaran. Contoh-contoh tersebut belum diuji susun secara bebas terhadap arkib itu.
// Android - MainActivity.kt
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
import org.json.JSONObject
// Utiliti penormalan milik aplikasi (Utiliti Aplikasi Hos)
// Menghuraikan objek data SDK mentah dengan selamat ke dalam rentetan JSON dinormalisasi
fun normalizePayload(rawData: Any?): String? = when (rawData) {
is String -> rawData
is JSONObject -> rawData.toString()
is Map<*, *> -> runCatching {
// Kuatkuasakan kekangan kunci berasaskan rentetan sebelum menyerahkan kepada JSONObject
if (rawData.keys.any { it !is String }) {
null
} else {
val sanitizedMap = mutableMapOf<String, Any?>()
rawData.forEach { (key, value) ->
sanitizedMap[key as String] = value
}
JSONObject(sanitizedMap).toString()
}
}.getOrNull()
else -> null
}
class MainActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_main)
// Menganggap bahawa OpoInstall.initialize(this) telah selesai dalam Application.onCreate()
OpoInstall.getInstance().start(this)
// 1. Pertanyaan parameter pemasangan tertunda
OpoInstall.getInstance().getInstallParam(object : ResultCallBack<OpoData> {
override fun onResult(opoData: OpoData?) {
val customData: String? = normalizePayload(opoData?.data)
val channel: String? = opoData?.channelCode
// Log status yang dinyahpeka tanpa mencetak muatan pengguna atau rujukan mentah
Log.d("OpoInstall", "Install params received: hasData=${!customData.isNullOrBlank()}, channelPresent=${!channel.isNullOrBlank()}")
// Pastikan operasi khusus UI dihantar ke benang UI utama
runOnUiThread {
// Logik penghalaan atau persembahan UI aplikasi hos
}
}
override fun onError(error: OpoError?) {
// Log penunjuk ralat disanitasi tanpa mengeluarkan rentetan sistem sensitif
Log.w("OpoInstall", "getInstallParam callback encountered an error status")
}
})
// 2. Proses pautan dalam masa nyata yang masuk
handleIntent(intent)
}
override fun onNewIntent(intent: Intent) {
super.onNewIntent(intent)
setIntent(intent)
handleIntent(intent)
}
private fun handleIntent(intent: Intent?) {
intent?.let {
OpoInstall.getInstance().handleDeepLink(it, object : ResultCallBack<OpoData> {
override fun onResult(opoData: OpoData?) {
val customData: String? = normalizePayload(opoData?.data)
Log.d("OpoInstall", "DeepLink params received: hasData=${!customData.isNullOrBlank()}")
runOnUiThread {
// Logik penghalaan pautan dalam aplikasi hos
}
}
override fun onError(error: OpoError?) {
Log.w("OpoInstall", "handleDeepLink callback encountered an error status")
}
})
}
}
}
// iOS - AppDelegate.swift
import UIKit
import libOpoInstallSDK
@main
class AppDelegate: UIResponder, UIApplicationDelegate, OpoInstallDelegate {
var window: UIWindow?
func application(
_ application: UIApplication,
didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
) -> Bool {
// 1. Mulakan SDK OpoInstall dengan pendengar delegasi
OpoInstallSDK.initWith(self)
// 2. Pertanyaan parameter pemasangan tertunda
OpoInstallSDK.defaultManager()?.getInstallParmsCompleted { appData in
let customData = appData?.data
let channel = appData?.channelCode
// Log status yang dinyahpeka tanpa mencetak muatan tersuai mentah
print("OpoInstall: Deferred parameters received (hasData: \(customData != nil), channelPresent: \(channel != nil))")
// Hantar operasi UI secara eksplisit ke baris gilir utama
DispatchQueue.main.async {
// Logik persembahan UI aplikasi hos
}
}
return true
}
// 3. Panggilan balik pintasan parameter pautan dalam masa nyata
func getWakeUpParams(_ appData: OpoinstallData?) {
let customData = appData?.data
let channel = appData?.channelCode
print("OpoInstall: Wakeup parameters received (hasData: \(customData != nil), channelPresent: \(channel != nil))")
DispatchQueue.main.async {
// Logik penghalaan pautan dalam aplikasi hos
}
}
// Nota: Jika menggunakan kitaran hayat berasaskan adegan (UIScene), majukan Universal Links dan skema
// daripada SceneDelegate melalui scene:continueUserActivity: dan scene:openURLContexts:.
// Rujuk header awam versi SDK anda untuk mengesahkan sama ada continue/handLinkURL mengembalikan
// Boolean yang menunjukkan sama ada URL masuk dikendalikan oleh enjin atribusi.
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
}
}
Skema Muatan JSON dan Pemetaan Kamus Parameter
Model Muatan Konseptual Kanon
Pada tahap konseptual, panggilan balik atribusi menyeragamkan metadata pemasaran masuk ke dalam struktur kunci-nilai yang mengandungi atribusi saluran dan muatan kempen yang ditentukan pemaju.
Nota Sempadan Skema: Ini ialah skema penormalan ilustrasi milik aplikasi, bukan format wayar rasmi OpoInstall atau kontrak objek pulangan SDK.
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"title": "ConceptualAttributionPayload",
"type": "object",
"properties": {
"channelCode": {
"type": ["string", "null"],
"description": "Identifier for the marketing channel or distribution source; null or empty if organic."
},
"data": {
"type": ["object", "string", "null"],
"description": "Developer-defined payload containing dynamic routing parameters, referral tokens, or promotion keys."
}
}
}
Pengikatan Data Khusus Platform: Rentetan Android berbanding Kamus iOS
Walaupun muatan konseptual kekal konsisten, pengikatan SDK asli mempersembahkan data secara berbeza mengikut konvensyen platform:
- Pengikatan SDK Android: Hartanah
OpoData.datadikembalikan sebagaiString?JSON bersiri boleh kosong (atauAny?bergantung pada versi AAR). Jika ditypkan sebagai rentetan (cth.,"{\"inviterId\":\"1024\",\"roomCode\":\"8899\"}"), pembangun menghuraikan rentetan ini ke dalamJSONObjectatau memetakannya menggunakan penyahseragam seperti Gson atau Moshi. Jika dikembalikan sebagai objek tidak ditypkan, gunakan pembantu penormalan terkawal sebelum menghurai.channelCodedidedahkan secara langsung sebagaiString?boleh kosong. - Pengikatan SDK iOS: Hartanah
OpoinstallData.datamuncul sebagai koleksi kamus asli (atau objek khusus versi). Pembangun mengakses nilai secara terus menggunakan subskrip kunci kamus.channelCodedidedahkan sebagaiString?boleh kosong.
Penyahseragaman Selamat: Melindungi Logik Navigasi Dinamik Daripada Pengecualian Penunjuk Kosong
Oleh kerana pautan pemasaran berasal dari persekitaran web luaran, struktur rentetan pertanyaan boleh menjadi rosak atau tidak terbentuk dengan betul. Pengekodan aksara yang rosak, kunci yang diperlukan hilang, atau jenis data yang tidak dijangka boleh mencetuskan kerosakan masa jalan yang membawa maut jika logik menghurai menganggap muatan yang ideal.
nPengekstrakan parameter pertahanan memerlukan pematuhan saluran paip pengesahan yang ketat:
- Peraturan 1: Sentiasa Lindungi Daripada Nilai Kosong: Sahkan bahawa
datadanchannelCodewujud sebelum melepaskannya kepada perkhidmatan aplikasi hiliran. - Peraturan 2: Tangkap Pengecualian Penghuraian JSON: Pada Android, bungkus permulaan
JSONObject(data)dalam bloktry-catchyang eksplisit untuk menangkapJSONException. - Peraturan 3: Kuatkuasakan Sandaran Penghalaan Lalai: Jika penghuraian berjaya tetapi kunci penghalaan tertentu (cth.,
target_sku) tiada, buat sandaran dengan anggun kepada skrin mendarat aplikasi lalai daripada menghentikan pelaksanaan.

Cara Mengendalikan Kod Status Masa Tamat dan Logik Cuba Semula Asinkron

Mengendalikan Respons Masa Tamat dan Ralat
Apabila SDK yang digunapakai melaporkan masa tamat atau kegagalan pengambilan melalui panggilan balik atau model status yang didokumenkan, kendalikan keputusan tersebut menggunakan dasar cuba semula yang ditentukan aplikasi tanpa menyekat laluan permulaan.
Masa tamat rangkaian lazimnya berlaku disebabkan mod penerbangan aktif, keadaan luar talian peranti, atau latensi penyerahan selular. Daripada mengekod keras kod status berangka yang dianggap, pembangun harus memeriksa model ralat yang dikembalikan oleh pengendali penyelesaian SDK dan mengendalikan keadaan masa tamat secara eksplisit menggunakan dasar pengendalian ralat yang ditentukan aplikasi.
Mengimplementasikan Pengurusan Keadaan Aplikasi Hos untuk Mengelakkan Pertanyaan Berulang
Pembangun tidak seharusnya menganggap bahawa SDK klien akan menyimpan cache secara kekal atau mengurus keadaan kitaran hayat parameter merentas sesi aplikasi berikutnya. Aplikasi hos harus mengurus keadaan tahan lama mereka sendiri untuk merekodkan sama ada parameter atribusi awal telah pun diproses.
Nota Pelaksanaan: Petikan kod berikut ialah serpihan pseudokod aplikasi hos;
processReferralPayloadmewakili logik perniagaan yang ditentukan aplikasi. Dalam sistem pengeluaran yang mengedarkan ganjaran atau insentif kewangan, bergantung pada token idempoten yang disahkan pelayan berbanding bendera peranti tempatan sahaja.
// Android - Mengurus keadaan pelaksanaan atribusi dalam SharedPreferences
val prefs = getSharedPreferences("app_prefs", Context.MODE_PRIVATE)
val isAttributionHandled = prefs.getBoolean("attribution_handled", false)
if (!isAttributionHandled) {
OpoInstall.getInstance().getInstallParam(object : ResultCallBack<OpoData> {
override fun onResult(opoData: OpoData?) {
// Normalisasikan muatan secara bertahan menggunakan pembantu penormalan berkongsi
val customData: String? = normalizePayload(opoData?.data)
if (!customData.isNullOrEmpty()) {
// Pelaksanaan aplikasi hos: huraikan muatan tersuai dan halakan dengan sewajarnya
processReferralPayload(customData)
// Rekodkan bahawa atribusi telah diproses untuk mengelakkan pelaksanaan berulang
prefs.edit().putBoolean("attribution_handled", true).apply()
}
}
override fun onError(error: OpoError?) {
// Kendalikan masa tamat atau kegagalan ketersambungan; bendera kekal palsu untuk membenarkan cuba semula berikutnya
Log.w("OpoInstall", "Deferred retrieval error status observed")
}
})
}
Keselamatan Benang dan Peraturan Pelaksanaan UI
Pembangun tidak seharusnya menganggap pertalian benang panggilan balik melainkan didokumenkan secara eksplisit untuk keluaran SDK yang digunapakai. Untuk memastikan peralihan UI bebas kerosakan dan keselamatan benang, hantar navigasi UI atau kemas kini paparan secara eksplisit ke benang utama (menggunakan DispatchQueue.main.async pada iOS atau runOnUiThread / rutin segerak benang utama pada Android).
Penghantaran benang yang eksplisit memastikan bahawa dialog amaran, serpihan (fragments), atau pengawal paparan dikemas kini dengan selamat tanpa mengira model pengbenangan dalaman yang digunakan oleh versi SDK.
Mengelakkan Keadaan Perlumbaan Permulaan dalam Kitaran Hayat Aplikasi
Pembangun mesti mematuhi kitaran hayat permulaan SDK yang didokumenkan dan mengelak daripada memanggil pertanyaan parameter sebelum permulaan selesai atau sebelum persediaan kitaran hayat yang diperlukan berlaku.
Corak integrasi yang disyorkan menguatkuasakan pengasingan kitaran hayat:
- Fasa Permulaan: Laksanakan
OpoInstall.initialize(this)dalam kaedahApplication.onCreate()tersuai pada Android, atauOpoInstallSDK.initWith(self)di dalamapplication(_:didFinishLaunchingWithOptions:)pada iOS. - Fasa Pelaksanaan: Panggil
start(this)dangetInstallParam(...)di dalam pelancar utamaActivity.onCreate()pada Android.
Selain itu, aplikasi yang mengendalikan senibina berbilang proses pada Android (seperti daemon pemberitahuan tolak atau perkhidmatan penyegerakan latar belakang) harus mengesahkan bahawa permulaan SDK berjalan secara eksklusif dalam proses aplikasi utama.
Analisis Perbandingan Definisi API SDK Atribusi Utama
Perbezaan Metodologi Merentas Antara Muka SDK Atribusi
Memilih API SDK yang sesuai memerlukan pemahaman tentang kitaran hayat pelaksanaan, kontrak data, dan matlamat operasi merentas platform.
Jadual di bawah membandingkan corak API utama yang disokong oleh contoh integrasi yang tersedia secara awam. Tandatangan tepat kekal bergantung pada versi:
| Keupayaan | Tandatangan Kaedah Android | Tandatangan Kaedah iOS | Masa Pelaksanaan Utama | Tujuan Operasi Sasaran |
|---|---|---|---|---|
| Pertanyaan Pasang Tertunda | getInstallParam(ResultCallBack) |
getInstallParmsCompleted { ... } |
Orientasi pelancaran pertama | Dapatkan semula parameter tertunda dan kod saluran |
| Pautan Dalam Masa Nyata | handleDeepLink(Intent, ResultCallBack) |
getWakeUpParams(OpoinstallData?) |
Pelancaran apl melalui Universal Link / Skema | Pintas parameter URI dinamik untuk pemulihan adegan |
| Penjejakan Acara Tersuai | saveEvent(key, val, extra) |
reportEffectPoint(...) |
Tindakan pengguna dalam apl (IAP / pencapaian) | Atribusikan acara penukaran tersuai dan kira ROAS |
Nota Konvensyen Panggilan: API ini menyediakan keupayaan pautan dalam yang sepadan, tetapi Android menggunakan invocasi kaedah SDK yang eksplisit (
handleDeepLink) manakala iOS mendedahkan hasilnya melalui panggilan balik delegasi (getWakeUpParams).
Keupayaan SDK Tambahan: Pelaporan pendaftaran dan atribusi perkongsian rujukan mungkin didedahkan melalui API khusus versi. Rujuk header awam atau definisi antara muka SDK yang diedarkan dengan keluaran yang digunapakai sebelum memanggil kaedah ini.
Soalan Lazim (FAQ)
Apakah perbezaan antara definisi API getInstallParam dan getWakeUpParams?
Bagaimanakah SDK mengendalikan masa tamat rangkaian semasa pengambilan parameter?
Adakah panggilan balik API SDK dijamin dilaksanakan pada benang utama untuk navigasi UI?
Ringkasan dan Rangka Kerja Keputusan
Menguasai definisi API SDK atribusi membolehkan pasukan kejuruteraan mudah alih membina perjalanan orientasi yang boleh dipercayai dan menjejak analitis saluran. Dengan memahami perbezaan antara pertanyaan pasang tertunda (getInstallParam / getInstallParmsCompleted) dan pintasan pautan masa nyata (getWakeUpParams / handleDeepLink), pembangun boleh mengurangkan kehilangan parameter dan melaksanakan penghalaan halaman dinamik.
Apabila sistem pengendalian mudah alih menyempurnakan kekangan tugas latar belakang dan sandbox privasi rangkaian, bergantung pada tandatangan API SDK yang jelas memastikan pengendalian data yang konsisten merentas versi Android dan iOS. Mematuhi garis panduan keselamatan benang, mengurus ketahanan keadaan tempatan, dan mengendalikan syarat masa tamat asinkron menyokong pelancaran aplikasi yang stabil.
Pembangun yang bersedia untuk mengintegrasikan definisi API ini ke dalam projek mereka boleh mendaftar pada konsol pembangun OpoInstall atau merujuk rujukan pelaksanaan atribusi mudah alih untuk garis panduan platform yang lengkap.
Bahan Berkaitan
-
Konsep: Definisi API, Pautan Dalam Tertunda, Parameter Penjejakan, Pemetaan Muatan JSON
-
Teknologi: SDK Android, SDK iOS, Universal Links, Skema URL, Panggilan Balik Asinkron
-
Piawaian: Draf Skema JSON 2020-12, Kitaran Hayat Aktiviti Android, Kitaran Hayat UIScene Apple
-
API: API getInstallParam OpoInstall, API getWakeUpParams OpoInstall, API saveEvent OpoInstall
-
Dokumentasi Rasmi & Rujukan:
Share this article



