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

一 面试题汇总(美团)

• 桌面卡片【卡片的堆叠】如何实现,APP内置卡片和远端加载卡片的区别？原理
• 鸿蒙arkts语言在api9和10之间的兼容性了解过吗？你们现在开发的api是多少？
• 分布式调用的故障定位、诊断和分析思路？使用过Hitrace工具吗？
• 编译过鸿蒙吗？简单说说鸿蒙编译流程？编译子系统？
• HarmonyOS IDL是什么？Android AIDL
• MVVM在鸿蒙中的实践，架构问题，理解

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

2.1 桌面卡片【卡片的堆叠】如何实现,APP内置卡片和远端加载卡片的区别？原理

在鸿蒙OS中，桌面卡片的堆叠通常是通过`CardView`来实现的。
`CardView`是一个支持卡片化布局的组件，用于显示卡片的内容。
堆叠效果可以通过控制卡片的位置和大小来实现

关于APP内置卡片和远端加载卡片的区别，主要体现在卡片的来源和加载方式上：

1. APP内置卡片：
这些卡片是应用安装时预先定义的，通常在应用内部开发并随应用一起发布。
内置卡片的加载和显示由应用自身控制，它们可以包含静态内容或通过网络动态获取。

2. 远端加载卡片：
这些卡片通常是在应用外部定义和管理的，例如通过服务器端动态配置。
鸿蒙OS支持从远端加载卡片数据，并将其显示在桌面上。
这种方式可以实现动态更新卡片内容，而无需通过应用升级来修改。

无论是内置卡片还是远端加载的卡片，其实现原理都涉及卡片的定义、加载和展示。
在远端加载的情况下，可能涉及到网络请求和异步加载的处理，以确保及时获取并展示最新的卡片内容。
整体原理涉及到系统桌面服务和卡片的动态管理机制，确保卡片的灵活性和及时性。

2.2 鸿蒙arkts语言在api9和10之间的兼容性了解过吗？你们现在开发的api是多少？

鸿蒙 ArkTS 语言在 API9 和 API10之间有不少变化，
尤其是在UI 声明、状态管理、生命周期、组件开发等方面都有优化和调整。
让我们简单对比一下：

1.API9和API10的兼容性差异：

1.1 声明方式变化：
-API 9： 使用@Entry注解作为程序入口。
-API 10：改为@Component注解，更贴近前端开发习惯


1.2 状态管理优化：
-API 9： 需要 @State、@Prop 明确声明组件状态和属性。
-API 10： 引入了 @Observed，进一步优化了状态监听机制

1.3 生命周期变化：
-API 9： 使用 onPageShow()、onPageHide() 管理生命周期。
-API 10： 改用 aboutToAppear()、aboutToDisappear()，逻辑更清晰

1.4 组件复用和事件处理：
-API 9： 事件绑定需要用 onClick。
-API 10： 支持链式调用，使代码更简洁。


2. 兼容性处理方式
-多版本支持： 使用 @system.capability 判断当前设备的 API 版本，适配不同逻辑
-升级建议： 如果项目目前在 API 9，建议逐步迁移到 API 10，新特性更简洁、性能更优。

3.现在版本api11

2.3 分布式调用的故障定位、诊断和分析思路？使用过Hitrace工具吗？

1-分布式调用故障定位思路

1.确认分布式能力是否启用：确认参与分布式调用的设备是否都开启了分布式能力，并已建立可信连接
2.日志排查：使用 hilog 打印关键日志点，关注分布式通信接口的返回值
3.接口调用链分析: 分析 DeviceManager、DistributedDataManager、等接口的调用链，确保数据正常传递。
4.异常捕获:捕获 RemoteException 等异常，定位失败原因
5.网络与权限检查: 确保设备间的网络畅通，并检查分布式权限

2-Hitrace 工具的使用

