鸿蒙口试 2025-01-10

写了鉴权工具，你在项目中申请了那些权限？（常用权限）

• 位置权限 ：
  
  1. ohos.permission.LOCATION_IN_BACKGROUND：允许应用在后台访问位置信息。
  2. ohos.permission.LOCATION：允许应用访问精确的位置信息。
  3. ohos.permission.APPROXIMATELY_LOCATION：允许应用访问大致的位置信息。

  复制代码
• 相机权限 ：
  
  1. ohos.permission.CAMERA：允许应用访问相机设备。

  复制代码
• 麦克风权限 ：
  
  1. ohos.permission.MICROPHONE：允许应用访问麦克风设备。

  复制代码
• 通讯录权限 ：
  
  1. ohos.permission.READ_CONTACTS：允许应用读取通讯录。
  2. ohos.permission.WRITE_CONTACTS：允许应用写入通讯录。

  复制代码
• 日历权限 ：
  
  1. ohos.permission.READ_CALENDAR：允许应用读取日历数据。
  2. ohos.permission.WRITE_CALENDAR：允许应用写入日历数据。

  复制代码
• 活动数据权限 ：
  
  1. ohos.permission.ACTIVITY_MOTION：允许应用访问运动数据。此权限不支持在2in1设备上申请。

  复制代码
• 身体传感器权限 ：
  
  1. ohos.permission.READ_HEALTH_DATA：允许应用读取健康数据。此权限仅穿戴设备可申请。

  复制代码
• 图片和视频权限 ：
  
  1. ohos.permission.WRITE_IMAGEVIDEO：允许应用写入图片和视频。
  2. ohos.permission.READ_IMAGEVIDEO：允许应用读取图片和视频。

  复制代码
• 音乐和音频权限 ：
  
  1. ohos.permission.WRITE_AUDIO：允许应用写入音频文件。
  2. ohos.permission.READ_AUDIO：允许应用读取音频文件。

  复制代码
• 跨应用关联权限 ：
  
  1. ohos.permission.APP_TRACKING_CONSENT：允许应用进行跨应用跟踪。

  复制代码
• 多装备协同权限 ：
  
  1. ohos.permission.DISTRIBUTED_DATASYNC：允许应用在多设备之间同步数据。

  复制代码
• 蓝牙权限 ：
  
  1. ohos.permission.ACCESS_BLUETOOTH：允许应用访问蓝牙设备。

  复制代码
• 剪切板权限 ：
  
  1. ohos.permission.READ_PASTEBOARD：允许应用读取剪切板数据。

  复制代码
• 文件夹权限 ：
  
  1. ohos.permission.READ_WRITE_DOWNLOAD_DIRECTORY：允许应用读写下载目录。
  2. ohos.permission.READ_WRITE_DOCUMENTS_DIRECTORY：允许应用读写文档目录。此权限仅2in1设备可申请。

  复制代码

---

使用安全控件的话可以免申请权限？为啥不考虑使用安全控件？

使用安全控件确实可以在某些情况下免去你在鸿蒙体系中申请权限的需要。安全控件是一种体系提供的ArkUI组件，它们允许应用在用户点击后自动授权，无需额外的弹窗授权。这种方式不仅简化了开辟者和用户的操作，还可以或许基于场景化授权，匹配用户的真实意图，从而减少弹窗打扰，提升用户体验。
安全控件的紧张优点包罗：

• 用户掌握授权时机 ：用户可以在需要时才举行授权，授权范围也最小化。
  
• 简化操作 ：开辟者不必向应用市场申请权限1。
  
• 隐私合规 ：安全控件坚持仅采集实现业务功能所必须的个人数据1。
  

目前，体系提供了三类安全控件：

• 粘贴控件（PasteButton） ：对应剪贴板读取特权，实用于需要读取剪贴板的场景1。
  
• 保存控件（SaveButton） ：对应媒体库写入特权，实用于需要保存文件到媒体库的场景1。
  
• 位置控件（LocationButton） ：对应精准定位特权，实用于需要在前台短暂使用位置信息的场景。
  

例如，在谈天界面发送及时定位信息的场景中，你可以直接使用位置控件来得到临时的精准定位授权，这样就可以避免长时间使用位置信息或后台使用位置信息的情况，从而满足权限最小化和提升隐私体验的要求2。
鉴于这些优势，使用安全控件成为了一种优选的解决方案，尤其是在应用不需要持续或后台访问敏感信息的情况下。这样不仅可以提高应用的隐私保护水平，还可以加强用户的信托和使用体验。
约束与限定
安全控件因其自动授权的特性，为了保障用户的隐私不被恶意应用获取，针对安全控件作了许多的限定。应用开辟者需保证安全控件在应用界面上清晰可见、用户能明确辨认，防止因覆盖、肴杂等因素导致授权失败。
当因控件样式不正当导致授权失败的情况发生时，请开辟者查抄装备错误日志，过滤关键字"SecurityComponentCheckFail"可以获取具体原因。
大概会导致授权失败的问题（包罗但不限于）：

• 字体、图标尺寸过小。
  
• 安全控件整体尺寸过大。
  
• 字体、图标、背景按钮的颜色透明度过高。
  
• 字体或图标与背景按钮颜色过于相似。
  
• 安全控件超出屏幕、超出窗口等，导致显示不全。
  
• 安全控件被其他组件或窗口遮挡。
  
• 安全控件的父组件有雷同变形模糊等大概导致安全控件显示不完备的属性。
  

---

扫描二维码需要相机权限吗？拍照需要相机权限吗？

需要
在鸿蒙（HarmonyOS）开辟中，使用相机举行扫码和拍照确实需要申请相机权限。这是因为相机操作涉及到用户的隐私和安全，因此应用在使用相机前必须得到用户的明确授权。
具体来说，对于相机权限的申请，您需要在应用的module.json5文件中设置相机权限，如下所示：

1. "permissions": [ "ohos.permission.CAMERA" ]

复制代码

这行设置表现您的应用哀求使用相机的权限。在应用运行时，您还需要通过代码哀求用户授权，可以使用以下代码片段：

1. import { requestPermissionsFromUser } from '@ohos.ability';
3. const permissions = ['ohos.permission.CAMERA'];
4. const result = await requestPermissionsFromUser(permissions);
5. if (result['ohos.permission.CAMERA'] === 'authorized') {
6.     console.log('Camera permission authorized');
7. } else {
8.     console.log('Camera permission denied');
9. }

