本文主要总结的内容如下：

• 一、框架简介
  1、框架
  2、Dalvik虚拟机与ART虚拟机
  3、Android应用程序框架（APPLICATION FRAMEWORK）
  4、简述下Android 数字签名

系列第二篇：<查漏补缺_Android基础系列>视图组件

一、框架简介

1、框架

• 总结：
  Android系统架构包含四层：Linux内核层，库和运行时、Framework层、应用层。Android的体系架构鼓励系统组件重用，共享组件间的数据，并定义组件间的访问控制权限。这些层次结构既相互独立，又互相关联。

• 说明：
  1、每个Android应用程序都运行在它自己的Dalvik 实例的一个进程中。
  2、Dalvik 和 Android运行时位于一个Linux 内核之上。
  3、Android软件栈 是通过一个应用程序框架提供一个Linux 内核和一个C/C++库集合，而该应用程序框架为运行时和应用程序提供服务，并对它们进行管理。
  

  Android体系架构（Android软件栈）

• Android软件栈（体系架构）
  1、Linux内核（Linux KERNEL）
  Linux提供了核心服务（硬件驱动程序、进程和内存管理、安全、网络和电源管理），而且内核还在硬件和软件栈的其他部分之间提供了一个抽象层。

  2、库（LIBRARIES）
  包含各种C/C++ 核心库（如libc和SSL），以及：

  • 用来回放音频和视频媒体的媒体库
  • 用来管理显示的外观管理器
  • 包含用于2D和3D图形的SGL和OpenGL 的图形库
  • 用于本地数据库支持的SQLite
  • 用于集成Web浏览器和Internet 安全的SSL和Webkit

  3、Android运行时（ANDROID RUNTIME）
  它是向应用程序提供动力的引擎，它和库 一起形成了应用程序框架的基础。

  • 核心库（Core Libraries）：提供了Java核心库以及Android特定库可用的大部分功能
  • Dalvik虚拟机（Dalvik Virtual Machine）：Dalvik是一个基于寄存器的虚拟机，它已经被优化从而确保一个设备可以高效地运行多个实例。它依赖Linux内核进行线程和底层内存管理。

  4、应用程序框架（APPLICATION FRAMEWORK）
  应用程序框架提供了用来创建Android应用程序的类。它还对硬件访问提供了一般抽象，并管理用户界面和应用程序资源。

  5、应用层（APPLICATIONS）
  所有的应用程序，包括原生的和第三方的，都在应用层上使用相同的库进行构建。
  应用层运行在Android运行时 内，并使用了应用程序框架中可用的类和服务。

相关链接：android平台原理机制

2、Dalvik虚拟机与ART虚拟机

• Dalvik虚拟机
  1、使用设备底层Linux内核来处理基本的功能，包括安全、线程以及进程和内存管理。
  2、可以编写直接运行在底层Linux OS 上的C/C++ 应用程序，但大部分没必要。
  3、Dalvik虚拟机的特点是在运行时才进行编译。
  4、每次运行时，字节码都需要通过即时编译器（JIT, just in time），转换为机器码。这会使得应用程序的效率降低。

• ART虚拟机（Android Runtime）
  1、从Android5.0开始，默认采用ART虚拟机。
  2、在ART中，系统在安装应用时会进行一次预编译（AOT，ahead of time）,将字节码预先编译成机器码并存储在本地，这样应用每次运行时就不需要执行编译了，运行效率也大大提升。

3、Android应用程序框架（APPLICATION FRAMEWORK）

下面的应用程序服务是所有Android应用程序的框架基础，它们提供了常用软件都会使用到的框架：

• Activity Manager 和Fragment Manager：
  分别控制Activity 和Fragment 的生命周期，包括对Activity 栈的管理。
• 视图（View）：
  用来为Activity 和Fragment 构建用户界面。
• Notification Manager（通知管理器）：
  提供了一种一致的和非打断性的机制来通知用户。
• Content Provider（内容提供者）：
  让应用程序可以共享数据。
• Resource Manager（资源管理器） ：
  支持像字符串和图形这样的非代码资源的具体化。
• Intent：
  提供了一种在应用程序及其组件之间传递数据的机制。

