很多app都有展示文件的需求，不需要额外添加信息的话，可以直接读取用户磁盘目录下的所有文件展示给用户。但是要给文件赋予定制属性（比如文件来源），就要建立自己的文件系统。本文主要讲述自定义文件系统和遇到的一些问题。

放上demo链接

思路

  • 数据库中存储自定义的文件信息和文件路径
  • 读取数据库，展示文件信息
  • 需要时，根据数据库存储的地址找到对应文件



遇到的问题

  • 文件更新丢失
    比如【文件列表页面】和【收发记录页面】都从数据库中分别取出了文件模型，两个页面分别对文件做了更新，这个时候先更新到数据库的部分就会被后面的更新覆盖。
  • 更新界面困难
    每次数据更新，要把所有更新写入数据库，再通知首页从数据库中重载数据更新界面，如果是像进度条这样需要频繁更新的需求，会很卡。

解决方案

  • 在数据库和业务之间，加一层中间件（FileManager）。
    FileManager保证了每一条数据库中的数据只对应一个内存中的数据模型，确保所有更改都是在同一份数据上进行
  • 在使用中间件的基础上，使用kvo绑定数据和界面
    更新界面有三种选择
  • 方法一：每次更新都使用 [tableview reloadData]
    缺点：增加不必要损耗，如果界面上有更新进度条，会频繁reloadData；每次数据更新都需要手动调用更新界面的方法
  • 方法二：使用delegate或者block更新特定cell
    缺点：每次数据更新都需要手动调用更新界面的方法
  • 方法三：kvo
    缺点：易崩溃，推荐使用FBKVOController



其他功能点：重名文件命名

目标效果：导入了“xxx.png”，第二次导入会变成“xxx-1.png”，第三次导入变成“xxx-2.png”。 这样判断重名需要两个材料：1）基础名 2）重名后缀 获取这两个材料我们有两种方式：

  1. 实时计算 按照重名规则截取文件名，实时复原文件基名（基本文件名）和index（重名后缀）
  2. 存储 在新建文件模型的时候，就存储文件重名index，和基名

个人倾向使用存储的方式，这样能将展示名和重名数据分开，每次展示的时候根据基础名和后缀灵活组建文件名