在 Android 中使用动态代码插桩监控应用性能

简介

之前写过两篇文章介绍了通过 APTJavassist 做静态的代码插桩:
1. 使用 APT 自动生成代码
2. 使用 Javassist 实现代码静态插桩

我们可以通过代码插桩,实现 代码日志记录、方法耗时统计、界面自动生成 等功能。
但是,通过 JavassistASM 做的代码插桩,只能修改 apk 包内的代码,无法修改系统中的代码。

例如在 Android 的性能优化等场景,需要 hook HandlerThread 等系统类才能实现,例如:
(1) 如何监控业务层代码没有使用线程池,而是创建 Thread 对象?
(2) 如何统计主线程 Message 的执行耗时,并在 Message 执行超时后打印其加入时的堆栈?

目前开源的代码动态插桩的技术,主要是基于 Xposed、Dexposed 以及 weishu 大佬的 epic 实现的。

我们在使用 epic 时,主要用它的 XposedBridge 类。这个类有三个重要的方法:hookMethodhookAllConstructorshookAllMethods

接下来我们就用上面两个性能监控的例子,看一下如何使用 动态代码插桩 来监控应用性能。
(这一篇只看怎么使用 epic,它的原理 weishu 大神在自己的博客中写得比较明白了,后续我也会补上一篇 epic 的原理)


一、如何监控线程的创建?

当我们要去监控某一个类是否有对象创建,例如 Thread,其实就是监控这个类的构造函数是否有被调用。
我们可以利用 XposedBridgehookAllConstructors 方法做监控,它的函数原型如下:

public static 
Set<Unhook> hookAllConstructors(Class klass, XC_MethodHook callback)

返回值可以用于解除 hook,参数一是想要 hook 的类,参数二是定义如何 hook 的回调。
XC_MethodHook 有两个方法,用于在原函数执行前后做插桩。
对于我们监控线程的这个目的,它的实现是:

class ThreadConstructorHooker(priority: Int) : XC_MethodHook(priority) {

    /* ======================================================= */
    /* Override/Implements Methods                             */
    /* ======================================================= */

    override fun beforeHookedMethod(param: MethodHookParam?) {
        super.beforeHookedMethod(param)
        Log.i("ZHP_TEST", "即将执行线程的构造方法")
    }

    override fun afterHookedMethod(param: MethodHookParam?) {
        super.afterHookedMethod(param)
        Log.i("ZHP_TEST", "线程的构造方法执行完毕")
        
        // 通过 thisObject 属性获取到 this
        val thread = param?.thisObject ?: return
        
        Log.i("ZHP_TEST", "线程创建的堆栈:")
        Throwable().printStackTrace();
    }
}

在尽可能早的地方,执行以下 hook 即可监控线程的初始化了:

val hookHandler = ThreadConstructorHooker(1)
XposedBridge.hookAllConstructors(Thread::class.java, hookHandler)

在具体的业务处理中,我们可以根据传入的 param 对象,获取 this 的具体类型、调用的堆栈等等,用于判断是否需要抛出异常。


二、如何监控主线程 Message 执行超时?

以前我们可以用反射替换掉 Looper 的 mLogging 对象,在其打印日志时统计 Message 的执行耗时。 但这种办法不能记录这个 Message 是在什么时候加入到 消息队列 中的。
如果想要记录 Message 在加入时的堆栈,则需要在 Handler 的 sendMessageAtTime 方法中插桩。可惜的是 Handler 是系统的类,无法通过 Javassist 或者 ASM 插桩。

用 epic 就容易多了。
首先我们定义一个 Map 用于保存 Message 在添加时的堆栈:

object MessageStackTraceMap {

    /* ======================================================= */
    /* Fields                                                  */
    /* ======================================================= */

    private val map = HashMap<Message, Throwable>()



    /* ======================================================= */
    /* Public Methods                                          */
    /* ======================================================= */