等等

4、简述下Android 数字签名

• 总结：
  在Android系统中，所有安装到系统的应用程序都必有一个数字证书，此数字证书用于标识应用程序的作者和在应用程序之间建立信任关系。

• 1、详细说明：
  Android系统要求每一个安装进系统的应用程序都是经过数字证书签名的，数字证书的私钥则保存在程序开发者的手中。Android将数字证书用来标识应用程序的作者和在应用程序之间建立信任关系，不是用来决定最终用户可以安装哪些应用程序。

  这个数字证书并不需要权威的数字证书签名机构认证(CA)，它只是用来让应用程序包自我认证的。

• 2、数字证书的好处：
  同一个开发者的多个程序尽可能使用同一个数字证书，这可以带来以下好处。

  • 有利于程序升级，当新版程序和旧版程序的数字证书相同时，Android系统才会认为这两个程序是同一个程序的不同版本。如果新版程序和旧版程序的数字证书不相同，则Android系统认为他们是不同的程序，并产生冲突，会要求新程序更改包名。

  • 有利于程序的模块化设计和开发。Android系统允许拥有同一个数字签名的程序运行在一个进程中，Android程序会将他们视为同一个程序。所以开发者可以将自己的程序分模块开发，而用户只需要在需要的时候下载适当的模块。

• 3、在签名时，需要考虑数字证书的有效期：

  • 数字证书的有效期要包含程序的预计生命周期，一旦数字证书失效，持有改数字证书的程序将不能正常升级。
  • 如果多个程序使用同一个数字证书，则该数字证书的有效期要包含所有程序的预计生命周期。
  • Android Market强制要求所有应用程序数字证书的有效期要持续到2033年10月22日以后。

• 4、Android数字证书包含以下几个要点：

  • 所有的应用程序都必须有数字证书，Android系统不会安装一个没有数字证书的应用程序
  • Android程序包使用的数字证书可以是自签名的，不需要一个权威的数字证书机构签名认证
  • 如果要正式发布一个Android ，必须使用一个合适的私钥生成的数字证书来给程序签名，而不能使用adt插件或者ant工具生成的调试证书来发布。
  • 数字证书都是有有效期的，Android只是在应用程序安装的时候才会检查证书的有效期。如果程序已经安装在系统中，即使证书过期也不会影响程序的正常功能。

二、Android下的架构模式：

• 架构：
  现在比较流行的项目架构基本都是基于模型（M）和视图（V）分离来说的，一般被定义为MVX的架构模型。
  其中最为常见和应用最广的有三种：MVC、MVP、MVVM。还有最新的MVI架构
  其中MVC是最早被提出的，MVP是MVC的变种。

1、MVC：Model-View-Controller

• 组成：
  Model：模型层，负责数据获取，包含：网络请求，数据库处理，I/O操作等
  View：视图层，对应于 xml 布局文件和 java 代码动态 view 部分
  Controller：控制层，主要负责业务逻辑，Activity既要负责视图又要加入控制逻辑

• 流程：
  通过 View 接受指令，传递给 Controller
  然后对模型进行修改或者查找底层数据
  最后把改动渲染在视图上

  
  
  示意图

• 问题：
  Activity 同时负责 View 与 Controller 层的工作，违背了单一职责原则
  Model 层与 View 层存在耦合，存在互相依赖，违背了最小知识原则

2、MVP：Model-View-Presenter

• 组成：
  Model：模型层，负责数据获取，包含网络请求，数据库处理等操作
  View：视图层，对应于 Activity 与 XML，只负责显示 UI，只与 Presenter 层交互，与Model层没有耦合
  Persenter：控制层，负责处理业务逻辑，通过接口回调 View 层，几乎承担所以逻辑

• 流程：
  View接收交互指令，将指令转交给Presenter
  Presenter操作Model进行数据的请求更新，
  Model更新后，通知Presenter数据变化
  Presenter将更新同步到View进行显示

  
  
  示意图

• 优点：
  Model与View完全分离，修改互不影响
  利用高效，方便重用和变更，所有逻辑都在Presenter
  更便于测试，可脱离用户接口来测试逻辑

