一个null引发的SharedPreference惨案

（转载）http://blog.csdn.net/tracyxia716/article/details/52967110

序

*本篇文章已授权微信公众号 guolin_blog （郭霖）独家发布 
本周在安卓博客周刊里看到了一篇请不要滥用SharedPreference，感觉颇有收获。而我恰好在这周碰到了一个关于SharedPreference的bug，让我费了一番功夫才找出，所以在这里就写一篇文章来记录一下这个bug。

1.bug再现

首先让我来讲下这个bug的由来，并通过一个demo来模拟下bug现场。

在我所做的产品中有个XX云盘模块，其中有部分登陆信息是记录在SharedPrefrence中的。突然有一天，测试的同学拿来一部手机跟我说，这个手机登陆以后，杀掉进程再重新启动app就会丢失掉之前的登陆信息。当时我就一脸懵逼，再拿来观察一下现象，更加奇怪的事情是：登陆以后我发现登陆信息确实保存在了SharedPreference中，杀掉进程以后也还在，但是重新打开app以后，发现SharedPreference里的数据有部分被清空了（注意不是全部清空，而是部分）。

从现象上来看让人感到一头雾水，同时有的手机上又没有这种奇怪的现象发生，让我一时间都觉得是不是这个手机的rom比较烂所导致的。但是作为一个开发人员当然不能如此妄下定论，于是我写了一个demo来测试，发现没有上述的问题。那么可以肯定的是，这是我自己的app的逻辑存在bug！但是我全局找了一遍代码，并没有发现有任何去删除SharedPreference值的逻辑，于是这条线索又断了。

一头雾水的我只能转而研究SharedPreference文件本身，此时我发现了一个很怪异的现象，我的SharedPreference里有个key为null的值。key为null？作为一个开发人员，对于空指针还是有着十足的敏感，于是我就怀疑到了是不是这个为null的key引起的呢？下面我通过一个demo演示就真相大白了：

public class MainActivity extends FragmentActivity
        implements
            View.OnClickListener {

    Button saveOne, saveTwo, getOne, getTwo;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        saveOne = (Button) findViewById(R.id.saveone);
        saveTwo = (Button) findViewById(R.id.savetwo);
        getOne = (Button) findViewById(R.id.getOne);
        getTwo = (Button) findViewById(R.id.getTwo);

        saveOne.setOnClickListener(this);
        saveTwo.setOnClickListener(this);
        getOne.setOnClickListener(this);
        getTwo.setOnClickListener(this);

    }

    @Override
    public void onClick(View v) {
        switch (v.getId()) {
            case R.id.saveone :
                putString("one", "saveone");
                break;
            case R.id.savetwo :
                putString(null, "savetwo");
                break;
            case R.id.getOne :
                Toast.makeText(this, getString("one"), Toast.LENGTH_LONG)
                        .show();
                break;
            case R.id.getTwo :
                Toast.makeText(this, getString(null), Toast.LENGTH_LONG).show();
                break;
        }
    }

    public void putString(String key, String value) {
        SharedPreferences sharedPreferences = getSharedPreferences("test",
                MODE_PRIVATE);
        SharedPreferences.Editor editor = sharedPreferences.edit();
        editor.putString(key, value);
        editor.commit();
    }

    public String getString(String key) {
        SharedPreferences sharedPreferences = getSharedPreferences("test",
                MODE_PRIVATE);
        return sharedPreferences.getString(key, "null");
    }
}
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

存储一个正常的key并获取值：

存储一个key为null的值并获取：

以上我们的存储与获取都是正常的，并没有什么好说的，现在我杀掉进程再重新启动这个demo，那么诡异的现象就发生了：

杀掉进程以后去查看值发现都还在

但是都获取不到值了

是不是很怪异，明明值还在，但是就是获取不到真实的值，但是更加怪异的事情还在后面，当我点击了”存储一个为null的key进去”的时候再去观察SharedPreference数据发现数据都没了： 

真相大白，原来杀掉进程以后数据被清空了是因为存储了一个为null的key引起的。

2分析bug

既然问题已经定位了，就很容易解决了，将那个为null的key找出来赋值进去即可。但是作为一个对自己有高要求的研发人员，还是很有必要研究清楚整个bug的来龙去脉的。 
首先，从现象上来分析下这个bug产生的原因，在我杀掉进程第二次进入app没有获取到值的时候，在logcat上打下了如下一段日志:

10-29 22:54:37.099 10964-11037/? W/SharedPreferencesImpl: getSharedPreferences
                                                          org.xmlpull.v1.XmlPullParserException: Map value without name attribute: string
                                                              at com.android.internal.util.XmlUtils.readThisMapXml(XmlUtils.java:568)
                                                              at com.android.internal.util.XmlUtils.readThisValueXml(XmlUtils.java:821)
                                                              at com.android.internal.util.XmlUtils.readValueXml(XmlUtils.java:755)
                                                              at com.android.internal.util.XmlUtils.readMapXml(XmlUtils.java:494)
                                                              at android.app.SharedPreferencesImpl.loadFromDiskLocked(SharedPreferencesImpl.java:113)
                                                              at android.app.SharedPreferencesImpl.access$000(SharedPreferencesImpl.java:48)
                                                              at android.app.SharedPreferencesImpl$1.run(SharedPreferencesImpl.java:87)
 
 
1
2
3
4
5
6
7
8
9
 
 
1
2
3
4
5
6
7
8
9

