导读： 从开发、测试到上线时期，随着功能需求累加，人员规模扩大，项目越来越复杂，且迭代周期短，用户感知到多种多样的性能问题，但当前 Android Profiling/Analysis 工具存在着工具零散、不自动化、覆盖狭窄等缺陷，根本无法彻底解决所面临的问题，对于美团外卖开发团队来说，需要这样一款能够实现自动化收集真实性能数据、解放人力、主动预防的整合工具，由此研发了移动端性能监控解决方案——Hertz。

前言

性能问题是造成App用户流失的罪魁祸首之一。App的性能问题包括崩溃、网络请求错误或超时、响应速度慢、列表滚动卡顿、流量大、耗电等，而导致App性能低下的原因有很多，除去设备硬件和软件的外部因素，其中大部分是开发者错误地使用线程、锁、系统函数、编程范式、数据结构等导致的。即便是最有经验的程序员，也很难在开发时就能避免所有导致性能低下的“坑”，因此解决性能问题的关键是在于能不能尽早地发现和定位这些“坑”。

美团外卖在实践中通过总结常见性能问题，并在学习了业内微信、360等性能监控技术原理后，开发了一套移动端性能监控解决方案——Hertz（赫兹）。Hertz的目标是解决这三个时期的问题（如图1所示）：

• 开发时期，检查性能异常点并通知给开发者；
• 测试时期，和现有测试工具结合产生性能测试报告；
• 上线时期，通过监控平台上报性能数据，实现线上问题定位和追查。

监控指标

虽然用户可以感知到的性能问题多种多样，我们仍然可以将其抽象成具体的监控指标。这些监控指标包括：FPS、CPU 使用率、内存占用、卡顿、页面加载时间、网络请求流量等。其中，有的性能指标比较容易获取，例如FPS、CPU 使用率、内存占用等，有的性能指标不易获取，例如卡顿、页面加载时间、网络请求流量等。

比如，在 iOS 中我们可以这样获取 FPS：

    - (void)tick:(CADisplayLink *)link
    {
        NSTimeInterval deltaTime = link.timestamp - self.lastTime;
        self.currentFPS = 1 / deltaTime;
        self.lastTime = link.timestamp;
    }
在Android中我们可以这样获取内存占用：
    public long useSize() {
        Runtime runtime = Runtime.getRuntime();
        long totalSize = runtime.maxMemory() >> 10;
        this.memoryUsage = (runtime.totalMemory() - runtime.freeMemory()) >> 10;
        this.memoryUsageRate = this.memoryUsage * 100 / totalSize;
    }

上面的例子只是为了说明获取FPS、内存、CPU 这些指标非常简单，但是它们必须与其他数据结合才有意义，这些数据包括当前页面的信息、当前App运行时间，或卡顿发生时程序执行的堆栈和运行日志等。例如：CPU 和当前页面信息结合，可以评测每个页面的运算复杂度；内存和 App 运行时间结合，可以观察内存和使用时长的关系进而分析是否发生内存泄漏；FPS 和卡顿信息结合，可以评估这次卡顿发生时 App 的性能究竟下降到什么程度。

卡顿侦测

目前主流移动设备均采用双缓存+垂直同步的显示技术。大概原理是显示系统有两个缓冲区，GPU 会预先渲染好一帧放入一个缓冲区内，让视频控制器读取，当下一帧渲染好后，GPU 会直接将视频控制器的指针指向第二个容器。这里，GPU 会等待显示器的 VSync（即垂直同步）信号发出后，才进行新的一帧渲染和缓冲区更新。

大多数手机的屏幕刷新频率是60Hz，如果在1000/60=16.67ms内没有将这一帧的任务执行完毕，就会发生丢帧现象，这便是用户感受到卡顿的原因。这一帧的绘制任务包括 CPU 的工作和 GPU 的工作两部分，CPU 负责计算显示的内容，例如视图创建、布局计算、图片解码、文本绘制等，随后CPU将计算好的内容提交给 GPU，由 GPU 进行变换、合成、渲染。

除了 UI 绘制外，系统事件、输入事件、程序回调服务，以及我们插入的其他代码也都在主线程中执行，那么一旦在主线程里添加了操作复杂的代码，这些代码就有可能阻碍主线程去响应点击、滑动事件，以及阻碍主线程的 UI 绘制操作，这就是造成卡顿的最常见原因。

