[老文章搬家] 插件化軟件設計的頭疼問題以及可能的解決思路

11年的文章，當時在作系統集成，實際上當時的思路到如今我還在琢磨，只不事後來就不作系統集成了，也一直沒機會深刻下去解決這個問題。

 

==== 正文 ====

 

一直以來作的項目中有很大一部分工做量都是有關集成設備的工做。爲了方便擴展以支持更多廠家的設備，但在這個過程當中遇到了很是頭疼的問題，在這裏我把問題描述一下，歡迎你們來探討。

問題描述：
所謂設備集成，多數狀況下能夠簡化爲SDK的集成（這個比較方便，有時候咱們寧願直接集成協議，可是廠家有廠家的考慮）。針對這種狀況，咱們的系統採用了比較典型的插件式設計思路，把功能大致一致的設備封裝爲統一接口的動態共享庫，運行時根據數據庫配置動態加載調用，同時宿主軟件自己也提供了一套接口以便下層動態庫來回調得到必要的信息。
我把問題描述到這個程度，估計不少人已經在竊笑了——是的，就是動態庫版本問題……

應該說在多數狀況下這種插件機制能夠很好的應付設備集成需求，而且能夠很容易的跨平臺實現（這很重要），可是有一種狀況，就是在一個進程中使用同一個共享庫，卻妄圖加載兩個版本。這時候狀況就變得很是混亂。看圖：（工具簡陋，箭頭我沒畫，大概意思應該都明白）

圖中的問題很明瞭：如今的嵌入式設備廠家衆多，可是跟手機行業同樣，有不少廠家生產的是「山寨機」，也就是基於嵌入式解決方案作二次開發作出來的產品（好比國內的周立功和華爲海思的方案）。針對一些複雜的功能好比解碼器，解決方案提供商會以動態庫的形式提供上位機開發包，也就是圖中的廠家底層庫那個模塊，而後設備廠家封裝SDK要調用這些動態庫。若是要在一個軟件內集成兩個廠家的設備A和B，倆廠家用的是一個品牌的硬件解決方案，可是版本不同，問題就出現了。這時候底層庫的文件名是同樣的，可是版本不同，一個進程作不到同時加載兩個版本的底層庫。若是解決方案提供商作不到徹底的版本兼容，必定會有一種設備用不了。

針對這個問題我曾經嘗試用兩個方法解決過：

方法一：

很猥瑣的方法。當時客戶的平臺爲win32，設備都是遺留設備，廠家的人根本找不到，爲了快速解決問題我直接用UltraEdit打開一種設備的SDK文件把裏面調用文件名字符串改了一個名字，而後把底層庫也改了一個名字，問題就解決了……後來我一直不太放心，怕出問題，還好一直沒出問題。後來問同事他們說也這麼幹過……囧。

方法二：

在設計新版軟件的時候，一方面行業的規範性加強了，地區性行業標準相繼出現，另外一方面新系統主打總體解決方案，不針對老項目改造，這個問題不被重視。可是我預感到基於商業的考量確定還會出現這種問題。我實驗了一種方法，就是把設備這一塊封裝到另外一個進程中，和主程序作數據交互，或者另外一個進程也實現一部分界面，直接嵌入到主程序界面中（就像是Smplayer）。我在windows上作了一個原型程序，功能沒有問題，可是最終新版軟件沒有考慮這個方案。緣由主要是一方面這個機制和主程序的機制差異很大，封裝到一塊兒很不容易，另外一方面要考慮跨平臺，在linux平臺上這樣作性能很差，也沒有辦法優化，甚至某些功能實現不了（通過研究這些確實是有結論的）。

目前這個問題我尚未太好的解決方案，只能就事論事針對項目的特色逐個解決。

 

應該說形成這個問題的緣由和技術是沒有關係的，主要仍是由於規範不到位，各廠家各行其是，盲目追求」大集成「，對可用性的關注不足。這種問題本事不足爲道，可是每每是這種「非智力問題」最困擾人。在這裏說這個問題可能不合時宜，就算是帶來一點不同的空氣吧。