SharedPreference引发ANR原理详解

正文

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

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

// 初始化一个sp
SharedPreferences sharedPreferences = context.getSharedPreferences("name_sp", MODE_PRIVATE);
// 修改key的值,有两种方法:commit和apply
sharedPreferences.edit().putBoolean("key_test", true).commit();
sharedPreferences.edit().putBoolean("key_test", true).apply();
// 读取一个key
sharedPreferences.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 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 getSharedPreferencesCacheLocked() {
        // sSharedPrefsCache是一个静态变量,全局有效
        if (sSharedPrefsCache == null) {
            sSharedPrefsCache = new ArrayMap<>();
        }
        // key:包名,value: ArrayMap 
        final String packageName = getPackageName();
        ArrayMap 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) 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 /* sync write on this thread okay */);
            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呢?

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

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

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

总结

综上所述,SharedPreference可能在以下几种情况下产生卡顿,从而引起ANR:

  • 创建SharedPreference时,调用getPreferenceDir,可能存在创建目录的行为
  • getBoolean等方法,会等待直到SharedPreference将文件中的键值对全部读取到缓存里,才会返回
  • commit方法直接同步写,如果不小心在主线程调用,会引起卡顿
  • apply方法虽然是在异步线程写入,但是由于ActivityService的生命周期会等待所有SharedPreference的写入完成,所以可能引起卡顿和ANR问题

SharedPreference从设计之初,就是为了存储少量key-value对,而存在的。其本身的设计,就存在很多缺陷。在存储特别少量数据的时候,性能瓶颈还不显著。但是现在很多开发同学在使用的时候,会往里面存一些大型的JSON字符串等,导致它的缺点被明显暴露出来。建议在使用SharedPreference的时候,只用于存储少量数据,不要存大的字符串。

当然,我们也有一些方法来统一优化SharedPreference,减少ANR的发生,下一篇我们继续讲。

以上就是SharedPreference引发ANR原理详解的详细内容,更多关于SharedPreference引发ANR的资料请关注脚本之家其它相关文章!

你可能感兴趣的:(SharedPreference引发ANR原理详解)