Android开发架构思考及经验总结（上）

前言

架构设计，到底是什么呢？基于这段时间的学习和自己的一些思考，我认为架构是基于产品和技术所达成的一种共识。我不是专业的架构师，也不是经验老道的开发者。本文目的有三，一是整理这段时间的架构学习和思考以及总结这一年的开发经验教训，二是希望能够与各位朋友探讨移动端App的架构设计，三是希望我们每一个应用开发者能够拥有架构的意识。个人的水平有限，诸多不对的地方，恳请批评指正。

提示：文中链接需要点击文章末尾处阅读原文才能点击。

零、

知识大纲

一、

萌芽

作为一只编程经验并不怎么丰富的程序猿来讲，我一直觉得架构师是一个比较神秘的职业，架构设计就更加的高大上了。经过今年的几个项目，之前曾发文叙述我的从MVC到MVP项目重构实战经验，也曾说过我准备对目前手底下的项目进行重构。但是，前段时间，我改变了我的想法。开发模式的重构，仅仅只是换了一个套路，也许在重构的过程中对业务的逻辑进行了一次梳理，也是在基于前人的代码设计上进行了一些优化。但是，这远远还不够，这不是我理想中的开发场景。在项目开发的过程中，也发现存在许多的问题，但是都是一些零散的问题，我很多时候希望能够改变现状，更加优雅地编程，然后实际的情况却是陷入了迭代功能开发和bug修复的死循环。现在回过头来想想，我理想中的开发应该是一种由规划和设计指导的开发，那么架构设计就显的尤为重要了。

二、

初识架构

1、阅读《架构之美》之论架构

仅看完了《架构之美》的第一部分：论架构，对架构有了一个大概的认识。下图是这部分的知识点概要：

书中很受启发的概念：

• 架构是一种折中，一种取舍。架构师要学会的就是平衡，质量与成本之间的平衡；
• 架构师首先关注的不是系统的功能，而是满足需求，满足品质；
• 架构设计要做的是让关注点分离，并且对每个关注点进行设计一定的结构，该结构都有利于解答这一个关注点所定义的问题；
• 好的架构应该是可以指导产品、开发、测试人员都对这一设计感到非常的舒适可靠，该设计覆盖了所有该软件系统相关利益的人员以及其中的关注点；
• 只设计你知道需要的东西，多余的设计是一种浪费；
• 架构几乎影响了该系统相关的所有的人和事，决定了该软件系统是否健康。

2、分析行业内各个APP的架构演进

这里仅仅通过Google搜索各个app在架构演进方面的一些文章，从中分析他们为什么要演进？怎么演进?带来了哪些好处？ 简单的整理如下：

（1）架构为什么需要演进

• 项目需求扩张，旧的架构不适应新的需求
• 开发团队人员增加，协作要求变高
• 新技术引入
• 更高的软件质量要求

（2）他们是怎么演进的

• 饿了么移动APP的架构演进 2016-01-20
  • 共有组件
  • 业务组件
  • 模块解耦
  • Excalibur映射系统，注册机制
  • 引入Hybrid框架
  • React-Native & Hot Patch
• 携程移动App架构优化之旅 2016-04-07
  • 工程结构调整、业务之前解耦，产品间相互独立，页面跳转使用事件总线或者URL总线方式
  • 统一基础功能业务组件，SDK化
  • 性能数据采集、监控
  • Native的插件化和HotFix
• 糯米移动组件架构演进之路 2016-05-24
  • 组件化
  • 统一服务入口
  • Hybrid框架优化
• 苏宁11.11：苏宁易购移动端的架构优化实践 2016-11-11
  • 分层解耦，解决纵向解耦
  • 中介型引用结构（protocol和url方式），横向解耦
  • H5容器优化
  • 网络链路优化
  • 移动App性能监控系统

（3）带来的好处

• 进行了模块化的解耦，产品相对独立，应对需求变化、技术更新更加灵活，团队协作更加方便，并减少了许多是无用功，也给团队留下了一些技术积累；
• 进行了必要的统一规范，组织结构更加清晰，系统更加健康；
• 引入了新的技术框架，，产品获得更好的体验；
• 进行了系统的优化工作，软件的品质更高，体验更好；

3、Google搜索关键字：架构设计

