HarmonyOS开发实战（ Beta5版）组件复用-精准控制组件刷新范围最佳实践

概述

在滑动场景下，常常会对同一类自定义组件的实例进行频繁的创建与销毁。此时可以考虑通过组件复用减少频繁创建与销毁的能耗。组件复用时，可能存在许多影响组件复用效率的操作，本篇文章将重点介绍如何通过组件复用四板斧提升复用性能。

组件复用四板斧：

  • 减少组件复用的嵌套层级，如果在复用的自定义组件中再嵌套自定义组件，会存在节点构造的开销，且需要在每个嵌套的子组件中的aboutToReuse方法中实现数据的刷新，造成耗时。
  • 优化状态管理，精准控制组件刷新范围，在复用的场景下，需要控制状态变量的刷新范围，避免扩大刷新范围，降低组件复用的效率。
  • 复用组件嵌套结构会变更的场景，使用reuseId标记不同结构的组件构成，如：使用if else结构来控制组件的创建，会造成组件树结构的大幅变动，降低组件复用的效率。需使用reuseId标记不同的组件结构，提升复用性能。
  • 不要使用函数/方法作为复用组件的入参，复用时会触发组件的构造，如果函数入参中存在耗时操作，会影响复用性能。

组件复用原理机制

组件复用机制图

优化状态管理，精准控制组件刷新范围使用

1.使用AttributeUpdater精准控制组件属性的刷新，避免组件不必要的属性刷新

复用场景常用在高频的刷新场景，精准控制组件的刷新范围可以有效减少主线程渲染负载，提升滑动性能。正反例如下：

反例：

  1. @Component
  2. export struct LessEmbeddedComponent {
  3.   aboutToAppear(): void {
  4.     momentData.getFriendMomentFromRawfile();
  5.   }
  6.  
  7.   build() {
  8.     Column() {
  9.       Text('use nothing')
  10.       List({ space: ListConstants.LIST_SPACE }) {
  11.         LazyForEach(momentData, (moment: FriendMoment) => {
  12.           ListItem() {
  13.             OneMomentNoModifier({ color: moment.color })
  14.               .onClick(() => {
  15.                 console.log(`my id is ${moment.id}`)
  16.               })
  17.           }
  18.         }, (moment: FriendMoment) => moment.id)
  19.       }
  20.       .width("100%")
  21.       .height("100%")
  22.       .cachedCount(5)
  23.     }
  24.   }
  25. }
  26.  
  27. @Reusable
  28. @Component
  29. export struct OneMomentNoModifier {
  30.   @State color: string | number | Resource = "";
  31.  
  32.   aboutToReuse(params: Record<string, Object>): void {
  33.     this.color = params.color as number;
  34.   }
  35.  
  36.   build() {
  37.     Column() {
  38.       Text('这是标题')
  39.         Text('这是内部文字')
  40.           .fontColor(this.color)// 此处使用属性直接进行刷新，会造成Text所有属性都刷新
  41.           .textAlign(TextAlign.Center)
  42.           .fontStyle(FontStyle.Normal)
  43.           .fontSize(13)
  44.           .lineHeight(30)
  45.           .opacity(0.6)
  46.           .margin({ top: 10 })
  47.           .fontWeight(30)
  48.           .clip(false)
  49.           .backgroundBlurStyle(BlurStyle.NONE)
  50.           .foregroundBlurStyle(BlurStyle.NONE)
  51.           .borderWidth(1)
  52.           .borderColor(Color.Pink)
  53.           .borderStyle(BorderStyle.Solid)
  54.           .alignRules({
  55.             'top': { 'anchor': '__container__', 'align': VerticalAlign.Top },
  56.             'left': { 'anchor': 'image', 'align': HorizontalAlign.End }
  57.           })
  58.     }
  59.   }
  60. }

上述反例的操作中，通过aboutToReuse对fontColor状态变量更新，进而导致组件的全部属性进行刷新，造成不必要的耗时。因此可以考虑对需要更新的组件的属性，进行精准刷新，避免不必要的重绘和渲染。

noModifier1

优化前，由H:ViewPU.viewPropertyHasChanged OneMomentNoModifier color 1标签可知，OneMomentNoModifier自定义组件下的状态变量color发生变化，与之相关联的子控件数量为1，即有一个子控件发生了标脏，之后Text全部属性会进行了刷新。

