HarmonyOS应用中正确释放Native层对象的实践与思

作为一名长期从事鸿蒙系统应用开发的工程师，我深知在跨平台应用开发中，正确管理内存资源的重要性。特别是在使用JavaScript与Native层交互时，如何确保Native对象能够被正确释放，一直是我们团队关注的焦点。最近，我们在开发过程中遇到了一个关于Native对象释放的问题，通过深入分析和实践，我们找到了解决方案，并在此分享我们的思考过程。

问题描述

在我们的应用中，当JavaScript层创建了一个Native层的对象后，如果JavaScript层的对象被释放，Native层的对象并没有随之释放，导致内存泄漏。具体代码如下：

typescript 复制代码

import { VodPlayerNapi } from 'libtransvod.so';

export class VodPlayer {
    public constructor() {
        this.napiContext = new VodPlayerNapi();
    }
}

// 创建播放器
let player = new VodPlayer();
// ...
// 最后执行释放播放器操作
player = undefined;

在Native层，我们使用了napi_wrap来绑定JavaScript对象与Native对象：

cpp 复制代码

napi_value VodPlayerNapi::jsConstruct(napi_env env, napi_callback_info info) {
    // ...
    VodPlayerNapi *napiClass = new VodPlayerNapi();
    napi_wrap(
        env, thisVar, napiClass,
        [](napi_env env, void *data, void *hint) {
            VodPlayerNapi *n = (VodPlayerNapi *)data;
            OH_LOG_Print(LOG_APP, LOG_INFO, LOG_DOMAIN, "napi-test", "delete player %{public}p", n);
            delete n;
        },
        nullptr, nullptr);
    // ...
}

问题在于，当JavaScript的player对象被置为undefined时，Native层的napi_wrap回调并没有被执行，导致Native对象没有被删除。

解决方案

经过深入研究，我们发现问题的关键在于napi_wrap的最后一个参数。如果该参数不为nullptr，则需要开发者手动调用napi_remove_wrap来释放资源。在我们的代码中，由于最后一个参数是nullptr，系统没有自动管理这个引用，因此我们需要修改代码来手动管理。

正确的做法是在napi_wrap时，将最后一个参数设为一个napi_ref指针，并在适当的时机调用napi_remove_wrap来释放资源。修改后的代码如下：

cpp 复制代码

napi_ref result;
napi_wrap(env, jsobject, nativeObject, cb, nullptr, &result);
// 当js_object和result不再使用时，及时调用napi_remove_wrap释放result
napi_value result1;
napi_remove_wrap(env, jsobject, result1);

思考与总结

通过这次问题的解决，我们深刻认识到在鸿蒙系统的应用开发中，合理使用napi_wrap和napi_remove_wrap对于管理Native层资源的重要性。开发者需要根据实际的业务场景，合理设置napi_wrap的参数，并在适当的时候手动释放资源，以避免内存泄漏和其他潜在的性能问题。

此外，我们也意识到在开发过程中，持续的代码审查和性能优化是必不可少的。通过定期的代码审查，我们可以及时发现并解决这类问题，确保应用的稳定性和性能。

总之，正确处理JavaScript与Native层的交互，特别是在资源管理方面，是鸿蒙系统应用开发中的一项重要技能。希望通过分享我们的经验，能够帮助更多的开发者避免类似的问题，共同推动鸿蒙生态的发展。