BlockCanary界面卡顿检测

添加依赖:

  implementation  ‘com.github.markzhai:blockcanary-android:1.5.0‘

运行后会同时安装检测工具,主要检测UI线程运行卡顿现象

public class MainActivity extends AppCompatActivity {

    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        SystemClock.sleep(1000);
    }

    }

让主界面卡顿1秒

public class MyApplication extends Application {
    @Override
    public void onCreate() {
        super.onCreate();
        BlockCanary.install(this, new AppContext()).start();

    }

    public class AppContext extends BlockCanaryContext {
        //默认卡顿阈值为1000ms
        public int provideBlockThreshold() {
            return 1000;
        }
        //输出的log
        public String providePath() {
            return "/blockcanary/";
        }
        //支持文件上传
        public void upload(File zippedFile) {
            throw new UnsupportedOperationException();

        }
        //可以在卡顿提供自定义操作
        @Override
        public void onBlock(Context context, BlockInfo blockInfo) {
            System.out.println("阻塞操作");
        }
    }
}

检测到卡顿超过1秒输出日志

<application
        android:name=".MyApplication"
        android:allowBackup="true"
        android:icon="@mipmap/ic_launcher"

声明name属性

原文地址:https://www.cnblogs.com/Ocean123123/p/11025102.html

时间: 2024-11-07 15:58:07

BlockCanary界面卡顿检测的相关文章

Android 卡顿检测方案

应用的流畅度最直接的影响了 App 的用户体验,轻微的卡顿有时导致用户的界面操作需要等待一两秒钟才能生效,严重的卡顿则导致系统直接弹出 ANR 的提示窗口,让用户选择要继续等待还是关闭应用. 所以,如果想要提升用户体验,就需要尽量避免卡顿的产生,否则用户经历几次类似场景之后,只会动动手指卸载应用,再顺手到应用商店给个差评.关于卡顿的分析方案,已经有以下两种: 分析 trace 文件.通过分析系统的/data/anr/traces.txt,来找到导致 UI 线程阻塞的源头,这种方案比较适合开发过程

APP测试工具之TraceView卡顿检测

Traceview卡顿检测 Traceview是Android平台特有的数据采集和分析工具,集成在DDMS工具中,可以采集程序中的方法执行耗时.调用关系.调用次数以及资源占用等情况. 一.使用方法 1.启动虚拟机/连接手机,cmd命令输入ddms启动DDMS工具.打开手机上被测应用,在ddms上选择测试应用的进程.点击Start Method Profiling按钮,当按钮上的小红点变成黑色的时候,处于采集信息状态. 2.操作应用被测模块,操作完成后,点击Start Method Profili

TTS零基础入门之拒绝界面卡顿--加入线程

相信大多数做wpf 的人 都曾经为界面卡顿发过愁.尤其是当WPF遇到TTS 简直是可以回去睡一觉了... 关于这个问题,出过几个解决方案,有的治小病,有的治大病,还有的去根.今天就跟大家分享一下. TTS 是微软开发的,在它对外为数不多的属性中发现有一个这样的SpeechVoiceSpeakFlags类.这个类封装了多个播放方式,比较常用的是SVSFDefault(同步)和SVSFlagsAsync(异步),它们的区别在于当我用同步执行的时候,如果当前需要播报的语音列表没有播放完,它不会执行后面

android viewpager fragment切换时界面卡顿解决办法

目前开发的程序在切换View时界面卡顿现象比较严重,影响用户体验,当前项目共就四个View,每个View也只是按钮,所以可以同时加载,不让其它view销毁. 只需在Adapter中重载destroyItem类即可 @Override public void destroyItem(ViewGroup container, int position, Object object) { //重载该方法,防止其它视图被销毁,防止加载视图卡顿 //super.destroyItem(container,

iOS:性能之卡顿检测

项目地址:https://github.com/tunsuy/iOSMonitorLag 该项目主要是针对ios项目的卡顿监控的探索,结合ios的运行机制和业界的实践,将其应用于公司项目中进行试运行,查看相关效果 二. 方案一 基于RunLoop 1. 背景 因为UIKit本身的特性,需要将所有的UI操作都放在主线程执行,所以也造成不少程序员都习惯将一些线程安全性不确定的逻辑,以及其它线程结束后的汇总工作等等放到了主线,所以主线程中包含的这些大量计算.IO.绘制都有可能造成卡顿. 在Xcode中

防止界面卡顿

void DoEvents() { MSG msg; // Process existing messages in the application's message queue. // When the queue is empty, do clean up and return. while (::PeekMessage(&msg,NULL,0,0,PM_NOREMOVE)) { if (!AfxGetThread()->PumpMessage()) return; } } void

Android App 优化之消除卡顿

转载:http://gold.xitu.io/post/582583328ac247004f3ab124 1, 感知卡顿 用户对卡顿的感知, 主要来源于界面的刷新. 而界面的性能主要是依赖于设备的UI渲染性能. 如果我们的UI设计过于复杂, 或是实现不够好, 设备又不给力, 界面就会像卡住了一样, 给用户卡顿的感觉. 1.1 16ms原则 在剖析卡顿的原因之前, 我们先来了解下Android中著名的"16ms"原则: Android系统每隔16ms会发出VSYNC信号重绘我们的界面(A

Android 卡顿优化 2 渲染优化

1.概述 2015年初google发布了Android性能优化典范,发了16个小视频供大家欣赏,当时我也将其下载,通过微信公众号给大家推送了百度云的下载地址(地址在文末,ps:欢迎大家订阅公众号),那么近期google又在udacity上开了系列类的相关课程.有了上述的参考,那么本性能优化实战教程就有了坚实的基础,本系列将结合实例为大家展示如何去识别.诊断.解决Android应用开发中存在的性能问题.那么首先带来的就是大家最关注的渲染的性能优化(~~渲染就是把东西绘制到屏幕上). ps:本博客所

WPF 卡顿调试经验

原文:WPF 卡顿调试经验 1. 问题 最近的一个项目,正常调试情况下,运行一切正常,但是有某个用户登录后,出现界面卡顿2-3mins后,才正常运行. 2.解决问题方法 (1)首先由于是必现问题,就想在vs的工作环境下调试一下,看看到底是什么地方比较慢,想法很理想,但是现实很残酷,没有找到问题所在. (2)使用VS中的性能与诊断工具,测试一下那个地方花费的时间多,具体步骤如下: (a)打开VS中的菜单栏分析->性能与诊断 (b)选择性能向导,开始 (c)选择检测,测量函数调用计数与用时 (d)选