首先上面的錯誤是因爲lib依賴了本地lib，然後發佈到遠程maven庫，使用時就會報上面的錯誤。
gradle3.+版本後，gradle的依賴方法發生了改變，推薦使用implementation，compile已經不被推薦，api代替compile，作用和compile相同。androidTestCompile被 androidTestImplementation替換，testCompile被 testImplementation 替換，本篇主要講解implementation和api。
簡單總結上面的意思就是推薦使用implementation，可以縮短編譯的時間。api和compile作用相同，所有使用compile的地方都可以用api替換。Implementation 的依賴沒有傳遞性，compile的依賴具有傳遞性。
使用implementation編譯的依賴，對該項目有依賴的項目將無法訪問到使用該命令編譯的依賴中的任何程序，也就是將該依賴隱藏在內部，而不對外部公開，也就是使用implementation指令的依賴不會傳遞。
implementation節省編譯時間的原理（module A implementation module B），由於只在本moduleA中有用，所以如果修改了引用的module B，其他引用module A的項目不需要重新編譯。
1 都是依賴本地module
使用api進行依賴：
如果APP本地依賴 module A ，module A本地依賴api module B ，則app可以使用B中元素。（APP 如果再依賴 module B 不會報錯）
使用implementation：
如果APP本地依賴module A ，module A 本地依賴implementation module B ，則app無法使用B中元素。（如果此時APP 又本地依賴了module B，APP中可以使用B 中元素，且不會報module B的版本衝突）
2 都是遠程依賴
使用api進行依賴：
如果APP遠程依賴 module A ，module A遠程依賴api module B ，則app可以使用B中元素。
使用implementation：
如果APP遠程依賴module A ，module A 遠程依賴 implementation module B ，則app可以使用B中元素。
3 一個遠程依賴 ，一個本地依賴
使用api進行依賴：
如果APP本地依賴 module A ，module A遠程依賴api module B ，則app可以使用B中元素（類似glide）。（APP 再添加對module B的遠程依賴，編譯不會有問題。）
使用implementation：
如果APP本地依賴 module A ，module A遠程依賴implementation module B ，則app無法使用B中元素（類似glide）。（app中添加module B的遠程引用，APP就可以使用module B中元素）
4 其他情況
如果APP遠程依賴 module A ，module A本地依賴 module B，編譯會出錯 ，如果app添加對module B的本地依賴，依然會存在問題。
如果APP遠程依賴 module A,module B ，module A 遠程依賴（api） module B，如果版本都相同，不會有問題。
app 依賴本地module A ，moduleB，而module A 又遠程依賴（api 或者implementation ）module B，此時會報錯誤，由於重複引用問題。需要把本地引用的module B 從遠程引用的module A中移除。
implementation ("com.xxx.a:moduleA:1.0.0"){
exclude group: "com.xxx.b", module:"moduleB"
}
添加的依賴版本不同時：
上面的每種情況都是建立在module 版本相同的情況下，如果版本不同會出現各種各樣的問題，當發生問題時，特別是包衝突問題，需要從module中exclude掉特定的包。
如果項目報V4 衝突，通常有兩種方案，本地包移除版本不同的v4（一般從v7中移除），第二種方案是從第三方包中exclude掉v4包。
發生上面的錯誤是由於，lib，引用了本地庫（本地module），換成引用網絡庫就好了。
全部遠程依賴模式下，無論是api還是implemention都起不到依賴隔離的作用。
如果一個module引用了jar文件，打包時不想把jar打入aar中，可以使用compileOnly，jar就不會存在aar中，使用時添加jar包就可以了。