搜索引擎对于我们来说是最棒的学习工具，我通过搜索架构设计等关键字，阅读了一些文章，并仔细研读Keegan小钢的博客文章《小钢的架构思考》系列。这几篇文章在发表之初曾阅读过，但是当时并不怎么理解，大概是对架构还没有一个大概的认识。在请教一位前辈的时候，他和说了对架构的一个理解，并再次推荐了这几篇文章。所以我再次阅读了好几遍。下图是文中关于架构设计的知识概要。

（1）知识概要

（2）个人小结

架构分为三个阶段：规划、设计、构建，每个阶段架构的设计有不同职能。在规划阶段，考虑的是产品的需求、质量的需求，技术的可行性分析以及预研。在设计阶段，考虑的如果将一个复杂的系统拆分，并设计如何进行组织这些拆分的模块。在构建阶段，考虑的就是具体的实施问题，并且要保证一定的伸缩扩展性，因为架构是不断演进的。文中引用了《软件架构设计》一书的一个模型图，我觉得有必要在此贴出来。最近也在思考软件模块化的设计，模块化的设计也许各有理解，在此先不做讨论。如下图：

这张图我起初理解不是很透彻，我曾尝试自己去画一些图来表达我的一些想法。但是，当我再次回过头看到这张图的时候，才恍然大悟。 架构的设计可以从两个维度来考虑，一是架构思维，二是架构原则。思维是我们的思考方式，是我们解决问题的方法。原则是我们思考问题的方向，是我们解决问题的一些标准。

三、

架构的定义

对于架构的定义，业界都各有看法，也曾微信私信请教过一些行业内有丰富经验的前辈。《软件架构设计》一书则将架构定义总结为组成派和决策派：

• 组成派：架构=组件+交互：软件系统的架构将系统描述为计算组件及组件之间的交互。
• 决策派：架构=重要决策集：软件架构是在一些重要方面所作出的决策的集合。

keegan小钢在《小钢的架构思考：什么是架构》文中提到：软件架构是规划、设计和构建软件的过程和结果。《架构之美》一书在1.1.3架构的含义中提出：架构说明了设计和构建一个系统所使用的结构。《Software Architecture in Practice,Second Edition》中提出：一个程序或计算机的软件架构是系统的一种结构或一组结构，它包含软件元素、这些元素的外部可见的属性，以及元素之间的关系。

本人并没有经历过大型的软件系统，做过的也只是移动端App的开发，所以个人也只敢从移动端app的架构设计出发，给出我一个狭义的理解。我认为，移动端的app架构是一种基于产品和技术的进行统筹管理最终所形成的共识。可能大部分的app开发尤其是小团队app的开发大多是由产品驱动的开发，需求来了，那就技术实现。需求变了，那就改。毕竟，应用层的开发是对业务负责的，必须保证正常的发布。所以大多数的情况下，程序猿不得不在产品经理面前妥协，这样对于开发人员的工作就会变的很被动。所以，就出现了程序猿和产品狗的撕逼笑谈。这种现象的原因在于项目各个相关利益人员没有对产品和技术达成共识，这正是移动端架构设计所要解决的问题。

四、

产品

产品，是我们产品经理们设计的结果，也是开发人员开发的最终成果，是前后两种人群的共同目标。作为软件的架构设计者应该充分理解产品的设计理念，除了明白已经设计的功能业务，还得具有一定的预见，掌握产品的发展趋势。下面主要从开发的角度来谈一谈产品。

1、产品设计（做什么）

作为一名开发人员，我不能很专业的来谈产品的设计，但是这里我还是希望以一个开发人员的角度来讲产品设计。什么是产品设计，我觉得可以从以下几个方面来思考。

（1）、用户群体（什么人用）

顾名思义，我们设计开发出来的产品最终是让人用的。所以首先我们得定位产品的用户是谁？用户群体代表了我们产品的市场。所以产品做的好不好，最终市场说了算，用户说了算。离开了用户，不理解用户，不注重用户的体验，一切都是无用功。

（2）、核心理念（要做什么）

你知道你最每天累死累活一行一行敲出来的是什么样的产品吗？可能对于我们开发人员很容易陷入到一个版本一个版本的迭代当中，这些永无止境的工作叫人忘记了思考，忘记了问下产品人员，我们最终是要做的什么？一年后我们的产品将是个什么样的状态，我们的最终愿景是什么？我们将会怎么一步步去实现我们最终的愿景？可能你会说，这些和我开发有什么关系。接到需求，我把他开发出来实现不就ok了。然而，在我们的小组里不乏有这些怨言，产品人员不断的修改，我TM代码改过来改过去。我们的leader在这方面很强调我们开发人员应该拥有自己的主动权，可以反驳产品不合理的设计。但是，前提是你至少理解产品的核心理念，我们最终要做什么。

