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

最新推荐文章于 2024-10-11 16:17:20 发布

2401_84132685

最新推荐文章于 2024-10-11 16:17:20 发布

阅读量311

点赞数 4

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

本文链接：https://blog.csdn.net/2401_84132685/article/details/138385132

版权

程序员专栏收录该内容

432 篇文章 0 订阅

订阅专栏

在实际编码之前应该先做技术方案。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 [$dirRelativePath] from cloud, code [${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 剩下的部分就是远程存在而本地不存在的文件或者目录。它们又可能存在几种情况，被本地删除、远程新增或者被本地移动到其他目录。然后，再根据数据库中的状态记录，对三种情况进行判断。

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

3.2 类设计

由于后续考虑支持更多的云服务器，所以，在新的同步方案中，我也对类结构进行了设计。首先是针对服务器的设计，

/** 云同步服务器接口封装 */
interface ICloudServer {

    /** 读取文件内容 */
    fun readText(rp: String): Resources<String>

    /** Write text to given file with relative path [rp]. */
    fun writeText(text: String, rp: String): Resources<Boolean>

    /** Read bytes of a cloud file. */
    fun readBytes(rp: String): Resources<ByteArray>

    // .....
}

这个类中定义了服务器需要实现的方法。比如，WebDAV 对应的实现是 WebDAVServer. 当后续需要支持 OneDrive 同步的时候，基于该接口进行实现即可。

另外是同步工作类，也是以上流程图逻辑存在的地方。这里定义了 ICloudSyncWorker 这个接口，

interface ICloudSyncWorker {

    /**
     * Sync a file.
     *
     * @param file the file to sync
     * @param syncRecord note last sync state, might be null
     * @param remoteFile the file info in cloud server
     * @param failures the failures to report, failures will be added to this list.
     */
    fun syncFile(
        file: File,
        syncRecord: NoteLastSyncState?,
        remoteFile: CloudResource?,
        failures: MutableList<ISyncManager.SyncFailure>
    )

    // ...
}

ICloudSyncWorker 中再引用 ICloudServer 进行网络请求。这样，我们就提高了以上同步流程的拓展性。类结构如下，

总结

根据以上分析和实际测试结果，第一次同步的时候，两个方案速率相近，而第一次同步完成之后，新的方案效率就高得多。因为第一次同步的时候，两种同步方案可能都需要对远程的全部文件进行拉取。而第一次之后，新的同步方案只需要判断文件的上次修改时间，因此请求的数量和所有目录、子孙目录的数量相近（每次至少请求一次目录下的文件/目录信息）。实际测试结果表明，600 个文件同步一次只需要 60s （其中，为避免向服务器请求过于频繁，每个文件处理延时时间为 50ms）.

以上就是基于 Android 系统的文件同步设计思路的分享。