SharedPreferences源码解析

对于SharedPreferences使用大家肯定都很熟悉,毕竟使用非常的简单,但是使用的过程中应该注意什么问题,这对于大部分人来说可能就不太清楚了。

这里先说下需要注意的几点:

1、SharedPreferences一经加载,它内部存储的数据就会以Map的形式一直保存在内存中,所以,对于SharedPreferences的使用,应该要分清哪些数据是常用的,哪些是不常用的,常用的保存在一起,不常用的保存在一起;

2、获取SharedPreferences时,如果是初次加载,那么需要从文件中去加载数据,这是一个耗时操作,所以加载数据的这个过程是在子线程中完成的,但是,注意重点,当我们对SharedPreferences进行操作,而SharedPreferences加载数据又还没有结束,这时会导致线程等待,直到数据加载完后在开始操作数据,所以,对于要用到SharedPreferences,应该提前去获取,以确保使用时已经将数据加载完毕,这里说的是首次,如果加载过一次,那么之后的获取就是直接从内存中获取了;

3、保存数据时,apply()是先将数据保存到内存中,然后在子线程中将数据保存到磁盘,commit()也是先将数据保存到内存中,之后立即将数据同步到磁盘,这个操作是在当前线程中完成,所以会阻塞线程,所以现在android建议使用apply(),但是使用apply()时也有需要注意的地方,如果保存数据时这个过程还没有结束,但是这时退出了activity,这时activity会先确保数据是否已经全部同步到磁盘了,如果没有,这时会两种情况,一是保存的过程正在子线中执行,这时等待就好,如果这时还没分发给子线程,那么就直接切换到主线程执行了,所以这时提交数据时也有需要注意的地方,使用SharedPreferences.Editor提交数据时,尽量在所有数据都提交后再调用apply()方法;

现在在从源码中看是如何体现这几点的,先看SharedPreferences的获取:

SharedPreferences currentSP = context.getSharedPreferences(spName, Context.MODE_PRIVATE);

这里context可能是Application的也可能是Activity的,但不管是谁的,它的实现都是ContextImpl,所以这里入口就是ContextImpl的getSharedPreferences()了,在看源码之前,我们先思考一个问题:

Activity和Application的context获取是否有什么区别(答案是没区别,一样的)?

这里先看ContextImpl的getSharedPreferences()方法:

    public SharedPreferences getSharedPreferences(String name, int mode) {
        // At least one application in the world actually passes in a null
        // name.  This happened to work because when we generated the file name
        // we would stringify it to "null.xml".  Nice.
        if (mPackageInfo.getApplicationInfo().targetSdkVersion <
                Build.VERSION_CODES.KITKAT) {
            if (name == null) {
                name = "null";
            }
        }

        File file;
        synchronized (ContextImpl.class) {
            if (mSharedPrefsPaths == null) {
                mSharedPrefsPaths = new ArrayMap<>();
            }
            file = mSharedPrefsPaths.get(name);
            if (file == null) {
                file = getSharedPreferencesPath(name);
                mSharedPrefsPaths.put(name, file);
            }
        }
        return getSharedPreferences(file, mode);
    }

方法还是挺简单的,这里主要做到了两个处理:

1、在api 19之前,如果name为null,那默认就将文件取名为null.xml,但是之后就会报NullPointerException;

2、这里先看下ArrayMap,它是Android中提供的,它的作用类似HashMap,但是在内存方面ArrayMap比HashMap更有效率,所以在android中推荐使用ArrayMap,这里使用的就是ArrayMap,他用于根据名字保存文件,这个文件就是保存内容的地方,接下来调用的就是getSharedPreferences(file, mode),如果你不想使用默认保存文件的地方,那就可以使用这个方法;

