HarmonyOS鸿蒙Next中在native中刷新arkUi的进度遇到的问题
HarmonyOS鸿蒙Next中在native中刷新arkUi的进度遇到的问题 先参考的这个
https://developer.huawei.com/consumer/cn/forum/topic/0208142474662146482?fid=0109140870620153026
我遇到的问题是，可以调，但全是在最后执行，感觉是阻塞了一样
主线是个下载按钮，点击后在native里启动curl下载，curl下载有个进度回调，可以获取下载了多少，然后我在这里想直接callfunction,不允许，只能用napi_call_threadsafe_function，然后我就在启动curl之前开了个thread，不断地读取进度值，在进度回调刷新进度值，然后napi_call_threadsafe_function，这种方式在所有下载完了之后才会执行这个napi_call_threadsafe_function，然后我又换了napi_queue_async_work的方式，然后一样的结果，有谁知道我是哪里阻塞了么
更多关于HarmonyOS鸿蒙Next中在native中刷新arkUi的进度遇到的问题的实战教程也可以访问 https://www.itying.com/category-93-b0.html
搞定，因为curl阻塞了，奇了怪了，这样会被阻塞，那呢个优先级有啥用
更多关于HarmonyOS鸿蒙Next中在native中刷新arkUi的进度遇到的问题的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html
在HarmonyOS Next中，通过Native层刷新ArkUI进度时，需使用Native API与ArkUI通信。可使用NativeModule或NativeComponent机制，通过JSBinding传递数据。在Native侧调用CallJsMethod触发ArkUI更新，或利用EventEmitter发送事件。确保线程安全，避免阻塞UI线程。
在HarmonyOS Next的Native层刷新ArkUI进度时，你遇到的阻塞问题通常是由于线程同步或消息队列处理不当导致的。根据你的描述，你已经在Native层启动了下载线程，并通过napi_call_threadsafe_function或napi_queue_async_work尝试更新进度，但回调直到下载完成后才执行。这可能是以下原因造成的：
-
线程安全函数的调用未正确触发：
napi_call_threadsafe_function需要确保在非UI线程中调用，并且关联的线程安全函数已正确初始化。如果下载线程在调用时未及时唤醒主线程的消息队列，更新可能会被延迟到下载结束后才批量处理。 -
异步工作队列的调度延迟：
napi_queue_async_work虽然能将任务加入队列，但如果主线程忙于处理其他任务（如下载操作占用资源），异步任务可能被积压，直到下载线程结束后才被调度执行。 -
进度回调频率过高导致阻塞：如果下载进度回调触发非常频繁（例如每秒数百次），而Native层向ArkUI传递数据的通道（如线程安全函数）处理速度跟不上，可能会造成消息堆积，最终在下载结束后才被处理。
建议检查点：
- 确保在调用
napi_call_threadsafe_function时，使用napi_tsfn_nonblocking模式，避免阻塞下载线程。 - 在进度回调中，可以加入简单的节流机制（例如每下载1%或100ms才触发一次更新），减少消息数量。
- 验证线程安全函数的回调是否在ArkUI主线程中正确执行UI更新逻辑，避免在Native层进行耗时操作。
如果问题仍存在，可以尝试简化测试，例如在进度回调中只传递简单数据，排除curl下载逻辑本身的影响。