Hitrace是鸿蒙提供的分布式链路追踪工具，能帮助开发者分析跨设备调用时的性能瓶颈和故障点。

使用步骤：
1.引入 Hitrace 模块
2.打点追踪：在关键逻辑前后加上traceBegin和traceEnd，追踪跨设备调用耗时
3.查看日志:使用 hilog 输出追踪信息
4.诊断分析:通过hitrace工具生成的追踪ID，可以在DevEco Studio的Profiler工具里查看详细的调用链、耗时、失败点等信息

2.4 编译过鸿蒙吗？简单说说鸿蒙编译流程？编译子系统？

鸿蒙OS的编译流程是一个复杂的过程，主要涉及到多个子系统的编译。以下是一个简单的概述：

1-鸿蒙OS编译流程：

1. 代码仓库克隆：开发者首先需要从鸿蒙OS的代码仓库中克隆代码到本地开发环境。
2. 环境配置：开发者需要配置编译环境，包括编译工具链、依赖库、环境变量等。
3. 选择目标设备：鸿蒙OS支持多种设备，包括手机、平板、智能穿戴、物联网设备等。开发者需要选择目标设备进行编译。
4. 选择编译目标：鸿蒙OS支持不同的编译目标，例如模拟器、硬件设备等。开发者需要选择合适的编译目标。
5. 配置编译选项：开发者可以根据需要配置编译选项，包括调试选项、优化选项等。
6. 执行编译命令：通过执行编译命令，开始对鸿蒙OS的源代码进行编译。编译命令可能会包括一系列参数和选项，以指定编译的具体细节。
7. 编译子系统：鸿蒙OS的源代码分为多个子系统，例如内核、系统服务、应用框架等。编译过程会涉及对每个子系统的编译。
8. 生成镜像文件：编译完成后，生成鸿蒙OS的镜像文件，这可以是用于模拟器的镜像、用于硬件设备的刷写镜像等。
9. 刷写到设备：如果目标是硬件设备，开发者可以将生成的镜像文件刷写到目标设备上进行测试和调试。

2-鸿蒙OS编译子系统：

鸿蒙OS的源代码包括多个子系统，每个子系统都有其独立的编译过程。以下是一些常见的鸿蒙OS编译子系统：

1. LiteOS Kernel：LiteOS Kernel是鸿蒙OS的内核，负责处理系统调用、进程管理、内存管理等。它有自己的编译流程，生成内核二进制文件。
2. LiteOS System Services：这个子系统包括一系列系统服务，例如网络服务、文件系统服务、图形服务等。每个系统服务都有独立的编译过程。
3. HarmonyOS Frameworks：这个子系统包括应用框架、图形框架、界面框架等。它们的编译过程涉及到应用程序框架的构建。
4. HarmonyOS Applications：应用程序层的子系统包括系统应用、第三方应用等。每个应用都有自己的编译过程。

编译子系统的具体细节可能因版本而异，鸿蒙OS的发展可能会引入新的编译和构建工具。
因此，为了获取准确的信息，建议查阅鸿蒙OS官方文档和相关的开发者资源。

2.5 HarmonyOS IDL是什么？Android AIDL

1-HarmonyOS IDL

HarmonyOS AIDL（Interface Definition Language，接口定义语言）是用于定义分布式服务接口的语言。
它定义了服务接口的数据类型、方法签名和调用规则，使得不同模块、设备之间可以通过统一的接口进行通信。
HarmonyOS IDL的设计旨在支持分布式能力，并在HarmonyOS生态系统中实现设备之间的高效互通。

一些 HarmonyOS IDL 的特点包括：
1. 数据类型支持：提供了基本数据类型、结构体、枚举等，以及支持分布式的特殊数据类型，方便在分布式环境中传递数据。
2. 接口定义：允许开发者定义接口，包括接口的方法、参数、返回值等。这样不同的设备和模块可以按照定义好的接口进行通信。
3. 异步调用：支持异步方法调用，允许设备在不阻塞主线程的情况下进行异步通信。