• 问题：
  Presenter 层通过接口与 View 通信，实际上持有了 View 的引用
  视图和Presenter的交互会过于频繁，使得他们的联系过于紧密，View接口会过于庞大

3、MVVM：Model-View-ViewModel

• 组成：
  Model：模型层，负责数据获取，包含网络请求，数据库处理等操作
  View：视图层，对应于 Activity 与 XML，只负责显示 UI，与ViewModel层交互
  ViewModel：控制层，采用双向数据绑定，主要通过 DataBinding 来实现

• 特点：
  分离视图（View）和模型（Model），双向绑定，数据驱动视图。
  和MVP基本一致，是将Presenter改名为ViewModel，区别是采用双向绑定，View的变动，自动更新到ViewModel上。

• 流程：
  View接收交互指令，并将指令转交给ViewModel
  ViewModel操作Model进行数据更新
  Model更新后通知ViewModel数据发生变化
  ViewModel将更新同步到View进行显示

  
  
  示意图

• 优点：
  低耦合（View可以独立于Model变化和修改）
  可重用（多view重用视图逻辑）、独立开发互不影响

• 问题：
  为保证对外暴露的 LiveData 是不可变的，需要添加不少模板代码并且容易遗忘
  View 层与 ViewModel 层的交互比较分散零乱，不成体系

4、MVI：Model-View-Intent

• 组成：
  Model：模型层，主要之UI状态（UI State）如页面加载状态，控件位置等都是UI状态
  View：视图层，对应于 Activity 与 XML，负责显示 UI；定于Intent的变化实现界面刷新
  Intent：非Android中的Intent组件，用户操作逻辑包装成Intent发送给Model层进行数据请求

• 特点：
  单向数据流
  数据永远在一个环形结构中单向流动，不能反向流动

• 流程：
  用户操作以 Intent 的形式通知 Model
  Model 基于 Intent 更新 State
  View 接收到 State 变化刷新 UI

  
  
  示意图

5、总结：

• 问题及区别：

• MVC 架构的主要 问题 在于 Activity 承担了 View 与 Controller 两层的职责，同时 View 层与 Model 层存在耦合
• MVP 引入 Presenter 层，解决了 MVC 架构的两个问题，View只能与 Presenter 层交互，业务逻辑放在 Presenter 层
  MVP 的问题 在于随着业务逻辑的增加，View 的接口会很庞大
• MVVM 架构中的ViewModel 相当于MVP的Presenter和MVC的Controller，
  View和ViewModel间没有了MVP的界面接口，而是直接交互，通过数据绑定（可认为是Observer 模式或者是 Publish/Subscribe 模式，原理都是为了用一种统一的集中的方式实现 频繁 需要被实现的数据 更新 问题。）自动双向同步（自动更新到UI上），解决MVP的问题，MVVM 更像是自动化的 MVP
  MVVM 的双向数据绑定主要通过 DataBinding 实现，但如果不用 DataBinding，而是 View 通过 LiveData 等观察 ViewModle 的数据变化并自我更新，这其实是单一数据源而不是双向数据绑定。
• MVI 抢到数据的 单向流动 和 唯一数据源。和MVVM很相似
  主要是为了减少模板代码，以及 View和ViewModel交互的分散问题。

• 个人理解：

架构都是围绕MV即 Model 和 View 来说的，如何更好的处理两者的交互和通信，才出现的各种架构模型，基于Android中视图层（基本是Activity和Fragment）的生命周期在各种场景下的复杂度，处理好M和V两者的关系，就需要根据不同的项目来制定不同的架构模型了。
关注的原则就在于：
1、分离关注点，也可以理解为职责单一，避免和Activity或Fragment的依赖。
2、数据模型驱动页面，最好是持久性模型，数据应独立于应用中的界面元素和组件，和生命周期无关联。最好可以在应用释放资源后，数据不丢失；网络不可用时，可进行工作。

参考链接：
应用架构指南
Google 推荐使用 MVI 架构？卷起来了~
MVVM 进阶版：MVI 架构了解一下~
MVI 架构封装：快速优雅地实现网络请求
MVI 架构更佳实践：支持 LiveData 属性监听