HashMap
什么时候进行扩容呢
当hashmap中的元素个数超过数组大小*loadFactor时，就会进行数组扩容，loadFactor的默认值为0.75
EVENTLOG
am_proc_start:位于AMS.startProcessLocked，启动进程
am_anr: 位于AMS.appNotResponding
am_crash:位于AMS.handleApplicationCrashInner
…
Activity生命周期相关的方法:
am_on_resume_called: 位于AT.performResumeActivity
am_on_paused_called: 位于AT.performPauseActivity, performDestroyActivity
am_resume_activity: 位于AS.resumeTopActivityInnerLocked
am_pause_activity: 位于AS.startPausingLocked
am_finish_activity: 位于AS.finishActivityLocked, removeHistoryRecordsForAppLocked
am_destroy_activity: 位于AS.destroyActivityLocked
am_focused_activity: 位于AMS.setFocusedActivityLocked, clearFocusedActivity
am_restart_activity: 位于ASS.realStartActivityLocked
am_create_activity: 位于ASS.startActivityUncheckedLocked
am_new_intent: 位于ASS.startActivityUncheckedLocked
am_task_to_front: 位于AS.moveTaskToFrontLocked
am_proc_start (User|1|5),(PID|1|5),(UID|1|5),(Process Name|3),(Type|3),(Component|3) am_proc_start: [0,9227,10002,com.android.browser,content provider,com.android.browser/.provider.BrowserProvider2]
进程启动: UserId=0, pid=9227, uid=10002, ProcessName=com.android.browser, 数据类型=ContentProvider, 组件=com.android.browser/.provider.BrowserProvider2
性能优化
应用卡顿问题的原因比较多, 在数据埋点还没有完善的情况下, 更多的依赖 Systrace 来从全局的角度来分析卡顿的具体原因:
应用卡顿问题的原因比较多, 在数据埋点还没有完善的情况下, 更多的依赖 Systrace 来从全局的角度来分析卡顿的具体原因:
Systrace 分析
首先确认卡顿的 App
通过 App 的主线程和 SurfaceFlinger 的主线程信息可以确定卡顿的现场
分析 Systrace , Systrace 的分析需要一定的知识储备 : 需要知道 Systrace 每一个模块展示的内容是如何与用户感受到的内容相对应的 ; 需要知道 Systrace 上各个模块的交互式如何展示的 ; 需要知道 Binder 调用信息 ; 需要会看 Kernel 信息 (后续会继续完善 Systrace 系列)
如果是 App 主线程耗时, 则分析 App 主线程的原因 ( 案例里有 App 的卡顿原因 )
如果是 System 的问题, 则需要分析 System_Server \ SurfaceFlinger \ HWC \ CRTC \ CPU 等 ( 详细参考下面系统卡顿原因)
TraceView + 源码分析
使用 Systrace 确定原因后, 可以使用 TraceView 结合源码查看对应的代码逻辑 , Android Studio 的 Profile 工具可以以进程为单位 , 进行 Method 的 Profile , 可以打出非常详细的函数调用栈 , 并且可以与 Systrace 相对应
源码分析可以使用 Android Studio 进行断点调试 App 或者 Framework , 观察 Debug 信息是否与预期相符
很多问题也需要借助 Log 工具抓上来的 Log 进行分析 , Log 分析 Log 里面一些比较重要的点 (一般从 Log 里面很难确定卡顿的原因, 但是可以结合 Systrace 做一定的辅助分析)
截图 : 确定卡顿发生的时间点 \ 卡顿的界面 (如果没有尽量提供)
dumpsys meminfo 信息
dumpsys cpuinfo 信息
“Slow dispatch” 和 “Slow delivery” Log 信息
卡顿发生的一段时间内的 EventLog , 还原卡顿时候用户的操作
本地尝试复现
可以录高速录像, 观察细节,如果必现,可以让测试这边提供录像.
过滤 Log , 找到卡顿时候的异常 Log
多抓几份 Systrace , 有助于确定原因
可以让测试提供 LogReport 中没有的一些信息, 来分析当时用户的手机的整体的状态.
adb shell dumpsys activity oom
adb shell dumpsys meminfo
adb shell cat /proc/buddyinfo
adb shell dumpsys cpuinfo
adb shell dumpsys input
adb shell dumpsys window
说回流畅度 , 其实就是操作过程中的丢帧 , 本来一秒中画面需要更新 60 帧,但是如果这期间只更新了 55 帧
Android 平台性能导致的性能案例
1.SurfaceFlinger 主线程耗时
Android App 自身导致的性能问题
1.App 主线程执行时间长
主线程执行 Input \ Animation \ Measure \ Layout \ Draw \ decodeBitmap 等操作超时都会导致卡顿
2.uploadBitmap 耗时
3.BuildDrawingCache 耗时
4.使用 CPU 渲染而不是 GPU 渲染
5.主线程 Binder 耗时
6.游戏 SurfaceView 内容绘制不均匀
7.WebView 性能不足
8.帧率与刷新率不匹配
9.应用性能跟不上高帧率屏幕和系统
10.主线程 IO 操作
11.WebView 与主线程交互（ 如果 WebView 出现问题, 那么也会出现卡顿）
12.RenderThread 耗时
Systrace 会用不同的颜色来标识不同的线程状态
绿色 : 运行中.
蓝色 : 可运行
白色 : 休眠中
在绿色框架圆圈中指示在16.6毫秒内呈现的帧以保持每秒稳定60帧。 花费16.6毫秒以上渲染的帧用黄色或红色框圈表示
硬件加速，指的就是 GPU 加速，这里可以理解为用 RenderThread 调用 GPU 来进行渲染加速
Input 是以 InputReader 这里的分类，不仅包含触摸事件(Down、Up、Move) ， 可包含 Key 事件(Home Key 、 Back Key) . 这里我们着重讲的是触摸事件
Offset 为 0
1.第一个 Vsync 信号到来, SurfaceFlinger 和 App 同时收到 Vsync 信号
2.SurfaceFlinger 收到 Vsync-sf 信号，开始进行 App 上一帧的 Buffer 的合成
3.App 收到 Vsycn-app 信号，开始进行这一帧的 Buffer 的渲染(对应上面的第一、二、三、四阶段)
4.第二个 Vsync 信号到来 ，SurfaceFlinger 和 App 同时收到 Vsync 信号，SurfaceFlinger 获取 App 在第二步里面渲染的 Buffer，开始合成（对应上面的第五阶段），App 收到 Vsycn-app 信号，开始新一帧的 Buffer 的渲染(对应上面的第一、二、三、四阶段)
本文地址：https://blog.csdn.net/s762888517/article/details/107350400
如对本文有疑问， 点击进行留言回复！！
Codeforces C. A Cookie for You (模拟 / 分类 / 贪心) (Round #654 Div.2)
DialogFragment弹窗（带黑色透明背景和不带黑色透明背景）
android 常用布局文件（LinearLayout，RelativeLayout，FrameLayout，ConstraintLayout，TableLayout）
我要评论
网友评论