在了解屏幕绘制原理和卡顿形成的原因后，很容易想到，通过检测 FPS 就可以知道 App 是否发生了卡顿，也能够通过一段连续的 FPS 帧数计算丢帧率来衡量当前页面绘制的质量。然而实践发现 FPS 的刷新频率非常快，且容易发生抖动，因此直接以 FPS 来侦测卡顿是比较困难的。而检测主线程消息循环执行的时间就要容易得多，这也是业内常用的一种检测卡顿的方法。因此，Hertz 在实践中采用的就是检测主线程每次执行消息循环的时间，当这一时间大于阈值时，就记为发生一次卡顿。

在实践中我们发现，有的卡顿的连续性耗时较长，例如打开新页面时的卡顿；而有的卡顿连续性耗时相对较短但频次较快，如列表滑动时的卡顿。因此，我们采用了“N次卡顿超过阈值T”的判定策略，即一个时间段内卡顿的次数累计大于N时才触发采集和上报：举例，卡顿阈值T=2000ms、卡顿次数N=1，可以判定为单次耗时较长的卡顿；而卡顿阈值T=300ms、卡顿次数N=5，可以判定为频次较快的卡顿。

    Runnable loopRunnable = new Runnable() {
        @Override
        public void run() {
            if (mStartedDetecting && !isCatched) {
                nowLaggyCount++;
                if (nowLaggyCount >= N) {
                    blockHandler.onBlockEvent();
                    isCatched = true;
                    ...
                }
            }
        }
    };
    public void onMainLoopFinish(){
        if(isCatched){
            blockHandler.onBlockFinishEvent(loopStartTime,loopEndTime);
        }
        resetStatus();
        ...
    }

当检测到卡顿后，如何定位到造成卡顿的问题呢？如果能抓取到卡顿发生时程序的调用堆栈和运行日志，是不是很酷？的确，通过抓取堆栈可以非常有效地帮我们定位到造成卡顿的“问题代码”。

在实践中我们发现抓取堆栈有两个需要注意的问题。第一个是堆栈抓取的时机，必须在卡顿发生的当时，而不是之后，否则不能准确抓到造成卡顿的代码，因此我们在子线程中，当卡顿还没有结束时就会抓取堆栈。第二个问题是堆栈如何归类。卡顿堆栈的归类和Crash堆栈不同，以最内层代码归类显然是不合适的，因为外层不同的业务逻辑代码在最内层的调用堆栈有可能是相同的。以最外层代码归类也不合适，因为最外层代码有可能是业务逻辑代码，也有可能是系统调用。目前Hertz的做法是按照最内层归类的原则，并匹配一些简单的规则，以命中规则的类名来归类。

流量监控

移动端用户对于流量非常敏感，美团外卖偶尔会收到用户投诉说短时间内消耗了巨大流量的问题，因此我们思考能不能在 App 本地来统计用户的流量消耗，并上报给后台。这个统计不必精确到每个 API，能够粗略地归类计算出总流量消耗即可。

我们对于流量统计的维度是：自然日+请求来源+网络类型。为什么有了服务端流量监控，还需要在客户端本地监控流量呢？本地流量能够统计由 User 端发出的全部网络请求，而这点服务端监控是很难做到的。一个例子是并非所有的网络请求都会上报服务端监控；另一个例子是由于网络原因可能造成用户仅仅消耗了上行流量，但这些请求并没有到服务端。

在 iOS 中我们通过注册 NSURLProtocol 实现流量统计：

    - (void)connectionDidFinishLoading:(NSURLConnection *)connection
    {
        [self.client URLProtocolDidFinishLoading:self];

        self.data = nil;
        if (connection.originalRequest) {
            WMNetworkUsageDataInfo *info = [[WMNetworkUsageDataInfo alloc] init];
            self.connectionEndTime = [[NSDate date] timeIntervalSince1970];
            info.responseSize = self.responseDataLength;
            info.requestSize = connection.originalRequest.HTTPBody.length;
            info.contentType = [WMNetworkUsageURLProtocol getContentTypeByURL:connection.originalRequest.URL andMIMEType:self.MIMEType];
        [[WMNetworkMeter sharedInstance] setLastDataInfo:info];
        [[WMNetworkUsageManager sharedManager] recordNetworkUsageDataInfo:info];
    }
}

