Android14 开发之Broadcast延迟及Service常驻等新特性说明

图片

Broadcast延迟问题

FLAG_RECEIVER_FOREGROUND 是 Android 中的一种标志,它用于将广播接收器(BroadcastReceiver)标记为前台广播。前台广播具有较高的优先级,系统会尽快调度前台广播接收器处理广播,确保及时性。

使用方法

使用 FLAG_RECEIVER_FOREGROUND 主要在两个场景中:

  1. 1. 发送广播时:将广播标记为前台广播。

  2. 2. 接收广播时:确保接收器在前台运行。

发送前台广播

在发送广播时,可以使用 sendBroadcast 方法,并传入一个 Intent 和 FLAG_RECEIVER_FOREGROUND 标志。例如:

val intent = Intent("com.example.ACTION")
intent.flags = Intent.FLAG_RECEIVER_FOREGROUND
sendBroadcast(intent)

示例代码

下面是一个完整的示例,包括发送和接收前台广播的代码。

发送前台广播
class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        // 发送前台广播
        val intent = Intent("com.example.ACTION")
        intent.flags = Intent.FLAG_RECEIVER_FOREGROUND
        sendBroadcast(intent)
    }
}
注册广播接收器

要接收广播,需要在 AndroidManifest.xml 中静态注册广播接收器,或者在代码中动态注册。

静态注册(AndroidManifest.xml):
<receiver android:name=".MyBroadcastReceiver">
    <intent-filter>
        <action android:name="com.example.ACTION" />
    </intent-filter>
</receiver>
动态注册(代码):
class MainActivity : AppCompatActivity() {
    private lateinit var receiver: MyBroadcastReceiver

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        // 动态注册广播接收器
        receiver = MyBroadcastReceiver()
        val filter = IntentFilter("com.example.ACTION")
        registerReceiver(receiver, filter)

        // 发送前台广播
        val intent = Intent("com.example.ACTION")
        intent.flags = Intent.FLAG_RECEIVER_FOREGROUND
        sendBroadcast(intent)
    }

    override fun onDestroy() {
        super.onDestroy()
        // 注销广播接收器
        unregisterReceiver(receiver)
    }
}
创建广播接收器
class MyBroadcastReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context?, intent: Intent?) {
        // 处理接收到的广播
        Toast.makeText(context, "Received foreground broadcast", Toast.LENGTH_SHORT).show()
    }
}

注意事项

  • • 权限:发送和接收广播可能需要特定的权限,例如 android.permission.BROADCAST_STICKY 或其他自定义权限。

  • • 性能影响:前台广播优先级较高,应谨慎使用,避免频繁发送大量前台广播,可能会影响系统性能。

通过以上示例,您可以了解如何使用 FLAG_RECEIVER_FOREGROUND 来发送和接收前台广播,确保广播接收器能够及时处理广播事件。

Service常驻问题

在 Android 13 中,根据 Intent 的 action 启动服务的方式与之前的版本大致相同,但需要注意一些新的权限要求和行为变化。以下是一个详细的指南,说明如何在 Android 13 中根据 Intent 的 action 启动服务。

创建服务

首先,我们需要创建一个服务。以下是一个简单的服务示例:

class MyService : Service() {

    override fun onBind(intent: Intent?): IBinder? {
        // 我们不会绑定此服务,因此返回null
        return null
    }

    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
        intent?.let {
            val action = it.action
            when (action) {
                "com.example.START_SERVICE" -> {
                    // 处理启动服务的逻辑
                    handleStartService()
                }
                // 可以添加更多的action处理逻辑
            }
        }
        // 如果系统因内存不足而终止此服务,重启服务
        return START_STICKY
    }

    private fun handleStartService() {
        // 处理服务启动逻辑
        Log.d("MyService", "Service started")
    }
}

在 AndroidManifest.xml 中注册服务

在 AndroidManifest.xml 中注册服务:

<service
    android:name=".MyService"
    android:exported="true">
</service>

启动服务

