鸿蒙面试题——面试题整理3

一 面试题汇总

  • 请简述鸿蒙OS与Android OS的主要区别是什么?
  • 请介绍UIAbility的生命周期
  • 请介绍UIAbility的启动模式
  • 鸿蒙OS提供了哪些开发工具和框架来帮助开发者提高开发效率?
  • 请介绍鸿蒙开发中如何进行管理组件状态
  • 在鸿蒙OS中,如何调试和优化应用的性能?
  • 介绍鸿蒙开发中各种配置文件的作用
  • ArkTS语言基础类库有哪些能力
  • 鸿蒙有哪些后台任务类型
  • 页面和自定义组件生命周期

二 面试题解答(仅供参考)

2.1 请简述鸿蒙OS与Android OS的主要区别是什么?

  1. 设备兼容性:鸿蒙OS是一款面向各种设备的分布式操作系统,支持手机、平板电脑、智能手表、智能家居、汽车等多种设备类型,并能在这些设备之间实现无缝切换和共享数据。而Android系统则主要用于移动设备,如手机和平板电脑。

  2. 系统架构:鸿蒙OS采用分布式技术架构,通过分布式技术实现多设备间的协作和数据共享,更加灵活、安全、高效。而Android则采用单一设备架构,其多设备协作能力较弱,数据共享相对不便。

  3. 应用生态:Android系统已经建立了非常完善的应用生态系统,拥有数百万的应用程序,涵盖了各种应用场景。相比之下,鸿蒙OS的应用程序数量较少,生态系统相对不成熟。不过,鸿蒙OS的应用程序数量正在不断增长,未来可能会吸引更多的开发者和应用。

  4. 安全性:鸿蒙OS采用了多层安全防护措施,包括安全隔离、安全通信、安全识别等,相比Android更加安全。此外,鸿蒙OS还采用了一种名为“微内核”的操作系统内核架构,该架构的安全性和稳定性都非常高。

  5. 性能和效率:鸿蒙OS在性能和效率方面进行了优化,采用了分布式架构,可以根据设备的资源情况进行智能调度和管理,旨在提供更流畅的用户体验。而Android系统在某些低端设备上可能存在卡顿和性能瓶颈的问题。

2.2 请介绍UIAbility的生命周期

鸿蒙开发中,UIAbility的生命周期是指UIAbility组件从创建到销毁的整个过程。这个过程包括一系列的状态转换和事件回调,开发者可以根据这些状态和回调来管理UIAbility的生命周期,从而实现更好的应用性能和用户体验。

UIAbility的生命周期主要包括以下几个阶段:

  1. Create(创建) :当UIAbility被创建时,系统会调用onCreate函数。在这个阶段,开发者可以进行一些初始化操作,比如设置UI界面、加载数据等。需要注意的是,在这个阶段,UIAbility还没有被展示给用户,因此不能进行与用户交互的操作。

  2. onWindowStageCreate(窗口创建) :在UIAbility创建之后,系统会调用onWindowStageCreate函数,创建与UIAbility相关联的窗口。在这个阶段,开发者可以设置窗口的属性,比如窗口的大小、位置、背景等。

  3. Foreground(前台展示) :当UIAbility被切换到前台时,系统会调用onForeground函数。在这个阶段,UIAbility的窗口会被展示出来,用户可以与之进行交互。开发者可以在这个阶段更新UI界面,响应用户的操作等。

  4. Background(后台隐藏) :当UIAbility被切换到后台时,系统会调用onBackground函数。在这个阶段,UIAbility的窗口会被隐藏,用户无法与之进行交互。开发者可以在这个阶段进行一些后台任务的处理,比如保存数据、下载文件等。

  5. onWindowStageDestroy(窗口销毁) :在UIAbility销毁之前,系统会调用onWindowStageDestroy函数,销毁与UIAbility相关联的窗口。在这个阶段,开发者可以释放与窗口相关的资源,比如内存、文件句柄等。

  6. Destroy(销毁) :最后,当UIAbility被销毁时,系统会调用onDestroy函数。在这个阶段,开发者需要释放所有与UIAbility相关的资源,比如UI界面、数据等。一旦UIAbility被销毁,就不能再被使用。

