Broadcast Receiver: khái niệm, các loại Broadcast và nguyên lý hoạt động

Broadcast Receiver là gì?

Broadcast Receiver là một thành phần Android được thiết kế để nhận và xử lý các thông điệp Intent được phân phối bởi hệ điều hành hoặc các ứng dụng khác. Không giống như Activity và Service, Broadcast Receiver không có giao diện người dùng — nhiệm vụ của nó là thực hiện một hành động ngắn khi có sự kiện xảy ra.

Broadcast Receiver hoạt động thông qua cơ chế Intent. Hệ thống hoặc ứng dụng gửi Intent qua sendBroadcast hoặc sendOrderedBroadcast, và hệ điều hành gửi nó đến các bộ thu đã đăng ký. Mỗi bộ thu nhận Intent trong phương thức onReceive, phương thức này chạy trên luồng chính.

Theo Android Compatibility Definition Document, Broadcast Receiver phải hoàn thành onReceive trong vòng 10 giây — nếu không, hệ thống sẽ coi nó bị treo và kết thúc tiến trình. Đối với các tác vụ nền dài, hãy sử dụng JobScheduler hoặc WorkManager khởi chạy từ bộ thu.

Các loại Broadcast trong Android

Android hỗ trợ hai loại Broadcast chính: Normal Broadcast và Ordered Broadcast. Sự khác biệt nằm ở thứ tự gửi và khả năng gián đoạn chuỗi xử lý. Ngoài ra, Broadcast được chia thành hệ thống (do OS tạo ra) và tùy chỉnh (do ứng dụng tạo ra).

Normal Broadcast

Normal Broadcast được gửi đến tất cả bộ thu đã đăng ký một cách bất đồng bộ mà không có thứ tự đảm bảo. Hệ thống có thể xử lý các Broadcast này song song — mỗi bộ thu nhận Intent trong luồng riêng của nó. Gọi abortBroadcast trên Normal Broadcast không có tác dụng: không thể hủy gửi đến các bộ thu khác.

Ordered Broadcast

Ordered Broadcast được gửi tuần tự — đến mỗi bộ thu theo thứ tự giảm dần của thuộc tính android:priority (từ 0 đến 999). Sau khi xử lý, bộ thu có thể chuyển kết quả cho bộ thu tiếp theo qua setResultExtras hoặc gián đoạn chuỗi bằng cách gọi abortBroadcast. Điều này được sử dụng trong các tình huống mà thứ tự xử lý quan trọng — ví dụ, bộ thu SMS.

Broadcast hệ thống

Android tạo ra nhiều Broadcast hệ thống: ACTION_BOOT_COMPLETED (khởi động thiết bị), ACTION_BATTERY_LOW, ACTION_POWER_CONNECTED, CONNECTIVITY_ACTION, ACTION_PACKAGE_ADDED và các loại khác. Mỗi Intent chứa dữ liệu bổ sung trong Extras — mức pin, loại kết nối, tên gói.

Sticky Broadcast là loại đã lỗi thời giữ lại giá trị cuối cùng được gửi. Thay vào đó, hãy sử dụng LiveData, StateFlow hoặc SharedPreferences dùng chung để lưu trạng thái mới nhất.

Đăng ký Broadcast Receiver

Broadcast Receiver có thể được đăng ký theo hai cách: tĩnh qua AndroidManifest.xml hoặc động trong mã qua registerReceiver. Việc lựa chọn phụ thuộc vào tình huống: đăng ký tĩnh hoạt động ngay cả khi ứng dụng không chạy, đăng ký động chỉ hoạt động khi thành phần đăng ký còn hoạt động.

Đăng ký tĩnh

Đăng ký tĩnh được khai báo trong tệp kê khai với thẻ <receiver> bên trong <application>. Đối với mỗi bộ thu, lớp xử lý và bộ lọc Intent với các hành động cần chặn được chỉ định. Hệ thống tải các bộ thu này khi có Broadcast xảy ra ngay cả khi ứng dụng không chạy.

<!-- Static Broadcast Receiver registration in manifest -->
<receiver android:name=".BootReceiver"
    android:exported="true">
    <intent-filter>
        <action android:name="android.intent.action.BOOT_COMPLETED" />
    </intent-filter>
</receiver>

Đăng ký động

Đăng ký động được thực hiện bằng phương thức registerReceiver trong mã Activity, Service hoặc Fragment. Bộ thu chỉ tồn tại khi thành phần đã đăng ký nó còn sống. Luôn gọi unregisterReceiver trong onPause hoặc onDestroy — nếu không, rò rỉ bộ nhớ sẽ xảy ra và hệ thống có thể kết thúc tiến trình.

