app文件管理

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

放上demo链接

思路

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

自定义文件管理基础.jpeg

遇到的问题

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

解决方案

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

加入FileManager后的数据流向.jpeg

功能点：重名文件命名

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

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

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