当前位置：首页 > 闲鱼脚本 > 舆情治理方案整体设计基于现状问题，重新梳理和补充

舆情治理方案整体设计基于现状问题，重新梳理和补充

admin11个月前 (10-29)闲鱼脚本1115

微信号：xy916228
添加微信好友。免费测试。
复制微信号

舆情治理方案整体设计

基于现状问题，重新梳理和补充的舆情治理体系如下图：

线上舆情问题治理体系

下面会重点展开讲述的内容：

提升本地日志定位能力本地控制台日志补充

治理前期，大量业务日志进入了控制台日志，即便治理后将大量日志转入 tlog 日志，仍有部分日志流入控制台，如 Maven 引入独立模块和插件包模块。此外，部分未知异常问题，如视频绿屏、黑屏等，日志也提供了定位的可能性。

Log 模块提供了多种日志缓存类型，见 [1]，可通过命令获取对应类型的日志。这里，我们在用户反馈的时候，分别将、和类型读取并写入到本地文件，而后将日志同 tlog 文件一起打包通过 AUS 上传至 OSS。

// LOG_ID_MAIN 主应用程序log，-t 设置日志上限 20000
adb logcat -d -v threadtime -t 20000

// LOG_ID_EVENTS 系统事件信息
adb logcat -d -b events -v threadtime -t 6666

// LOG_ID_CRASH 应用程序 crash 日志
adb logcat -d -b crash -v threadtime -t 6666

.txt 内容

本地日志回捞能力

前面提到，由于在线命令推送成功率低且后台无命令缓存机制，所以闲鱼 App 本地日志回捞困难。为解决日志难以获取问题，舆情治理体系中设计了多种日志回捞策略，见下图所示。

本地日志回捞策略

本地日志下载查看流程

线上卡顿/ANR检测能力

线上用户反馈 ANR 并给出截图证明，因为没有卡顿日志，难以定位问题。

线上用户反馈黑屏，无有效日志难以定位问题

页面卡死的另一种表现

技术方案现状

在闲鱼 App 的混合工程场景，依托 Emas 平台已实现 iOS 端卡顿检测，端卡顿检测方案查看卡顿问题的监控与思考[2]，这节主要讲述端线上卡顿/ANR 检测。

在线下场景，端卡顿/ANR 检测手段已经很成熟，普通卡顿检测方案有[3]，ANR 检测可通过adb 查看 .txt 文件得到。然而在线上环境，以上卡顿检测方案就存在一定问题。

.txt 文件权限问题

在线上场景，为了监听识别是否发生 ANR 以及读取 ANR 内容，APP 需要监听 .txt 文件变化，并尝试读取 .txt 文件内容。监听文件的方案，在 6.0 及以后存在权限问题，大部分场景无法检测到 ANR

如以下代码执行在红米手机 11 上运行，为 ""，的路径为 "/"

File mSystemTraceFile;

...
this.mSystemTraceFilePath = "/data/anr/traces.txt";
this.mSystemTraceFile = new File(this.mSystemTraceFilePath);
if (!this.mSystemTraceFile.exists()) {
    String propSystemTraceFilePath = SystemPropertiesUtils.get("dalvik.vm.stack-trace-file");
    ...
    this.mSystemTraceFile = new File(propSystemTraceFilePath);
    ...
}
...

检测原理和性能问题核心原理

检测 500ms 卡顿

的核心原理是，设置 UI 线程的 . 字段，主线程每次处理消息均会执行 print 方法。

public void start() {
    if (!mMonitorStarted) {
        mMonitorStarted = true;
        Looper.getMainLooper().setMessageLogging(mBlockCanaryCore.monitor);
    }
}

.java[4]

public void setMessageLogging(@Nullable Printer printer) {
    mLogging = printer;
}

public static void loop() {
    ...
    for (;;) {
        ...
        // This must be in a local variable, in case a UI event sets the logger
        final Printer logging = me.mLogging;
        if (logging != null) {
            logging.println(">>>>> Dispatching to " + msg.target + " " +
                    msg.callback + ": " + msg.what);
        }
        ...
    }
}

.java

在 print 方法中时，触发工作，即取消上一次异步线程延迟任务，重新触发一次延迟任务，延迟时间为 * 0.8f （假设要检测 500ms 以上的卡顿堆栈，则延迟时间为 400ms）。若 UI 任务发生卡顿（>），则延迟任务被执行，且在卡顿期间的获取主线程堆栈信息，之后在下一次 print 方法被执行的时候，若确认发生卡顿，则可把主线程堆栈信息当做卡顿堆栈记录上报。

@Override
public void println(String x) {
    ...
    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();
    }
}

.java[5]

性能问题

在线上环境，大部分场景下并不会发生卡顿，但卡顿检测 SDK 会一直执行。可以发现 app 每一帧时间(16.6ms)，UI 中的任务会执行多次，最终产生大量的无效字符串拼接操作和大量小对象碎片。特别的，在线上低端机或者 cpu 负载较高的场景下，app 性能会因此降低，影响用户体感。

logging.println(">>>>> Dispatching to " + msg.target + " " +
                    msg.callback + ": " + msg.what);

卡顿检测方案方案设计

针对 .txt 读取权限问题，可通过检测主线程 5s 卡顿当做 anr。针对线上使用的性能问题，为降低延迟任务取消和触发频率，同时避免字符串对象频繁创建问题，必须放弃 . 的方案。重新思考为什么可以通过设置 . 检测卡顿？其满足 2 个条件：

闲鱼线上使用帧回调代替 Task 方案，同时满足以上 2 个条件：

此外，为避免方案延迟任务触发和取消的频率过高的问题，仅在帧回调处记录时间戳，不再取消延迟任务，但在延迟任务执行时判断是否发生卡顿，同时记录主线程堆栈。

假设 500ms 以上为卡顿，整体方案流程图如下：

定义 5s 以上卡顿为 ANR，为检测 ANR，同样通过 500ms 卡顿检测，并做卡顿堆栈聚合，当连续发生卡顿大于 5s 且堆栈信息不变，则认为发生 ANR。发生 ANR 时，记录当前设备 CPU 负载等信息。

检测效果

闲鱼首页卡片点击事件中故意制造 500ms 和 5s 卡顿查看卡顿检测结果。

// CardView61801.java

private void doOnClick(String redirectUrl, Map<String, String> trackParams) {
    if (null == mCardBean) return;

    try {
        Thread.sleep(500);
        // Thread.sleep(5000);
    } catch (Exception e) {
        e.printStackTrace();
    }
    ...
}