[老文章搬家] 插件化软件设计的头疼问题以及可能的解决思路

11年的文章，当时在作系统集成，实际上当时的思路到如今我还在琢磨，只不事后来就不作系统集成了，也一直没机会深刻下去解决这个问题。

 

==== 正文 ====

 

一直以来作的项目中有很大一部分工做量都是有关集成设备的工做。为了方便扩展以支持更多厂家的设备，但在这个过程当中遇到了很是头疼的问题，在这里我把问题描述一下，欢迎你们来探讨。

问题描述：
所谓设备集成，多数状况下能够简化为SDK的集成（这个比较方便，有时候咱们宁愿直接集成协议，可是厂家有厂家的考虑）。针对这种状况，咱们的系统采用了比较典型的插件式设计思路，把功能大致一致的设备封装为统一接口的动态共享库，运行时根据数据库配置动态加载调用，同时宿主软件自己也提供了一套接口以便下层动态库来回调得到必要的信息。
我把问题描述到这个程度，估计不少人已经在窃笑了——是的，就是动态库版本问题……

应该说在多数状况下这种插件机制能够很好的应付设备集成需求，而且能够很容易的跨平台实现（这很重要），可是有一种状况，就是在一个进程中使用同一个共享库，却妄图加载两个版本。这时候状况就变得很是混乱。看图：（工具简陋，箭头我没画，大概意思应该都明白）

图中的问题很明了：如今的嵌入式设备厂家众多，可是跟手机行业同样，有不少厂家生产的是“山寨机”，也就是基于嵌入式解决方案作二次开发作出来的产品（好比国内的周立功和华为海思的方案）。针对一些复杂的功能好比解码器，解决方案提供商会以动态库的形式提供上位机开发包，也就是图中的厂家底层库那个模块，而后设备厂家封装SDK要调用这些动态库。若是要在一个软件内集成两个厂家的设备A和B，俩厂家用的是一个品牌的硬件解决方案，可是版本不同，问题就出现了。这时候底层库的文件名是同样的，可是版本不同，一个进程作不到同时加载两个版本的底层库。若是解决方案提供商作不到彻底的版本兼容，必定会有一种设备用不了。

针对这个问题我曾经尝试用两个方法解决过：

方法一：

很猥琐的方法。当时客户的平台为win32，设备都是遗留设备，厂家的人根本找不到，为了快速解决问题我直接用UltraEdit打开一种设备的SDK文件把里面调用文件名字符串改了一个名字，而后把底层库也改了一个名字，问题就解决了……后来我一直不太放心，怕出问题，还好一直没出问题。后来问同事他们说也这么干过……囧。

方法二：

在设计新版软件的时候，一方面行业的规范性加强了，地区性行业标准相继出现，另外一方面新系统主打总体解决方案，不针对老项目改造，这个问题不被重视。可是我预感到基于商业的考量确定还会出现这种问题。我实验了一种方法，就是把设备这一块封装到另外一个进程中，和主程序作数据交互，或者另外一个进程也实现一部分界面，直接嵌入到主程序界面中（就像是Smplayer）。我在windows上作了一个原型程序，功能没有问题，可是最终新版软件没有考虑这个方案。缘由主要是一方面这个机制和主程序的机制差异很大，封装到一块儿很不容易，另外一方面要考虑跨平台，在linux平台上这样作性能很差，也没有办法优化，甚至某些功能实现不了（通过研究这些确实是有结论的）。

目前这个问题我尚未太好的解决方案，只能就事论事针对项目的特色逐个解决。

 

应该说形成这个问题的缘由和技术是没有关系的，主要仍是由于规范不到位，各厂家各行其是，盲目追求”大集成“，对可用性的关注不足。这种问题本事不足为道，可是每每是这种“非智力问题”最困扰人。在这里说这个问题可能不合时宜，就算是带来一点不同的空气吧。