此时，H:CustomNode:BuildRecycle耗时543μs，Create[Text]耗时为4μs。

noModifier2

noModifier3

正例：

  1. import { AttributeUpdater } from '@ohos.arkui.modifier';
  2.  
  3. export class MyTextUpdater extends AttributeUpdater<TextAttribute> {
  4.   private color: string | number | Resource = "";
  5.  
  6.   constructor(color: string | number | Resource) {
  7.     super();
  8.     this.color = color
  9.   }
  10.  
  11.   initializeModifier(instance: TextAttribute): void {
  12.     instance.fontColor(this.color) // 差异化更新
  13.   }
  14. }
  15.  
  16. @Component
  17. export struct UpdaterComponent {
  18.   aboutToAppear(): void {
  19.     momentData.getFriendMomentFromRawfile();
  20.   }
  21.  
  22.   build() {
  23.     Column() {
  24.       Text('use MyTextUpdater')
  25.       List({ space: ListConstants.LIST_SPACE }) {
  26.         LazyForEach(momentData, (moment: FriendMoment) => {
  27.           ListItem() {
  28.             OneMomentNoModifier({ color: moment.color })
  29.               .onClick(() => {
  30.                 console.log(`my id is ${moment.id}`)
  31.               })
  32.           }
  33.         }, (moment: FriendMoment) => moment.id)
  34.       }
  35.       .cachedCount(5)
  36.     }
  37.   }
  38. }
  39.  
  40. @Reusable
  41. @Component
  42. export struct OneMomentNoModifier {
  43.   color: string | number | Resource = "";
  44.   textUpdater: MyTextUpdater | null = null;
  45.  
  46.   aboutToAppear(): void {
  47.     this.textUpdater = new MyTextUpdater(this.color);
  48.   }
  49.  
  50.   aboutToReuse(params: Record<string, Object>): void {
  51.     this.color = params.color as string;
  52.     this.textUpdater?.attribute?.fontColor(this.color);
  53.   }
  54.  
  55.   build() {
  56.     Column() {
  57.       Text('这是标题')
  58.       Text('这是内部文字')
  59.         .attributeModifier(this.textUpdater) // 采用attributeUpdater来对需要更新的fontColor属性进行精准刷新，避免不必要的属性刷新。
  60.         .textAlign(TextAlign.Center)
  61.         .fontStyle(FontStyle.Normal)
  62.         .fontSize(13)
  63.         .lineHeight(30)
  64.         .opacity(0.6)
  65.         .margin({ top: 10 })
  66.         .fontWeight(30)
  67.         .clip(false)
  68.         .backgroundBlurStyle(BlurStyle.NONE)
  69.         .foregroundBlurStyle(BlurStyle.NONE)
  70.         .borderWidth(1)
  71.         .borderColor(Color.Pink)
  72.         .borderStyle(BorderStyle.Solid)
  73.         .alignRules({
  74.           'top': { 'anchor': '__container__', 'align': VerticalAlign.Top },
  75.           'left': { 'anchor': 'image', 'align': HorizontalAlign.End }
  76.         })
  77.     }
  78.   }
  79. }

上述正例的操作中，通过AttributeUpdater来对Text组件需要刷新的属性进行精准刷新，避免Text其它不需要更改的属性的刷新。

useUpdater1

优化后，在H:aboutToReuse标签下没有H:ViewPU.viewPropertyHasChanged标签，后续也没有Create[Text]标签。此时，H:CustomNode:BuildRecycle耗时415μs

优化效果

在正反例中，针对列表滑动场景中，单个列表项中Text组件字体颜色属性的修改，反例中采用了普通组件属性刷新方式实现，正例中采用了AttributeUpdater动态属性设置方式实现。

优化后的H:CustomNode:BuildRecycle OneMomentNoModifier的耗时，如下表所示：

次数反例：使用@State(单位μs)正例：使用AttributeUpdater(单位μs)
1357338
2903494
3543415
4543451
5692509
平均607441

不同设备和场景都会对数据有影响，该数据仅供参考。

所以，Trace数据证明，精准控制组件的刷新范围可以有效减少主线程渲染负载，提升滑动性能。

因为示例中仅涉及一个Text组件的属性更新，所以优化时间绝对值较小。如果涉及组件较多，性能提升会更明显。

2.使用@Link/@ObjectLink替代@Prop减少深拷贝，提升组件创建速度

