乐趣区

关于android:Android源码进阶之深入理解SharedPreference原理机制

作者：

jiezi

在

一、SharedPreferences简略应用

1、创立

第一个参数是贮存的xml文件名称，第二个是打开方式，个别就用

Context.MODE_PRIVATE；
SharedPreferences sp=context.getSharedPreferences("名称", Context.MODE_PRIVATE);

2、写入

//能够创立一个新的SharedPreference来对贮存的文件进行操作
SharedPreferences sp=context.getSharedPreferences("名称", Context.MODE_PRIVATE);
//像SharedPreference中写入数据须要应用Editor
SharedPreference.Editor editor = sp.edit();
//相似键值对
editor.putString("name", "string");
editor.putInt("age", 0);
editor.putBoolean("read", true);
//editor.apply();
editor.commit();
  • apply和commit都是提交保留，区别在于apply是异步执行的，不须要期待。不管删除，批改，减少都必须调用apply或者commit提交保留；
  • 对于更新：如果曾经插入的key曾经存在。那么将更新原来的key；
  • 应用程序一旦卸载，SharedPreference也会被删除；

3、读取

SharedPreference sp=context.getSharedPreferences("名称", Context.MODE_PRIVATE);
//第一个参数是键名，第二个是默认值
String name=sp.getString("name", "暂无");
int age=sp.getInt("age", 0);
boolean read=sp.getBoolean("isRead", false);

4、检索

SharedPreferences sp=context.getSharedPreferences("名称", Context.MODE_PRIVATE);
//查看以后键是否存在
boolean isContains=sp.contains("key");
//应用getAll能够返回所有可用的键值
//Map<String,?> allMaps=sp.getAll();

5、删除

当咱们要革除SharedPreferences中的数据的时候肯定要先clear()、再commit()，不能间接删除xml文件；

SharedPreference sp=getSharedPreferences("名称", Context.MODE_PRIVATE);
SharedPrefence.Editor editor=sp.edit();
editor.clear();
editor.commit();
  • getSharedPreference() 不会生成文件，这个大家都晓得；
  • 删除掉文件后，再次执行commit()，删除的文件会新生，新生文件的数据和删除之前的数据雷同；
  • 删除掉文件后，程序在没有齐全退出进行运行的状况下，Preferences对象所存储的内容是不变的，尽管文件没有了，但数据仍然存在；程序齐全退出进行之后，数据才会失落；

  • 革除SharedPreferences数据肯定要执行editor.clear()，editor.commit()，不能只是简略的删除文件，这也就是最初的论断，须要留神的中央

    二、SharedPreferences源码剖析

1、创立

SharedPreferences preferences = getSharedPreferences("test", Context.MODE_PRIVATE);

实际上context的真正实现类是ContextImp，所以进入到ContextImp的getSharedPreferences办法查看：

@Override
    public SharedPreferences getSharedPreferences(String name, int mode) {
        ......
        File file;
        synchronized (ContextImpl.class) {
            if (mSharedPrefsPaths == null) {
            //定义类型：ArrayMap<String, File> mSharedPrefsPaths;
                mSharedPrefsPaths = new ArrayMap<>();
            }
            //从mSharedPrefsPaths中是否可能失去file文件
            file = mSharedPrefsPaths.get(name);
            if (file == null) {//如果文件为null
            //就创立file文件
                file = getSharedPreferencesPath(name);
                将name，file键值对存入汇合中
                mSharedPrefsPaths.put(name, file);
            }
        }
        return getSharedPreferences(file, mode);
    }

ArrayMap<String, File> mSharedPrefsPaths;对象是用来存储SharedPreference文件名称和对应的门路，获取门路是在下列办法中，就是获取data/data/包名/shared_prefs/目录下的

@Override
public File getSharedPreferencesPath(String name) {
    return makeFilename(getPreferencesDir(), name + ".xml");
}
private File getPreferencesDir() {
        synchronized (mSync) {
            if (mPreferencesDir == null) {
                mPreferencesDir = new File(getDataDir(), "shared_prefs");
            }
            return ensurePrivateDirExists(mPreferencesDir);
        }
}

