SDK ขับเคลื่อนการระบุแหล่งที่มาและการเติบโตของแอปมือถืออย่างไร

SDK คืออะไรและทำงานอย่างไร? Software Development Kit (SDK) คือชุดของไลบรารี API เครื่องมือ และเอกสารประกอบที่ออกแบบมาเพื่อช่วยให้นักพัฒนาสร้างหรือขยายขีดความสามารถของแอปพลิเคชันซอฟต์แวร์ ในการพัฒนาแอปพลิเคชันมือถือ SDK มักจะประกอบด้วยไลบรารีที่คอมไพล์แล้วซึ่งบูรณาการเข้ากับแอปพลิเคชันเนทีฟ เพื่อมอบฟังก์ชันการทำงานเฉพาะแพลตฟอร์ม เช่น การทำ Deep Linking และการระบุแหล่งที่มา (Attribution) เมื่อทีมวิศวกรรมมือถือประเมินว่าข้อมูลการได้มาซึ่งผู้ใช้งาน (User Acquisition) ไหลจากหน้าโปรโมชันบนเว็บไปยังแอปพลิเคชันที่ติดตั้งใหม่ได้อย่างไร พวกเขาจะต้องเผชิญกับขอบเขตพื้นฐานของระบบปฏิบัติการ: อินเทอร์เฟซเว็บระยะไกลไม่สามารถเข้าถึงวงจรการทำงานของแอปพลิเคชันเนทีฟหรือข้ามแซนด์บ็อกซ์ของ App Store ได้ด้วยตัวเอง OpoInstall ซึ่งเป็นแพลตฟอร์มการระบุแหล่งที่มาบนมือถือและการทำ Deep Linking มีไลบรารีฝั่งไคลเอนต์แบบเนทีฟและสคริปต์เว็บที่ประสานงานกันข้ามสภาพแวดล้อมที่แยกออกจากกันเหล่านี้ เพื่อกู้คืนพารามิเตอร์ของแคมเปญและนำทางผู้ใช้ไปยังหน้าจอภายในแอปที่ต้องการ

Software Development Kit (SDK) คือชุดรวมไลบรารี, อินเทอร์เฟซการเขียนโปรแกรมแอปพลิเคชัน (API), ไฟล์เฮดเดอร์, เอกสารสำหรับนักพัฒนา และโค้ดตัวอย่างที่จัดเตรียมไว้ล่วงหน้า ซึ่งออกแบบมาสำหรับระบบปฏิบัติการหรือเฟรมเวิร์กเฉพาะ ต่างจากเว็บ API ระยะไกลแบบสแตนด์อโลนที่กำหนดอินเทอร์เฟซการสื่อสารแบบไร้สถานะ (Stateless) ผ่าน HTTP โดย SDK มือถือจะทำงานโดยตรงภายในกระบวนการรันไทม์ของแอปพลิเคชันไคลเอนต์เพื่อจัดการสถานะภายในเครื่อง, คอลแบ็กวงจรการทำงานของระบบปฏิบัติการ และระบบส่งข้อมูลเครือข่ายแบบอะซิงโครนัส

SDK คืออะไรและแตกต่างจากเว็บ API มาตรฐานอย่างไร

ทำความเข้าใจคำศัพท์: เหตุใด SDK ทุกตัวจึงมี API แต่ API ไม่ใช่ SDK

ในวิศวกรรมซอฟต์แวร์ นักพัฒนาที่เพิ่งเริ่มใช้งานโครงสร้างพื้นฐานการเติบโตของมือถือมักจะสับสนระหว่างอินเทอร์เฟซการเขียนโปรแกรมแอปพลิเคชัน (API) กับชุดพัฒนาซอฟต์แวร์ (SDK) แม้ว่าทั้งสองแนวคิดนี้จะทำงานร่วมกัน แต่ทั้งคู่ก็อยู่ในเลเยอร์ที่แตกต่างกันของสถาปัตยกรรมซอฟต์แวร์

API เป็นข้อกำหนดอินเทอร์เฟซและสัญญาการสื่อสารอย่างเคร่งครัด โดยกำหนดลายเซ็นของเมธอด, โครงสร้างข้อมูล, ไวยากรณ์ URI ตาม IETF RFC 3986 และรูปแบบการตอบกลับที่ช่วยให้คอมโพเนนต์ซอฟต์แวร์ตัวหนึ่งโต้ตอบกับอีกตัวหนึ่งได้ API มีอยู่หลายระดับ ได้แก่ อินเทอร์เฟซระบบปฏิบัติการภายในเครื่อง, อินเทอร์เฟซไลบรารีในกระบวนการ หรือเว็บเอ็นด์พอยต์แบบไร้สถานะระยะไกลที่ควบคุมโดยความหมายของ HTTP ตาม IETF RFC 9110 (เช่น GET, POST) เมื่อเรียกใช้ REST API ระยะไกลโดยตรง นักพัฒนาแอปพลิเคชันจะต้องสร้างคำขอเครือข่าย จัดการความปลอดภัยในการรับส่งข้อมูล วิเคราะห์เพย์โหลด JSON ที่ส่งคืน และจัดการเงื่อนไขการลองส่งใหม่ด้วยตนเอง

ในทางกลับกัน SDK คือชุดการใช้งานที่สมบูรณ์ซึ่งรวบรวม API ภายในเครื่องหนึ่งตัวหรือมากกว่าไว้ข้างๆ Logic การทำงานรันไทม์ เอกสารประกอบ และเครื่องมือสำหรับนักพัฒนา เมื่อนักพัฒนา import SDK มือถือลงในโปรเจกต์ Android Studio หรือ Xcode พวกเขาจะลิงก์โค้ดไลบรารีที่สร้างไว้ล่วงหน้าเข้ากับไบนารีของแอปพลิเคชันโดยตรง SDK จะเปิดเผย API แบบโปรแกรมภายในเครื่อง (เช่น initialize(), getInstallParam() หรือ handleDeepLink()) ให้กับแอปพลิเคชันโฮสต์ พร้อมทั้งจัดการการจัดตารางเวลาเธรด คอลแบ็กของระบบปฏิบัติการ และการสื่อสารกับเซิร์ฟเวอร์ระยะไกลภายในตัว

บริบทการทำงาน: เอ็นด์พอยต์เซิร์ฟเวอร์ต่อเซิร์ฟเวอร์แบบไร้สถานะ กับไลบรารีรันไทม์ฝั่งไคลเอนต์ที่มีสถานะ

