一次Android线程优化的探索

作者：咕咚移动技术团队-Ares

当大家打开AndroidStudio的Profiler工具时，是否遇到过这种情况：

查看CPU状态

哇塞好几百个线程？？名字咋都是12345？怎么都在sleep或wait但就不销毁？

其实，当一个项目规模越来越大时，随着开发人员变更、老代码不规范、三方sdk引入越来越多，很难避免线程数量暴涨的问题。当线程过多时，不仅有oom风险，更会带来很多内存泄漏的隐患。但通过Profiler工具也只是知道线程数量，用Thread.getAllStackTraces()方法获取到的也只有线程的运行时堆栈，即到run()方法就结束了，并不知道start()是被谁调用的。所以也就无法得知当前线程所对应的业务逻辑，以及它在当前时刻是否本应该被销毁。

那如何才能得知一个线程start()方法的调用栈呢？如果我们有个BaseThread，然后所有的线程都使用或继承于它，就好办了，我们可以在start()方法中获取堆栈信息：

@Synchronized
override fun start() {
    val stackElements = Throwable().stackTrace
    super.start()
}

想要做到这一点，可以使用asm编译期间改字节码来完成。这里简单介绍下asm，它可以通过自定义gradle插件，在代码被编译成class后、打包成dex前，把项目中的所有class文件（包括你自己写的，和三方jar包中的）遍历一遍，遍历期间你就可以通过asm任意修改class字节码，以达到各种不可告人的目的。那么我们就可以通过asm来把项目中的Thread都替换掉：

new Thread() -> new BaseThread()

extends Thread -> extends BaseThread

（具体asm相关代码可参见github.com/codoon/Thre… ）

现在有了调用栈，如何将调用栈和线程建立联系呢？其实Thread初始化时已经产生了线程id，我们可以在start()中把线程id和对应栈信息放到一个map中。另外我们还可以复写run()方法，当super.run()执行完后，线程即将销毁，我们可以在此时把map中对应信息移除掉。

好了！就是这么简单，接下来看线程池。线程池中的线程按刚刚的方法是替换不掉的，因为这些代码在framework层，asm管不着。并且对于线程池来说，我们需要的不是它的线程在哪被启动，而是线程正在执行的task是从哪里被添加的，这样我们才知道是哪个业务添加了task使得线程一直在运行。线程池一般有两种创建方法，直接new和调用Executors.xxx，我们先看new出来的，按照上述套路，搞个BaseThreadPool，使用asm全部替换掉，然后在构造函数中获取线程池创建堆栈，再复写execute、submit、invokeAny等提交task的方法，在其中获取task添加堆栈。但获取到的堆栈如何跟线程对应上呢？我们知道提交的task都是Runnable或Callable形式，如果我们写个PoolRunnable把它包一层，把线程池名字和task添加栈传进去，然后在run()中调用Thread.currentThread()获取当前线程，就把线程池名、线程池创建栈、线程id、task添加栈都关联起来了。

class PoolRunnable constructor(
    private val any: Any,
    private val callStack: String,
    private val poolName: String? = null
) : Runnable, Callable<Any>, Comparable<Any> {

    override fun run() {
        val threadId = Thread.currentThread().id
        // 至此callStack、poolName、thread就可以全部关联上
        // poolName和poolCreateStack可在外面事先创建关联

        (any as Runnable).run()

        // 任务已执行结束，callStack表示task添加栈，此时应为空代表线程当前无任务在运行
        info.callStack = ""
    }

    override fun call(): Any {
        // 类似run()方法
    }

    override fun compareTo(other: Any): Int {
        // 省略代码
    }
}

这里有一点要说明，有些task可能同时继承于Runnable、Callable、甚至Comparable，如果只包装成Runnable，当调用其他接口方法时会crash，所以这里要把已知的可能会继承的接口都实现。（当然如果后面发现没覆盖全，可以把新的接口继续加进来。至于用户自定义Runnable实现很多接口的情况不用担心。因为替换为PoolRunnable后都是系统代码在运行，主要看系统代码是否会调用call()、compareTo()等方法就好，上层随意调用被包装的runnable中各种自定义方法是没问题的）。

但是对于建立“线程-线程池”关系来说，这样要等到run()方法被执行时才能建立关系，感觉有点晚。这里可以更进一步，替换掉线程池中threadFactory，同样是自己包一层，在newThread()方法中即可及时拿到线程池创建的线程，这样就可以先和线程池建立关联，然后run()时再和堆栈建立关联。

好了！new方式创建的线程池搞定，接下来看看Executors.xxx怎么玩，我们可不可以自己写个ProxyExecutors，使用asm把所有Executors.xxx都替换成ProxyExecutors.xxx，然后把其中new ThreadPool都换成new BaseThreadPool呢？

object ProxyExecutors {

