การเชื่อมต่อหลุด — สาเหตุทั่วไปและวิธีการแก้ไข

“การเชื่อมต่อหลุด” ในแอปมือถือหมายความว่าอย่างไร?

การเชื่อมต่อหลุด — คำที่ผู้ใช้ใช้อธิบายสถานการณ์เมื่อแอปสูญเสียการเชื่อมต่อกับเซิร์ฟเวอร์ หยุดตอบสนองต่อการกระทำ หรือสิ้นสุดด้วยข้อผิดพลาด ในทางเทคนิคอาจเป็น: ข้อผิดพลาดเครือข่าย (หมดเวลา, DNS ล้มเหลว), ANR (เธรด UI ค้าง), แครช (ข้อยกเว้นที่ไม่ได้รับการจัดการ) หรือ เรซคอนดิชัน (race condition)

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

ตาม Crittercism (ปัจจุบันคือ Apteligent) โดยเฉลี่ยแอปมือถือสูญเสียผู้ใช้ 1-2% ทุกครั้งที่แครช สำหรับแอปที่มีผู้ใช้ 1 ล้านคน นั่นหมายถึงการสูญเสียการติดตั้ง 10-20 พันครั้งต่อหนึ่งบัก โดยเฉพาะอย่างยิ่งสำคัญสำหรับแอปในภาคการเงินและการแพทย์

สาเหตุหลักของการสูญเสียการเชื่อมต่อ

เครือข่ายไม่เสถียร — อุปกรณ์มือถือสลับระหว่าง Wi-Fi และเครือข่ายมือถืออยู่ตลอดเวลา เข้าสู่พื้นที่ไม่มีสัญญาณ (รถไฟใต้ดิน ลิฟต์ ห้องใต้ดิน) การสลับแต่ละครั้งทำให้เกิดการสูญเสียการเชื่อมต่อชั่วคราวที่แอปต้องจัดการอย่างถูกต้อง

การหมดเวลา — หากเซิร์ฟเวอร์ไม่ตอบสนองภายในระยะเวลาที่กำหนด (ปกติ 10-30 วินาที) ไคลเอนต์จะโยน SocketTimeoutException การหมดเวลาที่ยาวนานโดยไม่มีการตอบกลับจะถูกรับรู้โดยผู้ใช้ว่าเป็นการค้าง แนะนำให้ตั้งค่าการหมดเวลาไม่เกิน 15 วินาที

val client = OkHttpClient.Builder()
    .connectTimeout(10, TimeUnit.SECONDS)
    .readTimeout(15, TimeUnit.SECONDS)
    .writeTimeout(15, TimeUnit.SECONDS)
    .retryOnConnectionFailure(true)
    .build()

เรซคอนดิชัน (race condition) — เกิดขึ้นเมื่อหลายเธรดอ่านและเขียนข้อมูลเดียวกันพร้อมกันโดยไม่มีการซิงค์โครไนซ์ ตัวอย่างเช่น การโหลดข้อมูลจากแคชในเธรด UI พร้อมกับการอัปเดตแคชจากเครือข่ายอาจนำไปสู่การแสดงข้อมูลที่ล้าสมัยหรือไม่ถูกต้อง

• ข้อยกเว้นที่ไม่ได้รับการจัดการในคอลแบ็กหรือโคโรทีนทำให้แอปแครช
• แรงกดดันหน่วยความจำ — ระบบฆ่าแอปเมื่อมีหน่วยความจำไม่เพียงพอสำหรับแอปพื้นหน้า
• เรซวงจรชีวิต — การทำงานแบบอะซิงก์เสร็จสมบูรณ์หลังจาก Activity/Fragment ถูกทำลาย
• การบล็อก UI — การดำเนินการเครือข่ายหรือฐานข้อมูลบนเธรดหลักทำให้ ANR หลังจาก 5 วินาที

สถาปัตยกรรมสำหรับแอปพลิเคชันที่ทนทานต่อข้อผิดพลาด

Offline-first — รูปแบบสถาปัตยกรรมที่พื้นที่จัดเก็บในเครื่อง (Room, CoreData) เป็นแหล่งความจริงเพียงแหล่งเดียว เครือข่ายใช้สำหรับซิงค์ข้อมูลในพื้นหลัง ผู้ใช้เห็นข้อมูลล่าสุดจากแคชในเครื่องเสมอ แม้ไม่มีเครือข่าย

รูปแบบ Repository — จุดเข้าเดียวสำหรับข้อมูลที่ตัดสินใจว่าจะดึงข้อมูลจากเครือข่ายหรือจากแคช Repository แยกแหล่งข้อมูลออกจาก ViewModel และ UI เมื่อเกิดข้อผิดพลาดเครือข่าย Repository จะสลับไปยังแหล่งในเครื่องโดยอัตโนมัติ

