HarmonyOS鸿蒙Next中碰一碰之后的卡片出现比较缓慢

HarmonyOS鸿蒙Next中碰一碰之后的卡片出现比较缓慢 【问题描述】：碰一碰之后的卡片出现比较缓慢，应该排除哪里的问题呢？
harmonyShare.on 里面的逻辑才执行9ms，但实际要两三秒才出现碰一碰卡片

碰一碰如果utd类型是HYPERLINK，不传递thumbnail会卡bug？thumbnail 我只放了个6kb的，应该不算大吧。。

【问题现象】：harmonyShare.on 里面的逻辑才执行9ms，但实际要两三秒才出现碰一碰卡片

【版本信息】：未涉及

【复现代码】：未涉及

【尝试解决方案】：后来逐步排查发现和应用的icon图标有关，用自定义的碰一碰就很卡，用自带的就不卡，这是为什么


更多关于HarmonyOS鸿蒙Next中碰一碰之后的卡片出现比较缓慢的实战教程也可以访问 https://www.itying.com/category-93-b0.html

3 回复

小伙伴你好，这个问题可能是根据系统传输协议导致的。也有可能你当前这个环境太复杂了。

更多关于HarmonyOS鸿蒙Next中碰一碰之后的卡片出现比较缓慢的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html


鸿蒙Next碰一碰后卡片加载缓慢，主要与设备发现、网络协商及卡片渲染流程相关。优化方向包括：确保NFC功能正常、设备间网络连接稳定、减少卡片资源包体积。可通过DevEco Studio的调试工具分析具体耗时环节。

根据你的描述，卡片出现缓慢但 harmonyShare.on 回调逻辑执行时间很短，问题很可能出在卡片渲染阶段，而非业务逻辑。结合你提到的“自定义icon卡顿，自带icon流畅”，可以重点排查以下两点：

  1. 自定义Icon资源问题：

    • 格式与尺寸：确保自定义图标（包括你提到的thumbnail）使用的是HarmonyOS推荐格式（如PNG）和标准尺寸。过大的分辨率或非标准格式（如WebP未良好支持）会导致解码和渲染耗时。
    • 资源路径：检查自定义图标的资源引用路径是否正确。如果资源未正确打包或路径错误，系统可能在渲染时进行查找或回退处理，造成延迟。
    • 优化建议：将自定义图标压缩至合适大小（例如，用于卡片的图标建议不超过几十KB），并确保其符合UI规范。

  2. 卡片布局与渲染优化：

    • 虽然harmonyShare.on回调快，但卡片的UI布局可能比较复杂，或者包含需要动态加载的内容（如网络图片）。首次渲染时，布局计算和资源加载可能成为瓶颈。
    • 对于HYPERLINK类型的utd，thumbnail虽然不是必传，但传递一个过小或格式不规范的图片可能导致渲染管线等待或重试。你使用的6KB图片虽小，仍需确认其格式和尺寸是否符合卡片渲染引擎的预期。

排查方向：

  • 检查自定义图标和thumbnail的格式、尺寸是否符合HarmonyOS Next的卡片开发规范。
  • 简化卡片的初始布局，排除布局复杂度和动态加载对首次渲染的影响。
  • 在真机上使用DevEco Studio的性能分析工具（如Profiler）监控卡片渲染期间的CPU、内存及UI线程性能，定位具体瓶颈。

总结：问题根源很可能在于自定义图标的处理或卡片UI的渲染环节，而非业务逻辑代码。建议从资源规范和渲染性能两个角度切入排查。

回到顶部