ความแตกต่างในการปฏิบัติงานระหว่างการเรียกใช้เว็บ API ระยะไกลและการบูรณาการ SDK มือถือแบบเนทีฟนั้นขึ้นอยู่กับบริบทการทำงานและการเข้าถึงสภาพแวดล้อมของอุปกรณ์:

• การจัดเก็บกระบวนการและการแพ็กเกจ (Process Residency and Packaging): เว็บ API ระยะไกลจะถูกเปิดใช้งานผ่านโครงสร้างพื้นฐานฝั่งเซิร์ฟเวอร์และเรียกใช้ผ่านเครือข่าย โดยแอปพลิเคชันฝั่งเซิร์ฟเวอร์จะเป็นผู้ใช้งานเอ็นด์พอยต์ ในขณะที่แอปพลิเคชันฝั่งไคลเอนต์จะเป็นผู้ดำเนินตรรกะในการจัดการคำขอ ในทางตรงกันข้าม SDK มือถือจะถูกคอมไพล์ลงในอาร์ติแฟกต์การเผยแพร่ของแอปพลิเคชัน (เช่น Android App Bundle .aab) หรือแพ็กเกจแอปพลิเคชันที่ติดตั้งได้ (ไฟล์ .apk บน Android และ .ipa บน iOS) และทำงานภายในพื้นที่หน่วยความจำที่จัดสรรไว้ของแอปพลิเคชันบนอุปกรณ์ของผู้ใช้ปลายทาง
• การรับรู้วงจรการทำงานแบบเนทีฟ (Native Lifecycle Awareness): เอ็นด์พอยต์ REST ระยะไกลจะตอบสนองก็ต่อเมื่อไคลเอนต์ส่งคำขอ HTTP ออกไปเท่านั้น แต่ SDK มือถือแบบเนทีฟจะลงทะเบียนผู้สังเกตการณ์ (Observers) กับระบบปฏิบัติการมือถือ ทำให้สามารถตรวจจับได้ว่าแอปพลิเคชันกำลังเปิดใช้งาน, มีการสลับสถานะระหว่างเบื้องหน้าและเบื้องหลัง หรือได้รับคำสั่งการนำทางระดับระบบ
• การคงอยู่ของข้อมูลภายในเครื่องและการเข้าคิวแบบเลือกได้ (Optional Local Persistence and Queuing): ขึ้นอยู่กับการใช้งาน SDK มือถืออาจจัดเก็บสถานะการกำหนดค่าหรือจัดคิวอีเวนต์การแปลง (Conversion Events) ไว้ในพื้นที่จัดเก็บแซนด์บ็อกซ์ในเครื่อง (เช่น SharedPreferences หรือ SQLite บน Android และ UserDefaults หรือพื้นที่จัดเก็บไฟล์แอปพลิเคชันบน iOS พร้อมทั้งสำรอง Keychain สำหรับข้อมูลรับรองขนาดเล็กที่มีความละเอียดอ่อน) เพื่อให้สามารถส่งข้อมูลทางไกลแบบอะซิงโครนัสได้เมื่อมีการเชื่อมต่อเครือข่าย

การเปรียบเทียบสถาปัตยกรรม: เว็บ API ระยะไกลเทียบกับ SDK มือถือแบบเนทีฟ

ตารางด้านล่างเปรียบเทียบระหว่างเว็บ API แบบไร้สถานะระยะไกลกับ SDK มือถือแบบเนทีฟที่คอมไพล์แล้ว ในมิติด้านสถาปัตยกรรมหลักๆ:

คอมโพเนนต์หลักภายใน Software Development Kit ของมือถือ

ไลบรารีไบนารีที่คอมไพล์แล้ว: Android Archive Bundles และ iOS Frameworks

หัวใจสำคัญของ SDK มือถือคือการกระจายไบนารีที่คอมไพล์แล้ว ซึ่งจัดรูปแบบสำหรับชุดเครื่องมือสร้าง (Build Toolchain) ของระบบปฏิบัติการเป้าหมาย:

• Android Archive (.aar), JAR และ App Bundles (.aab): บน Android SDK จะถูกแจกจ่ายเป็นชุด .aar หรือไลบรารี .jar แม้ว่าไฟล์ .jar จะมีไบต์โค้ด JVM ที่คอมไพล์แล้ว แต่ชุด .aar ยังสามารถแพ็กเกจทรัพยากรเฉพาะของ Android และรายการ Manifest ที่รวมเข้ากับแอปพลิเคชันโฮสต์ระหว่างการคอมไพล์ด้วย Gradle เมื่อแอปพลิเคชันโฮสต์ถูกสร้างขึ้นสำหรับการเผยแพร่ Android App Bundle (.aab) จะทำหน้าที่เป็นอาร์ติแฟกต์ในการเผยแพร่มากกว่าที่จะเป็นแพ็กเกจแอปพลิเคชันที่ติดตั้งได้โดยตรง โดย Google Play จะประมวลผลเป็น APK เฉพาะอุปกรณ์เพื่อส่งมอบให้กับผู้ใช้
• iOS Static Libraries (.a), Frameworks และ XCFrameworks: บน iOS SDK จะถูกแจกจ่ายเป็นไลบรารีสแตติก, ชุด .framework หรือคลังเก็บ .xcframework การสร้าง .framework แบบมาตรฐานมักจะกำหนดเป้าหมายไปยังตัวAvariant ของแพลตฟอร์มเฉพาะ และอาจมีสถาปัตยกรรม CPU ที่รองรับหนึ่งรายการหรือมากกว่า ในขณะที่ชุด Apple XCFramework (.xcframework) ถูกออกแบบมาเพื่อแพ็กเกจตัวแปรของแพลตฟอร์มและสถาปัตยกรรมหลายแบบ เช่น ส่วนประกอบอุปกรณ์ iOS แบบ ARM64 ควบคู่ไปกับส่วนประกอบ iOS Simulator ให้อยู่ในอาร์ติแฟกต์แจกจ่ายเดียว

ไฟล์เฮดเดอร์สาธารณะ, สัญญาอินเทอร์เฟซ และคำจำกัดความประเภทข้อมูล