复制代码

这段代码会弹出一个授权对话框，让用户决定是否授予应用相机权限。只有当用户同意后，应用才能使用相机举行扫码或拍照。
因此，无论是举行二维码扫描还是拍照，您的应用都需要先确保已经得到了相机权限。这是保障用户隐私和应勤奋能正常运行的紧张步骤。
不需要
体系通过提供体系Picker和安全控件两种方式，使得应用可以或许便捷地访问体系资源。这两种方法均依赖于体系的独立历程来实现，当应用拉起体系Picker或展示安全控件时，必须依赖用户的主动操作来获取资源或结果。这一流程避免了应用额外申请权限，同时，由于用户的积极到场，进一步加强了用户隐私和安全的保护。
体系Picker
体系Picker是拉起体系资源的一种方式，由于体系Picker已经获取了对应权限的预授权，开辟者使用体系Picker时，无需再次申请权限也可临时受限访问对应的资源。
使用体系Picker组件拉起体系应用的场景紧张有：联系人Picker（Contacts Picker），地图Picker，相机Picker（Camera Picker），扫码Picker，卡证辨认Picker，文档扫描Picker，文件Picker，音频Picker和照片Picker（PhotoViewPicker）等，具体可参考拉起体系应用。
安全控件
安全控件是体系提供的一组体系实现的ArkUI组件，应用集成这类组件就可以实现在用户点击后自动授权，而无需弹窗授权。它们可以作为一种“特殊的按钮”融入应用页面，实现用户点击即许可的设计思路。
目前体系提供三类安全控件：粘贴控件（PasteButton）、保存控件（SaveButton）、位置控件（LocationButton）。
使用场景示例
以下列举了三个优先使用体系Picker或者安全控件的场景：

• 读写媒体库图片或视频：
  
  
  
  • 推荐方案（无需申请权限）：使用PhotoViewPicker读取媒体库的图片与视频；使用安全控件中的保存控件保存媒体库的图片与视频。
    
  • 申请权限方案：申请受限权限ohos.permission.READ_IMAGEVIDEO或ohos.permission.WRITE_IMAGEVIDEO读取媒体库的图片与视频。
    
  
  
• 拉取体系相机拍照录制：
  
  
  
  • 推荐方案（无需申请权限）：仅是需要拉起体系相机拍摄一张照片、录制一段视频，可直接使用CameraPicker，无需申请相机权限。
    
  • 申请权限方案：开辟一个相机应用（或是在应用内开辟相机模块）时，需按相机开辟引导在开辟前做好申请权限的准备。
    
  
  
• 访问当前位置：
  
  
  
  • 推荐方案（无需申请权限）：应用仅需要在部分前台场景短暂地访问位置信息（例如定位城市、打卡、分享位置等），不需要长时间使用。此时，可以直接使用安全控件中的位置控件，免去权限申请和权限哀求等环节，得到临时授权，满足权限最小化，提升用户的隐私体验。
    
  • 申请权限方案：假如需要长时间使用或是在后台使用位置信息，建议申请位置权限。
    
  
  

---

华为一键登入认证需要怎么做？

华为一键登录认证紧张涉及以下几个步骤：

• 集成登录组件 ：
  
  
  
  • 在您的应用中集成华为账号登录组件。这可以通过添加LoginWithHuaweiIDButton按钮来实现，该按钮支持一键登录功能。
    
  
  
• 设置权限 ：
  
  
  
  • 在应用后台设置中，您需要申请quickLoginMobilePhone（华为账号一键登录）的scope权限。这是实现一键登录的前提条件。
    
  
  
• 用户交互设计 ：
  
  
  
  • 按照华为的设计规范，设计一键登录的用户体验（UX）。这包罗按钮的样式设计和页面布局，确保符合华为账号一键登录的视觉和体验标准。
    
  
  
• 处理惩罚登录逻辑 ：
  
  
  
  • 当用户点击一键登录按钮后，应用会查抄华为账号的登录状态。假如已经登录，应用将剖析出用户的UnionID、OpenID和手机号码。
    
  • 假如用户在90天内没有验证记载，体系将触发短信验证流程，以确保手机号的有效性。
    
  
  
• 协议处理惩罚 ：
  
  
  
  • 用户在使用一键登录前，必须同意《华为账号用户认证协议》1。您可以引导用户查看协议内容，并在用户同意后继续登录流程。
    
  
  
• 服务器设置 ：
  
  
  
  • 应用服务器在获取华为账号绑定的手机号码时，必须确保服务器部署在中国大陆境内，因为该项服务当前仅限中国大陆用户使用。
    
  
  

通过以上步骤，您的应用就可以实现华为账号的一键登录功能，提供给用户快速、便捷的登录体验。

---

华为一键登入前端能获取得手机号码吗？

在华为账号一键登录功能中，前端确实可以或许获取到用户的手机号码。这一功能是通过华为的Account Kit实现的，它允许开辟者在用户点击一键登录按钮后，获取用户绑定到华为账号的手机号码。
具体的实现方式如下：

• 用户点击一键登录按钮后，体系会查抄用户在近来90天内是否有短信验证通过的记载。假如有，則直接返回手机号码；假如没有，体系将触发默认的短信验证流程。
  
• 这一过程中，开辟者可以通过设置相应的回调函数来处理惩罚验证结果，例如在用户同意协议并完成登录后，可以使用continueLogin(callback)方法来处理惩罚登录结果。
  

    注意这里虽然获取到了手机号码，但是是匿名手机号码 例如 183******58
  

  

---

flutter怎么适配安卓和IOS？

Flutter 可以或许高效适配安卓（Android）与 iOS 平台，紧张得益于以下几个关键要素：

• 跨平台框架设计
  
  
  
  • 同一的编程语言：Flutter 使用 Dart 语言举行开辟，它无需针对差别平台学习 Objective-C、Swift（iOS） 或 Java、Kotlin（Android）。开辟者用一套代码，就能在两大主流移动平台构建应用，节省大量人力与学习本钱。例如开辟一款简单的待服务项应用，从创建任务列表、添加删除任务的逻辑，到界面布局与交互，代码只需编写一次。
    
  • 自绘引擎：Flutter 自带了一套高性能的自绘引擎，不依赖于原生体系控件。无论是在安卓的 Material Design 风格，还是 iOS 的扁平简约风格下，它能直接在画布上绘制出符合对应平台设计规范的 UI 元素，摆脱原生控件适配难题，像绘制一个自界说的渐变按钮，Flutter 可以精准出现，不受原生体系限定。
    
  
  
