本系列文章旨在概述我们在构建Android应用程序架构时可能遇到的问题。我意识到，无论实现Android应用程序架构的过程多么困难，事实证明，这些必须是每一个伟大应用程序的基础。每项技术都有其自然演变。或者更确切地说，它的社区经历了一个进化过程。新计算机语言或框架的早期采用者是业余爱好者，他们只想掌握这项技术并尽快完成一些工作。新社区通常很小，开发人员之间知识转移的潜力有限，即每个人都从自己的错误中吸取教训，因为没有可用的架构指南。前言Android的早期痛点：Google关心吗？你可以看出，有很多在不同技术方面拥有丰富经验的资深人士，但没有人有时间制定标准。好吧，不一定。如果技术背后有一家强大的公司想要赚钱，他们的布道者会告诉你这种新语言有多酷，能做很多事情，易学，可扩展，可以满足数百万用户。微软经常使用它的技术来做这样的事情。另一方面，当谷歌收购Android时，我真的以为他们只是把它当作一个副业。如果您从Android诞生之初就进入了它的世界，您一定还记得您因Google不关心而感到沮丧。那些拥有额外经验、能力和愿意帮助社区的少数人现在是Android巨星或神——例如JakeWharton。“当谷歌收购Android时，老实说，我认为他们只是把它当作其他副业来对待。”也许你会说，你不必考虑太多架构和代码组织，因为(Android)Framework为你做了。Android逼着你把界面放到Activity里，可重用的界面放到Fragment里，后台服务放到Service里，用BroadcastReceiver和其他组件通信，这样可以让你的生活更美好吧？不。首先，无论技术（平台）如何，都有一些非常好的实践和原则。比如单一职责原则、依赖倒置原则、接口编程、杀死全局状态、试图消灭所有状态等等。框架很少强制你遵循原则。恰恰相反，他们以最糟糕的方式违反了这些最佳实践和原则。想想Context，你到处都用到的上帝对象，各种单例管理器，有生命周期的Fragment（那是怎样的噩梦），经常没有正确实现的AsyncTask，它们吸你app的血。缺乏指导的新手开发人员可以轻松创建怪物而不是应用程序。把它想象成一个意大利面条怪物——一个不错的怪物，但不是一个好的应用程序。译者注：意大利面条怪物指的是一团糟的代码最后，技术（technology）和Framework隐藏了app的目的。好的，这是一个Android应用程序，但它是什么类型的Android应用程序？新闻阅读器？音乐播放器？语言学习计划？天气应用程序？也许是一个调度程序。如果所有东西都被打包到Framework提供的类中，你就分不清了（这是什么app）。正如RobertMartin，又名UncleBob所说，“你的架构应该尖叫（尖叫）应用程序做什么”，更技术地说，业务逻辑应该明确分离并独立于框架。Android架构的四大黄金法则我希望您已经清楚地知道，您不应该依赖框架来保持代码的整洁和有条理，尤其是在编写Android代码时。我们很久以前就意识到了这一点，但缺乏想出一个好的解决方案的经验。架构失败需要很长时间才能显现出来，而且您不能在项目中途更改整个架构。也不可能有时间将旧项目重构为新的、很酷的（希望成为）最好的架构。所以我们采取渐进的方法，从一个项目到另一个项目慢慢构建我们的架构，从我们的错误中吸取教训。我们相信我们的架构应该满足几个目标，这些目标是测试我们的方法的标准。一个好的架构应该做到：满足众多利益相关者的需求支持关注点分离脱离现实世界（Android、DB、互联网...）让你的组件可测试I.满足众多利益相关者在您的应用程序开发中。除了开发，还有视觉设计师、交互设计师、项目经理、数据库管理员、测试人员等等。当然，你不能按照一定的方式来组织你的代码，比如一个交互设计师可以打开项目并立即了解所有内容，甚至进行一些修改。这是一只独角兽。我的意思是，您可以按照与交互设计师交互的程序员只需要处理与交互相关的代码的方式来组织您的代码。因此，所有交互都被分离到负责交互的那些类/模块/组件/任何（组件）中，并且在处理应用程序的交互部分时，只需要处理那些组件。译者注：如果你暂时无法理解利益相关者，也没关系。看完本系列的第三部分，你就会明白II。支持关注点分离我刚才说的是关注点分离的一个例子。我们支持这种特殊的方法，因为它很好地表达了团队组织和项目阶段的一致性，而且通常您的架构还应该支持关注点分离。关注点分离或单一职责原则指出每个组件应该只有一个更改原因。三、Escapingfromtherealworld(Android,DB,Internet...)前面已经提到了逃离现实世界的规则。我们说我们想大声疾呼该应用程序的真正功能，仅此而已。我们想强调业务逻辑并隐藏框架细节。这条规则应该更严格：不仅隐藏框架细节，还隐藏与外界相关的所有细节。所有肮脏的Android东西，如传感器、通知机制、屏幕细节、数据库访问、互联网访问等。IV。让您的组件可测试您应该尽可能多地对您的应用程序进行单元测试，并且您的架构应该允许您这样做。如果你不能测试所有的东西，你至少应该覆盖你的业务逻辑。与现实世界的分离使这非常方便。如果您的业务逻辑与应用程序的其余部分明显隔离，则很容易测试。第一次迭代-GodActivitypublicfinalclassUsersActivityextendsListActivity{@OverrideprotectedvoidonCreate(BundlesavedInstanceState){super.onCreate(savedInstanceState);//...newListUsers().execute();}privatefinalclassListUsersextendsAsyncTask
