EventBus: คืออะไร หลักการทำงาน และบัสเหตุการณ์ Android

EventBus คืออะไร?

EventBus คือไลบรารีบัสเหตุการณ์สำหรับ Android ที่ใช้รูปแบบ Publisher-Subscriber ช่วยให้สามารถส่งเหตุการณ์ระหว่างคอมโพเนนต์ของแอปพลิเคชัน (Activity, Fragment, Service, ViewModel) โดยไม่ต้องสร้างการพึ่งพาที่ชัดเจนระหว่างกัน ต่างจากกลไกมาตรฐานของ Android (Intent, BroadcastReceiver) EventBus ทำงานภายในโพรเซสและไม่ใช้ IPC ไลบรารีได้รับการปรับให้เหมาะสมกับประสิทธิภาพและไม่ใช้รีเฟลกชันเมื่อกำหนดค่า Subscriber Index อย่างถูกต้อง

GreenRobot EventBus: สถาปัตยกรรม

สถาปัตยกรรม EventBus ประกอบด้วยสามองค์ประกอบหลัก: Event (คลาส POJO ที่มีข้อมูล), Subscriber (ออบเจกต์ที่มีเมธอดที่ใส่คำอธิบายประกอบ @Subscribe) และ EventBus (ตัวกระจายกลาง) สมาชิกลงทะเบียนผ่าน EventBus.getDefault().register(this) และยกเลิกการลงทะเบียนผ่าน unregister(this) เหตุการณ์ถูกกำหนดประเภท: ตัวจัดการสมัครรับคลาสเหตุการณ์เฉพาะและจะถูกเรียกเมื่อมีการโพสต์เหตุการณ์ของคลาสนั้นหรือคลาสย่อยเท่านั้น

// เหตุการณ์ POJO
data class MessageEvent(
    val message: String,
    val timestamp: Long = System.currentTimeMillis()
)

// สมาชิกใน Activity
class MainActivity : AppCompatActivity() {

    override fun onStart() {
        super.onStart()
        EventBus.getDefault().register(this)
    }

    override fun onStop() {
        EventBus.getDefault().unregister(this)
        super.onStop()
    }

    @Subscribe(threadMode = ThreadMode.MAIN)
    fun onMessageEvent(event: MessageEvent) {
        textView.text = event.message
    }
}

// การส่งเหตุการณ์จากคอมโพเนนต์อื่น
EventBus.getDefault().post(MessageEvent("Hello from Service"))

Subscriber Index เพื่อประสิทธิภาพ

โดยค่าเริ่มต้น EventBus ใช้รีเฟลกชันเพื่อค้นหาเมธอด @Subscribe ระหว่าง register() Subscriber Index จะสร้างดัชนีตัวจัดการในเวลาคอมไพล์ผ่านตัวประมวลผลคำอธิบายประกอบ ซึ่งช่วยลดโอเวอร์เฮดของรีเฟลกชันและเร่งการลงทะเบียน หากต้องการเปิดใช้งาน ให้เพิ่ม eventbus-annotation-processor ใน build.gradle EventBus จะใช้ดัชนีโดยอัตโนมัติหากมีใน classpath หากไม่มีดัชนี ไลบรารียังคงทำงานได้ แต่ประสิทธิภาพลดลงเล็กน้อย

EventBus ทำงานอย่างไรใน Android?

เมื่อเรียก EventBus.getDefault().post(event) ไลบรารีจะกำหนดประเภทเหตุการณ์ ค้นหาสมาชิกที่ลงทะเบียนทั้งหมดที่มีเมธอด @Subscribe ที่รับประเภทนั้น และเรียกใช้ตาม ThreadMode ที่ระบุ การค้นหาสมาชิก ดำเนินการโดยใช้แผนที่ Class → CopyOnWriteArrayList ที่สร้างขึ้นระหว่างการลงทะเบียน หากเหตุการณ์ไม่มีสมาชิก post จะเสร็จสมบูรณ์โดยไม่มีข้อผิดพลาด — นี่คือพฤติกรรมปลอดภัย

วงจรชีวิตการลงทะเบียน

สมาชิกควรลงทะเบียนใน onStart() และยกเลิกการลงทะเบียนใน onStop() หากคุณลงทะเบียนใน onCreate() และยกเลิกใน onDestroy() Activity ที่ถูกทำลายโดยไม่เรียก onDestroy (เนื่องจาก finish()) อาจอยู่ในรายชื่อสมาชิก การรั่วไหลของสมาชิก เป็นหนึ่งในปัญหาหลักของ EventBus: Activity ที่ยังคงอยู่ในรายชื่อสมาชิกจะไม่ถูกเก็บโดย GC จนกว่าจะยกเลิกการลงทะเบียน จับคู่ register/unregister ในเมธอดวงจรชีวิตที่ถูกต้องเสมอ

