Bagaimana Pembangun Membaca Definisi API untuk Panggilan Balik Pautan Dalam

opoinstall
2026-11-13
5 min read

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 getInstallParam pada Android dan getInstallParmsCompleted pada 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 handleDeepLink pada Android dan getWakeUpParams pada 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 saveEvent pada Android dan reportEffectPoint pada 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.

Pemasangan tertunda dan panggilan balik bangun masa nyata menggunakan laluan kitaran hayat mudah alih yang berbeza.

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, channelCode mendedahkan 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 OpoError pada 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: dalam SceneDelegate (atau scene:willConnectToSession:options: semasa sambungan adegan awal). Dalam aplikasi yang tidak menggunakan delegasi adegan, sistem pengendalian menghantar melalui application:continueUserActivity:restorationHandler: dalam AppDelegate. Skema URL tersuai memanggil application:openURL:options: atau scene: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, atau onNewIntent(Intent) jika Aktiviti beroperasi di bawah konfigurasi mod pelancaran singleTask atau singleTop.

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 data untuk kunci penghalaan yang dipersetujui sebelumnya, seperti target_screen atau resource_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

Kaedah panggilan balik Android dan delegasi iOS menerima acara pautan dalam asli secara berbeza.

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.data dikembalikan sebagai String? JSON bersiri boleh kosong (atau Any? bergantung pada versi AAR). Jika ditypkan sebagai rentetan (cth., "{\"inviterId\":\"1024\",\"roomCode\":\"8899\"}"), pembangun menghuraikan rentetan ini ke dalam JSONObject atau memetakannya menggunakan penyahseragam seperti Gson atau Moshi. Jika dikembalikan sebagai objek tidak ditypkan, gunakan pembantu penormalan terkawal sebelum menghurai. channelCode didedahkan secara langsung sebagai String? boleh kosong.
  • Pengikatan SDK iOS: Hartanah OpoinstallData.data muncul sebagai koleksi kamus asli (atau objek khusus versi). Pembangun mengakses nilai secara terus menggunakan subskrip kunci kamus. channelCode didedahkan sebagai String? 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.

n

Pengekstrakan parameter pertahanan memerlukan pematuhan saluran paip pengesahan yang ketat:

  • Peraturan 1: Sentiasa Lindungi Daripada Nilai Kosong: Sahkan bahawa data dan channelCode wujud sebelum melepaskannya kepada perkhidmatan aplikasi hiliran.
  • Peraturan 2: Tangkap Pengecualian Penghuraian JSON: Pada Android, bungkus permulaan JSONObject(data) dalam blok try-catch yang eksplisit untuk menangkap JSONException.
  • 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.

Parameter panggilan balik yang disahkan menghalakan pengguna ke skrin sasaran atau sandaran selamat.

Cara Mengendalikan Kod Status Masa Tamat dan Logik Cuba Semula Asinkron

Panggilan balik SDK selari dan pengawal masa tamat memastikan orientasi mudah alih sentiasa responsif.

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; processReferralPayload mewakili 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).

n

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 kaedah Application.onCreate() tersuai pada Android, atau OpoInstallSDK.initWith(self) di dalam application(_:didFinishLaunchingWithOptions:) pada iOS.
  • Fasa Pelaksanaan: Panggil start(this) dan getInstallParam(...) di dalam pelancar utama Activity.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?
`getInstallParam` (dan `getInstallParmsCompleted` pada iOS) ialah API pautan dalam tertunda asinkron yang direka untuk menanyakan parameter yang diluluskan apabila pengguna memasang dan membuka apl buat kali pertama. Sebaliknya, `getWakeUpParams` (dan `handleDeepLink` pada Android) ialah API pautan dalam masa nyata yang memintas acara pelancaran sistem (Universal Links atau Skema URL) apabila apl yang telah dipasang dilancarkan daripada pautan luaran.
Bagaimanakah SDK mengendalikan masa tamat rangkaian semasa pengambilan parameter?
Apabila pengambilan parameter tertunda dipanggil, SDK menanyakan cache klien dan titik akhir atribusi bahagian belakang. Jika SDK yang digunapakai melaporkan masa tamat atau kegagalan pengambilan melalui panggilan balik atau model status yang didokumenkan, kendalikan keputusan tersebut menggunakan dasar cuba semula terhad yang ditentukan aplikasi tanpa menyekat permulaan aplikasi.
Adakah panggilan balik API SDK dijamin dilaksanakan pada benang utama untuk navigasi 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 (cth., menggunakan `DispatchQueue.main.async` pada iOS atau `runOnUiThread` / peng dispatch Korutin pada Android).

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

Share this article