android 文件存储注意点

android 文件存储官方文档：https://developer.android.com/guide/topics/data/data-storage.html#AccessingExtFiles

多次读，收获也不一样。

1.SharedPreferences 

   commit()和apply();

  二者区别：

apply() ：Commit your preferences changes back from this Editor to the SharedPreferences object it is editing. This atomically performs the requested modifications, replacing whatever is currently in the SharedPreferences.

Note that when two editors are modifying preferences at the same time, the last one to call apply wins.

Unlike commit(), which writes its preferences out to persistent storagesynchronously, apply() commits its changes to the in-memorySharedPreferences immediately but starts an asynchronous commit to disk and you won't be notified of any failures. If another editor on thisSharedPreferences does a regular commit() while a apply() is still outstanding, the commit() will block until all async commits are completed as well as the commit itself.

As SharedPreferences instances are singletons within a process, it's safe to replace any instance of commit() with apply() if you were already ignoring the return value.

You don't need to worry about Android component lifecycles and their interaction with apply() writing to disk. The framework makes sure in-flight disk writes from apply() complete before switching states.

The SharedPreferences.Editor interface isn't expected to be implemented directly. However, if you previously did implement it and are now getting errors about missing apply(), you can simply call commit() from apply().

added in  API level 1

boolean commit ()

Commit your preferences changes back from this Editor to the SharedPreferences object it is editing. This atomically performs the requested modifications, replacing whatever is currently in the SharedPreferences.

Note that when two editors are modifying preferences at the same time, the last one to call commit wins.

If you don't care about the return value and you're using this from your application's main thread, consider using apply() instead.

2.内部存储

1. 使用文件名称和操作模式调用 openFileOutput()。 这将返回一个 FileOutputStream。
2. 使用 write() 写入到文件。
3. 使用 close() 关闭流式传输。

String FILENAME = "hello_file";
String string = "hello world!";

FileOutputStream fos = openFileOutput(FILENAME, Context.MODE_PRIVATE); //标注的重点，

FILENAME 切记不要随意命名，Context.MODE_PRIVATE 模式下会删掉重名的文件，重新创建新的文件，弄不好把系统中其他同志保存的文件给干掉了，最好以模块名称+随机4位数+作者来命名。

fos . write ( string . getBytes ()); fos . close ();

实际的例子中

API 17 中去掉了常量 MODE_WORLD_READABLE 和 MODE_WORLD_WRITEABLE，

MODE_PRIVATE 将会创建文件（或替换具有相同名称的文件），并将其设为应用的私有文件。 其他可用模式包括：MODE_APPEND、MODE_WORLD_READABLE和 MODE_WORLD_WRITEABLE。

注：自 API 级别 17 以来，常量 MODE_WORLD_READABLE 和 MODE_WORLD_WRITEABLE 已被弃用。从 Android N 开始，使用这些常量将会导致引发 SecurityException。这意味着，面向 Android N 和更高版本的应用无法按名称共享私有文件，尝试共享“file://”URI 将会导致引发FileUriExposedException。 如果您的应用需要与其他应用共享私有文件，则可以将 FileProvider 与 FLAG_GRANT_READ_URI_PERMISSION 配合使用。另请参阅共享文件。

保存缓存的文件

如app中需要保存页面临时的数据，防止下次加载网络不好情况下能展示出内容

如果您想要缓存一些数据，而不是永久存储这些数据，应该使用 getCacheDir() 来打开一个 File，它表示您的应用应该将临时缓存文件保存到的内部目录。

当设备的内部存储空间不足时，Android 可能会删除这些缓存文件以回收空间。 但您不应该依赖系统来为您清理这些文件， 而应该始终自行维护缓存文件，使其占用的空间保持在合理的限制范围内（例如 1 MB）。 当用户卸载您的应用时，这些文件也会被移除。

打开file之后，创建我们保存页面的临时文件夹，保存文件，控制这个文件夹的大小，最好在10M以内。保存最近一次加载的文件，删除以前的（根据实际情况来操作）。

私有文件存储是不需要申请权限的。