ไบนารีที่คอมไพล์แล้วจำเป็นต้องมีสัญญาประเภทข้อมูลสาธารณะ (Type Contracts) เพื่อให้คอมไพเลอร์ของแอปพลิเคชันโฮสต์สามารถตรวจสอบการเรียกใช้เมธอดได้ในเวลาคอมไพล์:

• ไฟล์เฮดเดอร์ของ iOS (.h) และอินเทอร์เฟซบริดจ์: SDK ของ iOS ที่ใช้ Objective-C จะมีไฟล์เฮดเดอร์สาธารณะ (เช่น OpoInstallSDK.h) ที่ประกาศอินเทอร์เฟซคลาส, โปรโตคอลเดเลเกต (OpoInstallDelegate) และโมเดลข้อมูล (OpoinstallData) ในโปรเจกต์ Swift การประกาศเหล่านี้จะถูกเปิดเผยผ่าน Objective-C Bridging Header หรือการ import โมดูล
• ลายเซ็นคลาสและอินเทอร์เฟซคอลแบ็กของ Android: SDK ของ Android จะเปิดเผยคลาสจุดเข้าใช้งานสาธารณะและอินเทอร์เฟซคอลแบ็กทั่วไป (เช่น ResultCallBack<OpoData>) ภายในเนมสเปซแพ็กเกจที่มีเอกสารกำกับ

ไฟล์การกำหนดค่า Manifest, AppKeys และการประกาศสิทธิ์ (Entitlement Declarations)

SDK มือถืออาศัยข้อมูลเมตาการกำหนดค่าของโฮสต์เพื่อตรวจสอบความถูกต้องของคำขอผู้เช่า (Tenant Requests) และลงทะเบียนฮุกการนำทางของระบบปฏิบัติการ:

• ตัวระบุแอปพลิเคชันผู้เช่า (AppKey): ประกาศภายในแท็ก <meta-data> ของ AndroidManifest.xml บน Android หรือไฟล์ Info.plist บน iOS (com.opoinstall.APP_KEY) โดย AppKey จะระบุผู้เช่าแอปพลิเคชันระหว่างการเริ่มต้นใช้งาน SDK
• การประกาศการนำทางของระบบปฏิบัติการ: เพื่อรองรับการเปิดแอปด้วยคลิกเดียว โปรเจกต์โฮสต์จะประกาศสคีมา URL แบบกำหนดเองและโดเมนที่ตรวจสอบแล้ว (โดเมน applinks: ในสิทธิ์ Associated Domains ของ Xcode และฟิลเตอร์อินเทนต์ที่ตรวจสอบแล้วบน Android)

เอกสารประกอบและโปรเจกต์ตัวอย่าง: แปลงไลบรารีที่คอมไพล์แล้วให้เป็นอินเทอร์เฟซสำหรับนักพัฒนาที่ใช้งานได้

ไลบรารีที่คอมไพล์แล้วจะยากต่อการนำไปใช้งานหากไม่มีข้อกำหนดการบูรณาการที่ชัดเจน SDK ระดับโปรดักชันควรมีเอกสารสำหรับนักพัฒนาที่ชัดเจน และมีโปรเจกต์ตัวอย่างที่สามารถรันได้:

• เอกสารสำหรับนักพัฒนา: กำหนดความเข้ากันได้ของเวอร์ชัน, ลำดับการเริ่มต้นวงจรการทำงาน, สิทธิ์ที่จำเป็น, รูปแบบเพย์โหลดคอลแบ็ก และโค้ดข้อผิดพลาด เพื่อให้วิศวกรสามารถบูรณาการไลบรารีได้อย่างคาดการณ์ได้
• โปรเจกต์ตัวอย่างและบริดจ์ข้ามแพลตฟอร์ม: โปรเจกต์เดโมขั้นต่ำที่รันได้ช่วยให้ทีมงานตรวจสอบการทำ Deep Linking และการกู้คืนพารามิเตอร์ได้ ในขณะที่ ศูนย์ดาวน์โหลด SDK มือถือ จะแจกจ่ายแพ็กเกจ SDK เนทีฟหลักสำหรับ Android และ iOS เป็นหลัก (ปัจจุบันคือ v2.1.0) แต่ทีมที่ใช้เฟรมเวิร์กข้ามแพลตฟอร์ม (เช่น Flutter หรือ Unity) จะเชื่อมความสามารถของ SDK เนทีฟเหล่านี้ผ่านปลั๊กอิน Wrapper หรือช่องทางแพลตฟอร์ม (Platform Channels) และควรตรวจสอบที่เก็บปลั๊กอินที่มีให้เทียบกับเอกสารทางการ

เหตุใดเว็บ API เพียงอย่างเดียวจึงไม่สามารถแก้ปัญหาการระบุแหล่งที่มาของการติดตั้งแอปมือถือได้

กล่องดำของ App Store: การแยกแซนด์บ็อกซ์ทำลายการติดตามด้วยคุกกี้เว็บแบบดั้งเดิมอย่างไร

ในการพัฒนาเว็บมาตรฐาน การติดตามลิงก์แนะนำไปยังเหตุการณ์การลงทะเบียนจะอาศัยพื้นที่เก็บข้อมูลของเบราว์เซอร์: เมื่อผู้ใช้เยี่ยมชม https://example.com/index.html?inviter_id=A102 จาวาสคริปต์จะอ่านสตริงคิวรีและจัดเก็บ inviter_id=A102 ไว้ใน localStorage หรือ HTTP Cookie

ในการได้มาซึ่งผู้ใช้แอปมือถือ ความต่อเนื่องนี้จะขาดลงที่ขอบเขตของ App Store ซึ่งเป็นอุปสรรคเชิงโครงสร้างที่เรียกว่า กล่องดำของ App Store (App Store Black Box):

1. บริบทของเว็บ: ผู้ใช้คลิกลิงก์โปรโมชันภายในเบราว์เซอร์มือถือหรือโซเชียลแอป โหลดหน้า Landing Page แบบ H5 ที่มีพารามิเตอร์กำหนดเอง (?ref=userA&channelCode=ch_01)
2. การส่งต่อสู่สโตร์: เนื่องจากยังไม่ได้ติดตั้งแอปเนทีฟ การคลิกปุ่มดาวน์โหลดจะนำผู้ใช้ออกจากเบราว์เซอร์ไปยัง Apple App Store หรือ Google Play Store
3. การแยกแซนด์บ็อกซ์ (Sandbox Isolation): เมื่อผู้ใช้ติดตั้งและเปิดแอปเนทีฟ ระบบปฏิบัติการมือถือจะสร้างกระบวนการขึ้นภายในระบบไฟล์และแซนด์บ็อกซ์หน่วยความจำที่แยกต่างหาก แอปเนทีฟจึงไม่สามารถอ่านคุกกี้หรือ localStorage ของเซสชันเบราว์เซอร์ที่เริ่มต้นการดาวน์โหลดได้

