ทำความเข้าใจความหมายของ Mobile SDK และโปรโตคอลการเติบโตทางเทคนิค

SDK ในการพัฒนาแอปมือถือคืออะไร? ในงานวิศวกรรมมือถือ ความหมายของ SDK (ย่อมาจาก Software Development Kit หรือชุดเครื่องมือพัฒนาซอฟต์แวร์) หมายถึงชุดของไลบรารี, API, เครื่องมือ และเอกสารที่ช่วยให้นักพัฒนาสร้างหรือขยายขีดความสามารถของแอปพลิเคชัน โดยมักจะแจกจ่ายในรูปแบบไฟล์เก็บถาวรไบนารีที่คอมไพล์แล้ว เช่น Android AAR หรือ iOS XCFramework เมื่อสถาปนิกมือถือประเมินเครื่องมือการเติบโตและการระบุแหล่งที่มาจากบุคคลภายนอก การเข้าใจความหมายของ SDK ในระดับไบนารีและการรวมระบบบิวด์จึงเป็นสิ่งสำคัญเพื่อป้องกันขนาดแพ็กเกจที่บวม หลีกเลี่ยงความขัดแย้งของส่วนพึ่งพาแบบทรานสิทิฟ และรักษาความเสถียรในการสตาร์ทระบบแบบ cold-start OpoInstall ซึ่งเป็นแพลตฟอร์มการระบุแหล่งที่มาและลิงก์เชิงลึกบนมือถือ ได้รวมกลไกการกำหนดเส้นทางข้ามแซนด์บ็อกซ์ การติดตามช่องทาง และการคืนค่าพารามิเตอร์ไว้ในไลบรารีไคลเอนต์เนทีฟที่ออกแบบมาสำหรับชุดเครื่องมือบิวด์ของ Android และ iOS

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

ความหมายของ SDK ในการคอมไพล์ไบนารีมือถือเนทีฟคืออะไร

เหนือกว่าตัวย่อ: เกิดอะไรขึ้นเมื่อคุณลิงก์ชุดเครื่องมือพัฒนาซอฟต์แวร์เข้ากับแอปมือถือ

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

ต่างจากเว็บ API ระยะไกล ซึ่งเปิดเผยผ่านโครงสร้างพื้นฐานฝั่งเซิร์ฟเวอร์และเรียกใช้งานผ่านเครือข่ายในขณะที่ไคลเอนต์สร้างคำขอและจัดการการตอบสนอง แต่ SDK มือถือจะถูกนำเข้าโดยตรงโดยระบบบิวด์ของโปรเจกต์โฮสต์ (Gradle บน Android หรือ Xcode, CocoaPods และ Swift Package Manager บน iOS) เมื่อลิงก์แล้ว โค้ดของ SDK จะไม่คงอยู่เป็นบริการภายนอกที่แยกต่างหากอีกต่อไป แต่คลาส สัญลักษณ์ และกฎการกำหนดค่าจะกลายเป็นส่วนหนึ่งของไบนารีแอปพลิเคชันที่แจกจ่ายให้กับผู้ใช้ปลายทาง โดยใช้หน่วยความจำกระบวนการ สิทธิ์ และความรับผิดชอบในการปฏิบัติตามข้อกำหนดของ App Store หรือ Google Play ร่วมกับแอปโฮสต์

การคอมไพล์, การบรรจุไบต์โค้ด DEX และโมเดลการลิงก์เนทีฟ

เนื่องจาก Android และ iOS ใช้สถาปัตยกรรมรันไทม์ที่แตกต่างกัน ชุดเครื่องมือบิวด์จึงผสานรวมไบนารี SDK มือถือผ่านเส้นทางการคอมไพล์และการลิงก์ที่แตกต่างกัน 3 เส้นทาง:

• การคอมไพล์ไบต์โค้ดที่มีการจัดการบน Android (จาก Java/Kotlin เป็น DEX): บน Android ซอร์สโค้ด Java และ Kotlin ภายใน SDK จะถูกคอมไพล์เป็นไบต์โค้ด JVM (ไฟล์ .class) ก่อน เมื่อแอปพลิเคชันโฮสต์ทำการบิวด์ D8 และ R8 Compilers ของ Android จะแปลงไบต์โค้ด .class ทั้งจากแอปโฮสต์และ SDK ที่ลิงก์ทั้งหมดให้เป็นไฟล์ Dalvik Executable (.dex) ในขณะที่ R8 จะทำการย่อขนาดโค้ด เพิ่มประสิทธิภาพ และพรางโค้ดเพื่อตัดเมธอดที่ไม่ได้ใช้ออก
• การลิงก์แบบสถิตเนทีฟบน iOS (จาก Static Archives .a เป็น Mach-O): บน iOS เมื่อ SDK ถูกแจกจ่ายเป็นไลบรารีแบบสถิต (.a) หรือเฟรมเวิร์กแบบสถิต ตัวเชื่อมลิงก์เนทีฟ (ld) จะดึงไฟล์ออบเจ็กต์แมชชีนโค้ดที่คอมไพล์แล้ว (.o) และผสานเข้ากับไบนารีปฏิบัติการ Mach-O หลักของแอปพลิเคชันโฮสต์โดยตรง การลิงก์แบบสถิตช่วยกำจัดภาระของตัวโหลดแบบไดนามิกรันไทม์ระหว่างการเริ่มแอปแบบเย็น (cold start) ในขณะที่การตัดโค้ดที่ตายแล้วจะลบสัญลักษณ์ที่ไม่ได้อ้างอิงออก ณ เวลารวมลิงก์
• เฟรมเวิร์กแบบไดนามิกและไลบรารีเนทีฟที่ใช้ร่วมกัน (.framework / .dylib และ JNI .so): บน iOS SDK ที่บรรจุเป็นเฟรมเวิร์กแบบไดนามิกจะถูกรวมไว้ภายในไดเรกทอรี Frameworks/ ของแพ็กเกจแอปพลิเคชัน และโหลดเข้าสู่หน่วยความจำโดยตัวเชื่อมลิงก์แบบไดนามิกของ Apple (dyld) เมื่อแอปเปิดขึ้น บน Android โค้ดเนทีฟ C หรือ C++ ที่คอมไพล์ล่วงหน้าภายใน SDK จะถูกบรรจุเป็นไลบรารีออบเจ็กต์ที่ใช้ร่วมกัน (.so) ซึ่งโหลดผ่าน Java Native Interface (System.loadLibrary) แม้ว่าเฟรมเวิร์กแบบไดนามิกจะช่วยให้สามารถแชร์โค้ดข้ามส่วนขยายแอป iOS ได้ แต่การโหลดเฟรมเวิร์กแบบไดนามิกจำนวนมากตอนเริ่มต้นระบบจะเพิ่มภาระการปรับฐานและการผูกของ dyld ก่อนถึงฟังก์ชัน main()

