Android應用程序體系結構：包應該如何形成？

Question

我是android編程新手。我經常看到程序員創建包作爲活動，片段，適配器等的集合。對我來說，將活動/屏幕所需的所有Java代碼放在一個地方似乎更直觀。例如：對於主屏幕，我會將活動，片段，適配器，自定義視圖等全部保存在一個地方。 整體實踐有沒有明確的理由，還是僅僅是傳統習慣？

Answer 1

這與創建組件，可重用對象和代碼維護在代碼庫中隨着它的增長有關。您的方法適用於小型應用程序，並且沒有任何反對它的規則。然而，通常根據建議的和通用的方法創建包/文件結構，可以更容易地修改代碼並在同一個項目中與其他人一起工作。考慮以下內容：

如果有許多活動分佈在許多包或文件夾中，那麼任何負責更改UI的任務都必須遍歷這些包。這使得很難識別可以跨越Activities使用的UI模式，甚至更難使用這些模式，因爲您需要在每個包/文件夾中實現它們。

這也會在非UI組件中看到不太明顯的模式，例如數據對象模型，視圖控制器等等。例如，如果您需要兩個不同的Activities中的「用戶」對象，是否創建2個不同的對象？這不是可重用的代碼。

因此，假設您決定重用「用戶」對象，以便您只有1個類。那麼你是否在需要它的其他軟件包中進行分類，以便遵循你的模式？那麼如果一個UI元素需要一個新的方法，那麼你在那個地方實現它嗎？還是基礎對象？

或者你是否公開「user」對象並從其他包/文件夾中引用它？如果這是您的答案，那麼您將開始基於代碼的演變在地點創建對象，而不是基於邏輯或易於維護。除此之外，這使得在代碼庫中「培訓所有人」時培訓新人非常困難。 「用戶」對象將坐落在一個地方，然後「用戶帳戶」對象結束到最初需要的地方，但不太可能與「用戶」對象在一起。

隨着項目發展到數百個課程，我認爲很明顯這種方法對於許多應用程序來說難以管理。類將根據UI要求顯示在包中，而不是基於它執行的功能。保持它們變得具有挑戰性。

例如，在棒棒糖到棉花糖的情況下，Apache http已被棄用。如果您在整個項目中分散了這種依賴關係，那麼您將在很多地方查看如何處理此更改。在一個可能很好的小型項目上，但如果在其他開發過程中嘗試這樣做的話，對於一個大型項目來說，這可能會變得非常混亂，因爲您現在正在修改許多包和文件夾，而不是僅在幾個位置。

但是，如果您有一個將行爲封裝在一個或多個文件夾中的數據訪問層或模型層組件，那麼您的更改範圍更容易與周圍的人看到。當您將更改合併到項目中時，與您共同工作的人員很容易知道其他組件是否受到影響。

因此，雖然沒有必要遵循這些指導方針（特別是對於小型項目），但隨着項目的增加以及多個或多個人參與開發，您將看到各種變化，但一般慣例是按目的進行組合或功能而不是按UI /可視組件分組。如果你從一開始就做好這些準備工作，那麼稍後你將不再需要處理這些變化。 （但是，如果項目早期過多的結構支持，可能會使項目面臨永不完整的風險......）

幾個答案提供指南的鏈接。我希望這個答案有助於解釋爲什麼這些準則存在，我相信這是你問題的核心。

Answer 2

沒有官方規定，也許最好的做法，我沒有記住。

我這樣我們就得到現在的意見基於答案：
我用的是包名進行分組類像適配器，活動邏輯題目，等

如果想要另一個結構做像你想，只是它可能會混淆其他開發者。

請記住，軟件包名稱應該是唯一的，因此您應該使用像您擁有的域名或允許您使用的前綴（按原因的顛倒順序）。

檢查也是這個鏈接，有一些更多的想法指出：http://www.javapractices.com/topic/TopicAction.do?Id=205

在構建應用程序的第一個問題是「我如何把它分成包？」。對於典型的商業應用，似乎有兩種方法來回答這個問題。
程序封套功能
按功能分類功能使用封裝形式來反應該功能的設置。它會嘗試將與單個功能相關的所有項目（僅限該功能）放置到單個目錄/軟件包中。這導致具有高凝聚力和高模塊性的包裝，並且包裝之間的耦合最小化。緊密合作的項目放在一起。它們並不遍佈整個應用程序。同樣值得注意的是，在某些情況下，刪除一個功能可以減少一個操作 - 刪除一個目錄。 （刪除操作可能會被認爲是一個很好的測試最大的模塊化：一個項目只有當它能夠在一個操作中刪除最高的模塊化）

Answer 3

通常的活動都在主包和片段的地方，適配器，utils，模型在它們自己的包中，比如碎片包中的碎片和ISODateParser類可以進入utils包。

您可以在Android Best Practices指南中找到關於它的更多信息，其中包含適用於Android的最佳做法。

有關哪些類應放置在指南中標題下下討論哪些包的準則。

希望它有助於！

Answer 4

是否有任何確定的理由或一般的做法是否只是 一個傳統的做法？

是。在我目前的應用程序中，我有超過50個自定義UI視圖和一些活動。至少10個單機控制器和大量的數據庫模型。所以to not lost項目，我使用的是整齊的結構是這樣的：

Activity 
Adapter 
Controller 
Native 
Model 
-Database 
-Rest 
Ui 

我建議你使用這種結構。