我读了这篇文章https://medium.com/@ianhlake/hidden-gems-of-android-o-7def63136629。这就是那里写的：
SharedPreferences已经死了。累积的SharedPreferences。
SharedPreferences会继续在Android O中工作吗？我们是否需要通过实现PreferenceDataStore来实现自己的机制来存储键值对中的数据
任何人都可以帮助如何使用SharedPreferences实现新的PreferenceDataStore＆开发自己的实现的用例是什么？目前的方法有任何缺点吗？
我不能想到它只适用于完全使用PreferenceDataStore而不是SharedPreferences的情况，但我认为如果你想一起使用它们会有所帮助。
SharedPreferences为您提供了一项出色的服务，即当您的应用程序更新时，数据仍保留在首选项中，但使用PreferenceDataStore，您还可以使用与SharedPreferences相同的格式存储数据。现在假设您想要使用相同的首选项界面，但是您希望将这些值存储在云中而不是设备中，因为设备可能会崩溃。
PreferenceDataStore可以帮助您的是它为您提供了在任何地方存储数据的灵活性并编写您自己的实现。它并不意味着完全取代SharedPreferences，但如果你愿意，你也可以这样做。
例如，您可以在共享首选项中使用应用程序的访问令牌，并在云或本地数据库或云或文件系统中使用所有其他数据（如果需要），并且可以使用PreferenceDataStore接口，记下您自己的实现，然后用它。
甚至在Google PreferenceDataStore https://developer.android.com/reference/android/preference/PreferenceDataStore.html中的开发者文档链接中也写了
在大多数情况下，您希望使用SharedPreferences，因为它会自动备份并迁移到新设备。但是，如果您的应用将其首选项存储在本地数据库，云中，或者它们是特定于设备的“开发人员设置”，则向首选项提供自定义数据存储非常有用。当您想要使用首选项UI时，它可能也很有用，但数据不应该存储，因为它们仅在每个会话中有效。
所以你可以看到，即使谷歌也不希望你一直使用PreferenceDataStore，它只是在你需要使用相同的Preferences风格存储键值对的时候，但你想要实现自己的数据存储将为您提供比目前在SharedPreferences中更多的灵活性。
例如，如果您想要获取SharedPreferences，然后将SharedPreferences数据放在云服务器上，该怎么办？您希望它在设备上，但也在云上备份，在这种情况下，PreferenceDataStore可以帮助您。
你应该放弃以封面来判断这本书的坏习惯，而不是仅仅从引人注目的章节标题中得出结论，只需完全阅读上述帖子即可。
在Android Oreo中甚至不赞成共享首选项，Ian Lake提到的是一项改进，它允许您的应用程序保持与现在相同的简单键/值对API，但另外能够提供您自己的数据存储实现所述数据（即Firebase，远程服务器等）。如果您不需要，那么您可以直接使用共享首选项，因为您没有对代码进行任何更改，并且此类用例没有真正改变。
我想你在这里读书。 SharedPreferences未被弃用。然而，他们遇到了相当多的问题，因此在Android O中，PreferenceDataStore接口旨在为开发人员提供开发自己实现的选项，而不是使用SharedPreferences。从docs你可以打电话给setPreferenceDataStore和
如果设置了数据存储，则首选项将不再使用SharedPreferences。
所以我认为他在帖子中的意思是你现在有一个内置的方式来推出你自己的提供商来克服SharedPreferences的缺点
我认为你得出了一个错误的结论，Shred Preferences在Android O中运行良好。
在Android O中，个人首选项甚至整个PreferenceManager都可以调用setPreferenceDataStore（），允许您的应用程序保持相同的简单键/值对API，但提供自己的机制来存储基础数据。
从这个link读