Android App Architecture : 包应该如何形成？
Android App Architecture : How should the packages be formed?
我是 android 编程新手。我经常看到程序员将包创建为活动、片段、适配器等的集合。对我来说，将 activity/screen 所需的所有 java 代码放在一个地方似乎更直观。例如：对于主屏幕，我会将 activity、片段、适配器、自定义视图等都放在一个地方。
一般做法是否有明确的原因，还是只是传统做法？
没有官方规则，也许是我没有想到的最佳做法。
我现在得到一个基于意见的答案：
我使用包名称将 类 分组到一个逻辑主题，如适配器、活动等
如果你想要另一种结构，按照你的意愿去做，只是它可能会让其他开发者感到困惑。
请记住，包名称应该是唯一的，因此您应该使用像您拥有的域这样的前缀，或者您被允许使用（以相反的顺序排列）。
另请检查此 link，其中指出了更多想法：http://www.javapractices.com/topic/TopicAction.do?Id=205
The first question in building an application is "How do I divide it up into packages?". For typical business applications, there seems to be two ways of answering this question.
Package By Feature
Package-by-feature uses packages to reflect the feature set. It tries to place all items related to a single feature (and only that feature) into a single directory/package. This results in packages with high cohesion and high modularity, and with minimal coupling between packages. Items that work closely together are placed next to each other. They aren't spread out all over the application. It's also interesting to note that, in some cases, deleting a feature can reduce to a single operation - deleting a directory. (Deletion operations might be thought of as a good test for maximum modularity: an item has maximum modularity only if it can be deleted in a single operation.)
通常活动位于主包中，片段、适配器、实用程序、模型在它们自己的包中，如片段包中的片段和 ISODateParser class 可以进入实用程序包。
您可以在包含 android 最佳实践的 Android Best Practices 指南中找到更多相关信息。
关于哪些 classes 应该放在哪些包下的指南在指南的 Java 包体系结构 标题下讨论。
希望对您有所帮助！
Is there is any definite reason the the general practice or is it just
a traditional practice ?
是的。在我当前的应用程序中，我有 50 多个自定义 UI 视图和一些活动。至少有10个单例控制器和很多数据库模型。所以 to not lost 在项目中，我使用了这样一个整洁的结构：
Activity
Adapter
Controller
Native
Model
-Database
-Rest
Ui
我建议你使用这个结构。
这与随着代码库的增长创建组件、可重用对象和代码维护有关。您的方法适用于小型应用程序，并且没有反对的规则。但是，通常根据推荐和常用方法创建 package/file 结构可以更轻松地修改代码并与其他人在同一项目中合作。考虑以下因素：
如果您有许多活动分布在许多包或文件夹中，那么负责更改 UI 的人将不得不遍历这些包。这使得很难识别可以跨 Activities 使用的 UI 模式，甚至更难使用这些模式，因为您需要在每个 package/folder 中实现它们。
这也会导致在数据对象模型、视图控制器等非 UI 组件中看到不太明显的模式的问题。例如，如果您需要一个 "user" 对象在两个不同的 Activities 你创建了两个不同的对象吗？这不是可重复使用的代码。
假设您决定重用 "user" 对象，这样您就只有 1 个 class。那么你是否在其他需要它的包中 sub-class 以遵循你的模式？那么如果一个 UI 元素需要一个新方法，你是否就在那个地方实现它？还是基础对象？
或者您创建 "user" 对象 public 并从其他 packages/folders 引用它？如果这是您的答案，那么您将开始根据代码的演变在适当的位置创建对象，而不是基于逻辑或易于维护。除其他外，这使得在您的代码库中培训新人 "where everything is" 变得非常困难。 "user" 对象将位于一个位置，然后 "user account" 对象最终出现在首先需要它的位置，但不太可能与 "user" 对象一起。
随着项目增长到数百个 classes，我认为很明显这种方法对于许多应用程序来说变得难以管理。 类 将根据 UI 要求出现在包中，而不是基于它执行的功能。维护它们变得具有挑战性。
例如，在 Lollipop 到 Marshmallow 的情况下，Apache http 已被弃用。如果这种依赖分散在整个项目中，那么您将在很多地方寻找如何处理这种变化。在一个小项目上可能没问题，但在一个更大的项目上，如果您在其他开发正在进行时尝试这样做，这可能会变得一团糟，因为您现在正在修改许多包和文件夹，而不是只修改几个位置.
但是，如果您有一个数据访问层或模型层组件将行为封装在一个或多个文件夹中，那么您周围的人就更容易看到您的更改范围。当您将更改合并到项目中时，与您一起工作的人很容易知道其他组件是否受到影响。
因此，虽然没有必要遵循这些准则（尤其是对于小型项目），但随着项目的发展和几个或许多人参与开发，您会看到变化，但一般做法是按目的分组或功能而不是按 UI / 视觉组件分组。如果您一开始就准备好其中的一些内容，那么您以后处理更改的工作量就会减少。 （但是，在项目早期开始过多的结构支持可能会使项目面临永远无法完成的风险...）
几个答案提供了指南的链接。我希望这个答案有助于解释为什么存在这些准则，我认为这是您问题的核心。
我是 android 编程新手。我经常看到程序员将包创建为活动、片段、适配器等的集合。对我来说，将 activity/screen 所需的所有 java 代码放在一个地方似乎更直观。例如：对于主屏幕，我会将 activity、片段、适配器、自定义视图等都放在一个地方。 一般做法是否有明确的原因，还是只是传统做法？
没有官方规则，也许是我没有想到的最佳做法。
我现在得到一个基于意见的答案：
我使用包名称将 类 分组到一个逻辑主题，如适配器、活动等
如果你想要另一种结构，按照你的意愿去做，只是它可能会让其他开发者感到困惑。
请记住，包名称应该是唯一的，因此您应该使用像您拥有的域这样的前缀，或者您被允许使用（以相反的顺序排列）。
另请检查此 link，其中指出了更多想法：http://www.javapractices.com/topic/TopicAction.do?Id=205
The first question in building an application is "How do I divide it up into packages?". For typical business applications, there seems to be two ways of answering this question.
Package By Feature
Package-by-feature uses packages to reflect the feature set. It tries to place all items related to a single feature (and only that feature) into a single directory/package. This results in packages with high cohesion and high modularity, and with minimal coupling between packages. Items that work closely together are placed next to each other. They aren't spread out all over the application. It's also interesting to note that, in some cases, deleting a feature can reduce to a single operation - deleting a directory. (Deletion operations might be thought of as a good test for maximum modularity: an item has maximum modularity only if it can be deleted in a single operation.)
通常活动位于主包中，片段、适配器、实用程序、模型在它们自己的包中，如片段包中的片段和 ISODateParser class 可以进入实用程序包。
您可以在包含 android 最佳实践的 Android Best Practices 指南中找到更多相关信息。
关于哪些 classes 应该放在哪些包下的指南在指南的 Java 包体系结构 标题下讨论。
希望对您有所帮助！
Is there is any definite reason the the general practice or is it just a traditional practice ?
是的。在我当前的应用程序中，我有 50 多个自定义 UI 视图和一些活动。至少有10个单例控制器和很多数据库模型。所以 to not lost 在项目中，我使用了这样一个整洁的结构：
Activity
Adapter
Controller
Native
Model
-Database
-Rest
Ui
我建议你使用这个结构。
这与随着代码库的增长创建组件、可重用对象和代码维护有关。您的方法适用于小型应用程序，并且没有反对的规则。但是，通常根据推荐和常用方法创建 package/file 结构可以更轻松地修改代码并与其他人在同一项目中合作。考虑以下因素：
如果您有许多活动分布在许多包或文件夹中，那么负责更改 UI 的人将不得不遍历这些包。这使得很难识别可以跨 Activities 使用的 UI 模式，甚至更难使用这些模式，因为您需要在每个 package/folder 中实现它们。
这也会导致在数据对象模型、视图控制器等非 UI 组件中看到不太明显的模式的问题。例如，如果您需要一个 "user" 对象在两个不同的 Activities 你创建了两个不同的对象吗？这不是可重复使用的代码。
假设您决定重用 "user" 对象，这样您就只有 1 个 class。那么你是否在其他需要它的包中 sub-class 以遵循你的模式？那么如果一个 UI 元素需要一个新方法，你是否就在那个地方实现它？还是基础对象？
或者您创建 "user" 对象 public 并从其他 packages/folders 引用它？如果这是您的答案，那么您将开始根据代码的演变在适当的位置创建对象，而不是基于逻辑或易于维护。除其他外，这使得在您的代码库中培训新人 "where everything is" 变得非常困难。 "user" 对象将位于一个位置，然后 "user account" 对象最终出现在首先需要它的位置，但不太可能与 "user" 对象一起。
随着项目增长到数百个 classes，我认为很明显这种方法对于许多应用程序来说变得难以管理。 类 将根据 UI 要求出现在包中，而不是基于它执行的功能。维护它们变得具有挑战性。
例如，在 Lollipop 到 Marshmallow 的情况下，Apache http 已被弃用。如果这种依赖分散在整个项目中，那么您将在很多地方寻找如何处理这种变化。在一个小项目上可能没问题，但在一个更大的项目上，如果您在其他开发正在进行时尝试这样做，这可能会变得一团糟，因为您现在正在修改许多包和文件夹，而不是只修改几个位置.
但是，如果您有一个数据访问层或模型层组件将行为封装在一个或多个文件夹中，那么您周围的人就更容易看到您的更改范围。当您将更改合并到项目中时，与您一起工作的人很容易知道其他组件是否受到影响。
因此，虽然没有必要遵循这些准则（尤其是对于小型项目），但随着项目的发展和几个或许多人参与开发，您会看到变化，但一般做法是按目的分组或功能而不是按 UI / 视觉组件分组。如果您一开始就准备好其中的一些内容，那么您以后处理更改的工作量就会减少。 （但是，在项目早期开始过多的结构支持可能会使项目面临永远无法完成的风险...）
几个答案提供了指南的链接。我希望这个答案有助于解释为什么存在这些准则，我认为这是您问题的核心。