google低存储方案设计(略微修改)

一.概述

  当手机剩余存储过低时系统可能会无存储可用,从而导致系统崩溃或无法开机问题。为了解决这类问题我们制定了一套低存储方案,引导用户清理垃圾腾出存储空间,和预留空间给系统应用使用,降低存储导致的系统崩溃或无法开机的问题。该方案主要从应用,Framework,文件系统层三层来深入展开。应用层,这一层主要是清理应用中的垃圾。Framework层,这层主要是给应用提供数据支撑,和情非得以的情况下删除一下应用的下载文件等。文件系统层,这一层是我们的最后防线,它主要是提供了128M的预留空间给系统关键进程使用。

二.整体框架

  整体框架由应用层,Framework层,文件系统层这三层组成,每层的分工不一样,应用层主要帮助用户清理垃圾,Framework层为应用层和用户提供通知,文件系统层为系统重要进程提供能使用的预留空间。
我们针对存储空间不足进行了分级,划分为3级,每级对应不同的策略:
1.剩余存储较低(小于1G),发出系统通知,温和提示用户清理垃圾
2.严重低(小于500M),弹出对话框,警告用户清理垃圾
3.危险(小于100M),直接进入清理页面,只有清理垃圾并恢复至非危险状态才可退出此页面

三.应用层

应用层,这一层主要是提醒引导用户清理垃圾,帮忙手机腾出存储空间,从而降低存储导致低导致系统崩溃的情况。应用主要负责的事情是清理应用缓存,垃圾文件,安装包,卸载残留。

四.框架层

Framework层,这一层主要是提醒用户手机存储空间不足,需要清理垃圾,并且启动应用程序来清理垃圾。存储监控的逻辑主要实现是在DeviceStorageMonitorService,监控逻辑如下图:

DeviceStorageMonitorService中会每隔一分钟读一次当前的存储情况然后根据不同的等级做不同的处理:
1.如果存储等级等于一,并且和上次等级不一样,那么会发送等级一的通知,用户点击通知后会弹出垃圾清理应用。
2.如果存储等级等于二,并且和上次等级不一样,那么会发送等级二的通知,并且会弹出垃圾清理提示框,这时候无论用户点击通知栏的消息还是垃圾清理提示框都会弹出垃圾清理应用。
3.如果存储等级等于三,并且和上次等级不一样,那么会发出等级三的通知,并且直接弹出手机瘦身让用户清理垃圾,这时候点击通知栏的消息弹出的也会是手机瘦身。
当处于第三等级的时候每此解锁手机都会弹出手机瘦身,提示用户清理垃圾,主要逻辑如下:

当DeviceStorageMonitorService接收到解锁广播后,会判断一下当前的等级是不是第二级,如果是的话会判断这个广播是不是解锁广播,如果是的话会再次读取现在的存储等级 如果是第三等级的情况下会弹出手机瘦身,让用户清理垃圾。

五.文件系统层

    文件系统层是我们的最后一层防护了,这一层主要是预留了128M的存储空间,一般进程无法使用,在O上只有配置了ACCESS_REVERSED_DISK权限的进程才能够使用这预留的存储空间,目前在小米机器上有Zygote,system_server,SystemUI配置了该权限。具体实现原理:
首先在fstab文件中声明要预留的存储空间是多少,例如这里声明的是128M
/dev/block/bootdevice/by-name/userdata   /data              ext4   nosuid,nodev,barrier=1,noauto_da_alloc,discard   wait,check,reservedsize=128M,fileencryption=ice
然后在fs_mgr_fstab.c中的parse_flags方法中会去解析定义好的预留空间大小,详细代码如下:
{ "reservedsize=", MF_RESERVEDSIZE },
} else if ((fl[i].flag == MF_RESERVEDSIZE) && flag_vals) {
/* The reserved flag is followed by an = and the
* reserved size of the partition. Get it and return it.
*/
flag_vals->reserved_size = parse_size(strchr(p, '=') + 1);
}
接着:
//reserved_blocks大小就是128M
snprintf(buf, sizeof (buf), "-r %lu", reserved_blocks);
char *tune2fs_argv[] = {
TUNE2FS_BIN, //system/bin/tune2fs
buf, //预留大小
blk_device, //对应data块
};
ret = android_fork_execvp_ext(ARRAY_SIZE(tune2fs_argv), tune2fs_argv,
&status, true, LOG_KLOG | LOG_FILE,
true, NULL, NULL, 0);
这里通过tune2fs命令来修改了保留块的大小。然后配置了CAP_SYS_RESOURCE权限的进程可以使用该保留块(N的机型)。因为O上android o system.te 文件中限制了capability sys_resource权限:neverallow system_server system_server:capability sys_resource,所以system_server在O上会被阻止对sys_resource的访问,这个配置CAP_SYS_RESOURCE权限的方案在O上失效了。最后我们根据GOOGLE的建议:用resuid, resgid的方式可以绕开selinux权限,访问分区预留空间。我们在允许拥有ACCESS_REVERSED_DISK权限的进程访问这个保留块。

六.总结

    这套低存储方案由应用,Frameork,文件系统这三层全面保障系统拥有良好的剩余存储环境。我们经过层层防护也减少了大量因为没有存储导致的系统崩溃以及无法开机问题,并且大大减少了工程师重复分析问题的时间,提高了很多工作效率。

猜你喜欢

转载自blog.csdn.net/aa787282301/article/details/84820847