ลำดับความสำคัญของตัวจัดการ

คำอธิบายประกอบ @Subscribe รองรับพารามิเตอร์ priority (จำนวนเต็ม, ค่าเริ่มต้น 0) ตัวจัดการที่มีลำดับความสำคัญสูงกว่าจะถูกเรียกก่อน cancelEventDelivery() ช่วยให้สามารถขัดขวางการส่งเหตุการณ์ไปยังสมาชิกที่เหลือได้ มีประโยชน์สำหรับตัวจัดการลำดับความสำคัญ (การบันทึก, การรับรองความถูกต้อง) ที่สามารถยกเลิกการประมวลผลเหตุการณ์โดยสมาชิกระดับล่าง ฟังก์ชันนี้ใช้ได้เฉพาะในเธรดที่โพสต์เหตุการณ์เท่านั้น

// ตัวอย่างซับซ้อนพร้อมลำดับความสำคัญ
data class NavigationEvent(val screen: String, val data: Bundle)

class NavigationInterceptor {
    @Subscribe(priority = 10, threadMode = ThreadMode.POSTING)
    fun onNavigationEvent(event: NavigationEvent) {
        if (event.screen == "restricted" && !isAuthorized) {
            EventBus.getDefault().cancelEventDelivery(event)
        }
    }
}

class AnalyticsLogger {
    @Subscribe(priority = 5)
    fun logNavigation(event: NavigationEvent) {
        analytics.logScreen(event.screen)
    }
}

// การส่งเหตุการณ์
EventBus.getDefault().post(NavigationEvent("profile", bundle))

EventBus vs LocalBroadcastManager vs LiveData

Android มีกลไกหลายอย่างสำหรับการสื่อสารภายในโพรเซส: EventBus, LocalBroadcastManager (เลิกใช้งานแล้ว) และ LiveData/Flow แต่ละอย่างมีข้อดีและข้อเสีย การเลือกขึ้นอยู่กับแนวทางสถาปัตยกรรมและข้อกำหนดด้านประสิทธิภาพ คำแนะนำสมัยใหม่ของ Google มุ่งไปที่ LiveData และ Flow เนื่องจากการรวมเข้ากับ Lifecycle และไม่มีการรั่วไหล

เมื่อใดควรเลือก EventBus

EventBus มีประโยชน์ในโปรเจกต์ที่มีโค้ดดั้งเดิมจำนวนมากและเมื่อ LiveData/Flow ไม่พร้อมใช้งาน (โปรเจกต์ Java เท่านั้น) Sticky events ของ EventBus ให้ความยืดหยุ่นที่ไม่มีใน LocalBroadcastManager EventBus ยังง่ายกว่าสำหรับการส่งเหตุการณ์จาก Service ไปยัง Activity โดยไม่ต้องใช้ ViewModel — โดยเฉพาะเมื่อต้องแจ้งความคืบหน้าของงานพื้นหลัง ไลบรารีมีขนาดเล็ก (ประมาณ 50 KB) และไม่เพิ่มการพึ่งพา

เมื่อใดควรเลือก LiveData/Flow

LiveData และ Flow เป็นส่วนหนึ่งของ Android Jetpack และรวมเข้ากับ Lifecycle พวกเขายกเลิกการสมัครรับโดยอัตโนมัติเมื่อคอมโพเนนต์ถูกทำลาย กำจัดการรั่วไหลของหน่วยความจำ Flow รองรับโค routine และตัวดำเนินการแปลงที่ซับซ้อน Google แนะนำ LiveData สำหรับเลเยอร์ UI และ Flow สำหรับพื้นที่เก็บข้อมูล EventBus ยังคงมีประโยชน์สำหรับเหตุการณ์ข้ามโมดูลที่การนำทางและตรรกะทางธุรกิจไม่เข้ากับ MVVM

Subscribe และ Post: การดำเนินการพื้นฐาน

Subscribe คือการลงทะเบียนตัวจัดการเหตุการณ์ผ่านคำอธิบายประกอบ @Subscribe เมธอดต้องเป็น public, void และรับพารามิเตอร์เดียว — ประเภทเหตุการณ์ Post คือการส่งเหตุการณ์ไปยังตัวจัดการที่สมัครรับทั้งหมดผ่าน EventBus.getDefault().post(event) เมธอด post ไม่ส่งคืนผลลัพธ์และไม่ระบุว่ามีตัวจัดการกี่ตัวถูกเรียก สำหรับเหตุการณ์ที่ต้องการการตอบสนอง ให้ใช้คลาส Event แยกต่างหากพร้อมฟิลด์ผลลัพธ์

การสร้างเหตุการณ์ที่กำหนดเอง

