序
*本篇文章已授权微信公众号 guolin_blog （郭霖）独家发布
(之前发表在我的csdn博客中，现在同步到来)
本周在安卓博客周刊里看到了一篇请不要滥用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");
}
}
存储一个正常的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)
同时，此异常只有在我第一次获取值没有获取到的时候才打印出来，后面无论有多少次未获取到都不会打印。大概从字面上的意思上来说，就是去获取了一个没有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");
}
真相豁然开朗，当name为null的时候抛出了异常，与我之前在logcat上看到的一模一样。那么接着我们再看看5.1的代码这段是怎么处理的：
public static final HashMap readThisMapXml(XmlPullParser parser, String endTag,
String[] name, ReadMapCallback callback)
throws XmlPullParserException, java.io.IOException
{
HashMap map = new HashMap();
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");
}
我们可以看到明显的区别是，这里没有对name为null的分支进行处理，而是一视同仁的去读取值写入了map中。
那么，至于为什么在杀掉进程以后再次开启APP又会"删除"掉部分值呢？我们接着分析源码：
SharedPreferencesImpl.java
private MemoryCommitResult commitToMemory() {
MemoryCommitResult mcr = new MemoryCommitResult();
synchronized (SharedPreferencesImpl.this) {
if (mDiskWritesInFlight > 0) {
mMap = new HashMap(mMap);
}
//我们可以看到在内存中commit值的时候会基于创建SharedPreferences时候得到的map来进行一个copy并写入新值最后写入磁盘中
mcr.mapToWriteToDisk = mMap;
mDiskWritesInFlight++;
省略以下代码....
在这一块上4.4的代码与5.1的代码几乎一致，所以，导致4.4会删除值的原因就在于之前并没有从磁盘中读取到值到内存中。在对值进行copy的时候就"丢失"，从而导致写入进去的新文件里没有以前的旧值，由此现象上来看好像是某些值被删除了，但实际上确切的说应该是被空值所覆盖。
4总结
总的来说，这个问题的根源在于4.X的sdk里允许了往SharedPreferences里写入key为null的值而不允许取出来，并且不仅不能取出来，甚至还在写的过程当中引发了"删除"数据这样灾难性的后果。这样是及其不合理的，所以google在后续的SDK里也对这一块的逻辑修复了。不过，作为一个应用层开发人员，也是需要从自身检讨一下这样的低级错误。毕竟这个错误的后果十分严重，但又无色无味难以发现，以后需要尽可能的避免这样的错误再次发生。
相信通过这样一次从现象入手分析问题到追踪，再到SDK源码比对各版本间的差异，对于自身的水平提高还是有很多的益处的，希望以后还能够这样来分析一些更加深入的问题。当然，最后想说的是，我们还是从自身做起，尽量少犯低级错误，少出bug，做一个高水平的工程师，而不是整天debug的码农。