# dlocalshare

**Repository Path**: DragonCodingPlus/dlocalshare

## Basic Information

- **Project Name**: dlocalshare
- **Description**: 局域网传文件工具。
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2026-06-11
- **Last Updated**: 2026-06-11

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# DLocalShare：为什么我又造了一个局域网传文件的轮子

## 起因

传文件这件事，放在 2026 年依然是个问题。

微信传文件会压缩图片视频，QQ 传大文件限速限大小，AirDrop 只在苹果生态里好用，跨安卓和电脑就只能靠数据线或者网盘中转。我试过不少传文件工具，有的要手动输 IP 地址，有的一断就得从头开始，还有的恨不得让你开会员。

所以我自己做了一个。DLocalShare，Android 端的局域网文件传输应用。

## 它做了什么

DLocalShare 只做两件事：**发现设备**和**传输文件**。没有文件管理，没有云备份，没有社交分享。打开应用，看到局域网里开着同样应用的其他设备，选文件，发送。就这么多。

但这两件事做得比较讲究。

### 设备发现：组播，不用输 IP

很多局域网传输工具需要你手动输入对方 IP 地址。192.168.1.xxx 这种，输错一位就连不上。DLocalShare 用的是**组播（Multicast）**，每台设备启动后周期性地往组播地址广播一条服务注册消息，带上自己的设备名和 IP。同时也在监听这个地址，收到别人的注册消息就知道对方在线。

所以你一打开应用，设备列表就有了。对方上线、下线都能看到。全程不需要手动输入任何东西。

### 文件传输：TCP 直连 + Block 分块 + 多线程 + 断点续传

发现设备之后走 TCP Socket 直连传输。为什么不用 UDP？因为传文件对数据完整性和顺序要求高，TCP 自带确认重传和流量控制，没必要自己再造一个可靠传输层。

文件不是整体一次性传过去的，而是**切分成固定大小的 Block**，每个 Block 在独立线程里并发发送。这么做有几个好处：

1. **多线程加速**——几个 Block 同时传，充分利用局域网带宽。千兆网络下，单线程串行传根本跑不满带宽，多线程才能打满。
2. **断点续传**——Block 是续传的最小单位，中断后只重传没完成的 Block，传过的不用再传。
3. **内存友好**——大文件不用一次性加载进内存，按 Block 流式读取。

Block 数据帧的结构也很直白：头部携带文件的偏移量和大小，接收端拿到头信息就知道这个 Block 要写到文件的哪个位置。用 RandomAccessFile 定位写入，不需要在内存里拼完整文件。

### 断点续传的握手协议

断点续传不是简单地"断了接着传"，它需要一个轻量的握手协议来确定从哪里开始：

1. **查询帧**：传输开始前，发送端先发一个查询帧过去，问"这个文件你收到哪了？"
2. **反馈帧**：接收端回复反馈帧，告诉发送端已经收到了多少数据。
3. **定位续传**：发送端根据反馈定位文件的读取位置，接着上次断开的地方读取数据发送。接收端也根据 Block 头信息定位到对应位置写入。

就这样，三步握手，然后接着传。已完成的 Block 不会重复发送，进度精确到 Block 级别。

整个流程就是：查询 → 反馈 → 定位 → 发送 → 定位 → 写入。循环到文件传完。

## 怎么用

接收端什么都不用做。打开应用，默认就在接收模式。

发送端在系统图库或文件管理器里选文件，分享菜单里选 "DLocalShare"，或者在应用内选择目标设备发送。接收的文件默认存在下载目录，用户可以在主界面改保存位置。

文件传完之后应用就不管了。想看文件去系统文件管理器，想删去系统相册。DLocalShare 不维护文件列表，不建数据库，不缓存索引——它不是文件管理器，它是传输工具。

## 技术选型上的一点想法

为什么用组播不用 mDNS 或 NSD？组播更底层，可控性更好。mDNS 和 Android 的 NSD（Network Service Discovery）封装了不少东西，但也引入了一些不可控因素，比如某些路由器对 mDNS 的支持不太稳定。直接基于 UDP 组播自己做服务注册和发现，协议结构完全可控，出问题也好排查。

TCP vs UDP：翻来覆去还是选了 TCP。局域网内延迟本来就不高，TCP 的可靠传输特性对文件传输是刚需。有人说可以 UDP + 自定义重传，但那就等于自己实现了一个劣化版的 TCP，没必要。

Block 大小：这个做了测试，太小了线程切换开销大，太大了断点续传精度不够。最后选了一个中间值，在千兆局域网下能跑满带宽，中断后续传也足够精确。

## 和微信/QQ 传文件的区别

微信会把图片视频压缩，QQ 有限速和文件大小限制，而且数据都要过服务器。DLocalShare 是纯局域网直连，速度取决于你的路由器（百兆/千兆），不压缩文件，不限大小。文件数据从不离开你的局域网。

## 结束

DLocalShare 是极简主义的产物。不做管理，不建索引，不开会员，不弹广告。组播发现设备，TCP 直连传输，Block 分块多线程加速，查询/反馈帧断点续传。传完即走。

如果你也在传文件这件事上被微信压缩、AirDrop 不跨平台、手动输 IP 这些破事困扰过，试试它。

## 下载

[DLocalShare](https://gitee.com/DragonCodingPlus/dlocalshare/releases/download/V1.0/DLocalShare-1.0.apk)

[了解产品](https://mjlong123.top/products/dlocalshare)
[了解开发者](https://mjlong123.top)