Android App架构， 技术选型，技术堆栈，工程架构分层设计，项目重构(!!!)

    在Android App中，哪些是我们需要的横切关注点？个人认为主要包括以下几个方面：Http, SharedPreferences, Json, Xml, File, Device, System, Log, 格式转换等。

Bob大叔 所说：“Architecture is About Intent, not Frameworks”。

- 移动架构 (一) 架构第一步，学会画各种 UML 图- https://juejin.im/post/5d2e048cf265da1b9163c7c8
UML 图开始用是 Windows PowerDesigner 工具，后来换电脑了用的 StarUML。
用例图 (User Case Diagram)

-- Android APP架构思考- https://blog.csdn.net/xiaxl/article/details/72593945
  从2011年到现在，做了几年的Android应用与Android平台上Opengl es应用开发，下面是关于Android APP开发架构的一些思考：构建框架的最终目的是增强项目代码的可读性 ，维护性 和方便测试 ，如果背离了这个初衷，为了使用而使用，最终是得不偿失的。

从根本上来讲，要解决上述的三个问题，核心思想无非两种：一个是分层 ，一个是模块化 。两个方法最终要实现的就是解耦，分层讲的是纵向层面上的解耦，模块化则是横向上的解耦。
  框架和通信方式：模块内部，采用观察者回调进行通信；模块之间采用广播(或者其他进程间通信方式)进行通信.
- 以广播举例： 
+ 1、主模块内部采用事件回调进行通信； 
+ 2、主模块使用广播将事件传递给子模块；
+ 3、每个子模块内部采用事件回调进行通信；

-- 简洁架构 意味着产品系统中遵循一系列的习惯原则：
 1.框架独立性
 2.可测试
 3.UI独立性
 4.数据库独立性
 5.任何外部代理模块的独立性
 6.Entities：是指一款应用的业务对象
 7.Use cases：是指结合数据流和实体中的用例，也称为Interactor
 8.Interface Adapters： 这一组适配器，是负责以最合理的格式转换用例（use cases）和实体（entities）之间的数据，表现层（Presenters ）和控制层（Controllers ），就属于这一块的。
 9.Frameworks and Drivers: 这里是所有具体的实现了：比如：UI，工具类，基础框架，等等。

   ClassLoader/泛型/反射/注解 .
   不要天天谈什么框架，什么库，框架每年层出不穷，可是扒下框架那层炫酷漂亮的外衣，里面还是那些最基础的知识和原理。就是这些算法，数据结构，计算机网络，计算机原理这些看似基础的东西。面试数据结构和算法，可以面出你的思维能力，思考能力，这个能力对于编程来说很重要。比如：如果面试你使用过什么框架吗？你说：会，使用过，然后你谈了谈使用这些框架的一些知识和遇到的坑，以及怎么解决的？通过这样的问题，不能看出的思维能力和编程能力，只能看出你确实会用这个东西。
   学习的最佳方式就是阅读，对程序员来说也是如此。如果你想成为一个更优秀的程序员，你必须阅读更多的代码，就是这么简单。书籍，博客，论坛在某种程度上都是有益的，但是没有什么能替代功能完善、代码详细的开源项目。整个app的所有相关资源都直接呈现在你面前。这些都是很好的学习素材，不管是代码设计、UI设计还是产品设计都值得我们学习和借鉴。
   2017年4月，随着流量分析工具 StatCounter 的报告，，Android 首次超越 Windows，成为用户访问互联网最常用的操作系统！Android 不仅在移动领域，在全操作系统内，都成为了当之无愧的霸主！

App架构经验总结- http://www.iteye.com/news/31472