接下来看getSharedPreferences(file, mode):

    public SharedPreferences getSharedPreferences(File file, int mode) {
        SharedPreferencesImpl sp;
        synchronized (ContextImpl.class) {
            final ArrayMap<File, SharedPreferencesImpl> cache = getSharedPreferencesCacheLocked();
            sp = cache.get(file);
            if (sp == null) {
                checkMode(mode);
                if (getApplicationInfo().targetSdkVersion >= android.os.Build.VERSION_CODES.O) {
                    if (isCredentialProtectedStorage()
                            && !getSystemService(UserManager.class)
                            .isUserUnlockingOrUnlocked(UserHandle.myUserId())) {
                        throw new IllegalStateException("SharedPreferences in credential encrypted "
                                + "storage are not available until after user is unlocked");
                    }
                }
                sp = new SharedPreferencesImpl(file, mode);
                cache.put(file, sp);
                return sp;
            }
        }
        if ((mode & Context.MODE_MULTI_PROCESS) != 0 ||
                getApplicationInfo().targetSdkVersion < android.os.Build.VERSION_CODES.HONEYCOMB) {
            // If somebody else (some other process) changed the prefs
            // file behind our back, we reload it.  This has been the
            // historical (if undocumented) behavior.
            sp.startReloadIfChangedUnexpectedly();
        }
        return sp;
    }

这个方法主要的逻辑就是先获取缓存,根据文件查看缓存中是否存在,如果存在就直接返回,如果不存在,那么就新建一个SharedPreferences,然后保存到缓存中,再返回,这里获取缓存使用的是getSharedPreferencesCacheLocked(),这里先去看下它的缓存是怎样设计的;

getSharedPreferencesCacheLocked()方法:

    private static ArrayMap<String, ArrayMap<File, SharedPreferencesImpl>> sSharedPrefsCache;
    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;
    }

这里用的也是ArrayMap,并且还是static的,这也就是说这个是一直保存在内存中的,这也就是为什么说在第一次加载后,在这之后就一直在内存中获取了,接下来就去看下初次加载是怎样的一个执行逻辑,对于初次加载,是创建sp = new SharedPreferencesImpl(file, mode)这样一个对象并返回,那我们就去看看它的构造方法到底做了些什么事情:

SharedPreferencesImpl(file, mode)的构造方法:

    SharedPreferencesImpl(File file, int mode) {
        mFile = file;
        mBackupFile = makeBackupFile(file);
        mMode = mode;
        mLoaded = false;
        mMap = null;
        startLoadFromDisk();
    }

咋一看没什么啊,都是初始化一些变量,但这里有一个重点需要注意,那就是startLoadFromDisk(),看名字就知道是去磁盘中加载数据,也就是说只有在创建实例的时候才会去加载数据,前面的有说到,一旦创建一个实例后就会保存到缓存中,这也就是说只在第一次获取的时候才会去磁盘中加载数据;

接下来就去看看startLoadFromDisk()方法:

    private void startLoadFromDisk() {
        synchronized (mLock) {
            mLoaded = false;
        }
        new Thread("SharedPreferencesImpl-load") {
            public void run() {
                loadFromDisk();
            }
        }.start();
    }

没做什么操作,就是开了一个线程去执行loadFromDisk(),这也就是说加载数据是在子线程中执行的,接着往下看loadFromDisk():

private void loadFromDisk() {
        synchronized (mLock) {
            if (mLoaded) {
                return;
            }
            if (mBackupFile.exists()) {
                mFile.delete();
                mBackupFile.renameTo(mFile);
            }
        }

        // Debugging
        if (mFile.exists() && !mFile.canRead()) {
            Log.w(TAG, "Attempt to read preferences file " + mFile + " without permission");
        }

        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中
                    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;
            if (map != null) {
                // 真正保存数据的mMap,后面数据的保存和获取都会用到
                mMap = map;
                mStatTimestamp = stat.st_mtim;
                mStatSize = stat.st_size;
            } else {
                mMap = new HashMap<>();
            }
            mLock.notifyAll();
        }
    }

