Android定制系统的架构设计思路_android系统制作思路

前言：

文章根据现阶段自身实际工作经验，总结一套Android的系统架构流程，以梳理从业以来对这部分技术的理解。

因为接触的系统定制化都是大屏商显和TV盒子，是基于芯片厂商提供的源码开发，所以本文章是从这方面角度去看待架构设计，若以后能接触到更多的系统定制化内容，再梳理更新文章。

从分层角度看系统结构

下图是Android的系统分层图：
定制系统开发就是源码级开发：基于AOSP（Android Open Source Project）环境的开发工作。主要开发场景为Android系统定制，比如手机设备的MIUI,Flyme，Smartisan OS,基于电视的Leanback，TIF框架，甚至还有针对投影仪，路由器等传统物联设备的Android系统定制开发等等。

下面介绍一下在芯片方案上定制系统通常需要关注的部分：

Hal硬件抽象层

Android系统里封装内核驱动程序的接口层。对上层提供接口，屏蔽底层驱动实现细节，在实际项目中，根据所选的硬件方案，由厂商基于接口去实现硬件功能，而不直接在内核空间实现驱动，这部分的常用定制实现有：WIFI,BLUETOOTH,I2C,触摸方案,功放,光感,GPIO,信号输入输出等等。

Framework层

Framework连接调用核心库的底层方法最终访问到linux内核，提供API供上层调用，包含了服务端、客户端、linux驱动三个部分。

Applications

基于SDK开发，实际上就是对四大组件的具体实现，开发出来的组件套是需要和Framework框架结合在一起才是一个完整的程序。

定制架构设计

基于以上概念以及结合项目需求的经验，下面总结一套定制设计方案：

上图总体框架的分层示意图，分为配置层，核心功能层，一般业务层，三个层级，可以看作是Hal硬件抽象层到Frameworks到Applications的实现，不过并不是完全遵循Android的系统分层，下面会分布详细介绍。

思路：

最终我们需要基于命令模式，来实现一套代码通过命令编译出指定硬件，指定客户及软件功能的固件。有了这个目标，然后从以下几个角度分析：

从团队开发的角度来看：设计时，应当尽量对硬件，驱动，系统，应用的开发解耦，通过封装接口和SDK的方式来连接，以便团队成员更加专注自己的领域，提高排查问题的效率。

从架构对业务的角度来看：设计时，应提供一条主线路，用于核心功能和基础功能的维护和送样展示的目的。当有业务需求时，提供基于主线路的分支，每一个客户对应一个分支，客户的分支上应支持创建自己的分支。借鉴命令模式的思想，以硬件的版本标识+客户的分支标识来汇总一条编译指令，用来拷贝相应的配置文件，编译出对应分支的系统固件

从团队开发人员对业务的角度来看：业务的需求应该独立出来，互不影响，可以提取复合的需求到主线路中，供其他业务开发通用。

实现

基于上面的思路，下面通过进一步拆分框架来描述一下该框架如何实现这些思路：

配置层

build：提供统一的开发工具、签名、编译命令脚本。

config:提供安全策略配置，如selinux等

customization:提供公共和业务相关的配置参数，以及架构中的每一个模块介绍文档。

以上这三个部分作为配置层，用于构成定制部分的整体编译相关的配置，以实现思路中的主线和分支构建需求。

核心功能层

这一层是整个客制化功能实现的核心，包含硬件接口的实现、定制化SDK、核心功能型组件，核心功能APP，原生framew的定制修改。
到这一层基本完成了全部的核心定制内容，并提供第三方SDK供最上层的业务开发使用。需要注意的是，这一层的SDK及应用组件设计，应使用MVC或MVP的思维，实现思路中的解耦需求，以便团队更好的展开工作。（主要是对设计模式和通信机制的运用）

一般业务层

这一层提供非核心的基础功能实现，和实际的业务需求开发，无法访问内部SDK，只能访问开放的通用API，也可以根据实际需求，在外部SDK中添加API，实现思路中的业务独立，互不影响的需求。

总结：

从一开始的简单定制开发，到现在的基于架构的定制开发，能很深刻的体会到架构的重要性，大大提高了输出效率，减少了很多重复的工作，当然现在总结的架构设计并不全面，也许不能适用于更多场景，有不少需要优化的地方，还要在今后的学习和工作中继续完善。