前言：
文章根據現階段自身實際工作經驗，總結一套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，實作思路中的業務獨立，互不影響的需求。
總結：
從一開始的簡單定制開發，到現在的基于架構的定制開發，能很深刻的體會到架構的重要性，大大提高了輸出效率，減少了很多重複的工作，當然現在總結的架構設計并不全面，也許不能适用于更多場景，有不少需要優化的地方，還要在今後的學習和工作中繼續完善。