这里有一个mLock锁,这个锁很重要,这里获取到了锁,当SharedPreferences去操作数据的时候就会先去判断这个锁是否释放了,如果没有,那么就会等待锁释放了在执行,执行到就将数据加载到了内存中,最终保存在mMap中,那么接下来看他是怎样获取数据的,这里就看下它的getString()方法:

    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() {
        if (!mLoaded) {
            // Raise an explicit StrictMode onReadFromDisk for this
            // thread, since the real read will be in a different
            // thread and otherwise ignored by StrictMode.
            BlockGuard.getThreadPolicy().onReadFromDisk();
        }
        while (!mLoaded) {
            try {
                mLock.wait();
            } catch (InterruptedException unused) {
            }
        }
    }

这里一进来就加了一个锁,这个锁是为了防止数据还没加载就执行到这里,那这时就需要将锁释放掉,但又不对数据进行操作,那这个awaitLoadedLocked()就起到了这个作用,这也就是说,数据没加载完是不能对数据进行操作的,这时就阻塞在这里,到这,一开始说到的第一点和第二点就可以解释了,那么接下来就来看看数据是如何修改的;

对于数据的修改都是使用它的Editor()方法,那就来看下这个方法:

    public Editor edit() {
        // TODO: remove the need to call awaitLoadedLocked() when
        // requesting an editor.  will require some work on the
        // Editor, but then we should be able to do:
        //
        //      context.getSharedPreferences(..).edit().putString(..).apply()
        //
        // ... all without blocking.
        synchronized (mLock) {
            awaitLoadedLocked();
        }

        return new EditorImpl();
    }

这里也是要等数据加载完才能对数据进行操作,但实际上对数据进行修改使用的是EditorImpl这个类,每调用一次这个方法就会新建一个EditorImpl实例,所以不要每修改一次就调用一次,可以尽量将所有需要修改的数据放一起进行操作,接下来看看这个类:

public final class EditorImpl implements Editor {
        private final Object mLock = new Object();

        @GuardedBy("mLock")
        private final Map<String, Object> mModified = Maps.newHashMap();

        @GuardedBy("mLock")
        private boolean mClear = false;

        public Editor putString(String key, @Nullable String value) {
            synchronized (mLock) {
                mModified.put(key, value);
                return this;
            }
        }
        public Editor putStringSet(String key, @Nullable Set<String> values) {
            synchronized (mLock) {
                mModified.put(key,
                        (values == null) ? null : new HashSet<String>(values));
                return this;
            }
        }
        public Editor putInt(String key, int value) {
            synchronized (mLock) {
                mModified.put(key, value);
                return this;
            }
        }
        public Editor putLong(String key, long value) {
            synchronized (mLock) {
                mModified.put(key, value);
                return this;
            }
        }
        public Editor putFloat(String key, float value) {
            synchronized (mLock) {
                mModified.put(key, value);
                return this;
            }
        }
        public Editor putBoolean(String key, boolean value) {
            synchronized (mLock) {
                mModified.put(key, value);
                return this;
            }
        }

        public Editor remove(String key) {
            synchronized (mLock) {
                mModified.put(key, this);
                return this;
            }
        }

        public Editor clear() {
            synchronized (mLock) {
                mClear = true;
                return this;
            }
        }

        public void apply() {
            final long startTime = System.currentTimeMillis();

            final MemoryCommitResult mcr = commitToMemory();
            final Runnable awaitCommit = new Runnable() {
                    public void run() {
                        try {
                            mcr.writtenToDiskLatch.await();
                        } catch (InterruptedException ignored) {
                        }

                        if (DEBUG && mcr.wasWritten) {
                            Log.d(TAG, mFile.getName() + ":" + mcr.memoryStateGeneration
                                    + " applied after " + (System.currentTimeMillis() - startTime)
                                    + " ms");
                        }
                    }
                };

            QueuedWork.addFinisher(awaitCommit);

            Runnable postWriteRunnable = new Runnable() {
                    public void run() {
                        awaitCommit.run();
                        QueuedWork.removeFinisher(awaitCommit);
                    }
                };

            SharedPreferencesImpl.this.enqueueDiskWrite(mcr, postWriteRunnable);

            // Okay to notify the listeners before it's hit disk
            // because the listeners should always get the same
            // SharedPreferences instance back, which has the
            // changes reflected in memory.
            notifyListeners(mcr);
        }