在 Android 中我们通过基于 Aspectj 的 AOP 方式拦截网络请求 API 实现流量统计：

    @Pointcut("target(java.net.URLConnection) && " +
            "!within(retrofit.appengine.UrlFetchClient) " +
            "&& !within(okio.Okio) && !within(butterknife.internal.ButterKnifeProcessor) " +
            "&& !within(com.flurry.sdk.hb)" +
            "&& !within(rx.internal.util.unsafe.*) " +
            "&& !within(net.sf.cglib..*)" +
            "&& !within(com.huawei.android..*)" +
            "&& !within(com.sankuai.android.nettraffic..*)" +
            "&& !within(roboguice..*)" +
            "&& !within(com.alipay.sdk..*)")
    protected void baseCondition() {

    }

    @Pointcut("call (org.apache.http.HttpResponse org.apache.http.client.HttpClient.execute(org.apache.http.client.methods.HttpUriRequest))"
            + "&& target(org.apache.http.client.HttpClient)"
            + "&& args(request)"
            + "&& !within(com.sankuai.android.nettraffic.factory..*)"
            + "&& baseClientCondition()"
    )
    void httpClientExecute(HttpUriRequest request) {
    }    

统计到总的流量消耗后，我们还希望对流量进行粗略的归类，方便定位问题。有两个因素是我们关心的：第一是请求来源，即流量消耗是来自 API 请求、H5还是CDN的；第二是网络类型，即 Wi-Fi、4G 还是 3G 流量。对于流量来源，我们首先通过域名做下简单的归类。以 iOS 为例，示例代码如下：

    - (NSString *) regApiHost {
        return _regApiHost ? _regApiHost :@"^(.*\\.)?(meituan\\.com|maoyan\\.com|dianping\\.com|kuxun\\.cn)$";
    }

    - (NSString *) regResHost {
        return _regResHost ? _regResHost : @"^(.*\\.)?(meituan\\.net|dpfile\\.com)$";
    }

    - (NSString *) regWebHost {
        return _regWebHost ? _regWebHost : @"^(.*\\.)?(meituan\\.com|maoyan\\.com|dianping\\.com|kuxun\\.cn|meituan\\.net|dpfile\\.com)$";
    }

但是某些域名可能既部署了 API 服务，又部署了 Web 服务。对于这类域名，我们还通过校验返回包的 MIMEType 作进一步的区分。以 iOS 为例，示例代码如下：

    + (BOOL)isPermissiveWebURL:(NSURL *)URL andMIMEType:(NSString *)MIMEType
    {
        NSRegularExpression *permissiveHost = [NSRegularExpression regularExpressionWithPattern:[[WMNetworkMeter sharedInstance] regWebHost]
                                                                                    options:NSRegularExpressionCaseInsensitive
                                                                                      error:nil];
        NSString *host = URL.host;
        return ([MIMEType isEqualToString:@"text/css"] || [MIMEType isEqualToString:@"text/html"] || [MIMEType isEqualToString:@"application/x-javascript"] || [MIMEType isEqualToString:@"application/javascript"]) && (host && [permissiveHost numberOfMatchesInString:host options:0 range:NSMakeRange(0, [host length])]);
    }

页面测速

要测量页面加载时间，我们要解决两个问题。第一，如何衡量一个页面的加载时间；第二，如何尽量不写或少写代码来实现测速。先看第一个问题，以 Android 为例，在 Activity 的创建加载过程中，会执行很多操作，例如设置页面主题、初始化页面布局、加载图片、获取网络数据或读写数据库等。上述操作的任何一个环节出现性能问题都可能导致画面不能及时显示，影响用户体验。Hertz将这些可能发生的操作抽象为图3所示的测速模型。

其中，T1 指页面初始化到第一个 UI 元素显示的时间，这个 UI 元素一般是指数据加载时的等待动画之类的。T2 是指网络请求时间，其开始点可能早于 T1 的结束点。T3 是加载到数据后，为 UI 填充数据并重新渲染完成的时间。T 是整个页面从初始化到最终UI绘制完成的时间。

对于第二个问题，如果每个时间点都需要人工写代码埋点的话，效率非常低并且容易出错。因此，Hertz 通过一个配置文件配置每个页面对应的 API，在 API 请求的基类中统一埋点。这个方案当然还有优化空间，例如 hook 关键节点上的 API 调用注入埋点代码。

    [{
      "page": "MainActivity",
      "api": [
        "/poi/filter",
        "/home/head",
        "/home/rcmdboard"
      ]
    },
    {
      "page": "RestaurantActivity",
      "api": [
        "/poi/food"
      ]
    }]

此外，还有一个问题是如何判定 UI 渲染完成？在 Android 中，Hertz 的做法是在 Activity 的 rootView 中插入一个 FrameLayout，并且监听这个 FrameLayout 是否调用了 dispatchDraw 方法实现的。当然，这个方案的缺点是由于插入了一级 View 导致层级嵌套变深。

    @Override
    protected void dispatchDraw(Canvas canvas) {
        super.dispatchDraw(canvas);
        if (!mIsComplete) {
            mIsComplete = mCallback.onDrawEnd(this, mKey);
        }
    }