• 平台适配插件
  
  
  
  • 官方插件：Flutter 官方提供海量的插件库，覆盖常见的功能，如摄像头调用、地理位置获取、蓝牙毗连等。针对安卓与 iOS 平台的特性差异，这些插件内部已做了适配处理惩罚。以地图插件为例，它能无缝对接谷歌地图（Android）和苹果地图（iOS），开辟者使用时只需按同一接口操作，不必费心底层适配。
    
  • 社区插件：活跃的 Flutter 社区持续贡献丰富插件，增补官方遗漏的小众或新需求场景。当新的 iOS 体系特性发布，社区开辟者会迅速反应，更新插件适配新功能，其他开辟者拿来就能用，加速项目适配新平台特性的速率。
    
  
  
• 遵循设计规范
  
  
  
  • 安卓 Material Design：对于安卓平台，Flutter 提供了遵循 Material Design 规范的组件库，开辟者可以轻松组合出具有安卓风格的页面，像带水波纹殊效的按钮、多层卡片式布局，让应用融入安卓生态。
    
  • iOS Human Interface Guidelines：对应 iOS，Flutter 同样能塑造贴合 iOS 设计理念的界面，如简便大气的导航栏样式、精致的动画过渡，确保应用在 iOS 装备上的用户体验符合苹果官方标准。
    
  
  
• 编译打包流程
  
  
  
  • 差异化设置：Flutter 项目标构建脚本支持为安卓与 iOS 分别设置特定参数，比如安卓的差别应用市场渠道包设置、iOS 的 App Store 上架证书设置等。开辟者可以在编译时精致调解，确保生成的应用包符合对应平台的上架、分发要求。
    
  • 多平台测试：Flutter CLI 工具方便开辟者在安卓模拟器、真机以及 iOS 模拟器、真机上快速测试，通过多轮反复测试，排查因平台差异隐藏的兼容性问题，从布局错乱到功能异常，尽早发现并修复。
    
  
  

---

安卓的四大组件？


安卓的四大组件分别是 Activity（活动）、Service（服务）、Broadcast Receiver（广播吸取器）以及 Content Provider（内容提供者），它们各自发挥着关键作用，协同构建起功能丰富的安卓应用：

• Activity（活动）
  
  
  
  • 用户交互核心：作为安卓应用中直接与用户交互的可视化界面单元，每一个 Activity 通常对应一屏显示内容，像登录界面、主菜单、商品详情页等。它吸取并响应用户的各类操作，例如触摸屏幕、按键点击，借此驱动页面跳转、数据更新、输入处理惩罚等交互流程。用户打开购物 APP，起首映入眼帘的首页 Activity，浏览商品时点击图片进入对应的商品详情 Activity，这一系列交互都发生在 Activity 层面。
    
  • 生命周期管理：有着严谨的生命周期，包罗创建（onCreate）、启动（onStart）、规复（onResume） 、停息（onPause）、制止（onStop）、销毁（onDestroy）等阶段。开辟者依据这些阶段精准把控资源分配与回收，比如在 onCreate 阶段初始化界面布局与数据，onDestroy 阶段开释不再使用的资源，防止内存泄漏。
    
  
  
• Service（服务）
  
  
  
  • 后台持续运行：专注于在后台长时间实行特定任务，无需可视化界面。范例场景如音乐持续播放、文件后台下载、及时数据同步等。即使用户切换到其他 APP，对应的服务依然可以稳定运行，维持业务的连贯性，用户开启音乐播放服务后，即便切出去浏览新闻资讯，音乐也不停歇。
    
  • 跨组件协作：它可以或许与其他组件共同，通过 Intent 启动，也可以与 Activity、Broadcast Receiver 互动。例如，Activity 可以启动一个 Service 来实行耗时任务，之后通过广播吸取器吸取 Service 完成任务的反馈，实现差别组件间的接力协作。
    
  
  
• Broadcast Receiver（广播吸取器）
  
  
  
  • 消息监听响应：负责监听体系或应用发出的广播消息，安卓体系在浩繁关键变乱节点，如开机、网络毗连厘革、电量不足等，都会发送广播；应用自身也能按需自界说广播。广播吸取器捕捉到广播后，即刻实行预设的响应动作，手机电量低时，体系广播发出，电量预警类 APP 中的广播吸取器收到信号，便及时提醒用户充电。
    
  • 体系集成与拓展：借助广播吸取器，应用得以深度融入安卓体系生态，拓展功能边界。例如，安装新应用时体系广播触发，某些文件管理类 APP 借此广播可自动扫描新安装应用相关文件，实现智能管理。
    
  
  
• Content Provider（内容提供者）
  
  
  
  • 数据共享桥梁：充当差别安卓应用间数据共享的媒介，把自身应用的数据以安全、可控的方式提供给其他授权应用访问。常见的，通讯录应用通过 Content Provider 将联系人数据开放，第三方短信、外交 APP 获取授权后，就能读取联系人，实现诸如短信群发、好友推荐等功能。
    
  • 数据封装与访问控制：它将数据封装成同一格式，配套设置访问权限规则，既保障数据拥有者的权益，也让有需求的应用合规获取数据，促进安卓应用间的数据流通与协同。 。
    
  
  

---

有相识Handler吗？Handler是什么？


在安卓开辟中，Handler是一个极为关键的类，用于实现线程间通讯，尤其是在处理惩罚主线程（UI 线程）与子线程交互时必不可少，紧张体现在以下几方面：

• 基本原理
  
  
  
  • Handler 关联着 MessageQueue（消息队列）与 Looper（循环器）。MessageQueue 是一个存放 Message（消息）的队列，按先进先出原则分列，用于暂存那些等候被处理惩罚的消息；Looper 则持续不停地从这个队列里取出消息，并把消息分发给对应的 Handler 去处理惩罚。每个线程默认只有一个 Looper，主线程的Looper在安卓应用启动时就自动创建好了，而子线程若要使用Handler，往往得手动创建Looper 。
    
  
  