2-Android AIDL

Android AIDL（Android Interface Definition Language，Android接口定义语言）是Android中用于进行跨进程通信的一种接口定义语言。
它与 HarmonyOS IDL 有一些相似之处，但在语法和使用上有一些差异。
Android AIDL 主要用于在不同的 Android 进程之间传递复杂对象和调用远程服务。

一些 Android AIDL 的特点包括：

1. 跨进程通信：Android AIDL主要用于实现跨进程通信。
通过定义接口和接口中的方法，应用可以通过AIDL文件描述接口，从而实现在不同进程之间传递数据和调用远程服务。
2. Binder机制：AIDL的底层机制依赖于Android的Binder机制，这是一种跨进程通信的底层实现。
3. 复杂对象支持：AIDL支持传递复杂对象，包括自定义的数据类型、对象等。

3-区别

虽然 HarmonyOS IDL 和 Android AIDL 有一些相似之处，但它们是两个不同系统中用于不同目的的接口定义语言。
HarmonyOS IDL 更侧重于分布式能力，而 Android AIDL 更专注于 Android 平台的进程间通信。

2.6 MVVM在鸿蒙中的实践，架构问题，理解

1-说明

在鸿蒙OS中实践MVVM（Model-View-ViewModel）架构模式与在其他移动应用框架中有相似之处，但也存在一些特定的考虑因素。
MVVM是一种用于构建用户界面的软件架构模式，
它将应用程序分为三个主要组件：Model（模型）、View（视图）和ViewModel（视图模型）。

2-MVVM 在鸿蒙中的实践：

1.Model（模型）：
- Model 表示应用程序的数据层。在鸿蒙OS中，Model 可能包括应用的业务逻辑、数据存储和处理等。
- 鸿蒙OS提供了分布式能力，因此 Model 的数据可能来自本地设备或其他远程设备。在 Model 中需要考虑分布式数据的管理。

2.View（视图）：
- View 是用户界面的表示。在鸿蒙OS中，使用XML布局文件来定义视图的层次结构和外观。
- 视图层可以通过数据绑定与 ViewModel 交互，当 ViewModel 的数据发生变化时，自动更新视图。

3.ViewModel（视图模型）：
- ViewModel 负责处理用户界面的业务逻辑和状态管理，将 Model 层的数据转化为可在视图层显示的形式。
- 鸿蒙OS中，ViewModel 的设计需要考虑到分布式环境，可能需要处理来自不同设备的数据。

3-架构问题和考虑因素：

1.分布式环境：
-鸿蒙OS支持分布式能力，因此在设计 MVVM 架构时需要考虑数据的分布和管理。
-ViewModel 可能需要与其他设备进行通信以获取数据。

2.数据绑定：
-数据绑定是 MVVM 中的核心概念，
-但在鸿蒙OS中可能需要特别关注分布式环境下的数据同步问题，确保数据变更能够及时反映在视图层。

3.异步操作：
-在鸿蒙OS中，涉及分布式通信、文件读写等操作可能是异步的。
-ViewModel 需要支持异步操作，并确保界面的响应性。

4.事件处理：
事件处理在 MVVM 架构中是重要的一部分，确保 ViewModel 能够正确地响应用户操作，触发相应的业务逻辑。

5.设备适配：
-鸿蒙OS支持多种设备类型，包括手机、平板、物联网设备等。
-在实践中需要考虑不同设备上界面和交互的适配问题。

4-总结

总体而言，MVVM在鸿蒙OS中的实践与其他移动应用框架有相似之处，
但在考虑分布式环境和鸿蒙OS特有的能力时，需要对架构进行适当调整。
正确的MVVM实践可以帮助提高代码的可维护性和扩展性，同时保持良好的用户体验。

三 参考

• 掘金—首发：鸿蒙面试真题分享