SharedPreference不一样的封装

SharedPreference是android常用的轻量级存储方式,使用非常方便,常用来保存app的一些配置值.

但是SharedPreference的效率并不高.

SharedPreferences mSp = context.getSharedPreferences(fileName,MODE_PRIVATE);
mSp.getInt(KEY_2,DEFAULT);
mSp.getInt(KEY_1,DEFAULT);

很多app在启动过程中都会去SharedPreference中读取配置值,如上面两行代码.第一行代码执行时间为0-1毫秒忽略不计,第三行代码执行时间也为0-1毫秒,忽略不计.

但是第二行代码,也就是第一次读取SharedPreference的执行时间与文件中存储的条目数有关.

//存储简单数据
100条    10毫秒
1000条   60毫秒
10000条  200毫秒

这数据是手机运行状态良好,并且存储简单数据的时候获取的,如果手机运行状态差,存储复杂的数据,这个时间只会更长(复杂数据是指xml需要转义的数据).

不过一般情况,一个SharedPreference文件不会存这么多数据.但是一个老项目,四五年的发版更新,经过不知道多少人维护,可能就会出现这种情况了.这也许就是为什么安卓越用越卡的一个原因!!!!

解决这个问题很简单:

  • 历史版本存储的数据该删的就删

需要对历史版本进行不同处理,从逻辑上就类似数据库的升级了.所以模仿数据库升级对SharedPreference进行封装.示例如下:

public class Config {

public static final int VERSION = 2;
private static Config sInstance;
private SharedPreferences mSp;

private Config(Context context) {
    mSp = context.getSharedPreferences(FILE_NAME, Context.MODE_PRIVATE);
    checkUpdate();
}

public static Config getInstance(Context context) {
    if (sInstance == null) {
        synchronized (Config.class) {
            if (sInstance == null) {
                sInstance = new Config(context);
            }
        }
    }
    return sInstance;
}

private void checkUpdate() {
    int oldVersion = mSp.getInt(KEY_VERSION,VERSION);
    if(oldVersion < VERSION){
        onUpgrade(oldVersion, VERSION);
    }
}

private void onUpgrade(int oldVersion, int newVersion) {
    switch (oldVersion) {
        case 1:
            //do something update SharedPreferences 1 > 2
        case 2:
            //do something update SharedPreferences 2 > 3
        case 3:
            //do something update SharedPreferences 3 > 4
        case 4:
            //do something update SharedPreferences 4 > 5
        case 5:
            //do something update SharedPreferences 5 > 6

        ...

        default:
            break;
    }
}
}

参考:

赞赏还是要有的QAQ
100斤 WeChat Pay

微信打赏

100斤 Alipay

支付宝打赏