plus.io
2020-10-18 本文已影响0人
扶不起的蝌蚪
很久没写文章了,最近深入研究了下io
方面的问题,发现5+API
还是很强大的。
Android系统限制
Android 10+
Android 10
系统开始 进一步增强了平台功能,为外部存储设备上的应用和用户数据提供了更好的保护。作为这项工作的一部分,平台引入了进一步的改进,以简化向分区存储的转换,让用户更好地控制自己的文件,保护用户隐私数据,并限制文件混乱情况。
Android 11
在基础上限制了应用访问其他应用的文件。
分区存储
概念
先说一下为什么会有分区存储这个机制出现。
在分区存储之前,某些应用中,即使功能很简单,大部分都不需要这么宽泛的权限,这就使得某些应用程序:
1、乱占空间 :各种各样的文件散布在磁盘的各个地方,当用户卸载应用之后,这些被遗弃的文件被滞留在原地,无人管理,占用了磁盘空间,最终结果就会导致磁盘不足
2、随意读取用户的数据
3、随意读取应用的数据
因此诞生了,也可以把它叫做。
是一种安全机制,用于防止应用读取其他应用的数据。
- 每个应用程序都有自己的存储空间。
- 应用程序不能翻过自己的目录,去访问系统公共目录。
- 应用程序请求的数据都要通过权限检测,不符合要求不会被放行。
分区存储机制下uni-app/5+ 开发者的影响
-
android 9
及以下系统未做分区存储,除其他应用的内部存储空间不可以读写,其他任意存储目录下的资源文件都可以正常读写操作。 -
android 10
仅对targetSdkVersion
>=29则会开启分区存储。targetSdkVersion
<29则不会有任何限制与android9
及以下同理。 -
andorid 11
强制执行分区存储。不允许应用读写操作非应用沙盒目录和系统公共目录下的资源文件。
dcloud已对分区存储机制做了适配工作。但也增加了开发者对文件目录操作的规则。在分区存储的环境下分出两个可操文件数据目录和
目录分析
android的目录在开发APP所涉及到的有和
下面又分为和
系统公共目录
主要包括Downloads
、Documents
、Pictures
、DCIM
、Movies
、Music
等。
- 公共目录的文件在App卸载后,不会删除
- 如系统相册可以通过
plus.gallery.pick
获取 -
拥有权限,也能通过路径直接访问
plus.gallery.pick(successCB=>{})选取图片效果
系统公共目录缺陷:
- 仅支持读取媒体文件 如:音频文件、视频文件、图片文件。其他类型文件不支持!!!!
- 创建的文件是公用的,你需要确保你的文件命名是惟一的。否则会出现名称对应不上的问题。多数重命名会文件名尾部(i++)处理
- 不可随意删减。该文件谁创建的谁才有权限删除修改。如果不是当前应用创建的文件是无权权限删改的。
删减文件会被系统认为恶意操作。将会弹通知栏。告诫手机用户当前XXX应用删除了什么文件。
如果需要其他第三方读取我们开发的APP的文件怎么办?
-
5+APP
和5+APP
可以通过plusAPI
读取对方应用的应用公共
目录,所以将图片等资源拷贝到应用公共目录下。第三方5+APP应用才有权读取该文件。进行操作业务逻辑。 - 如果第三方APP是非5+APP,需要将图片等资源拷贝到
系统公共
目录下。别的三方应用才有权读取该文件。进行操作业务逻辑。
应用沙盒存储(分区存储)目录
分区存储主要包括应用的公有目录和应用的私有目录
- 公有目录(多个
5+ App
或uni-app
时(如小程序SDK),所有5+ App
或uni-app
都可进行读写操作,就是该目录只能Dcloud
的APP才能访问,其他框架的APP和原生APP无法访问此目录)
plus.io.PUBLIC_DOCUMENTS
:应用公共文档目录
fileSystem
注意的是当我们请求这个公共目录的时候,它不会创建显示出来,只有当我们在这个文件夹下面创建文件或者目录的时候,这个document
目录才会出来
plus.io.requestFileSystem(plus.io.PUBLIC_DOCUMENTS, fileSystem => {
console.log(fileSystem.name);
});
//PUBLIC_DOCUMENTS
plus.io.requestFileSystem(plus.io.PUBLIC_DOCUMENTS, fileSystem => {
fileSystem.root.getDirectory('testCommonEntry', {
create: true,
exclusive: false
})
});
documents目录出现
testCommonEntry测试公共目录
plus.io.PUBLIC_DOWNLOADS
:应用公共下载目录
fileSystem
注意的是当我们请求这个公共目录的时候,它不会创建显示出来,只有当我们在这个文件夹下面创建文件或者目录的时候,这个downloads
目录才会出来
plus.io.requestFileSystem(plus.io.PUBLIC_DOWNLOADS fileSystem => {
console.log(fileSystem.name);
});
//plus.io.PUBLIC_DOWNLOADS
plus.io.requestFileSystem(plus.io.PUBLIC_DOWNLOADS, fileSystem => {
fileSystem.root.getDirectory('testDownloadEntry', {
create: true,
exclusive: false
})
});
downloads
testDownloadEntry测试公共目录
- 私有目录(仅应用自身可读/写)
plus.io.PRIVATE_WWW
:应用所有资源保存到此目录,仅本应用可访问。 为了确保应用资源的安全性,通常此目录只可读
。
官方基座
和自定义基座
不需要进行plus.io
操作即可看到WWW
目录
www目录
但是注意正式包
看不了www
目录
正式包没有WWW目录
如何才能看到WWW目录呢,需要将应用设置为释放资源模式才能访问此目录,配置方法:
- uni-app项目,在
manifest.json
的app-plus
节点下添加"runmode":"liberate"
- 5+ App项目,在
manifest.json
的plus
节点下添加"runmode":"liberate"
不过本人测试的APP中有些有WWW目录,有些还是没有WWW目录,不知道是什么原因,以后再分析吧
plus.io.PRIVATE_DOC
:应用私有文档目录,仅本应用可读写
doc目录
这个目录没啥好说的,不需要配置或者用plus.io即可正常看到该目录
uni.downloadFile
和uni.saveFile
分析
直接上代码,我们去手机目录看
const downloadTask = uni.downloadFile({
//仅为示例,并非真实的资源
url: 'http://img.netbian.com/file/2019/0414/7bee7eef5fc44417a0b02a46576e7e16.jpg',
success: res => {
if (res.statusCode === 200)
uni.saveFile({
tempFilePath: res.tempFilePath,
success: red => {
this.luj = red.savedFilePath
}
});
}
});
第一次uni.downloadFile
官方注明了:文件的临时路径,在应用本次启动期间可以正常使用,如需持久保存,需在主动调用 uni.saveFile,才能在应用下次启动时访问得到**
我们第二次启动APP,再进行一次下载看会发生什么
第二次uni.downloadFile
可以看到将第一次的download目录删除了,重新生成了一个下载的目录,所以为了持久存储,uni.saveFile出现了。
uni.saveFile目录