        // Returns true if any changes were made
        private MemoryCommitResult commitToMemory() {
            long memoryStateGeneration;
            List<String> keysModified = null;
            Set<OnSharedPreferenceChangeListener> listeners = null;
            Map<String, Object> mapToWriteToDisk;

            synchronized (SharedPreferencesImpl.this.mLock) {
                // We optimistically don't make a deep copy until
                // a memory commit comes in when we're already
                // writing to disk.
                if (mDiskWritesInFlight > 0) {
                    // We can't modify our mMap as a currently
                    // in-flight write owns it.  Clone it before
                    // modifying it.
                    // noinspection unchecked
                    mMap = new HashMap<String, Object>(mMap);
                }
                mapToWriteToDisk = mMap;
                mDiskWritesInFlight++;

                boolean hasListeners = mListeners.size() > 0;
                if (hasListeners) {
                    keysModified = new ArrayList<String>();
                    listeners = new HashSet<OnSharedPreferenceChangeListener>(mListeners.keySet());
                }

                synchronized (mLock) {
                    boolean changesMade = false;

                    if (mClear) {
                        if (!mMap.isEmpty()) {
                            changesMade = true;
                            mMap.clear();
                        }
                        mClear = false;
                    }

                    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);
                        }

                        changesMade = true;
                        if (hasListeners) {
                            keysModified.add(k);
                        }
                    }

                    mModified.clear();

                    if (changesMade) {
                        mCurrentMemoryStateGeneration++;
                    }

                    memoryStateGeneration = mCurrentMemoryStateGeneration;
                }
            }
            return new MemoryCommitResult(memoryStateGeneration, keysModified, listeners,
                    mapToWriteToDisk);
        }

        public boolean commit() {
            long startTime = 0;

            if (DEBUG) {
                startTime = System.currentTimeMillis();
            }

            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");
                }
            }
            notifyListeners(mcr);
            return mcr.writeToDiskResult;
        }

        private void notifyListeners(final MemoryCommitResult mcr) {
            if (mcr.listeners == null || mcr.keysModified == null ||
                mcr.keysModified.size() == 0) {
                return;
            }
            if (Looper.myLooper() == Looper.getMainLooper()) {
                for (int i = mcr.keysModified.size() - 1; i >= 0; i--) {
                    final String key = mcr.keysModified.get(i);
                    for (OnSharedPreferenceChangeListener listener : mcr.listeners) {
                        if (listener != null) {
                            listener.onSharedPreferenceChanged(SharedPreferencesImpl.this, key);
                        }
                    }
                }
            } else {
                // Run this function on the main thread.
                ActivityThread.sMainThreadHandler.post(new Runnable() {
                        public void run() {
                            notifyListeners(mcr);
                        }
                    });
            }
        }
    }

这里逻辑可以分为两点:

1、调用putXXX()方法,将所有需要修改的数据先保存在一个临时的集合中;

2、调用apply()或commit()方法将临时集合中的数据合并到mMap集合中并同步到磁盘中;