• 作用
  
  
  
  • 助力 UI 更新：安卓规定，耗时操作不能在主线程实行，否则会阻塞 UI，造成界面卡顿甚至 ANR（Application Not Responding，应用无响应）。当子线程完成耗时任务，如网络下载、数据库查询后，可将结果封装进 Message，借助 Handler 发送到主线程的 MessageQueue。主线程的Looper会从队列中取出该消息，再由对应的Handler处理惩罚，从而安全地更新 UI 。例如，子线程下载好一张图片后，把图片数据通过Handler传递给主线程，主线程更新 ImageView 来展示图片。
    
  • 线程间协调：不仅是子线程向主线程汇报，Handler也用于多线程间的信息传递与任务调理。差别子线程之间可以通过共享的 Handler 发送和吸取消息，让它们的工作协同起来，井井有条地完成复杂项目，像是在一个多线程处理惩罚多媒体文件的项目里，音频处理惩罚线程与视频处理惩罚线程靠Handler沟通进度、同步状态。
    
  
  
• 使用方式
  
  
  
  • 创建与发送消息：起首得创建 Handler 对象，通常是在主线程创建，并重写 handleMessage 方法，用于界说收到消息后的处理惩罚逻辑。接着，在子线程生成 Message ，通过 Handler 的sendMessage 或 post方法把消息发送出去 。例如：
    1. Handler handler = new Handler() {
    2.     @Override
    3.     public void handleMessage(Message msg) {
    4.         // 处理消息，msg里携带了数据
    5.         super.handleMessage(msg);
    6.     }
    7. };
    9. new Thread(new Runnable() {
    10.     @Override
    11.     public void run() {
    12.         Message message = Message.obtain();
    13.         // 设置消息内容
    14.         handler.sendMessage(message);
    15.     }
    16. }).start();

    复制代码
    在上述代码中，先界说Handler，子线程获取Message后发送给主线程的Handler处理惩罚。
    
  
  

---

Handler、Message，Looper与MessageQueue 之间的关系？


Handler、Message、Looper 与 MessageQueue 在安卓开辟的线程间通讯机制里紧密协作，各自负担独特功能，共同构成一个高效的信息流转体系：

• Message
  
  
  
  • 数据载体：它是整个通讯流程的 “包裹”，用来承载各式各样的数据。无论是简单的整数、字符串，还是复杂的自界说对象，都能封装进Message。例如，子线程完成网络数据下载任务后，把下载的数据封装到Message里，以便传递给其他线程处理惩罚。Message自身带有一些属性字段，像是what，开辟者可以为其赋值，以此区分差别范例的消息，方便吸取方针对性处理惩罚。
    
  
  
• MessageQueue
  
  
  
  • 消息队列：充当 “信息仓库”，是一个按先进先出（FIFO）原则构造的队列。所有待处理惩罚的Message都会被依次排入这个队列，无论消息来自哪个线程。这就好比银行业务厅的排队叫号体系，浩繁客户（消息）按先来后到次序等候被服务（处理惩罚）。它负责暂存浩繁Message，保证消息处理惩罚的有序性。
    
  
  
• Looper
  
  
  
  • 消息循环器：关联着MessageQueue，是驱动整个消息处理惩罚流程的 “引擎”。Looper会不停地从MessageQueue里取出Message，然后将其分发给对应的Handler去处理惩罚。每个线程默认情况下只会有一个Looper，主线程的Looper在安卓应用启动时便自动创建完成；而子线程假如要启用Handler，多数时间得手动搭建Looper体系，否则无法正常收发消息。Looper持续运转，不停地从队列中捞出消息，维持信息处理惩罚的动态循环。
    
  
  
• Handler
  
  
  
  • 消息处理惩罚器：一方面，Handler是消息的 “投递员”，负责把Message发送到对应的MessageQueue。比如，子线程中有紧张数据要传递给主线程更新 UI，就通过子线程创建的Handler把封装好数据的Message排入主线程的MessageQueue。另一方面，Handler也是消息的 “吸取站”，它界说了handleMessage方法，当Looper把从MessageQueue中取出的Message转交给Handler时，就会触发该方法，进而处理惩罚消息内容，完成从消息发送、排队、提取到终极处理惩罚的完备闭环。
    
  
  

总结来说，Message承载具体数据进入MessageQueue排队等候，Looper驱动循环从队列中提取Message，再由Handler完成收发与处理惩罚，它们协同运作，保障安卓应用多线程间井井有条地通讯。

---

鸿蒙状态管理的装饰器？

• @State
  
  
  
  • 功能：在使用鸿蒙的声明式开辟范式时，@State 是极为紧张的标识。当一个变量被标注为 @State，意味着这个变量用于保存组件的本地状态，它的任何改变都会触发组件的重新渲染。例如在一个简单的计数器组件里，把记载当前计数值的变量标记成 @State，每次点击增长或减少按钮改变这个值时，组件会迅速响应，更新界面显示的数字，精准出现最新状态。
    
  • 原理：鸿蒙的 ArkUI 框架依赖这种机制追踪状态厘革。被 @State 修饰的变量发生变更，框架可以或许感知，随即启动重新构建受影响的 UI 部分流程，避免了不必要的全页面革新，优化性能的同时，也让 UI 与数据状态紧密同步。
    
  
  
• @Prop
  
  
  
  • 功能：用于父子组件之间的数据传递与状态关联。假如父组件有某个数据需要传递给子组件，将该数据通过 @Prop 修饰后传递下去，子组件吸取后就能基于这份数据展示内容或者实行逻辑。而且，子组件对这个数据的修改，也能反向关照父组件，维持父子组件间状态的协同更新。打个比方，父组件是一个商品列表，把选中商品的索引用 @Prop 传给子组件（商品详情展示框 ），子组件里切换商品详情时，父组件也能同步知晓，更新列表选中状态。
    
  • 优势：通过 @Prop 构建起清晰高效的父子组件交互通道，简化跨组件状态同步的复杂水平，提升代码可读性与可维护性，低沉因状态差别步引发的 bug 出现概率。
    
  
  
• @Link
  
  
  
  • 功能：建立父子组件间的双向数据绑定通道。无论是父组件数据变动影响子组件显示，还是子组件对数据的修改，都能及时反馈给父组件，让二者的数据状态时刻保持同步，双向互通。
    
  • 协同：和平凡单向传递数据的机制相互增补，在父子组件交互场景下，要是数据需频繁来回变动，@Link 简化操作，无需手动编写过多更新逻辑，双方数据自动协同，提升开辟效率与交互响应速率。
    
  
  
