一、前言
我在使用我们的App的时候发现发送文件的时候,从进入文件选择界面到文件完全加载出来,时间过长,大概10s左右,然后我想这个是否可以优化一下,然后进过自己查资料,瞎搞,弄出啦了。下面不多说,先上效果图(实现的UI可以各位自行实现,我这里只是提供文件扫描功能的实现)。
- 说明:
我们这个文件扫描是基于 https://github.com/DroidNinja/Android-FilePicker 这个开源框架的(这个框架还不错,可以对文件进行归类),这里只是进行了优化。
- 效果图如下:
- 优化思路:
1、基于原有的方案,优化代码;
2、在不改变原有框架的前提下,寻找替代原有扫描文件方法的方案;
3、剔除原有的扫描文件方案,找一个更优的框架进行替换。
二、思路实现说明
2.1 剔除原有的扫描文件方案,找一个更优的框架进行替换
该方案被第一个排除:
i、因为之前框架涉及的代码比较多,改动可能比较大,担心影响功能
ii、看了一些框架,对比于原有的,不符合原有设计需求
2.2 在不改变原有框架的前提下,寻找替代原有扫描文件方法的方案
我在网上看了一个大牛的扫描方案 https://blog.csdn.net/bingjianit/article/details/78822490,大家可以看一看。他的大体思路如下:
i、扫描全盘文件,剔除隐藏文件或者文件夹。
ii、将文件夹存入专门存放文件夹的队列中,并且为每个文件夹创建一个线程,将当前的文件夹中的指定文件存入集合中
iii、开启线程池,执行所有线程,执行效果类似于第二步,直到所有文件夹都遍历完(直到所有线程执行完毕),将所有文件输出。
我将该方案替代我之前的扫描方案的代码中,运行发现扫描的速度与之前方案对比,扫描速度似乎更慢。我猜测问题可能是线程过多。经过查看原方案的代码,并与这个方案进行对比,排除了这个方案。2.3 基于原有的方案,优化代码
排除了上面两个方案,那只能改进现有代码了(回到原地),通过查看原有方案的扫描文件的源码,发现该方案的实现方式是通过contentprovider进行查询(由此确定可能该实现方法可能是最快的),经过查询资料发现contentprovider存储文件的方式类似于数据库(好久没用这个contentprovider,忘了,哈哈),我后来发现这个查询文件是不是可以通过mime_type这个字段进行查询,然后下面就开始进入正文:
首先先给一个各种文件对应的mime_type的链接 https://blog.csdn.net/mazaiting/article/details/78129532,这里面包好了.doc .mp4等等文件对应的mime_type。
下面看扫描文件的核心方法:
context.getContentResolver().query(uri,
projection,
selection,
selectionArgs,
MediaStore.Files.FileColumns.DATE_ADDED + " DESC");
说明:该方法类似于数据库查询的方法。它有5个参数,这些参数我这里只做简单的描述,具体的大家可以自己自行百度。
参数 | 描述 | 举例 |
---|---|---|
uri | 内容提供者中文件的路径 | 比如:音频(MediaStore.Audio.Media.EXTERNAL_CONTENT_URI) |
projection | 需要查询出来的列 | 文件的_id 文件的大小等 |
selection | 查询的条件 | 指定一个查询的条件,比如 selection = “mime_type = ?”; |
selectionArgs | 查询的条件的值 | 比如:selectionArgs = new String[]{“video/mp4”}; |
sortOrder | 排序 | 比如:MediaStore.Files.FileColumns.DATE_ADDED + ” DESC” |
下面贴实现代码(导包移除):