記事のこのシリーズは、Androidアプリケーションのアーキテクチャを構築するときに我々が発生する可能性のある問題の概要を説明することを意図しています。私は結果が、これらはそれぞれの基本的な優れたアプリケーションのために完了しなければならないことを示しているいかに難しいかを実現Androidアプリのアーキテクチャのプロセスに関係なく、ことに気づきました。
それぞれの技術は、その持っている自然な進化を。または、より正確には、そのコミュニティは、進化の過程を経ています。新しいコンピュータ言語や愛好家ですアーリーアダプターのフレームワークは、彼らは単に技術を習得したい、といくつかの作業は、可能な限り迅速に行われます。何のアーキテクチャガイドが利用できないがあるので一般的に、小規模、潜在的な開発者の間の限られた知識移転の新しいコミュニティは、それは、誰もが自分の過ちから学んでいると言うことです。
初期のAndroidの痛みのポイント：Googleが気にするかどうか？
あなたは、経験豊富な男性の多くは、様々な技術で多くの経験をそこに持っていると言うことができ、誰も水準を引き上げるための時間を持っていません。ああ、必ずしも。強い会社の背後にある技術は、お金を稼ぐことが予想される場合は、その説教者は、あなたがスケーラブルな習得が容易多くのことを、どのようにクールこの新しい言語を行うことができ、そして数百万人のユーザーを満たすことを教えてくれます。
マイクロソフトでは、多くの場合、それが乾燥技術だようなものを使用します。GoogleがAndroidのを買収したとき一方、私は本当に彼らがちょうど些細プロジェクトとして扱いと思いました。あなたがAndroidの誕生からアンドロイドの世界を入力すると、Googleがあなたの欲求不満を気にしないことを覚えておく必要があります。このようジェイクウォートンなど - コミュニティを支援するための追加的な経験、能力と意欲を持っている少数の人々は、今のAndroidのスーパースターや大神です。
「GoogleはAndroidのを買ったとき、私は正直に、彼らは単にいくつかの他のサイドプロジェクトとして、それを扱うと思います。」
可能你会说，你不必考虑太多架构和组织代码的事情，因为（Android）Framework 帮你做了。Android 强迫你把界面放到 Activity 中，可重用的界面放到 Fragment 中， 后台服务放到 Service 中，并且用 Broadcast Receiver 和其它组件通信，这样可以使你的生活变得更美好，是这样吗？不是的。
首先，有一些很好的实践和原则确实很好，与技术（平台）无关。例如，单一职责原则，依赖倒置原则，面向接口编程，杀死全局状态，尝试消灭所有状态，等等。
Framework 很少强迫你遵循原则。恰恰相反，它们以最坏的方式侵犯这些最佳实践和原则。想想 Context 这个你到处使用的上帝对象（God object），各种单例管理者（singleton managers），拥有生命周期的 Fragment（那是怎样的噩梦呢），常常不能正确实现的 AsyncTask，它们吸着你 app 的血。
一个缺乏指导的刚入行的开发者很容易造出一个怪物而不是一个 app。把它想象成一个意大利面条般的怪物吧 —— 这是一个不错的怪物，但不是一个好的 app。
注：意大利面条般的怪物寓指一团乱麻的代码
最后，技术（technology）和 Framework 隐藏了 app 的用途。好的，这是一个 Android app，但是一个什么样的 Android app 呢？新闻阅读器？音乐播放器？ 语言学习程式？天气应用？也许是一个计划表。如果所有的东西都打包到由 Framework 提供的类，你就说不出（这是什么 app）。
正如 Robert Martin，也就是 Uncle Bob 说，“你的架构应该尖声喊出（scream）app 是做什么”，更技术一点说，业务逻辑应该清晰地分离，独立于 Framework。
Android 架构的四条黄金法则
我希望已经说清楚了，你不应当依赖 Framework 来使你的代码整洁有序，尤其是在编写 Android 代码的时候。我们很早以前就意识到这点，可是缺乏拿出牛逼解决方案的经验。架构失败要花很多时间才能表现出来，又不可以在项目中途改变整个架构。也不可能有时间将旧项目重构成新的、酷的、（想成为）最佳的架构。因此，我们采取渐进的方法，慢慢地从一个项目到另一个项目搭建我们的架构，从我们的错误中学习。我们认为我们的架构应该满足几个目标，它们是检验我们的方法的标准。好的架构应该做到:
满足众多利益相关者的需求
支持关注点分离
逃离现实世界（Android、DB、Internet...）
使你的组件可测试
I.满足众多利益相关者
利益相关者（在这篇文章中）是任何对你的 app 开发感兴趣的人。除了开发，还有视觉设计师，交互设计师，项目经理，数据库管理员，测试等等。
当然，你不可能以某种方式组织你的代码，例如，交互设计师可以打开项目并立即了解所有内容，甚至可以进行一些修改。It's a unicorn.
我的意思是，你可以以这样一种方式组织你的代码，那个和交互设计师对接的程序员只需要打理和交互相关的代码。因此，所有交互被分离到那些负责交互的 classes / modules / components / whatever （组件）中，当处理 app 的交互部分时，只需要打理那些组件。
注：如果暂时不能理解利益相关者，没关系的，看完本系列第三部分你就明白了
II.支持关注点分离
我刚刚所说的就是一个关注点分离的例子。我们支持这种特定的方法，因为它能很好地表达团队组织和项目阶段的配合，一般来说，你的架构也应该支持关注点分离。关注点分离或者单一职责原则是指，每一个组件应该只有一个变化的原因。
III.逃离真实世界（Android、DB、Internet...）
逃离真实世界这条规则，先前已经提及。我们曾说我们想要尖声喊出 app 真正是做什么的，就是那样。我们想要强调业务逻辑并且隐藏 Framework 的细节。这条规则应该更严格：不仅要隐藏 Framework 的细节，而且要隐藏所有与外部世界相关的细节。
所有的肮脏的 Android 的东西，如传感器、通知机制、屏幕细节、数据库访问、互联网访问等。
IV.使你的组件可测试
你应该尽可能地对你的 app 进行单元测试，并且你的架构应该允许你这样做。如果你不能测试所有东西，你至少应该覆盖你的业务逻辑。与真实世界分离可以很方便地做到这点。如果你的业务逻辑清晰地和 app 其余部分隔离，是很容易测试的。
第一次迭代 —— 上帝 Activity
public final class UsersActivity extends ListActivity { @Override
protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); //...
new ListUsers().execute();
} private final class ListUsers extends AsyncTask<Void, Void, Void> { @Override
protected Void doInBackground(Void... voids) { // final SQLiteOpenHelper sqLiteOpenHelper = ...
// JsonObjectRequest jsObjRequest = new JsonObjectRequest
// (Request.Method.GET, url, null, new Response.Listener<JSONObject>() {
// MySingleton.getInstance(this).addToRequestQueue(jsObjRequest);
// showData(user);
return null;
}
}
}
你可能在 “上古时代” 看到过这样的代码。如果没有，说明你很年轻。但是这一段代码哪里有问题呢？答案是哪里都有问题。
我们有一个 Activity 操作数据库，访问网络，解析数据，切换线程以及渲染数据。所有的利益相关者都在看这一个类，没有关注点是分离的，它是不可测试的，业务逻辑和 Android 的东西混杂在一起。
注：留意上图左边红色的标签。每个标签分别对应一条黄金法则，红色表示不满足。SRP 是指单一职责原则，即分离关注点。
第二次迭代 —— MVP
第一种方法显然是不能工作的。我们尝试过的第一件事情是 MVP，或者说 model-view-presenter。每个人都熟悉 MVP。它是最受欢迎的架构模式之一。看起来像这样：
这里，我们分离了实际上是 Android Fragment 的 View，我们拥有代表我们业务的（领域）模型，最后我们有协调一切的 Presenter。这肯定是更好的。关注点有了一些分离，利益相关者不再那么困惑，你也可以写一些单元测试了。尽管如此，由于 Presenter 直接操作数据库和所有一切，我们仍然和真实世界混杂在一起。Presenter 成了上帝对象。它处理模型，将数据发送到视图，它拥有业务逻辑（业务逻辑是那些齿轮 :)），它访问数据库和网络，获取传感器数据，等等。所以，是好了些，但可以更好。
注：×××的标签表示好了些
第三次迭代 —— MVP + managers
当政府不知道做什么的时候它会做什么？它成立一个代理机构。当开发不知道做什么的时候他们会做什么？他们引入一些 Manager。你不一定把它命名为 “*Manager” 。 这些类有很多名字：uitls、helpers、fooBarBuzz-ator、等等。因此我们引入 Manager。
正直に言うと、これは少しでもばかげています。ビジネスロジックは、マネージャに含まれています。関係者が見てどこを知って、ある程度まで、フォーカスが別であるが、より良い行うことができます、あなたはより多くのテストを書くことができますが、あなたはまだダイレクトタッチアンドロイド、アンドロイドあなたはテストケースと事前にデータベースを作成するために持つことができますので、テストビジネスロジック、一言：地獄。はい、マネージャーは怪物になる傾向があり、すぐにそれを維持することが困難になります。あなたはそれがより複雑になっていません、あなたは高速なコードのためのシンプルなアーキテクチャを提供できると主張するかもしれませんが、バグの多くを持って、この方法では、まだ、保守性が破壊されます。
注：このとマネージャーそのManagerの間でラベルに注意を払います
概要
このシリーズの最初の部分では、実際に利用可能なAndroidのアーキテクチャを構築するの挑戦を経験しました。良いAndroidのアーキテクチャはビジネスロジックを強調し、懸念の分離をサポートするために、多くの利害関係者のニーズを満たす必要があり、フレームワークは、細部を隠し、すべてのコンポーネントをテストすることができます。このシリーズの第二部では、私たちは私たちのために便利な機能を管理する方法を紹介します。これに先立ち、あなたは適切なワークフローのAndroidを作成する方法についての提案がありますか？それとも、何か問題が発生しましたか？
あなたはこれを読むことができると思います親指が私の懸念、将来は知識やAndroidの決意を共有することになり、あなたのサポートが私の最大の動機です！！
