Android 应用架构—— 那些由于年青犯的错

你应该尽也许地对你的 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 测试用例，并预先填写数据库来测试营业逻辑，一个字：不爽。

是的，Manager 有酿成巨兽的倾向，很快就变得难以维护。你也许争论说它不会变得更伟大，你可以通过更简朴的架构来更快地提供代码，但通过这种要领依然会有许多 BUG，可维护性也会遭到粉碎。

译者注：寄望 Manager this 和 Manager that 之间的标签

总结

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!