同时，此异常只有在我第一次获取值没有获取到的时候才打印出来，后面无论有多少次未获取到都不会打印。大概从字面上的意思上来说，就是去获取了一个没有attribute的一个Map值产生的。通过我开头提到的文章了解到，SharedPreference每次取值的时候都是在第一次get的时候就将SharedPreference文件里的值一一读取并存入内存中，而后我们的每次get操作都是从内存当中取出的。

基于这个推断，我大胆的推测：之所以为null，是因为我们在此第一次去解析xml文件失败(抛异常了)，所以导致了我们内存中取出来的map里为null，以至于我们后面每次取值都为null。而后写入的值则是因为我们将内存的值直接写入磁盘，覆盖了原有的值，所以导致了我们的数据”部分被删除”。至于有的手机没有该问题，我猜测的是Android在5.0开始对于这类问题进行了容错处理，就是当发现有的value没有key的时候也能将值写入内存，只不过对应的key为null而已。

3.验证猜想

为了验证之前的猜想，就必须深入到安卓系统源码研究了。这里我们拿4.4的代码与5.1的代码来进行对比。首先我们根据抛异常的位置到4.4的源码里来一窥究竟：

    public static final HashMap readThisMapXml(XmlPullParser parser, String endTag, String[] name)
    throws XmlPullParserException, java.io.IOException
    {
        HashMap map = new HashMap();

        int eventType = parser.getEventType();
        do {
            if (eventType == parser.START_TAG) {
                Object val = readThisValueXml(parser, name);
                if (name[0] != null) {
                    //System.out.println("Adding to map: " + name + " -> " + val);
                    map.put(name[0], val);
                } else {
                    throw new XmlPullParserException(
                        "Map value without name attribute: " + parser.getName());
                }
            } else if (eventType == parser.END_TAG) {
                if (parser.getName().equals(endTag)) {
                    return map;
                }
                throw new XmlPullParserException(
                    "Expected " + endTag + " end tag at: " + parser.getName());
            }
            eventType = parser.next();
        } while (eventType != parser.END_DOCUMENT);

        throw new XmlPullParserException(
            "Document ended before " + endTag + " end tag");
    }
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

真相豁然开朗，当name为null的时候抛出了异常，与我之前在logcat上看到的一模一样。那么接着我们再看看5.1的代码这段是怎么处理的：

 public static final HashMap<String, ?> readThisMapXml(XmlPullParser parser, String endTag,
            String[] name, ReadMapCallback callback)
            throws XmlPullParserException, java.io.IOException
    {
        HashMap<String, Object> map = new HashMap<String, Object>();

        int eventType = parser.getEventType();
        do {
            if (eventType == parser.START_TAG) {
                Object val = readThisValueXml(parser, name, callback);
                map.put(name[0], val);
            } else if (eventType == parser.END_TAG) {
                if (parser.getName().equals(endTag)) {
                    return map;
                }
                throw new XmlPullParserException(
                    "Expected " + endTag + " end tag at: " + parser.getName());
            }
            eventType = parser.next();
        } while (eventType != parser.END_DOCUMENT);

        throw new XmlPullParserException(
            "Document ended before " + endTag + " end tag");
    }
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

我们可以看到明显的区别是，这里没有对name为null的分支进行处理，而是一视同仁的去读取值写入了map中。 
那么，至于为什么在杀掉进程以后再次开启APP又会”删除”掉部分值呢？我们接着分析源码：

SharedPreferencesImpl.Java

private MemoryCommitResult commitToMemory() {
            MemoryCommitResult mcr = new MemoryCommitResult();
            synchronized (SharedPreferencesImpl.this) {
                if (mDiskWritesInFlight > 0) {
                    mMap = new HashMap<String, Object>(mMap);
                }
                //我们可以看到在内存中commit值的时候会基于创建SharedPreferences时候得到的map来进行一个copy并写入新值最后写入磁盘中
                mcr.mapToWriteToDisk = mMap;
                mDiskWritesInFlight++;
                省略以下代码....

 
 
1
2
3
4
5
6
7
8
9
10
11
12
 
 
1
2
3
4
5
6
7
8
9
10
11
12

在这一块上4.4的代码与5.1的代码几乎一致，所以，导致4.4会删除值的原因就在于之前并没有从磁盘中读取到值到内存中。在对值进行copy的时候就”丢失”，从而导致写入进去的新文件里没有以前的旧值，由此现象上来看好像是某些值被删除了，但实际上确切的说应该是被空值所覆盖。

4总结

总的来说，这个问题的根源在于4.X的sdk里允许了往SharedPreferences里写入key为null的值而不允许取出来，并且不仅不能取出来，甚至还在写的过程当中引发了”删除”数据这样灾难性的后果。这样是及其不合理的，所以google在后续的SDK里也对这一块的逻辑修复了。不过，作为一个应用层开发人员，也是需要从自身检讨一下这样的低级错误。毕竟这个错误的后果十分严重，但又无色无味难以发现，以后需要尽可能的避免这样的错误再次发生。

相信通过这样一次从现象入手分析问题到追踪，再到SDK源码比对各版本间的差异，对于自身的水平提高还是有很多的益处的，希望以后还能够这样来分析一些更加深入的问题。当然，最后想说的是，我们还是从自身做起，尽量少犯低级错误，少出bug，做一个高水平的工程师，而不是整天debug的码农。