วิธีที่ระบบบิวด์รวมโค้ด SDK, ทรัพยากร, แมนิเฟสต์ และความสามารถของแอปโฮสต์

ในระหว่างกระบวนการบิวด์ ชุดเครื่องมือโฮสต์จะประมวลผลเมทาเดตาที่บรรจุอยู่ใน SDK ควบคู่ไปกับการกำหนดค่าความปลอดภัยของโปรเจกต์โฮสต์:

• การผสานไฟล์ Android Manifest: ไลบรารี Android .aar ทุกตัวจะมีไฟล์ AndroidManifest.xml ที่ประกาศสิทธิ์หรือคอมโพเนนต์ที่ SDK ต้องการ ในระหว่างการคอมไพล์ด้วย Gradle ระบบ Android Manifest Merger จะรวมโหนดแมนิเฟสต์ของ SDK เข้ากับแมนิเฟสต์ของแอปพลิเคชันโฮสต์ หาก SDK ประกาศสิทธิ์ที่ไม่จำเป็นในแมนิเฟสต์ที่มาพร้อมกัน สิทธิ์เหล่านั้นจะถูกสืบทอดไปยังไฟล์แมนิเฟสต์ที่ผสานขั้นสุดท้าย เว้นแต่จะถูกตัดออกอย่างชัดเจนโดยใช้ tools:node="remove"
• ความสามารถและสิทธิ์ของโฮสต์ iOS: ต่างจากแมนิเฟสต์ของ Android สิทธิ์ของระบบ iOS (เช่น com.apple.developer.associated-domains สำหรับ Universal Links) จะไม่ถูกผสานโดยอัตโนมัติจาก XCFramework ของบุคคลภายนอกเข้าสู่แอปโฮสต์ แต่ Developer ต้องเปิดใช้งานความสามารถที่จำเป็นอย่างชัดเจนบนเป้าหมายแอปพลิเคชันโฮสต์ใน Xcode และลงชื่อไบนารีแอปด้วยโปรไฟล์การจัดเตรียมที่ได้รับอนุญาตจากพอร์ทัล Apple Developer
• การบรรจุอาร์ทิแฟกต์สำหรับการปล่อยตัว: บน Android เมื่อสร้างแอปพลิเคชันโฮสต์เพื่อปล่อยลงสโตร์ Android App Bundle (.aab) จะทำหน้าที่เป็นอาร์ทิแฟกต์สำหรับเผยแพร่แทนที่จะเป็นแพ็กเกจแอปพลิเคชันที่ติดตั้งได้โดยตรง โดย Google Play App Bundle Delivery จะประมวลผลไฟล์ .aab เป็นแพ็กเกจ .apk เฉพาะอุปกรณ์เพื่อส่งมอบให้กับผู้ใช้ ส่วนบน iOS ทาง Xcode จะคอมไพล์และลงชื่อไฟล์ปฏิบัติการและเฟรมเวิร์กที่ฝังอยู่ลงในไฟล์เก็บถาวร .ipa สำหรับการแจกจ่ายผ่าน App Store

กายวิภาคของอาร์ทิแฟกต์ Mobile SDK: เจาะลึกภายในแพ็กเกจ Android AAR และ iOS XCFramework

ภายในไฟล์เก็บถาวร Android AAR: ไบต์โค้ด, แมนิเฟสต์, ทรัพยากร และไลบรารีเนทีฟ

อ้างอิงตาม คู่มือ Google Android Developers เกี่ยวกับกายวิภาคของ Android Archive (AAR) ไฟล์ AndroidManifest.xml เป็นรายการเดียวที่จำเป็นต้องมีในไฟล์เก็บถาวร .aar ส่วนรายการอื่นๆ รวมถึง classes.jar, R.txt, res/, ไลบรารีเนทีฟ .so และ proguard.txt นั้นเป็นทางเลือกและขึ้นอยู่กับการใช้งานของไลบรารี:

• /AndroidManifest.xml (บังคับ): ประกาศเนมสเปซแพ็กเกจของไลบรารี, เวอร์ชัน SDK ขั้นต่ำที่รองรับ (minSdk) รวมถึงสิทธิ์ของระบบหรือการประกาศคอมโพเนนต์ที่จำเป็น
• /classes.jar (ไม่บังคับ): บรรจุไบต์โค้ด Java และ Kotlin ที่คอมไพล์แล้ว (ไฟล์ .class) ซึ่งเปิดเผยคลาส API สาธารณะและตรรกะการทำงานภายในของ SDK
• /res/ และ /R.txt (ไม่บังคับ): บรรจุเลย์เอาต์ UI ที่มาพร้อมกัน, แอสเซท drawable หรือตารางสตริง พร้อมกับการแมัป ID สัญลักษณ์ สำหรับ SDK โครงสร้างพื้นฐานที่ไม่ใช่ภาพ (เช่น ไลบรารีระบุแหล่งที่มาและลิงก์เชิงลึกของมือถือ) การละเว้นทรัพยากร UI จะช่วยป้องกันการขยายตัวของตารางทรัพยากรโดยไม่จำเป็น
• /jni/[abi]/lib*.so (ไม่บังคับ): ไลบรารีเนทีฟ C หรือ C++ ที่คอมไพล์ล่วงหน้าซึ่งกำหนดเป้าหมายไปยัง Application Binary Interface (ABI) ของ CPU เฉพาะ (arm64-v8a, armeabi-v7a, x86_64)
• /proguard.txt (ไม่บังคับ): กฎ ProGuard หรือ R8 สำหรับผู้บริโภค ซึ่งจะสั่งการเครื่องมือย่อขนาดของแอปโฮสต์ว่าคลาส SDK หรืออินเทอร์เฟซคอลแบ็กใดบ้างที่ต้องเก็บรักษาไว้ในระหว่างการย่อขนาดเพื่อปล่อยตัวแอป

ภายในบันเดิล iOS XCFramework: Info.plist, ชิ้นส่วนตัวแปรแพลตฟอร์ม, เฮดเดอร์ และโมดูล

บนแพลตฟอร์มของ Apple การแจกจ่ายไบนารี SDK จำเป็นต้องรองรับทั้งอุปกรณ์ iOS ทางกายภาพ (ARM64) และเครื่องมือพัฒนา macOS ที่รัน iOS Simulator (ARM64 Apple Silicon และ x86_64 Intel) เพื่อรองรับการแจกจ่ายแบบหลายสถาปัตยกรรมโดยไม่มีปัญหาความขัดแย้งของไฟล์ไบนารีขนาดใหญ่ (fat-binary) Apple จึงได้แนะนำข้อกำหนด Apple XCFramework (.xcframework) บิวด์ของ .framework ทั่วไปมักจะกำหนดเป้าหมายไปยังตัวแปรแพลตฟอร์มใดแพลตฟอร์มหนึ่งและอาจมีสถาปัตยกรรม CPU ที่รองรับอย่างน้อยหนึ่งรายการ ในขณะที่บันเดิล .xcframework จะบรรจุตัวแปรแพลตฟอร์มและสถาปัตยกรรมหลายรายการ เช่น ชิ้นส่วนอุปกรณ์ iOS แบบ ARM64 ควบคู่ไปกับชิ้นส่วน iOS Simulator ไว้ในไดเรกทอรีเดียวที่สามารถแจกจ่ายได้:

• Info.plist (แมนิเฟสต์ราก): แสดงรายการไลบรารีทุกตัวที่มีให้ใช้งาน (AvailableLibraries) โดยระบุ SupportedPlatform (ios), SupportedPlatformVariant (simulator เทียบกับอุปกรณ์) และ SupportedArchitectures (arm64, x86_64)
• ios-arm64/ และ ios-arm64_x86_64-simulator/: ไดเรกทอรีย่อยเฉพาะแพลตฟอร์มที่มีไบนารี .framework หรือไลบรารีสถิต .a สำหรับเป้าหมายนั้น ในระหว่างการบิวด์ไฟล์เก็บถาวร Xcode จะเลือกเฉพาะชิ้นส่วนอุปกรณ์จริงและยกเว้นชิ้นส่วนตัวจำลองออกจากไฟล์ .ipa ขั้นสุดท้าย
• Headers/ และ Modules/: ไฟล์เฮดเดอร์ Objective-C .h สาธารณะ (เช่น OpoInstallSDK.h) และไฟล์ Clang module.modulemap ที่เปิดเผยคำจำกัดความประเภทให้กับคอมไพเลอร์ Objective-C และ Swift

# การเปรียบเทียบไดเรกทอรีไบนารีแบบจำลอง: Android .aar เทียบกับ iOS .xcframework
# หมายเหตุ: มีเพียง AndroidManifest.xml เท่านั้นที่จำเป็นใน .aar ส่วนเส้นทางภายใน XCFramework จะแตกต่างกันไปตามผู้จำหน่ายบิวด์

opoinstall-android-sdk.aar                 libOpoInstallSDK.xcframework/
├── AndroidManifest.xml (บังคับ)             ├── Info.plist
├── classes.jar (ไม่บังคับ)                ├── ios-arm64/
│   └── com/opoinstall/api/                │   ├── Headers/
│       ├── OpoInstall.class               │   │   └── OpoInstallSDK.h
│       ├── OpoData.class                  │   └── libOpoInstallSDK.a
│       ├── OpoError.class                 └── ios-arm64_x86_64-simulator/
│       └── ResultCallBack.class               ├── Headers/
└── proguard.txt (ไม่บังคับ)                   │   └── OpoInstallSDK.h
                                               └── libOpoInstallSDK.a

[อาร์ทิแฟกต์ Mobile SDK ของบุคคลภายนอก]
       |
       +---> Android (.aar) ---> [AndroidManifest.xml + classes.jar / proguard.txt ทางเลือก]
       |                                  |
       |                                  v (Gradle Manifest Merger และคอมไพเลอร์ D8/R8 DEX)
       |                         [อาร์ทิแฟกต์เผยแพร่แอปโฮสต์ .aab -> Google Play .apk]
       |
       +---> iOS (.xcframework) -> [ชิ้นส่วนอุปกรณ์ ios-arm64 + ชิ้นส่วน ios-simulator]
                                          |
                                          v (Xcode Linker ตัดชิ้นส่วน Simulator ออก)
                                 [ไฟล์ปฏิบัติการอุปกรณ์แอปโฮสต์ .ipa]

โปรโตคอลการเติบโตทางเทคนิคที่ห่อหุ้มอยู่ภายใน SDK การระบุแหล่งที่มา

