SharedPreference引发ANR原理是什么

这篇文章主要介绍“SharedPreference引发ANR原理是什么”，在日常操作中，相信很多人在SharedPreference引发ANR原理是什么问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”SharedPreference引发ANR原理是什么”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！

正文

日常开发中，使用过SharedPreference的同学，肯定在监控平台上看到过和SharedPreference相关的ANR，而且量应该不小。如果使用比较多或者经常用sp存一些大数据，如JSON等，相关的ANR经常能排到前10。下面就从源码的角度来看看，为什么SharedPreference容易产生ANR。

SharedPreference的用法，相信做过Android开发的同学都会，所以这里就只简单介绍一下，不详细介绍了。

// 初始化一个spSharedPreferences sharedPreferences = context.getSharedPreferences("name_sp", MODE_PRIVATE);// 修改key的值，有两种方法：commit和applysharedPreferences.edit().putBoolean("key_test", true).commit();sharedPreferences.edit().putBoolean("key_test", true).apply();// 读取一个keysharedPreferences.getBoolean("key_test", false);

SharedPreference问题

SharedPreference的相关方法，除了commit外，一般的开发同学都会直接在主线程调用，认为这样不耗时。但其实，SharedPreference的很多方法都是耗时的，直接在主线程调很可能会引起ANR的问题。另外，虽然apply方法的调用不耗时，但是会引起生命周期相关的ANR问题。

下面就来从源码的角度，看一下可能引起ANR的问题所在。

