共计 1752 个字符，预计需要花费 5 分钟才能阅读完成。
一、序
之前水群的时候，有个群友在小米手机上，碰到个很奇怪的现象。
在 SP 中持久化的数据，App 卸载重装之后，又被还原了。还原就还原吧，其实也不是什么大事，但是还原的并不是最后一次使用的数据，而是之前不知道什么时候使用的数据，这就变成问题了。
举个例子：这个手机用 A 账户登录了，在 SP 中存储了我们登录的信息，例如 uid、Token 之类的数据，客户端通过这些数据去判断是否登录，也就是说有这些数据可以证明这个用户是有效的登录用户。然后卸载重装，再用 B 账户登录，莫名其妙的再下次启动时，又变回 A 账户了。并且再卸载再重装，还原的还是 A 账户，你说巧不巧？
这个问题的现场，是出现在小米 6x 手机上，系统是 Android 8.0.1。
接下来就是分析这个问题的原因。
二、被还原是谁的锅？
2.1 什么原因？
现象也说了，App 数据被恢复到之前的某个状态了，那肯定不存在“卸载残留”一说，并且也在卸载后查看了应用数据存储的目录，确实已经被清理掉了。
那么猜想应该是被系统备份后还原了，尝试修改 android:allowBackup 属性。
经过试验也验证了这个猜想，确实是被系统备份了，并且在下次安装时还原了。
2.2 什么是 allowBackup？
那么，allowBackup 是干什么的呢？
从名字就可以看出，这其实是一个备份功能。在 Android API level 8 开始引入的系统级备份和恢复功能。
可以通过在清单文件中设置 android:allowBackup 属性，来为其标记开关。在允许备份后，可以通过 adb 命令 adb backup 和 adb restore 来将应用数据进行备份和恢复。该属性默认值为 true。
利用备份功能，我们可以在格式化手机、换机前，将当前手机的很多信息备份一份，之后再进行还原，这其实是为了方便用户的功能。
早期这个属性争议挺大，很重要的一个问题是安全隐患。利用备份功能，可以在 A 手机上对某个 App 进行备份，然后在 B 手机上进行还原。
也就是说，如果 App 本身没有对手机做限制，同时开启了 allowBackup，有人拿到你的手机后，可以将手机上一些 App 备份后再换一台手机还原，这当然是存在一定的安全隐患了。
例如最近比较火的灵魂社交 Soul，allowBackup 就是开启状态。
试想一下，有人拿到我们的手机，将其数据备份后是不是就可以知道我们在与谁的聊天呢？有个懂技术的对象好可怕呀！
我并没有用过 Soul，也没有尝试备份，不确定 Soul 对登录设备有没有判断。
虽说存在隐患，但是大部分情况下还是安全的。因为当我们使用 adb backup 命令备份的时候，是会要求输入密码的。
假如密码已经被泄露了，那就根本不存在安全隐患的问题，因为钥匙就在别人哪儿，锁等于形同虚设。
2.3 自动备份
是不是我们不主动触发备份，就不存在问题呢？并不是。
在安装了 Google Play 服务的手机上，开启备份并且在设置中开启自动备份后，是可以定时自动备份的。
国内的一些厂商，也会在自己的 ROM 中实现备份功能，例如前文提到的小米的 MIUI。
这就引发了备份的数据不可控的问题。在我们开发时，频繁卸载、安装，可能就会在某个时刻恢复到之前备份的数据，这并不是我们想看到的。
遇到这个问题，在清单文件中，关闭备份就好了。
三、小结时刻
一切都是自动备份的锅，没特殊需求，在发布的 App 上，建议显式关闭 allowBackup 属性。
这个服务对开发者是一个黑盒子，它具体什么时机，做了什么，并不是我们开发者可控的，所以索性直接关掉就好了。而且在不同的设备上表现不一致，本身也不是我们想要的功能。
重要的数据应该在线上存储，而不重要的数据，丢了也就丢了。卸载重新安装这种场景，丢一些数据应该是可以接受的。
简单总结一下本文的内容：
android:allowBackup 属性用于标识是否开启备份数据功能。
备份和恢复可以通过 adb 命令主动触发。
当开启云备份时，系统服务（已实现的系统）可能会定期自动备份 App 数据。
系统备份实现机制不透明，建议上线 App 前将这个属性关闭。
虽说是云备份，但断网并不能阻止系统服务恢复备份，应该有缓存（在小米手机上已验证）。
