鸿蒙综合讨论/so 插件 dlopen 迁移

so 插件 dlopen 迁移

桌面应用常用插件架构:功能模块编译成独立 so,运行时按需加载(配置目录扫插件、用户装插件)。这套机制迁移到鸿蒙,有几个必须处理的差异。这篇讲 dlopen 插件迁移。

▍插件架构的迁移面
插件机制三要素:发现(哪里找插件——配置目录、注册表文件)、加载(dlopen 加 dlsym 取入口)、生命周期(初始化、卸载、版本协商)。鸿蒙侧的变化主要在发现与加载:插件文件必须随包分发(没有运行时下载安装的通道——市场分发机制约束),沙箱内路径要重新规划(配置与插件目录篇),加载要过 musl 的严格检查。

▍发现机制改造
桌面习惯:系统目录、家目录、环境变量指定的目录扫描。鸿蒙改造:插件目录固定在应用包内(预编译库目录或 rawfile 部署后目录),发现逻辑改为扫描包内清单(构建期生成插件列表——打包清单纪律再次生效)或固定目录。用户级扩展(用户自己装插件)的形态:应用数据目录的插件区加安全校验(来源、签名、完整性——别重蹈桌面插件被滥用的覆辙)。

▍加载的纪律
dlopen 的路径与顺序:相对与绝对路径在沙箱内的解析(路径视图差异);依赖闭包(插件依赖的库都要在包里——依赖闭包递归核对,打包篇的方法)。musl 严格性:依赖名去版本号、段对齐合规(ELF 纪律篇)。加载失败的诊断:错误日志带插件名与失败原因(找不到文件、找不到符号、格式拒绝——三种原因三种修法)。

▍卸载的风险
dlopen 容易 dlclose 难:卸载插件时残留的引用(回调注册没清、静态状态、线程)造成悬空指针崩溃。工程实践:能不卸载就不卸载(加载后常驻,重启生效——插件的更新走应用版本节奏);必须卸载的场景(内存紧张)要设计完整卸载协议(注销回调、等待在途调用、释放资源、再卸库)。

▍版本与兼容
插件接口版本协商(接口版本号校验,不匹配拒载并提示);插件与主程序的符号冲突(隔离编译选项,别让两个插件的同名符号互相覆盖)。

▍验收
全插件加载日志零失败;禁用单个插件的降级行为正确(缺了它应用照常跑);插件清单与包内核对。

更多真实移植案例,欢迎到 apps 板块翻看 56 篇《鸿蒙PC适配全记录》系列实录。
楼主 7 天前
想参与讨论?登录 或 30 秒注册。