在某些情况下,我们需要根据 Intent 的 action 来启动服务。以下是一个示例代码,展示如何从活动中启动服务:

val intent = Intent(this, MyService::class.java).apply {
    action = "com.example.START_SERVICE"
}
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
    startForegroundService(intent)
} else {
    startService(intent)
}

处理权限

从 Android 8.0(API 级别 26)开始,后台启动服务受到了限制。为了确保服务能够在后台启动,您可能需要请求权限或采取其他措施。例如,可以使用前台服务来确保服务的持久性。

前台服务

为了确保服务在后台能够正常运行,我们可以将服务提升为前台服务。以下是如何实现的:

  1. 1. 在服务中启动前台服务:

    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
        val notification = createNotification()
        startForeground(1, notification)
    
        // 处理服务逻辑
        handleStartService()
    
        return START_STICKY
    }
    
    private fun createNotification(): Notification {
        val notificationChannelId = "MY_SERVICE_CHANNEL"
    
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
            val channel = NotificationChannel(
                notificationChannelId,
                "My Background Service",
                NotificationManager.IMPORTANCE_DEFAULT
            )
            val manager = getSystemService(NotificationManager::class.java)
            manager.createNotificationChannel(channel)
        }
    
        val builder = NotificationCompat.Builder(this, notificationChannelId)
            .setContentTitle("My Service")
            .setContentText("Running...")
            .setSmallIcon(R.drawable.ic_notification)
            .setPriority(NotificationCompat.PRIORITY_DEFAULT)
    
        return builder.build()
    }
  2. 2. 权限声明: 在 AndroidManifest.xml 中声明前台服务权限:

    <uses-permission android:name="android.permission.FOREGROUND_SERVICE" />

示例项目结构

  • • MainActivity: 负责启动服务。

  • • MyService: 服务类,包含启动前台服务的逻辑。

// MainActivity.kt
class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        val intent = Intent(this, MyService::class.java).apply {
            action = "com.example.START_SERVICE"
        }
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
            startForegroundService(intent)
        } else {
            startService(intent)
        }
    }
}
// MyService.kt
class MyService : Service() {

    override fun onBind(intent: Intent?): IBinder? {
        return null
    }

    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
        val notification = createNotification()
        startForeground(1, notification)

        intent?.let {
            val action = it.action
            when (action) {
                "com.example.START_SERVICE" -> {
                    handleStartService()
                }
            }
        }

        return START_STICKY
    }

    private fun createNotification(): Notification {
        val notificationChannelId = "MY_SERVICE_CHANNEL"

        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
            val channel = NotificationChannel(
                notificationChannelId,
                "My Background Service",
                NotificationManager.IMPORTANCE_DEFAULT
            )
            val manager = getSystemService(NotificationManager::class.java)
            manager.createNotificationChannel(channel)
        }

        val builder = NotificationCompat.Builder(this, notificationChannelId)
            .setContentTitle("My Service")
            .setContentText("Running...")
            .setSmallIcon(R.drawable.ic_notification)
            .setPriority(NotificationCompat.PRIORITY_DEFAULT)

        return builder.build()
    }

    private fun handleStartService() {
        Log.d("MyService", "Service started")
    }
}

总结

通过以上步骤,您可以在 Android 13 中根据 Intent 的 action 启动服务,并确保服务在后台运行时不会被系统终止。使用前台服务可以确保服务的持久性,并且可以处理新的权限要求和行为变化。

转自:Android14 开发之Broadcast延迟及Service常驻等新特性说明

