- 综合排序
- 最热优先
- 最新优先
- 来自专栏李蔚蓬的专栏
Android卡顿优化 | 卡顿单点问题监测方案
ARTHook实战 小结 项目GitHub 背景介绍 前面提到过两种自动化自动化检测方案： AndroidPerformanceMonitor和ANR-WatchDog； 需要本方案的原因：自动化卡顿检测方案无法满足所有场景 ； 如，有很多Message要执行， 但是所有Message的时间， 都没有达到自动化卡顿检测方案所配置的卡顿的判定阈值， 那这种情况，自动化卡顿检测方案对这些“较小型”的卡顿问题便无能为力了； 可是这些没有达到卡顿的判定阈值的“较小型”的卡顿问题， 却会一直影响用户体验，这显然是不行的！！ 需要建立体系化的卡顿解决方案， 便要尽早地尽可能多地暴露问题，补充已有方案的不足； ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 需要关注的单点问题 View绘制等； 下面以主线程IPC为例， 因为IPC其实是一个很耗时的操作， 但实际开发时很多时候都没有得到足够的重视， 偶尔还会在主线程进行IPC操作，以及频繁的调用， 而这种耗时其实很少达到卡顿的阈值
2.9K20发布于 2020-04-09 - 来自专栏Android 进阶
卡顿优化
AndroidPerformanceMonitor implementation 'com.github.markzhai:blockcanary-android:1.5.0' AndroidPerformanceMonitor 是一个检测卡顿的开源库 而其使用与LeakCanary也比较相似，可以自主设置卡顿检测时间，检测到的卡顿同样是以Notification展示，在使用体验上也相当类似，与LeakCanary可以说是孪生兄弟。 提示框（Room表现不一，有些手机厂商会把提示框给去掉） ANR 解决方式 adb pull data/anr/traces.txt存储路径，然后分析CPU、IO及锁 ANR 测试 //给主线程造成卡顿 检测组件 https://github.com/SalomonBrys/ANR-WatchDog 使用：new ANRWatchDog().start(); 原理 ANR-WatchDog同样是一个检测卡顿的检测库 AndroidPerformanceMonitor与 ANR-WatchDog 区别 AndroidPerformanceMonitor：监控Msg ANR-WatchDog：看最终结果 前者适合监控卡顿
2.3K30发布于 2020-04-23 - 来自专栏IT杂症
photoshop卡顿问题
从网上下载的资源用PS打开有时候会很卡顿以下几个方法可以让PS很丝滑 删除冗余的元数据，如何查看元数据菜单（文件）--文件简介（alt+ctrl+shift+i）--原始数据 有时候会显示meta数据过大无法显示
2.3K20编辑于 2022-09-08 - 来自专栏葬爱家族
Android卡顿分析
一、卡顿原因 屏幕1秒60帧，平均每帧16.6毫秒，如果代码实现不佳，或者过于复杂，导致一帧绘制时间大于16.6毫秒，则无法完成绘制，造成丢帧，连续出现掉帧，在现象上表现为卡顿。 默认情况下，性能分析器只会将卡顿帧显示为有待调查的候选对象。在每个卡顿帧中，红色部分突出显示了相应帧超出其渲染截止时间的时长。 image.png 发现卡顿帧后，点击该帧；可根据需要按 M 键调整缩放程度以聚焦到所选帧。 若要调查导致卡顿的确切细节，您可以查看 Threads 部分，其中会显示与界面呈现有关的线程。 这些线程与界面呈现有关，可能是导致卡顿的原因。 如需在 Android 10 或更低版本上检测卡顿情况，请执行以下操作： 查看 Display 中的 Frames 轨迹。
3.5K20编辑于 2022-11-14 - 来自专栏Helloted
监测APP卡顿
这就是界面卡顿的原因。 所以，卡顿造成的原因分为CPU卡顿和GPU卡顿，CPU卡顿可以用CADisplayLink来检测，UI更新卡顿可以用Runloop的mode来检测 监测卡顿：开一个子线程，利用displaylink或者 Runloop来监测卡顿； 收集堆栈：将卡顿时的堆栈收集起来； 上传记录：将卡顿上传到后台或自定义； 这里我引用一张微信开发团队的监测流程图： 二、Runloop检测卡顿 首先我们来看一个 所以通过比较dispalylink的更新时间就可以知道是否存在卡顿 - (void)updateTime{ if (! 2、上传位置，一种是自己建立后台来统计这些卡顿，嫌麻烦的话是利用第三方平台、如友盟（统计崩溃比较多）、听云、OneApm、博睿，都大同小异。
2.1K10编辑于 2022-06-06 技术指南：实现云直播的“秒开”和低卡顿率
我们将探讨如何通过腾讯云直播服务实现“秒开”和低卡顿率，满足用户对直播服务的高要求。 技术解析 核心价值与典型场景 云直播技术通过实时传输视频内容，为用户提供低延迟、高画质的直播体验。 3大关键挑战 性能瓶颈：直播服务需要处理高并发访问，确保流畅播放，避免卡顿。 安全风险：直播内容易遭盗播，需要有效的安全防护措施。 成本控制：直播服务涉及大量数据传输，如何优化成本是一大挑战。 操作示例：在云直播控制台配置CDN加速，选择覆盖区域，确保全球用户都能获得低延迟访问。 步骤3：实施专业视频处理 原理说明：云端转码和音视频处理服务可以提升视频质量，适应不同播放环境。 步骤4：安全防盗 原理说明：通过IP黑白名单、referer黑白名单等技术防止盗播行为。 操作示例：在云直播控制台设置安全策略，如IP限制和URL加密。 以上指南提供了实现云直播“秒开”和低卡顿率的技术解析、操作指南及增强方案，旨在帮助用户利用腾讯云产品构建高效、安全、经济的直播服务。
30910编辑于 2025-07-29低代码平台的性能优化：解决页面卡顿、加载缓慢问题
低代码平台的性能优化：解决页面卡顿、加载缓慢问题 低代码平台的页面由“描述型 Schema + 运行时引擎 + 组件库”动态拼装而成，性能问题常来自大体量 Schema 解析、海量组件渲染、表达式计算、 滚动卡顿：列表渲染过多、布局/重绘频繁、事件处理未节流、动画未合成到合适的层。 操作延迟：INP 高，表达式/校验在主线程密集执行、状态更新产生级联重渲染。 低端设备/弱网：CPU/内存瓶颈、网络握手与下载慢、缓存命中率低。 加载阶段优化（把包与资源“变小、变快”） 代码分割：低代码构件按“页面级/组件族级/编辑器/运行时”拆分，import() 懒加载。 const start = Math.floor(scrollTop / itemHeight); const visible = Math.ceil(height / itemHeight) + 4;
29920编辑于 2025-12-15- 来自专栏iOS 备忘录
iOS卡顿优化
按照60FPS的帧率，每隔16ms就会有一次VSync信号，1秒是1000ms，1000/60 = 16 卡顿的原因： iOS默认刷新频率是60HZ，所以GPU渲染只要达到60fps就不会产生卡顿。 ； 实现成本低，单纯的采用CADisplayLink实现； 更适用于开发阶段。 RunLoop监听 原理：卡顿是在主线程进行了耗时的操作，可以添加Observer到主线程的Runloop中，通过Runloop状态切换的耗时，达到监控卡顿的目的。 卡顿监控起一个子线程定时检查主线程的状态，当主线程的状态运行超过一定的阈值，则认为主线程卡顿，从而标记为一个卡顿。 分析实现： 使用Runloop进行卡顿监控，定义一个阈值判断卡顿的出现，记录下来上报到服务器。
4.6K11发布于 2021-02-27 - 来自专栏快乐阿超
idea卡顿崩溃坑
青年时代的锻炼比黄金还贵——佚名 今天idea很卡，经常卡死动不了崩溃，明明内存分配了很高，使用率也很低，但还是卡死 最后把所有插件禁用掉，发现不卡了，于是一个插件一个插件启用，直到又出现崩溃
1.2K20编辑于 2023-07-21 - 来自专栏用户4624600的专栏
Android BlockCanary卡顿检测
前言 在日常业务测试中经常会发现页面跳转卡顿、滑动卡顿等等卡顿问题，但是往往发生了卡顿问题也没有什么具体信息提供给开发同学排查问题，所以也就不了了之了。 Blockcanary介绍 介绍 Blockcanary是@markzhai开发的检测app主线程卡顿工具，不需要在代码中插桩和debug代码就能检测出卡顿。 log日志 根据上面的配置代码并打包app，进行手工测试如果主线程卡顿超过1000ms，会在手机sdcard/BlockTest目录下生成卡顿日志。 卡顿文件包含几点: 发生时间 版本 imei cpu型号 内存 卡顿堆栈 上报log日志 之前方式的卡顿日志需要连接该设备把log手动导出来分析，或者在卡顿弹框中展示，这样并不能做到日志持久化和做后期的数据分析 项目 我们模拟一个Demo项目来模卡顿，点击block按钮后sleep2秒来模拟卡顿。 卡顿日志:
2.1K30编辑于 2022-12-05 - 来自专栏科控自动化
解决UI卡顿问题
视频演示：http://mpvideo.qpic.cn/0b2e4yaaiaaaa4alewnoojqvbzwdattaabaa.f10002.mp4? btnStartRead.Enabled = true; UiRefresh(null); } 正常运行时: 点击停止读: 正常读,拔掉通讯线,界面不卡:
4.4K12编辑于 2022-03-29 - 来自专栏测试开发
Android卡顿监控系统
，无法覆盖大量的可疑场景，测试重现耗时耗人力； 3、无法衡量静态页面的卡顿情况； 4、出现卡顿的时候app无法及时获取运行状态和信息，开发定位困难。 ，增加0.1%的CPU使用； 3）卡顿监控开启后，增加Davilk Heap内存约1MB； 4）对于流量，文件可按天写入，压缩文件最大约100KB，一天上传一次 痛点2：海量卡顿堆栈后该如何处理？ 这是一个权衡的过程，实际则按照一定的尝试效果后去划分层数，如微信iOS卡顿监控采用的策略是一级分类按最内层倒数2层分类，二级分类按最内层倒数4层。 ，按照卡顿上报重复的次数降序列出； 2、归类后展示每个卡顿的关键耗时代码，也可查看全部堆栈内容； 3、支持操作卡顿记录，如搜索卡顿，提tapd单，标注已解决等； 4、展示每个版本的卡顿问题修复数据情况， ，堆栈可尽量落到绘制帧过程中） 4、启动监控后，卡顿日志就会不断通过内部的writer输出，实现MonitorLogWriter.setDelegate才能获取这些日志，具体的日志落地和上报策略因为各个
8.5K52发布于 2018-07-03 - 来自专栏技术趋势
问题：tomcat启动卡顿
多配置中心，解决无法同步更新(nacos/consul) 问题背景 tomcat部署于linux centos 7.x 安装了jdk1.8和tomat8 发现，每次在启动tomcat的时候都会出现卡顿好久才会完成部署
1.7K20编辑于 2022-01-18 - 来自专栏sofu456
wpf绘制drawvisual卡顿
drawvisual wpf的控件frameworkelement、继承自visual，wpf的gui节点分为 visualtree，可见的ui树 logictree，xaml中的节点树 drawvisual卡顿 drawvisual数量增加后，有时出现卡顿现象，比对分析发现卡顿时的资源情况 drawvisual绘制完成后正确释放，否则大量的资源集中起来会造成绘制卡顿，如下图gc占了很多时间 io写入数据明显增加
1.3K20编辑于 2021-12-06 - 来自专栏三流程序员的挣扎
Android 优化——卡顿优化
丢帧给用户的感觉就是卡顿，而且如果运算过于复杂，丢帧会更多，导致界面常常处于停滞状态。 卡顿原因 过于复杂的布局 界面性能取决于 UI 的渲染性能，UI 渲染的整个过程由 CPU 和 GPU 两个部分协同完成。 如果 UI 布局层次太深，或是自定义控件的 onDraw 中有复杂运算，CPU 的相关运算就可能大于 16ms，导致卡顿。 过度绘制 UI 线程的复杂运算 UI 线程的复杂运算会造成 UI 无响应，导致 ANR，但更多的是造成 UI 响应停滞卡顿，ANR 是卡顿的极致。
2.8K20发布于 2018-09-11 - 来自专栏微信终端开发团队的专栏
Matrix TraceCanary -- 初恋·卡顿
什么是卡顿 什么是卡顿，很多人能马上联系到的是帧率 FPS (每秒显示帧数)。那么多低的 FPS 才是卡顿呢？又或者低 FPS 真的就是卡顿吗？ 一个稳定在 30FPS 的动画，我们不会认为是卡顿的，但一旦 FPS 很不稳定，人眼往往容易感知到。 FPS 低并不意味着卡顿发生，而卡顿发生 FPS 一定不高。 相比单看平均帧率，掉帧程度的分布可以明显的看出，界面卡顿（平均帧率低）的原因是因为连续轻微的掉帧（下图1），还是某次严重掉帧造成的（下图2）。 ? 一般也是从用户反馈中得到，通常表述为“新版本变卡了”，“朋友圈很卡”，“聊天经常无响应”，我们很难在这种描述中，直接洞察到卡顿的根源，甚至有些连卡顿的场景都不知道，很难准确重现，所以这种卡顿容易让人摸不着头脑 4、为了方便及高效记录函数执行过程，我们为每个插桩的函数分配一个独立 ID，在插桩过程中，记录插桩的函数签名及分配的 ID，在插桩完成后输出一份 mapping，作为数据上报后的解析支持。
4.7K41发布于 2019-01-11 - 来自专栏Bairuo的文章
UE4 EditorPIE比移动端卡顿的可能原因
这里主要考虑业务代码大体合理，由于引起引擎设计本身的卡顿，业务代码自身问题带来的卡顿另做考虑 1.注意SetActorLabel，编辑器中很多项目可能有在Outline中重命名物体显示各种id的需求（刚需 而UE的SetActorLabel会引起flush加载的，意思是只要你重命名，这个时候在异步加载的Package均会被flush，卡顿也就是显而易见的了。 但可惜UE4设计下就是不行，不是简单改一两行代码就能做到的，它背后涉及太多可以让你放弃这个想法。 UE4 Package加载的分析可以阅读一下别人的文章 UE4加载模块分析笔记（一） UE4加载模块分析笔记（二） 其实评论区就不止一个人有疑问，为什么Editor设计成这样，这也是我刚看到时的最大疑问 4.部分机器下电脑管家会影响，不一定所有人的机器都会遇到，但我确实遇到过，开启和关闭电脑管家立马就能感觉到了。
1.5K10编辑于 2022-11-18 技术指南：X-P2P技术实现低延迟与低卡顿率的腾讯云实践
摘要 本文旨在解析X-P2P技术的核心价值、实施挑战，并提供详细的腾讯云操作指南，以实现低延迟和低卡顿率的网络传输。通过对比通用方案和腾讯云方案，展示腾讯云产品在提升性能和可靠性方面的优势。 步骤4：服务接入与优化 原理说明：在X-P2P网络中，利用腾讯云的多网聚合加速产品，可以优化节点间的通信质量。 操作示例：根据提供的接入文档，实现服务接入，并利用腾讯云产品的特性进行优化。 增强方案 对比表格 特性 通用方案 腾讯云方案 延迟 较高延迟 低延迟，<100ms 卡顿率 高卡顿率 低卡顿率 安全性 通过上述步骤和方案，可以实现X-P2P技术在低延迟和低卡顿率方面的优化，同时利用腾讯云产品的特性，提升整体网络性能和安全性。
34510编辑于 2025-07-28- 来自专栏李蔚蓬的专栏
Android卡顿优化 | 卡顿及其优化工具概述及StrictMode实践案例
项目GitHub 本文要点 一般使用的卡顿优化工具 卡顿问题概述 卡顿问题分析难点 关于CPU Profiler 关于Systrace 关于StrictMode 磁盘读写违例检测实战 实例限制检测实战 一般使用的卡顿优化工具 CPU Profiler Systrace StrictMode （strict adj.精确的； 绝对的； 严格的，严谨的； [植]笔直的 mode n.方式； 状况； 时尚，风尚； 调式 模式；） 卡顿问题概述 很多性能问题（如内存占用高、耗费流量等）都相对不容易被发现， 但是卡顿问题却是很容易被直观感受到的； 卡顿问题较难排查、定位； 卡顿问题分析难点 可能的产生原因 繁杂：代码、内存、绘制、IO、【在主线程做UI处理、IO操作耗时操作】等； 线上卡顿问题，在线下难以复现， 卡顿问题跟用户届时的现场环境有很大的关系； 比如， 届时用户终端的磁盘IO空间不足，影响了 APP的IO写入性能， 导致APP卡顿，这样的场景有时候是很难复现的； 【最好在问题发生时候，就记录下来用户届时的场景】 关于CPU Profiler 图形的形式展示程序的执行时间、调用栈、执行次数等
2.7K20发布于 2020-04-01 - 来自专栏李蔚蓬的专栏
Android卡顿优化 | 自动化卡顿检测方案与优化(AndroidPerformanceMonitor BlockCanary)
，同时用logcat打印出关于卡顿的详细信息； 可以检测所有线程中执行的任何方法，又不需要手动埋点， 设置好阈值等配置，就“坐享其成”，等卡顿问题“愿者上钩”！！ 采集堆栈周期的 设定 4. 框架的 配置存储类 以及 文件系统操作封装 5. 文件写入过程（生成.log文件的源码） 6. 上传文件 7. 设计模式、技巧 8. 前提是T2-T1大于阈值，确定了是卡顿问题）的时刻， 方案才开始获取卡顿堆栈的信息， 而实际发生卡顿（如发生违例耗时处理过程）的时间点， 可能是在这个时间段内，而非获取信息的T2点， 那有可能 如此一来， 便能更清楚地知道在整个卡顿周期（阻塞开始到结束；Message分发、处理前到后）之内， 究竟是哪些方法在执行，哪些方法执行比较耗时； 优化卡顿现场不能还原的问题； 新问题：面对 高频卡顿堆栈信息的上报 、处理，服务端有压力； 突破点：一个卡顿下多个堆栈大概率有重复； 解决：对一个卡顿下的堆栈进行hash排重， 找出重复的堆栈； 效果：极大地减少展示量，同时更高效地找到卡顿堆栈； ---- 参考：
3K30发布于 2020-04-09
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号