ANR及卡顿体验优化

置顶 已于 2022-09-30 14:11:52 修改
阅读量949 收藏 2
点赞数 1
分类专栏： Android Android——性能优化 文章标签： android 性能优化
于 2022-09-30 14:09:18 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/wzj_what_why_how/article/details/127118721
版权

ANR及卡顿体验优化

背景与意义

据统计，73%的性能问题都是由用户发现的，在这73%的问题中，严重性能问题占到
23%，遇到性能问题的用户有98%的会选择沉默，忍受、或离开，仅有2%的核心用户
才会进行投诉反馈。当应用出现崩溃、错误时会引起关键业务中断、收入减少等情况；又
如由于应用请求响应时间过长，启动较慢导致的终端用户体验下降；以及应用交互性能
慢引发的页面元素加载缓慢，造成ANR、卡顿或是页面元素加载不完整造成的布局错乱，种种
原因都会导致最终的用户流失。
因此，调研并落地ANR及卡顿体验优化是非常有必要并且极大作用于提高用户体验，减少用户流失。

ANR

ANR 全称Application Not Responding，即应用无响应。一般在测试人员进行Monkey测试的时候，ANR出现的概率会比较高。

ANR一般有三种类型

  • KeyDispatchTimeout(5 seconds) --主要类型按键或触摸事件在特定时间内无响应。（比较常见）
  • BroadcastTimeout(10 seconds)-- BroadcastReceiver 的 onReceive()函数运行在主线程中，在特定时间内无法处理完成。
  • ServiceTimeout(20 seconds) --小概率类型 Service的各个生命周期函数 在特定的时间内无法处理完成。

超时的原因一般有两种

  1. 当前的事件没有机会得到处理（UI 线程正在处理前一个事件没有及时完成或者 looper 被某种原因阻塞住）
  2. 当前的事件正在处理，但没有及时完成UI。（解决方案：线程尽量只做跟 UI 相关的工作，耗时的工作放在子线程处理。）
    （耗时任务包括：数据库操作，I/O，连接网络 或者其他可能阻碍 UI 线程的操作）

典型的ANR问题场景

  1. 耗时的网络访问
  2. 大量的数据读写
  3. 数据库操作
  4. 硬件操作（比如 camera)
  5. 调用 thread 的 join()方法、sleep()方法、wait()方法或者等待线程锁的时候
  6. service binder 的数量达到上限
  7. service 忙导致超时无响应
  8. 其他线程持有锁，导致主线程等待超时
  9. 其它线程终止或崩溃导致主线程一直等待

ANR的定位和分析

  1. 导出/data/data/anr/traces.txt，找出函数和调用过程，分析代码。
  2. 通过性能 LOG 人肉查找；可以找一些工具，比如使用 Bugly、Matrix等APM工具。

卡顿

卡顿问题分析

  1. 用户对卡顿的感知, 主要来源于界面的刷新. 而界面的性能主要是依赖于设备的UI 渲染性能。
  2. 如果我们的 UI 设计过于复杂, 或是实现不够友好，计算绘制算法不够优化, 设备又不给力, 界面就会像卡住了一样, 给用户卡顿的感觉。
  3. 如果应用界面出现卡顿不流畅的情况，很大原因是没有在16ms 完成你的工作。

16ms原则

  • Android 在不同的版本都会优化“UI 的流畅性”问题，但是直到在 android 4.1 版 本中做了有效的优化，这就是 Project Butter。
  • Project Butter 加入了三个核心元素: VSYNC、Triple Buffer 和 Choreographer。 其中，VSYNC 是理解 Project Buffer 的核心。
    • VSYNC：产生一个中断信号。
    • Triple Buffer：当双 Buffer 不够使用时，该系统可分配第三块 Buffer
    • Choreographer：这个用来接受一个 VSYNC 信号来统一协调 UI 更新
      （关于这三个核心元素具体的原理后续叙述。）

卡顿处理

下面我们就以下几种情况导致卡顿问题进行分析处理。

过于复杂的布局