-- 怎么架构一个APP？
  有些东西还是通用的，是所有架构师都需要考虑的，也是所有项目都会有的需求，比如API如何设计？架构如何分层？开发环境和生产环境如何分离？
 1.从API开始 ,一个App，最核心的东西，其实就是数据，而数据的主要来源，就是API。
 2.制定安全机制 ,设计API第一个需要考虑的是API的安全机制。保证API的调用者是经过自己授权的App；保证数据传输的安全。
 3.接口协议标准化 ,API返回的数据，一般都是采用JSON格式进行传输。
 4.接口版本控制 ,我们已经不止一次因为接口发生变动而导致旧版本的App出错的问题，而且变动不一定是修改了接口本身，有可能是底层增加了一种新的数据结构，接口把新数据也返回给客户端了，但客户端旧版本是解析不了的，从而就导致出错了。 
 为了解决接口的兼容性问题，需要做好接口版本控制。实现上，一般有两种做法： 
   a.每个接口有各自的版本，一般为接口添加个version的参数； 
   b.整个接口系统有统一的版本，一般在URL中添加版本号，比如http://api.domain.com/v2。 
 5.架构分层 , API的设计完成之后，接下来我就会考虑App项目的整体架构了。整体如何架构，我也曾经做过不少尝试。早期的时候，Android就是将所有操作都放在Activity里完成，包括界面数据处理、业务逻辑处理、调用API。后来发现Activity越来越臃肿，代码越来越复杂，很难维护。于是就开始思考如何拆分，如何才能做到松耦合高内聚。 
  从App对数据处理的角色划分出发，最简单的划分就是：数据管理、数据加工、数据展示。相应的也就有了三层架构：数据层、业务层、展示层。 从上往下：展示层，业务层，数据层。
 6.环境分离 ， 每个App项目，至少都会有两个环境：测试环境和生产环境。多的甚至有四个环境：开发环境、测试环境、预生产环境和生产环境。开发人员经常需要在环境之间切换，测试人员也同样。
 7.应用层（MVC MVP等）-> 组件层（推送 社会化分享等）-> 基础层（网络通信、数据解析、日志记录等）-> 跨平台（消息处理 IO操作 线程等）。。。

 8.客户端架构，这一层是对APP的横向拆分，根据业务的特点，分为Native，H5，SDK三块。SDK化和SOA服务化的主要区别是解决思路的不同。SDK化是模块的横向切分，进行部门间、公司间协作。SOA服务化的思路是独立、单一、解耦、提高复用，最好是在分层之后再按模块分类。因为不同的层，分类的标准都有可能不同。
  将传统的APP分为三层。界面层只做界面相关的事情，和UI一起开发；数据层专门负责API接口的实现，和APP后台一起开发。业务逻辑层主要用来实现业务规则，做到与数据和界面无关，尽量提高复用度。

 9.对于一个App来说，不管大小，我们在开发的过程中或多或少，都会碰到下面罗列的各种模块，需要我们去处理。

业务处理，对用户输入的校验和展现判断等；
 统计处理，对当前App或者对业务的数据统计等；
 UI效果，包括主题配置，按钮，输入框，动画效果，自定义控件等；

 更新升级，当前App的检查更新等；

 服务器通信，与服务器通信获取数据，心跳连接等；

 数据解析，比如对json，对xml等的解析等；
 分享处理，分享到微信朋友圈；
 通知消息，Notification处理;
数据存储，包括SharedPerference和SQLiteDatabase；
 文件处理，对SDCard的读写；
 异常处理，对DefaultUncaughtExceptionHandler的使用

  Android的开发知识，Android的单元测试、代码规范、版本控制、重构、架构等。

10. 应用层（MVC MVP等）-> 组件层（推送 社会化分享等）-> 基础层（网络通信、数据解析、日志记录等）-> 跨平台（消息处理 IO操作 线程等）。。。

11.APP技术框架：需要了解业务；分包分module；详情页需要用到H5吗？ 需要统计 需要bug收集，MVC还是MVP 哪些由原生做，哪些由H5做？分几个Tab 每个tab规划放什么内容；产品的定位，及要突出表现什么  APP的主体颜色？需要使用哪些框架 自己开发和使用第三方框架的衡量？

App 后台架构- https://blog.csdn.net/yangzhongxuan/article/details/77949315

> App 架构师
-- App 架构师的核心职责 :

选型规划;架构设计;技术攻关;沟通协调;疑难攻略等;
 这些对架构师来说应该都是通用的。对效率、性能的追求，我认为是架构师最崇高的目标。

  功能、安全、性能、稳定，架构是一种折中;资深开发需要技术的广度和深度，架构师需要技术和业务并重.除了日常开发的知识以外，更是对我们经常忽略的架构模式、应用质量和稳定性监控处理、测试相关知识做了介绍.

-- App 架构:
 常用模块的设计思路;基础组件、必备的基础业务模块如何设计;App 架构的基本功;组件和模块;
 UML 基本功、设计模式概览;接口设计、常见架构模式等;App 质量和稳定;衡量指标、处理手段;
 测试相关知识点介绍;App 性能优化;硬件、UI、CPU、内存、网络、安装包体积、启动优化;
 App 安全逆向;逆向的基本介绍;混淆和加固的原理;Proguard 配置详细例子.

-- 对架构师思维的理解:
 架构思维：以产品和业务为驱动的顶层解决问题的思维，需要同时考虑产品、技术和人三重关系。
 架构师经常做的是“分”和“合”，即所谓的系统拆分和重新组合，这要求他的综合能力要很高，需要同时具备思维的高度和深度：具备技术思维的广度和深度，涉猎多领域时能够有足够的技术前瞻思维;具备沟通协调能力，更懂得平衡

> Android技术选型或整体框架图：如下

