相关问题
冷启动加载完成时延(离手帧为起始点)
579浏览 • 1回复 待解决
关于启动慢问题首帧卡顿分析
220浏览 • 1回复 待解决
响应时延/掉帧性能问题分析
671浏览 • 1回复 待解决
HarmonyOS 用启动首帧图片怎么全屏
207浏览 • 1回复 待解决
HarmonyOS冷启动相关性能分析
199浏览 • 1回复 待解决
冷启动加载耗时长,应用在设备上冷启动打开加载完成耗时XXXXms
907浏览 • 1回复 待解决
HarmonyOS Push点击冷启动跳转问题
263浏览 • 1回复 待解决
#鸿蒙学习大百科#如何避免阻塞首帧绘制?
112浏览 • 1回复 待解决
冷启动报错Error message
1879浏览 • 1回复 待解决
冷启动加载慢问题定位三板斧
745浏览 • 1回复 待解决
HarmonyOS 如何统计应用冷启动耗时
223浏览 • 1回复 待解决
如何提升应用冷启动速度?
288浏览 • 1回复 待解决
HarmonyOS 视频抽帧上传的完成链路
291浏览 • 1回复 待解决
#鸿蒙学习大百科#如何定位应用冷启动缓慢的问题?
113浏览 • 1回复 待解决
UIAbility的冷启动过程是怎样的?
449浏览 • 1回复 待解决
当前HarmonyOS是否支持低时延耳返
279浏览 • 0回复 待解决
OHAudio实现低时延音频录制和播放功能
1285浏览 • 1回复 待解决
应用启动框架AppStartup应用场景分析
325浏览 • 1回复 待解决
冷启动性能指标起止点查找方法
663浏览 • 1回复 待解决
指令数问题分析,如何抓取指令数进行问题拆解和分析。
545浏览 • 1回复 待解决
#鸿蒙学习大百科#什么是应用的冷启动和热启动?
178浏览 • 1回复 待解决
#鸿蒙学习大百科#如何提升应用冷启动的速度?
119浏览 • 1回复 待解决
HarmonyOS 如何自定义App冷启动的闪屏页
348浏览 • 1回复 待解决
#鸿蒙学习大百科#应用冷启动的流程是怎样的?
87浏览 • 1回复 待解决
Text组件如何实现首行缩进并文本超长时,以省略号结尾?
366浏览 • 1回复 待解决
应用启动可以分为冷启动和热启动:
冷启动首帧完成时延:指的是应用冷启动时,从点击离手开始到应用进程首帧送显上屏显示的这一段时间,称为冷启动首帧完成时延。
冷启动首帧完成时延的参考值为680ms,在定位冷启动时延相关问题时可以将此作为性能是否达标的一个参考。
性能参考起止点介绍
冷启动首帧完成时延的性能衡量的起点为用户点击应用图标离手点时间,止点为应用首帧送显的时间。
注意:如果应用启动时存在广告,需要减去广告时间,即冷启动首帧完成时延计算要去除广告时间。
问题定位思路
冷启动首帧完成时延问题的通用定位思路为先确认时延起止点,然后看起止点时延是否超参考值680ms,未超过则说明达标,超过则根据关键Trace信息将时延区间分为七个阶段:
1. input阶段(参考值:8ms)。
2. TP事件分发(参考值:15ms)。
3. 触发应用启动(参考值:20ms)。
4. 进程创建(参考值:15ms)。
5. 应用加载(参考值:15ms)。
6. Ability资源加载界面布局(参考值:500ms)。
7. 首帧渲染显示(参考值:20ms)。
分析时,优先看第6阶段Ability资源加载界面布局是否超过参考值500ms(应用进程耗时),如果超过则根据应用进程Trace信息分析耗时原因,并和应用侧对齐处理。如果是其他阶段耗时超过参考值,则根据实际情况找到耗时Trace并和对应领域对齐是否存在问题(通常情况下都是应用侧耗时导致超标,其他阶段可视情况是否需要分析),处理流程如下图:
确认起止点
冷启动首帧完成时延起点确认:冷启动首帧完成时延的起点是多模子系统收到硬件传递过来的离屏信号的Trace开始点。
起点Trace查找顺序:H:DispatchTouchEvent type=1(大桌面ohos.sceneboard) -> CPU Running Trace(多模子系统mmi_service)-> H:service report(多模子系统mmi_service)。
冷启动首帧完成时延止点确认:冷启动首帧完成时延的终点是应用进程启动后的第一帧。
在应用进程中找到首个H:ReceiveVsync Trace点代表应用进程启动后收到的首个垂直同步信号,这里就会开始绘制应用的首帧。
止点Trace查找顺序:H:ReceiveVsync(应用进程) -> H:FlushMessages(大桌面ohos.sceneboard)-> H:SendCommands(大桌面ohos.sceneboard)-> H:MarshRSTransactionData(大桌面ohos.sceneboard) -> H:RSMainThread::ProcessCommandUni(RS服务render_service)-> H:RSUniRender:FlushFrame(RS服务render_service)-> H:RSHardwareThread(RS送显线程RSHardwareThrea)。
找问题点
根据应用进程启动过程中的关键Trace点,我们可以将应用启动划分为:
1.input阶段 -> 2.TP事件分发 -> 3.触发应用启动 -> 4.进程创建 -> 5.应用加载 -> 6.Ability资源加载界面布局 -> 7.首帧渲染显示等七个部分,每个部分所属领域及参考耗时见下表:
序号
阶段(子系统)
起点Trace(泳道)
终点Trace(泳道)
参考耗时
1
input阶段(多模)
H:service report开始(mmi_service)
H:DispatchTouchEvent开始(render_service)
8ms
2
TP事件分发(大桌面)
H:DispatchTouchEvent开始(render_service)
AppExecFwk::BundleMgrProxy::QueryAbilityInfo结束(OS_SceneSession)
15ms
3
触发应用启动(元能力)
AppExecFwk::BundleMgrProxy::QueryAbilityInfo结束(OS_SceneSession)
AppExecFwk::AppSpawnClient::StartProcess开始(OS_FFRT)
20ms
4
进程创建(Appspawn)
AppExecFwk::AppSpawnClient::StartProcess开始(OS_FFRT)
AppExecFwk::AppSpawnClient::StartProcess结束(OS_FFRT)
15ms
5
应用加载(元能力)
AppExecFwk::AppSpawnClient::StartProcess结束(OS_FFRT)
AppExecFwk::MainThread::HandleLaunchApplication结束(应用进程)
15ms
6
Ability资源加载界面布局(应用)
AppExecFwk::MainThread::HandleLaunchApplication结束(应用进程)
首帧H:FlushMessages结束(应用进程)
500ms
7
首帧渲染显示(图形)
应用首个H:ReceiveVsync开始(应用进程)
H:RSHardwareThread::CommitAndReleaseLayers结束点(RSHardwareThrea)
20ms
注:这里耗时均为参考值,仅供定界参考。
分析应用侧耗时
从上表中可以看出第6阶段Ability资源加载界面布局(应用侧)是参考耗时最长的部分,所以我们优先分析第6阶段应用侧耗时是否超标,应用侧Trace区间如下图:
可以看到第6阶段耗时589ms,明显超出参考值500ms,所以可以判定为应用侧时延超标。通过观察应用进程这段Trace信息发现是H:PageRouterManager::RunPage这一个Trace耗时较长,大约413ms,进一步往下看发现是H:SourceTextModule::Instantiate和H:SourceTextModule::Evaluate这两部分耗时较长,至此基本确定了问题Trace点。
常见问题
1. 应用首页加载耗时较长导致应用冷启动首帧完成时延不达标
问题根因分析
正常H:PageRouterManager::RunPage Trace的时长在40ms左右。
问题Trace,H:PageRouterManager::RunPage耗时414ms,明显高于正常值。
查看Trace信息发现耗时主要集中在H:SourceTextModule::Instantiate和H:SourceTextModule::Evaluate两个Trace:
a. H:SourceTextModule::Instantiate异常点分析。
圈中该Trace范围,在下方详情中可以看到方法调用栈及耗时,可以看到AbilityRuntime::JsModuleReader::operator执行了很多次每次2.5ms左右,实际上里面调用的是AppExecFwk::BundleMgrProxy::GetBundleInfoForSelf方法,然后切到Slice List页签,这里可以看到函数的调用次数和耗时统计,发现GetBundleInfoForSelf调用了41次,总耗时109.3ms,到这里基本可以判断耗时长的原因是因为重复调用GetBundleInfoForSelf。
a. H:H:SourceTextModule::Evaluate异常点分析。
中间存在一段空白区域,耗时84ms,这里执行的是应用侧代码逻辑,需联系应用侧结合具体代码分析耗时原因。
优化方案
a. GetBundleInfoForSelf 调用41次,原因是import hsp包时会获取hsp的路径信息,从而调用了GetBundleInfoForSelf。单hap场景下,模块推荐使用多har,不推荐使用hsp,hsp是采用动态加载,会增加编译耗时、响应时延会出现多次调用。
b. 应用侧问题由应用侧分析修改。
应用Ability的onCreate回调耗时较长导致应用冷启动首帧完成时延不达标
问题根因分析
Trace点H:virtual void OHOS::AbilityRuntime::JsUIAbility::OnStart(const OHOS::AbilityRuntime::Want &, sptrAAFwk::SessionInfo)对应的Ability生命周期函数onCreate的回调函数,其中H:napi_value OHOS::AbilityRuntime::JsUIAbility::CallObjectMethod耗时376ms, 这个是在执行应用侧JS代码。
优化方案
应用侧排查Ability生命周期函数onCreate是否存在耗时操作,是否可优化。
首页so加载耗时较长导致应用冷启动首帧完成时延不达标
问题根因分析
H:PageRouterManager::LoadPage下的H:JSPandaFileExecutor::ExecuteFromFile代表加载首页时的so加载,这里看到导入耗时208ms,通过分析应用首页代码发现是因为引入了photobrowser大图组件,多引入了90+so文件导致so加载时间变长。
去除photobrowser大图组件后,so加载耗时降低到92ms。
优化方案
首页尽量不要引入过多无用组件或非必要组件,对于非常用页面及引入耗时长so的页面可以采用动态加载的方式进行优化。
冷启动Trace抓取方法
Step1:打开DevEco Studio的Profiler -> 选择设备进程 -> Frame模式 -> Create Session -> 启动录制。
注意:第二步选择进程时不要选择要录制的进程,因为要录制的进程需要处于未启动状态,这里是通过录制其他进程间接录制目标进程的启动Trace信息。
Step2: 启动录制后,在设备上点击应用图标启动要录制的目标应用(点击到离手时间稍微长点,否则可能录制不到点击事件的Trace),等到应用首页加载后,点击停止结束录制。
Step3:录制完成后会工具会分析展示Trace数据。
冷启动首帧完成时延Trace点解读
冷启动首帧完成时延之后的关键Trace区间主要体现在应用进程启动阶段,关键Trace为H:static void OHOS::AppExecFwk::MainThread::Start(),这是进程启动的Trace打点,该Trace点下主要包含如下Trace:
序号
所属泳道
Trace点
Trace点描述
1
应用进程
H:void OHOS::AppExecFwk::MainThread::HandleLaunchApplication
应用对象创建及相关资源依赖模块加载
2
应用进程
H:void OHOS::AppExecFwk::MainThread::HandleLaunchAbility
Ability对象创建及相关资源依赖模块加载
3
应用进程
H:void OHOS::AbilityRuntime::UIAbilityThread::HandleAbilityTransaction
该阶段主要是AbilityStage/Ability的启动生命周期,执行相应的生命周期回调
4
应用进程
H:Napi complete, name:getRawFileContent
加载本地资源
5
应用进程
H:Napi complete, name:JsWindowStage::OnLoadContent
加载首页内容
6
应用进程
H:PageRouterManager::RunPage
页面路由预处理及页面绘制(这里是出问题频率比较高的地方)