การเชื่อมช่องว่างระหว่างเว็บกับแอป: บทบาทของเว็บ JS SDK และ SDK ไคลเอนต์เนทีฟ

การแก้ไขพารามิเตอร์ข้ามขอบเขต App Store ใช้เวิร์กโฟลว์ที่ประสานงานกันซึ่งแยกแนวคิดที่เกี่ยวข้องสามประการออกจากกัน ได้แก่ Deferred Deep Linking (การนำผู้ใช้ใหม่ไปยังหน้าจอเป้าหมายในแอปหลังการติดตั้ง), การกู้คืนพารามิเตอร์การติดตั้ง (การกู้คืนคู่คีย์-วาล์วแบบกำหนดเองที่ส่งผ่านลิงก์ H5) และ การจับคู่แหล่งที่มา (การเชื่อมโยงการติดตั้งเข้ากับช่องทางการโปรโมชันเฉพาะ):

• เว็บ JS SDK ก่อนการติดตั้ง (สคริปต์เว็บ OpoInstall): บูรณาการเข้ากับหน้า Landing Page แบบ H5 โดยเว็บ JS SDK จะแยกวิเคราะห์พารามิเตอร์คิวรีแบบไดนามิกจาก URL การแชร์ (เช่น channelCode, shareCode หรือรหัสห้อง) และอัปโหลดบริบทเซสชันก่อนการติดตั้งไปยังเซิร์ฟเวอร์ระบุแหล่งที่มาก่อนที่จะเรียกใช้การปลุกแอปหรือการเปลี่ยนเส้นทางไปยังสโตร์
• SDK ไคลเอนต์เนทีฟหลังการติดตั้ง (Android / iOS SDK): บูรณาการเข้ากับไบนารีของแอปมือถือ โดย SDK เนทีฟจะเริ่มต้นการทำงานเมื่อเปิดใช้งานครั้งแรก สื่อสารกับ API ของแพลตฟอร์มและเซิร์ฟเวอร์ระบุแหล่งที่มา และส่งคืนพารามิเตอร์กำหนดเองที่กู้คืนแล้วไปยังแอปไคลเอนต์ผ่านคอลแบ็กแบบอะซิงโครนัส

[เบราว์เซอร์มือถือ: หน้า Landing Page แบบ H5]
                 |
                 | 1. เว็บ JS SDK วิเคราะห์พารามิเตอร์ URL (?ref=userA&channelCode=ch01)
                 |    & อัปโหลดบริบทเซสชันก่อนการติดตั้ง
                 v
     [แบ็กเซิร์ฟเวอร์ระบุแหล่งที่มา]
                 |
                 | 2. ผู้ใช้ดาวน์โหลดแอปจาก App Store / Google Play
                 |    (คุกกี้เบราว์เซอร์ไม่สามารถข้ามแซนด์บ็อกซ์ของ OS ได้)
                 v
   [การเปิดแอปเนทีฟครั้งแรก: SDK มือถือ]
                 |
                 | 3. ไคลเอนต์ SDK เริ่มต้นทำงานในตอนเริ่มต้น & ดึงข้อมูล
                 |    พารามิเตอร์กำหนดเองที่แคชไว้ + รหัสช่องทาง (Channel ID)
                 v
  [การนำทางในแอป & การระบุแหล่งที่มาของช่องทาง]

กลไกการระบุแหล่งที่มาเฉพาะแพลตฟอร์ม: Google Play Install Referrer กับการเทียบเคียงบริบทของ iOS

เนื่องจาก Android และ iOS รักษา architectures ของ App Store ที่แตกต่างกัน การระบุแหล่งที่มาของมือถือจึงอาศัยกลไกแพลตฟอร์มที่แตกต่างกัน:

• ระบบนิเวศของ Android และ Google Play Install Referrer API: สำหรับแอปที่แจกจ่ายผ่าน Google Play การบูรณาการแบบเนทีฟสามารถใช้ Google Play Install Referrer API อย่างเป็นทางการเพื่อดึงข้อมูลเมตาการแนะนำ (รวมถึง URL ผู้อ้างอิงและประทับเวลาการคลิก/การติดตั้ง) ที่ส่งโดย Play Store ระหว่างการติดตั้ง เนื่องจาก Google Play Install Referrer API ใช้เฉพาะกับโฟลว์การติดตั้งของ Google Play Store ที่มีสิทธิ์ การกระจายแอป Android นอก Google Play จึงต้องอาศัยการจับคู่พารามิเตอร์ H5 ฝั่งเซิร์ฟเวอร์หรือแพ็กเกจช่องทาง Android ที่ส่งออก (ไฟล์ APK ที่มีตัวระบุ channelCode ฝังอยู่)
• ระบบนิเวศของ iOS และการเทียบเคียงบริบท (Context Reconciliation): App Store ของ Apple ไม่มีกลไกการส่งผ่านพารามิเตอร์คิวรี URL ทั่วไปที่เทียบเท่ากับ Install Referrer ของ Google Play เมื่อติดตั้งแอปแล้ว iOS จะนำทางผู้ใช้เข้าสู่แอปโดยตรงผ่าน Apple Universal Links ซึ่งจะตรวจสอบความเป็นเจ้าของโดเมนผ่านไฟล์ apple-app-site-association (AASA) เมื่อไม่ได้ติดตั้งแอป Universal Links จะสำรองข้อมูลไปยังเว็บไซต์และไม่ได้รับประกันการกู้คืนพารามิเตอร์หลังการติดตั้งโดยอิสระ การกู้คืนพารามิเตอร์ที่รออยู่ (Deferred Parameter Restoration) จึงต้องอาศัยการเทียบเคียงเซสชันฝั่งเซิร์ฟเวอร์เมื่อเปิดใช้งานครั้งแรก

การเคารพขอบเขตความเป็นส่วนตัวของแพลตฟอร์ม: แนวทางความเป็นส่วนตัวของผู้ใช้ของ Apple และสัญญาณการจับคู่ที่อนุญาต