> android APP工程架构和框架
  分享些思想，抛砖引玉：1.GOF的设计模式；2.android APP工程架构：MVC MVP MVVP ；3.android APP框架（可自己来实现）：基于注解 、基于ORM、基于代理、基于IOC AOP等
>  模块化开发
有赞 App 模块化实战经验总结- https://youzanmobile.github.io/2017/04/14/youzan-app-modularization/
Android 开发:由模块化到组件化(一)- http://blog.csdn.net/dd864140130/article/details/53645290
  将项目分为了四个层级：模型层、接口层、核心层、界面层。模型层定义了所有的模型；接口层封装了服务器提供的API；核心层处理所有业务逻辑；界面层就处理界面的展示。在Android Studio分为了相应的四个模块(Module)：model、api、core、app。
  model为模型层，api为接口层，core为核心层，app为界面层。
  model、api、core这三个模块的类型为library，app模块的类型为application。
四个模块之间的依赖设置为：model没有任何依赖，接口层依赖了模型层，核心层依赖了模型层和接口层，界面层依赖了核心层和模型层。
  模块化就是将一个程序按照其功能做拆分，分成相互独立的模块，以便于每个模块只包含与其功能相关的内容。模块我们相对熟悉,比如登录功能可以是一个模块,搜索功能可以是一个模块,汽车的发送机也可是一个模块.
 模块化开发,模块化开发中最大的问题就是组件间通讯-->路由的概念,把项目模块化了, 那两个组件间进行通讯或者跳转, 我们一般构建Intent的方式就不再使用了。
  模块之间总是存在这一定的接口，从调用方式上看，可以分为三类：同步调用、回调和异步调用。同步调用是一种阻塞式调用，也是我们在写程序中经常使用的；回调是一种双向的调用模式，也就是说，被调用的接口被调用时也会调用对方的接口，这句话可能有点绕，等文章后面举例说明；异步调用是一种类似消息或事件的机制，解决了同步阻塞的问题。

-- App模块化分为5层模型:
（1）应用层是生成app和初始化操作的加载
（2）模块层，每个模块相当于一个业务，通过module来分隔开每个业务的逻辑。
（3）基础层，基础组件的整合，提供基础组件能力给业务层使用。
（4）组件层，通过图片加载，网络http,socket等基础功能划分为一层。
（5）基础库层，更加基础的库类依赖，此层非必须，例如（Rxjava，EventBus等一些代码结构优化的库），还有自己编写的封装类。

-- 插件化，研发阶段考虑的问题
（1）资源冗余解决，包括对于base module的依赖和库依赖
（2）混淆相关和资源冲突
（3）插件加载方式
（4）通信依赖，数据交互，事件触发

> 路由机制
模块化开发中最大的问题就是组件间通讯。
开源最佳实践：Android平台页面路由框架ARouter- https://yq.aliyun.com/articles/71687?t=t1#
Android平台页面路由框架ARouter的技术方案- https://github.com/alibaba/ARouter
 -- 路由的方案：
1.完全自己实现路由, 完全封装跳转参数
2.利用隐式意图跳转（Android原生支持，仅支持Activity, Service, BroadcastReceiver）
go web开发之url路由设计- http://blog.csdn.net/qibin0506/article/details/52614290
Android路由实现- http://blog.csdn.net/qibin0506/article/details/53373412

> 重构围绕一个老生常谈的概念「解耦」展开，设定几个目标：
1.清晰划分各模块的角色
2.明确架构层级及各个模块所在的层级
3.提高整个架构横向扩展的能力
4.提高编译效率，由于我们项目大量使用 Kotlin 开发和 AOP 技术，在编译上面个比较耗时，期望在架构调整后，在整个项目的编译效率上又一次大的提升
5.各模块独立开发，面向接口和协议编程
6.提高可维护性

充分考虑可拓展性和可维护性，把模块化、性能优化、用户体验等
关于App重构的几个方面- http://www.jianshu.com/p/1125f4be4cc3
Android重构记录及其模块化- http://blog.csdn.net/jonstank2013/article/details/56833462
Android项目重构之路:架构篇 - http://keeganlee.me/post/android/20150605
Android项目重构之路:界面篇 - http://keeganlee.me/post/android/20150619
Android项目重构之路:实现篇- http://keeganlee.me/post/android/20150629

> App架构设计
App架构设计经验谈:接口的设计     - http://keeganlee.me/post/architecture/20160107
App架构设计经验谈:技术选型         - http://keeganlee.me/post/architecture/20160114
App架构设计经验谈:数据层的设计 - http://keeganlee.me/post/architecture/20160120
App架构设计经验谈:业务层的设计 - http://keeganlee.me/post/architecture/20160214
App架构设计经验谈:展示层的设计 - http://keeganlee.me/post/architecture/20160222