再看apply()方法前,这里先来看下commitToMemory()方法:

    private MemoryCommitResult commitToMemory() {
        long memoryStateGeneration;
        List<String> keysModified = null;
        Set<OnSharedPreferenceChangeListener> listeners = null;
        Map<String, Object> mapToWriteToDisk;

        synchronized (SharedPreferencesImpl.this.mLock) {
            // We optimistically don't make a deep copy until
            // a memory commit comes in when we're already
            // writing to disk.
            if (mDiskWritesInFlight > 0) {
                // We can't modify our mMap as a currently
                // in-flight write owns it.  Clone it before
                // modifying it.
                // noinspection unchecked
                mMap = new HashMap<String, Object>(mMap);
            }
            // 将需要保存到磁盘中的数据保存到这个集合中
            mapToWriteToDisk = mMap;
            mDiskWritesInFlight++;

            boolean hasListeners = mListeners.size() > 0;
            if (hasListeners) {
                keysModified = new ArrayList<String>();
                listeners = new HashSet<OnSharedPreferenceChangeListener>(mListeners.keySet());
            }

            synchronized (mLock) {
                boolean changesMade = false;
                // 如果调用了clear(),那么就会将集合中原先的数据清除掉
                if (mClear) {
                    if (!mMap.isEmpty()) {
                        changesMade = true;
                        mMap.clear();
                    }
                    mClear = false;
                }
                // 遍历存储在临时集合中的数据,然后合并到原先的数据集合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);
                    }

                    changesMade = true;
                    if (hasListeners) {
                        keysModified.add(k);
                    }
                }

                mModified.clear();

                if (changesMade) {
                    mCurrentMemoryStateGeneration++;
                }

                memoryStateGeneration = mCurrentMemoryStateGeneration;
            }
        }
        return new MemoryCommitResult(memoryStateGeneration, keysModified, listeners,
                mapToWriteToDisk);
    }

这个方法主要做的就是将保存在临时集合中的数据合并到mMap(之前的数据集合)中,同时返回一个MemoryCommitResult对象,将数据保存到磁盘中用到的就是这个类;

接下来就该看看apply()方法了:

    public void apply() {
        final long startTime = System.currentTimeMillis();
        // 先将数据同步到内存中
        final MemoryCommitResult mcr = commitToMemory();
        final Runnable awaitCommit = new Runnable() {
            public void run() {
                try {
                    // writtenToDiskLatch是一个CountDownLatch对象,除非数据全部同步到磁盘,否则这里就一直阻塞
                    mcr.writtenToDiskLatch.await();
                } catch (InterruptedException ignored) {
                }

                if (DEBUG && mcr.wasWritten) {
                    Log.d(TAG, mFile.getName() + ":" + mcr.memoryStateGeneration
                            + " applied after " + (System.currentTimeMillis() - startTime)
                            + " ms");
                }
            }
        };
        // 这里将awaitCommit添加到QueuedWork中的目的是为了退出activity时,确保所有数据已经全部同步到磁盘中了
        QueuedWork.addFinisher(awaitCommit);

        Runnable postWriteRunnable = new Runnable() {
            public void run() {
                awaitCommit.run();
                // 数据同步完这里就会将awaitCommit从QueuedWork移除
                QueuedWork.removeFinisher(awaitCommit);
            }
        };
        // 开始执行将数据同步到磁盘中,会新开线程,后面会说到
        SharedPreferencesImpl.this.enqueueDiskWrite(mcr, postWriteRunnable);

        // Okay to notify the listeners before it's hit disk
        // because the listeners should always get the same
        // SharedPreferences instance back, which has the
        // changes reflected in memory.
        // 这里是唤醒回调,前提是你注册了registerOnSharedPreferenceChangeListener()回调
        // 还有一个条件就是这个key是新添加的才会触发
        notifyListeners(mcr);
    }

在这个方法中真正将数据同步到磁盘中是queueDiskWrite(),其中传了两个参数,第一个参数其内部保存的是需要同步的相关数据,第二个参数是为了确保退出activity时数据全部同步到了磁盘中,来看下这个方法的内部实现:

    private void enqueueDiskWrite(final MemoryCommitResult mcr, final Runnable postWriteRunnable) {
        // 注意这里的postWriterRunnable,如果是apply()方法,传进来的参数是不为null的,如果是commit(),
        // 这里传进来的为null,isFromSyncCommit的值决定了是立即同步还是稍后再同步
        final boolean isFromSyncCommit = (postWriteRunnable == null);

        final Runnable writeToDiskRunnable = new Runnable() {
            public void run() {
                synchronized (mWritingToDiskLock) {
                    writeToFile(mcr, isFromSyncCommit);
                }
                synchronized (mLock) {
                    mDiskWritesInFlight--;
                }
                if (postWriteRunnable != null) {
                    postWriteRunnable.run();
                }
            }
        };

        // Typical #commit() path with fewer allocations, doing a write on
        // the current thread.
        // 如果是commit(),那么就会执行到这里,在当前线程中同步数据
        if (isFromSyncCommit) {
            boolean wasEmpty = false;
            synchronized (mLock) {
                wasEmpty = mDiskWritesInFlight == 1;
            }
            if (wasEmpty) {
                writeToDiskRunnable.run();
                return;
            }
        }
        // 如果是apply(),那么就会执行到这里,看来还得继续跟下去
        QueuedWork.queue(writeToDiskRunnable, !isFromSyncCommit);
    }