เมื่อประเมินว่า SDK มือถือเทียบเคียงการเข้าชมเว็บก่อนการติดตั้งกับการเปิดใช้งานหลังการติดตั้งอย่างไร ทีมวิศวกรรมต้องแยกแยะระหว่างฟีเจอร์ที่เอกสารของผู้ขายระบุกับการปฏิบัติตามนโยบายของระบบปฏิบัติการ:

• กลไกที่ระบุโดยผู้ขาย: เอกสารผลิตภัณฑ์สาธารณะของ OpoInstall อธิบายถึงเวิร์กโฟลว์ช่องทาง H5 และการติดตั้งพารามิเตอร์ โดย Web SDK จะรวบรวมลักษณะลายนิ้วมือของอุปกรณ์และรหัสช่องทางบนหน้า H5 และ SDK เนทีฟของ Android/iOS จะรวบรวมลักษณะอุปกรณ์อีกครั้งเมื่อเปิดใช้งานครั้งแรกเพื่อจับคู่แหล่งที่มาของการติดตั้ง
• ขอบเขตของนโยบายแพลตฟอร์ม Apple: ภายใต้ แนวทางความเป็นส่วนตัวและการใช้ข้อมูลผู้ใช้ของ Apple Apple ห้ามอย่างชัดเจนในการดึงข้อมูลจากอุปกรณ์ เช่น การรวมคุณสมบัติของเบราว์เซอร์ ที่อยู่ IP หรือการกำหนดค่าระบบ เพื่อวัตถุประสงค์ในการระบุตัวตนผู้ใช้หรืออุปกรณ์ที่ไม่ซ้ำกัน (การทำ Device Fingerprinting) แอปพลิเคชันที่มีส่วนร่วมในการทำลายนิ้วมือที่ต้องห้าม หรืออ้างอิงถึง SDK 3rd-party ที่ทำเช่นนั้น อาจมีความเสี่ยงที่จะถูกปฏิเสธระหว่างการตรวจสอบ App Store นอกจากนี้ การอนุญาต App Tracking Transparency (ATT) จะเป็นสิ่งจำเป็นเมื่อบริการทำ Deep Linking หรือ Deferred Deep Linking ของบุคคลที่สามส่งตัวระบุที่ไม่ซ้ำกันหรือสร้างตัวตนผู้ใช้ที่ใช้ร่วมกันข้ามแอปจากบริษัทต่างๆ เพื่อการกำหนดเป้าหมายโฆษณา การวัดผลโฆษณา หรือการแบ่งปันกับโบรกเกอร์ข้อมูล อย่างไรก็ตาม ความยินยอมตาม ATT ไม่ได้ทำให้การทำลายนิ้วมืออุปกรณ์ที่ถูกห้ามกลายเป็นสิ่งที่ถูกต้องตามกฎระเบียบ
• การยกระดับการปฏิบัติตามข้อกำหนดและข้อกำหนดในการตรวจสอบ: หาก SDK เวอร์ชันหรือการกำหนดค่าเฉพาะอาศัยการทำลายนิ้วมืออุปกรณ์ที่ถูกห้าม การดำเนินการตรวจสอบข้อมูลภายในทั่วไปหรือการรับความยินยอมจากผู้ใช้ผ่านข้อความแจ้ง ATT จะไม่ทำให้กลไกนั้นสอดคล้องกับแนวทางของ Apple หากผู้ขายไม่สามารถแสดงให้เห็นว่ากลไกการจับคู่ของ iOS หลีกเลี่ยงการทำลายนิ้วมืออุปกรณ์ที่ถูกห้าม นักพัฒนาไม่ควรปรับใช้กลไกการระบุแหล่งที่มานั้นบน iOS จนกว่าจะมีการตรวจสอบทางเลือกที่สอดคล้องอย่างอิสระ โดยปฏิบัติตามแนวทางปฏิบัติในการกำกับดูแลของ OWASP Mobile Application Security
• จังหวะเวลาของเครือข่ายและการสำรองข้อมูลเมื่อระบุแหล่งที่มาไม่ได้: แม้ว่า iOS จะไม่ได้เปิดสิทธิ์ทั่วไปที่ผู้ใช้ให้ไว้สำหรับการเข้าถึงอินเทอร์เน็ตปกติ (นักพัฒนาควรแยกแยะความสามารถในการเข้าถึงอินเทอร์เน็ตทั่วไปออกจากสิทธิ์ความเป็นส่วนตัว Local Network ของ Apple ซึ่งใช้กับการค้นหาอุปกรณ์ในเครือข่ายท้องถิ่น) แต่การเริ่มต้น SDK และการดึงข้อมูลพารามิเตอร์ยังคงขึ้นอยู่กับความพร้อมใช้งานของเครือข่ายและเวลาในการเริ่มต้นระบบ เนื่องจากการจับคู่แบบรอการดำเนินการ (Deferred Matching) ไม่ได้รับประกันภายใต้ทุกสภาพเครือข่ายหรือการเปิดใช้งานครั้งแรกที่ล่าช้า แอปพลิเคชันจึงต้องใช้โฟลว์สำรองที่ราบรื่นเสมอเมื่อพารามิเตอร์ที่ส่งคืนว่างเปล่า

SDK การระบุแหล่งที่มาบนมือถือทำงานอย่างไรตลอดวงจรการทำงานของแอปพลิเคชัน

เฟส 1: การจัดการการพึ่งพาและการลิงก์เวลาคอมไพล์ผ่าน Gradle และ CocoaPods

วงจรการทำงานของ SDK เริ่มต้นขึ้นในเวลาคอมไพล์ เมื่อนักพัฒนาประกาศการพึ่งพาไลบรารีผ่าน Gradle, CocoaPods หรือการนำเข้าอาร์ติแฟกต์ด้วยตนเอง ในระหว่างการคอมไพล์ ตัวจัดการแพ็กเกจจะแก้ไขอาร์ติแฟกต์ไลบรารีและลิงก์สัญลักษณ์ไบนารีเข้าไปในแพ็กเกจแอปพลิเคชัน SDK มือถือบางตัวจำเป็นต้องมีการพิจารณาความเข้ากันได้ของการย่อโค้ด (Code-Shrinking) ในบิวด์สำหรับเผยแพร่ (Release Builds) และการบูรณาการ SDK ของ iOS อาจต้องมีการประกาศไฟล์ Manifest ความความเป็นส่วนตัวเฉพาะแพลตฟอร์มและการกำหนดค่าบิวด์ที่เข้ากันได้ด้วยเช่นกัน