通过管理UIAbility的生命周期,开发者可以实现更好的应用性能和用户体验。比如,在UIAbility切换到后台时,开发者可以暂停一些不必要的任务,以节省系统资源;在UIAbility切换到前台时,开发者可以恢复这些任务,以保证应用的流畅性。同时,开发者还需要注意在适当的时机释放资源,避免内存泄漏等问题。

2.3 请介绍UIAbility的启动模式

UIAbility的启动模式是指在启动UIAbility实例时所采用的不同呈现状态和行为方式。HarmonyOS为UIAbility提供了多种启动模式,以满足不同业务场景的需求。这些启动模式包括:

  1. Singleton(单实例模式) :这是默认情况下的启动模式。当应用进程中该类型的UIAbility实例已经存在时,系统会复用该实例,而不是创建新的实例。这意味着每次调用startAbility()方法时,如果相同类型的UIAbility实例已经存在,则不会进入onCreate()和onWindowStageCreate()生命周期回调,而只会进入onNewWant()回调。这种模式下,UIAbility在任务列表里只会有一个历史任务。

  2. Multiton(多实例模式) :在这种模式下,可以多次创建UIAbility实例。但是,每次创建新的实例之前,之前的实例都会被销毁。因此,在任务列表里也只能看到一个历史任务。每次创建新的实例时,都会重新走一遍UIAbility的生命周期方法。

  3. Standard(标准实例模式) :这也是一种多实例模式。与Multiton不同的是,创建新的实例时不会销毁之前的实例,所以在任务列表里可以看到多个实例。这意味着每次点击都会创建新的实例,并且每个实例都有自己的生命周期。

  4. Specified(指定实例模式) :这种启动模式需要指定一个ID。在创建UIAbility时,系统会先判断任务列表里是否存在指定ID的UIAbility实例。如果存在,则不会创建新的实例;如果不存在,则会创建新的实例。

选择合适的启动模式对于优化应用性能和用户体验非常重要。例如,对于需要频繁切换的页面或功能,使用Singleton模式可以避免不必要的实例创建和销毁,从而提高应用的响应速度和性能。而对于需要独立存在的页面或功能,则可以使用Standard或Specified模式来创建多个独立的实例。

2.4 鸿蒙OS提供了哪些开发工具和框架来帮助开发者提高开发效率?

  1. DevEco Studio:这是华为为鸿蒙OS开发的集成开发环境(IDE),提供了工程管理、代码编辑、编译构建、调试仿真等基础功能。此外,它还支持远程真机调试、APP云测试等特色服务,方便开发者进行高效的应用开发。

  2. 鸿蒙开发者服务:这是一套包括鸿蒙云服务、鸿蒙AI开放平台、鸿蒙支付服务等在内的开发者服务,可以帮助开发者快速构建和部署鸿蒙应用程序。

  3. 分布式架构:鸿蒙OS的分布式架构使得开发者可以更方便地实现多设备间的协作和数据共享,提高了开发效率和用户体验。

总的来说,鸿蒙OS提供的这些开发工具和框架为开发者提供了全方位的支持,从开发环境到应用发布,从单一设备到多设备协作,都有相应的解决方案,从而帮助开发者提高开发效率,降低开发成本。

2.5 请介绍鸿蒙开发中如何进行管理组件状态

在鸿蒙开发中,组件的状态管理是通过使用ArkUI框架提供的装饰器来实现的。这些装饰器用于修饰变量,使其成为状态变量,并提供了多种管理状态的功能。

首先,状态变量通常使用@State装饰器进行修饰。@State装饰器用于声明一个私有变量,这个变量只能在组件内部访问。它必须在创建组件实例时分配初始值,因为将变量保持未初始化可能导致框架行为未定义。此外,创建自定义组件时,可以通过状态变量名显式指定@State状态属性的初始值。

其次,当使用@State修饰的组件时,多个组件之间的内部状态和数据是相互独立的。这意味着每个组件都有自己的状态变量副本,修改一个组件的状态不会影响其他组件的状态。
除了@State之外,鸿蒙开发中还有其他一些用于管理组件状态的装饰器。以下是其中一些常见的装饰器:

