Android系统镜像优化：RK与MTK平台差异分析与实践

1. 问题现象与背景分析

最近在对比RK（瑞芯微）和MTK（联发科）两个平台的Android系统镜像时，发现一个有趣的现象：同样的代码基线编译出来的system.img，RK平台比MTK平台大了约350MB。这个差异已经超出了正常的波动范围，引起了我的注意。

作为一名长期从事Android系统开发的工程师，我深知system.img的大小直接影响OTA升级包体积、设备存储空间占用等关键指标。特别是在资源受限的嵌入式设备上，每一MB的存储空间都弥足珍贵。于是决定深入探究这个现象背后的原因。

初步排查发现，两个平台使用的都是AOSP同一分支代码（如android-13.0.0_r41），编译配置也保持一致（eng/userdebug）。硬件差异方面，RK3588和MT8186都是ARMv8架构的SoC，指令集兼容性没有问题。那么问题可能出在平台相关的配置或工具链处理上。

2. 镜像组成结构解析

2.1 system.img的构建过程

要理解镜像大小差异，首先需要了解system.img的生成流程。在Android编译系统中：

1. 代码编译阶段：将Java/Kotlin代码编译为dex文件，C/C++代码编译为so/a文件
2. 资源打包阶段：生成APK、资源文件等
3. 镜像组装阶段：使用build_image.py脚本将上述内容打包为system.img

关键点在于，最终的system.img大小主要由以下因素决定：

• 预装APK的数量和体积
• 原生库（.so文件）的大小
• 系统配置文件的数量
• 文件系统类型（ext4/erofs）和块大小设置
• 平台特定的二进制文件和驱动

2.2 对比分析方法论

为了准确定位差异来源，我采用了以下对比方法：

1. 解压两个平台的system.img：

   bash复制simg2img system.img system.raw.img
   mkdir system && mount -o loop system.raw.img system
   

2. 使用磁盘分析工具对比目录结构：

   bash复制tree -d -L 3 > tree.txt
   du -sh * | sort -h
   

3. 重点对比以下目录：

   • /system/app
   • /system/priv-app
   • /system/lib(64)
   • /system/vendor
   • /system/etc

3. 差异点定位与验证

3.1 预装应用差异分析

通过对比发现，RK平台在/system/priv-app下多出了以下应用：

• RKUpdateService (约45MB)
• RKSettings (约32MB)
• RKVideoPlayer (约28MB)

这些是瑞芯微提供的定制系统应用，用于平台特有功能（如芯片级OTA更新、视频硬解配置等）。而MTK平台对应的实现已经集成到AOSP标准组件中。

提示：平台定制应用虽然提供了更好的硬件适配，但也会增加镜像体积。建议评估是否真的需要这些功能。

3.2 原生库体积对比

在/system/lib64目录下，RK平台有几个显著的体积差异点：

1. 图形处理相关库：

   • librga.so (RK独有，约18MB)
   • libGLES_mali.so (MTK为12MB，RK版本为21MB)

2. 多媒体编解码库：

   • librockchip_mpp.so (约25MB)
   • libmtk_mpp.so (约15MB)

3. AI加速库：

   • librknn_runtime.so (RK独有，约32MB)

这些差异主要源于两家芯片厂商对不同硬件模块的驱动实现方式不同。RK倾向于提供功能更全面的独立库，而MTK更多复用AOSP标准组件。

3.3 配置文件差异

在/system/etc目录下，RK平台多了以下内容：

• 多个XML格式的硬件配置描述文件（约8MB）
• 预置的DRM证书和密钥（约12MB）
• 平台特定的音频策略配置（约5MB）

这部分差异相对较小，但累计也有约25MB。

4. 深度技术原因探究

4.1 编译系统差异

通过分析build目录下的中间文件，发现RK的编译系统有以下特点：

1. 默认开启了更多编译选项：

   makefile复制# RK的BoardConfig.mk
   BOARD_WITH_EXTRA_MODULES := true
   BOARD_INCLUDE_RECOVERY_DTBO := true
   