• @Provide 与 @Consume
  
  
  
  • 功能：@Provide 负责将某个状态变量公开，使其成为全局或局部范围内可共享的 “资源池”；@Consume 则像一个 “取水口”，组件添加该装饰器就能获取、使用被提供的状态，让状态能跨多层级、多组件流通。
    
  • 协同：二者共同冲破组件层级束缚，差别深度嵌套的组件依赖它们能基于共享状态协同运作，一处状态变更，各处相关消费该状态的组件自动更新，维持应用整体状态同等性。
    
  
  
• @ObjectLink
  
  
  
  • 功能：聚焦于对象属性层面的厘革追踪与同步。只要被观察对象的属性值出现变动，与之绑定、添加此装饰器的 UI 组件立即知晓，随即更新展示内容，精准出现对象最新状态。
    
  • 协同：搭配通例的对象操作逻辑，当业务频繁更新对象属性时，它保障 UI 与对象状态无缝衔接，无需额外干预，就能让相关 UI 与对象状态协同厘革，优化用户界面及时响应结果。
    
  
  
• @Observerd
  
  
  
  • 功能：自动监测被修饰变量或对象的属性改变，一旦发生厘革，迅速触发相关 UI 的更新流程，让 UI 始终贴合数据最新情况，实现数据驱动 UI 更新。
    
  • 协同：融入整体数据处理惩罚与 UI 构建流程，和其他改变数据的操作协同，例如用户输入、后台数据推送，确保数据更新瞬间，UI 也能及时跟进，维持数据与展示的连贯性。
    
  
  

• @StorageLink
  
  
  
  • 功能：它紧张用于将组件内的状态与长期化存储相关联。当被标记的变量发生厘革时，不仅会更新 UI，还会同步更新对应的存储数据，保障数据的长期保存。例如在一个笔记应用里，用户编辑笔记内容，被 @StorageLink 修饰的笔记文本变量，每一次改动，都会及时存入本地存储，无惧意外关闭应用导致数据丢失。
    
  • 协同：与本地存储模块紧密协作，像是和鸿蒙体系的文件体系 API 共同，一方面吸取存储数据初始化组件状态，另一方面，持续推送状态更新，让存储体系与应用内状态互为表里，协同维护数据的完备性与即时性。
    
  
  
• @StorageProp
  
  
  
  • 功能：和 @Prop 有相似之处，不过它额外负担了存储功能。父组件传递给子组件的数据通过 @StorageProp 修饰后，子组件对该数据的修改，除了反馈给父组件更新状态，还会自动存储下来。这在设置类信息传递场景很实用，比如一个主题切换设置，从父组件传到子组件，子组件调解后存好，下次启动应用依然生效。
    
  • 协同：整合父子组件交互流程与存储流程，让跨组件的数据流通环节和长期化环节无缝对接，低沉开辟者额外编写存储逻辑的负担，促使组件交互与数据留存高效协同。
    
  
  
•  @Watcher
  
• 功能：
  
  
  
  • 当一个变量或者对象属性被标注为 @Watcher，它就进入了被 “监控” 状态。只要该变量或属性的值有所变动，与之绑定的 UI 组件会立即感知到这些厘革，从而触发对应的 UI 更新流程。这一机制让开辟者可以或许轻松构建响应式的用户界面，把数据的动态更新与 UI 的及时革新紧密关联起来。例如，在一个及时显示股票价格的鸿蒙应用中，代表股价的变量添加上 @Watcher，股价数据从后台推送过来发生改变时，对应的股价展示 UI 组件，像是文本标签、走势图，会立刻更新显示最新价格。
    
  
  
• 协同：
  
  
  
  • 和数据获取逻辑协同：常与网络哀求、本地数据读取等数据获取本事共同。后端源源不停推送新数据，或是本地数据库数据更新，被 @Watcher 标记的数据吸取新值，随即驱动 UI 协同更新，保障展示内容与最新数据同步。
    
  • 与组件生命周期协同：在组件的生命周期各个阶段，@Watcher 持续发挥作用。从组件创建之初初始化数据，到后续运行中数据的多次更迭，无论组件处于活跃、停息状态，只要数据改变，就能精准更新 UI，维持组件状态与 UI 展示在全生命周期内的同等性。
    
  • 跟其他状态管理机制协同：与 @State、@Prop 等装饰器共存时，进一步细化状态管控。@State 侧重于本地组件状态，@Prop 管理父子组件间数据传递，@Watcher 则专注于数据厘革触发 UI 更新这一关键环节，它们相互交织，为复杂应用的精准状态管理筑牢根基。
    
  
  

---

@Observed装饰器和@ObjectLink装饰器使用场景？

@Observed 和 @ObjectLink 是 HarmonyOS 开辟中用于处理惩罚嵌套对象或数组的数据同步装饰器。它们紧张用于确保数据模子中的属性厘革可以或许反映到视图上，特殊是在 dealing with nested objects or arrays。
@Observed 装饰器 @Observed 用于修饰类，它允许观察类的属性厘革。这使得开辟者可以在类的属性被修改时得到关照，从而实行相应的操作，如更新UI。以下是使用 @Observed 的一个示例：

1. @Observed
2. class Person {
3.     name: string;
4.     age: number;
6.     constructor(name: string, age: number) {
7.         this.name = name;
8.         this.age = age;
9.     }
10. }

复制代码

在这个例子中，Person 类的 name 和 age 属性将被观察。当这些属性发生厘革时，由于 Person 类被 @Observed 装饰，所以这些厘革会被自动同步到使用 Person 实例的组件中。
@ObjectLink 装饰器 @ObjectLink 用于在父组件和子组件之间建立双向数据绑定。它通常与 @Observed 团结使用，以便将 @Observed 装饰的类的实例传递给子组件，并确保任何对类实例的修改都能反映到父组件和子组件的UI中。以下是使用 @ObjectLink 的一个示例：

1. @Component
2. struct MyPerson {
3.     @ObjectLink person: Person
5.     build() {
6.         Column() {
7.             Text(`姓名: $${this.person.name}`)
8.                 .fontSize(20)
9.                 .fontWeight(FontWeight.Bold)
10.             Text(`年龄: $${this.person.age}`)
11.                 .fontSize(15)
12.                 .fontWeight(FontWeight.Regular)
13.         }
14.     }
15. }

