鸿蒙面试题

图片处理你是怎么做的

图片处理

上传文件有没有做过

上传应用文件
开发者可以使用上传下载模块（ohos.request）的上传接口将本地文件上传。文件上传过程使用系统服务代理完成, 在api12中request.agent.create接口增加了设置代理地址参数，支持用户设置自定义代理地址。

说明

当前上传应用文件功能，仅支持上传应用缓存文件路径（cacheDir）下的文件。

使用上传下载模块，需声明权限
：ohos.permission.INTERNET。

下载网络资源文件至应用文件目录
开发者可以使用上传下载模块（ohos.request）的下载接口将网络资源文件下载到应用文件目录。对已下载的网络资源文件，开发者可以使用基础文件IO接口（ohos.file.fs）对其进行访问，使用方式与应用文件访问一致。文件下载过程使用系统服务代理完成, 在api12中request.agent.create接口增加了设置代理地址参数，支持用户设置自定义代理地址。

说明

当前网络资源文件仅支持下载至应用文件目录。

使用上传下载模块，需声明权限：ohos.permission.INTERNET。

你是怎么做布局适配的呢

界面适配

网络方面的优化

网络优化

页面优化你是怎么做的呢

1. 减少主线程上的耗时操作
   • 避免在主线程上执行长时间加载的内容或其他非UI任务。这些任务应该通过异步任务延迟处理或分配到其他线程处理。
2. 优化布局性能
   • 减少UI布局的嵌套层次，使用高性能布局节点。
   • 精确控制状态变量的关联组件数，移除冗余的组件关联。
   • 在对象上谨慎使用状态变量关联，以减少不必要的UI更新操作。
3. 使用ArkTS高性能编程实践
   • 利用ArkTS的编程特性，使得代码更容易被方舟编译运行时进行编译优化，生成更高性能的机器码。
   • 采用AOT（Ahead-Of-Time）编译模式，通过PGO（Profile-Guided Optimization）方式提前生成高性能机器码。
4. 减少丢帧卡顿
   • 避免在主线程上执行耗时操作，以减轻UI主线程的负载。
   • 减少渲染进程的冗余开销，例如使用资源图代替绘制、合理使用renderGroup、尺寸位置设置尽量使用整数。
   • 避免频繁更新UI，减少不必要的界面刷新或布局计算。
5. 利用组件复用
   • 使用ArkUI提供的组件复用机制，如LazyForEach，以减少组件的频繁创建和销毁开销。
6. 优化内存管理
   • 合理使用分页内存管理，提高内存利用率，减少内存碎片。
   • 根据应用需求选择合适的内存分配策略，如动态分配、静态分配或伙伴系统。
   • 及时释放不再使用的内存，避免内存泄漏问题。
7. 延迟加载
   • 将不必要的资源延迟加载，特别是在应用启动阶段，以减少启动时间。
8. 图片加载优化
   • 使用系统提供的Image组件的异步加载特性，避免图片加载阻塞页面显示。
9. 代码逻辑优化
   • 审查并优化代码逻辑，确保代码的高效执行。
10. 使用性能分析工具
    • 利用鸿蒙系统提供的性能分析工具，如性能分析器（Profiler），来识别和解决性能瓶颈。

app.json有配置过吗

{
   
  "app": {
   
    /*包名*/
    "bundleName": "com.example.demo",
    /*标识应用的Bundle类型，用于区分应用或者原子化服务。该标签可选值为app 和 atomicService。（-app：当前Bundle为普通应用。-atomicService：当前Bundle为元服务），该标签可以缺省，缺省为app*/
    "bundleType": "app",
    /*应用开发厂商*/
    "vendor": "example",
    /*版本号（该标签值为32位非负整数。此数字仅用于确定某个版本是否比另一个版本更新，数值越大表示版本越高。开发者可以将该值设置为任何正整数，但是必须确保应用的新版本都
    使用比旧版本更大的值。该标签不可缺省，versionCode 值应小于2^31次方）*/
    "versionCode": 10000,
    /*版本名称（该标签仅由数字和点构成，推荐采用 "A.B.C.D"四段式的形式。四段式推荐的含义如下：
    第一段：主版本号/Major，范围0-99，重大修改的版本，如实现新的大功能或重大变化。
    第二段：次版本号/Minor，范围0-99，表示实现较突出的特点，如新功能添加或重大问题修复）。
    第三段：特性版本号/Feature，范围0-99，标识规划的新版本特性。
    第四段：修订版本号/Patch，范围0-999，表示维护版本，修复bug
    标签最大字节长度为127.*/
    "versionName": "1.0.0",
    /*应用图标，该标签不可缺省*/
    "icon": "$media:app_icon",
    /*应用的名称，该标签不可缺省*/
    "label": "$string:app_name",
    /*标识应用是否可调试，该标签由IDE编译构建时生成（-true：可调试；-false：不可调试），该标签可以缺省，缺省为false*/
    "debug": true,
    /*标识应用的描述信息，标签值是字符串类型（最大255个字节）或对描述内容的字符串资源索引。该标签可缺省，缺省值为空*/
    "description": "",
  }
}

你常用的装饰器

1.@Entry

用来装饰 struct 使用表示页面的入口

2.@Component

装饰 struct, 表示该 struct 具有基于组件的能力 保证 struct 内部 包含一个且只能包含一个 build() 函数, 用于绘制 UI 界面 struct 内部, build() 函数外部, 用于存储数据的位置 注意 : build() 函数内部必须要有容器组件

3.@State

用来装饰变量的装饰器( 其实就是用于定义变量 )

必须本地初始化数据, 支持通过构造函数赋值

当 @State 定义的数据被修改的时候, 所在组件的 build() 方法会被重新调用, 重新绘制所在 UI 界面

4.@Prop

继承了 @State 的所有功能 注意 : 定义的时候可以不需要本地直接初始化, 调用子组件的时候需要对其进行赋值 被 @Prop 装饰的变量可以和父组件建立单向同步关系 @Prop 装饰的变量是可变的, 但是修改时不会同步回父组件, 当父组件的 @State 变化时, 本地修改的 @Prop 会被覆盖

5.@Link

@Link 装饰的变量和父组件会构建双向同步关系 父组件会接受来自 @Link 装饰的变量的修改同步 父组件的更新也会同步给 @Link 装饰的变量 @Link 装饰的变量与其父组件中的数据源共享相同的值 注意 : 子组件使用 @Link 定义变量的时候不需要赋值, 而是调用子组件的时候进行赋值 调用子组件赋值的时候使用 “$变量名” 的形式进行赋值 @Link 装饰器不能再 @Entry 装饰的自定义组件中使用 6.@Provide 和 @Consume (层级过深时建议使用)

@Provide(‘名字’) 变量名: 类型 = 赋值

@Consume(‘名字’) 变量名

注意 : @Provide 和 @Comsume 处使用的名字要一致, 但是变量名不需要一致

使用发布订阅模式, 父类使用 @Provide, 其他需要观察的子类使用 @Consume, 就可以实现双向绑定 当层级很深时, 不