网站后缀有哪些,做网站分页,网站建设策划书格式及范文,ftp 企业网站简介
在应用开发中#xff0c;有的页面需要在列表中加载大量的数据#xff0c;就会导致组件数量较多或者嵌套层级较深#xff0c;从而引起组件负载加重#xff0c;绘制耗时增长。虽然可以通过组件复用避免组件重复创建#xff0c;但是如果每个列表项中包含的组件较多有的页面需要在列表中加载大量的数据就会导致组件数量较多或者嵌套层级较深从而引起组件负载加重绘制耗时增长。虽然可以通过组件复用避免组件重复创建但是如果每个列表项中包含的组件较多在转场或者列表滑动的时候列表项就会一次性加载大量的数据可能引起卡顿掉帧等性能问题。
转场场景
由于业务需求从当前页面进入一个新页面时会有转场动画播放并且在动画首帧中加载新页面所需要的数据。如果数据量较多那么动画首帧的响应时延就会变长导致后面的动画帧延迟播放产生卡顿的情况。 解决思路
既然转场时一次性加载大量的数据会导致卡顿情况那么将数据拆分成多份并分批次进行加载就是一种解决思路。ArkTS中提供了DisplaySync可变帧率可以设置帧回调监听让开发者在不同的帧中进行一些操作这样就可以将本来在一帧中加载的数据分到多帧中加载减少动画首帧的响应时间降低完成时延。
常规代码
在自定义列表组件中一次性加载全部数据可参考组件堆叠场景中的具体实现。
// CommonAppDevelopment/feature/componentstack/src/main/ets/view/ProductList.ets
Component
export struct ProductList {private productData: ProductDataSource new ProductDataSource();aboutToAppear(): void {this.productData.pushData(PRODUCT_DATA)}build() {WaterFlow() {LazyForEach(this.productData, (item: ProductDataModel) {FlowItem() {ItemView({ item: item })}}, (item: ProductDataModel) item.id.toString())}...}
}
这段代码里在aboutToAppear()接口中将数据放入productData中并通过瀑布流加载。编译运行后可以通过Trace图看到转场动画的首帧235970耗时21ms左右这是因为在点击进入页面时将6条数据全部放入瀑布流在235970帧中需要计算6个子组件的尺寸导致了响应时间增长。如果数据量更大那么这个时间会变得更长动画的卡顿效果就会更加明显。 优化代码
在aboutToAppear()接口中添加DisplaySync的帧回调并将数据拆分进行加载。
Component
export struct ProductList {private productData: ProductDataSource new ProductDataSource();private displaySync: displaySync.DisplaySync | undefined undefined;private frame: number 1;aboutToAppear(): void {// 创建DisplaySync对象this.displaySync displaySync.create();// 设置期望帧率const range: ExpectedFrameRateRange {expected: 120,min: 60,max: 120};this.displaySync.setExpectedFrameRateRange(range);// 添加帧回调this.displaySync.on(frame, () {if (this.frame 1) {hiTraceMeter.startTrace(firstFrame, 1);this.productData.pushData(PRODUCT_DATA.slice(0, 2))this.frame 1;hiTraceMeter.finishTrace(firstFrame, 1);} else if (this.frame 2) {hiTraceMeter.startTrace(secondFrame, 2);this.productData.pushData(PRODUCT_DATA.slice(2, PRODUCT_DATA.length));hiTraceMeter.finishTrace(secondFrame, 2);this.frame 1;this.displaySync?.stop();}});// 开启帧回调监听this.displaySync.start();}aboutToDisappear(): void {// 页面销毁时需要停止帧回调this.displaySync?.stop();}build() {// TODO: 知识点瀑布流容器由“行”和“列”分割的单元格所组成通过容器自身的排列规则将不同大小的“项目”自上而下如瀑布般紧密布局。WaterFlow() {LazyForEach(this.productData, (item: ProductDataModel) {FlowItem() {ItemView({ item: item })}}, (item: ProductDataModel) item.id.toString())}.nestedScroll({scrollForward: NestedScrollMode.PARENT_FIRST,scrollBackward: NestedScrollMode.SELF_FIRST}).columnsTemplate(1fr 1fr).columnsGap(COLUMNSGAP).rowsGap(ROWSGAP).padding({ bottom: $r(app.integer.component_stack_water_flow_padding_bottom) })}
}
在这段代码中aboutToAppear()接口中并没有一次性加载全部数据而是将数据拆分在帧回调中分成2次进行加载。编译运行后通过Trace图可以看到动画首帧232011的耗时是12ms。相较于优化前的代码不再是首帧占据大量的时间而是将耗时分摊到了后面的动画帧中。在点击进入页面时只放入了2条数据所以232011帧的Measure[WaterFlow]只需要计算2个子组件的尺寸并将剩余的4条数据放入productData让后面的一帧232013计算剩余子组件的尺寸。当数据量更大时可以将数据进行更多次拆分将不会直接出现在屏幕上的数据放到第二帧或者第三帧中进行加载降低首帧的响应时延进而减少转场动画的卡顿现象。 滑动场景
在日历应用中需要在一个List里面加载每个月的全部天数包括公历和农历日期这样在一个Item中就会有最少58条数据加载也就相当于需要58个组件。当列表滑动的时候通过组件复用的aboutToReuse()接口设置新的数据就会导致可能有58个组件一起刷新可能会引起掉帧卡顿现象。 解决思路
由于一次性加载大量数据、刷新大量组件会导致卡顿丢帧那么减少一次性加载的数据量就是一种解决方法。但是由于业务需求需要加载的数据总量和绘制的组件数量是不能减少的那么只能想办法将数据进行拆分将和数据相关的组件分成多次进行绘制。ArkTS中提供了DisplaySync可变帧率支持开发者设置回调监听可以在回调里做一些数据的处理在每一帧中加载少量的数据减少卡顿或者滑动动画的掉帧现象。
优化示例
常规代码
通常情况下会在aboutToReuse()中设置新的数据并一次性绘制所有的组件。
Entry
Component
struct Direct {...// 初始化日历中一年的数据initCalenderData() {...}aboutToAppear() {...this.initCalenderData();}build() {Column() {...List() {LazyForEach(this.contentData, (monthItem: Month) {// 每个月的日期ListItem() {ItemView({monthItem: monthItem,currentMonth: this.currentMonth,currentDay: this.currentDay})// 根据每月的天数设置复用ID组件复用时会选择相同ID的组件进行复用.reuseId(reuse_id_ monthItem.days.length.toString())}})}...}
}
Reusable
Component
struct ItemView {State monthItem: Month { month: , num: 0, days: [], lunarDays: [] };...aboutToReuse(params: Recordstring, Object): void {hiTraceMeter.startTrace(reuse_ (params.monthItem as Month).month, 1);this.monthItem params.monthItem as Month;hiTraceMeter.finishTrace(reuse_ (params.monthItem as Month).month, 1);}build() {Flex({ wrap: FlexWrap.Wrap }) {...// 日期信息ForEach(this.monthItem.days, (day: number, index: number) {...}, (index: number): string index.toString())}...}
}
在上面的代码中通过组件复用在ItemView的aboutToReuse()接口中将一个月的数据直接设置到状态变量monthItem中这样下面的Flex就会收到状态变量变更的消息通知从而刷新组件中的数据。编译运行后进入日历页面通过SmartPerf Host工具开始抓取Trace然后滑动列表到最底端结束Trace的抓取通过SmartPerf Host对抓取的Trace文件进行分析选中标签和相关数据区域可以得到图1。图中三个Actual Timeline标签分别代表应用和RenderService每帧的总耗时、应用每帧的绘制时间和RenderService层每帧的绘制时间render_service标签表示RenderService层每帧中的绘制操作example.display标签是应用的bundlename表示应用在每一帧中的操作包括创建组件、加载数据等。
图1 通过图中信息可以看到滑动期间的帧率是113帧按照手机120帧来计算滑动期间掉帧率约为5.8%。放大图1后可以看到应用每次加载新数据时图2中橙色部分RenderService层都会有一帧出现异常情况图2中黄色部分。此处对于图中颜色区域的解释可参考SmartPerf Host工具。
图2 将其中一部分继续放大后可以得到图3。选中Actual Timelinerender_service标签中的146272后可以通过箭头看到它所关联到的位置是Actual Timelineexample.display标签中的209136和209137即RenderService层出现的异常情况是由应用层中前面两帧里面的操作引起的。结合代码和箭头2的标签可以看到在209135中调用了aboutToReuse接口此时系统开始了组件复用的绘制操作。通过代码可以看到在aboutToReuse接口将一个月的所有数据全部放入了当前被复用的组件中并更新了所有的用于显示日期的Text组件中的数据箭头3diffIndexArray.lenght35表示有35个不同的元素这就导致209136需要计算35个子组件的尺寸箭头1从而引起146272的绘制时间延长。在列表数据量较少时其实并不会引起掉帧现象因为每次延长帧的时间都很短对帧率的影响较小但是在列表数据较多时就会因为延长帧过多发生掉帧现象。
图3 优化代码
通过DisplaySync中的帧回调方法将数据拆分到每一帧中进行加载和绘制。此处只需要修改自定义子组件ItemView中加载数据的方式所以与常规代码中相同的部分进行了省略。
首先需要在ItemView中第一次使用时创建DisplaySync对象设置期望帧率添加帧回调的监听然后进行启动。
Reusable
Component
struct ItemView {...aboutToAppear(): void {// 创建DisplaySync对象this.displaySync displaySync.create();// 初始化期望帧率let range: ExpectedFrameRateRange {expected: 120,min: 60,max: 120};// 设置期望帧率this.displaySync.setExpectedFrameRateRange(range);// 设置帧回调监听this.displaySync.on(frame, () {...});// 开启监听帧回调this.displaySync.start();... }...
}
然后在监听中添加更新数据的代码。这里将每个月的数据更新拆分开来第一步用来更新月份数据和计算总的执行步骤最后一步将计数数据初始化其余需要执行步骤的多少根据每次加载数据量会有所改变。
...
private temp: Month[] [];
...
this.displaySync.on(frame, () {// 数组中有数据时才开始执行if (this.temp.length 0) {if (this.step 0) {// 第一步放入月份数据并计算最多需要几帧完成数据操作hiTraceMeter.startTrace(reuse_ this.step, 1);this.month this.temp[0].month;this.monthNumber this.temp[0].num;this.year this.temp[0].year;this.maxStep this.maxStep Math.ceil(this.temp[0].days.length / this.MAX_EVERY_FRAME);hiTraceMeter.finishTrace(reuse_ this.step, 1);this.step 1;} else if (this.step this.maxStep - 1) {// 最后一步初始化部分计数数据this.temp.shift();this.step 0;this.maxStep 2;} else {hiTraceMeter.startTrace(reuse_ this.step, 1);// 计算从所有数据中取值时的开始索引 let start: number this.MAX_EVERY_FRAME * (this.step - 1);// 计算从所有数据中取值时的结束索引 let end: number (this.MAX_EVERY_FRAME * this.step) this.temp[0].days.length ? this.temp[0].days.length : this.MAX_EVERY_FRAME * this.step;// 更新日期数据 for (let i start; i end; i) {this.days[i] this.temp[0].days[i];this.lunarDays[i] this.temp[0].lunarDays[i];}hiTraceMeter.finishTrace(reuse_ this.step, 1);this.step 1;}}
});
...
最后在aboutToReuse接口中将数据放入数组中用于帧回调中开始执行数据更新。
aboutToReuse(params: Recordstring, Object): void {hiTraceMeter.startTrace(reuse_ (params.monthItem as Month).month, 1);this.temp.push(params.monthItem as Month);hiTraceMeter.finishTrace(reuse_ (params.monthItem as Month).month, 1);
}
编译运行后使用相同的方法查看优化后的Trace信息如图4所示。
图4 从图4中可以看到通过代码优化后帧率是正常的120帧了。然后将图4中的Trace结果放大后可以看到图5RenderService层出现的延长帧Actual Timelinerender_service标签中的黄色部分明显减少了已经不是优化前每次加载数据都会出现的情况了。
图5 下面将图5中的信息继续放大一些看一下现在每一帧里都做了什么操作如图6所示。在211618中开始调用aboutToReuse接口由于只是将数据放入一个数组中并没有更新复用组件中的数据所以这一帧并没有发生延长现象。在211619中开始逐步更新复用组件中的数据但是由于前一帧211618中并没有更新当前复用组件中的数据所以在211619中并不需要绘制组件所以此帧耗时依旧很短。结合代码可以看到在211620中放入了5天的日期数据由于前一帧211619只是设置了2条数据并且只有1条会更新组件this.month this.temp[0].month会更新显示月份的Text所以这一帧的绘制时间也不会超时。
图6 继续看后面的Trace信息如图7所示。和前一帧211621一样此帧中更新了5天的日期数据并且会重新测量上一帧211621中更新数据的5个Text组件尺寸箭头1而其余的组件由于数据并没有变动所以测量被略过了箭头2。后面的帧是类似的每次只会放入5天的数据并且更新上一帧中设置的数据所关联的Text组件。由于每次更新的组件数量较少每帧基本上都能在规定的时间内1秒120帧即8ms一帧绘制完成所以延长帧就会较少。这样不论列表中数据多还是少都不会引起掉帧现象的发生。
图7 不建议锁定最高帧率运行
不建议将ExpectedFrameRateRange中的expected、min、max都设置为120否则会干扰系统的可变帧率机制运行产生不必要的负载进而影响到整机的性能和功耗。
反例
let sync displaySync.create();
sync.setExpectedFrameRateRange({expected: 120,min: 120,max: 120
})
正例
let sync displaySync.create();
sync.setExpectedFrameRateRange({expected: 60,min: 0,max: 60
})
主要原因有以下三点
ExpectedFrameRateRange中关键参数是expected期望帧率系统会优先按照expected设置的帧率执行。当系统难以满足expected帧率诉求时会在min和max之间选一个更合适的帧率给到应用。如果应用锁定120HZ系统会优先满足应用的显式设置按照120帧运行。此时手机功耗会显著增加长时间运行会引起手机过热等严重影响用户体验的问题。同时也由于不必要的高帧率会额外占据更多的算力可能导致其他场景的响应受到不必要的延迟。如果系统持续按照120HZ运行从某种意义上来说此时系统的可变帧率能力已失效这显然与可变帧率的设计原则不相符。
总结
通过上面的示例代码和优化过程可以看到在列表中使用组件复用时一次性全部加载时可能会引起掉帧。虽然在数据量较少时单帧绘制的延长并不会引起掉帧但是数据量变多后这种延长帧的影响就会比较明显。合理进行数据拆分后可以有效减少延长帧的发生从而减少掉帧引起的性能问题。
FAQ
Q在ItemView中为什么要给ForEach设置第三个参数
A在组件复用中如果有用到ForEach必须设置第三个参数即给每个数据设置一个key否则ForEach中添加的组件不会被复用而是会全部重新创建。
Q对List中每一个ListItem的子组件都设置一个DisplaySync的帧回调监听会不会引起性能问题
A并不会通过示例中的Trace图可以看到除了正在被复用的ItemView的DisplaySync的回调监听外其余的监听耗时非常短对性能的影响可以忽略不计。如图8所示。
图8 Q为什么抓取到的Trace中没有示例中那么多的标签
A需要通过hdc shell命令开启标签
hdc shell
param set persist.ace.debug.enabled 1
param set persist.ace.trace.enabled 1
param set persist.ace.trace.layout.enabled true
param set const.security.developermode.state true
param set persist.ace.trace.build.enabled 1
最后
小编在之前的鸿蒙系统扫盲中有很多朋友给我留言不同的角度的问了一些问题我明显感觉到一点那就是许多人参与鸿蒙开发但是又不知道从哪里下手因为资料太多太杂教授的人也多无从选择。有很多小伙伴不知道学习哪些鸿蒙开发技术不知道需要重点掌握哪些鸿蒙应用开发知识点而且学习时频繁踩坑最终浪费大量时间。所以有一份实用的鸿蒙HarmonyOS NEXT文档用来跟着学习是非常有必要的。
为了确保高效学习建议规划清晰的学习路线涵盖以下关键阶段
GitCode - 全球开发者的开源社区,开源代码托管平台 希望这一份鸿蒙学习文档能够给大家带来帮助~ 鸿蒙HarmonyOS NEXT最新学习路线
该路线图包含基础技能、就业必备技能、多媒体技术、六大电商APP、进阶高级技能、实战就业级设备开发不仅补充了华为官网未涉及的解决方案
路线图适合人群
IT开发人员想要拓展职业边界零基础小白鸿蒙爱好者希望从0到1学习增加一项技能。技术提升/进阶跳槽发展瓶颈期提升职场竞争力快速掌握鸿蒙技术
2.视频学习教程学习PDF文档
HarmonyOS Next 最新全套视频教程 纯血版鸿蒙全套学习文档面试、文档、全套视频等
总结
参与鸿蒙开发你要先认清适合你的方向如果是想从事鸿蒙应用开发方向的话可以参考本文的学习路径简单来说就是为了确保高效学习建议规划清晰的学习路线
