android同步阻塞,Android性能优化：注意同步锁的影响

同步锁的影响

在我们的运行过程中，我们经常要加上同步锁，避免其他线程同时修改了数据。但是在要去获取锁的过程中，该锁被其他耗时线程占用或者其他线程占用了并等待其他线程唤醒，从而导致主线程获取不了锁等待最后发生ANR的情况。实际上，这种情况一般发生在使用了CountDownLatch的情况。CountDownLatch是一个计时器闭锁，该计数器是原子操作，同时只能有一个线程去操作该计数器。调用该类await的方法一直处于阻塞的状态，直到其他线程调用countdown使得计数器为0，每次调用countdown减1。当计数器为0之后，其他线程才能被唤醒并继续后面的操作。因此，CountDownLatch特别容易引起主线程被阻塞导致现象看起来变慢了或者发生卡顿了。CountDownLatch在操作数据库的时候会经常发生，因此要特别注意这块可能潜在的问题。既主线程想去获取数据库实例的同时，然而其他线程正在查询数据库的操作，从而其他线程先占有了锁，这种情况同步延时不大，但是存在情况就是多个数据库同事操作，而数据库部分方法使用了CountDownLatch锁，从而必须等待计数器为0才能释放相关的锁。

我们可以通过Traceview或profile查看哪个地方主线程的CPU间隔比较大，从而找到对应的方法，进而通过Threads工具进一步查看线程哪些地方出现await了，进一步确定具体是哪个方法，从而根据找到的方法做出相应的解法方案。如下使用Threads工具找到对应的线程阻塞方法：

image

SharedPreference文件操作引起的同步问题

SharedPreference文件是Android App开发中基本会用到的。然而SharedPreference在使用过程中存在引起新能的问题。如下SharedPreference初始化的时候，会进入到SharedPreferencesImpl构造函数，从磁盘中加载文件资源到内存，加载过程使用了同步锁，而在get和put的操作中同样使用到同步锁，因此，若在SP没初始化完成的情况下，我们的get和put操作将只能等待初始化获得的锁释放。另外一个，我们看到初始化的时候是从磁盘进行文件读取并且解析xml文件到内存的，因此我们应该尽量保障SP文件不要过大，这样可以尽量保证初始化能快速完成。

SharedPreferencesImpl(File file, int mode) {

mFile = file;

mBackupFile = makeBackupFile(file);

mMode = mode;

mLoaded = false;

mMap = null;

mThrowable = null;

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()) {

mFile.delete();