Android 包结构最佳实践 [关闭]答案

【问题标题】：Android Package Structure Best Practice [closed]Android 包结构最佳实践 [关闭]
【发布时间】：2011-09-30 19:37:30
【问题描述】：

我对应用程序包结构的最佳做法有疑问。

我观看了 Reto Meier 的 Google I/O 2011 演示文稿"Android Protips: Advanced Topics for Expert Android Developers”并阅读了他的博文“A Deep Dive Into Location”并注意到他的应用程序包结构：

com. ... .content_providers
com。 ... .receivers
com。 ... .服务
com。 ... .UI com。 ... .UI.fragments
com。 ... .utils
com。 ... .utils.base

这是包的首选结构吗？有更好的结构吗？

【问题讨论】：

【解决方案1】：

打包类的主要目的是简化源代码的导航。这对于开源应用程序尤其重要。在我看来，一个易于导航的包结构包括以下几个包：

com.example.main - 包含您的主要驱动功能，例如您的主要活动、您的应用程序类（如果有的话）等

com.example.conf - 包含您的配置文件，例如那些包含常量（静态最终变量）的配置文件

com.example.net - 与网络相关的类，例如发出 http 请求的类

com.example.util - 实用程序类，例如服务、BroadcastReceivers 或其他后台进程

【讨论】：

这是包的目的之一，但不一定是主要目的。二是妥善隐藏关注领域。例如，您可以将所有 UI 代码放在 .ui 包中，将所有类 pkg 设为私有，而不将它们暴露给代码的任何其他层。
我看到很多项目都是以这种方式构建的（我认为即使是 Google IO 2012 也是如此）。我喜欢我的项目按主题分组（打包）：（com.apps.player 与 PlayerActivity、PlayerListView、PlayerListAdapter、com.apps.sync 与 SyncService、SyncHelper 等）我发现以这种方式更易于导航和理解代码.此外，如果我处理特定功能，我手头有所有课程。我不明白为什么有人将在其名称中指示其功能的类（例如 PlayerActivity）放入指示其类功能（例如 com.apps.activities）的包中。