BlockPool 策略仅适用于 Federated HDFS 服务 block approach

转载

mob6454cc6acccd 2024-04-28 12:33:40

文章标签 android 主线程 java 堆栈 文章分类 架构后端开发

1.BlockCanary

造成app卡顿的直接原因通常是，主线程执行繁重的UI绘制、大量的计算或IO等耗时操作。常用的解决卡顿的方法有BlockCanary、ArgusAPM、LogMonitor等。

从监控主线程哦哦实现原理上，主要分为两种：

①依赖主线程Looper，监控每次dispatchMessage的执行耗时。（BlockCanary）

②依赖Choreographer模块，监控相邻两次Vsync事件通知的时间差。（ArgusAPM、LogMonitor）

BlockCanary是Android平台的一个非侵入式的性能监控组件，应用只需要实现一个抽象类，提供一些该组件需要的上下文环境，就可以在平时使用应用的时候检测主线程上的各种卡慢问题，并通过组件提供的各种信息分析出原因并进行修复。

BlockCanary对主线程操作进行了完全透明的监控，并能输出有效的信息，帮助开发分析、定位到问题所在，迅速优化应用。其特点有：

①非侵入式，简单的两行就打开监控，不需要到处打点，破坏代码优雅性。

②精准，输出的信息可以帮助定位到问题所在（精确到行），不需要像Logcat一样，慢慢去找。

2.BlockCanary使用

①添加依赖

dependencies {
    compile 'com.github.markzhai:blockcanary-android:1.5.0'
    // 仅在debug包启用BlockCanary进行卡顿监控和提示的话，可以这么用
    debugCompile 'com.github.markzhai:blockcanary-android:1.5.0'
    releaseCompile 'com.github.markzhai:blockcanary-no-op:1.5.0'
}

②在Application里进行初始化和start

BlockCanary.install(this, new BlockCanaryContext()).start();

3.BlockCanary原理

首先看install方法：

public static BlockCanary install(Context context, BlockCanaryContext blockCanarayContext) {
    BlockCanaryContext.init(context, blockCanaryContext);
    setEnabled(context, DisplayActivity.class, BlockCanaryContext.get().displayNotification());
    return get();
}

其中BlockCanaryContext表示监测的某些参数，包括卡顿的阈值、输出文件的路径等等。

public class BlockCanaryContext implements BlockInterceptor {
    public int provideBlockThreshold() {
        return 1000;   //默认卡顿阈值为1000ms
    }
    public String providePath() {
        return "/blockcanary/";//输出的log
    }
    //支持文件上传
    public void upload(File zippedFile) {
        throw new UnsupportedOperationException();
    }
    //可以在卡顿提供自定义操作
    @Override
    public void onBlock(Context context, BlockInfo blockInfo) {
    }
}

install只是创建出BlockCanary实例，主要是start方法的操作：

BlockCanary.java:
//Start monitoring.
public void start() {
    if (!mMonitorStarted) {
        mMonitorStarted = true;
        Looper.getMainLooper().setMessageLog ging(mBlockCanaryCore.monitor);
    }
}

start方法其实就是给主线程的Looper设置一个monitor。

熟悉Message/Looper/Handler系列的一定知道Looper.java中这么一段：

private static Looper sMainLooper;

public static void prepareMainLooper() {
    prepare(false);
    synchronized (Looper.class) {
        if (sMainLooper != null) {
            throw new IllegalStateException("The main Looper has already been prepared.");
        }
        sMainLooper = myLooper();
    }
}
public static Looper getMainLooper() {
    synchronized (Looper.class) {
        return sMainLooper;
    }
}

即整个应用的主线程，只有这一个looper，不管有多少handler，最后都会回到这里。

在Looper的loop方法中，看看主线程的looper实现：

public static void loop() {
    ...
    for (;;) {
        ...
        Printer logging = me.mLogging;
        if (logging != null) {
            logging.println(">>>>> Dispatching to " + msg.target + " " + msg.callback + ": " + msg.what);
        }
        msg.target.dispatchMessage(msg);
        if (logging != null) {
            logging.println("<<<<< Finished to " + msg.target + " " + msg.callback);
        }
        ...
    }
}

主线程所有执行的任务都在dispatchMessage方法中派发执行完成，通过setMessageLogging的方式给主线程的Looper设置一个Printer，因为dispatchMessage执行前后都会打印对应信息，在执行前利用另外一条线程，通过Thread#getStackTrace接口，以轮询的方式获取主线程执行堆栈信息并记录起来，同时统计每次dispatchMessage方法执行耗时，当超出阈值时，将该次获取的堆栈进行分析上报，从而捕捉卡顿信息，否则丢弃此次记录的堆栈信息。

这个Printer - mLogging在每个message处理的前后被调用，而如果主线程卡住了，不就是在dispatchMessage里卡住了吗？

在上面的loop循环的代码中，msg.target.dispatchMessage就是UI线程收到每一个消息需要执行的操作，都在其内部执行。系统在其执行的前后都会执行logging类的print方法，这个方法是可以自定义的。所以只要在运行的前后都添加一个时间戳，用运行后的时间减去运行前的时间，一旦这个时间超过了设定的阈值，就可以说这个操作卡顿，阻塞了UI线程，最后通过dump出此时的各种信息，来分析各种性能瓶颈。

核心流程图：

BlockPool 策略仅适用于 Federated HDFS 服务 block approach_android