@Prop:这个装饰器用于声明一个属性(property),它允许父组件向子组件传递数据。@Prop装饰的变量必须使用其父组件提供的@State变量进行初始化,并且允许在子组件内部进行修改。但需要注意的是,子组件对@Prop变量的修改不会通知给父组件,即@Prop属于单向数据绑定。

  1. @Link:这个装饰器用于建立父子组件之间的双向数据绑定。与@Prop不同,@Link装饰的变量可以和父组件的@State变量进行双向绑定。这意味着当子组件修改@Link变量时,父组件的对应状态也会自动更新,反之亦然。需要注意的是,@Link变量不能在组件内部进行初始化。

  2. @Observed@ObjectLink:这两个装饰器主要用于处理对象或数组内部的状态变化。当对象或数组内的属性发生变化时,@State@Prop@Link等装饰器可能无法触发组件的更新。在这种情况下,可以使用@Observed来装饰需要监控的对象组件,同时使用@ObjectLink来装饰对象内部的属性。这样,当对象属性发生变化时,组件会相应地更新。

跨组件层级双向同步状态:@Provide@Consume。跨组件层级双向同步状态是指@Provide修饰的状态变量自动对提供者组件的所有后代组件可用,后代组件通过使用@Consume装饰的变量来获得对提供的状态变量的访问。@Provide作为数据的提供方,可以更新其子孙节点的数据,并触发页面渲染。@Consume在感知到@Provide数据的更新后,会触发当前自定义组件的重新渲染。使用@Provide的好处是开发者不需要多次将变量在组件间传递。

2.6 在鸿蒙OS中,如何调试和优化应用的性能?

  1. 性能分析:首先,使用鸿蒙OS提供的性能分析工具来评估应用的性能。这些工具可以帮助你识别性能瓶颈,如CPU使用率、内存消耗、渲染速度等。
  2. 代码优化
    • 减少不必要的计算:避免在UI线程中进行复杂的计算,这样可以防止界面卡顿。
    • 使用异步编程:对于可能阻塞主线程的操作,如网络请求、文件读写等,使用异步编程模式。
    • 优化数据结构和算法:选择高效的数据结构和算法,以减少内存使用和计算时间。
  3. 内存管理
    • 避免内存泄漏:确保不再使用的资源被正确释放。
    • 合理使用缓存:适当使用缓存可以提高性能,但要避免缓存过大导致内存不足。
    • 优化图片资源:压缩图片大小,减少内存占用。
  4. 网络优化
    • 减少网络请求:合并多个请求,减少网络延迟。
    • 使用缓存策略:对于频繁请求的数据,使用缓存策略来减少网络请求。
  5. 数据库优化
    • 合理使用索引:为数据库表添加合适的索引,提高查询效率。
    • 避免频繁读写:批量操作可以减少数据库操作的次数。
  6. 界面优化
    • 减少界面层级:简化界面布局,减少不必要的视图层级。
    • 使用高效的绘图API:选择性能更好的绘图API来渲染界面
  7. 日志和监控
    • 添加日志记录:在关键代码路径中添加日志记录,以便追踪性能问题。
    • 使用监控工具:使用鸿蒙OS提供的监控工具来实时监控应用的性能。
  8. 用户反馈:积极收集用户反馈,了解应用在实际使用中的性能表现,并根据反馈进行针对性的优化。

通过以上步骤,你可以有效地调试和优化鸿蒙OS中应用的性能。需要注意的是,性能优化是一个持续的过程,需要不断地评估、调整和优化。

2.7 介绍鸿蒙开发中各种配置文件的作用

app.json5

  • 应用的全局配置信息,包含应用的Bundle名称、开发厂商、版本号等基本信息。
  • 特定设备类型的配置信息。

module.json5

  • Module的基本配置信息,包含Module名称、类型、描述、支持的设备类型等基本信息。
  • 应用组件信息,包含UIAbility组件和ExtensionAbility组件的描述信息。
  • 应用运行过程中所需的权限信息。

