关于ArkUI渲染性能优化的几个“隐形”坑 最近在做列表页优化，发现即使数据量不大，滑动时还是有轻微掉帧。排查后发现，问题不出在数据量，而出在一些容易被忽略的渲染细节上。 1.避免在build()函数中执行复杂计算 build()函数在状态更新时会频繁调用。如果在这里面进行复杂的逻辑运算、数据格式化或对象创建，会直接阻塞UI渲染线程。正确的做法是将计算结果缓存起来，或者在状态更新时预先计算好。 2

在OpenHarmony应用开发中，网络请求是基础且高频的操作。一个清晰、可维护的网络模块架构能有效提升开发效率和代码质量。 1.摒弃全局单例模式 问题：传统的全局单例模式（如export default new HttpClient()）在Stage模型中可能导致Context上下文获取失败的问题，尤其是在应用启动初期。 风险：依赖全局状态会使得模块耦合度高，难以进行单元测试和独立维护。 2.采

在Stage模型中，系统对后台任务的管理更为严格，以确保设备的性能和续航。实现可靠的后台服务（如文件下载、音乐播放）需要遵循特定的策略。 1.使用前台服务 核心方法：在ServiceAbility的onStart生命周期回调中，调用createNotification方法创建一个持续的通知。 作用：将服务提升为前台服务，显著降低被系统回收的概率。通知会持续显示在状态栏，告知用户有任务正在后台运行。

一、启动优化 优化方案： 精简启动初始化操作：避免在Application、Ability的onCreate方法中，执行大量初始化操作（如加载全局数据、初始化第三方SDK、同步接口请求）；将非必要的初始化操作，延迟到首屏渲染完成后执行（如在onWindowStageCreate方法中，通过setTimeout延迟初始化）。 优化资源加载：减少启动时加载的资源数量（如避免启动时加载大量图片、字体）；

一、应用闪退 1. 排查思路​ 闪退问题的排查核心是“捕获异常日志”，通过日志定位具体报错代码行，再分析报错原因。OpenHarmony应用闪退时，会在DevEco Studio的“Run”日志或设备日志中输出异常信息，重点关注“Error”“Crash”“Exception”等关键词。​ 2. 常见场景与解决方案​ 场景1：页面跳转时闪退，日志提示“Ability not found”​ 原因：

一、环境安装类 问题1：DevEco Studio无法自动下载SDK，提示“网络连接失败” 排查思路：优先排查网络与代理配置，这是最常见的原因；其次检查SDK路径是否合法，避免中文、空格等特殊字符。 解决方案： 检查网络通畅性，关闭防火墙、杀毒软件，尝试访问OpenHarmony官方网站，确认网络能正常访问外网。 若所在网络有管控（如公司内网），进入DevEco Studio配置界面，依次点击“S

v7验证 1.部署 1.接入D100开发板，进入hdc模式，挂载根目录 hdcshell mount-oremount,rw / 2.传输三方库到开发板根目录 hdcfile send D:\app\inotify.tar.gz / 3.解压缩到开发板根目录，设置环境变量 tar-zxvfinotify.tar.gz exportPATH=/inotify/bin:$PATH exportLD_L

v8验证 1.部署 1.接入c200开发板，进入hdc模式，挂载根目录 hdcshell mount-oremount,rw / 2.传输三方库到开发板根目录 hdcfile send D:\app\inotify.tar.gz / 3.解压缩到开发板根目录，设置环境变量 tar-zxvfinotify.tar.gz exportPATH=/inotify/bin:$PATH exportLD_L

1.拷贝 将build.tar.gz压缩包拷贝到用户的编译目录下解压 tar-zxvfbuil.tar.gz 目录层级： build ├── inotifypatch.patch └── inotify.sh 2.修改 1.打开编译脚本inotify.sh 2.修改“用户配置路径” 3.编译 安装工具 sudoapt-get install autoconf automake libtool 进入

can-utils测试验证（V7验证D100开发板，支持can fd） 先从iproute中编译出ip命令，拷贝到can-utils可执行文件中 在客户端执行 ./ip link set down can0 ./ip link set can0 type can bitrate 1000000 dbitrate 1000000 fd on ./ip link set can0 type can l