RK与MTK平台system.img大小差异分析与优化

1. 问题背景：RK与MTK平台system.img大小差异

在Android 8.1系统开发过程中，我们发现一个有趣的现象：相同1.5GB分区大小的system.img，Rockchip（RK）平台编译生成的镜像比MediaTek（MTK）平台多占用约350MB存储空间。这个差异在存储资源紧张的嵌入式设备上尤为关键，直接影响OTA更新包大小和系统运行效率。

具体数据对比：

• MTK平台system.img实际占用：1.1GB
• RK平台system.img实际占用：1.4GB（已进行应用裁剪后）

注意：这个差异是在相同Android版本（8.1）、相同分区大小配置下出现的，说明问题根源在于平台特定的编译策略和文件组织方式。

2. 分析工具准备与环境搭建

2.1 安装必要的工具链

在Ubuntu环境下（推荐18.04 LTS及以上版本），需要安装以下工具：

bash复制sudo apt update
sudo apt install -y simg2img e2fsprogs tree ncdu

simg2img用于处理Android的sparse image格式转换，e2fsprogs提供ext4文件系统支持，tree和ncdu则是分析目录结构的利器。

2.2 处理system.img的完整流程

Android系统镜像通常以sparse格式分发，需要转换为raw镜像才能挂载：

bash复制# 转换RK平台镜像
simg2img rk_system.img rk_system_raw.img

# 转换MTK平台镜像
simg2img mtk_system.img mtk_system_raw.img

2.3 挂载镜像的正确姿势

创建挂载点并挂载镜像（需要root权限）：

bash复制# 创建挂载目录
mkdir -p /mnt/{rk_system,mtk_system}

# 挂载RK镜像
mount -o loop,rw rk_system_raw.img /mnt/rk_system

# 挂载MTK镜像
mount -o loop,rw mtk_system_raw.img /mnt/mtk_system

避坑指南：如果在macOS环境下操作会遇到ext4支持问题。建议使用Docker创建Ubuntu容器：

bash复制docker run -it --privileged -v $(pwd):/data ubuntu:18.04

3. 深度差异分析：从宏观到微观

3.1 目录级空间占用对比

使用du命令进行目录大小统计：

bash复制# RK平台分析
du -h --max-depth=1 /mnt/rk_system | sort -hr > rk_size.txt

# MTK平台分析
du -h --max-depth=1 /mnt/mtk_system | sort -hr > mtk_size.txt

关键差异点统计表：

3.2 重点目录的细粒度分析

3.2.1 priv-app差异分析

priv-app存放系统核心应用，使用以下命令深入分析：

bash复制# 生成详细文件列表
find /mnt/rk_system/priv-app -type f -exec du -h {} + | sort -hr > rk_priv_app_detail.txt

发现RK平台多包含以下应用：

• RkVideoPlayer (42MB)
• RkGallery (38MB)
• RkSettings (28MB)

这些是RK定制化的系统应用，虽然可以裁剪但会影响平台特定功能。

3.2.2 framework差异分析

framework目录包含系统框架jar文件，差异主要来自：

bash复制du -h /mnt/rk_system/framework/* | sort -hr

关键发现：

• arm64目录（87MB）：64位架构的framework库
• oat/arm64（39MB）：64位的ART优化文件
• MTK平台完全缺失这些64位支持

3.2.3 lib64目录分析

RK平台独有的lib64目录包含：

• 64位系统库（lib64/*.so）
• 64位硬件抽象层（lib64/hw/*.so）
• 64位厂商闭源库（lib64/egl/*.so）

4. 技术根源：32位与64位的策略差异

4.1 Android的多架构支持机制

Android支持三种ABI（应用二进制接口）：

• armeabi-v7a（32位）
• arm64-v8a（64位）
• x86（Intel兼容）

RK平台默认同时包含32位和64位支持，而MTK选择仅保留32位。这种策略差异体现在：

1. 库文件冗余：

   • RK：/lib（32位） + /lib64（64位）
   • MTK：仅/lib（32位）

2. ART优化文件重复：

   • RK：oat/arm + oat/arm64
   • MTK：仅oat/arm

3. Framework双备份：

   • RK：framework/arm + framework/arm64
   • MTK：仅framework/arm

4.2 平台厂商的编译策略

通过分析build/core/main.mk，发现关键差异点：

makefile复制# RK的TARGET_PREFER_32BIT配置
PRODUCT_PROPERTY_OVERRIDES += ro.zygote=zygote64_32
TARGET_SUPPORTS_64_BIT_APPS := true

# MTK的配置
TARGET_PREFER_32BIT := true
TARGET_SUPPORTS_64_BIT_APPS := false

5. 优化方案与实施建议

5.1 方案一：移除64位支持（推荐）

修改device/rockchip/common/BoardConfig.mk：

makefile复制# 强制32位模式
TARGET_PREFER_32BIT := true
TARGET_SUPPORTS_64_BIT_APPS := false

# 禁用64位 zygote
PRODUCT_PROPERTY_OVERRIDES += ro.zygote=zygote32

预期效果：

• 删除/lib64目录（节省166MB）
• 删除framework/arm64（节省87MB）
• 删除oat/arm64（节省39MB）
• 总计节省：292MB

5.2 方案二：应用裁剪（辅助方案）

在device/rockchip/common/device.mk中移除非必要应用：

makefile复制# 移除预装应用
PRODUCT_PACKAGES := \
    $(filter-out RkVideoPlayer RkGallery, \
    $(PRODUCT_PACKAGES))

预期效果：

• 最大可节省约100MB
• 可能影响平台特定功能

5.3 混合方案实施步骤

1. 修改BoardConfig.mk配置
2. 执行完整编译：

bash复制make clean
source build/envsetup.sh
lunch rk3328-eng
make -j8

3. 验证修改效果：

bash复制# 检查lib64是否存在
ls out/target/product/rk3328/system/lib64

# 检查zygote模式
adb shell getprop ro.zygote

6. 验证与效果评估

6.1 编译结果对比

优化前后数据对比表：

6.2 兼容性测试要点

1. 应用兼容性测试：

   bash复制adb install --abi armeabi-v7a test.apk
   

2. 性能基准测试：

   bash复制adb shell am start -n com.futuremark.dmandroid/.activity.DMAndroidActivity
   

3. 稳定性测试：

   bash复制adb shell monkey -p your.package -v 10000
   

7. 深入技术探讨：为什么MTK选择32位？

通过与MTK工程师交流，了解到他们的策略基于：

1. 目标设备定位：主要面向低端设备，内存通常≤2GB
2. 性能权衡：32位代码在Cortex-A7上效率更高
3. 存储优化：减少OTA更新包大小
4. 生态现状：2018年时多数应用仍以32位为主

8. 扩展思考：Android 64位化的趋势

虽然本文建议移除64位支持来节省空间，但需要注意：

1. Google Play从2019年起要求新应用必须支持64位
2. Android 12+开始逐步淘汰32位支持
3. 64位在AArch64处理器上有明显性能优势

因此，对于新项目建议：

• 高端设备：保留完整64位支持
• 低端设备：采用本文优化方案
• 过渡方案：使用TARGET_PREFER_32BIT但保留64位能力