基于 Android 的文件同步设计方案_android同步文件夹(4)

2301_76223496

已于 2024-04-10 21:49:30 修改

阅读量989

点赞数 13

分类专栏： 2024年程序员学习文章标签： android php 开发语言

于 2024-04-10 21:49:28 首次发布

本文链接：https://blog.csdn.net/2301_76223496/article/details/137612509

版权

2024年程序员学习专栏收录该内容

301 篇文章 0 订阅

订阅专栏

对本地文件的状态，我设计了如下数据结构。新的同步方案中，我选用了 Room 作为数据库框架。因此，以下数据结构也大致对应数据库中的 Shcema，

/** 笔记上次同步状态 /
@Entity class NoteLastSyncState: Serializable {
@PrimaryKey(autoGenerate = true) var id: Long? = null
/* 笔记的路径 /
var path: String? = null
/* 文件相对路径，直接父路径，用来根据父路径找子路径 /
var parent: String? = null
/* 如果文件时移动过来的话，记录从哪里移动过来的 /
var movedFrom: String? = null
/* 服务器返回的上次修改的时间，如果有的话，用来判断远程是否修改过 /
var serverLastModifiedTime: Date? = null
/* 上次同步时的 Md5 值，用来判断上次同步完成之后是否又被改动过 /
var lastSyncMd5: String? = null
/* 备注信息，冗余字段，用 json 存储 /
var remark: String? = null
/* 上次同步的时间 */
var lastSyncTime: Date? = null
}

这里的 path 字段是该文件相对于笔记根目录的路径。parent 是它的父目录相对于笔记根目录的路径。parent 的作用是用来根据父目录查找其所有的子文件/目录。比如下面的 SQL 就是基于前缀的匹配方式查询父目录的子文件/目录的状态，

@Query("SELECT * FROM NoteLastSyncState WHERE path LIKE :parent || ‘%’ ")
fun getUnderParent(parent: String): List

在实际编码之前应该先做技术方案。parent 等字段是在方案确定了基础之上，确定需要用到该字段，才将它们加入到数据结构中的。

这里的 movedFrom 用来记录该文件是从哪个位置移动过来的。在最初设计方案的时候，我本打算让移动行为走删除和新增的逻辑。这种思路虽然可行，但是性能会低。因为每个文件的删除和新增都要请求一次网络。当一个目录下存在很多子孙文件/目录的时候，请求的数量会非常多。因此，这里我使用 movedFrom 标记文件从何处移动而来。然后，在同步的时候，再根据该字段，调用服务器的移动接口，直接在服务器进行移动操作。这样一个请求即可完成同步。对于用户直接通过文件管理器移动目录或者文件的情况，由于不存在 movedFrom 标记，会走删除和新增的逻辑（被移动的位置删除，移动到的位置新增）。

这里的 serverLastModifiedTime 用来记录服务器返回的文件的上次修改时间。因为当我们请求一个目录的信息的时，可以获取到该目录下所有子文件的状态，其中就可能包含文件的上次修改时间。因此，每次同步完成之后，我们会记录该文件的上次修改时间。这样，下次同步的时候，通过对比服务器和本地数据库中的上次修改时间，我们就可以判断远程是否对文件做了修改，而无需使用文件的 md5. 这样就可以大幅提升同步的速率并降低流量的消耗。需要注意的是，这里用到的是服务器的修改时间，因为本地时间是不可靠的。

需要注意的是，我们不能假设服务器一定返回文件的上次修改时间字段。因此，它在新的同步方案中是作为判断逻辑的第一道防线。只有确保该字段一定存在的情况下才会使用它作为判断依据。代码如下所示，

/** Check is file changed remotely by last modified time. */
private fun isFileChangedRemotely(
syncState: NoteLastSyncState,
remoteFile: CloudResource
): Boolean = syncState.serverLastModifiedTime != null
&& remoteFile.lastUpdate != null
&& remoteFile.lastUpdate.after(syncState.serverLastModifiedTime)

