图片处理你是怎么做的
图片处理
上传文件有没有做过
上传应用文件
开发者可以使用上传下载模块（ohos.request）的上传接口将本地文件上传。文件上传过程使用系统服务代理完成, 在api12中request.agent.create接口增加了设置代理地址参数，支持用户设置自定义代理地址。
说明
当前上传应用文件功能，仅支持上传应用缓存文件路径（cacheDir）下的文件。
使用上传下载模块，需声明权限
：ohos.permission.INTERNET。
下载网络资源文件至应用文件目录
开发者可以使用上传下载模块（ohos.request）的下载接口将网络资源文件下载到应用文件目录。对已下载的网络资源文件，开发者可以使用基础文件IO接口（ohos.file.fs）对其进行访问，使用方式与应用文件访问一致。文件下载过程使用系统服务代理完成, 在api12中request.agent.create接口增加了设置代理地址参数，支持用户设置自定义代理地址。
说明
当前网络资源文件仅支持下载至应用文件目录。
使用上传下载模块，需声明权限：ohos.permission.INTERNET。
你是怎么做布局适配的呢
界面适配
网络方面的优化
网络优化
页面优化你是怎么做的呢
- 减少主线程上的耗时操作
- 避免在主线程上执行长时间加载的内容或其他非UI任务。这些任务应该通过异步任务延迟处理或分配到其他线程处理。
- 优化布局性能
- 减少UI布局的嵌套层次，使用高性能布局节点。
- 精确控制状态变量的关联组件数，移除冗余的组件关联。
- 在对象上谨慎使用状态变量关联，以减少不必要的UI更新操作。
- 使用ArkTS高性能编程实践
- 利用ArkTS的编程特性，使得代码更容易被方舟编译运行时进行编译优化，生成更高性能的机器码。
- 采用AOT（Ahead-Of-Time）编译模式，通过PGO（Profile-Guided Optimization）方式提前生成高性能机器码。
- 减少丢帧卡顿
- 避免在主线程上执行耗时操作，以减轻UI主线程的负载。
- 减少渲染进程的冗余开销，例如使用资源图代替绘制、合理使用
renderGroup、尺寸位置设置尽量使用整数。 - 避免频繁更新UI，减少不必要的界面刷新或布局计算。
- 利用组件复用
- 使用ArkUI提供的组件复用机制，如
LazyForEach，以减少组件的频繁创建和销毁开销。
- 使用ArkUI提供的组件复用机制，如
- 优化内存管理
- 合理使用分页内存管理，提高内存利用率，减少内存碎片。
- 根据应用需求选择合适的内存分配策略，如动态分配、静态分配或伙伴系统。
- 及时释放不再使用的内存，避免内存泄漏问题。
- 延迟加载
- 将不必要的资源延迟加载，特别是在应用启动阶段，以减少启动时间。
- 图片加载优化
- 使用系统提供的Image组件的异步加载特性，避免图片加载阻塞页面显示。
- 代码逻辑优化
- 审查并优化代码逻辑，确保代码的高效执行。
- 使用性能分析工具
- 利用鸿蒙系统提供的性能分析工具，如性能分析器（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, 就可以实现双向绑定 当层级很深时, 不