该组件利用了主线程的消息队列处理机制，通过Looper.getMainLooper().setMessageLogging(mainLooperPrinter);并在mainLooperPrinter中判断start和end，来获取主线程dispatch该message的开始和结束时间，并判定该时间超过阈值(如2000毫秒)为主线程卡慢发生，并dump出各种信息，提供开发者分析性能瓶颈。

接下来看看这个monitor的println方法：

LooperMonitor.java：
@Override
public void println(String x) {
    //如果当前在调试中，那么直接返回，不做处理
    if (mStopWhenDebugging && Debug.isDebuggerConnected()) {
        return;
    }
    if (!mPrintingStarted) {
        //执行操作前
        mStartTimestamp = System.currentTimeMillis();
        mStartThreadTimestamp = SystemClock.currentThreadTimeMillis();
        mPrintingStarted = true;
        startDump();
    } else {
        //执行操作后
        final long endTime = System.currentTimeMillis();
        mPrintingStarted = false;
        //是否卡顿
        if (isBlock(endTime)) {
            notifyBlockEvent(endTime);
        }
        stopDump();
    }
}
private boolean isBlock(long endTime) {
    return endTime - mStartTimeMillis > mBlockThresholdMillis;
}

在ui操作执行前，将会记录当前的时间戳，同时会startDump。

在ui操作执行后，将会计算当前是否卡顿了，如果卡顿了，将会回调到onBlock的onBlock方法。同时将会停止dump。

为什么操作之前就开启了startDump，而操作执行之后就stopDump呢?

LooperMonitor.java：
private void startDump() {
    if (null != BlockCanaryInternals.getInstance( ).stackSampler) {
        BlockCanaryInternals.getInstance( ).stackSampler.start();
    }
    if (null != BlockCanaryInternals.getInstance( ).cpuSampler) {
        BlockCanaryInternals.getInstance( ).cpuSampler.start();
    }
}

其中start方法：

AbstractSampler.java:
public void start() {
    if (mShouldSample.get()) {
        return;
    }
    mShouldSample.set(true);
    HandlerThreadFactory.getTimerThreadHandl er().removeCallbacks(mRunnable);
    HandlerThreadFactory.getTimerThreadHandl er().postDelayed(mRunnable, BlockCanaryInternals.getInstance().getSampleDelay()); 
}

可以看到，startDump的时候并没有马上start，而是会postDelay一个runnable，这个runnable就是执行dump的真正的操作，delay的时间是设置的阈值的0.8倍，也就是，一旦stop在设置的延迟时间之前执行，就不会真正的执行dump操作。

AbstractSampler.java:
public void stop() {
    if (!mShouldSample.get()) {
        return;
    }
    mShouldSample.set(false);
    HandlerThreadFactory.getTimerThreadHandl er().removeCallbacks(mRunnable);
}

只有当stop操作在设置的延迟时间之后执行，才会执行dump操作。

AbstractSampler.java:
private Runnable mRunnable = new Runnable() {
    @Override
    public void run() {
        doSample();
        if (mShouldSample.get()) {
            HandlerThreadFactory.getTimerThreadHa ndler().postDelayed(mRunnable,mSampleInterval);
        }
    }
};

这个doSameple分别会dump出stack信息和cpu信息。

CpuSampler.java：
protected void doSample() {
    cpuReader = new BufferedReader(new InputStreamReader(new FileInputStream( "/proc/stat")), BUFFER_SIZE);
    String cpuRate = cpuReader.readLine();
    if (cpuRate == null) {
        cpuRate = "";
    }
    if (mPid == 0) {
        mPid = android.os.Process.myPid();
    }
    pidReader = new BufferedReader(new InputStreamReader(new FileInputStream( "/proc/" + mPid + "/stat")), BUFFER_SIZE);
    String pidCpuRate = pidReader.readLine();
    if (pidCpuRate == null) {
        pidCpuRate = "";
    }
    parse(cpuRate, pidCpuRate);
}
StackSampler.java：
 protected void doSample() {
    StringBuilder stringBuilder = new StringBuilder();
    for (StackTraceElement stackTraceElement : mCurrentThread.getStackTrace()) {
        stringBuilder.append( stackTraceElement.toString()).append(BlockInfo.SEPARATOR);
    }
    synchronized (sStackMap) {
        if (sStackMap.size() == mMaxEntryCount && mMaxEntryCount > 0) {
            sStackMap.remove( sStackMap.keySet().iterator().next());
        }
        sStackMap.put(System.currentTimeMillis(), stringBuilder.toString());
    }
}

这样，整个blockCanary的执行过程就完毕了。

4.总结

BlockCanary会在发生卡顿（通过MonitorEnv的getConfigBlockThreshold设置）的时候记录各种信息，输出到配置目录下的文件，并弹出消息栏通知（可关闭）。

简单的使用如在开发、测试、Monkey的时候，Debug包启用。

BlockCanary提供了一个友好的展示界面，供开发测试直接查看卡慢信息（基于LeakCanary的界面修改）。

dump的信息包括：

①基本信息：安装包标示、机型、api等级、uid、CPU内核数、进程名、内存、版本号等

②耗时信息：实际耗时、主线程时钟耗时、卡顿开始时间和结束时间

③CPU信息：时间段内CPU是否忙，时间段内的系统CPU/应用CPU占比，I/O占CPU使用率

④堆栈信息：发生卡慢前的最近堆栈，可以用来帮助定位卡慢发生的地方和重现路径

sample如下图，可以精确定位到代码中哪一个类的哪一行造成了卡慢。

本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。