在iOS中我们采取了不同的做法，Hertz 在配置文件中指定最终渲染页面的某个元素的 Tag，并在网络请求成功后开启 CADisplayLink 检查该元素是否出现在根节点下面。

    - (void)tick:(CADisplayLink *)link
    {
        [_currentTrackRecordArray enumerateObjectsUsingBlock:^(WMHertzPageTrackRecord * _Nonnull record, NSUInteger idx, BOOL * _Nonnull stop) {
            if ([self findTag:record.configItem.tag inViewHierarchy:record.rootView]) {
                [self endPageRenderEvent:record];
            }
        }];
    }

设计范式

在设计之初，考虑到 SDK 的可扩展性和易用性，我们做了很多考量。SDK 的框架如图4所示，整体上分为三层：最上层是接口层，提供极少量的对外暴露的方法，以及环境和配置参数等。第二层是业务层，包含了页面测速、卡顿检测 和 参数采集等所有的核心逻辑。第三层是数据适配层，将业务层产生的数据封装为统一的数据结构，并通过适配器适配到不同的输出通道上。

我们第一个考量的就是接口的易用性，Hertz 内置了三种运行模式，分别为开发、测试和线上。开发者只需要指定一种模式，就可以开始工作了。各种模式预设了 SDK 运行所需要的参数，例如采样频率、卡顿阈值、上报通道开关等，而监控指标的采集、卡顿的侦测、页面测速等逻辑都在内部自动执行。以 Android 为例，示例代码如下：

    final HertzConfiguration configuration = new HertzConfiguration.Builder(this)
            .mode(HertzMode.HERTZ_MODE_DEBUG)
            .appId(APP_ID)
            .unionId(UNION_ID)
            .build();
    Hertz.getInstance().init(configuration);

其次是 SDK 的可扩展性。以数据适配层为例，目前内置了五种适配通道，可以将采集到的监控数据适配到不同的数据通道。根据选择的工作模式不同，数据将被适配到服务端监控通道，生成测试报告，或者只在 App 本地输出日志和提示。这种设计带来的一个好处是，如果需要新增一种数据输出通道，既可以在上层添加一个拦截器，也可只改动 SDK 极少量的代码来添加一个适配器。同样地，性能采集模块和页面测速模块的设计也遵循这种思路。

实际用例

美团外卖在接入 Hertz 后，初步具备了发现、定位性能问题的能力，在开发、测试、线上三个阶段都对其进行了数据验证，接下来具体分享。

开发期应用

在开发期接入 Hertz 相当于集成了一个离线的性能检测工具，当检测到异常时，它能够将这些数据直接反馈给开发者，如图5所示。

运行时采集的数据会输出到日志中，而 App 的页面上也会插入一个浮层来展示当前的 FPS、CPU、内存等基本信息。如果检测到卡顿发生，会弹出提示页面并列出当前的执行堆栈。目前从卡顿检测结果来看，大部分堆栈日志可以比较明显的定位到有问题的代码，只要略微查看代码和分析原因，这些问题都能很容易的优化。

下面是初始化复杂 UI 造成卡顿的例子：

    android.content.res.StringBlock.nativeGetString(Native Method)
    android.content.res.StringBlock.get(StringBlock.java:82)
    android.content.res.XmlBlock$Parser.getName(XmlBlock.java:175)
    android.view.LayoutInflater.inflate(LayoutInflater.java:470)
    android.view.LayoutInflater.inflate(LayoutInflater.java:420)
    android.view.LayoutInflater.inflate(LayoutInflater.java:371)
    com.sankuai.meituan.takeoutnew.controller.ui.PoiListAdapterController.getView(PoiListAdapterController.java:77)
    com.sankuai.meituan.takeoutnew.adapter.PoiListAdapter.getView(PoiListAdapter.java:26)
    android.widget.HeaderViewListAdapter.getView(HeaderViewListAdapter.java:220)

下面是使用 Gson 反向解析字符串时造成卡顿的例子：

    com.google.gson.Gson.toJson(Gson.java:519)
    com.meituan.android.common.locate.util.GoogleJsonWrapper    $MyGson.toJson(GoogleJsonWrapper.java:236)
    com.sankuai.meituan.location.collector.CollectorJson    $MyGson.toJson(CollectorJson.java:216)
    com.sankuai.meituan.location.collector.CollectorFilter.saveCurrentData(CollectorFilter.java:67)
    com.sankuai.meituan.location.collector.CollectorFilter.init(CollectorFilter.java:33)
    com.sankuai.meituan返回首页] [打印] [返回上页]   下一篇