默认判定卡顿的阀值为什么是500ms而不是16ms呢？
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 25/100
- Issue 类型
- 文档
- 描述清晰度
- 需要澄清
- 活跃度
- 停滞
- 领域
- mobile, performance
调研方向
首先阅读记录主线程消息计时并将差值与500ms阈值进行比较的实现。追踪 issue 中所描述的 Android 帧调度假设；完成的标准是记录清楚为什么使用该阈值，以及它与16ms帧间隔的关系。
由索引模型根据 Issue 内容生成。
描述
看了原理：在主线程处理消息的前后记录时间，算出差值，与阀值进行比较从而判断卡顿
疑问：主线程处理消息时间差值为什么能判断卡顿呢？如果我的理解没错的话，主线程16ms一次接收到垂直信号，然后进行下一帧画面的绘制。那么这个绘制的消息的处理时间不应该不超过16ms吗？（不影响到下一次接收信号）
- 主要语言
- Java
- 星标
- 6.7k
- 派生
- 1k
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
markzhai/AndroidPerformanceMonitor 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 65/100
markzhai/AndroidPerformanceMonitor#144 · 4 条评论 · 1 个 reaction ·
-
难度 3/5 1-2 天 新手友好度 52/100
markzhai/AndroidPerformanceMonitor#154 · 2 条评论 ·
-
难度 5/5 一周以上 新手友好度 5/100
markzhai/AndroidPerformanceMonitor#153 · 5 条评论 · 1 个 reaction ·
-
这个库希望有人能维护一下未关闭
难度 5/5 一周以上 新手友好度 15/100
markzhai/AndroidPerformanceMonitor#149 · 5 条评论 · 3 个 reaction ·
-
如何保证捕获卡顿堆栈的准确性？未关闭
难度 4/5 3-5 天 新手友好度 25/100
查看 markzhai/AndroidPerformanceMonitor 的全部 Issue
相似的 Issue
-
Clock.MakeDate continues execution and returns a rolled-over instant after dispatching error on invalid date可能已有人在做 关联的 PR 仍在进行中或已合并。 未关闭
难度 1/5 1 小时以内 新手友好度 82/100
mit-cml/appinventor-sources#4155 ·
维护者通常 1 天内回复
-
难度 1/5 1-3 小时 新手友好度 62/100
Hira-shi/PW1-DAI-Carrel-Egal-Eyer#28 ·
维护者通常 1 天内回复
-
`GET /v1/event/token/{uuid}` can report a BOM upload as done before policy evaluation and metrics have finished可能已有人在做 @Zargath 今天认领。 未关闭defect in triage
难度 2/5 1-3 小时 新手友好度 72/100
DependencyTrack/dependency-track#7646 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 62/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 85/100
objectionary/eo-graphs#80 ·