一个null引发的SharedPreference惨案
来源:互联网 发布:广州商学院网络教学 编辑:程序博客网 时间:2024/05/16 09:19
序
*本篇文章已授权微信公众号 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"); }}
存储一个正常的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<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"); }
我们可以看到明显的区别是,这里没有对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++; 省略以下代码....
在这一块上4.4的代码与5.1的代码几乎一致,所以,导致4.4会删除值的原因就在于之前并没有从磁盘中读取到值到内存中。在对值进行copy的时候就”丢失”,从而导致写入进去的新文件里没有以前的旧值,由此现象上来看好像是某些值被删除了,但实际上确切的说应该是被空值所覆盖。
4总结
总的来说,这个问题的根源在于4.X的sdk里允许了往SharedPreferences里写入key为null的值而不允许取出来,并且不仅不能取出来,甚至还在写的过程当中引发了”删除”数据这样灾难性的后果。这样是及其不合理的,所以google在后续的SDK里也对这一块的逻辑修复了。不过,作为一个应用层开发人员,也是需要从自身检讨一下这样的低级错误。毕竟这个错误的后果十分严重,但又无色无味难以发现,以后需要尽可能的避免这样的错误再次发生。
相信通过这样一次从现象入手分析问题到追踪,再到SDK源码比对各版本间的差异,对于自身的水平提高还是有很多的益处的,希望以后还能够这样来分析一些更加深入的问题。当然,最后想说的是,我们还是从自身做起,尽量少犯低级错误,少出bug,做一个高水平的工程师,而不是整天debug的码农。
- 一个null引发的SharedPreference惨案
- 一个null引发的SharedPreference惨案
- 一个null引发的SharedPreferences惨案
- 一个电阻引发的惨案
- 一个反射引发的异常惨案
- 一个组件注册失败引发的惨案
- 一个由API level引发的惨案
- 一个 Google 汉堡引发的惨案
- const引发的惨案
- 一个css的大括号引发的惨案
- 谓词推入引发的惨案
- realloc函数引发的惨案
- 更换jdk引发的惨案
- VS2010下注释引发的惨案
- SQL Server Collation引发的惨案
- 一条sleep语句引发的惨案
- 由sp单位引发的惨案
- javascript:一次alert引发的惨案
- PHP文件操作 - 替换某行,插入某行,删除某行,获取行号
- MyBatis学习总结(一)——MyBatis快速入门
- Matlab生成各种伪随机信号_idinput指令
- JS之鼠标移入移出事件2
- Java 程序员必备学习资源
- 一个null引发的SharedPreference惨案
- 手机助手(四):复杂的ListView + 自定义控件
- Android 面试相关总结
- Android逆向实例笔记—初入so并还原分析出代码
- 跟我一起学python(八),网络编程(基础篇)
- Java开发工具_Eclipse中构造方法和get_set方法的自动生成
- Java语言基础
- hdu5938 Four Operations(贪心)
- Java设计模式之——工厂方法模式