เหตุการณ์คือคลาส Java/Kotlin ใด ๆ แนะนำให้ใช้ data class สำหรับเหตุการณ์ที่ไม่เปลี่ยนสภาพและคลาสปกติสำหรับเหตุการณ์ที่มีฟิลด์ที่เปลี่ยนแปลงได้ การตั้งชื่อเหตุการณ์ควรสะท้อนถึงการกระทำ: UserLoggedInEvent, DataLoadedEvent, NetworkErrorEvent หลีกเลี่ยงคลาส Event ทั่วไปเดียวที่มีฟิลด์ String type — สิ่งนี้จะลบข้อดีของการกำหนดประเภท ลำดับชั้นของเหตุการณ์ (Event หลัก) ช่วยให้สามารถสมัครรับกลุ่มของเหตุการณ์ที่เกี่ยวข้องได้

// ลำดับชั้นเหตุการณ์
open class UserEvent
data class UserLoggedIn(val userId: String) : UserEvent()
data class UserLoggedOut(val reason: String) : UserEvent()

// การสมัครรับคลาสพื้นฐาน
class SessionManager {
    @Subscribe(threadMode = ThreadMode.MAIN)
    fun onUserEvent(event: UserEvent) {
        when (event) {
            is UserLoggedIn -> startSession(event.userId)
            is UserLoggedOut -> endSession(event.reason)
        }
    }
}

// การส่ง
EventBus.getDefault().post(UserLoggedIn("user_123"))

การลงทะเบียนและการยกเลิกการลงทะเบียน

การเรียก EventBus.getDefault().register(this) จะสแกนคลาสสมาชิกผ่านรีเฟลกชันหรือ Subscriber Index และเก็บเมธอด @Subscribe ที่พบในแผนที่เหตุการณ์ Unregister จะลบสมาชิกออกจากแผนที่ การลงทะเบียนซ้ำโดยไม่ยกเลิกเป็นข้อผิดพลาด (จะเกิด MultipleSubscriberException) สำหรับ Fragment ให้ลงทะเบียนใน onStart() และยกเลิกใน onStop() สำหรับ Service ใน onCreate() และ onDestroy() สำหรับ ViewModel ไม่แนะนำ — ให้ใช้ LiveData

Sticky Events และ ThreadMode

Sticky event คือเหตุการณ์ที่ยังคงอยู่ใน EventBus หลังจากถูกส่ง สมาชิกใหม่ที่ลงทะเบียนหลังจาก postSticky() จะได้รับ sticky event ล่าสุดของประเภทนั้นทันที สะดวกสำหรับการส่งสถานะเริ่มต้น: เมื่อเปิดหน้าจอ จะได้รับข้อมูลล่าสุดที่ส่งก่อนการลงทะเบียน คุณสามารถลบ sticky event ผ่าน EventBus.getDefault().removeStickyEvent(Class)

ThreadMode: สี่โหมดการทำงาน

ThreadMode กำหนดว่าเธรดใดทำงานตัวจัดการ POSTING (ค่าเริ่มต้น) — ตัวจัดการทำงานในเธรดเดียวกับที่เรียก post MAIN — ตัวจัดการทำงานในเธรดหลักผ่าน Handler BACKGROUND — ตัวจัดการทำงานในเธรดพื้นหลัง ถ้า post ถูกเรียกในเธรดหลัก EventBus จะวางตัวจัดการในคิวเธรดพื้นหลัง ASYNC — ตัวจัดการแต่ละตัวทำงานในเธรดพื้นหลังแยกจากพูลเธรด สำหรับการอัปเดต UI ให้ใช้ MAIN

// Sticky Event
data class LocationEvent(val lat: Double, val lng: Double)

// การส่ง sticky event จาก LocationService
EventBus.getDefault().postSticky(LocationEvent(55.7558, 37.6173))

// สมาชิกได้รับตำแหน่งล่าสุดทันทีหลังจากลงทะเบียน
class MapFragment : Fragment() {
    override fun onStart() {
        super.onStart()
        EventBus.getDefault().register(this)
        // จะได้รับ LocationEvent ทันทีหากมีการเรียก postSticky
    }

    override fun onStop() {
        EventBus.getDefault().unregister(this)
        super.onStop()
    }

    @Subscribe(sticky = true, threadMode = ThreadMode.MAIN)
    fun onLocationEvent(event: LocationEvent) {
        moveMapTo(event.lat, event.lng)
    }
}

// การลบ sticky event
EventBus.getDefault().removeStickyEvent(LocationEvent::class.java)

ThreadMode.BACKGROUND vs ASYNC