### Android Looper 长时间消息处理问题分析 #### 日志中的长时间消息处理现象 当 `Looper` 处理的消息超出了预期的时间范围时,可能会触发性能监控器 (`PerfMonitor`) 的警告日志。例如,在提供的日志中提到的 `longMsg` 警告表明某个消息的处理时间过长[^2]。 具体来看,日志显示了一个序列号为 464 的消息计划时间为 `09:52:59.079`,但由于延迟了 126 毫秒才被处理,整个 Wall 时间消耗达到了 16,982 毫秒 (约 17 秒)。这说明主线程在此期间可能处于繁忙状态或者阻塞状态。 此外,Choreographer 提供的日志也指出应用跳过了大量帧数 (1018 帧),进一步验证了主线程负载过高或存在卡顿的情况。 --- #### 可能的原因分析 1. **主线程执行耗时操作** 主线程上可能存在一些高复杂度的操作,比如文件读写、网络请求或其他计算密集型任务。这些操作会占用大量的 CPU 时间并阻止其他 UI 更新任务被执行[^3]。 2. **广播接收者超时取消机制** 如果应用程序注册了许多广播接收器,并且某些广播未及时完成其回调函数,则可能导致系统调用 `cancelBroadcastTimeoutLocked` 来清理超时的任务链路。这种情况下,Binder IPC 和 AMS 中间件也会参与其中,从而增加额外开销[^1]。 3. **WiFipickerTracker 或其他后台服务的影响** 特定的服务组件(如 WiFipickerTracker)如果频繁唤醒设备或运行在前台优先级下,也可能间接影响到主进程资源分配情况。尤其是当它们尝试同步数据至服务器端或者其他远程节点时更容易引发此类异常行为[^4]。 4. **垃圾回收活动干扰** Java 虚拟机内部实现自动内存管理功能——即 GC(Garbage Collection) 过程本身就会暂停所有正在工作的线程一段时间来进行对象标记与清除工作;因此即使没有显式的重载逻辑代码段仍可能出现短暂停滞效应[^5]。 --- #### 解决方案建议 针对上述几种可能性分别给出对应的优化措施: 1. **迁移耗时任务到子线程/异步框架** 使用 HandlerThread、AsyncTask(已废弃推荐使用 WorkManager/Kotlin Coroutines) 等工具将那些不适合放在 Main Thread 上面的工作转移到 Background Threads 执行可以有效缓解这个问题带来的负面影响[^6]。 示例代码展示如何通过 ExecutorService 实现多线程编程模型: ```java public void performBackgroundOperation() { Executors.newSingleThreadExecutor().execute(() -> { try { // Simulate a time-consuming task. Thread.sleep(5000); } catch (InterruptedException e) { Log.e("TAG", "Error during background operation.", e); } runOnUiThread(() -> updateUI()); }); } private void updateUI() { TextView textView = findViewById(R.id.textView); textView.setText("Updated after background process."); } ``` 2. **精简广播监听器生命周期管理** 对于不再使用的 BroadcastReceiver 应该尽早解除绑定关系以免造成不必要的竞争条件以及潜在的安全漏洞风险[^7]。另外还可以考虑采用 LocalBroadcastManager 替代全局性的 Intent Filter 方式来减少跨 App 数据交换频率进而提升整体效率水平[^8]。 3. **调整特定 Service 工作模式** 根据实际需求重新评估各个后台 Services 是否有必要保持常驻状态还是可以通过 JobScheduler API 安排周期性启动即可满足业务目标同时降低功耗成本[^9]。 4. **监测并控制 Garbage Collector 行动时机** 尽量避免创建过多短寿命临时变量实例因为这样不仅增加了 JVM 内存压力而且还会促使更频繁地触发 FullGC 动作最终拖慢程序响应速度[^10]。对于大尺寸 Bitmap 图像加载场景则可借助第三方库 Glide/Picasso 自动缓存机制减轻原始像素数组拷贝负担[^11]. --- ### 总结 通过对现有资料深入剖析发现导致 Android 设备上出现 “Looper longMsg” 类型错误的根本原因是由于多种因素共同作用所致其中包括但不限于:Main Loop 占用率超标、BroadCast Receiver Timeout Chain Reaction Effect 发生概率增大还有可能是由个别特殊模块(WiFiPickerTrackor etc.) 异常活跃引起连锁反应等等。为此提出了若干针对性改进策略旨在帮助开发者快速定位根源所在并通过合理手段加以修正恢复流畅用户体验效果。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值