前言

implementation，api...，每次寫的時候，都不好記住差別，都要重新查資料，實在麻煩，這也說明android studio有關這塊的命名肯定不當，那麼不容易記。

在此，需要搞清楚google為何這麼搞，其動機是什麼為了解決什麼問題？

背景原因

其實追究其後面原因，是因為android studio要優化編譯效率，解決依賴庫的後期開發變更引起的一系列編譯的效率問題。

例如有這麼一個依賴：lib1依賴lib2,lib2依賴lib3，lib3依賴lib4 ....。

如果lib4某天內部進行了修改，那麼lib3要不要重新編譯？lib2，lib1呢？如果理論上不需要重新編譯的，卻因此而重新編譯了，那麼就是浪費時間，而android studio不夠智慧，無法檢測到lib2、lib1要不要重新編譯。這時候只能靠程式設計師來手工指定一些標誌，然後android studio根據這些標誌內部進行分析而決定哪些庫需要重新編譯。

原理

某個庫，後期因為程式設計師改動而導致變化，分為兩種：

1.對外介面不變；

2.對外介面變化了；

對於第1中情況，使用了這個庫的其它庫，都不需要重新編譯，

對於第2中情況，所有引用了它的庫都需要重新編譯。

在實際使用中，引用的關係可能會更加複雜，例如下面的例子：

依賴關係：lib1->lib2->lib3->lib4。。。

這種依賴關係中，如果lib1不但使用lib2的介面，還通過lib2使用lib2依賴的lib3的介面，

那麼lib3介面後期變化後lib1需要重新編譯，

而如果lib1只是使用lib2的介面而不用lib3介面，則不需要重新編譯。

android studio提出了庫依賴關係宣告，就是為了解決這種情況。

通過依賴關係宣告，程式設計師可以表明lib2對lib3的引用僅僅是為了自己內部的實現而不對lib1提供介面，如此，編譯系統就能在lib3後期修改的時候不再編譯lib1。

依賴關係說明

發展到現在，android studio針對引用庫的方式有好幾種具體，參考下面的介紹。

• implementation

對庫的引用，僅僅供自己內部實現，庫的介面不對外公開。

例如lib2使用implementation的方式依賴引用lib3，如果lib1引用了lib2，那麼lib1是無法使用lib2裡面的lib3的介面，因為lib2使用了implementation。

• api

依賴的庫不僅被自己用，其api介面還對外公開。所以，在編譯時候，會一起打包。

例如lib2使用api的方式依賴lib3，lib1引用了lib2，則lib1就可以呼叫lib2中的lib3的介面。在編譯打包lib2的時候，也會把lib3同時打包到lib2中。

• compileOnly

依賴的庫僅僅用來編譯，打包時候不參與。

• runtimeOnly

打包的時候會包括進去，不參與編譯。

• testImplementation

測試才有效。

• debugImplementation

debug模式才用的implementation方式

• releaseImplementation

release模式才用的implementation方式

總結

implementation，意思就是你用這個庫僅僅是為了自己內部的功能實現（implementation）！

api，意思就是，你除了自己用這個庫，也把這個庫對外公開，別人通過你，也能呼叫這個庫的api介面！

最後：平時就用implementation，如果你要依賴的庫裡面有介面也想對外公開，那就用api。