门路之后才开始创建对象

@Override
    public SharedPreferences getSharedPreferences(File file, int mode) {
    //重点1
        checkMode(mode);
    .......
        SharedPreferencesImpl sp;
        synchronized (ContextImpl.class) {
        //获取缓存对象（或者创立缓存对象）
            final ArrayMap<File, SharedPreferencesImpl> cache = getSharedPreferencesCacheLocked();
            //通过键file从缓存对象中获取Sp对象
            sp = cache.get(file);
            //如果是null，就阐明缓存中还没后该文件的sp对象
            if (sp == null) {
            //重点2：从磁盘读取文件
                sp = new SharedPreferencesImpl(file, mode);
                //增加到内存中
                cache.put(file, sp);
                //返回sp
                return sp;
            }
        }
        //如果设置为MODE_MULTI_PROCESS模式，那么将执行SP的startReloadIfChangedUnexpectedly办法。
        if ((mode & Context.MODE_MULTI_PROCESS) != 0 ||
            getApplicationInfo().targetSdkVersion < android.os.Build.VERSION_CODES.HONEYCOMB) {
            sp.startReloadIfChangedUnexpectedly();
        }
        return sp;
    }

就是重载之前的办法，只是入参由文件名改为File了，给创立过程加锁了synchronized ，通过办法getSharedPreferencesCacheLocked()获取零碎中存储的所有包名以及对应的文件，这就是每个sp文件只有一个对应的SharedPreferencesImpl实现对象起因

流程：

  • 获取缓存区，从缓存区中获取数据，看是否存在sp对象，如果存在就间接返回
  • 如果不存在，那么就从磁盘获取数据，
  • 从磁盘获取的数据之后，增加到内存中，
  • 返回sp；

getSharedPreferencesCacheLocked

private ArrayMap<File, SharedPreferencesImpl> getSharedPreferencesCacheLocked() {
        if (sSharedPrefsCache == null) {
            sSharedPrefsCache = new ArrayMap<>();
        }
        final String packageName = getPackageName();
        ArrayMap<File, SharedPreferencesImpl> packagePrefs = sSharedPrefsCache.get(packageName);
        if (packagePrefs == null) {
            packagePrefs = new ArrayMap<>();
            sSharedPrefsCache.put(packageName, packagePrefs);
        }
        return packagePrefs;
    }
  • getSharedPreferences(File file, int mode)办法中，从下面的零碎缓存中分局File获取- SharedPreferencesImpl对象，如果之前没有应用过，就须要创立一个对象了，通过办法checkMode(mode);
  • 先查看mode是否是三种模式，而后通过sp = new SharedPreferencesImpl(file, mode);

  • 创建对象，并将创立的对象放到零碎的packagePrefs中，不便当前间接获取；

    SharedPreferencesImpl(File file, int mode) {
      mFile = file; //存储文件
      //备份文件（灾备文件）
      mBackupFile = makeBackupFile(file);
      //模式
      mMode = mode;
      //是否加载过了
      mLoaded = false;
      // 存储文件内的键值对信息
      mMap = null;
      //从名字能够晓得是：开始加载数据从磁盘
      startLoadFromDisk();
  }
  • 次要是设置了几个参数，mFile 是原始文件；mBackupFile 是后缀.bak的备份文件；
  • mLoaded标识是否正在加载批改文件；
  • mMap用来存储sp文件中的数据，存储时候也是键值对模式，获取时候也是通过这个获取，这就是示意每次应用sp的时候，都是将数据写入内存，也就是sp数据存储数据快的起因，所以sp文件不能存储大量数据，否则执行时候很容易会导致OOM；
  • mThrowable加载文件时候报的谬误；
  • 上面就是加载数据的办法startLoadFromDisk();从sp文件中加载数据到mMap中

