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 

我建议你使用这种结构。