界面性能取决于 UI 渲染性能. 我们可以理解为 UI 渲染的整个过程是由 CPU 和 GPU 两个部分协同完成的。 其中,

  • CPU 负责 UI 布局元素的 Measure, Layout, Draw 等相关运算执行.

  • GPU负责栅格化, 将 UI 元素绘制到屏幕上。 如果我们的 UI 布局层次太深, 或是自定义控件的 onDraw 中有复杂运算, CPU 的相关运算就可能大于 16ms, 导致卡顿。

    解决方案：

    • Android Studio 3.1以下的可以借助 Hierarchy Viewer[层级观察器] 这个工具来帮我们分析布局了。
    • HierarchyViewer 不仅可以以图形化树状结构的形式展示出 UI 层级, 还对每个节点给出了 三个小圆点, 以指示该元素 Measure, - - Layout, Draw 的耗时及性能。
    • 关于HierarchyViewer具体可以看官网的 《使用 Hierarchy Viewer 分析布局》
    • Android Studio 3.1 或更高版本的可以借助 Layout Inspector[布局检查器]
    • 关于Layout Inspector具体可以看官网的 《使用布局检查器和布局验证工具调试布局》

过度绘制

Overdraw: 用来描述一个像素在屏幕上多少次被重绘在一帧上.
通俗的说: 理想情况下, 每屏每帧上, 每个像素点应该只被绘制一次, 如果有多 次绘制, 就是 Overdraw, 过度绘制了。 常见的就是:绘制了多重背景或者绘制了 不可见的 UI 元素.

解决方案：
Android 系统提供了可视化的方案来让我们很方便的查看 overdraw 的现象:
在”系统设置”–>”开发者选项”–>”调试 GPU 过度绘制”中开启调试，此时界面可能会有五种颜色标识:overdraw indicator

  • 原色: 没有 overdraw
  • 蓝色: 1 次 overdraw
  • 绿色: 2 次 overdraw
  • 粉色: 3 次 overdraw
  • 红色: 4 次及 4 次以上的 overdraw
    一般来说, 蓝色是可接受的, 是性能优的。

分析与处理

方式一：Logcat本地日志信息

在Logcat日志信息可以看到主要包含如下内容：

  • 导致 ANR 的类名及所在包X
  • 发生 ANR 的进程名称及 ID
  • ANR 产生的原因(类型)
  • 系统中活跃进程的 CPU 占用率
    （对于一些生产包，不做处理的话则开发人员较难看到对应设备的Logcat日志，不过如果项目接入XLog工具之后，将可以拿到用户上传的Logcat日志进行辅助分析）

方式二：traces.txt文件

该文件对应位置在 /data/data/anr/traces.txt中，导出之后，可以找出函数和调用过程，分析代码。可以看到有助于问题定位的信息主要包括如下内容

  • 发生ANR的进程名称.ID,以及时间

  • 手机的CPU架构

  • 堆内存信息

  • 主线程基本信息

    • 线程名称
    • 线程优先级
    • 线程锁ID
    • 线程状态

  • 主线程的详细信息

    • 线程组名称
    • 线程被挂起的次数
    • 线程被调试器挂起的次数
    • 线理的Java对象地址
    • 线程本身的对象地址

  • 线程的调度信息。

    • Linux系统中内核线程U)
    • 线程调优优先级
    • 线程调度组
    • 线程调度策略和优先级
    • 线程处理函数地址

  • 线程的上下文消息

    • 线程调度状态
    • 线程在CPU中的执行时间、线程等待时间、线程执行的时间片长度
    • 线程在用户态中调度时间值
    • 线程在内核态中的调度时间值

  • 线程的堆栈位息。

    • 堆栈地址和大小
    • 堆栈信息

方式三：接入APM监控方案

目前有不少行业方案可以从一定程度上，帮助开发者快速定位到卡顿的堆栈，如 [BlockCanary]、[ArgusAPM]、[LogMonitor]、[Matrix]等。
另外， U-APM 和 Dokit 工具也有支持可以分析ANR和卡顿的相关功能，这里关于这两个工具就不多说明。
接下来对各类APM进行分析与对比。

APM

StrictMode

严格模式 StrictMode 是Android SDK提供的一个用来检测代码中是否存在违规操作的工具类,StrictMode 主要检测两大类：

  • 线程策略 ThreadPolicy:

    • detectCustomSlowCalls:检测自定义耗时操作。
    • detectDiskReads:检测是否存在磁盘读取操作。
    • detectDiskWrites:检测是否存在磁盘写入操作。
    • detectNetwork:检测是否存在网络操作。

  • 虚拟机策略VmPolicy

    • detectActivityLeaks:检测是否存在Activity泄漏。
    • detectLeakedClosableObjects:检测是否存在未关闭的Closable对象泄漏。
    • detectLeakedSqlLiteObjects:检测是否存在Sqlite对象泄漏。
    • setClassInstanceLimite:检测类实例个数是否超过限制。

