文章概要

簡述
一般來說，SDK依賴庫的Api相容性問題一直是個隱藏的問題，通常沒有很好的方式解決，即使使用語義化版本管理，在眾多基礎SDK的引用依賴下，不能100%保證其中一個基礎SDK的Api發生不相容的改變後，該改變可能是對外暴露方法的簽名改變、方法名稱改變亦或是類名包名等改變，而發生這些不相容Api的變化後，不能保證所有依賴該基礎SDK的上層SDK全部對應的升級依賴版本。當然，良好的開發模式對於基礎SDK開發來講，對外暴露的Api的改變，一般不能直接改變其方法簽名以及包名類名等，而應該相應的標為@Deprecated提供向下相容

但是，作為團隊多人協作開發模式下，不能100%保證所有基礎SDK的開發都以相容方式進行Api的改變，除此之外，使用到的一些三方開源SDK，這個也不能保證它提供的Api是否是相容的，以及在進行元件化、外掛化過程中，Api相容性問題是必須要考慮的

為什麼要考慮？這裡所說的Api相容性問題，不是發生在專案編譯期，而是在執行期，因為專案中的SDK依賴庫依賴進來時，是已經編譯好的位元組碼檔案，所以SDK依賴庫內的相容性問題，只有在程式執行期才可出現，一般表現為Crash或無響應，且出現上述情況的前提條件是程式碼剛好執行到了這段，否則還是不會有任何異常

示例
一個通俗的例子，假如有A、B、C三個SDK
A和B都依賴了C，在一個版本迭代中，其中C的一個對外暴露的方法發生了簽名的變更，而A對應的更新了C的依賴，B並不知道所以沒更新

那麼在整合打包後，Gradle版本會自動解決傳遞依賴的版本衝突選擇版本，假如同深度且無直接依賴都為傳遞依賴，那麼C的相同版本型別高版本會作為衝突解決的版本，App在編譯過程肯定是沒問題的，而在執行到的某一個地方，則發生了Crash，method not found exception

即使exclude後使用直接依賴不使用傳遞依賴，結果還是一樣的

原文連結

http://zhengxiaoyong.com/2018/12/27/%E4%B8%80%E7%A7%8DApi%E5%85%BC%E5%AE%B9%E6%80%A7%E6%A3%80%E6%B5%8B%E6%96%B9%E6%A1%88/

服務推薦

• 蜻蜓代理ip
• 微信域名攔截檢測服務