2、迭代计划（计划怎么做）

对于一个产品，用户的需求是很多的，而且随着时间不断改变的。需求可以分两种，一种是人性本能的需求，还有一种，是我们的产品催生的需求。这两种需求都是合理的，也正是我们需要满足用户的。对于各式各样的需求我们怎么有计划的去实现呢？在敏捷开发中，我们将这些需求放到一个“需求池”中，然后进行计划安排在不同版本的迭代中。这个工作，不仅是产品人员去决定，开发人员也应该起一定的决策作用。产品人员需要从产品的角度去考虑，开发人员需要从技术实现的角度去考虑，最终的计划应该是两者的共同决策。特别注意的是，根据产品的特性，技术人员也应该提出技术方面的需求。合理的迭代计划可以保证正常的开发节奏，完成迭代目标。

3、开发资源（用什么做）

（1）、开发团队配置（人）

在《人件》一书中提到了软件开发中人的因素很重要，合理配置开发团队是非常重要的。一个App的开发团队至少需要5个角色，即产品、交互、UI、软件、测试。不同角色也分不同的层次，比如软件分初级、中级、高级。不同角色、不同层次合理搭配，才能够获得更高的工作效率，保证产品开发顺利进行。

（2）、数据内容配置（物）

产品最终呈现给用户的是数据，数据分两种。一种是私有的数据，是由开发商自己生产的数据。一种是平台自生的数据，是由用户生产的。如果是自己生产的数据，就得考虑数据来源，数据的覆盖率，数据的准确性，合法性等。如果是用户生产数据，就得考虑用户生产数据的动力、入口以及数据安全性、传播性等。

（3）、开发投入预算（钱）

万事俱备，只欠东风。完成一款app开发，需要一支专业的开发团队，这里的人力成本也是很高的。当然我这里只谈开发的预算，至于运营就不说了。我们得考虑，开发周期多长、需要多少人、后期维护怎么办。比如一个APP需要5个人开发，2个月的时间，开发两个版本，按照每人1W的工资来计算的话，也需要 10W。这估计是最低级别的算法了。所以，如果是创业公司，我们在组建开发团队的时候，也得看看预算是多少，多少钱能办多大事，当然如果是那些拿到投资无所谓的老板来时得另算了，不过今年死的太多的公司以前都是大手笔。钱烧完了，也就没有了。如果是大公司，可能不带这么抠门的。不过也应该去考虑，开发团队会消耗公司多少资源，我们能否获得相应或者更高的产出。

（4）、第三方资源

目前的开发而言，很多资源是可以寻找第三方合作的。比如，服务器、云存储、支付接口、登录接口、内容数据以及开发过程中的一些开源框架等等。我们需要选择、商务谈判直到集成到自己的APP中。

4、产品质量（做的怎么样）

（1）、用户体验

现在对于我们来说，用户体验是一个说烂了的词。那是因为，用户体验真的很重要，决定了一个产品的成败。产品开发完成后，最终到达用户的手中。产品好不好，用户说了算。哪些因素影响到用户体验呢？我想大概可以从5个角色各自的职责出发来看，产品的设计是否直达用户痛点？交互是否符合人的喜好、习惯，UI是否让用户觉得舒适？软件的性能好不好？软件的缺陷是否多不多？

（2）、软件性能

从技术的角度来讲，我们可以通过软件的性能来分析一个软件产品的质量。今年许多的技术文章都在谈性能优化，软件的性能主要从软件的启动速度、流畅度、内存、功耗、流量、apk体积等几个方面来评判。如果想做好一个应用，性能优化应该纳入到日常的开发中持续进行。具体如何优化，这里就不再多说了。

（3）、产品安全

产品的安全性可以从两个角度来看，产品的生产商和产品的最终用户。对于生产商而言，有许多的内容是需要受到法律保护的，有许多的敏感信息，核心技术、网络接口等是不可以泄露的。对于用户而言，我们肯定在本地或者服务器存储了大量的用户信息，比如账号密码，一些信息一旦泄露将严重伤害到用户的个人利益。所以，为了保护自己以及用户利益，我们必须要生产一个安全可靠的产品。那么对于一个应用端的开发者而言，我们的编译出的apk最终会到用户手中。所以，我们需要通过代码混淆、数据加密、权限限制等一些技术手段来保护我们的应用。