可以看到,其中的ThreadPolicy可以用来检测可能存在的主线程耗时操作,解决这些检测到的问题能够减少应用发生ANR的慨率。
需要注意的是,我们只能在Debug版本中使用它. 发布到市场上的版本要关闭掉 StrictMode 的使用很简单,我们只需在应用初始化的地方例如 Application MainActivity 类的onCreate方法中执行如下代码即可。

@Override
protected void onCreate(Bundle savedlnstanceState) {
  if (BuildConfig.DEBUG){
        //开启线程模式
        StrictMode.setThreadPolicy(new StrictMode.Threadpolicy.Builder())
            .detectAll()
            .penaltyLog()
            .build();
        //开启虚拟机模式
        StrictMode.setVmPolicy(new VmPolicy.Builder()).detectAll().penaltyLog().build();
        super.onCreate(savedlnstanceState);
  }
}

上面的初始化代码调用penaltyLog表在Logcat中打印日志.调用 detectAll 方法表示启动 所有的检测策略,我们也可以根据应用的具体需求只开启某些策略.语句如下：

StrictMode.setThreadPolicy(new StrictMode.Threadpolicy.Builder)
  .detectDiskReads()
  .detectDiskWrites()
  .detectNetwork()
  .penaltyLog()
  .buildO);
StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
  .detectActivityLeaks()
  .detectLeakedSqlLiteObjects()
  .detectLeakedClosableObjects()
  .penaltyLog(）
  .build();

BlockCanary

BlockCanary 是一个非侵入式的性他监控函数库.它的用法和 LeakCanary 类似.只不过后者监控应用的内存泄漏,
而BlockCanary 主要用来监控应用主线程的卡顿，它的基本原理是利用主线程Looper的消息队列处理机制，监控每次 dispatchMessage 的执行耗时，
通过对比消息分发开始和结束的时间点来判断是否超过设定的时间，如果是，则判断为主线程卡顿。
它的集成很简单，首先在Build.gradle中添加依赖。然后在Application类中进行配置和初始化即可：

public void onCreate(){
	...
    //在主线程初始化调用
    BlockCannary.install(this, new AppBlockCanaryContext()).start();
}
public class AppBlockCanaryContext extends BlockCannaryContext{
    //实现各种上下文，包括应用标志服、用户uid、网络类型、卡慢判断阈值、Log保存位置等。
}

360的ArgusAPM

ArgusAPM是360移动端产品使用的可视化性能监控平台，为移动端APP提供性能监控与管理，可以迅速发现和定位各类APP性能和使用问题，帮助APP不断的提升用户体验。
其实现原理主要是依赖 Choreographer 模块，监控相邻两次 Vsync 事件通知的时间差。

简介：

ArgusAPM有以下几个特性：

  • 非侵入式：无需修改原有工程结构，无侵入接入，接入成本低。
  • 无性能损耗：ArgusAPM针对各个性能采集模块，优化了采集时机，在不影响原有性能的基础上进行性能的采集和分析。
  • 监控全面：目前支持UI性能、网络性能、内存、进程、文件、卡顿、ANR等各个维度的性能数据分析，后续还会继续增加新的性能维度。
  • Debug模式：支持开发和测试阶段、实时采集性能数据，实时本地分析的能力，帮助开发和测试人员在上线前解决性能问题。
  • 支持插件化方案：在初始化阶段进行设置，可支持插件接入，目前360手机卫士采用的就是在RePlugin插件中接入ArgusAPM，并且性能方面无影响。
  • 支持多进程采集：针对多进程的情况，我们做了相应的数据采集及优化方案，使ArgusAPM即适合单进程APP也适合多进程APP。

ArgusAPM目前支持如下性能指标：

  • 交互分析：分析Activity生命周期耗时，帮助提升页面打开速度，优化用户UI体验
  • 网络请求分析：监控流量使用情况，发现并定位各种网络问题
  • 内存分析：全面监控内存使用情况，降低内存占用
  • 进程监控：针对多进程应用，统计进程启动情况，发现启动异常（耗电、存活率等）
  • 文件监控：监控APP私有文件大小/变化，避免私有文件过大导致的卡顿、存储空间占用等问题
  • 卡顿分析：监控并发现卡顿原因，代码堆栈精准定位问题，解决明显的卡顿体验
  • ANR分析：捕获ANR异常，解决APP的“未响应”问题。

接入流程

一. Gradle配置 在 Project 的 build.gradle 文件中添加ArgusAPM的相关配置，示例如下：

在项目根目录的 build.gradle（注意：不是 app/build.gradle） 中添加以下配置：

buildscript {
    repositories {
        jcenter()
    }
	
    dependencies {
        classpath 'com.android.tools.build:gradle:2.2.3'
	classpath 'com.qihoo360.argusapm:argus-apm-gradle-asm:3.0.1.1001'
    }
}

allprojects {
    repositories {
        jcenter()
    }
}

二. AndroidManifest.xml配置

a. 权限相关

<!--需要申请如下权限-->
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.CHANGE_WIFI_STATE" />
<uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
<uses-permission android:name="android.permission.BATTERY_STATS" />
<uses-permission android:name="android.permission.READ_PHONE_STATE" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />

b. 组件使用 需要在AndroidManifest.xml里添加如下组件声明：

<provider
        android:name="com.argusapm.android.core.storage.ApmProvider"
		android:authorities="{当前应用的applicationId}.apm.storage"
		android:exported="false" />

三. 一个简单的SDK初始化代码

在项目的Application的attachBaseContext里调用如下代码即可

Config.ConfigBuilder builder = new Config.ConfigBuilder()
        .setAppContext(this)
        .setAppName("apm_demo")
		.setRuleRequest(new RuleSyncRequest())
		.setUpload(new CollectDataSyncUpload())
        .setAppVersion("0.0.1")
        .setApmid("apm_demo");
Client.attach(builder.build());
Client.startWork();

Matrix

对比

  • APM方案思想：
    以上的APM方案思想：监控主线程执行耗时，当超过阈值时，dump出当前主线程的执行堆栈，通过堆栈分析找到卡顿原因。
    从监控主线程的实现原理上，主要分为两种：

    1. 依赖主线程 Looper，监控每次 dispatchMessage 的执行耗时。
    2. 依赖 Choreographer 模块，监控相邻两次 Vsync 事件通知的时间差。

  • 存在的问题：
    这两种方案，可以较方便的捕捉到卡顿的堆栈，但其最大的不足在于，无法获取到各个函数的执行耗时，对于稍微复杂一点的堆栈，很难找出可能耗时的函数，也就很难找到卡顿的原因。
    另外，通过其他线程循环获取主线程的堆栈，如果稍微处理不及时，很容易导致获取的堆栈有所偏移，不够准确，加上没有耗时信息，卡顿也就不好定位。

  • 计算函数的执行耗时：
    可以在线上准确地捕捉卡顿堆栈，又能计算出各个函数执行耗时的方案。 而要计算函数的执行耗时，最关键的点在于如何对执行过程中的函数进行打点监控。有两种方式：

    1. 在应用启动时，默认打开 Trace 功能（Debug.startMethodTracing），应用内所有函数在执行前后将会经过该函数（dalvik 上 dvmMethodTraceAdd 函数 或 art 上 Trace::LogMethodTraceEvent 函数）， 通过 hook 手段代理该函数，在每个执行方法前后进行打点记录。

    2. 修改字节码的方式，在编译期修改所有 class 文件中的函数字节码，对所有函数前后进行打点插桩。
      第一种方案，最大的好处是能统计到包括系统函数在内的所有函数出入口，对代码或字节码不用做任何修改，所以对apk包的大小没有影响，但由于方式比较hook，在兼容性和安全性上存在一定的风险。
      第二种方案，利用 Java 字节码修改工具（如 BCEL、ASM、Javassis等），在编译期间收集所有生成的 class 文件，扫描文件内的方法指令进行统一的打点插桩，同样也可以高效的记录函数执行过程中的信息。
      相比第一种方案，除了无法统计系统内执行的函数，其它应用内实现的函数都可以覆盖到。而往往造成卡顿的函数并不是系统内执行的函数，一般都是我们应用开发实现的函数，所以这里无法统计系统内执行的函数对卡顿的定位影响不大。

此方案无需 hook 任何函数，所以在兼容性方面会比第一个方案更可靠。 Matrix-TraceCannary 便是选择了修改字节码的方案来实现，解决其它方案中卡顿堆栈无耗时信息的主要问题，来帮助开发者发现及定位卡顿问题。并且，本次调研后确定选用集成的APM方案也是这个方案。

Trace Canary特点

  • 编译期动态修改字节码, 高性能记录执行耗时与调用堆栈
  • 准确的定位到发生卡顿的函数，提供执行堆栈、执行耗时、执行次数等信息，帮助快速解决卡顿问题
  • 自动涵盖卡顿、启动耗时、页面切换、慢函数检测等多个流畅性指标
  • 准确监控ANR，并且能够高兼容性和稳定性地保存系统产生的ANR Trace文件

实现的核心思想：

通过向 Choreographer 注册监听，在每一帧 doframe 回调时判断距离上一帧的时间差是否超出阈值（卡顿），如果超出阈值，则获取数组 index 前的所有数据（即两帧之间的所有函数执行信息）进行分析上报。
同时，在每一帧 doFrame 到来时，重置一个定时器，如果 5s 内没有 cancel，则认为 ANR 发生，这时会主动取出当前记录的 buffer 数据进行独立分析上报，对这种 ANR 事件进行单独监控及定位。
（性能细节优化：（多次获取系统时间）：为了减少对性能的影响，通过另一条更新时间的线程每 5ms 去更新一个时间变量，而每个方法执行前后只读取该变量来减少性能损耗。）
（堆栈聚类问题：数据量很大而且后台很难聚类有问题的堆栈，所以在上报之前需要对采集的数据进行简单的整合及裁剪，并分析出一个能代表卡顿堆栈的 key，方便后台聚合。）

热门方案对比

APM方案对比.png
截图摘自Matrix Android TraceCanary

基本使用

  • 项目依赖：在项目根目录下的build.gradle文件添加Matrix依赖

      classpath ("com.tencent.matrix:matrix-gradle-plugin:2.0.5") { changing = true }

  • 在 app/build.gradle 文件中添加 Matrix 各模块的依赖

      apply plugin: 'com.tencent.matrix-plugin'
  
  matrix {
      trace {
          enable = true	//if you don't want to use trace canary, set false
          baseMethodMapFile = "${project.buildDir}/matrix_output/Debug.methodmap"
          blackListFile = "${project.projectDir}/matrixTrace/blackMethodList.txt"
      }
  }
  
  implementation group: "com.tencent.matrix", name: "matrix-android-lib", version: "2.0.5", changing: true
  implementation group: "com.tencent.matrix", name: "matrix-android-commons", version: "2.0.5", changing: true
  implementation group: "com.tencent.matrix", name: "matrix-trace-canary", version: "2.0.5", changing: true
  implementation group: "com.tencent.matrix", name: "matrix-resource-canary-android", version: "2.0.5", changing: true
  implementation group: "com.tencent.matrix", name: "matrix-resource-canary-common", version: "2.0.5", changing: true
  implementation group: "com.tencent.matrix", name: "matrix-io-canary", version: "2.0.5", changing: true
  implementation group: "com.tencent.matrix", name: "matrix-sqlite-lint-android-sdk", version: "2.0.5", changing: true
  implementation group: "com.tencent.matrix", name: "matrix-battery-canary", version: "2.0.5", changing: true
  implementation group: "com.tencent.matrix", name: "matrix-hooks", version: "2.0.5", changing: true

  • 接收Matrix处理后的数据 (参考 Matrix中sample-android示例代码 TestPluginListener )

      /**
   * 接收 Matrix 处理后的数据
   */
  public class TestPluginListener extends DefaultPluginListener {
  	public static final String TAG = "Matrix.TestPluginListener";
  	public TestPluginListener(Context context) {
  		super(context);
  
  	}
  
  	@Override
  	public void onReportIssue(Issue issue) {
  		super.onReportIssue(issue);
  		MatrixLog.e(TAG, issue.toString());
  
  		//add your code to process data
  	}
  }

  • 实现动态配置接口， 可修改 Matrix 内部参数. 在 sample-android 中 有个简单的动态接口实例DynamicConfigImplDemo.java, 其中参数对应的 key 位于文件 MatrixEnum中， 摘抄部分示例如下：

        public class DynamicConfigImplDemo implements IDynamicConfig {
      public DynamicConfigImplDemo() {}
  
      public boolean isFPSEnable() { return true;}
      public boolean isTraceEnable() { return true; }
      public boolean isMatrixEnable() { return true; }
      public boolean isDumpHprof() {  return false;}
  
      @Override
      public String get(String key, String defStr) {
          //hook to change default values
      }
  
      @Override
      public int get(String key, int defInt) {
           //hook to change default values
      }
  
      @Override
      public long get(String key, long defLong) {
          //hook to change default values
      }
  
      @Override
      public boolean get(String key, boolean defBool) {
          //hook to change default values
      }
  
      @Override
      public float get(String key, float defFloat) {
          //hook to change default values
      }
  }

  • 选择程序启动的位置对 Matrix 进行初始化，如在 Application 的继承类中， Init 核心逻辑如下：

        Matrix.Builder builder = new Matrix.Builder(application); // build matrix
    builder.pluginListener(new TestPluginListener(this)); // add general pluginListener
    DynamicConfigImplDemo dynamicConfig = new DynamicConfigImplDemo(); // dynamic config
    
    // init plugin 
    IOCanaryPlugin ioCanaryPlugin = new IOCanaryPlugin(new IOConfig.Builder()
                      .dynamicConfig(dynamicConfig)
                      .build());
    //add to matrix               
    builder.plugin(ioCanaryPlugin);
    
    //init matrix
    Matrix.init(builder.build());
  
    // start plugin 
    ioCanaryPlugin.start();

至此，Matrix就已成功集成到项目中，并且开始收集和分析性能相关异常数据。

参考资料：

wzj_what_why_how
关注
  • 1
    点赞
  • 踩
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
ANR工具篇 - 分析工具
Android百晓生的博客
05-11 495
ANRWatchdog + Crashlytic实现监控+上报，捕获线上ANR日志。ANRWatchdog：接入后在控制台打印类似Crash的疑似卡顿堆栈。 Matrix通过监听 SIGQUIT 信号，来达到监控 ANR 的目的。 Systrace + TraceView解决较为复杂，比较难定位的ANR。
ANR的监测与定位Demo
11-08
这种情况严重影响用户体验，因此开发者需要对ANR进行及时监控和定位。 本"ANR的监测与定位Demo"提供了这样一个工具，它能帮助开发者实时监测应用中的ANR问题，并在出现ANR时迅速定位到问题根源。在实际开发中，定位...
android ANR发生的原因总结和解决办法
qq_30723541的博客
08-30 943
ANR的全称是application not responding，意思就是程序未响应，类似于我们在windows上见到的程序未响应。ANR发生会使用户觉得我们的程序不友好，那么什么情况会导致ANR的发生呢？ 首先ANR的发生是有条件限制的，分为以下三点： 1.只有主线程才会产生ANR，主线程就是UI线程； 2.必须发生某些输入事件或特定操作，比如按键或触屏等输入事件，在BroadcastR
360 apm框架Argus源码解析（1）——开始
hunter800421的专栏
01-23 1178
开始 先看一个简单的代码示例，演示如何集成360 Argus APM： public class ArgusAPMApplication extends Application { @Override protected void attachBaseContext(Context base) { super.attachBaseContext(base); ...
2019最新Android常用开源库总结（附带github链接）
kongT。的博客
09-27 815
转载brave-sailor大神的笔记，自己记录一份，便于查阅 前言 收集了一些比较常见的开源库，特此记录（已收录350+）。另外，本文将持续更新，大家有关于Android 优秀的开源库，也可以在下面留言。 一 、基本控件 1.TextView HTextView一款支持TextView文字动画效果的Android组件库。 ScrollNumber滚动数字控件 ticker滚动数字控件 ReadMoreTextView阅读更多，折叠文本 ExpandableTextView折叠文...
性能优化系列（二）告别卡顿与 ANR —— 计算性能优化
jeanboy
12-05 1920
上一篇文章 渲染性能优化 中，我们分析了 UI 可能引起卡顿原因。卡顿的因素有很多，UI 只是其中一个因素。应用是否流畅往往也与 CPU 的计算性能有关，接下来我们从代码上来分析下引起性能问题的因素。 ArrayMap 与 HashMap ArrayMap 是 Android 提供的工具类，在 android.util.ArrayMap 中，ArrayMap 的使用方式与 HashMap 几乎没有...
深入探索Android稳定性优化
gqg_guan的博客
11-09 1202
深入探索Android稳定性优化
深入探索Android卡顿优化（下）1
08-03
在深入探索Android卡顿优化的过程中，我们需要关注多个关键点，包括ANR分析与实战、卡顿检测方案以及界面秒开等策略。首先，ANR（Application Not Responding）是Android系统中一个重要的性能问题，它通常发生在用户...
Android性能优化.pdf
12-22
【Android性能优化】是Android开发中的重要环节，涵盖了多个关键领域，包括ANR问题解析、crash监控方案、启动速度与执行效率优化、内存优化、耗电优化、网络传输与数据存储优化以及APK大小优化。 **ANR问题解析**是...
Android APP性能优化分析
01-20
Android APP性能优化是提升用户体验的关键，尤其是在Android系统中，由于其碎片化和兼容性问题，开发者需要更加关注应用的性能表现。Android系统虽然在不断优化，但国内许多用户使用的并非最新版本，而是厂商定制的...
360ArgusAPM:奇虎360 Argus APM android sdk源代码解读
03-23
360ArgusAPM 奇虎360 Argus APM android sdk源代码解读
微信终端跨平台组件 mars 系列（一） - 高性能日志模块xlog
10-12
微信终端跨平台组件 mars 系列（一） - 高性能日志模块xlog 微信终端跨平台组件 mars 系列（一） - 高性能日志模块xlog
Android性能优化 - ANR的分析、监控和解决
emmmsuperdan的博客
03-09 1786
1、首先我们搜索am_anr，找到出现ANR的时间点、进程PID、ANR类型、然后再找搜索PID，找前5秒左右的日志。2、过滤ANR IN 查看CPU信息3、接着查看traces.txt，找到java的堆栈信息定位代码位置，最后查看源码，分析与解决问题。到这里，通过上面三个步骤我们基本就能定位出来大部分ANR的来龙去脉了。下面是更多其他不同的ANR场景。
Android程序性能优化——ANR、卡顿优化，2024年最新安卓app界面开发
最新发布
2401_84166147的博客
04-11 801
今天关于面试的分享就到这里，还是那句话，有些东西你不仅要懂，而且要能够很好地表达出来，能够让面试官认可你的理解，例如Handler机制，这个是面试必问之题。有些晦涩的点，或许它只活在面试当中，实际工作当中你压根不会用到它，但是你要知道它是什么东西。最后在这里小编分享一份自己收录整理上述技术体系图相关的几十套腾讯、头条、阿里、美团等公司20年的面试题，把技术点整理成了视频和PDF（实际上比预期多花了不少精力），包含知识脉络 + 诸多细节，由于篇幅有限，这里以图片的形式给大家展示一部分。还有。
Android ANR 线上监控，日志收集分析
onelove_for的博客
06-26 1144
本文对anr进行全面的分析，目标解决遇到的所有anr问题。
【安卓稳定性之ANR】第一篇：安卓ANR问题综述
qq_23542165的博客
04-30 2674
本文针对anr问题分析的一般套路与技巧进行了总结与归纳。 以下所有内容均为本人的个人理解以及经验积累，偏向于实战若有任何问题，请给出建议及帮忙进行纠错。 通过本文的阅读，你将有以下收获： 1：了解什么是anr 2：了解anr的简单分析套路 3：了解攻克较难无响应问题的部分手段 一、安卓无响应问题概述 ANR，应用程序无响应即Application not Responding，以下简称“无响应”或“anr”。 在安卓系统中，当应用因为Java Exception与Native Exception发生异常.
性能优化-ANR总结
qq_37776700的博客
10-08 918
ANR总结
ANR的理论_anr概念/类型/原理/机制
lcj908692的博客
07-09 1352
ANR的学习以及分析
android 卡顿、ANR优化（1）屏幕刷新机制
z936689039的博客
03-08 772
本文通过阅读各种文章和源码总结出来的，如有不对，还望指出目录正文基础概念视觉暂留逐行扫描帧帧率、刷新率、画面撕裂画面撕裂Android屏幕刷新机制的演变单缓存（Android4.0之前）双缓存VSync（垂直同步）三缓存源码解析。
Android卡顿优化实战：ANR分析与界面秒开策略
在深入探索Android卡顿优化的系列...本文深入剖析了Android应用卡顿问题的多个方面，旨在帮助开发者提升应用的性能和用户体验。对于希望提高Android应用稳定性和响应速度的开发者来说，这是一篇不可忽视的参考资料。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值