背景
在开发鸿蒙的cronet版本时候，发现如果同时用for循环发起多个网络请求，在cronet网络线程回调到uv_queue_work时候，after_work_cb只会回调一次，然后js主线程就ANR了，一脸懵逼的我，我一度怀疑自己理解错鸿蒙的线程模型。
问题
在第一个after_work_cb触发时候，调用《C++处理业务代码》里面的 “workData->handler_(workData->env_, workData->data_)”，会回调到RequestCallback函数里面，触发了死循环，把ArkTS线程（主线程）卡死了，在3秒系统检测后就会ANR退出app。因为js调用C++由于是另外开辟线程（“std::thread testThread(StartThread, asyncContext);”）添加任务到uv_queue里面，所以日志打印是可以看到对应循环次数的 "add uv_queue_work" 输出，但是日志只会输出一次“WorkData::workData->handler_ before”一次调用，如果后面不加日志来看，就造成了一种after_work_cb不调用的假象，其实是主线程被我们的函数给卡死了，没机会执行队列中下一个函数。
JS代码
- 在NativeMultiThreads/entry/src/main/cpp/types/libentry/index.d.ts定义好下面js接口
export const queueWork: (arg: number) => Promise<number>;
C++层代码
- 下面是定义函数传递内容，持有js的上下文，和js对应映射的c++方法
struct CallbackContext {
napi_env env = nullptr;
napi_deferred deferred_;
int32_t retData = 0;
};
static napi_value QueueWork(napi_env env, napi_callback_info info) {
size_t argc = 1;
napi_value argv[1] = {nullptr};
napi_value thisVar = nullptr;
void *data = nullptr;
napi_get_cb_info(env, info, &argc, argv, &thisVar, &data);
// 参数检查
if (argc < 1) {
napi_throw_error(env, "ParameterError", "one param expected");
return nullptr;
}
// 保存env和回调函数，以便后续回调
auto asyncContext = new CallbackContext();
napi_value result = nullptr;
napi_create_promise(env, &asyncContext->deferred_, &result);
asyncContext->env = env;
// napi_create_reference(env, argv[0], 1, &asyncContext->callbackRef);
// 模拟抛到非js线程执行逻辑
std::thread testThread(StartThread, asyncContext);
testThread.detach();
return result;
}
C++处理业务代码
void RequestCallback(napi_env env, void *data) {
CallbackContext *context = static_cast<CallbackContext *>(data);
napi_value retArg;
napi_create_int32(env, context->retData, &retArg);
napi_resolve_deferred(env, context->deferred_, retArg);
//todo 死循环
while(1) {
}
}
//子线程调用函数，主要问题出在RequestCallback函数里
void StartThread(CallbackContext *context) {
// 从env中获取对应的ArkTS线程的loop，此处的env需要在注册JS回调时保存下来。
uv_loop_s *loop = nullptr;
napi_get_uv_event_loop(context->env, &loop);
context->retData = 1;
auto workData = new WorkData(context->env, context, RequestCallback);
auto work = new uv_work_t;
work->data = reinterpret_cast<void *>(workData);
OH_LOG_Print(LOG_APP, LogLevel::LOG_INFO, CRONET_LOG_DOMAIN, "magic native", "add uv_queue_work");
// 抛任务到ArkTS线程
uv_queue_work(
loop, work,
// work_cb
// 此回调在另一个普通线程中执行，用于处理异步或者耗时任务，回调执行完后执行下面的回调。本示例中无需执行任务。
[](uv_work_t *work) {},
// after_work_cb 此回调在env对应的ArkTS线程中执行。
[](uv_work_t *work, int status) {
OH_LOG_Print(LOG_APP, LogLevel::LOG_INFO, CRONET_LOG_DOMAIN, "magic native", "uv_queue_work callback");
auto workData = static_cast<WorkData *>(work->data);
napi_env env = workData->env_;
napi_handle_scope scope = nullptr;
// 打开handle scope用于管理napi_value的生命周期，否则会内存泄露。
napi_open_handle_scope(env, &scope);
if (scope == nullptr) {
return;
}
OH_LOG_Print(LOG_APP, LogLevel::LOG_INFO, CRONET_LOG_DOMAIN, "magic native", "WorkData::workData->handler_ before");
workData->handler_(workData->env_, workData->data_);
OH_LOG_Print(LOG_APP, LogLevel::LOG_INFO, CRONET_LOG_DOMAIN, "magic native",
"WorkData::workData->handler_ after");
napi_close_handle_scope(env, scope);
if (work != nullptr) {
delete work;
}
delete workData;
});
}
解决
- 把《 C++处理业务代码》里面的 while死循环删除掉，after_work_cb 就可以正常工作了
总结
- 官方uv_queue_work介绍
- 官网基本api都会给出简单示例，自己多结合项目排查问题即可
