首先声明，我本身并不是专业的架构师，文中所有观点均来自项目开发经验总结，难免可能有错误，如果有专业架构师看到了，欢迎及时指正。
架构这个词，可能在很多萌新看起来很高大上，觉得遥不可及。其实懂的人都知道，也就那么回事，架构本身并不难，难的是如何设计一个好的架构。说的通俗一点，如果说编程好比盖楼房，所谓架构就是我们的房屋结构设计而已，如果一栋楼房建成没多久就垮了，排除材料问题和本身施工问题，首先我们想到的肯定是这个房屋本身设计不够合理。
那么如何搭建一个合理的架构？对于初学水平来说，我觉得首先满足以下几点：
- 稳定
- 简单
- 功能齐全
- 相对高效
稳定。这个很好理解，以上面盖房子为例，房屋结构设计好不好，首先就是够不够稳定。如果遇到点轻微地震就垮了，那么这个设计一定是失败的。放在编程中同理，你的架构应该除了能处理常见的能够预知的错误外，对于不可见的异常也应该有一定适应力，当然，架构只是一方面，再好的架构，你的具体代码如果没有足够的健壮性，造成程序崩溃也是必然的。
简单。这里其实包含的东西比较多：首先，使用简单，因为通常我们的架构肯定是由多人共同开发的，所以在使用上一定要简单，哪怕你设计的再好，但是使用非常复杂，我觉得，很多人可能并不会按你的架构这来写，那么架构也会失去了意义。其次，结构简单，架构的结构应尽可能简单易懂，这样的好处是，哪怕是才加入团队的新人也能很快的理解你的架构设计，快速进入开发，不论设计模式还是什么，我们都不应该为了用而用，而是确实需要用才用。最后，维护简单，也就是说易扩展易维护，因为通常你完成一个架构设计的整套框架后，后面是否由你维护是不确定的，所以我们就要尽可能提高本身的易维护性，方便协同维护。
功能齐全。如果仅仅是写两个基类就能叫架构框架的话，我相信架构师都没法混了。良好的架构应该是让各个模块间有机的集合在一起，开发中方便各个地方调用而又不会引起过强的耦合。当然，我们不应该为了功能齐全而全部揉在一起，那样也就失去了架构的意义，我自己本身也看过一些人写的架构框架，他们很多人都有一个共同的问题，就是架构框架依赖了过多的库，比如某些第三方控件，又比如Butter Knife。我觉得，纯粹的架构框架应该尽可能少的依赖这种第三方库，这样才能避免因为第三方库引起的一系列问题。
相对高效。为什么这里叫相对高效？我个人的主观意见就是，不要盲目追求高效。为了提升0.01秒的运行速度而花几百上千行代码去优化，在移动端来说是完全没必要的，因为移动端和后端不同，需要处理的数据量级是非常小的，没有必要过度关注效率，更不应该为了一点点效率去复杂自己的设计和代码。所以说，相对高效就是说，在满足了前面几个条件后，我们再来实现尽量的高效。
差不多就是这些了，当然，很多东西，说起来很容易，实现起来确实比较难，所以，我想给那些想自己打框架的同学的建议是，不要想一次就搭出完美的架构框架，好的东西都是需要经过时间的打磨的，唯有一次次改进，你最终才能拥有自己的一套架构框架思想和体系。
题外话：前段时间和一家线上公司谈好，帮他们维护和修改他们现有的安卓项目架构框架，所以，后面几个月可能没有太多时间发博文了，等后面弄完这块，我会把维护别人的框架的经验再次分享给大家，欢迎大家持续关注。