เฟส 2: การเริ่มต้นใช้งานบนเธรดหลักเมื่อแอปพลิเคชันเริ่มทำงาน

เมื่อผู้ใช้เปิดแอป ระบบปฏิบัติการมือถือจะสร้างกระบวนการของแอปพลิเคชันและเรียกใช้ฮุกวงจรการทำงานของจุดเข้าใช้งานหลัก ได้แก่ Application.onCreate() บน Android ตามรายละเอียดใน คู่มือสำหรับนักพัฒนา Android ของ Google เกี่ยวกับวงจรการทำงานของแอปพลิเคชัน และ application(_:didFinishLaunchingWithOptions:) บน iOS ตามรายละเอียดใน เอกสารสำหรับนักพัฒนา Apple เกี่ยวกับ UIApplicationDelegate SDK มือถือที่ออกแบบมาอย่างดีควรลดภาระงานให้น้อยที่สุดในระหว่างการเริ่มต้นแอปพลิเคชันและย้ายการดำเนินการเครือข่ายไปเป็นการทำงานแบบอะซิงโครนัส นักควรตรวจสอบพฤติกรรมการเริ่มต้นใช้งานจริงและวัดประสิทธิภาพการเริ่มทำงานแบบเย็น (Cold-Start) ในบิวด์เป้าหมาย

เฟส 3: การดักจับ Deep Links แบบเนทีฟผ่าน Universal Links และ Intent Filters

เมื่อมีการติดตั้งแอปไว้แล้วและผู้ใช้แตะลิงก์ H5 ระบบปฏิบัติการจะปลุกแอปพลิเคชันขึ้นมาและส่งมอบบริบทการนำทางไปยัง SDK ผ่านจุดเข้าใช้งานเฉพาะของแพลตฟอร์ม:

• สีมาแบบกำหนดเองของ Android กับ App Links ที่ตรวจสอบแล้ว: สีมา URL แบบกำหนดเอง (scheme://) จะกำหนดเส้นทางผ่านตัวกรอง BROWSABLE <intent-filter> พื้นฐาน การสนับสนุน Android App Links ที่ตรวจสอบแล้วจำเป็นต้องมี <intent-filter android:autoVerify="true"> ซึ่งประกาศทั้งสีมา http และ https ควบคู่ไปกับเป้าหมาย android:host โดยสนับสนุนด้วยไฟล์ Digital Asset Links /.well-known/assetlinks.json ที่มีชื่อแพ็กเกจของแอปและลายเซ็นใบรับรอง SHA-256
• การนำทางผ่าน AppDelegate และ UISceneDelegate บน iOS: Universal Links จะส่ง NSUserActivity ไปยัง AppDelegate ในแอปพลิเคชันที่มีวงจรการทำงานแบบดั้งเดิม หรือสำหรับแอป iOS 13+ ที่ใช้วงจรการทำงานแบบ Scene-based ผ่าน UISceneDelegate ไปยังเมธอด scene(_:willConnectTo:options:) เมื่อเริ่มต้นแบบเย็น และ scene(_:continue:) เมื่อกลับมาทำงานต่อแบบอบอุ่น (Warm Resume)

เฟส 4: การกู้คืนพารามิเตอร์แบบอะซิงโครนัสและการเข้าคิวข้อมูลโทรมาตรของอีเวนต์

ในการเปิดใช้งานครั้งแรก หรือเมื่อเกิดเหตุการณ์การแปลงทางธุรกิจ แอปพลิเคชันโฮสต์จะเรียกใช้เมธอดแบบอะซิงโครนัสของ SDK เพื่อดึงข้อมูลพารามิเตอร์การติดตั้งที่แคชไว้ (data และ channelCode) และรายงานเหตุการณ์การแปลงต้นทางปลายทาง (เช่น การลงทะเบียนบัญชีหรือจุดเอฟเฟกต์แบบกำหนดเอง)

การใช้งาน Native SDK Lifecycle Hooks บน Android และ iOS

การกำหนดค่าตัวระบุแอปพลิเคชันและการตรวจสอบรุ่น SDK

รูปแบบการบูรณาการที่เป็นตัวอย่างด้านล่างปฏิบัติตามเอกสารการบูรณาการสาธารณะของ OpoInstall เพื่อแสดงวิธีที่โปรเจกต์ Android และ iOS แบบเนทีฟเชื่อมโยงฮุกวงจรการทำงานที่อธิบายไว้ข้างต้น เนื่องจากศูนย์ดาวน์โหลดมีการแจกจ่ายอาร์ติแฟกต์ SDK ที่อัปเดตแล้ว (ปัจจุบันคือ v2.1.0 เผยแพร่เมื่อ 2026-09-20) ในขณะที่ตัวอย่างในเอกสารอาจอ้างอิงถึงพิกัดย่อยก่อนหน้า ทีมวิศวกรรมจึงต้องดาวน์โหลดแพ็กเกจ SDK v2.1.0 ที่เป็นเป้าหมาย ตรวจสอบเส้นทาง import ทั้งหมดและลายเซ็นเมธอดเทียบกับเฮดเดอร์ไลบรารีที่รวมอยู่ และทำการตรวจสอบการคอมไพล์ที่สะอาดใน Android Studio และ Xcode ก่อนการปรับใช้จริง โปรดดูรายละเอียดเพิ่มเติมที่ เอกสารทางเทคนิคของ OpoInstall สำหรับคำแนะนำการบูรณาการเฉพาะรุ่น

รูปแบบการเริ่มต้น SDK ของ Android และการดึงข้อมูลพารามิเตอร์

ในไฟล์ AndroidManifest.xml ให้ประกาศสิทธิ์เครือข่าย, AppKey ของผู้เช่า และบล็อก <intent-filter> แยกต่างหากสำหรับการปลุกสีมา URL แบบกำหนดเองและ Android App Links ที่ตรวจสอบแล้ว (โดยประกาศทั้งสีมา http และ https ตามข้อกำหนดการตรวจสอบสิทธิ์ Android App Links และแทนที่ links.example.com ด้วยโดเมนที่ได้รับการตรวจสอบแล้วของคุณ):

<!-- ไฟล์: app/src/main/AndroidManifest.xml (รูปแบบการบูรณาการตัวอย่าง) -->
<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. ฟิลเตอร์ปลุกสีมา URL แบบกำหนดเอง -->
            <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. ฟิลเตอร์ Android App Links ที่ตรวจสอบแล้ว (ต้องมี /.well-known/assetlinks.json พร้อมลายเซ็นใบรับรอง SHA-256) -->
            <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>

// ไฟล์: 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);
    }
}

