Android之FileProvider详解

简介

Android 7.0 之前,文件的 Urifile:// 形式提供给其他 app 访问。

Android 7.0 之后,分享文件的 Uri 发生了变化。为了安全起见,file:// 形式的Uri 不能正常访问。官方提供了 FileProviderFileProvider生成的Uri会以content://的形式分享给其他app使用。

content形式的Uri可以让其他app临时获得读取(Read)和写入(Write)权限,只要我们在创建 Intent 时,使用 Intent.setFlags() 添加权限。只要接收Uriapp在接收的Activity任务栈中处于活动状态,添加的权限就会一直有效,直到app被任务栈移除。

目的

7.0 以前,为了访问 file:// 形式的 Uri,我们必须修改文件的权限。修改后的权限对所有 app 都是有效的,这样的行为是不安全的。content://形式的UriAndroid的文件系统更安全,对于分享的文件,接收方 app 只拥有临时的权限,减少了我们app内部的文件被其他 app 恶意操作的行为。

使用

创建FileProvider

manifest文件<application>标签中添加pvodier标签,配置如下。

android:name指定Provider所在的位置。官方自带的FileProvider已经相当完善,所以我们不需要像ServiceBroadcast一样自定义,直接使用自带的就行,直接输入privoder会自动出现提示。

android:authorities相当于一个用于认证的暗号,在分享文件生成Uri时,会通过它的值生成对应的Uri。值是一个域名,一般格式为<包名>.fileprovider

android:exported设置为falseFileProvider不需要公开。

android:grantUriPermissions设置为true,这样就能授权接收端的app临时访问权限了。

设置共享目录

res/xml中创建一个资源文件(如果xml目录不存在,先创建),名字随便(一般叫file_paths.xml)。

<paths>必须有1个或多个子标签,每个子标签代表要请求的私有文件目录。不同的子标签代表不同的目录类型。

<provider>标签中添加<meta-data>子标签。

设置<meta-data>的属性android:name值为android.support.FILE_PROVIDER_PATHS,属性android:resouce的值为刚才我们创建的path文件名。

配置paths

<paths>的每个子标签必须有path属性,代表content Uris的路径。name不需要和path保持一样,只是一个名称。

子标签有以下几种。

files-path

代表内部存储的files目录,与Context.getFilesDir()获取的路径对应。

最终生成的Uri格式为:authorities/pathname/filename

示例:

cache-path

代表内部存储的cache目录,与Context.getCacheDir()获取的路径对应。

external-path

代表外部存储(sdcard)的cache目录,与Environment.getExternalStorageDirectory()获取的路径对应。

external-files-path

代表app的外部存储的根目录,与Context#getExternalFilesDir(String) Context.getExternalFilesDir(null)获取的路径对应。

external-cache-path

代表app外部缓存区域的根目录,与Context.getExternalCacheDir()获取的路径对应。

external-media-path

代表app外部存储媒体区域的根目录,与Context.getExternalMediaDirs()获取的路径对应。

注意: 这个目录只在API 21(也就是Android 5.0)以上的系统上才存在。

生成Content Uri文件

为了让其他app使用Content Uri,我们的app必须提前生成Uri

这里注意获取目录,在配置paths时我们讲了,paths的子标签必须和获取目录的代码保持对应。这里我们用的是Context.getFilesDir(),所以paths文件中必须包含files-path子标签,不然别的app获取uri时会出现异常。

最终生成Uri是使用的FileProvider.getUriForFile()。第一个参数就是provider中设置的authorities属性值。

授权临时权限

分享一般只有这读取和写入2种权限,根据需要传入Intent.addFlags()中。

Uri传入Intent

有好几种传入的方式,根据不同的场景使用不同的方式。

为邮箱app分享附件文件

其他分享

使用Intent.setDateIntent.setClipData()

最后使用startActivity(intent)启动分享操作。

参考链接


Android之FileProvider详解

解决mysql导入数据文件过慢的问题

目前遇到一个问题,mysql 使用 source 命令导入  *.sql  数据文件时,运行的很慢,大概一秒钟插入一两百条左右的样子,对于大的文件来说这个太慢了。

1.登入mysql

2.查看mysql中对于参数 innodb_flush_log_at_trx_commit 的配置

3.修改

修改完成后在次执行相同的文件,200M大约200w+条的数据在1分钟左右。

对于该参数的不同值的说明:

1.innodb_flush_log_at_trx_commit参数为 0
        binlog_group_flush && thd_flush_log_at_trx_commit(NULL) == 0 条件成立,因此直接return了,那么这种情况下log_buffer_flush_to_disk函数不会调用,因此不会做redo刷盘。依赖master线程。
    2.innodb_flush_log_at_trx_commit参数为 1
        !binlog_group_flush || thd_flush_log_at_trx_commit(NULL) == 1 返回为1即为True,因此调用log_buffer_flush_to_disk(True),因此需要做redo刷盘,也要做sync。
    3.innodb_flush_log_at_trx_commit参数为 2
        !binlog_group_flush || thd_flush_log_at_trx_commit(NULL) == 1 返回为0即为Flase,因此调用log_buffer_flush_to_disk(Flase),因此需要做redo刷盘,不做sync。依赖OS的刷盘机制。

参考例子如下:

实际测试结果感觉还是不够快。

参考链接