协议插件与动态加载

【踩坑实录】协议插件与动态加载

▍现象
远程桌面工程（GTK3 客户端）的插件体系：上游是一个连接管理器加一组协议插件（RDP、VNC、SSH 各一个插件），运行时从系统插件目录动态加载。移植后插件加载全部失败——系统插件目录在沙箱里不存在，插件找不到自然全灭。

▍定位过程
桌面 Linux 上这类应用的运行时前提一整串：系统的窗口后端、窗口管理器、系统插件目录、托盘协议、可执行文件导出的服务函数表。工程记录的定性：这些前提在鸿蒙沙箱里一个都不存在——只把本体编成动态库，得到的是无法出窗口、无法加载插件、无法断开连接的空壳。插件加载这一环的具体断点：目录指向（系统的全局插件路径）与加载机制（运行时模块加载）都建立在桌面文件系统布局上。

▍对策
两级重定向（工程的登记条目）：一，目录重定向——插件的查找路径经环境变量指向应用包内目录（打包时协议插件以独立库形态放进去，环境变量在进程最早期设置——环境前置的老纪律）；二，加载机制沿用——模块加载接口（g_module_open 族）在目标环境可用，插件库本体按 ELF 纪律（依赖闭包齐、无版本号依赖名）打进包里，运行时按需加载。插件与主程序的服务函数表对接保持上游语义（主程序导出符号表供插件反查——这个机制在沙箱内照常工作）。

▍根因抽象
插件体系的移植三查：查找路径（桌面全局路径改应用包内路径）、加载机制（动态加载在沙箱可用但依赖闭包要自己背）、服务对接（主程序与插件的双向符号协商）。三查过了，插件体系原样活。

▍方法论沉淀
插件目录的环境变量重定向是廉价而有效的标准解法；插件的依赖闭包核对（每个插件拉一遍依赖树核对包内齐全）进打包检查。

插件重定向的完整登记在远程桌面工程实录，apps 板块 56 篇欢迎对照。