2、startLoadFromDisk()


 private void startLoadFromDisk() {
        synchronized (mLock) {
            mLoaded = false;
        }
        //开启子线程加载磁盘数据
        new Thread("SharedPreferencesImpl-load") {
            public void run() {
                loadFromDisk();
            }
        }.start();
    }
    private void loadFromDisk() {
        synchronized (mLock) {
        //如果加载过了 间接返回
            if (mLoaded) {
                return;
            }
            //备份文件是否存在，
            if (mBackupFile.exists()) {
            //删除file原文件
                mFile.delete();
                //将备份文件命名为：xml文件
                mBackupFile.renameTo(mFile);
            }
        }
        .......
        Map map = null;
        StructStat stat = null;
        try {
        //上面的就是读取数据
            stat = Os.stat(mFile.getPath());
            if (mFile.canRead()) {
                BufferedInputStream str = null;
                try {
                    str = new BufferedInputStream(
                            new FileInputStream(mFile), 16*1024);
                    map = XmlUtils.readMapXml(str);
                } catch (Exception e) {
                    Log.w(TAG, "Cannot read " + mFile.getAbsolutePath(), e);
                } finally {
                    IoUtils.closeQuietly(str);
                }
            }
        } catch (ErrnoException e) {
            /* ignore */
        }
        synchronized (mLock) {
        //曾经加载结束，
            mLoaded = true;
            //数据不是null
            if (map != null) {
            //将map赋值给全局的存储文件键值对的mMap对象
                mMap = map;
                //更新内存的批改工夫以及文件大小
                mStatTimestamp = stat.st_mtime;
                mStatSize = stat.st_size;
            } else {
                mMap = new HashMap<>();
            }
            //重点：唤醒所有以mLock锁的期待线程
            mLock.notifyAll();
        }
    }
  • 首先判断备份文件是否存在，如果存在，就更该备份文件的后缀名；接着就开始读取数据，而后将读取的数据赋值给全局变量存储文件键值对的mMap对象，并且更新批改工夫以及文件大小变量；
  • 唤醒所有以mLock为锁的期待线程；
  • 到此为止，初始化SP对象就算实现了，其实能够看进去就是一个二级缓存流程：磁盘到内存；

3、get获取SP中的键值对

@Nullable
    public String getString(String key, @Nullable String defValue) {
        synchronized (mLock) { 锁判断
            awaitLoadedLocked(); //期待机制
            String v = (String)mMap.get(key); //从键值对中获取数据
            return v != null ? v : defValue;
        }
    }
 private void awaitLoadedLocked() {
        .......
        while (!mLoaded) { //在加载数据结束的时候，值为true
            try {
            //线程期待
                mLock.wait();
            } catch (InterruptedException unused) {
            }
        }
    }

如果数据没有加载结束（也就是说mLoaded=false），此时将线程期待；

4、putXXX以及apply源码


public Editor edit() {
        //跟getXXX原理一样
        synchronized (mLock) {
            awaitLoadedLocked();
        }
        //返回EditorImp对象
        return new EditorImpl();
    }
 public Editor putBoolean(String key, boolean value) {
      synchronized (mLock) {
           mModified.put(key, value);
           return this;
         }
 }
       public void apply() {
            final long startTime = System.currentTimeMillis();
            //依据名字能够晓得：提交数据到内存
            final MemoryCommitResult mcr = commitToMemory();
           ........
//提交数据到磁盘中
            SharedPreferencesImpl.this.enqueueDiskWrite(mcr, postWriteRunnable);
            //重点：调用listener
            notifyListeners(mcr);
        }
  • 先执行了commitToMemory，提交数据到内存；而后提交数据到磁盘中；
  • 紧接着调用了listener；

5、commitToMemory


