鸿蒙开发踩坑三(uv_queue_work的after_work

背景

在开发鸿蒙的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代码

1. 在NativeMultiThreads/entry/src/main/cpp/types/libentry/index.d.ts定义好下面js接口

export const queueWork: (arg: number) => Promise<number>;

C++层代码

1. 下面是定义函数传递内容，持有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;
        });
}

解决

1. 把《 C++处理业务代码》里面的 while死循环删除掉，after_work_cb 就可以正常工作了

总结

1. 官方uv_queue_work介绍
2. 官网基本api都会给出简单示例，自己多结合项目排查问题即可