    @JvmStatic
    fun newFixedThreadPool(nThreads: Int): ExecutorService {
        return BaseThreadPoolExecutor(
            nThreads, nThreads,
            0L, TimeUnit.MILLISECONDS,
            LinkedBlockingQueue()
        )
    }

    @JvmStatic
    fun newCachedThreadPool(): ExecutorService {
        return BaseThreadPoolExecutor(
            0, Int.MAX_VALUE,
            60L, TimeUnit.SECONDS,
            SynchronousQueue()
        )
    }

    @JvmStatic
    fun newScheduledThreadPool(
        corePoolSize: Int,
        threadFactory: ThreadFactory?
    ): ScheduledExecutorService {
        return BaseScheduledThreadPoolExecutor(corePoolSize, threadFactory)
    }
}

对于某些线程池确实没啥问题，但当你继续写下去时，会出问题，比如：

    @JvmStatic
    fun newSingleThreadScheduledExecutor(): ScheduledExecutorService {
        return BaseDelegatedScheduledExecutorService(
            ScheduledThreadPoolExecutor(1)
        )
    }

DelegatedScheduledExecutorService是Executors的私有内部类，没办法方便的写出BaseDelegatedScheduledExecutorService。所以继续观察下，发现所有创建线程池方法都返回的都是ExecutorService或ScheduledExecutorService，既然这么统一，并且这两个都是接口，那我们就使用动态代理吧！通过代理，就可以拿到接口的各种方法以及方法参数，然后为所欲为。以ExecutorService接口为例：

object ProxyExecutors {
    @JvmStatic
    fun newFixedThreadPool(nThreads: Int): ExecutorService {
        return proxy(Executors.newFixedThreadPool(nThreads))
    }
}

    private fun proxy(executorService: ExecutorService): ExecutorService {
        if (executorService is ThreadPoolExecutor) {
            // 这里和BaseThreadPoolExecutor一样，设置ThreadFactory为了尽早获取线程信息和线程池建立联系，而不用等到run时
            executorService.threadFactory = BaseThreadFactory(
                executorService.threadFactory,
                toObjectString(executorService)
            )
        }
        val handler = ProxyExecutorService(executorService)
        return Proxy.newProxyInstance(
            executorService.javaClass.classLoader,
            AbstractExecutorService::class.java.interfaces,
            handler
        ) as ExecutorService
    }

// 这里使用java是因为kotlin在调用java变长参数方法时有坑
public class ProxyExecutorService implements InvocationHandler {
    private ExecutorService executor;
    private String poolName = null;

    ProxyExecutorService(ExecutorService executor) {
        this.executor = executor;
        poolName = TrackerUtils.toObjectString(executor);
        // 初始化时获取线程池信息
        String createStack = TrackerUtils.getStackString(false);
        // 省略部分代码
    }

    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        // 因方法数众多，并且被代理的各类中方法也不一致
        // 所以被调用方法中只要含有Runnable、Callable类型的参数，都替换成PoolRunnable代理
        if (args != null) {
            String callStack = TrackerUtils.getStackString(true);
            for (int i = 0; i < args.length; i++) {
                Object arg = args[i];
                if ((arg instanceof Runnable || arg instanceof Callable) && !(arg instanceof PoolRunnable)) {
                    // execute submit 等情况
                    PoolRunnable any = new PoolRunnable(arg, callStack, poolName);
                    // 替换方法参数
                    args[i] = any;
                } else if (arg instanceof Collection && !((Collection) arg).isEmpty()) {
                    // invokeAny invokeAll 等情况
                    Iterator iter = ((Collection) arg).iterator();
                    ArrayList<PoolRunnable> taskList = new ArrayList<>();
                    boolean allOk = iter.hasNext();
                    while (iter.hasNext()) {
                        Object it = iter.next();
                        if (it instanceof Runnable || it instanceof Callable) {
                            if (it instanceof PoolRunnable) {
                                taskList.add((PoolRunnable) it);
                            } else {
                                taskList.add(new PoolRunnable(it, callStack, poolName));
                            }
                        } else {
                            allOk = false;
                            break;
                        }
                    }
                    if (allOk) {
                        // 替换方法参数
                        args[i] = taskList;
                    }
                }
            }
        }

        if (method.getName().equals("shutdown") || method.getName().equals("shutdownNow")) {
            ThreadInfoManager.getINSTANCE().shutDownPool(poolName);
        }
        return method.invoke(executor, args);
    }
}

在invoke方法中，我们把所有参数为Runnable或Callable的都替换成自己的PoolRunnable，后面和new创建线程池的套路一样，在PoolRunnable的run()或call()方法中进行线程与堆栈的关联。完美！

但是考虑一个问题，如果有人不幸写出这样的代码，会发生什么呢？

val pool = Executors.newFixedThreadPool(3) as ThreadPoolExecutor