在父子组件数据同步时，如果仅仅是需要父组件向子组件同步数据，不存在修改子组件的数据变化不同步给父组件的需求。建议使用@Link/@ObjectLink替代@Prop，@Prop在装饰变量时会进行深拷贝，在拷贝的过程中除了基本类型、Map、Set、Date、Array外，都会丢失类型。正反例如下：

反例：

  1. @Entry
  2. @Component
  3. struct lessEmbeddedComponent {
  4.   aboutToAppear(): void {
  5.     getFriendMomentFromRawfile();
  6.   }
  7.  
  8.   build() {
  9.     Column() {
  10.       TopBar()
  11.       List({ space: ListConstants.LIST_SPACE }) {
  12.         LazyForEach(momentData, (moment: FriendMoment) => {
  13.           ListItem() {
  14.             OneMoment({moment: moment})
  15.           }
  16.         }, (moment: FriendMoment) => moment.id)
  17.       }
  18.       .cachedCount(Constants.CACHED_COUNT)
  19.     }
  20.   }
  21. }
  22.  
  23. @Reusable
  24. @Component
  25. export struct OneMoment {
  26.   @Prop moment: FriendMoment;
  27.     
  28.   build() {
  29.     Column() {
  30.       ...
  31.       Text(`${this.moment.userName}`)
  32.       ...
  33.     }
  34.   }
  35. }
  36.  
  37. export const momentData: FriendMomentsData = new FriendMomentsData(); 
  38.     
  39. export class FriendMoment {
  40.   id: string; 
  41.   userName: string; 
  42.   avatar: string; 
  43.   text: string; 
  44.   size: number; 
  45.   image?: string; 
  46.  
  47.   constructor(id: string, userName: string, avatar: string, text: string, size: number, image?: string) {
  48.     this.id = id;
  49.     this.userName = userName;
  50.     this.avatar = avatar;
  51.     this.text = text;
  52.     this.size = size;
  53.     if (image !== undefined) {
  54.       this.image = image;
  55.     }
  56.   }
  57. }

上述反例的操作中，父子组件之间的数据同步用了@Prop来进行，各@Prop装饰的变量在初始化时都在本地拷贝了一份数据。会增加创建时间及内存的消耗，造成性能问题。

优化前，子组件在初始化时都在本地拷贝了一份数据，BuildItem耗时7ms175μs。

useProp

正例：

  1. @Entry
  2. @Component
  3. struct lessEmbeddedComponent {
  4.   @State momentData: FriendMomentsData = new FriendMomentsData();
  5.   aboutToAppear(): void {
  6.     getFriendMomentFromRawfile();
  7.   }
  8.  
  9.   build() {
  10.     Column() {
  11.       TopBar()
  12.       List({ space: ListConstants.LIST_SPACE }) {
  13.         LazyForEach(momentData, (moment: FriendMoment) => {
  14.           ListItem() {
  15.             OneMoment({moment: moment})
  16.           }
  17.         }, (moment: FriendMoment) => moment.id)
  18.       }
  19.       .cachedCount(Constants.CACHED_COUNT)
  20.     }
  21.   }
  22. }
  23.  
  24. @Reusable
  25. @Component
  26. export struct OneMoment {
  27.   @ObjectLink moment: FriendMoment;
  28.     
  29.   build() {
  30.     Column() {
  31.       ...
  32.       Text(`${this.moment.userName}`)
  33.       ...
  34.     }
  35.   }
  36. }
  37.     
  38. @Observed
  39. export class FriendMoment {
  40.   id: string; 
  41.   userName: string; 
  42.   avatar: string; 
  43.   text: string; 
  44.   size: number; 
  45.   image?: string; 
  46.  
  47.   constructor(id: string, userName: string, avatar: string, text: string, size: number, image?: string) {
  48.     this.id = id;
  49.     this.userName = userName;
  50.     this.avatar = avatar;
  51.     this.text = text;
  52.     this.size = size;
  53.     if (image !== undefined) {
  54.       this.image = image;
  55.     }
  56.   }
  57. }

上述正例的操作中，父子组件之间的数据同步用了@ObjectLink来进行，子组件@ObjectLink包装类把当前this指针注册给父组件，会直接将父组件的数据同步给子组件，实现父子组件数据的双向同步，降低子组件创建时间和内存消耗。

优化效果