private MemoryCommitResult commitToMemory() {
            long memoryStateGeneration;
            List<String> keysModified = null;
            Set<OnSharedPreferenceChangeListener> listeners = null;
            //写到磁盘的数据汇合
            Map<String, Object> mapToWriteToDisk;
            synchronized (SharedPreferencesImpl.this.mLock) {
                if (mDiskWritesInFlight > 0) {
                    mMap = new HashMap<String, Object>(mMap);
                }
                //赋值此时缓存汇合给mapToWriteToDisk 
                mapToWriteToDisk = mMap;
                .......
                synchronized (mLock) {
                    boolean changesMade = false;
                    //重点：是否清空数据
                    if (mClear) {
                        if (!mMap.isEmpty()) {
                            changesMade = true;
                            //清空缓存中键值对信息
                            mMap.clear();
                        }
                        mClear = false;
                    }
                    //循环mModified，将mModified中的数据更新到mMap中
                    for (Map.Entry<String, Object> e : mModified.entrySet()) {
                        String k = e.getKey();
                        Object v = e.getValue();
                        // "this" is the magic value for a removal mutation. In addition,
                        // setting a value to "null" for a given key is specified to be
                        // equivalent to calling remove on that key.
                        if (v == this || v == null) {
                            if (!mMap.containsKey(k)) {
                                continue;
                            }
                            mMap.remove(k);
                        } else {
                            if (mMap.containsKey(k)) {
                                Object existingValue = mMap.get(k);
                                if (existingValue != null && existingValue.equals(v)) {
                                    continue;
                                }
                            }
                            //留神：此时把键值对信息写入到了缓存汇合中
                            mMap.put(k, v);
                        }
.........
                    }
                    //清空长期汇合
                    mModified.clear();
                   ......
                }
            }
            return new MemoryCommitResult(memoryStateGeneration, keysModified, listeners,
                    mapToWriteToDisk);
        }
  • mModified就是咱们本次要更新增加的键值对汇合；
  • mClear是咱们调用clear()办法的时候赋值的；
  • 大抵流程就是：首先判断是否须要清空内存数据，而后循环mModified汇合，增加更新数据到内存的键值对汇合中；

6、commit办法


public boolean commit() {
            .......
            //更新数据到内存
            MemoryCommitResult mcr = commitToMemory();
            //更新数据到磁盘
            SharedPreferencesImpl.this.enqueueDiskWrite(
                mcr, null /* sync write on this thread okay */);
            try {
            //期待：期待磁盘更新数据实现
                mcr.writtenToDiskLatch.await();
            } catch (InterruptedException e) {
                return false;
            } finally {
                if (DEBUG) {
                    Log.d(TAG, mFile.getName() + ":" + mcr.memoryStateGeneration
                            + " committed after " + (System.currentTimeMillis() - startTime)
                            + " ms");
                }
            }
            //执行listener回调
            notifyListeners(mcr);
            return mcr.writeToDiskResult;
        }
  • 首先apply没有返回值，commit有返回值；
  • 其实apply执行回调是和数据写入磁盘并行执行的，而commit办法执行回调是期待磁盘写入数据实现之后；

二、QueuedWork详解

1、QueuedWork

QueuedWork这个类，因为sp的初始化之后就是应用，后面看到，无论是apply还是commit办法都是通过QueuedWork来实现的；

QueuedWork是一个治理类，顾名思义，其中有一个队列，对所有入队的work进行治理调度；

其中最重要的就是有一个HandlerThread

private static Handler getHandler() {
        synchronized (sLock) {
            if (sHandler == null) {
                HandlerThread handlerThread = new HandlerThread("queued-work-looper",
                        Process.THREAD_PRIORITY_FOREGROUND);
                handlerThread.start();
                sHandler = new QueuedWorkHandler(handlerThread.getLooper());
            }
            return sHandler;
        }
    }

2、入队queue

// 如果是commit，则不能delay，如果是apply，则能够delay
    public static void queue(Runnable work, boolean shouldDelay) {
        Handler handler = getHandler();
        synchronized (sLock) {
            sWork.add(work);
            if (shouldDelay && sCanDelay) {
                // 默认delay的工夫是100ms
                handler.sendEmptyMessageDelayed(QueuedWorkHandler.MSG_RUN, DELAY);
            } else {
                handler.sendEmptyMessage(QueuedWorkHandler.MSG_RUN);
            }
        }
    }