复制代码

在这个例子中，MyPerson 组件通过 @ObjectLink 吸取一个 Person 实例。这样，任何对 Person 实例属性的修改都会导致UI的更新。
通过这种方式，@Observed 和 @ObjectLink 帮助开辟者管理和同步复杂的数据结构，简化代码

---

鸿蒙关系型数据库是哪个？使用场景是什么？

鸿蒙操作体系中的关系型数据库是指基于SQLite组件实现的数据库管理体系。这种数据库管理体系提供了一套完备的本地数据库管理机制，支持传统的增、删、改、查等操作，而且可以或许实行用户自界说的SQL语句，以应对更复杂的场景需求。
紧张功能和参数：

• RdbStore ：这是操作关系型数据库的核心接口，通过这个接口可以实行各种数据库操作1。它需要三个参数：context（应用上下文）、config（数据库设置）和callback（回调函数）。
  
• ResultSet ：这是数据库查询结果的集合，允许用户遍历和访问查询结果。
  
• RdbPredicates ：用于界说数据库操作的条件1。
  

使用场景：

• 复杂关系数据存储 ：实用于需要存储具有复杂关系的数据场景，如学校的弟子成绩或公司的员工信息2。这些数据不仅包罗基本的信息（如姓名、编号），还大概涉及多种多样的关联信息（如课程成绩、部门职位等）。
  
• 数据长期化 ：关系型数据库提供了强盛的数据长期化能力，可以或许确保数据的完备性和同等性，特殊适合需要高频更新和复杂查询的应用。
  

注意事项：

• 在使用过程中，建议单条数据不要超过2MB，以确保数据的正确读取。
  
• 大数据量查询时，应尽量避免一次性查询过多数据，建议不超过5000条，并在TaskPool中实行此类操作，以减少对应用性能的影响。
  

---

数据库增删改查的API？

鸿蒙操作体系为SQLite数据库的增删改查操作提供了以下API：

• RdbStore接口 ：
  
  
  
  • 获取RdbStore ：getRdbStore(context: Context, config: StoreConfig, version: number, callback: AsyncCallback<RdbStore>): void12
    
    
    
    • 参数 ：
      
      
      
      • context：应用的上下文。
        
      • config：与此RDB存储相关的数据库设置12。
        
      • version：数据库版本。
        
      • callback：指定callback回调函数，返回RdbStore对象12。
        
      
      
    • 说明 ：通过这个接口，开辟者可以得到一个RdbStore对象，进而实行数据库的操作。这个接口从API版本7开始支持，但已从API版本9起不再维护，推荐使用新的relationalStore模块1。
      
    
    
  
  
• relationalStore模块 ：
  
  
  
  • 获取RdbStore ：getRdbStore(context: Context, config: StoreConfig, callback: AsyncCallback<RdbStore>): void2
    
    
    
    • 参数 ：
      
      
      
      • context：应用的上下文。
        
      • config：与此RDB存储相关的数据库设置。
        
      • callback：指定callback回调函数，返回RdbStore对象。
        
      
      
    • 说明 ：这是推荐使用的 newer API，从API版本9开始支持。它允许开辟者设置数据库操作的参数，并通过回调获取操作结果。
      
    
    
  
  

    relationalStore 的增删改查属性
  
  insertSync
  

• insertSync(table: string, values: ValuesBucket, conflict?: ConflictResolution):number
  
• 向目标表中插入一行数据。由于共享内存巨细限定为2Mb，因此单条数据的巨细需小于2Mb，否则会查询失败。
  

  batchInsertSync
  

• batchInsertSync(table: string, values: Array<ValuesBucket>):number
  
• 向目标表中插入一组数据。
  

  updateSync
  

• updateSync(values: ValuesBucket, predicates: RdbPredicates, conflict?: ConflictResolution):number
  
• 根据RdbPredicates的指定实例对象更新数据库中的数据。由于共享内存巨细限定为2Mb，因此单条数据的巨细需小于2Mb，否则会查询失败。
  

  deleteSync
  

• deleteSync(predicates: RdbPredicates):number
  
• 根据RdbPredicates的指定实例对象从数据库中删除数据。
  

  querySync
  

• querySync(predicates: RdbPredicates, columns?: Array<string>):ResultSet
  
• 根据指定条件查询数据库中的数据。对query同步接口得到的resultSet举行操作时，若逻辑复杂且循环次数过多，大概造成freeze问题，建议将此步骤放到taskpool线程中实行。
  

  

---

鸿蒙数据库支持事件吗?事件是用来解决什么问题的？

鸿蒙的数据库支持事件。
事件紧张用于解决数据库操作中的一系列复杂问题，确保数据的完备性、可靠性与同等性，具体如下：

• 原子性问题
  
  
  
  • 场景：假想一个在线购票体系，当用户购买一张演出票时，数据库需要实行多个操作，比如减少对应场次的余票数量、将购票记载插入订单表、更新用户消费积分等。要是没有事件机制，在实行部分操作后体系忽然崩溃，例如插入订单表成功了，但余票数量没更新，就会造成数据状态混乱。
    
  • 解决：事件具备原子性，将这一系列购票相关操作囊括此中，它们被当作一个不可拆分的单元。要么所有操作都顺利完成，要么只要此中一个环节堕落，整个事件就会回滚，数据库状态规复到事件开启前，避免出现 “半吊子” 数据。
    
  
  
• 同等性问题
  
  
  
  • 场景：在银行转账业务里，从账户 A 转出一笔钱，必须等额转入账户 B，双方的账户余额总和要始终保持稳定。若转账中途遭遇网络故障，只扣了 A 账户的钱，没能成功汇入 B 账户，就冲破了账户余额的同等性。
    
  • 解决：事件把转账涉及的扣钱、转账操作绑定在一起，成功实行完所有步骤，才能提交事件，让数据库状态更新；要是过程中出现意外，事件回滚，维持账户数据的同等性。
    
  
  