/** Check is file not changed remotely by last modified time. */
private fun isFileNotChangedRemotely(
syncState: NoteLastSyncState,
remoteFile: CloudResource
): Boolean = syncState.serverLastModifiedTime != null
&& remoteFile.lastUpdate != null
&& !remoteFile.lastUpdate.after(syncState.serverLastModifiedTime)

最后值得一提的字段是 lastSyncMd5，顾名思义，它是文件的 md5 值，是在文件被写入到本地磁盘之后记录到数据库中的。使用该字段，在远程和本地文件的 md5 不一致的时候，我们可以和之前的方案一样，判断文件是本地还是远程的文件发生了改动。

3、同步方案

3.1 流程图

整个流程图比较长，大致可以几个部分，我已经在图中标出。

顶部是对之前生成的一些文件的删除和对图片信息的同步，属于本软件特有的部分，可以忽略。然后是整体的循环结构。流程图比较复杂，实际编码会清晰一些。即，我是通过 BFS 算法遍历本地文件树进行同步的。在对目录进行遍历的时候会先读取其对应的服务器目录下所有文件的状态以及本地存储的所有子文件的状态到 remoteFiles。然后，通过对比本地的文件状态和远程的文件状态进行同步。一个文件或者目录同步完成之后会从 remoteFiles 中移除。

runBackground(onFinished, onInterrupted) { failures ->
val visitors = mutableListOf(File(path))
val count = AtomicInteger(0)
while (visitors.isNotEmpty() && !interrupted) {
try {
val directory = visitors.removeAt(0)
val dirRelativePath = sm.relativePathOf(directory.path)

// Read contents of directory from cloud.
val listResult = server.list(dirRelativePath)
val remoteFiles: MutableMap<String, CloudResource> = if (listResult.isFailed) {
log { “failed to read contents of directory [ $d i r R e l a t i v e P a t h] f ro m c l o u d, co d e [$ {listResult.code}], msg [${listResult.message}] .” }
val synced = syncDirectoryWhenFailedReadRemotely(directory, failures)
if (synced) {
continue
}
mutableMapOf()
} else {
insertDirectoryLastSyncState(directory)
listResult.data.toMutableMap()
}

// Read last sync records from local database.
val syncRecords = mutableMapOf<String, NoteLastSyncState>()
DB.get().noteLastSyncStateDao().getByParent(dirRelativePath).forEach {
syncRecords[it.path ?: “”] = it
}

// Travel under directory and handle files.
directory.listFiles()?.forEach { file ->
if (interrupted) {
return@forEach
}

val fileRelativePath = sm.relativePathOf(file.path)

// Files should be ignored.
if (fileRelativePath == “/ $SETTING_FOLDER_NAME/$ SETTING_IMAGE_MODEL_DATA”) {
return@forEach
}

val syncRecord = syncRecords[fileRelativePath]

if (file.isDirectory) {
visitors.add(file)

// The directory exists in cloud: remove from remote files.
if (remoteFiles.containsKey(fileRelativePath)) {
remoteFiles.remove(fileRelativePath)
}
} else if (file.isFile) {
Thread.sleep(timeDelayMillis.toLong())
val remoteFile = remoteFiles[fileRelativePath]

// Sync a single file.
syncFile(file, syncRecord, remoteFile, failures)

if (remoteFile != null) {
remoteFiles.remove(fileRelativePath)
}
notifyProgressChanged(count.addAndGet(1), onProgress)
}
}

// Handle left remote resources.
syncRemoteResourcesNotFoundLocally(remoteFiles, failures, count, onProgress)
} catch (t: Throwable) {
t.printStackTrace()
log { “failed to sync folder with exception: $t” }
}
}
}

remoteFiles 剩下的部分就是远程存在而本地不存在的文件或者目录。它们又可能存在几种情况，被本地删除、远程新增或者被本地移动到其他目录。然后，再根据数据库中的状态记录，对三种情况进行判断。

具体同步流程代码比较长，不便于贴出，后续我会将文件同步逻辑提取出来，开源出一个通用的框架。