对了，会crash，因为我们动态代理后代理对象变成了ExecutorService，没办法向下转型成ThreadPoolExecutor，这也是动态代理的一个缺点，只能代理接口，如果一个类A除了实现接口还有很多自己的方法，动态代理对这些方法是无能为力的，代理后对象只是接口的实例，无法转成类A。这个问题可以使用cglib/javassist库解决，这里就不展开了。为了保险起见，我们可以把能用Base替换的都替换掉，只有类似newSingleThreadScheduledExecutor()这种不能用Base替换的才用动态代理：

object ProxyExecutors {

    @JvmStatic
    fun newFixedThreadPool(nThreads: Int): ExecutorService {
        // 这里使用BaseThreadPoolExecutor主要是为了避免上层代码把ExecutorService转型成ThreadPoolExecutor的问题，如果使用proxy方法动态代理，上层这么做会crash
        return BaseThreadPoolExecutor(
            nThreads, nThreads,
            0L, TimeUnit.MILLISECONDS,
            LinkedBlockingQueue()
        )
        // return proxy(Executors.newFixedThreadPool(nThreads))
    }

ok，线程池搞定了。但除了线程和线程池，Java和Android中还有很多封装了线程线程池的类。比如HandlerThread，Timer，ASyncTask等，我们先处理这几个常用类吧。

HandlerThread本质上就是Thread，采用和Thread类似的处理方式就好。

Timer内部有个私有的TimerThread成员，本质也是个Thread，看源码可知Timer在构造方法中便启动了这个Thread，所以调用栈也就是Timer被初始化的栈。我们可以新建BaseTimer，使用asm将代码中的Timer替换掉，然后构造方法中获取调用栈，再通过反射拿到内部Thread成员，获取其id等信息，与调用栈关联即可。

ASyncTask这个相对来说难办一些，这里面主要有两个Executor：THREAD_POOL_EXECUTOR和SERIAL_EXECUTOR，其中主要干活的是THREAD_POOL_EXECUTOR，而SERIAL_EXECUTOR并不是真正意义上的线程池，只是实现了Executor接口而已。SERIAL_EXECUTOR的execute()方法在向一个队列中添加任务，然后依次取出送入THREAD_POOL_EXECUTOR中执行，所以我们需要THREAD_POOL_EXECUTOR的线程池信息，关联SERIAL_EXECUTOR的execute()任务添加栈信息。而外界又可以直接用THREAD_POOL_EXECUTOR添加任务，这种情况下就又需要THREAD_POOL_EXECUTOR的任务添加栈信息了，所以这里需要一些特殊处理。总体思路仍然是动态代理SERIAL_EXECUTOR和THREAD_POOL_EXECUTOR，然后把代理设置回ASyncTask，时机为app启动时。由于ASyncTask中这两个线程池对象是final的，所以需要通过反射修改modifiers去掉final位。这在5.0及以上系统没什么问题，但4.x的源码中modifiers是通过native获取的：

    /**
     * Returns the modifiers for this field. The {@link Modifier} class should
     * be used to decode the result.
     *
     * @return the modifiers for this field
     * @see Modifier
     */
    public int getModifiers() {
        return getFieldModifiers(declaringClass, slot);
    }

    private native int getFieldModifiers(Class<?> declaringClass, int slot);

对此暂未找到修改方式，所以如果要追踪ASyncTask，请使用Android 5.0及以上手机。

至此，线程/线程池溯源基本完成了，后续会继续完善IntentService、ForkJoinPool和Java/Android源码中封装的其他不太常用的线程/线程池封装类。

初版效果长这样：主界面

可以看到界面中对用户代码做了高亮，帮助用户在迷乱的调用栈中一眼看到问题根源。其原理大致是在asm扫描class过程中，根据获取到的项目信息来记录哪些是用户写的代码（不能直接根据是否为jar包来判断，如果项目存在多个module，可能这些module最后也是以jar包形式被asm扫描），然后把相关class包名记下来，过滤掉包含有“已有短包名”的“较长包名”，把这些包名list通过asm写入到指定Java类的指定ArrayList成员中。在获取到调用栈后，可以和这些包名list对比，进行高亮。

最后，此文作为抛砖引玉，提供一种线程溯源的思路。其实可以看出asm还是很强大的，能做什么就取决于大家的想象力了。后面会逐渐完善新功能，比如记录线程运行时间，根据线程各维度状态筛选/排序等，统计线程所属包名或jar文件名，看看那些三方库在为非作歹（特别是某些广告sdk，简直。。），甚至对线程/线程池运行状态可疑的给出警告和优化建议等等。

最最后，作为asm初学者，很多用法还比较初级，如果有更优雅的实现方式，欢迎疯狂pull requests；另外，该项目虽然目前在咕咚这个比较庞大复杂的app上可正常运行，但难免还有考虑不周全的地方，毕竟替换字节码是比较危险的操作。如果引入后出现崩溃，欢迎花式提issues ~

项目地址：github.com/codoon/Thre…

欢迎Star ^_^