3、音讯的解决

private static class QueuedWorkHandler extends Handler {
        static final int MSG_RUN = 1;
        QueuedWorkHandler(Looper looper) {
            super(looper);
        }
        public void handleMessage(Message msg) {
            if (msg.what == MSG_RUN) {
                processPendingWork();
            }
        }
    }
    private static void processPendingWork() {
        synchronized (sProcessingWork) {
            LinkedList<Runnable> work;
            synchronized (sLock) {
                work = (LinkedList<Runnable>) sWork.clone();
                sWork.clear();
                getHandler().removeMessages(QueuedWorkHandler.MSG_RUN);
            }
            if (work.size() > 0) {
                for (Runnable w : work) {
                    w.run();
                }
            }
        }
    }
  • 能够看到，调度非常简单，外部有一个sWork，须要执行的时候遍历所有的runnable执行；
  • 对于apply操作，会有肯定的提早再去执行work，然而对于commit操作，则会马上触发调度，而且并不仅仅是调度commit传过来的那个工作，而是马上就调度队列中所有的work；

4、waitToFinish

零碎中很多中央会期待sp的写入文件实现，期待形式是通过调用QueuedWork.waitToFinish();

public static void waitToFinish() {
        Handler handler = getHandler();
        synchronized (sLock) {
            // 移除所有音讯，间接开始调度所有work
            if (handler.hasMessages(QueuedWorkHandler.MSG_RUN)) {
                handler.removeMessages(QueuedWorkHandler.MSG_RUN);
            }
            sCanDelay = false;
        }
        StrictMode.ThreadPolicy oldPolicy = StrictMode.allowThreadDiskWrites();
        try {
            // 如果是waitToFinish调用过去，则马上执行所有的work
            processPendingWork();
        } finally {
            StrictMode.setThreadPolicy(oldPolicy);
        }
        try {
            // 在所有的work执行结束之后，还须要执行Finisher
            // 后面在apply的时候有一步是QueuedWork.addFinisher(awaitCommit);
            // 其中的实现是期待sp文件的写入实现
            // 如果没有通过msg去调度而是通过waitToFinish，则那个runnable就会在这里被执行
            while (true) {
                Runnable finisher;
                synchronized (sLock) {
                    finisher = sFinishers.poll();
                }
                if (finisher == null) {
                    break;
                }
                finisher.run();
            }
        } finally {
            sCanDelay = true;
        }
        ...
    }

零碎中对于四大组件的解决逻辑都在ActivityThread中实现，在service/activity的生命周期的执行中都会期待sp的写入实现，正是通过调用QueuedWork.waitToFinish()，确保app的数据正确的写入到disk；

5、sp应用的倡议

  • 对数据实时性要求不高，尽量应用apply
  • 如果业务要求必须数据胜利写入，应用commit
  • 缩小sp操作频次，尽量一次commit把所有的数据都写入结束
  • 能够适当思考不要在主线程拜访sp

  • 写入sp的数据尽量轻量级

    总结：

SharedPreferences的自身实现就是分为两步，一步是内存，一部是磁盘，而主线程又依赖SharedPreferences的写入，所以可能当io成为瓶颈的时候，App会因为SharedPreferences变的卡顿，重大状况下会ANR，总结下来有以下几点：

  • 寄存在xml文件中的数据会被装在到内存中，所以获取数据很快
  • apply是异步操作，提交数据到内存，并不会马上提交到磁盘
  • commit是同步操作，会期待数据写入到磁盘，并返回后果
  • 如果有同一个线程屡次commit，则前面的要期待后面执行完结
  • 如果多个线程对同一个sp并发commit，前面的所有工作会进入到QueuedWork中排队执行，且都要等第一个执行结束

评论

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

这个站点使用 Akismet 来减少垃圾评论。了解你的评论数据如何被处理。

更多文章