HarmonyOS开发实战（ Beta5.0）系统提供的接口实践规范

最新推荐文章于 2024-09-29 21:12:21 发布

让开，我要吃人了

最新推荐文章于 2024-09-29 21:12:21 发布

阅读量1.3k

点赞数 21

分类专栏： HarmonyOS 鸿蒙开发 OpenHarmony 文章标签： harmonyos 华为前端鸿蒙移动开发 linux 鸿蒙系统

本文链接：https://blog.csdn.net/weixin_55362248/article/details/141932027

版权

鸿蒙开发同时被 3 个专栏收录

150 篇文章 2 订阅

订阅专栏

HarmonyOS

149 篇文章 1 订阅

订阅专栏

OpenHarmony

149 篇文章 1 订阅

订阅专栏

简介

在应用开发中，经常会调用系统提供的接口，比如读取本地文件、处理服务端数据等等。若对接口使用不合理，可能引起延迟、卡顿、丢帧等性能问题。本文以如下系统提供的接口为例，总结了使用中的注意事项。

ResourceManager的getXXXSync接口
wordBreak属性

ResourceManager的getXXXSync接口

ResourceManager通过getXXXSync接口获取资源的方式有两种：通过resource对象resourceManager.getStringSync($r('app.string.test'))和通过idresourceManager.getStringSync($r('app.string.test').id)。通过resource对象的方式在获取过程中发生了一次拷贝，通过id的方式只是对原对象的引用。下面以getStringSync为例，测试一下这两种参数在方法中的使用是否会有耗时区别。

通过resource对象获取(源码示例链接)

@Entry
@Component
struct Index {
  @State message: string = 'getStringSync';

  aboutToAppear(): void {
    hiTraceMeter.startTrace('getStringSync', 1);
    // getStringSync接口的入参直接使用资源，未使用资源ID
    getContext().resourceManager.getStringSync($r('app.string.test'));
    hiTraceMeter.finishTrace('getStringSync', 1);
  }

  build() {
    RelativeContainer() {
      Text(this.message)
        .fontSize(50)
        .fontWeight(FontWeight.Bold)
    }
    .height('100%')
    .width('100%')
  }
}

通过SmartPerf Host工具抓取Trace。持续时间为1.621ms。

通过id获取(源码示例链接)

@Entry
@Component
struct Index {
  @State message: string = 'getStringSyncAfter';

  aboutToAppear(): void {
    hiTraceMeter.startTrace('getStringSyncAfter', 2);
    // getStringSync接口的入参使用了资源ID
    getContext().resourceManager.getStringSync($r('app.string.test').id);
    hiTraceMeter.finishTrace('getStringSyncAfter', 2);
  }

  build() {
    RelativeContainer() {
      Text(this.message)
        .fontSize(50)
        .fontWeight(FontWeight.Bold)
    }
    .height('100%')
    .width('100%')
  }
}

通过SmartPerf Host工具抓取Trace。持续时间为0.124ms。

总结

参数为资源信息时（1.621ms）比参数为资源ID值时（0.124ms）耗时更多。所以当需要使用类似方法时，使用资源ID值作为参数更优。

wordBreak属性

零宽空格（Zero Width Space, ZWSP）是一个特殊的Unicode字符。它是一个不可见的字符，其宽度为零，不占用任何可见空间。在文本处理系统中，尽管它在视觉上是不可见的，但它在文本中确实存在，并可以作为潜在的断点，即允许在此位置断开行。这意味着如果一行文本过长需要自动换行时，文本可以在零宽空格的位置进行折行，而不影响单词的完整性。

虽然零宽空格在许多情况下都是有用的，但它也可能引起问题，特别是在文本处理和数据清洗中。不注意这些看不见的字符可能导致数据的意外错误、搜索失败、数据不一致等问题。因此，在处理来自不同源的文本数据时，了解和考虑这些不可见字符是非常重要的。

避免在文本组件内使用零宽空格(\u200b)的形式来设置断行规则，推荐使用wordBreak，wordBreak在使用性能方面优于零宽空格。例如推荐用法为：Text(this.diskName).wordBreak(WordBreak.BREAK_ALL)。

反例(源码示例链接)

@CustomDialog
export struct DiskFormatDialog {
  private diskName: string = '';
  build() {
    Column() {
      Text(this.diskName.split("").join("\u200B"))
      .textAlign(TextAlign.Start)
    }
  }
}

通过SmartPerf Host工具抓取Trace。启动时ReceiveVsync阶段耗时为3s271ms。

正例(源码示例链接)

@CustomDialog
export struct DiskFormatDialog {
  private diskName: string = '';
  build() {
    Column() {
      Text(this.diskName)
      .textAlign(TextAlign.Start)
      .wordBreak(WordBreak.BREAK_ALL)
    }
  }
}

通过SmartPerf Host工具抓取Trace。启动时ReceiveVsync阶段耗时为301ms。

总结

使用零宽空格时（3s271ms）比使用wordBreak时（301ms）耗时更多。所以当需要使用类似方法时，使用wordBreak性能更优。

最后

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

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

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

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