Ưu tiên và thứ tự xử lý

Đối với Ordered Broadcast, thứ tự gửi được xác định bởi thuộc tính android:priority. Bộ thu có ưu tiên cao hơn nhận Intent trước. Nếu nó gọi abortBroadcast sau khi xử lý, các bộ thu có ưu tiên thấp hơn sẽ không nhận được Intent. Đối với bộ thu tĩnh, ưu tiên được đặt trong bộ lọc Intent của tệp kê khai.

Truyền dữ liệu giữa các bộ thu

Các bộ thu trong Ordered Broadcast có thể truyền dữ liệu cho bộ thu tiếp theo trong chuỗi qua setResultExtras hoặc setResultData. Điều này cho phép xử lý đường ống: bộ thu đầu tiên làm phong phú Intent với dữ liệu bổ sung, bộ thu thứ hai sử dụng chúng, bộ thu thứ ba hoàn thành chuỗi. Phương thức getResultExtras đọc dữ liệu do bộ thu trước truyền đến.

Đối với Normal Broadcast, thứ tự không được đảm bảo, do đó tất cả các bộ thu nhận được Intent gốc không thay đổi. Nếu bạn cần các bộ thu ảnh hưởng lẫn nhau, hãy sử dụng sendOrderedBroadcast thay vì sendBroadcast.

Hạn chế trong Android 8 trở lên

Android 8 (API 26, Oreo) đã giới thiệu các hạn chế đáng kể đối với Broadcast nền. Hầu hết các Broadcast ngầm — những broadcast không nhắm đến một ứng dụng cụ thể — không còn hoạt động với đăng ký tĩnh. Hệ thống chặn các bộ thu đăng ký trong tệp kê khai cho các hành động như CONNECTIVITY_ACTION hoặc ACTION_BATTERY_LOW.

Những gì đã thay đổi

Google đã xác định danh sách các Broadcast tiếp tục hoạt động với đăng ký tĩnh: BOOT_COMPLETED, TIME_TICK, Alarm và thay đổi gói — tổng cộng khoảng mười ngoại lệ. Tất cả các Broadcast ngầm khác hiện yêu cầu đăng ký động qua Context.registerReceiver, chỉ hoạt động khi ứng dụng ở tiền cảnh.

Các lựa chọn thay thế cho Broadcast Receiver

Đối với các tác vụ nền trước đây được xử lý qua Broadcast Receiver, Android khuyến nghị WorkManager (tác vụ trì hoãn có đảm bảo thực thi), JobScheduler (tác vụ định kỳ xét trạng thái thiết bị) và NotificationListenerService (giám sát thông báo). Các thành phần này hoạt động mà không bị hạn chế Android 8 và được tối ưu hóa về mức tiêu thụ điện.

Ví dụ Broadcast Receiver trong Kotlin

Hãy tạo một Broadcast Receiver để theo dõi kết nối mạng. Bộ thu sẽ chụp Broadcast CONNECTIVITY_ACTION và ghi lại loại kết nối. Đối với Android 8+, chúng ta sẽ đăng ký động vì đây là Broadcast ngầm bị loại khỏi đăng ký tĩnh.

// Broadcast Receiver theo dõi trạng thái mạng
class NetworkReceiver : BroadcastReceiver() {

    override fun onReceive(context: Context, intent: Intent) {
        val cm = context.getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager
        val network = cm.activeNetwork
        val caps = cm.getNetworkCapabilities(network)

        val connectionType = when {
            caps?.hasTransport(NetworkCapabilities.TRANSPORT_WIFI) == true -> "WiFi"
            caps?.hasTransport(NetworkCapabilities.TRANSPORT_CELLULAR) == true -> "Cellular"
            else -> "Disconnected"
        }

        Log.d("NetworkReceiver", "Loại kết nối: $connectionType")
    }
}

// Đăng ký động trong Activity
class MainActivity : AppCompatActivity() {

    private val networkReceiver = NetworkReceiver()

    override fun onStart() {
        super.onStart()
        val filter = IntentFilter(ConnectivityManager.CONNECTIVITY_ACTION)
        registerReceiver(networkReceiver, filter)
    }

    override fun onStop() {
        super.onStop()
        unregisterReceiver(networkReceiver)
    }
}

Luôn hủy đăng ký bộ thu trong onStop — nếu Activity chuyển sang nền nhưng bộ thu vẫn được đăng ký, hệ thống không thể giải phóng tài nguyên. Đối với Service, sử dụng onDestroy. Trong các fragment, đăng ký bộ thu trong onStart và hủy đăng ký trong onStop, tuân theo vòng đời của fragment.