这里会先判断是不是commit()执行的,如果是commit(),那么就在当前线程中同步数据,这也就是为什么android现在不推荐使用这个方法了,如果是apply()方法,那就还得往下看了,这里调用的是QueueWork这个类queue(),并将同步数据的任务传递进去,这里同步数据的工作就封装在writerDiskRunnable中,接下来看看queue()里面是如何做的处理:

    public static void queue(Runnable work, boolean shouldDelay) {
        Handler handler = getHandler();

        synchronized (sLock) {
            sWork.add(work);

            if (shouldDelay && sCanDelay) {
                handler.sendEmptyMessageDelayed(QueuedWorkHandler.MSG_RUN, DELAY);
            } else {
                handler.sendEmptyMessage(QueuedWorkHandler.MSG_RUN);
            }
        }
    }

先获取到一个handler,然后将同步数据的任务添加到了sWork这个集合中,那后面处理肯定也是去这个集合里面拿了,根据上面的分析,这里的shouldDelay是为false的,所以执行的是下面这个方法,看来重点是这个handler了,那就去看看这个getHandler()了:

    private static Handler getHandler() {
        synchronized (sLock) {
            if (sHandler == null) {
                // 这里使用HandlerThread是为了获取子线程的looper对象,handler中处理消息就是通过这个looper
                HandlerThread handlerThread = new HandlerThread("queued-work-looper",
                        Process.THREAD_PRIORITY_FOREGROUND);
                handlerThread.start();

                sHandler = new QueuedWorkHandler(handlerThread.getLooper());
            }
            return sHandler;
        }
    }
    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();
            }
        }
    }

这里就是构建一个handler,如果已经存在就直接返回了,不过这个handler处理消息是在子线程中执行的,要看明白这里,首先你得知道Handler和HadlerThread的原理,构建Handler在子线中处理消息时,一定要为他准备一个looper对象,否则是会有异常的,看这里的handleMessage(),将执行的逻辑交给了processPendingWork(),来看看:

    private static void processPendingWork() {
        long startTime = 0;

        if (DEBUG) {
            startTime = System.currentTimeMillis();
        }

        synchronized (sProcessingWork) {
            LinkedList<Runnable> work;

            synchronized (sLock) {
                // 将前面添加的任务全部clone出来,然后清除
                work = (LinkedList<Runnable>) sWork.clone();
                sWork.clear();

                // Remove all msg-s as all work will be processed now
                // 将任务取出来后,就可以取消后面执行任务的消息了,这里取消的只是上面clone出来的任务
                getHandler().removeMessages(QueuedWorkHandler.MSG_RUN);
            }
            // 这里就是开始将数据同步到内存中
            if (work.size() > 0) {
                for (Runnable w : work) {
                    w.run();
                }

                if (DEBUG) {
                    Log.d(LOG_TAG, "processing " + work.size() + " items took " +
                            +(System.currentTimeMillis() - startTime) + " ms");
                }
            }
        }
    }

这里执行的逻辑就是将前面添加的数据clone出来作为局部变量,然后将clone的集合清空,再移除发送任务的消息(这个任务已经添加到集合中了),这样数据同步就在子线程中完成了。到这,主要的逻辑都捋了一遍,但是还有一个点,就是一开始说的第三点,退出activity时,数据没同步完是会阻塞线程的,现在就看看为什么会阻塞线程?这里要先知道一点,Activity生命周期都是通过ActivityThread来控制的,在ActivityThread的handleStopActivity方法中,这里控制的就是Activity的stop,在这个方法中有调用到:

QueuedWork.waitToFinish();

这里就是查看QueuedWork中的任务是否都执行完了,如果没有执行完,那么就会处于等待状态,看下它里面是一个怎样的逻辑:

    public static void waitToFinish() {
        long startTime = System.currentTimeMillis();
        boolean hadMessages = false;

        Handler handler = getHandler();
        // 先看下Handler中是否还有等待的消息,如果有那么就移除
        synchronized (sLock) {
            if (handler.hasMessages(QueuedWorkHandler.MSG_RUN)) {
                // Delayed work will be processed at processPendingWork() below
                handler.removeMessages(QueuedWorkHandler.MSG_RUN);

                if (DEBUG) {
                    hadMessages = true;
                    Log.d(LOG_TAG, "waiting");
                }
            }

            // We should not delay any work as this might delay the finishers
            sCanDelay = false;
        }

        StrictMode.ThreadPolicy oldPolicy = StrictMode.allowThreadDiskWrites();
        try {
            // 这里就是将本该在子线程中执行的任务直接拿到主线程中来执行了
            processPendingWork();
        } finally {
            StrictMode.setThreadPolicy(oldPolicy);
        }

        try {
            // 这里是为了确保所有的任务确实已经执行完了
            while (true) {
                Runnable finisher;

                synchronized (sLock) {
                    finisher = sFinishers.poll();
                }

                if (finisher == null) {
                    break;
                }

                finisher.run();
            }
        } finally {
            sCanDelay = true;
        }

        synchronized (sLock) {
            long waitTime = System.currentTimeMillis() - startTime;

            if (waitTime > 0 || hadMessages) {
                mWaitTimes.add(Long.valueOf(waitTime).intValue());
                mNumWaits++;

                if (DEBUG || mNumWaits % 1024 == 0 || waitTime > MAX_WAIT_TIME_MILLIS) {
                    mWaitTimes.log(LOG_TAG, "waited: ");
                }
            }
        }
    }

这里会判断添加的任务是否全部执行完了,如果没有执行完,那么就会将本该在子线程中执行的任务全部移到主线程中来执行。

到这,才算是该注意的地方都分析到了,这里再把前面该注意的点说下:

1、SharedPreferences一经加载,它内部存储的数据就会以Map的形式一直保存在内存中,所以,对于SharedPreferences的使用,应该要分清哪些数据是常用的,哪些是不常用的,常用的保存在一起,不常用的保存在一起;

2、获取SharedPreferences时,如果是初次加载,那么需要从文件中去加载数据,这是一个耗时操作,所以加载数据的这个过程是在子线程中完成的,但是,注意重点,当我们对SharedPreferences进行操作,而SharedPreferences加载数据又还没有结束,这时会导致线程等待,直到数据加载完后在开始操作数据,所以,对于要用到SharedPreferences,应该提前去获取,以确保使用时已经将数据加载完毕,这里说的是首次,如果加载过一次,那么之后的获取就是直接从内存中获取了;

3、保存数据时,apply()是先将数据保存到内存中,然后在子线程中将数据保存到磁盘,commit()也是先将数据保存到内存中,之后立即将数据同步到磁盘,这个操作是在当前线程中完成,所以会阻塞线程,所以现在android建议使用apply(),但是使用apply()时也有需要注意的地方,如果保存数据时这个过程还没有结束,但是这时退出了activity,这时activity会先确保数据是否已经全部同步到磁盘了,如果没有,这时会两种情况,一是保存的过程正在子线中执行,这时等待就好,如果这时还没分发给子线程,那么就直接切换到主线程执行了,所以这时提交数据时也有需要注意的地方,使用SharedPreferences.Editor提交数据时,尽量在所有数据都提交后再调用apply()方法。

 

 

    原文作者:tangedegushi
    原文地址: https://blog.csdn.net/tangedegushi/article/details/82383509
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