Android 性能监控之——消息调度启动优化方案实践_性能优化demo(1)

最新推荐文章于 2024-10-11 16:17:20 发布

2401_83974607

最新推荐文章于 2024-10-11 16:17:20 发布

阅读量780

点赞数 14

分类专栏： 2024年程序员学习文章标签： android

本文链接：https://blog.csdn.net/2401_83974607/article/details/137552204

版权

2024年程序员学习专栏收录该内容

250 篇文章 2 订阅

订阅专栏

模拟劣化场景

我们首先模拟一个会影响冷启动的耗时消息场景, 在demo中，插入一个耗时消息到 startActivity对应的消息之前。

package com.knightboost.appoptimizeframework

import android.content.Intent
import androidx.appcompat.app.AppCompatActivity
import android.os.Bundle
import android.os.Handler
import android.os.Looper
import android.util.Log
import com.knightboost.optimize.looperopt.ColdLaunchBoost
import com.knightboost.optimize.looperopt.ColdLaunchBoost.WatchingState

class SplashActivity : AppCompatActivity() {
val handler = Handler(Looper.getMainLooper())

override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_splash)
Log.d(“MainLooperBoost”, “SplashActivity onCreate”)

}

override fun onStart() {
super.onStart()
Log.d(“MainLooperBoost”, “SplashActivity onStart”)
}

override fun onResume() {
super.onResume()
Log.d(“MainLooperBoost”, “SplashActivity onResume”)
Handler().postDelayed({
//发送3秒的耗时消息到队列中
//这里为了方便模拟，直接在主线程发送耗时任务,模拟耗时消息在启动Activity消息之前的场景
handler.post({
Thread.sleep(3000)
Log.e(“MainLooperBoost”, “任务处理3000ms”)
})
val intent = Intent(this, MainActivity::class.java)
Log.e(“MainLooperBoost”, “begin start to MainActivity”)
startActivity(intent)
//标记接下来需要优化启动Activity的相关消息
ColdLaunchBoost.getInstance().curWatchingState = WatchingState.STATE_WATCHING_START_MAIN_ACTIVITY
},1000)

}

override fun onPause() {
super.onPause()
Log.d(“MainLooperBoost”, “SplashActivity onPause”)
}

override fun onStop() {
super.onStop()
Log.d(“MainLooperBoost”, “SplashActivity onStop”)
}

}

这里的startActivity函数在实现底层会生成2个消息，其目的分别对应“Pause当前的Activity"，以及 “resume MainActivity”。在函数刚执行结束时，此时的消息队列大概是这样的(为了方便理解，忽略延迟1秒对应的消息以及其它消息)。

以下视频为代码运行效果，可以发现在闪屏页展示一秒后，并未立即进行页面跳转操作，其被阻塞了3秒。

对应运行时的日志：

那么为了不让其他消息，影响到 startActivity的操作，就需要提升 startActivity操作相应消息的顺序。

优化方案

消息调度监控

提高目标消息的顺序，首先需要一个检查消息队列内消息的时机, 我们可以在每次消息调度结束时进行，如果发现当前队列中有相应的需要提升优先级的消息，则将其移动至消息队首。

消息的调度监控有两种方式，在低版本系统可以基于设置Printer替换实现，不过这种方式只能获取到消息的开始和结束时间，无法获取到Message对象，并且基于Printer的方案会有额外的字符串拼接的性能开销。第二种是通过调用Looper的 setObserver 函数设置消息调度观察者，相比Printer的方案，它可以拿到调度的Message对象，并且没有额外的性能开销，缺点是有hiddenApi的限制。

消息类型判断

修改消息的顺序，需要先从队列中获取到目标消息，上个小节已经说过，startActivity 会有2个消息调度，分别是：“pause 当前Activity”，以及“resum新的Activity” 。在Android 9.0以下版本，可以通过判断 message的target(Handler) 以及 what值区分，它们分别对应 ActivityThread中 mH Handler 的 LAUNCH_ACTIVITY (100), PAUSE_ACTIVITY(107)

而在Android 9.0以上版本，所有Activity生命周期事务变化被合并到一个消息 EXECUTE_TRANSACTION 中

那么高版本如何判断一个消息是为了 PauseActivity呢？通过源码分析，可以发现这个Message的obj属性是一个ClientTransaction类型的对象，而该对象的mLifecycleStateRequest的getTargetState()函数返回值标识了期望的生命周期状态

以pauseActivity为例，其实际的对象类型为 PauseActivityItem, 它的getTargetState 函数返回值为 ON_PAUSE =4。

因此，我们可以先通过判断Message what值为 EXECUTE_TRANSACTION (159)，再通过反射最终获取到 mLifecycleStateRequest 对象getTargetState函数的返回值，来判断消息是pauseActivity，还是 resumeActivity。

以下为整个流程具体的实现代码: 首先在startActivity 后，主动标记后续需要优化启动页面的消息

class SplashActivity : AppCompatActivity() {
//…
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_splash)
Log.d(“MainLooperBoost”, “SplashActivity onCreate”)
Handler().postDelayed({
//发送3秒的耗时消息到队列中
//这里为了方便模拟，直接在主线程发送耗时任务,模拟耗时消息在启动Activity消息之前的场景
handler.post({
Thread.sleep(3000)
Log.e(“MainLooperBoost”, “任务处理3000ms”)
})
val intent = Intent(this, MainActivity::class.java)
Log.e(“MainLooperBoost”, “begin start to MainActivity”)
startActivity(intent)
//标记接下来需要优化启动Activity的相关消息
ColdLaunchBoost.getInstance().curWatchingState = WatchingState.STATE_WATCHING_START_MAIN_ACTIVITY

},1000)
}
//…
}

基于Looper消息调度监控，每次消息调度结束时，检查消息队列中的消息，判断是否存在目标消息

其中pauseActivity的Message判断逻辑为， launchActivity消息判断同理。

launchActivity消息判断同理，只是判断targetState的值不同。

修改消息顺序、优化页面跳转

修改普通消息的顺序比较简单。当遍历消息队列找到目标message后，可以修改前一个消息的next值，使其指向下一个消息，这样就从消息队列中移除了消息，之后再复制一份目标消息，重新发送到队列首部。

public boolean upgradeMessagePriority(Handler handler, MessageQueue messageQueue,
TargetMessageChecker targetMessageChecker) {
synchronized (messageQueue) {
try {
Message message = (Message) filed_mMessages.get(messageQueue);
Message preMessage = null;
while (message != null) {
if (targetMessageChecker.isTargetMessage(message)) {
// 拷贝消息
Message copy = Message.obtain(message);
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP_MR1) {
if (message.isAsynchronous()) {
copy.setAsynchronous(true);
}
}
if (preMessage != null) { //如果已经在队列首部了，则不需要优化
//当前消息的下一个消息