main_pages.json

  • 页面列表json,对应上面module.json5的pages字段

oh-package.json5

  • 应用/服务支持通过ohpm来安装、共享、分发代码,管理项目的依赖关系。oh-package.json5格式遵循标准的ohpm规范。

build-profile.json5

  • 应用/服务构建配置文件。

2.8 ArkTS语言基础类库有哪些能力

ArkTS语言基础类库是HarmonyOS系统上为应用开发者提供的常用基础能力,主要包含能力如下图所示。

ArkTS语言基础类库能力示意图

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
提供异步并发和多线程并发的能力。
支持Promise和async/await等标准的JS异步并发能力。
TaskPool为应用程序提供一个多线程的运行环境,降低整体资源的消耗、提高系统的整体性能,开发者无需关心线程实例的生命周期。
Worker支持多线程并发,支持Worker线程和宿主线程之间进行通信,开发者需要主动创建和关闭Worker线程。
提供常见的容器类库增、删、改、查的能力。
提供XML、URL、URI构造和解析的能力。
XML被设计用来传输和存储数据,是一种可扩展标记语言。语言基础类库提供了XML生成、解析与转换的能力。
URL、URI构造和解析能力:其中URI是统一资源标识符,可以唯一标识一个资源。URL为统一资源定位符,可以提供找到该资源的路径。
提供常见的字符串和二进制数据处理的能力,以及控制台打印的相关能力。
字符串编解码功能。
基于Base64的字节编码和解码功能。
提供常见的有理数操作支持,包括有理数的比较、获取分子分母等功能。
提供Scope接口用于描述一个字段的有效范围。
提供二进制数据处理的能力,常见于TCP流或文件系统操作等场景中用于处理二进制数据流。
Console提供控制台打印的能力。
提供获取进程信息和操作进程的能力。

2.9 鸿蒙有哪些后台任务类型

OpenHarmony标准系统支持规范内受约束的后台任务,包括短时任务、长时任务、延迟任务、代理提醒和能效资源。

开发者可以根据如下功能介绍,选择合适的后台任务以满足应用退至后台后继续运行的需求。

短时任务:适用于实时性要求高、耗时不长的任务,例如状态保存。

长时任务:适用于长时间运行在后台、用户可感知的任务,例如后台播放音乐、导航、设备连接等,使用长时任务避免应用进程被挂起。

延迟任务:对于实时性要求不高、可延迟执行的任务,系统提供了延迟任务,即满足条件的应用退至后台后被放入执行队列,系统会根据内存、功耗等统一调度。

代理提醒:代理提醒是指应用退后台或进程终止后,系统会代理应用做相应的提醒。适用于定时提醒类业务,当前支持的提醒类型包括倒计时、日历和闹钟三类。

后台任务类型选择

2.10 页面和自定义组件生命周期

自定义组件:@Component装饰的UI单元,可以组合多个系统组件实现UI的复用,可以调用组件的生命周期。

页面:即应用的UI页面。可以由一个或者多个自定义组件组成,@Entry装饰的自定义组件为页面的入口组件,即页面的根节点,一个页面有且仅能有一个@Entry。只有被@Entry装饰的组件才可以调用页面的生命周期。 页面生命周期,即被@Entry装饰的组件生命周期,提供以下生命周期接口:

onPageShow:页面每次显示时触发一次,包括路由过程、应用进入前台等场景。

onPageHide:页面每次隐藏时触发一次,包括路由过程、应用进入后台等场景。

onBackPress:当用户点击返回按钮时触发。

组件生命周期,即一般用@Component装饰的自定义组件的生命周期,提供以下生命周期接口:

aboutToAppear:组件即将出现时回调该接口,具体时机为在创建自定义组件的新实例后,在执行其build()函数之前执行。

aboutToDisappear:在自定义组件析构销毁之前执行。不允许在aboutToDisappear函数中改变状态变量,特别是@Link变量的修改可能会导致应用程序行为不稳定。

生命周期流程如下图所示,下图展示的是被@Entry装饰的组件(页面)生命周期

三 参考

  • 掘金—鸿蒙应用开发面试题