• 隔离性问题
  
  
  
  • 场景：多用户并发访问数据库的电商库存管理场景下，多个管理员同时处理惩罚商品入库、出库事宜。假如没有隔离机制，两个管理员同时读取某热门商品的库存数，又各自基于读取到的数据去更新库存，就轻易导致库存数据错误，后续订单分配也会混乱。
    
  • 解决：事件设定差别的隔离级别，通过隔离并发事件，让每个事件实行时不受其他事件干扰。在高隔离级别下，当一个事件正在操作库存数据时，其他事件必须等候它完成，避免并发冲突，保证每个操作都基于准确的库存数据。
    
  
  
• 长期性问题
  
  
  
  • 场景：对于关键业务数据录入，如医院病历体系，大夫录入患者新的诊断信息，这些数据必须永世保存。要是录入后不久发生体系崩溃，数据丢失，后续治疗就失去依据。
    
  • 解决：事件一旦成功提交，其对数据库所做的修改就具有长期性，即使后续遭遇体系故障、重启，数据也不会丢失，因为数据库体系会运用日志、备份等机制保障已提交事件的数据安全落地。
    
  
  

---

navigation和router用过吗？哪个用的多一点？

Navigation和Router都是HarmonyOS中用于实现页面路由的机制，但它们在使用方式和提供的功能上有显着的差异。
Navigation作为一种新的路由解决方案，旨在提供更强盛和灵活的功能。它允许开辟者通过组件来构建页面，支持共享元素的转场，且没有路由数量限定。Navigation还支持嵌套在模态对话框中，提供更高的自界说性，如动效和属性设置。别的，Navigation在性能上也优于Router，因为它通过引用传递参数，支持动态加载组件。
Router则是一个较早的页面路由解决方案，虽然仍然使用广泛，但它的功能较为有限。Router支持通过URL地点举行页面跳转，但每个应用的页面栈容量限定为32个页面。Router也不支持一些高级功能，如共享元素动画和模态框中的路由嵌套。
根据这些信息，可以看出Navigation因为在功能性和性能上的优势，大概会被更多地用于新的HarmonyOS应用开辟中。然而，Router由于其简便性和与现有应用的兼容性，大概仍会在一些旧的应用或特定场景下使用。
总之，选择哪个工具取决于具体的应用需求和开辟者的偏好。建议在新的项目中优先考虑使用Navigation，以使用其更多的功能和更好的性能。

---

navigation常用的生命周期？

其生命周期大抵可分为三类，自界说组件生命周期、通用组件生命周期和自有生命周期。此中，aboutToAppear和aboutToDisappear是自界说组件的生命周期(NavDestination外层包罗的自界说组件)，OnAppear和OnDisappear是组件的通用生命周期。剩下的六个生命周期为NavDestination独有。

• aboutToAppear：在创建自界说组件后，实行其build()函数之前实行（NavDestination创建之前），允许在该方法中改变状态变量，更改将在后续实行build()函数中生效。
  
• onAppear：通用生命周期变乱，NavDestination组件挂载到组件树时实行。
  
• onWillAppear：NavDestination创建后，挂载到组件树之前实行，在该方法中更改状态变量会在当前帧显示生效。
  
• onWillShow：NavDestination组件布局显示之前实行，此时页面不可见（应用切换到前台不会触发）。
  
• onShown：NavDestination组件布局显示之后实行，此时页面已完成布局。
  
• onWillHide：NavDestination组件触发隐藏之前实行（应用切换到后台不会触发）。
  
• onHidden：NavDestination组件触发隐藏后实行（非栈顶页面push进栈，栈顶页面pop出栈或应用切换到后台）。
  
• onWillDisappear：NavDestination组件即将销毁之前实行，假如有转场动画，会在动画前触发（栈顶页面pop出栈）。
  
• onDisappear：通用生命周期变乱，NavDestination组件从组件树上卸载销毁时实行。
  
• aboutToDisappear：自界说组件析构销毁之前实行，不允许在该方法中改变状态变量。
  

---

想获取navigation谁人页面的栈，需要在哪个生命周期获取（用于页面跳转的哪个对象）？

在HarmonyOS开辟中，获取页面栈是通过NavPathStack对象实现的，这个对象是管理页面栈的核心。您可以通过以下方式获取页面栈的巨细：

1. let size: number = this.pathStack.size();

复制代码

这里的pathStack是一个NavPathStack的实例，它包罗了所有页面的路径信息。您可以在需要举行页面跳转或在页面加载时获取这个信息，以便于管理页面的状态和跳转。
别的，您可以通过NavPathStack对象举行页面的push、pop和其他操作，这些操作都会影响到页面栈的状态。因此，建议在页面的aboutToAppear或build方法中获取页面栈的信息，这两个方法分别在页面即将显示和页面构建时被调用，是获取页面栈的理想时机。

---

navigation怎么带参数跳转，跳转页怎吸取参数？

在鸿蒙（HarmonyOS）开辟中，通过Navigation组件传递参数通常涉及到两个方面：设置跳转参数和在目标页面中吸取这些参数。以下是具体的实现步骤：

• 设置跳转参数 ： 在跳转到另一个页面时，你可以通过NavPathStack来传递参数。例如，假如你从一个名为LoginPage的页面跳转到UserProfilePage，可以在pushPath方法中设置参数，如下所示：
  
  1. function pushPath(name, param, animated, onPop) {
  2.     has.navPathStack.pushPath({
  3.         name: name,
  4.         param: param,
  5.         animated: animated,
  6.         onPop: onPop,
  7.         callback: (err, res) => commonCallback('pushPath', err, res)
  8.     });
  9. }

  复制代码
  在这个例子中，name是要跳转到的页面名称，param是要传递的参数。
  
• 在目标页面中吸取参数 ： 当你在目标页面中需要使用这些参数时，可以通过适当的方法来吸取它们。这通常在目标页面的加载或初始化过程中完成，例如在UserProfilePage中，你大概会这样使用参数：
  
  1. function handleParams(params) {
  2.     // 处理接收到的参数
  3.     console.log("接收到的参数：", params);
  4. }

  复制代码

通过上述步骤，你可以在Navigation组件中有效地传递和吸取参数，从而实现更复杂的功能和页面交互。
获取参数的方法

• 通过索引获取参数 ：你可以使用 getParamByIndex(index) 方法来获取指定索引的 NavDestination 页面的参数信息。例如，假如你想要获取索引为1的页面参数，可以使用以下代码：
  
  1. let param = this.pathStack.getParamByIndex(1);

  复制代码