2. 对PRODUCT_PACKAGES的扩展更激进：

   makefile复制PRODUCT_PACKAGES += \
       RKSettings \
       RKUpdateService
   

而MTK的配置相对保守，更依赖AOSP默认值。

4.2 文件系统参数设置

查看镜像生成日志发现，RK平台使用了更大的inode数量和块大小：

code复制# RK
mkfs.ext4 -b 4096 -I 256 -i 8192

# MTK 
mkfs.ext4 -b 2048 -I 128 -i 16384

这种设置虽然能提升大文件性能，但也会增加约5%的镜像体积。

4.3 符号调试信息保留

使用readelf检查so文件发现，RK版本的库文件中保留了更多调试符号：

bash复制readelf -S librga.so | grep debug

这会导致库文件体积增大10-15%。虽然正式发布时可以strip掉，但默认编译配置保留了这些信息。

5. 优化方案与实践

基于以上分析，可以采取以下措施缩减RK平台的system.img体积：

5.1 精简预装应用

1. 评估定制应用的必要性：

   makefile复制# 在device/rockchip/rk3588/device.mk中注释掉非必要应用
   # PRODUCT_PACKAGES -= RKSettings
   

2. 使用更轻量的替代方案：

   makefile复制PRODUCT_PACKAGES += \
       ExactCalculator \
       SimpleGallery
   

5.2 优化库文件编译

1. 移除调试符号：

   makefile复制PRODUCT_MINIMIZE_JAVA_DEBUG_INFO := true
   STRIP_MODULE := true
   

2. 启用LTO（链接时优化）：

   makefile复制BOARD_LTO_ENABLE := true
   

3. 选择更优化的编译flags：

   makefile复制TARGET_OPTIMIZATION := -Os
   

5.3 文件系统优化

1. 调整ext4参数：

   makefile复制BOARD_SYSTEMIMAGE_FILE_SYSTEM_TYPE := ext4
   BOARD_SYSTEMIMAGE_EXTFS_INODE_COUNT := 16384
   BOARD_SYSTEMIMAGE_EXTFS_BLOCK_SIZE := 2048
   

2. 考虑使用erofs：

   makefile复制BOARD_SYSTEMIMAGE_FILE_SYSTEM_TYPE := erofs
   BOARD_EROFS_COMPRESSOR := lz4hc
   

5.4 实测优化效果

经过上述调整后，重新编译得到的system.img体积对比：

6. 经验总结与避坑指南

在实际优化过程中，我总结了以下几点经验：

1. 平台特性评估：不要盲目移除平台厂商提供的组件，特别是涉及硬件加速的部分。例如RKUpdateService虽然增加了体积，但提供了芯片级的OTA验证机制。

2. 兼容性测试要点：

   • 移除库文件后务必测试硬件加速功能
   • 修改文件系统参数需要验证启动速度
   • 精简预装应用要检查系统功能完整性

3. 常用分析工具链：

   bash复制# 分析so文件依赖
   readelf -d libname.so
   
   # 查看APK内容
   apktool d app.apk
   
   # 分析磁盘占用
   ncdu -x /
   

4. 常见误区警示：

   • 直接删除/vendor目录下的文件（会导致硬件失效）
   • 过度压缩图片资源（影响显示效果）
   • 关闭所有调试信息（增加问题排查难度）

5. 持续优化建议：

   makefile复制# 定期清理废弃的overlay配置
   PRODUCT_ENFORCE_RRO_TARGETS := *
   
   # 启用APK瘦身
   PRODUCT_MINIMIZE_APK_SIZE := true
   

通过这次深入分析，不仅解决了RK平台镜像过大的问题，更重要的是建立了一套系统性的分析方法。不同芯片平台的设计哲学差异会体现在最终的系统镜像中，理解这些差异有助于我们做出更合理的定制决策。