在正反例中，针对列表滑动场景，反例采用@Prop修饰的变量，来进行父子组件间的数据同步。子组件在初始化时@Prop修饰的变量，都在本地拷贝了一份数据，增加了组件创建的时间；正例采用@ObjectLink来进行父子组件间的数据同步，把当前this指针注册给父组件，减少了组件创建的时间。

优化后，子组件直接同步父组件数据，无需深拷贝，BuildItem耗时缩短为7ms1μs。

useLink

所以，Trace数据证明，使用@Link/@ObjectLink替代@Prop减少深拷贝，可以提升组件创建速度。

因为示例中仅涉及一个简单对象FriendMoment的深拷贝，所以优化时间绝对值较小。如果涉及变量较多、对象较复杂，性能提升会更明显。

3.避免对@Link/@ObjectLink/@Prop等自动更新的状态变量，在aboutToReuse方法中再进行更新

在父子组件数据同步时，如果子组件已经使用@Link/@ObjectLink/@Prop等会自动同步父子组件数据、且驱动组件刷新的状态变量。不需要再在boutToReuse方法中再进行数据更新，此操作会造成不必要的方法执行和变量更新的耗时。正反例如下：

反例：

  1. @Entry
  2. @Component
  3. struct LessEmbeddedComponent {
  4.   @State momentData: FriendMomentsData = new FriendMomentsData();
  5.   aboutToAppear(): void {
  6.     getFriendMomentFromRawfile();
  7.   }
  8.  
  9.   build() {
  10.     Column() {
  11.       TopBar()
  12.       List({ space: ListConstants.LIST_SPACE }) {
  13.         LazyForEach(momentData, (moment: FriendMoment) => {
  14.           ListItem() {
  15.             OneMoment({moment: moment})
  16.           }
  17.         }, (moment: FriendMoment) => moment.id)
  18.       }
  19.       .cachedCount(Constants.CACHED_COUNT)
  20.     }
  21.   }
  22. }
  23.  
  24. @Reusable
  25. @Component
  26. export struct OneMoment {
  27.   // 该类型的状态变量已包含自动刷新功能，不需要再重复进行刷新
  28.   @ObjectLink moment: FriendMoment;
  29.  
  30.   // 此处aboutToReuse为多余刷新
  31.   aboutToReuse(params: Record<string, Object>): void {
  32.     this.moment.id = (params.moment as FriendMoment).id
  33.     this.moment.userName = (params.moment as FriendMoment).userName
  34.     this.moment.avatar = (params.moment as FriendMoment).avatar
  35.     this.moment.text = (params.moment as FriendMoment).text
  36.     this.moment.image = (params.moment as FriendMoment).image
  37.   }
  38.     
  39.   build() {
  40.     Column() {
  41.       ...
  42.       Text(`${this.moment.userName}`)
  43.       ...
  44.     }
  45.   }
  46. }
  47.     
  48. @Observed
  49. export class FriendMoment {
  50.   id: string; 
  51.   userName: string; 
  52.   avatar: string; 
  53.   text: string; 
  54.   size: number; 
  55.   image?: string; 
  56.  
  57.   constructor(id: string, userName: string, avatar: string, text: string, size: number, image?: string) {
  58.     this.id = id;
  59.     this.userName = userName;
  60.     this.avatar = avatar;
  61.     this.text = text;
  62.     this.size = size;
  63.     if (image !== undefined) {
  64.       this.image = image;
  65.     }
  66.   }
  67. }

上述反例的操作中，子组件中moment变量被@ObjectLink修饰，把当前this指针注册给父组件，会直接将父组件的数据同步给子组件，实现数据刷新。重新在aboutToReuse中刷新，如果刷新涉及的变量较多、变量中成员变量复杂，可能会造成较大性能开销。

优化前，由于在复用组件OneMoment的aboutToReuse方法中，对moment变量的各个成员变量进行了刷新，aboutToReuse耗时168μs。

refresh_auto_fresh_variable