• 通过页面名获取参数 ：假如你知道页面的名字，可以使用 getParamByName(name) 方法来获取所有名为 name 的 NavDestination 页面的参数信息1。例如，假如页面名为 PageOne，你可以这样获取它的参数：
  
  1. let params = this.pathStack.getParamByName("PageOne");

  复制代码

这些方法允许你在导航过程中灵活地获取和管理页面参数，从而实现复杂的功能组合和页面间的数据交互。
通过这些方法，你可以轻松地在页面之间传递和吸取参数，这对于维护页面的状态和实现复杂的导航逻辑非常有效。

---

git场景题：假如我在一个分支上功能写了一半，现在我需要去另一个分支写其他功能，请问用哪个git命令可以解决这个问题

• 暂存当前工作进度
  
  
  
  • 实行 git stash
     ，该命令会把当前工作区（包罗未提交的修改、暂存区新增内容等 ）的所有改动收集起来，保存到一个雷同栈的结构中，让工作目录立即变得干净，仿佛从未做过这些修改一样。示例：
    
  
  

1. git stash

复制代码

• 切换分支
  
  
  
  • 完成暂存后，就可以安心使用 git checkout 命令切换到目标分支，着手开辟新功能。假设要切换到名为 new-branch 的分支，命令如下：
    
  
  

1. git checkout new-branch

复制代码

• 规复暂存的工作
  
  
  
  • 当在新分支的工作告一段落，想要回到之前未完成的功能分支接着开辟时，先切回原来的分支：
    
  
  

1. git checkout original-branch

复制代码

• 接着，使用 git stash
  apply 把之前暂存的工作内容重新应用到当前工作区，让之前未完成的工作状态得以规复，继续接着之前的进度开辟：
  

1. git stash
2. apply

复制代码

需要注意的是，git stash
apply 实行后，暂存的内容并不会从栈里删除。要是想删除这个已经应用的暂存项，可以额外实行 git stash
drop；要是想一步到位，在应用的同时删除暂存内容，就用 git stash
pop 命令。

---

http和https的区别，https为啥是安全的？

HTTP（超文本传输协议）和 HTTPS（超文本传输安全协议）紧张有以下几方面区别：

• 数据传输安全性
  
  
  
  • HTTP：使用明文传输数据，数据在网络传输过程中，是以原始的文本格式出现，这就导致像用户名、密码、银行卡号这类敏感信息，非常轻易被网络中的第三方截获，毫无保密性可言。
    
  • HTTPS：在传输层与应用层之间参加了 SSL/TLS 加密层，所有传输的数据都会先举行加密处理惩罚变成密文，吸取方再用对应的密钥解密还原，就算数据中途被截取，第三方没有密钥也无法解读内容。
    
  
  
• 端口使用
  
  
  
  • HTTP：默认工作在 80 端口，当我们在浏览器地点栏输入网址，不特殊指定端口号时，浏览器就默认通过 80 端口去毗连目标服务器，发起 HTTP 哀求。
    
  • HTTPS：常用的工作端口是 443，同理，访问 HTTPS 网站，若不额外输入端口号，浏览器自动从 443 端口尝试建立毗连。
    
  
  
• 性能开销
  
  
  
  • HTTP：因为无需加密、解密操作，传输过程相对简便快速，对服务器的计算资源占用较少，数据传输效率更高。
    
  • HTTPS：加密和解密过程会消耗大量的服务器 CPU、内存资源，尤其是在高并发场景下，额外的运算负担会让响应时间有所延伸，性能开销显着更大。
    
  
  
• 证书要求
  
  
  
  • HTTP：不逼迫要求使用数字证书，网站搭建部署更为简便直接，小型个人站点常接纳 HTTP 协议。
    
  • HTTPS：必须申请权势巨子 CA 机构颁发的 SSL/TLS 数字证书，以此证明服务器身份正当性，证书申请、更新等流程增长了网站运维本钱与复杂度。
    
  
  

HTTPS 之所以安全，核心在于它的加密机制与身份认证体系：

• 加密机制
  
  
  
  • 混淆加密：结合了对称加密与非对称加密的优势。通讯开始时，客户端与服务器使用非对称加密（公钥、私钥体系 ）来安全交换对称加密所需的密钥 ，后续大量的数据传输就接纳运算速率更快的对称加密。例如，客户端向服务器发起哀求，服务器把公钥发给客户端，客户端使用公钥加密自己生成的对称密钥，再传回给服务器，之后双方就用这个对称密钥加密传输实际数据，分身了安全性与传输效率。
    
  
  
• 身份认证
  
  
  
  • 数字证书：服务器部署 SSL/TLS 数字证书，证书里包罗服务器的公钥以及服务器的身份信息，诸如域名、构造等。客户端访问服务器时，会验证证书真伪，只有通过 CA 机构严格审核验证的正当证书，客户端才会信托该服务器与之通讯，杜绝中央人伪装成正当服务器窃取数据的隐患，防止遭遇钓鱼网站。
    
  
  

---

https是怎么加密的？

非对称加密与证书验证

• 服务器发送证书：客户端向服务器发起 HTTPS 毗连哀求后，服务器会将包罗自身公钥、域名、证书颁发机构、证书有效期等信息的数字证书发送给客户端。
  
• 客户端验证证书：客户端吸取到证书后，会验证证书的正当性，包罗查抄证书是否由可信的证书机构颁发、证书是否在有效期内、证书中的域名与服务器的实际域名是否同等等。假如证书验证不通过，客户端会中断毗连；假如验证通过，则进入下一步。
  

对称加密密钥协商

• 客户端生成对称密钥：客户端在本地生成一个随机数，用尴尬刁难称加密的密钥。
  
• 客户端加密并发送密钥：客户端取出证书中的公钥，用该公钥对随机数举行加密，将加密后的结果发送到服务端。
  
• 服务端解密获取密钥：服务端收到客户端发来的加密后的密钥，先用自己的私钥解密，得到对称密钥。
  

数据加密传输

• 使用对称密钥加密数据：客户端和服务器使用协商好的对称密钥对传输的数据举行加密和解密。在数据传输过程中，发送方将数据用对称密钥加密成密文后发送，吸取方收到密文后用雷同的对称密钥举行解密还原出原始数据。   

  ---

  信息仅供参考，如有更优方案，欢迎批评，谢谢
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。