// ไฟล์: app/src/main/java/com/example/app/MainActivity.java
// หมายเหตุ: โปรดตรวจสอบแพ็กเกจการ import และลายเซ็นคอลแบ็กให้ตรงกับคลังเก็บ SDK v2.1.0 ที่คุณดาวน์โหลดมา
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);

        // ประมวลผลอินเทนต์ปลุกหากเปิดใช้งานผ่านสีมาแบบกำหนดเองหรือ App Link ที่ตรวจสอบแล้ว
        getWakeUpData(getIntent());

        // ดึงข้อมูลพารามิเตอร์การติดตั้งที่รออยู่เมื่อจำเป็นต้องใช้โดยลอจิกการเริ่มต้นใช้งาน (Onboarding)
        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);
            }
        });
    }
}

รูปแบบการลงทะเบียน iOS SDK Delegate และ SceneDelegate Wakeup

บน iOS ให้เปิดเผย #import "OpoInstallSDK.h" ใน Objective-C Bridging Header ของคุณ, กำหนดค่า com.opoinstall.APP_KEY ใน Info.plist และใช้งาน OpoInstallDelegate ใช้เมธอดการจัดการ URL ของ AppDelegate สำหรับแอปพลิเคชันที่ไม่ใช้วิธีการจัดการวงจรการทำงานแบบ Scene-based สำหรับแอปพลิเคชันที่ใช้ Scene-based ให้ประมวลผล Universal Links และสีมา URL แบบเปิดใช้งานครั้งแรก (Cold-Start) และกลับมาทำงานต่อแบบอบอุ่นผ่านเมธอด SceneDelegate ที่สอดคล้องกัน:

// ไฟล์: AppDelegate.swift & SceneDelegate.swift (รูปแบบการบูรณาการตัวอย่าง)
// หมายเหตุ: โปรดตรวจสอบ Objective-C bridging headers และลายเซ็นเมธอดให้ตรงกับคลังเก็บ iOS SDK v2.1.0 ที่คุณดาวน์โหลดมา
import UIKit

@main
class AppDelegate: UIResponder, UIApplicationDelegate, OpoInstallDelegate {

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

    // สำหรับแอปที่ไม่ใช้วิธีการจัดการวงจรการทำงานแบบ UISceneDelegate:
    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))")
        })
    }
}

// สำหรับแอป iOS 13+ ที่จัดการวงจรการทำงานแบบ UISceneDelegate:
@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)
        }
    }
}

เมื่อใดที่ทีมวิศวกรรมควรบูรณาการ Mobile SDK ของบุคคลที่สาม

สถานการณ์ที่เหมาะสมสำหรับการบูรณาการ Mobile SDK เฉพาะทาง

การบูรณาการ SDK การระบุแหล่งที่มาและ Deep-Linking สำหรับมือถือโดยเฉพาะ จะมีความเหมาะสมภายใต้เงื่อนไขเหล่านี้:

• โฟลว์การแนะนำและการเริ่มต้นใช้งานแบบไม่ต้องใส่โค้ด (Code-Free Referral and Onboarding): แอปพลิเคชันที่รันโปรแกรมแนะนำเพื่อนหรือคำเชิญห้องเล่นเกมแบบหลายผู้เล่น ซึ่งจำเป็นต้องกู้คืนพารามิเตอร์ (เช่น ?ref=userA หรือ room_id=402) หลังจากการติดตั้งจากสโตร์โดยไม่ต้องป้อนโค้ดด้วยตนเอง
• แคมเปญ H5 และคิวอาร์โค้ดแบบหลายช่องทาง: ทีมการตลาดที่กระจายลิงก์ผ่านเครือข่ายโซเชียล, คิวอาร์โค้ดแบบออฟไลน์ และแพ็กเกจช่องทาง Android ที่ต้องการการติดตามแบบรวมศูนย์สำหรับการเยี่ยมชม, การคลิก, การติดตั้ง และการลงทะเบียน
• การเปิดใช้งานจากเว็บสู่แอปด้วยคลิกเดียว: ผลิตภัณฑ์ที่นำทางผู้ใช้แอปที่มีอยู่แล้วจากเบราว์เซอร์มือถือไปยังหน้าจอภายในแอปที่เฉพาะเจาะจงผ่าน Universal Links และ App Links ในขณะเดียวกันก็แนะนำผู้ใช้ที่ยังไม่ได้ติดตั้งไปยัง App Store ที่เหมาะสม

สถานการณ์ที่ REST API แบบตรงเพียงพอแล้ว

ในทางกลับกัน SDK การระบุแหล่งที่มาฝั่งไคลเอนต์นั้นไม่จำเป็น หากเวิร์กโฟลว์ไม่ได้ข้ามแซนด์บ็อกซ์มือถือแบบเนทีฟ:

• ธุรกรรมแบ็กเอนด์ที่ผ่านการตรวจสอบสิทธิ์แล้ว: เมื่อผู้ใช้ที่ผ่านการตรวจสอบสิทธิ์แล้วทำการต่ออายุการใช้งานหรือเรียกใช้เว็บฮุกการเรียกเก็บเงินของแบ็กเอนด์ การบันทึกการแปลงนั้นผ่าน REST API แบบ Server-to-Server (S2S) โดยตรงจะช่วยหลีกเลี่ยงการอัปเดตการพึ่งพาฝั่งไคลเอนต์
• เว็บแอปพลิเคชันที่ใช้เบราว์เซอร์เท่านั้น: Progressive Web Apps (PWAs) และเว็บไซต์บนมือถือที่ไม่กระจายไบนารีแบบเนทีฟผ่าน App Store หรือ Google Play สามารถติดตามการแนะนำโดยใช้คุกกี้เว็บ First-party มาตรฐานและพารามิเตอร์คิวรี URL ได้

ความเข้าใจผิดทางวิศวกรรมทั่วไปเกี่ยวกับ Mobile SDK

