android架构拆分方案-结构相关方案与技术-创新互联
上上android架构拆分思想https://blog.csdn.net/dongyi1988/article/details/128617738
上文编译拆分https://blog.csdn.net/dongyi1988/article/details/128629011
android如此大系统，结构上有一些耦合依赖比较严重的模块，需要设计解耦方案。
android架构官网地址https://source.android.google.cn/docs/core/architecture?hl=zh-cn
规范统一HIDL/AIDL接口https://source.android.google.cn/docs/core/architecture/hidl?hl=zh_cn
boot变更follow https://blog.csdn.net/dongyi1988/article/details/103994321可知boot包含kernel，ramdisk，dtb三大部分，以及参数cmdline；
Boot Image Header的版本变化可以看到boot内容的变更
https://source.android.google.cn/docs/core/architecture/bootloader/boot-image-header
android R涉及boot改动内容太多，将启新blog详细介绍。
GKI（通用内核镜像）https://source.android.google.cn/docs/core/architecture/kernel?hl=zh-cn
DTB&DTBO（设备树&设备树叠加层）https://source.android.google.cn/docs/core/architecture/dto/partitions
https://blog.csdn.net/dongyi1988/article/details/103995862 2、多设备树叠加层合入(dtbo)
ko模块（linux动态加载模块）https://www.bbsmax.com/A/Ae5RN42r5Q/
DLKM 分区,动态加载模块分区https://source.android.google.cn/docs/core/architecture/partitions/vendor-odm-dlkm-partition
ODM、product、version编译这几个镜像是集合到super里面的sparse格式压缩镜像，原格式一般是文件系统格式，开机时直接挂载使用。
查编译日志，编译mk文件可以看到编译规则。
GSI（通用系统镜像）https://developer.android.google.cn/codelabs/using-android-q-gsi#0
https://source.android.google.cn/docs/setup/build/gsi
vendor（平台仓）高通和MTK开始分仓了，肯定会用到VNDK，具体细节查看源码。
VNDK（The Vendor Native Development Kit）google官网https://source.android.google.cn/docs/core/architecture/vndk
使用方式参考官网或源代码。
技术扩展 开机logo自适应方案https://blog.csdn.net/dongyi1988/article/details/103995862 1、多开机画面适配
SELinuxSELinux 也有域的概念、system与vendor域添加位置不同，启动加载不同https://source.android.google.cn/docs/security/features/selinux/vendor-init?hl=zh-cn
https://blog.csdn.net/dongyi1988/article/details/103994152日志种多次加载SELinux文件规则也是受开机流程影响，第一次load rootfs的policy，第二次load system的policy，第三次 load vendor的policy。
OverlayfsOverlayfs是一种类似aufs的一种堆叠文件系统,
https://blog.csdn.net/qq_15770331/article/details/96699386
域的实现下面6个域所用镜像与剥离用到的技术（除拆包、打包、仓库管理、签名外）如下：
system系统域，主要system.img，用VNDK与其它域拆分，等效于GSI，注意system域的SELinux；
vendor芯片域，分vendor.img和boot.img，
vendor.img需要VNDK与其它域拆分，可利用芯片厂商的vendor仓隔离，注意vendor域的SELinux，
boot.img需要动态库、设备树与设备树叠加、boot镜像打包等技术，等效于GKI，注意boot的启动流程与boot域的SELinux；
device设备域，分dtbo.img、ko动态库、硬件固件、硬件相关配置文件
dtbo.img需要设备树与设备树叠加技术，注意android源码是支持多设备叠加层merge的（https://blog.csdn.net/dongyi1988/article/details/103995862 第2节）
ko动态库与硬件相关配置文件可以存储在odm.img，通过cmdline适配加载，注意这个跨域（域看你的理解与划分，odm域的固件、配置文件和硬件配置部分可划给device域）；
odm厂商域，主要odm.img，里面内容包括app、配置文件、固件等；
product产品域，主要product.img，里面内容包括app、配置文件等；
version版本域，主要version.img，里面二进制存放加密的设备信息，利用设备信息启动过程中进行版本的自适应，设备信息可以包括使用哪些硬件、选择什么logo、overlayfs堆叠选择等；
https://source.android.google.cn/docs/core/architecture/partitions?hl=zh_cn
android官网系统分区布局，将系统的差异化定制为system_ext。
满足差异性需求也可以用自适应。碰到过自适应到极致的方案，这个方案用一个OTA包升级所有产品。这个方案兼容代码量、OTA的冗余不敢想。
Modem、安全、稳定性等拆分解耦没涉及，实际拆起来还有不少问题要解决。
拆分解耦没有定式，例如域拆分有多细，差异怎么划域、哪些差异需求自适应、哪些差异内容拆分做版本等问题，均有不同答案。带着绝不做重复事情的懒惰思想去拆分解耦，就是最适合自己的方式。
拆分解耦虽然是google和芯片平台方案商都在干的，也是厂商为了产品的多样性、技术迭代成长必须要做的，但是只看得到眼前的只有几个产品的小厂商不认为有性价比。因为拆分解耦会多出拆分任务，并且需要架构的合理规划。
拆分虽然好，但是老板不听话啊。
这种拆分解耦思想也可以应用到非终端、非android的项目。
The end!
你是否还在寻找稳定的海外服务器提供商？创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源，准确流量调度确保服务器高可用性，企业级服务器适合批量采购，新人活动首月15元起，快前往官网查看详情吧
网页标题：android架构拆分方案-结构相关方案与技术-创新互联
网站链接：http://pwwzsj.com/article/jdppd.html
