架构与框架的区别

                                                                           （https://www.cnblogs.com/cjm123/p/8124946.html）
一句话，框架是软件，架构不是软件。

框架落脚在“架”字上，可以理解成名词性的，是一个客观性的名词存在，如.Net Framework；

而架构体现在“构”字上，理解成构造，是一个动词性的，是一系列动作发生的策略性体现。

相同点： 框架技术和架构技术的出现，都是为了解决软件系统日益复杂所带来的困难而采取“分而治之”思维的结果

不同点：

1、架构的解决思路是——先大局后局部。框架的思路是——先通用后专用。

2、架构不是软件，而是关于软件如何设计的重要策略。他主要处理如何将软件系统分解成不同的部分，各部分之间静态结构关系以及动态交互关系等。架构是抽象的解决方案。

   框架是一种特殊软件，它不能提供具体的功能、应用级别的功能，它是个半成品，专门为开发者构建具体的解决方案提供良好的基础。框架中的服务可以被最终应用系统直接调用，而框架中的扩展点是供应用开发人员定制的“可变化”点。

Android 架构的应用  

Android架构作为一种解决Android开发问题的抽象策略，主要解决了以下几个问题：

1、分工协作，专人专事，更能发挥开发人员局部能力，提高App质量

2、统筹管理，单个App或者整个App生态，被统一分解成不同部分，统一分配，有利于对庞大的开发团队和任务进行管理。

3、有利于APP通用部分的技术沉淀，减少重复开发，提高新产品的开发效率。

4、方便剥离核心机密技术，进行专门的保密。

5、高扩展性，方便公司扩张中对收购的APP的快速改造与接纳到现有的技术框架中。

6、分布式开发，远程协作开发的功能有助于公司业务上进行跨地域，跨部门技术合作开发，方便公司在战略上跨地域扩张

Android 通用技术有哪些？

1、网络请求框架  （Okhttp3、OkhttpUtils）

2、上下拉刷新框架 （PullToRefreshLayout）

3、数据存储框架 （Sp存储， 数据库存储，多用户空间管理）

4、全局Loading动画框架  （自己封装）

5、埋点框架  （友盟 和腾讯）

6、日志搜集上报框架 （友盟 和腾讯）

7、日志打印管理框架 （日志开关，日志级别管理，日志文件形式输出）

8、线程调度框架  （自己封装）

9、网络数据解析工具（通常是json格式数据的解析，fastJson ）

10、文件上传下载 （OkttpUtils 自带文件上传下载，）

11、屏幕适配框架 （AutoLayout 和  AndroidAutoSize）

12、权限申请框架  （自己封装）

13、图片下载与压缩框架  （Gilde，ImgUtils）

14、路由框架 （自己封装）

15、热修复框架  （腾讯 bugFix）

16、音视频播放   （第三方合作商）

17、沉浸式状态栏  （自己封装）

18、防重复点击 （自己封装）

Andorid 架构设计图

Android架构设计的原则，高复用性，高解耦性，无限扩展性，支持多人协作开发。

1、组件是整个架构中，最底层的一级，也是功能最单一的一级。它为上层提供最基础的功能。

2、功能模块，是对单个组件或者多个组件的组合使用，组合出高级功能，业务模块能够直接使用的功能。

3、业务模块，这种模块会使用功能模块加上具体的业务数据和逻辑组成跟具体业务相关的可复用模块。

4、组件与功能模块可以是自己编码，也可以是使用满足需求的第三方代码。使用第三方代码时，需要封装接口适配器，将第三方与上次调用模块进行隔离，以方便随时更换第三方或者扩展出新功能。

支撑此 Android 架构的协同工具

上述 Android架构在实现时，无论是组件还是模块对于上层调用者来讲都是一个SDK。而对于Sdk，android提供了aar格式的包。所以，需要使用搭建私有Maven进行发布aar和依赖其它模块的aar。

具体使用参见 https://www.jianshu.com/p/d813d28699ce

Android 架构的弊端

这种Android架构的产生的背景是，随着公司的业务不断发展，延伸出多个App，成立多个团队。然App技术有很多共用部分 ，如果每一个团队都各行其是，必然会重写这部分代码，造成人力资源浪费。代码风格与管理也不能统一。基于这种情况，产生了上述支持分布式开发App端统一架构。但使用这种架构解决上述问题时，是付出了不可避免的代价的。

1、代码冗余。当模块被作为Sdk开发时，开发Sdk时看不到具体业务究竟有哪些需求，在面对未知的调用者进行开发时，只有将几乎所有常规调用全部实现，才能确保业务调用者无论是谁，无论需求是什么，都万无一失。

2、模块和模块之间通信的位置提到重要位置。两个模块开发时互相不知道彼此的功能实现，只能靠沟通和想象进行自己一边的功能开发，初期常会出现想象的情况或者沟通的情况与实践不符然后反复修改，沟通成本提高。

3、调试成本与测试成本增加。之前当发现一个BUG时，我们处理方式是定位问题，如果问题在另一个模块中，直接修改源码，然后编译运行。是有架构之后，当我们依赖的模块编程Sdk，问题定位本身就出现争议，即便已经定位确实是模块中问题，也需要通知到开发者进行修改，重新发布。 

历次实践问题总结

1、UI模块化问题：

     将UI模块化的问题，主要集中在UI复用性相对功能较低且更新频繁，封装之后可能只被一个模块引用或只被一个版本使用。所以通常UI模块化的规则时，一处UI被三个及以上模块引用或者被应用三次及以上，可以考虑将其模块化。以此标准，封装UI一般有BaseAcitity和BaseFragment、主要布局、主题、进度、按钮等。

2、同层依赖问题

     在开发过程中通常是向下依赖，同层之间出现依赖时，一般是把被依赖模块中被依赖部分抽取成组件或者直接把整个模块降级成组件层，但抽取有时需要时间，而整个模块降级有时会造成概念定义不清，调用者或者后来者分不清这个一块的代码到底是组件还是模块。所以遇到以上两种情况，难以抉择时，允许同层依赖，但不允许互相依赖。

3、重复依赖问题

      开发过程中不可避免的会出现多个模块同时依赖同一个模块的情况，在这种情况下，由于所有组件和模块都是aar形式上传至了Maven私有服务器且所有依赖使用Gradle语言的依赖方式，所以完全可以使用Gradle语言屏蔽掉多个模块中的引用，只留下一个模块引用。

4、模块使用文档

     一个模块开发完毕，外界很难清除这个模块是如何使用的，并且aar不是Java源码，里面所有的方法注释都已经删除掉了，所以需要一个txt文件对其主要用法进行说明。而整个文件需要放在res文件夹下的raw文件夹中。这样，当我们引用了一个模块之后，只需要使用开发工具找到引用的模块，点击打开Raw文件夹就可以阅读到开发者的介绍。通常这个文件名字被统一命名为Readme.txt 

5、UI基础库与组件基础库管理

      长期的开发实践中，基础组件不仅是一些功能性的，UI也有一些基础的组件，是各个模块都需要的。比如，TabLayout、带头尾的RecycleView等。所以在Maven库的管理中，需要建立两个库，一个BaseUI和一个BaseComponent 库。依赖时，基本是把这两个库作为基础，几乎所有模块多会用到。