项目应用需要匹配多个外部厂家，如何优雅实现

[FranzKafka95]

继上次头文件向下兼容后（最终我们采用了宏控的方式来解决这个问题），我们产品经理又给我们带来了难题，在同一个项目中，两个厂家都需要来适配我们定义的借口并提供 lib.so ，在编译时无法区分具体的厂家，只有在程序运行起来时根据配置去解析。
这样意味着我们的软件在打包时需要打包两个 libx.so ，且不能再放到 system/lib64 目录下了（程序运行环境是安卓）

目前为止，我们想到的办法是，将代码里直接调用 libx.so 接口的地方改掉，改为调用函数指针，而这个指针地址通过 dlopen 后拿到的句柄去获取，对于不同的厂家 dlopen 不同路径下的 libx.so 即可。

除了这种方式，我们也想过在程序运行真正前，先执行代码逻辑将 libx. so 拷贝到 system/lib64 目录下，然后调用的地方仍旧保持不变。但实践下来并不成功，原因是 system/lib64 不支持外部拷入。

想问一下大家，这种情况有没有好的解决办法？

[FranzKafka95]

另外备注一下，本身我们的进程属于 root 进程，而且 /system/lib64 对于 root 是可读写的，但就是不清楚为什么 cp 执行不成功，脑壳痛

[cppc]

一个 so ，两份头文件分别给两家厂商。你这个场景我看着像提供两份特供 SDK ，不是别人来适配你们。。

[jorneyr]

so 动态加载

[FranzKafka95]

@cppc 一份头文件，给两个甚至多个厂家，厂家来实现提供 so 库，我们集成厂家的 so 库

[FranzKafka95]

@jorneyr 请问如果实现这个动态加载，除了 dlopen 的这种形式坏还有其他办法吗

[cppc]

@FranzKafka95 搞半天你才是服务使用方，你自己开发一个代理层，它在根据需求加载同厂家的 so ，把 so 的句柄，和函数指针保存起来，你自己应用不直接调用厂商的 so ，而是通过这个代理来调用。

[jorneyr]

@FranzKafka95
好像没了，就是 so 的隐式动态加载。

[FranzKafka95]

@cppc 貌似只有这样改了，可是我还是不死心，为什么不能 cp 到 system/lib64 直接以系统加载的方式直接掉接口

[cppc]

jna 跨平台动态库加载实现是这样的：它加载动态库时，先判断当前环境，然后把 jar 包里面的动态库保存到临时目录，最后再通过绝对路径加载动态库。
都是 java ，可抄

[FranzKafka95]

@cppc 我们是 native C++的应用，你说的这个我知道，最终都是通过 dlopen 动态加载，可现在我就是不想通过 dlopen 加载

[orannge]

要是 /system/lib64 改了，系统还怎么做 OTA 升级？这样明显不行