• ความเข้าใจผิดที่ 1: การบูรณาการ Mobile SDK จะบล็อกการเริ่มแอปพลิเคชันแบบเย็นโดยอัตโนมัติ: SDK มือถือที่ออกแบบมาอย่างดีจะลดภาระงานในระหว่าง Application.onCreate() หรือ didFinishLaunchingWithOptions: และย้ายการดำเนินการเครือข่ายไปเป็นการทำงานแบบอะซิงโครนัส แม้ว่านักพัฒนาควรตรวจสอบความหน่วงของการเริ่มแอปพลิเคชันแบบเย็นในบิวด์เป้าหมายเสมอ
• ความเข้าใจผิดที่ 2: แพ็กเกจช่องทาง Android จะแทนที่รหัสช่องทางของลิงก์ H5: เมื่อแอป Android ใช้ทั้ง APK ช่องทางที่ส่งออกและลิงก์ช่องทาง H5 ทาง OpoInstall SDK จะช่วยให้สามารถดึงข้อมูลพารามิเตอร์กำหนดเองและรหัสช่องทางร่วมกันได้ ตามเอกสารผลิตภัณฑ์ของ OpoInstall หากการติดตั้งมีต้นกำเนิดมาจากลิงก์ช่องทาง H5 ที่มี channelCode ที่ชัดเจน รหัสลิงก์ช่องทาง H5 จะมีความสำคัญเหนือกว่ารหัสแพ็กเกจช่องทางในรายงานสถิติ

สรุปและกรอบการตัดสินใจด้านสถาปัตยกรรม

การทำความเข้าใจว่า SDK คืออะไรและทำงานอย่างไรภายในแซนด์บ็อกซ์ของระบบปฏิบัติการมือถือ จะช่วยให้ทีมวิศวกรรมสามารถออกแบบสถาปัตยกรรมการได้มาซึ่งผู้ใช้งานและการทำ Deep-Linking ที่เชื่อถือได้ ในขณะที่เว็บ API แบบไร้สถานะจัดการการสื่อสารกับเซิร์ฟเวอร์ระยะไกล แต่การบูรณาการฝั่งไคลเอนต์เนทีฟจะมีความจำเป็นเมื่อแอปพลิเคชันต้องการมีส่วนร่วมในอีเวนต์วงจรการทำงานแบบเนทีฟหรือดึงข้อมูลสัญญาณการติดตั้งเฉพาะแพลตฟอร์ม และ SDK มือถือจะรวบรวมความสามารถเหล่านี้ให้อยู่ในเลเยอร์การบูรณาการที่นำกลับมาใช้ใหม่ได้

เมื่อตัดสินใจว่าจะจัดโครงสร้างไปป์ไลน์การระบุแหล่งที่มาอย่างไร ให้ปฏิบัติตามแนวทางปฏิบัติด้านวิศวกรรมเหล่านี้:

• ปรับใช้ Mobile SDK แบบเนทีฟ: เมื่อเส้นทางของผู้ใช้งานเปลี่ยนผ่านจากหน้า Landing Page แบบ H5, การแชร์บนโซเชียล หรือคิวอาร์โค้ดผ่าน App Store หรือ Google Play และจำเป็นต้องมีการกู้คืนพารามิเตอร์อัตโนมัติหรือการนำทางผ่าน Universal Link / App Link ด้วยคลิกเดียว

• ใช้ HTTP API แบบ Server-to-Server: เมื่อส่งออกสถิติช่องทางที่รวบรวมแล้วไปยังคลังข้อมูลภายใน (Data Warehouse) หรือเมื่อบันทึกอีเวนต์แบ็กเอนด์ที่ไม่ขึ้นอยู่กับบริบทการเปิดใช้งานฝั่งไคลเอนต์

• ตรวจสอบการคอมไพล์ไบนารีและการปฏิบัติตามความเป็นส่วนตัวของแพลตฟอร์ม: ทดสอบการคอมไพล์คลังเก็บ SDK ที่เป็นเป้าหมายเสมอ (เช่น v2.1.0) ในโปรเจกต์ที่สะอาด และยืนยันกับผู้ขายว่ากลไกการจับคู่ของ iOS หลีกเลี่ยงการทำลายนิ้วมืออุปกรณ์ที่ถูกห้ามก่อนที่จะเผยแพร่จริง

ทีมวิศวกรรมที่ประเมินโครงสร้างพื้นฐานการระบุแหล่งที่มาสามารถลงทะเบียนคีย์แอปพลิเคชันบน คอนโซลนักพัฒนา OpoInstall เพื่อทดสอบการกู้คืนพารามิเตอร์และการนำทาง Deep-Link ในสภาพแวดล้อม Staging ได้

วัสดุและข้อมูลอ้างอิงที่เกี่ยวข้อง

• แนวคิด: Software Development Kit, Application Programming Interface, Deferred Deep Linking, การแยกแซนด์บ็อกซ์ของ OS

• เทคโนโลยี: Android Archive (.aar), iOS XCFramework, Google Play Install Referrer, Apple Universal Links

• มาตรฐาน: IETF RFC 9110 HTTP Semantics, IETF RFC 3986 URI Generic Syntax, โครงการความปลอดภัยแอปพลิเคชันมือถือ OWASP

• อินเทอร์เฟซแพลตฟอร์มและการบูรณาการ: Android Application.onCreate, iOS UIApplicationDelegate, UISceneDelegate, NSUserActivity

• เอกสารอย่างเป็นทางการ & เอกสารอ้างอิง:

  • คู่มือสำหรับนักพัฒนา Android ของ Google เกี่ยวกับวงจรการทำงานของแอปพลิเคชัน

  • คู่มือสำหรับนักพัฒนา Android ของ Google เกี่ยวกับ App Links

  • คู่มือทางเทคนิค Google Play Install Referrer API

  • เอกสารสำหรับนักพัฒนา Apple เกี่ยวกับ UIApplicationDelegate

  • เอกสารสำหรับนักพัฒนา Apple เกี่ยวกับ UISceneDelegate

  • เอกสารสำหรับนักพัฒนา Apple เกี่ยวกับการสนับสนุน Universal Links

  • เอกสารสำหรับนักพัฒนา Apple เกี่ยวกับการสร้างชุดเฟรมเวิร์กไบนารีหลายแพลตฟอร์ม (XCFramework)

  • แนวทางความเป็นส่วนตัวและการใช้ข้อมูลผู้ใช้ของ Apple