本文主要是针对于个人的一些理解，和平时真正能用上的。如果有不妥之处，说明还是我个人技术不过关，希望大家多多指正。
首先来说，一切得看需求、周期、环境。
这三个方面啥意思呢
1.需求，就是具体的需求文档，设计文档，和应用所需要达到的高度和深度（具体点可以指日活、平均使用时长、累计用户等）
2.周期就是应用开发的周期时间，测试时间（是否有A/B测试），后期维护时间，整个生命周期
3.环境，就是应用在什么环境下开发，安卓终端、手机、或者电视；开发团队成员组成环境；应用后期需要面对的用户市场等；
针对于这三个，我们需要考虑的是，是否采用原生APP、hybrid APP、WebApp设计；采用MVC、MVP、MVVM中的哪一种；网络请求框架选择volley、OkHttp or Retrofit；图片框架采用ImageLoader、Picasso、Glide哪一种；缓存策略的选择等等；
其实只要是设计到技术的，都得具体到团队，团队中的人，是可以花时间来适应你熟悉的框架，还是时间周期只够用他们熟悉的框架。这个我一般是对团队成员进行统计，选出一款他们喜欢，熟练度高的框架，在保证需求在计划内完成的情况下，尽可能让他们尽快上手。也会将复杂程度不同的业务和技术，分配给不同的人来完成。这是架构设计的核心。当然，前提都得满足可维护性、可阅读性等。
我再举几个例子：
1.后台数据请求频繁，且数据量较小，你会选择哪种网络请求框架，我会选择Volley框架，开销小，速度快。还有一点，大家都很熟悉。
2.app页面比较多，时间周期较短，那么有些页面我们可以采用H5来实现；即选择WebApp
3.业务逻辑不复杂，那么我们首选MVC模式，代码量小，还能满足大部分人的开发；
4.H5可以选择两种方案，web server方式，通过LoadURL来实现，效率低，但是复杂程度也低；本地方式，将H5代码，CSS/javascript代码，都存在本地，效率高，实现起来可能稍微复杂一些；
5.对于应用体量较大，设计的模块功能业务都很复杂，我们可以采用模块化设计，即将应用分为不同的module，不同的人复杂不同的模块，对于开发来说，节省了很多沟通成本，最终转化为效率上的差异；
6.对于第三方的SDK来说，在预算允许的情况下尽量选择大公司的品牌，尽量选择稳定性较高的品牌；预算不允许，这个就得分情况而定，不是一个应用架构师就能决定的，你可以给上级出几套方案，供他们选择；某些情况下，你可以自己选择出一款最优的。
栗子吃完了吧， 是不是觉得有点虚，来点实际的，好的呢。
应用架构设计中，有四种方案：
1、三层分层设计，表示层（UI）、业务逻辑层（BLL）、数据访问层（DAL）；其中业务逻辑层，作为表示层和数据访问层的桥梁；
2.四层分层设计，表示层、业务规则层（ECL）、业务逻辑层、数据访问层，业务规则层的作用呢，就是对UI层传下来的参数进行检验，比如登录名的合法性，密码的合法性等；
3.引用Service层，表示层、服务层、业务逻辑层、数据访问层，服务层主要用于给表示层业务逻辑入口，定义接口服务；
4.VIPER，这里给个链接，讲解比较详细，点击了解VIPER
下面我们来讲下针对于三层设计的一个具体案例
表示层
表示层其实最重要的就是保持代码和结构整洁：
1.尽量采用抽象和封装的思维，面向对象设计
2.按组件划分，比如包名按照view/activity/fragment/adapter/util/service/app/network等来划分，因为组件大家都懂，一看就能知道当前包里有什么东西；
3.基类的定义和封装，这里不细讲，相信大家对基类都有一个比较深的体会
4.ActivityManager，Activity的堆栈式管理；CrashHandler，应用崩溃日志统计；NetworkApi，管理所有的API接口等。
业务层
业务层的作用就是向上，跟表示层交互；向下，与数据层交互；
举个栗子：用户注册，需要检查登录名密码等的合法性、是否自动登录、注册成功如何处理；这都根据具体业务来设计就好，这个相对来说，是比较简单的一个阶段，只涉及到具体的一些解决方案和算法；
数据层
数据层主要有几个问题，如何获取数据，如何组织整理数据，如何展示数据?
主要涉及到的，如何调用API接口，如果对数据进行保存或者清理，如何将数据交给业务层，最终展示出来
根据上面三个问题，可以将数据层分为网络层，本地数据层，交付层
网络层主要处理一些网络相关的，比如节省流量、不同网络状态的处理、API参数合法性、不同的错误码和响应码对应情况
本地数据层主要处理数据，数据是否需要缓存，缓存策略和缓存的时间周期等；
交付层则可以理解为取数据层，不用关心数据来源，只关心结果。向上需要向数据层获取数据，这里可以定义一些开发的接口或者协议。
根据这上面三层结构，大致可以清楚，一个应用架构设计的要点。下面给大家看一个案例，我设计的一个业务逻辑相对简单的框架
有没有觉得结构还算清晰，app处理一些全局变量，Application等；manager主要是Activity堆栈式管理类;network主要是封装了一层Volley框架，然后对http的一些协议证书等上面的一些处理，再加上API接口类。
最后讲解接口设计
接口设计原则大家应该都很清楚，就是每次请求都要带上身份验证信息；但有一点可能大家会忽视，如果接口被劫持，那么很有可能获取到我们应用的一些重要数据，这个时候有两种解决方案：
1.采用Https,这个一般用得比较少，可能大厂里面可能会用到把
2.采用秘钥的形式，应用登录后，返回给应用一个秘钥，每次上传请求的参数，都与秘钥进行合成生产签名值，最后传递给服务器的就是一个签名值的串，这就是为什么我们请求百度，或者一些网站的时候，后面会有一大串十六进制的数据。
最后来个接口设计的案例吧：
这里就发一个目录，仅供大家参考。具体的定义根据公司规范和个人习惯等。
最后再发两个干货，
1.关于命名规范，大家可以遵守阿里巴巴android开发手册
2.性能优化 Android性能优化大全