BACKGROUND ใช้เธรดพื้นหลังเดียวสำหรับตัวจัดการทั้งหมด — ทำงานตามลำดับ ASYNC สร้างเธรดใหม่จากพูลสำหรับตัวจัดการแต่ละตัว — ทำงานแบบขนาน เหมาะสำหรับการดำเนินการ I/O กับฐานข้อมูลที่ใช้ร่วมกัน BACKGROUND เหมาะสำหรับการดำเนินการ I/O กับฐานข้อมูลที่ใช้ร่วมกัน ASYNC สำหรับการดำเนินการระยะยาวอิสระ (คำขอเครือข่าย) ทั้งสองโหมดต้องการการเข้าถึงทรัพยากรที่ใช้ร่วมกันอย่างปลอดภัยต่อเธรด โปรดทราบจำนวนเธรด: พูล ASYNC ไม่จำกัด

ข้อผิดพลาดทั่วไปและประสิทธิภาพของ EventBus

เมื่อใช้ EventBus นักพัฒนามักทำผิดพลาดที่นำไปสู่การรั่วไหลของหน่วยความจำ การเรียกที่ไม่คาดคิด และประสิทธิภาพลดลง ที่สำคัญที่สุด: ลืมยกเลิกการลงทะเบียนใน Activity, ลงทะเบียนใน onCreate (แทน onStart/onStop), สมัครรับ Object (เหตุการณ์ทั้งหมด), ส่งเหตุการณ์ในลูปไม่สิ้นสุด การสร้างโปรไฟล์ด้วย Android Profiler ช่วยระบุปัญหา

การรั่วไหลของหน่วยความจำผ่าน EventBus

ข้อผิดพลาดที่พบบ่อยที่สุดคือการลงทะเบียน Activity ใน onCreate() โดยไม่ยกเลิกใน onDestroy() ผลลัพธ์: EventBus เก็บการอ้างอิงไปยัง Activity GC ไม่สามารถปล่อยได้ เมื่อหมุนหน้าจอ Activity ใหม่จะถูกสร้างขึ้นในขณะที่ Activity ก่อนหน้าอยู่ในหน่วยความจำ วิธีแก้ปัญหา: จับคู่ register/unregister ใน onStart/onStop เสมอ สำหรับ Fragment ให้ใช้รูปแบบเดียวกัน หาก Activity ถูก EventBus เก็บไว้หลังจาก finish ให้ตรวจสอบด้วย Memory Profiler

ประสิทธิภาพ: Subscriber Index

หากไม่มี Subscriber Index EventBus จะใช้รีเฟลกชันเพื่อค้นหาเมธอด @Subscribe ทุกครั้งที่ register() บนอุปกรณ์ Android 6-7 รีเฟลกชันทำงานช้า ทำให้เกิดความล่าช้าถึง 50 ms Subscriber Index จะกำจัดรีเฟลกชันโดยสิ้นเชิง: เมธอดจะถูกจัดทำดัชนีในเวลาคอมไพล์ผ่านตัวประมวลผลคำอธิบายประกอบ สำหรับโปรเจกต์ที่มีสมาชิก 20 คนขึ้นไป ดัชนีเป็นสิ่งจำเป็น ตรวจสอบให้แน่ใจว่ามีการกำหนดค่า kapt หรือ annotationProcessor ใน build.gradle

// build.gradle (app) — เพิ่ม Subscriber Index
dependencies {
    implementation 'org.greenrobot:eventbus:3.3.1'
    annotationProcessor 'org.greenrobot:eventbus-annotation-processor:3.3.1'
}

// สำหรับ Kotlin ใช้ kapt
plugins {
    id 'kotlin-kapt'
}

dependencies {
    implementation 'org.greenrobot:eventbus:3.3.1'
    kapt 'org.greenrobot:eventbus-annotation-processor:3.3.1'
}

// การกำหนดค่าดัชนี (ใน defaultConfig)
kapt {
    arguments {
        arg('eventBusIndex', 'com.app.EventBusIndex')
    }
}

ทางเลือกของ EventBus ใน Android สมัยใหม่

โปรเจกต์สมัยใหม่ที่ใช้ Kotlin และ Jetpack Compose มักเลือกใช้ SharedFlow และ Channel จากไลบรารี kotlinx.coroutines SharedFlow รองรับการเล่นซ้ำ (sticky), การบัฟเฟอร์ และแรงดันย้อนกลับ Channel จัดการเหตุการณ์ครั้งเดียว (toast, การนำทาง) ทั้งสองโซลูชันรวมเข้ากับ Lifecycle ผ่าน repeatOnLifecycle และไม่ต้องการการยกเลิกการสมัครด้วยตนเอง สำหรับโปรเจกต์ใหม่ แนะนำให้ใช้ SharedFlow แทน EventBus สำหรับโปรเจกต์ที่มีอยู่ การย้ายข้อมูลนั้นสมเหตุสมผลในระหว่างการปรับโครงสร้าง