ในบทความนี้ “โปรโตคอลการเติบโตทางเทคนิค” หมายถึงชุดของกลไกการกำหนดเส้นทางแบบเนทีฟ ตัวอ้างอิงการติดตั้ง การคืนค่าพารามิเตอร์ และการรายงานเหตุการณ์ ซึ่งมักใช้งานโดย SDK การระบุแหล่งที่มาบนมือถือ แทนที่จะเป็นมาตรฐานทางการเดี่ยวๆ การตรวจสอบกลไกเหล่านี้จะช่วยให้เข้าใจชัดเจนว่าเหตุใดทีมเติบโตจึงลิงก์ไคลเอนต์ SDK เข้ากับไบนารีของตนเอง แทนที่จะพึ่งพาสคริปต์การติดตามบนเว็บเพียงอย่างเดียว

โปรโตคอลที่ 1: การดักจับการกำหนดเส้นทาง URI Scheme และ Universal Link หรือ App Link

เมื่อผู้ใช้แตะลิงก์โปรโมชันบนหน้าเว็บ H5 (https://links.example.com/offer?room_id=402) SDK การเติบโตบนมือถือจะประสานงานการกำหนดเส้นทางภายในแอปโดยตรงสำหรับผู้ใช้ที่มีแอปติดตั้งอยู่แล้ว:

• แฮนด์เชกการตรวจสอบความถูกต้องของระบบ: บน iOS 9 ขึ้นไป Apple Universal Links จะตรวจสอบความเป็นเจ้าของโดเมนผ่านไฟล์ JSON apple-app-site-association (AASA) ที่โฮสต์ด้วย HTTPS ซึ่งเชื่อมโยงกับสิทธิ์ applinks: ของแอปโฮสต์ ส่วนบน Android Android App Links ที่ผ่านการตรวจสอบจะใช้ android:autoVerify="true" บน <intent-filter> ที่ประกาศทั้งสคีม http และ https ควบคู่ไปกับ android:host ที่เป็นเป้าหมาย โดยตรวจสอบเทียบกับไฟล์ Digital Asset Links /.well-known/assetlinks.json ที่โฮสต์ไว้ ซึ่งมีชื่อแพ็กเกจของแอปและลายนิ้วมือใบรับรองการลงชื่อ SHA-256
• การดักจับวงจรชีวิต: เมื่อ OSปลุกแอปพลิเคชันผ่านลิงก์ที่ตรวจสอบแล้วหรือสคีม URI แบบกำหนดเองสำรอง (scheme://) ตาม IETF RFC 3986 SDK แบบเนทีฟจะดักจับ Intent ที่เข้ามา (ผ่าน onCreate หรือ onNewIntent บน Android) หรือ NSUserActivity / UIOpenURLContext (ผ่าน UISceneDelegate ในแอป iOS ยุคใหม่ที่ใช้ฉาก หรือเมธอดการจัดการ URL ของ UIApplicationDelegate แบบเดิม ซึ่ง Apple ระบุว่าเลิกใช้งานแล้วสำหรับแอปที่เปิดใช้งานฉาก) แยกวิเคราะห์เพย์โหลดคิวรี และส่งมอบพารามิเตอร์การกำหนดเส้นทางไปยังแอปโฮสต์

โปรโตคอลที่ 2: การผูก IPC ตัวอ้างอิงการติดตั้งจากสโตร์

เมื่อแอปพลิเคชันยังไม่ได้ติดตั้งและผู้ใช้ดาวน์โหลดจาก Google Play Store คุกกี้ของเบราว์เซอร์จะไม่สามารถข้ามแซนด์บ็อกซ์ของ Android OS ไปยังแอปที่ติดตั้งใหม่ได้ เพื่อเชื่อมช่องว่างนี้อย่างแม่นยำบน Android ไคลเอนต์ SDK จึงใช้กลไกการสื่อสารระหว่างกระบวนการ (Inter-Process Communication - IPC) โดยใช้ Google Play Install Referrer API อย่างเป็นทางการ

ในการเปิดใช้งานครั้งแรก SDK จะผูกเข้ากับบริการ Google Play Store ผ่านอินเทอร์เฟซ IPC Binder ของ Android และอ่านสตริง install_referrer พร้อมกับประทับเวลาการคลิกและการเริ่มติดตั้ง เนื่องจาก Google Play Install Referrer API นำไปใช้เฉพาะกับโฟลว์การติดตั้ง Google Play Store ที่มีสิทธิ์ การแจกจ่าย Android นอก Google Play จึงใช้การจับคู่พารามิเตอร์ H5 ฝั่งเซิร์ฟเวอร์หรือแพ็กเกจช่องทาง Android ที่ส่งออก (ไฟล์ APK ที่มีเมทาเดตา channelCode ฝังอยู่)

โปรโตคอลที่ 3: การคืนค่าพารามิเตอร์แบบอะซิงโครนัสและการแฮนด์เชกการปรับเทียบเซสชัน

สำหรับการเดินทางจากเว็บสู่แอปข้ามแพลตฟอร์ม (รวมถึงการติดตั้ง App Store บน iOS ซึ่ง Apple ไม่มีระบบส่งผ่านพารามิเตอร์คิวรี URL ทั่วไปที่เทียบเท่ากับ Install Referrer ของ Google Play) ไคลเอนต์ SDK จะดำเนินการแฮนด์เชกการคืนค่าพารามิเตอร์แบบอะซิงโครนัสผ่าน HTTPS ตาม IETF RFC 9110:

1. การอัปโหลดบริบทเว็บก่อนการติดตั้ง: เมื่อผู้ใช้เข้าชมหน้าแชร์ H5 เว็บ JS SDK ที่รวมอยู่จะวิเคราะห์พารามิเตอร์กำหนดเองที่ต่อท้าย URL (เช่น รหัสผู้เชิญหรือ channelCode) และอัปโหลดบันทึกเซสชันก่อนการติดตั้งไปยังเซิร์ฟเวอร์ระบุแหล่งที่มา
2. การแฮนด์เชกไคลเอนต์หลังการติดตั้ง: เมื่อผู้ใช้เปิดแอปที่ติดตั้งใหม่ ไคลเอนต์ SDK จะเริ่มต้นและสื่อสารกับเซิร์ฟเวอร์ระบุแหล่งที่มาผ่าน HTTPS โดยระบุแอปพลิเคชันที่ลงทะเบียนผ่านผู้เช่า AppKey และใช้กลไกการตรวจสอบความถูกต้องหรือการยืนยันตัวตนเพิ่มเติมที่ผู้จำหน่ายกำหนด จากนั้นเซิร์ฟเวอร์จะพยายามคืนค่าพารามิเตอร์กำหนดเองที่แคชไว้ (data) และตัวระบุช่องทาง (channelCode) ไม่ควรปฏิบัติกับ AppKey ที่ฝังอยู่ว่าเป็นความลับในการยืนยันตัวตนแบบสแตนด์อโลน
3. กลไกของผู้จำหน่ายเทียบกับขอบเขตความเป็นส่วนตัวของแพลตฟอร์ม: เอกสารผลิตภัณฑ์สาธารณะของ OpoInstall อธิบายถึงเวิร์กฟิลด์ช่องทาง H5 และการติดตั้งพารามิเตอร์ ซึ่งเว็บ SDK จะรวบรวมลายนิ้วมืออุปกรณ์และรหัสช่องทางบนหน้า H5 และ SDK เนทีฟของ Android/iOS จะรวบรวมลายนิ้วมืออุปกรณ์อีกครั้งเมื่อเปิดใช้งานครั้งแรกเพื่อจับคู่แหล่งที่มาของการติดตั้ง ภายใต้ แนวทางปฏิบัติด้านความเป็นส่วนตัวของผู้ใช้และการใช้ข้อมูลของ Apple Apple ห้ามอย่างชัดเจนในการดึงข้อมูลจากอุปกรณ์เพื่อระบุตัวตนผู้ใช้หรืออุปกรณ์ที่ไม่ซ้ำกัน (การทำลายนิ้วมืออุปกรณ์หรือ fingerprinting) และแอปที่อ้างอิงถึง SDK ของบุคคลภายนอกที่มีการทำลายนิ้วมืออุปกรณ์ต้องห้ามมีความเสี่ยงที่จะถูกปฏิเสธจาก App Store นอกจากนี้ จำเป็นต้องได้รับอนุญาตจากความโปร่งใสในการติดตามแอป (ATT) เมื่อบริการลิงก์เชิงลึกหรือลิงก์เชิงลึกแบบเลื่อนเวลาของบุคคลภายนอกส่งตัวระบุที่ไม่ซ้ำกันหรือสร้างตัวตนผู้ใช้ร่วมกันข้ามแอปจากบริษัทต่างๆ เพื่อการกำหนดเป้าหมายโฆษณา การวัดผลโฆษณา หรือการแบ่งปันกับโบรกเกอร์ข้อมูล และความยินยอมของ ATT ไม่ได้ทำให้การทำลายนิ้วมืออุปกรณ์ต้องห้ามเป็นสิ่งที่อนุญาต หากผู้จำหน่ายไม่สามารถพิสูจน์ได้ว่ากลไกการจับคู่บน iOS หลีกเลี่ยงการทำลายนิ้วมืออุปกรณ์ต้องห้าม นักพัฒนาไม่ควรปรับใช้กลไกการระบุแหล่งที่มานั้นบน iOS จนกว่าจะมีทางเลือกอื่นที่ปฏิบัติตามข้อกำหนดได้รับการตรวจสอบอิสระแล้ว

โปรโตคอลที่ 4: เทเลเมทรีของเหตุการณ์การแปลงและช่องทางที่มีการตัดความซ้ำซ้อน

เมื่อแก้ไขแหล่งที่มาของการติดตั้งได้แล้ว SDK จะมีอินเทอร์เฟซการรายงานเหตุการณ์แบบอะซิงโครนัส ด้วยการตัดความซ้ำซ้อนของรายงานการติดตั้งและการลงทะเบียนฝั่งแอป และอนุญาตให้นักพัฒนา9รายงาน “จุดผล” การแปลงกำหนดเอง (saveEvent / reportEffectPoint) หรือการกระทำแชร์ไวรัล (reportShare พร้อม shareCode) SDK จึงสนับสนุนการวิเคราะห์ประสิทธิภาพช่องทางโดยไม่ต้องมีคิวลองใหม่แบบกำหนดเอง ข้อมูลจำเพาะโดยละเอียดและคำจำกัดความ API มีอยู่ใน เอกสารทางเทคนิคของ OpoInstall

การตรวจสอบรอยเท้าไบนารีของ SDK และส่วนพึ่งพาแบบทรานสิทิฟ

ทำไมขนาดของ SDK จึงสำคัญต่อวิศวกรรมมือถือและการได้มาซึ่งผู้ใช้

แพ็กเกจแอปพลิเคชันที่มีขนาดใหญ่อาจเพิ่มเวลาในการดาวน์โหลดและข้อกำหนดด้านพื้นที่จัดเก็บ ซึ่งอาจส่งผลต่ออัตราความสำเร็จในการติดตั้งในสภาพแวดล้อมเครือข่ายหรืออุปกรณ์ที่มีข้อจำกัด ตามที่ระบุไว้ในคำแนะนำ การลดขนาดแอปของคุณ (App Thinning) ของ Apple ผลกระทบของ SDK บุคคลภายนอกใดๆ ควรได้รับการวัดผลผ่านการวัดขนาดบิวด์เชิงประจักษ์และเมตริกช่องทางที่สังเกตได้ แทนที่จะคาดเดาจากขนาดแพ็กเกจเพียงอย่างเดียว

ต้นทุนที่ซ่อนอยู่ของส่วนพึ่งพาแบบทรานสิทิฟ: ขีดจำกัดการอ้างอิงเมธอดและความขัดแย้งของไลบรารี

สาเหตุหลักของขนาด SDK ที่บวมและความไม่เสถียรของการบิวด์แทบจะไม่ใช่ตรรกะการระบุแหล่งที่มาหลักของ SDK แต่เป็น ส่วนพึ่งพาแบบทรานสิทิฟ (Transitive Dependencies) ซึ่งเป็นไลบรารีโอเพนซอร์สภายนอกที่ SDK ดึงเข้ามาในโปรเจกต์โฮสต์โดยอัตโนมัติผ่าน Gradle หรือ CocoaPods:

• ความขัดแย้งของเวอร์ชันส่วนพึ่งพา: หาก SDK ของบุคคลภายนอกประกาศส่วนพึ่งพาแบบทรานสิทิฟไปยังไลบรารีเครือข่ายหรือการ serialization ทั่วไปเวอร์ชันใดเวอร์ชันหนึ่ง (เช่น OkHttp, Gson, Retrofit หรือ Protobuf) และแอปพลิเคชันโฮสต์ใช้ไลบรารีเวอร์ชันหลักที่เข้ากันไม่ได้ การบิวด์อาจล้มเหลวด้วยข้อผิดพลาดคลาสซ้ำหรือแครชรันไทม์ด้วยข้อยกเว้น NoSuchMethodError
• ภาระการอ้างอิงเมธอด DEX: บน Android ไฟล์ .dex แต่ละไฟล์จะถูกจำกัดไว้ที่ 65,536 การอ้างอิงเมธอด ตาม คู่มือทางเทคนิค Android Multidex นี่คือขีดจำกัดการอ้างอิงต่อไฟล์ DEX มากกว่าขีดจำกัดเมธอดของแอปพลิเคชันทั้งหมด multidex อนุญาตให้แอปพลิเคชันบรรจุการอ้างอิงข้ามไฟล์ DEX หลายไฟล์ แม้ว่าการดึงต้นไม้ส่วนพึ่งพาแบบทรานสิทิฟขนาดใหญ่จะยังคงเพิ่มจำนวนไฟล์ DEX, เวลาในการคอมไพล์ R8 และขนาด APK สุดท้าย
• พื้นผิวความปลอดภัยของห่วงโซ่อุปทาน: ภายใต้มาตรฐาน โครงการความปลอดภัยแอปพลิเคชันมือถือ OWASP ไลบรารีทรานสิทิฟทุกตัวที่ดึงเข้ามาโดย SDK จะขยายพื้นผิวการโจมตีห่วงโซ่อุปทานซอฟต์แวร์ของแอปพลิเคชัน และต้องมีการตรวจสอบช่องโหว่อย่างต่อเนื่อง

ดังนั้น SDK การระบุแหล่งที่มาแบบมินิมอลควรหลีกเลี่ยงส่วนพึ่งพาแบบทรานสิทิฟภายนอกที่ไม่จำเป็น โดยพึ่งพาระบบเครือข่ายที่มีอยู่ในตัวระบบปฏิบัติการมือถือ (HttpURLConnection / NSURLSession) และตัวแยกวิเคราะห์ JSON แบบเนทีฟ (org.json / NSJSONSerialization) แทน

การตรวจสอบผลกระทบของไบนารีจริงโดยใช้ Android Studio APK Analyzer และรายงาน App Thinning ของ Xcode

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

• ต้นไม้ส่วนพึ่งพาของ Android และ APK Analyzer: รันงาน dependency ของ Gradle เพื่อตรวจสอบว่า SDK ดึงไลบรารีทรานสิทิฟเข้ามาหรือไม่ และใช้ คู่มือ Google Android Developers อย่างเป็นทางการเกี่ยวกับ APK Analyzer (CLI apkanalyzer หรือ GUI ของ Android Studio) เพื่อรัน apk compare สำหรับความแตกต่างของขนาดไฟล์ รัน dex references บนทั้งสองบิวด์เพื่อเปรียบเทียบจำนวนการอ้างอิงเมธอด และรัน apk download-size เพื่อประเมินผลกระทบต่อขนาดการดาวน์โหลด
• การเปรียบเทียบพื้นฐานของ iOS ผ่านรายงานขนาด App Thinning: เนื่องจากไฟล์เก็บถาวร .xcframework มีทั้งชิ้นส่วนอุปกรณ์จริงและตัวจำลอง ขนาดโฟลเดอร์ดิบจึงไม่เท่ากับสิ่งที่ผู้ใช้ปลายทางดาวน์โหลด สร้างรายงานขนาด App Thinning ใน Xcode Organizer สำหรับทั้งบิวด์พื้นฐาน (ไม่มี SDK) และบิวด์ที่รวม SDK โดยใช้การตั้งค่าการปล่อยตัวที่เหมือนกัน เปรียบเทียบขนาดที่บีบอัดและไม่ได้บีบอัดสำหรับตัวแปรอุปกรณ์เดียวกัน ($\Delta S = S_{\text{with SDK}} - S_{\text{baseline}}$) เพื่อประเมินรอยเท้าเพิ่มเติมนอกเหนือจาก SDK และตรวจสอบขนาดการแจกจ่ายขั้นสุดท้ายใน App Store Connect

คำสั่ง CLI ต่อไปนี้แสดงวิธีตรวจสอบส่วนพึ่งพาแบบทรานสิทิฟ, เดลตาขนาด APK และชิ้นส่วน XCFramework (โปรดสังเกตว่าเส้นทาง xcrun lipo ด้านล่างเป็นเพียงภาพประกอบ ควรอ่านไฟล์ Info.plist และตัวแปรไลบรารีที่เลือกภายใน .xcframework ทุกครั้งก่อนสร้างคำสั่ง lipo):

# 1. Android: ตรวจสอบส่วนพึ่งพารันไทม์ของการปล่อยตัวเพื่อยืนยันว่าไม่มีไลบรารีทรานสิทิฟที่ไม่ต้องการ
./gradlew :app:dependencies --configuration releaseRuntimeClasspath

# 2. Android: ตรวจสอบจำนวนการอ้างอิงเมธอด DEX ใน APK พื้นฐานและ APK ที่รวม SDK
apkanalyzer dex references baseline-release.apk
apkanalyzer dex references with-sdk-release.apk

# 3. Android: ตรวจสอบขนาดไฟล์ APK ดิบและขนาดดาวน์โหลดทางอากาศที่ประเมินไว้
apkanalyzer apk file-size with-sdk-release.apk
apkanalyzer apk download-size with-sdk-release.apk

# 4. Android: เปรียบเทียบ APK พื้นฐาน (ไม่มี SDK) กับ APK ที่รวม SDK แล้ว
apkanalyzer apk compare baseline-release.apk with-sdk-release.apk

# 5. iOS: ตรวจสอบแพลตฟอร์มและตัวแปรสถาปัตยกรรมที่รองรับใน plist รากของ XCFramework
plutil -p libOpoInstallSDK.xcframework/Info.plist

# 6. iOS: การตรวจสอบ lipo แบบจำลองบนชิ้นส่วนไบนารีอุปกรณ์เฉพาะหลังจากตรวจสอบ Info.plist แล้ว
xcrun lipo -info libOpoInstallSDK.xcframework/ios-arm64/libOpoInstallSDK.a

เมทริกซ์การประเมินสถาปัตยกรรมและรอยเท้าไบนารีของ Mobile SDK

การเปรียบเทียบ SDK ขนาดใหญ่แบบโมโนลิธิกกับ SDK การระบุแหล่งที่มาแบบมินิมอล

เมื่อดำเนินการตรวจสอบทางสถาปัตยกรรมของ SDK มือถือภายนอก ผู้นำทางวิศวกรรมสามารถประเมินผู้สมัครตามมิติโครงสร้าง 5 มิติต่อไปนี้:

เมื่อใดที่ทีมวิศวกรรมจึงต้องการ SDK การเติบโตเฉพาะทาง

สถานการณ์ที่ SDK การระบุแหล่งที่มาแบบน้ำหนักเบามีความชอบธรรมทางสถาปัตยกรรม

การบูรณาการ SDK การระบุแหล่งที่มาและลิงก์เชิงลึกบนมือถือเฉพาะทางจะเหมาะสมภายใต้เงื่อนไขเหล่านี้:

• การคืนค่าพารามิเตอร์ข้ามแซนด์บ็อกซ์: ช่องทางการได้มาซึ่งผู้ใช้ของคุณนำทางผู้ใช้จากหน้าเว็บ H5 การแชร์โซเชียล หรือรหัส QR ผ่าน App Store หรือ Google Play และจำเป็นต้องคืนค่าพารามิเตอร์กำหนดเอง (เช่น รหัสแนะนำหรือรหัสห้อง) เมื่อเปิดใช้งานครั้งแรกโดยไม่ต้องป้อนโค้ดด้วยตนเอง
• การบำรุงรักษาการกำหนดเส้นทางลิงก์เชิงลึกแบบรวม: ทีมของคุณต้องการอินเทอร์เฟซคอลแบ็กไคลเอนต์ตัวเดียวเพื่อจัดการ Universal Links, Android App Links และสคีม URL กำหนดเองสำรองข้ามเบราว์เซอร์มือถือและ WebView โซเชียลในแอปที่หลากหลาย
• การติดตามแพ็กเกจ H5 และ APK หลายช่องทาง: การดำเนินงานด้านการตลาดของคุณกระจายแคมเปญข้ามลิงก์ช่องทาง H5 และแพ็กเกจช่องทาง Android และจำเป็นต้องมีการรายงานการติดตั้ง การลงทะเบียน และเหตุการณ์การแปลงแบบรวมศูนย์

สถานการณ์ที่ควรหลีกเลี่ยงการเพิ่ม Mobile SDK อื่น

ในทางกลับกัน ควรหลีกเลี่ยงการเพิ่มไคลเอนต์ SDK ของบุคคลภายนอกในสถานการณ์ต่อไปนี้:

• ความสามารถของไคลเอนต์ที่ซ้ำซ้อน: หาก SDK ที่เสนอมาทำซ้ำฟังก์ชันการทำงานที่แอปพลิเคชันของคุณใช้งานไว้อย่างสะอาดเรียบร้อยอยู่แล้วโดยใช้ API ระบบปฏิบัติการเนทีฟหรือไลบรารีหลักที่มีอยู่
• สถานะความเป็นส่วนตัวหรือการปฏิบัติตามข้อกำหนดที่ยังไม่ได้ตรวจสอบ: หาก SDK พึ่งพาสัญญาณการจับแมตช์อุปกรณ์ (เช่น การทำลายนิ้วมืออุปกรณ์ต้องห้ามบน iOS) ซึ่งไม่สามารถตรวจสอบอย่างอิสระว่าสอดคล้องกับแนวทางปฏิบัติในการตรวจสอบ App Store และกฎหมายคุ้มครองข้อมูลระดับภูมิภาคปัจจุบัน
• เวิร์กโฟลว์การวิเคราะห์ฝั่งแบ็กเซิร์ฟเวอร์ล้วนๆ: หากเหตุการณ์ที่คุณต้องติดตามเกิดขึ้นทั้งหมดบนเซิร์ฟเวอร์แบ็กเซิร์ฟเวอร์ที่ผ่านการตรวจสอบความถูกต้องแล้ว (เช่น การต่ออายุสมาชิกแบบ périodique) ซึ่ง API แบบ Server-to-Server (S2S) โดยตรงสามารถหลีกเลี่ยงรอยเท้าไบนารีของไคลเอนต์ได้ทั้งหมด

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

• ความเข้าใจผิดที่ 1: ขนาดไฟล์ซิป SDK ที่ดาวน์โหลดเท่ากับการเพิ่มขึ้นของขนาดแอป: ไฟล์เก็บถาวร .xcframework หรือ .aar ที่ดาวน์โหลดมาจะรวมชิ้นส่วนตัวจำลอง, ไฟล์เฮดเดอร์ และเมทาเดตาที่ยังไม่ได้บีบอัด ซึ่งจะถูกตัดออกโดย App Thinning ของ Xcode และ Android R8 ในระหว่างการคอมไพล์เพื่อปล่อยตัวแอป ควรวัดเดลตาเพิ่มเติมนเสมอ ($\Delta S$) ระหว่างบิวด์การปล่อยตัวพื้นฐานและบิวด์การปล่อยตัวที่รวม SDK
• ความเข้าใจผิดที่ 2: การไม่มีส่วนพึ่งพาแบบทรานสิทิฟหมายถึงการไม่ต้องตรวจสอบความเป็นส่วนตัว: แม้แต่ SDK ที่บรรจุในตัวเองและใช้ไลบรารีโอเพนซอร์สของบุคคลภายนอกเป็นศูนย์ ก็ยังคงทำงานภายในขอบเขตความเป็นส่วนตัวของแอปพลิเคชันของคุณ ทีมวิศวกรรมต้องตรวจสอบคำขอเครือข่าย การประกาศ plist และสัญญาณอุปกรณ์ทุกรายการที่รวบรวมโดย SDK ก่อนการปล่อยตัว

สรุปและรายการตรวจสอบการประเมินไบนารี

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

ก่อนอนุมัติ Mobile SDK ของบุคคลภายนอกสำหรับการปล่อยตัวจริง ผู้นำทางวิศวกรรมควรปฏิบัติตามรายการตรวจสอบการตรวจสอบไบนารีและการปฏิบัติตามข้อกำหนดนี้:

• ตรวจสอบต้นไม้ส่วนพึ่งพา: รัน ./gradlew :app:dependencies --configuration releaseRuntimeClasspath หรือตรวจสอบ Podfile.lock เพื่อยืนยันว่า SDK นำไลบรารีทรานสิทิฟที่ขัดแย้งกันเข้ามาหรือไม่

• วัดขนาดหลังการคอมไพล์ที่เพิ่มขึ้น ($\\Delta S$): เปรียบเทียบบิวด์การปล่อยตัวพื้นฐานกับการปล่อยตัวที่รวม SDK (ทดสอบกับไฟล์เก็บถาวรที่ดาวน์โหลดมาปัจจุบัน เช่น v2.1.0) โดยใช้ apkanalyzer apk compare บน Android และรายงานขนาด App Thinning แบบเปรียบเทียบพื้นฐานกับที่รวม SDK บน iOS

• ตรวจสอบลายเซ็น API และการคลีนบิวด์: ยืนยันการนำเข้าแพ็กเกจทั้งหมด ตัวกรองแมนิเฟสต์ (สคีม http และ https สำหรับ Android App Links) และคอลแบ็กรอบชีวิต (UISceneDelegate เทียบกับเมธอด URL ของ AppDelegate ที่เลิกใช้งานแล้ว) ในสภาพแวดล้อมการสร้างที่สะอาด

• ตรวจสอบโปรโตคอลและการปฏิบัติตามข้อกำหนดความเป็นส่วนตัว: ยืนยันกับผู้จำหน่ายว่าสิทธิ์ลิงก์เชิงลึก การผูกตัวอ้างอิงการติดตั้ง และสัญญาณการจับคู่ฝั่งเซิร์ฟเวอร์ทั้งหมดหลีกเลี่ยงการทำลายนิ้วมืออุปกรณ์ต้องห้าม และปฏิบัติตามแนวทางความเป็นส่วนตัวของผู้ใช้ Apple และนโยบาย Google Play ปัจจุบัน

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

วัสดุที่เกี่ยวข้อง

• แนวคิด: ความหมายของชุดเครื่องมือพัฒนาซอฟต์แวร์, รอยเท้าไบนารี, ส่วนพึ่งพาแบบทรานสิทิฟ, โปรโตคอลการเติบโตทางเทคนิค

• เทคโนโลยี: Android Archive (.aar), Apple XCFramework (.xcframework), Android Studio APK Analyzer, Xcode App Thinning

• มาตรฐาน: IETF RFC 9110 HTTP Semantics, IETF RFC 3986 URI Generic Syntax, OWASP Mobile Application Security Project

• อินเทอร์เฟซแพลตฟอร์มและการบูรณาการ: Gradle Dependency Management, Android D8/R8 Compiler, Xcode Linker, Google Play Install Referrer API, Apple Universal Links

• เอกสารและข้อมูลอ้างอิงอย่างเป็นทางการ:

  • คู่มือ Google Android Developers เกี่ยวกับกายวิภาคของ Android Archive (AAR)

  • คู่มือ Google Android Developers เกี่ยวกับ APK Analyzer CLI

  • คู่มือ Google Android Developers เกี่ยวกับการย่อขนาดและเพิ่มประสิทธิภาพโค้ด (D8/R8)

  • คู่มือ Google Android Developers เกี่ยวกับ Multidex

  • คู่มือ Google Android Developers เกี่ยวกับ App Bundles

  • คู่มือ Google Android Developers เกี่ยวกับ App Links

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

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

  • เอกสารสำหรับนักพัฒนา Apple เกี่ยวกับการลดขนาดแอปของคุณ (App Thinning)

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

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