Android中级第十二讲浅谈架构设计- http://blog.csdn.net/reboot123/article/details/51321248
内容型App的客户端架构之道- http://www.infoq.com/cn/presentations/content-type-app-client-architecture
Android开发框架大全- http://www.ctolib.com/topics-113373.html?ref=myread
平安好医生技术栈的分析（APP架构）- http://blog.csdn.net/caroline_wendy/article/details/51426837
基于RxJava+Retrofit精心打造的Android基础框架(源码)-http://download.csdn.net/detail/xiaoyaoyou1212/9755991
好客户端是怎样炼成的- http://blog.csdn.net/a345017062/article/details/45538187

程序的功能才是我做的所有工作中用户真正想要和关心的。架构能够满足应用的需要即可。
安居客 Android 项目架构演进- https://mp.weixin.qq.com/s/aizuJ2qZhP-lYANirXI1og

> App架构
详解Android主流框架不可或缺的基石- https://blog.csdn.net/lfdfhl/article/details/52673536
谈谈我理解的Android应用架构- https://www.jianshu.com/p/734d3693da02
Android架构：代码层面，主要是MVC和MVP的理解。项目层面，主要是怎么搭建整个项目，怎么划分模块。
-- 项目常见的架构方式：应用层+业务层+基础库
  1、最底层是基础库，放置与业务无关的模块：比如基础网络请求，图片压缩等等，可以按需分为逻辑模块，通用UI模块和第三方库。（建议采用独立的svn分支）
  2、中间层是通用业务层，放置公司多个android项目的通用业务模块（和业务相关的），比如登录流程，文件上传/下载等。
  3、最上层就是应用层了，比如公司有三个android项目：LbBoss,BV和BVHD。我们还可以针对相似的项目再抽取通用层（比如这里的BV和BV PAD版，通用层为BVCommon）。

避免重复制造轮子，更要造特别的轮子。

-- APP的整体架构分层
从较高的层次将，一个APP的整体架构可以分为两层，即应用层和基础框架层。
  1.应用层专注于行业领域的实现，例如金融、支付、地图导航、社交等，它直接面向用户，是用户对产品的第一层感知。
  2.基础框架层专注于技术领域的实现，提供APP公有的特性，避免重复制造轮子，它是用户对产品的第二层感知，例如性能、稳定性等。
  基础框架层：这里所谓的基础框架，指多数App都必需的基础功能，是具体业务逻辑实现的基础。主要有网络请求功能、图片加载与缓存功能、SQLite数据库管理功能、Log管理功能等，当然根据对业务逻辑支持的不同，基础框架层的功能支持也不一定相同，上述几个应该是大部分App都要支持的，当然Crash监控与常用工具类也可归为该层次。 
  具体到每个基础框架的实现则没有任何限制，如网络功能可以使用Volley、OkHttp或者自己封装实现网络请求逻辑；对于图片管理功能则可以使用Glide、Fresco、Picasso，亦或自己实现……总之每个基础框架都要遵循一定的实现原则，保持功能模块的独立性，与具体业务解耦并对外提供良好的交互接口。
  3.业务逻辑层：如果把App架构比作高层建筑，那么上述两层就是地基。地基打好之后，就可以在上面任意发挥了，至于如何发挥，那就必须结合实际的业务需求，不同的应用往往有不同的业务功能模块。 
  4.另一方面，业务功能模块也并非完全是并列的级别，有一些业务逻辑也是可以抽象出来的，作为通用的功能模块，比如登录、分享、扫描、统计等，其他的业务模块可能会调用到这些功能。

-- 关于移动端架构的思考与总结- https://blog.csdn.net/uxiAD7442KMy1X86DtM3/article/details/79683582
  1. 移动端目前的架构，差异化在于通信机制。通过以上说明，通信机制主要分为3种：
      a.对象持有；b.接口持有；c.路由
  2. 通信方式中，对象持有是比较原始的，解耦率最低，建议放弃； 接口持有是个不错的选择，极大程度上实现解耦的诉求，但是解耦不彻底，相互持有交互方的接口。 路由机制也是个不错的选择，可以实现完全解耦，就像组件化一样。但是路由机制的设计是个技术难点，怎么设计效率最高？更健壮？代码可查阅性更好？这些都是值得思考的问题。
  3. 对于路由机制的优化，阿里的ARouter（用于组件通信）中，采用了分组的模式，我们可以采用；其次可以根据AnnotationProcessor 的处理，为每一个注册接收器的组件实现一个SupportActions来确保消息只发送给注册了指定类型的模块，也是个不错的选择。