logcat 在华为手机上运行时无法抓起log的问题

本文介绍了一种方法来开启手机设备的日志记录功能,通过输入特定代码进入隐藏菜单,进一步打开详细的LOG记录并设置其等级为VERBOSE,适用于调试及故障排查。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1.拨号界面输入  : *#*#2846579#*#*

2. 选择ProjectMenu--后台设置---LOG设置--LOG开关-- 点击开,点LOG级别选择VERBOSE.

3.重启机器 ok

 

 

转载于:http://sjbbs.zol.com.cn/2/613_11061.html

响应速度问题分析套路(以 Systrace 为主) 确认前提条件(老化,数据量、下载等)、操作步骤、问题现象,本地复现 需要明确测试标准 启动间的起点是哪里 启动机的终点是哪里 取所需的日志信息(Systrace、常规 log 等) 首先分析 Systrace,大概找出差异的点 首先查看应用耗点,分析对比机差异,这里可以把应用启动阶段分成好几段来看,来对比分析是哪部分间增加 Application 创建 Activity 创建 第一个 doFrame 后续内容加载 应用自己的 Message 分析应用耗的点 是否某一段方法自身执行耗比较久(Running 状态) –> 应用自身问题 主线程是否有大段 Running 状态,但是底下没有任何堆栈 –> 应用自身问题,加 TraceTag 或者使用 TraceView 来找到对应的代码逻辑 是否在等 Binder 耗比较久(Sleep 状态) –> 检测 Binder 服务端,一般是 SystemServer 是否在等待子线程返回数据(Sleep 状态) –> 应用自身问题,通过查看 wakeup 信息,来找到依赖的子线程 是否在等待子进程返回数据(Sleep 状态) –> 应用自身问题,通过查看 wakeup 信息,来找到依赖的子进程或者其他进程(一般是 ContentProvider 所在的进程) 是否有大量的 Runnable –> 系统问题,查看 CPU 部分,看看是否已经跑满 是否有大量的 IO 等待(Uninterruptible Sleep | WakeKill - Block I/O) –> 检查系统是否已经低内存 RenderThread 是否执行 dequeueBuffer 和 queueBuffer 耗 –> 查看 SurfaceFlinger 如果分析是系统的问题,则根据上面耗的点,查看系统对应的部分,一般情况要优先查看系统是否异常,参考上面列出的的系统原因,主要看下面四个区域(Systrace) Kernel 区域 查看关键任务是否跑在了小核 –> 一般小核是 0-3(也有特例),如果启动候的关键任务跑到了小核,执行速度也会变慢 查看频率是否没有跑满 –> 表现是核心频率没有达到最大值,比如最大值是 2.8Ghz,但是只跑到了 1.8Ghz,那么可能是有问题的 查看 CPU 使用率,是否已经跑满了 –> 表现是 CPU 区域八个核心上,任务和任务之间没有空隙 查看是否低内存 应用进程状态有大量的 Uninterruptible Sleep | WakeKill - Block I/O HeapTaskDeamon 任务执行频繁 kswapd0 任务执行频繁 SystemServer 进程区域 input 事件读取和分发是否有异常 –> 表现是 input 事件传递耗,比较少见 binder 执行是否耗 –> 表现是 SystemServer 对应的 Binder 执行代码逻辑耗 binder 等 am、wm 锁是否耗–> 表现是 SystemServer 对应的 Binder 都在等待锁,可以通过 wakeup 信息跟踪等锁情况,分析等锁是不是由于应用导致的 是否有应用频繁启动或者被杀 –> 在 Systrace 中查看 startProcess,或者查看 Event Log SurfaceFlinger 进程区域 dequeueBuffer 和 queueBuffer 是否执行耗 –> 表现是 SurfaceFlinger 的对应的 Binder 执行 dequeueBuffer 和 queueBuffer 耗 主线程是否执行耗 –> 表现是 SurfaceFlinger 主线程耗,可能是在执行其他的任务 Launcher 进程区域(冷热启动场景) Launcher 进程处理点击事件是否耗 –> 表现在处理 input 事件耗 Launcher 自身 pause 是否耗 –> 表现在执行 onPause 耗 Launcher 应用启动动画是否耗或者卡顿 –> 表现在动画耗或者卡顿 初步分析有怀疑的点之后 如果是系统的原因,首先需要看应用自身是否能规避,如果不能规避,则转给系统来处理 如果是应用自身的原因,可以使用 TraceView(AS 自带的 CPU Profiler)、Simple Perf 等继续查看更加详细的函数调用信息,也可以使用 TraceFix 插件,插入更多的 TraceTag 之后,重新取 Systrace 来对比分析 问题可能有很多个原因 首先要把影响最大的因素找出来优化,影响比较小的因素可以先忽略 有些问题需要系统的配合才能解决,这候需要跟系统一起进行调优(比如各大 App 厂商就会有专门跟手机厂商打交道的,手机厂商会以 SDK 的形式,暴露部分系统接口给 App 来使用,比如 Oppo 、华为、Vivo 等) 有些问题影响很小或者无解,这候需要跟测试同学沟通清楚 有些问题是重复问题或不同平台的相同,可以在 Bug 库中搜索是否有案例 帮我总结以上systrace中分析响应速度问题的过程,给我形成一个大致的思路和流程,给我讲明白
03-08
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值