（4）、质量评测

一个应用做的好不好，我认为可以主要从上述用户体验、软件性能、产品安全三个维度来进行评判。那么，我们该如何组织这些评判工作呢？我们有在进行这些工作吗？就目前而言，我相信大多数的产品、开发、测试人员都或多或少的参与到这些工作当中，但是也许没有将一些数据量化、没有系统的组织这些工作。目前大部分的应用都集成了行为采集，产品的下载量、用户的活跃度等也都是体现产品用户体验的主要参数。开发团队内部一直在进行性能优化的工作，比如异常修复、bug修复、内容泄露，过度绘制，apk瘦身。我们也进行了代码混淆、数据加密、apk签名加密的工作。但是，你知道你的产品质量如何吗？相比同类产品来，你哪些做的好，哪些做的不好吗？所以，我觉得将上述这些零碎的工作有系统的组织起来，将一些影响因素进行量化，让我们更加清楚的了解我们的产品质量是一件非常有意义的事情。

5、风险规避

（1）、人力变动风险

人是善变的，尤其对于IT来说，人员的流动就更加的频繁了，公司内部的调整，员工跳槽等等。所以，对于一直开发团队，必须要考虑到人员变动的风险。如果，某某不在了，项目是否可以正常运行。开发团队之间是否能够交叉熟悉各自之间的业务。

（2）、上层决策风险

是否经历过一个项目做到一大半业务被停掉了的情况？而这个时候，你做的是个半吊子。如果出现了这种情况，我们该怎么办？假设就在刚才你的老板说你现在的项目不做了，那么如何才能最大程度的挽回损失？如何进行项目的收尾工作?而不至于在项目又突然重启的时候接收的是一个烂摊子。

（3）、项目延期风险

我们在项目开发的时候会进行评审，然后按照迭代计划开发，但是在开发过程中一定会有许多问题影响我们的预期，比如需求变动、技术难题等等。项目延期在软件项目的开发中是普遍存在的问题，对于某些迭代而言，可能并不对整个项目造成重大影响，但是这个问题是一定需要考虑的。并且，我们应该严格的掌控项目的进度，平衡这些问题，保证能够按时交付产品。

（4）、软件缺陷风险

我们应该随时能够提供一个稳定的版本，这是我们的leader所要求的。软件的缺陷存在是正常的，我们不停的写bug,也在不停的修改bug,对于那些隐藏很深的bug也许没有让测试测出来，最后流通到用户的手中，这个时候我们如何完成紧急修复？如何快速响应能给到用户一个稳定可靠的版本。这些是我们需要考虑的，任何时候，都应该有PlanB。

（5）、人为失误风险

前段时间，公司内由于操作失误，上架更新一个apk的时候不小心发错了机型，导致使用该机型的用户升级后程序无法使用。然后，由于这个机型缺少维护，找不到代码，仅仅只能找到一个apk文件，然后只能考虑反编译升级等等。我想，类似于这类的人为失误还有很多，比如代码提交错误，集成路径出错等等。人总有一不小心的时候，所以，我们在设计的时候，应该将这些因素考虑进去，如何在出现失误的时候主动警告，如何在用户错误已经发生的时候启动紧急方案，将不良影响降到最低。

6、产品交付

（1）、测试版本

在敏捷迭代开发中，我们基本上能够一周提交两个测试版本。我们开发一部分、修复一部分，都可以提交一个可测试的版本，这样可以最大程度的降低开发风险，有利于软件的稳定性。

（2）、灰度机制

如果你产品的用户量够大，这个时候发布新的版本就得慎重考虑，用户才是你的产品的检验员。目前基本都是使用灰度发布的策略，先给少量的用户发布，看看用户的反馈，而后逐步发布给所有用户。

（3）、版本管理

我们在开发过程中有许多的版本，也有很多分法。如debug和release版本，有的时候还需要给内容提供测试数据的data版本，还有的时候上一个版本还没有正式发布我们就需要开发下一个版本的功能。我们如何去管理各个版本的代码以及如何通过版本名来区分这些版本？我们需要制定一定的管理规范，并且这一规范是否在开发团队中达成共识，就显得非常重要。

篇幅原因，未完待续,敬请期待............

小贴士

本文版权归Open软件开发小组所有，如需转载请联系主编申请授权。