dlmopen与dlopen适用场景差异及Linker Namespace技术咨询

1. 用通俗易懂的语言解释Linker Namespace是什么？ #

可以把Linker Namespace理解成共享库的"独立房间"。每个房间里有自己加载的共享库和对应的符号（函数、变量等），房间之间默认互相隔离，不会随便访问对方的符号。Android引入这个机制，就是为了避免不同模块的共享库因符号重名、版本冲突等问题互相干扰，让各模块的运行环境更独立稳定。

2. dlmopen与dlopen的适用场景分别是什么？ #

• dlopen：是最常用的动态加载API，适用于大多数普通场景。它会把共享库加载到当前进程的默认命名空间中，加载的库可直接访问当前命名空间内的其他符号，也会被同空间的其他库访问。比如项目只是简单加载一个工具库、不需要隔离时，用dlopen就足够。
• dlmopen：专门用于需要符号隔离的场景。它可以指定一个独立的Linker Namespace来加载共享库，让这个库运行在专属的"独立房间"里。比如需要加载多个版本的同一款库，或者加载的库和现有库存在符号冲突时，就适合用dlmopen。

3. dlmopen可解决哪些dlopen无法覆盖的问题？ #

• 多版本库共存问题：用dlopen加载不同版本的同一款库时，默认命名空间的符号是全局的，后加载的库会覆盖先加载的符号，导致版本混乱。dlmopen可把不同版本的库放到不同命名空间，各自独立运行、互不干扰。
• 符号冲突问题：如果项目里已有某个符号（比如同名函数），再加载的第三方库也有相同符号，用dlopen会导致符号被覆盖，引发运行错误。dlmopen通过隔离命名空间，让两个同名符号在各自空间独立存在，不会互相影响。
• 严格模块隔离需求：有些敏感模块（比如安全相关库）需要完全独立的运行环境，不希望被其他模块符号干扰，也不希望自身符号被外部访问，dlmopen可以实现这种严格隔离。

4. 我方项目使用dlXXX API运行时加载共享库，需确保加载的符号完全隔离，dlmopen能否解决该问题？ #

可以解决。dlmopen的核心能力就是通过创建或指定独立的Linker Namespace，让加载的共享库及其依赖库都运行在专属空间里，和其他命名空间（包括默认命名空间）的符号完全隔离：

• 该命名空间内的符号不会被外部访问；
• 外部符号也不会影响该空间内的库；
• 不同命名空间加载的库之间，符号也不会互相干扰。

不过要注意，使用时需正确指定命名空间参数（比如用LM_ID_NEWLM创建全新命名空间），同时确保库的依赖也被正确加载到对应命名空间，才能实现完整的符号隔离。

内容的提问来源于stack exchange，提问作者Self