正例：

  1. @Entry
  2. @Component
  3. struct LessEmbeddedComponent {
  4.   @State momentData: FriendMomentsData = new FriendMomentsData();
  5.   aboutToAppear(): void {
  6.     getFriendMomentFromRawfile();
  7.   }
  8.  
  9.   build() {
  10.     Column() {
  11.       TopBar()
  12.       List({ space: ListConstants.LIST_SPACE }) {
  13.         LazyForEach(momentData, (moment: FriendMoment) => {
  14.           ListItem() {
  15.             OneMoment({moment: moment})
  16.           }
  17.         }, (moment: FriendMoment) => moment.id)
  18.       }
  19.       .cachedCount(Constants.CACHED_COUNT)
  20.     }
  21.   }
  22. }
  23.  
  24. @Reusable
  25. @Component
  26. export struct OneMoment {
  27.   @ObjectLink moment: FriendMoment;
  28.     
  29.   build() {
  30.     Column() {
  31.       ...
  32.       Text(`${this.moment.userName}`)
  33.       ...
  34.     }
  35.   }
  36. }
  37.     
  38. @Observed
  39. export class FriendMoment {
  40.   id: string; 
  41.   userName: string; 
  42.   avatar: string; 
  43.   text: string; 
  44.   size: number; 
  45.   image?: string; 
  46.  
  47.   constructor(id: string, userName: string, avatar: string, text: string, size: number, image?: string) {
  48.     this.id = id;
  49.     this.userName = userName;
  50.     this.avatar = avatar;
  51.     this.text = text;
  52.     this.size = size;
  53.     if (image !== undefined) {
  54.       this.image = image;
  55.     }
  56.   }
  57. }

上述正例的操作中，子组件中moment变量被@ObjectLink修饰，把当前this指针注册给父组件，会直接将父组件的数据同步给子组件，实现数据刷新。

优化效果

在正反例中，针对列表滑动场景，反例中在aboutToReuse方法中，冗余刷新了自动刷新的变量moment中的各个成员变量。正例中，利用@ObjectLink修饰的变量moment自动同步数据的特性，直接进行刷新，不在aboutToReuse方法再进行刷新。

优化后，避免在复用组件OneMoment的aboutToReuse方法中，重复刷新变量moment的各个成员变量，aboutToReuse耗时110μs。

aovid_refresh_auto_fresh_variable

所以，通过上述Trace数据证明，避免在复用组件中，对@Link/@ObjectLink/@Prop等自动更新的状态变量，在aboutToReuse方法中再进行更新。会减少aboutToReuse方法的时间，进而减少复用组件的创建时间。

因为示例中仅涉及一个简单变量moment的各成员变量的冗余刷新，所以优化时间绝对值不大。如果涉及变量较多、变量中成员变量复杂，性能提升会更明显。

最后

小编在之前的鸿蒙系统扫盲中，有很多朋友给我留言，不同的角度的问了一些问题，我明显感觉到一点，那就是许多人参与鸿蒙开发，但是又不知道从哪里下手，因为资料太多，太杂，教授的人也多，无从选择。有很多小伙伴不知道学习哪些鸿蒙开发技术？不知道需要重点掌握哪些鸿蒙应用开发知识点？而且学习时频繁踩坑，最终浪费大量时间。所以有一份实用的鸿蒙（HarmonyOS NEXT）文档用来跟着学习是非常有必要的。 

为了确保高效学习，建议规划清晰的学习路线，涵盖以下关键阶段：

GitCode - 全球开发者的开源社区,开源代码托管平台  希望这一份鸿蒙学习文档能够给大家带来帮助~

鸿蒙（HarmonyOS NEXT）最新学习路线

​

该路线图包含基础技能、就业必备技能、多媒体技术、六大电商APP、进阶高级技能、实战就业级设备开发，不仅补充了华为官网未涉及的解决方案

路线图适合人群：

IT开发人员：想要拓展职业边界
零基础小白：鸿蒙爱好者，希望从0到1学习，增加一项技能。
技术提升/进阶跳槽：发展瓶颈期，提升职场竞争力，快速掌握鸿蒙技术

2.视频学习教程+学习PDF文档

HarmonyOS Next 最新全套视频教程

  纯血版鸿蒙全套学习文档（面试、文档、全套视频等）       

​​

总结

参与鸿蒙开发，你要先认清适合你的方向，如果是想从事鸿蒙应用开发方向的话，可以参考本文的学习路径，简单来说就是：为了确保高效学习，建议规划清晰的学习路线

鸿蒙NEXT全套学习资料
微信名片
注：本文转载自blog.csdn.net的让开，我要吃人了的文章"https://blog.csdn.net/weixin_55362248/article/details/141862762"。版权归原作者所有，此博客不拥有其著作权，亦不承担相应法律责任。如有侵权，请联系我们删除。
复制链接
相关推荐
发表评论

评论记录：

未查询到任何数据！