class UserRepository(
    private val api: UserApi,
    private val dao: UserDao
) {
    suspend fun getUsers(): Result<List<User>> {
        return try {
            val remote = api.fetchUsers()
            dao.insertAll(remote)
            Result.success(remote)
        } catch (e: IOException) {
            val cached = dao.getAll()
            if (cached.isNotEmpty()) {
                Result.success(cached) // return cache on network error
            } else {
                Result.failure(e)
            }
        }
    }
}

เซอร์กิตเบรกเกอร์ (Circuit Breaker) — รูปแบบที่ปกป้องเซิร์ฟเวอร์จากคำขอจำนวนมากเมื่อไม่พร้อมใช้งาน หลังจากข้อผิดพลาดติดต่อกัน N ครั้ง เซอร์กิตเบรกเกอร์จะเปิด และคำขอทั้งหมดจะส่งคืนข้อผิดพลาดทันทีโดยไม่พยายามเชื่อมต่อ หลังจากหมดเวลาที่กำหนด เซอร์กิตเบรกเกอร์จะเปลี่ยนเป็นสถานะเปิดครึ่งสำหรับคำขอทดสอบ

วิธีจัดการกับข้อผิดพลาดเครือข่าย?

แบ็กออฟแบบเอกซ์โปเนนเชียล (Exponential backoff) — กลไกการลองใหม่มาตรฐาน หลังจากล้มเหลวครั้งแรก รอ 1 วินาที หลังจากครั้งที่สอง รอ 2 วินาที จากนั้น 4, 8, 16 จำกัดจำนวนการลองสูงสุด (ปกติ 3-5) เพื่อไม่ให้เซิร์ฟเวอร์และแบตเตอรีทำงานหนักเกินไป

การตอบกลับผู้ใช้ — เมื่อเกิดข้อผิดพลาดเครือข่าย ให้แสดงข้อความที่ชัดเจน: “ไม่มีการเชื่อมต่อ”, “เซิร์ฟเวอร์ไม่พร้อมใช้งานชั่วคราว”, “ตรวจสอบอินเทอร์เน็ตของคุณ” ใช้ Snackbar หรือ Inline State View ห้ามแสดงข้อผิดพลาดทางเทคนิค (HTTP 500, SocketException) ให้ผู้ใช้เด็ดขาด

ConnectivityManager — Android API สำหรับตรวจสอบเครือข่าย ปล่อยให้แอปตอบสนองต่อการเปลี่ยนแปลง: แสดงตัวยึดตำแหน่งเมื่อสูญเสียการเชื่อมต่อ อัปเดตข้อมูลโดยอัตโนมัติเมื่อกู้คืน ใน iOS ให้ใช้ NWPathMonitor จากเฟรมเวิร์ก Network

class NetworkMonitor(private val context: Context) {
    private val manager =
        context.getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager

    fun isOnline(): Boolean {
        val network = manager.activeNetwork ?: return false
        val caps = manager.getNetworkCapabilities(network) ?: return false
        return caps.hasCapability(NetworkCapabilities.NET_CAPABILITY_INTERNET)
    }
}

เครื่องมือตรวจสอบและการบันทึก

Crashlytics (Firebase) — เครื่องมือรายงานแครชมาตรฐานสำหรับแอปมือถือ มันรวบรวมสแต็กเทรซของข้อยกเว้นที่ไม่ได้รับการจัดการทั้งหมด เวอร์ชันระบบปฏิบัติการ รุ่นอุปกรณ์ และเวลาแครช มันช่วยให้จัดกลุ่มข้อผิดพลาดและกำหนดผู้รับผิดชอบในการแก้ไข

Sentry — ทางเลือกแทน Crashlytics ที่รองรับการตรวจสอบประสิทธิภาพ มันช่วยให้ติดตามธุรกรรมเฉพาะ (เช่น “การอนุญาตผู้ใช้”) และดูว่าขั้นตอนใดเกิดข้อผิดพลาด การติดตามประสิทธิภาพ ช่วยแยกแยะการหมดเวลาเครือข่ายจากบักในตรรกะของแอป

Timber — ไลบรารีการบันทึกสำหรับ Android ที่เพิ่มแท็กโดยอัตโนมัติตามคลาส ในบิลด์ดีบัก ให้บันทึกคำขอและการตอบกลับเครือข่ายทั้งหมด ในบิลด์รีลีส ให้บันทึกเฉพาะข้อผิดพลาดและคำเตือนผ่าน Crashlytics.setCustomLog

ตาม Firebase Summit 2023 แอปที่ใช้ Crashlytics + Performance Monitoring ลดเวลาเฉลี่ยในการตรวจจับและแก้ไขบักวิกฤตจาก 3 วันเหลือ 4 ชั่วโมง แนะนำให้ตั้งค่าการแจ้งเตือนสำหรับทุกแครชที่มีความถี่มากกว่า 0.1% ของผู้ใช้ที่ใช้งาน