getSharedPreference(String name, int mode)

    @Override    public SharedPreferences getSharedPreferences(String name, int mode) {        File file;        //  与sp相关的操作，都使用ContextImpl的类锁        synchronized (ContextImpl.class) {            if (mSharedPrefsPaths == null) {                mSharedPrefsPaths = new ArrayMap<>();            }            // mSharedPrefsPaths是内存缓存的文件路径            file = mSharedPrefsPaths.get(name);            if (file == null) {                // 此处获取SharedPreferences的文件路径，可能存在耗时                file = getSharedPreferencesPath(name);                mSharedPrefsPaths.put(name, file);            }        }        return getSharedPreferences(file, mode);    }

下面看下获取文件路径的方法：getSharedPreferencesPath()，这个方法可能存在耗时。

    public File getSharedPreferencesPath(String name) {        // 创建一个sp的存储文件        return makeFilename(getPreferencesDir(), name + ".xml");    }

调用getPreferencesDir()获取sharedPrefs的根路径

    private File getPreferencesDir() {        // 所有和文件有关的操作，都会使用mSync锁，可能出现与其他线程抢锁的耗时        synchronized (mSync) {            if (mPreferencesDir == null) {                mPreferencesDir = new File(getDataDir(), "shared_prefs");            }            // 这个方法，如果目录不存在，会创建目录，可能存在耗时            return ensurePrivateDirExists(mPreferencesDir);        }    }

ensurePrivateDirExists()：确保文件目录存在

    private static File ensurePrivateDirExists(File file, int mode, int gid, String xattr) {        if (!file.exists()) {            final String path = file.getAbsolutePath();            try {                // 创建文件夹，会耗时                Os.mkdir(path, mode);                Os.chmod(path, mode);            } catch (ErrnoException e) {            }        return file;    }

再来看看getSharedPreferences生成SharedPreferenceImpl对象的流程。

    public SharedPreferences getSharedPreferences(File file, int mode) {        SharedPreferencesImpl sp;        synchronized (ContextImpl.class) {            // 获取cache，先从cache中获取SharedPreferenceImpl            final ArrayMap<File, SharedPreferencesImpl> cache = getSharedPreferencesCacheLocked();            sp = cache.get(file);            if (sp == null) {                // 如果没有cache，则创建一个SharedPreferencesImpl，此处可能存在耗时                sp = new SharedPreferencesImpl(file, mode);                cache.put(file, sp);                return sp;            }        }        return sp;    }

先来看下cache的原理

    private ArrayMap<File, SharedPreferencesImpl> getSharedPreferencesCacheLocked() {        // ssharedPrefsCache是一个静态变量，全局有效        if (sSharedPrefsCache == null) {            sSharedPrefsCache = new ArrayMap<>();        }        // key:包名，value: ArrayMap<File, SharedPreferencesImpl>         final String packageName = getPackageName();        ArrayMap<File, SharedPreferencesImpl> packagePrefs = sSharedPrefsCache.get(packageName);        if (packagePrefs == null) {            packagePrefs = new ArrayMap<>();            sSharedPrefsCache.put(packageName, packagePrefs);        }        return packagePrefs;    }

再来看看SharedPreferenceImpl的构造方法，看看SharedPreference是怎么初始化的。

    SharedPreferencesImpl(File file, int mode) {        mFile = file;        mBackupFile = makeBackupFile(file);        // 设置是否load到内存的标志位为false        mLoaded = false;        startLoadFromDisk();    }

startLoadFromDisk()：开启一个子线程，将sp中的内容读取到内存中

    private void startLoadFromDisk() {        // 改mLoaded标志位时，需要获取mLock锁        synchronized (mLock) {           // load之前先设置mLoaded标志位为false            mLoaded = false;        }        // 开启一个线程，从文件中将sp中的内容读取到内存中        new Thread("SharedPreferencesImpl-load") {            public void run() {                // 在子线程load                loadFromDisk();            }        }.start();    }

loadFromDisk：真正读取文件的地方

   private void loadFromDisk() {        synchronized (mLock) {            // 如果已经load过了，直接return，不需要再重新load            if (mLoaded) {                return;            }            stat = Os.stat(mFile.getPath());            if (mFile.canRead()) {                BufferedInputStream str = null;                try {                    str = new BufferedInputStream(                            new FileInputStream(mFile), 16 * 1024);                    // 读取xml的内容到map中                    map = (Map<String, Object>) XmlUtils.readMapXml(str);                } catch (Exception e) {                    Log.w(TAG, "Cannot read " + mFile.getAbsolutePath(), e);                } finally {                    IoUtils.closeQuietly(str);                }            }        synchronized (mLock) {            // 设置mLoaded标志位为true，表示已经load完，通知所有在等待的线程            mLoaded = true;            mLock.notifyAll();        }    }

总结：经过上面的分析，getSharedPreferences主要的卡顿点在于，获取PreferencesDir的时候，可能存在目录尚未创建的情况。如果这个时候调用了创建目录的方法，就会非常耗时。

getBoolean(String key, boolean defValue)

这个方法和所有获取key的方法一样，都可能存在耗时。

从SharedPreferencesImpl的构造方法，我们知道会开启一个新的线程，将内容从文件中读取到缓存的map里，这个步骤我们叫load。

    public boolean getBoolean(String key, boolean defValue) {        synchronized (mLock) {            // 需要等待，直到load成功            awaitLoadedLocked();            // 从缓存中取value            Boolean v = (Boolean)mMap.get(key);            return v != null ? v : defValue;        }    }

主要耗时的方法，在awaitLoadedLocked里。

    private void awaitLoadedLocked() {       // 只有当mLoaded为true时，才能跳出死循环        while (!mLoaded) {            try {                // 调用wait后，会释放mLock锁，并且进入等待池，等待load完之后的唤醒                mLock.wait();            } catch (InterruptedException unused) {            }        }    }

这个方法，调用了mLock.wait()，释放了mLock的对象锁，并且进入等待池，直到load完被唤醒。

总结：所以，getBoolean等获取key的方法，会等待，直到sp的内容从文件中copy到缓存map里。很可能存在耗时。

commit()

commit()方法，会进行同步写，一定存在耗时，不能直接在主线程调用。

        public boolean commit() {            // 开始排队写            SharedPreferencesImpl.this.enqueueDiskWrite(                mcr, null );            try {                // 等待同步写的结果                mcr.writtenToDiskLatch.await();            } catch (InterruptedException e) {                return false;            } finally {            }            notifyListeners(mcr);            return mcr.writeToDiskResult;        }

apply()

大家都知道apply方法是异步写，但是也可能造成ANR的问题。下面我们来看apply方法的源码。

        public void apply() {            // 先将更新写入内存缓存            final MemoryCommitResult mcr = commitToMemory();            // 创建一个awaitCommit的runnable，加入到QueuedWork中            final Runnable awaitCommit = new Runnable() {                    @Override                    public void run() {                        try {                            // 等待写入完成                            mcr.writtenToDiskLatch.await();                        } catch (InterruptedException ignored) {                        }                    }                };            // 将awaitCommit加入到QueuedWork中            QueuedWork.addFinisher(awaitCommit);            Runnable postWriteRunnable = new Runnable() {                    @Override                    public void run() {                        awaitCommit.run();                        QueuedWork.removeFinisher(awaitCommit);                    }                };            // 真正执行sp持久化操作，异步执行            SharedPreferencesImpl.this.enqueueDiskWrite(mcr, postWriteRunnable);            // 虽然还没写入文件，但是内存缓存已经更新了，而listener通常都持有相同的sharedPreference对象，所以可以使用内存缓存中的数据            notifyListeners(mcr);        }

可以看到这里确实是在子线程进行的写入操作，但是为什么说apply也会引起ANR呢？

因为在Activity和Service的一些生命周期方法里，都会调用QueuedWork.waitToFinish()方法，这个方法会等待所有子线程写入完成，才会继续进行。主线程等子线程，很容易产生ANR问题。

public static void waitToFinish() {       Runnable toFinish;       //等待所有的任务执行完成       while ((toFinish = sPendingWorkFinishers.poll()) != null) {           toFinish.run();       }   }

Android 8.0 在这里做了一些优化，但还是需要等写入完成，无法完成解决ANR的问题。

到此，关于“SharedPreference引发ANR原理是什么”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注编程网网站，小编会继续努力为大家带来更多实用的文章！