Android 应用架构—— 那些由于年青犯的错
|
副问题[/!--empirenews.page--]
本系列文章旨在概述我们搭建 Android 应用措施架构时也许会遇到的题目。我意识到，无论实现 Android app 架构的进程何等坚苦，功效证明这些必然是完成每一个卓越的应用的基本。 每种技能都有其天然的进化。可能更确切地说，它的社区经验了进化的进程。一个新的计较机说话或框架的早期回收者是喜爱者，他们只是但愿把握技能，并尽快完成一些事变。凡是，新社区局限小，在开拓职员之间的常识转达潜力有限，也就是说，每小我私人都从本身的错误中进修，由于没有架构指南可用。
媒介 早期 Android 们的痛点：谷歌是否体谅? 你可以说，有许多资深的家伙在差异的技能上有许多的履历，但谁也没偶然刻提出尺度。嗯，不必然。假如技能背后有一个强盛的公司指望赚钱，他们的布道师会汇报你这个新说话何等酷，可以做许多工作，轻易进修，可扩展，而且可以满意数以百万计的用户。 微软就常常用它的技醒目这样的工作。另一方面，当谷歌收购了 Android， 我真的觉得他们只是把它看成一个无关紧急的项目。假如你从 Android 降生之时就进入 Android 的天下，你必然记得 Google 基础不在乎你的那种沮丧感。那些有特另外履历，手段和辅佐社区的意愿的少数几小我私人此刻是 Android 的超等明星或大神 —— 譬如 Jake Wharton。 “When Google bought Android, I honestly think they treated it just as some other side project.”
也许你会说，你不必思量太多架构和组织代码的工作，由于(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 代码的时辰。我们很早早年就意识到这点，然则缺乏拿出牛逼办理方案的履历。架构失败要花许多时刻才气示意出来，又不行以在项目半途改变整个架构。也不行能偶然刻将旧项目重组成新的、酷的、(想成为)最佳的架构。因此，我们采纳渐进的要领，逐步地从一个项目到另一个项目搭建我们的架构，从我们的错误中进修。我们以为我们的架构应该满意几个方针，它们是检讨我们的要领的尺度。好的架构应该做到:
I.满意浩瀚好处相干者 好处相干者(在这篇文章中)是任何对你的 app 开拓感乐趣的人。除了开拓，尚有视觉计划师，交互计划师，项目司理，数据库打点员，测试等等。 虽然，你不行能以某种方法组织你的代码，譬喻，交互计划师可以打开项目并当即相识全部内容，乃至可以举办一些修改。It's a unicorn.
我的意思是，你可以以这样一种方法组织你的代码，谁人和交互计划师对接的措施员只必要打理和交相互关的代码。因此，全部交互被疏散到那些认真交互的 classes / modules / components / whatever (组件)中，当处理赏罚 app 的交互部门时，只必要打理那些组件。 译者注：假如暂且不能领略好处相干者，不要紧的，看完本系列第三部门你就大白了 II.支持存眷点疏散 我方才所说的就是一个存眷点疏散的例子。我们支持这种特定的要领，由于它能很好地表达团队组织和项目阶段的共同，一样平常来说，你的架构也应该支持存眷点疏散。存眷点疏散可能单一职责原则是指，每一个组件应该只有一个变革的缘故起因。 III.逃离真实天下(Android、DB、Internet...) 逃离真实天下这条法则，先前已经说起。我们曾说我们想要尖声喊出 app 真正是做什么的，就是那样。我们想要夸大营业逻辑而且潜匿 Framework 的细节。这条法则应该更严酷：不只要潜匿 Framework 的细节，并且要潜匿全部与外部天下相干的细节。
全部的肮脏的 Android 的对象，如传感器、关照机制、屏幕细节、数据库会见、互联网会见等。 IV.使你的组件可测试 （编辑：湖南网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