    fun put(message: Message, throwable: Throwable) {
        map[message] = throwable
    }

    fun remove(message: Message) {
        map.remove(message)
    }

    fun get(message: Message): Throwable? {
        return map[message]
    }

}

这只是一个简化版的代码~

接下来定义如何 hook Handler 的 sendMessageAtTime 方法:

class SendMessageAtTimeHooker(priority: Int) : XC_MethodHook(priority) {

    /* ======================================================= */
    /* Override/Implements Methods                             */
    /* ======================================================= */

    override fun beforeHookedMethod(param: MethodHookParam?) {
        super.beforeHookedMethod(param)

        // 获取 Handler 对象
        val handler = param?.thisObject as? android.os.Handler ?: return

        // 如果不是主线程,不处理
        if (handler.looper != Looper.getMainLooper()) {
            return
        }

        // 加入到 map 中,记录其堆栈
        MessageStackTraceMap.put(param.args[0] as Message, Throwable());
    }
}

以及 dispatchMessage 方法,这个方法用于计算 Message 的执行耗时:

class DispatchMessageHooker(priority: Int) : XC_MethodHook(priority) {

    /* ======================================================= */
    /* Fields                                                  */
    /* ======================================================= */
    
    /** Message 开始执行的时刻 */
    private var begin: Long = 0



    /* ======================================================= */
    /* Override/Implements Methods                             */
    /* ======================================================= */

    override fun beforeHookedMethod(param: MethodHookParam?) {
        super.beforeHookedMethod(param)

        // 获取 Handler 对象
        val handler = param?.thisObject as? android.os.Handler ?: return

        // 如果不是主线程,不处理
        if (handler.looper != Looper.getMainLooper()) {
            return
        }

        // 记录 Message 执行的开始时间
        begin = SystemClock.elapsedRealtime()
    }


    override fun afterHookedMethod(param: MethodHookParam?) {
        super.afterHookedMethod(param)

        // 获取 Handler 对象
        val handler = param?.thisObject as? android.os.Handler ?: return

        // 如果不是主线程,不处理
        if (handler.looper != Looper.getMainLooper()) {
            return
        }

        // 计算这个 message 的执行耗时
        val now = SystemClock.elapsedRealtime()
        val cost = now - begin

        // 获取消息对象
        val msg = param.args[0] as Message

        // 如果耗时小于  60  毫秒,还能接受
        if (cost < 60) {
            // 从队列中移除消息
            MessageStackTraceMap.remove(msg)
            return
        }

        // 对于大于 60 毫秒的消息,获取其添加时的堆栈,并报警
        val throwable = MessageStackTraceMap.get(msg)
        MessageStackTraceMap.remove(msg)
        Log.w("ZHP_TEST", "消息执行超时,添加位置:")
        throwable?.printStackTrace()
    }
}

最后我们在使用 XposedBridge 将这个两个方法 hook 了:

val handlerClass = Handler::class.java

// hook Handler#sendMessageAtTime 方法
val sendMessageAtTime = handlerClass.getDeclaredMethod(
    "sendMessageAtTime",
    Message::class.java,
    Long::class.java
)
XposedBridge.hookMethod(
    sendMessageAtTime,
    SendMessageAtTimeHooker(1)
)

// hook Handler#dispatchMessage 方法
val dispatchMessage = handlerClass.getDeclaredMethod(
    "dispatchMessage",
    Message::class.java
)
XposedBridge.hookMethod(
    dispatchMessage,
    DispatchMessageHooker(1)
)

这就实现了监控主线程消息执行耗时的功能啦~

这篇只是说一下怎么实现这两个常见的性能监控需求,下一篇我们了解 epic 的具体实现原理。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,222评论 6 493
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,455评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,720评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,568评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,696评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,879评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,028评论 3 409
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,773评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,220评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,550评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,697评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,360评论 4 332
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,002评论 3 315
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,782评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,010评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,433评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,587评论 2 350

推荐阅读更多精彩内容