1. 从手动选图到 4 分钟入库Dots 这个 66KB App 是怎么诞生的先说结论一个完全不会写代码的普通用户用 Dots 拼出了一个只有 66KB 的 App把 15.32GB、总计大约 2500 张照片和视频在 4 分钟内批量存进了系统相册。整个过程没有一行手写代码没有昂贵的云盘中转也没有像网上教程那样开一堆命令行工具。我亲眼看着这个人在 Dots 的面板里拖了十几个节点点了导出然后一个轻飘飘的 66KB 文件就出现在桌面上。这件事最触动我的不是“快”而是它捅破了一层窗户纸以前我们总觉得批量处理照片这种事要么手动一张张选要么找人写脚本要么忍受各种应用导来导去。但 Dots 这种可视化逻辑搭建工具把“批量导入”这个需求拆成了几个很容易理解的积木块——选择来源、遍历文件、判断重复、写入相册、通知完成。折腾下来你会发现所谓编程思维其实并没有那么玄乎至少在这个场景里它更像是在画一张流程图。这篇文章我会把这个项目从头到尾复盘一遍。包括为什么要把 App 体积压到 66KB、为什么 15.32GB 能 4 分钟跑完、搭建过程中踩了哪几个坑以及如何把这套思路迁移到照片之外的其他场景。如果你是那种“不会写代码但想用技术解决自己问题”的人这篇应该能给你一些真正用得上的参考。1.1 15.32GB 摆在手机里手动选图到底有多崩溃先说这个需求的来源。那位用户手机里堆了多年积攒的素材有旅行拍的原始照片、聚会视频、还有从旧设备导出来的缓存文件。清点下来总共 15.32GB其中大头是照片按单张 4.5MB 左右估算大约 2500 张另外还有几十段视频单段从几十兆到两三百兆不等。如果走“手动全选然后隔空投送”的路子问题立刻冒出来手机相册一旦被选了几百张以上界面就会卡顿而且传输过程中只要有一张失败整个选择状态可能就乱了你还得从头开始。更麻烦的是这些素材分布在不同文件夹里有的在旧相册备份里有的在“最近删除”边缘徘徊手动整理的体验可以用四个字形容——度日如年。我一开始还建议过用电脑中转先插数据线把文件拷贝到电脑再从电脑拖进相册。但实际操作后发现这种方式对普通用户也有门槛要装驱动、要找对目录、要处理 HEIC 和 MOV 格式的兼容性稍有不慎就会出现“照片能打开但不显示在相册时间线里”的诡异问题。这也是为什么最终选择把 Dots 作为核心方案——它把“导入相册”这件事做成了一套可视化流程用户只需要告诉它“从哪读”“写到哪”“遇到重复怎么办”剩下的脏活累活全部交给运行引擎。1.2 为什么是 Dots而不是“找个程序员朋友写脚本”很多人遇到这种批量需求第一反应是找身边会写代码的朋友。但问过一圈你就会发现程序员朋友大概率会反问三个问题你的文件在什么设备上是 iPhone 还是 Android相册能不能用脚本直接写入这三个问题一问出来你这个需求就变成了一个需要远程联调的小项目人情成本和时间成本都不低。Dots 的价值在于它把所有常见的“文件操作逻辑”封装成了可视化节点。你不用理解什么是沙盒、什么是相册权限、什么是元数据你只需要按直觉把节点连起来。比如“从文件夹读取文件”这个节点界面上就是一个很形象的文件夹卡片点击之后能设置递归读取、过滤条件、排序方式比命令行参数友好得多。而且平台生成的 App 体积非常小。当时我拿到那个 66KB 的导出文件时还愣了一下——市面上很多无代码平台导出的应用动辄几十兆因为里面塞了完整运行时和 UI 框架。但 Dots 的导出物更像是一份“流程图描述文件”真正的执行引擎是客户端本地自带的。也就是说66KB 存的是逻辑本身而不是整个运行环境。这个思路在后面的性能表现上也起到了关键作用因为逻辑和数据分离之后执行阶段几乎没有额外的资源开销。2. 在 Dots 里把一个批量导入脚本搭出来的完整过程如果你以为 Dots 的使用方式像建站工具那样“拖个按钮、摆个图片”那就想简单了。它更像是在画一张数据流图。我没有做任何界面设计所有精力都花在“流程设计”上。下面我把整个搭建过程拆成四步每一步都讲清楚为什么这么设计。2.1 先画数据流再拖节点第一次打开 Dots 的编辑界面你会看到一个很大的空白画布左侧是一堆可拖拽的节点有点像编程里的“函数库”。一开始不要急着拖节点先在纸上或者脑子里把数据流画出来。我这个项目里的数据流非常简单来源目录 → 逐个读取文件信息 → 判断是否已在相册 → 写入相册 → 记录日志 → 结束把这个流程画清楚之后剩下的工作就是把左侧的节点一个个拖到画布上按顺序连线。Dots 的连线方式也很直观从节点底部的小圆点拖到下一个节点的顶部小圆点就行。我特意没让用户去理解“回调”“异步”这些概念因为在这个工具里连线顺序就是执行顺序你甚至可以理解为“水流的方向”。这里有个很关键的细节节点的输入输出都带“数据类型”。比如“从目录读取文件”这个节点输出的是“文件对象列表”“写入相册”节点接受的不是文件路径而是“文件对象”。这意味着你必须保证前一个节点的输出类型和后一个节点的输入类型匹配否则连线根本连不上。我一开始没注意把“读取文件路径”这种普通文本直接接到了“写入相册”的端口上程序一运行就报错。后来学聪明了每次连接之前先看端口旁边的小标签比如“Path”“Asset”“Bool”。这个设计对新手非常友好因为它把很多低级错误直接挡在了画布阶段。2.2 循环里的重复判断这个环节最像“写逻辑”批量导入最忌讳的事情是什么是重复。假设相册里已经有一批照片你又跑了一遍导入如果不做判断就会出现两个几乎一模一样的“最近项目”时间线被挤乱不说空间也被白白占掉。Dots 里解决这个问题的方式是“条件节点”。我在画布上加了这样一个判断读取文件的创建时间和文件名拼接成一个唯一标识然后去相册的现有资源里查一遍如果查到了就跳过查不到才允许写入。这个判断节点在界面上长得像一个菱形左右两边各有一个出口左边标着“是”右边标着“否”。这个地方最像写代码的逻辑判断。你要理解“相等”“包含”“大于”“小于”这些比较关系Dots 的下拉菜单里全部预设好了你不需要记语法只需要选择。比如判断文件扩展名是否在允许列表里我用的表达式就是“文件扩展名 属于 [jpg, png, heic, mov]”整个配置了十几秒就完成了。如果换成写代码这种逻辑至少要两三行 switch-case里面还要处理大小写、空指针这些烦人的细节。2.3 66KB 的导出包是怎么压缩出来的搭建流程本身其实只花了不到半小时但导出设置我研究了挺久。Dots 在导出时提供了几个选项是否包含自定义图标、是否使用第三方扩展库、是否保留调试日志。为了把体积压到最小我把图标换成了空白占位第三方库全部不勾选调试日志只保留了错误级别。最终导出的文件就是那个 66KB 的独立应用。66KB 是个什么概念一张普通 JPEG 照片差不多就是 4MB 到 8MB这个 App 比一张照片还小几十倍。它能这么小核心原因是 Dots 的“应用包”里只存了流程图描述、节点参数和必要的权限声明没有包含可执行代码。当你在目标设备上打开这个 App 时设备上的 Dots 运行环境会读取这份流程图描述然后逐节点执行。这种设计其实借用了“解释执行”的思路——就好比你给一位厨师写了张非常详细的菜谱食材、步骤、火候都写得清清楚楚但菜谱本身不会占多少地方因为“会做菜”的能力在厨师脑子里。Dots 运行环境就是那个厨师66KB 只是菜谱。这种轻量设计带来的直接好处是分享特别方便用聊天软件发一下就能传到其他设备不用下载几十兆的安装包。3. 15.32GB 四分钟跑完关键不是“快”而是“不折腾”把 App 拿到手之后接下来就是见证奇迹的时刻。导入过程总共耗时 4 分钟出头换算下来每秒要处理大约 10 个文件传输速率接近 65MB/s。如果对移动设备有所了解你会意识到这套运行机制做了相当多优化。这里我拆开来讲三层原因。3.1 本地原图导入绕开了云端中转和二次转码市面上不少批量整理工具的做法是先把文件传到自家服务器处理完再下载到手机这样做的理由是“统一处理格式”或者“生成预览图”。但如果你只是想把自己已有的照片原封不动放进相册云端中转完全是多余的而且会带来两个致命问题上传带宽拥堵和隐私泄露风险。Dots 在这个项目里走的路线是纯本地处理。来源目录和目标相册都在同一台设备上读取文件、写入相册全部通过系统的原生接口调用不带任何网络请求。我做了一个简单的时间测算如果同样这批数据走某云盘的“上传—处理—下载”流程在普通家用宽带上光上传就得花 20 到 40 分钟更别提服务端排队时间。所以 4 分钟这个成绩本质上不是因为什么黑科技而是因为它根本没走冤枉路。另外很多工具在导入相册时会偷偷帮你“优化”格式——比如把 PNG 转成 JPEG或者把大视频转成低码率版本。看起来是贴心实际上对想要原始素材的人来说是灾难。Dots 的写入节点里有一个“保留原始格式”开关我一开始没注意后来发现默认竟然是关闭的也就是说默认会做格式转换。把这个开关打开之后导入速度反而更快了因为省掉了转码计算写入的是原封不动的数据块。3.2 批量写入相册接口的并发设计如果是单线程逐个写入 2500 个文件4 分钟是远远不够的因为每个文件都要经过“创建资源请求—系统确认—写入元数据”这套流程单次至少 300 毫秒2500 个文件就是 750 秒也就是 12 分钟以上。但实际只用了 4 分钟说明 Dots 运行引擎在底层做了并发写入。我在 Dots 的参数面板里看到了“并发数量”这个选项默认值是 4最大可以调到 8。底层原理其实不复杂系统相册的写入接口允许同时初始化多个创建请求只要不超过系统资源限制并发数量越大吞吐量越高。把并发从 1 调到 4吞吐量几乎线性提升但调到 8 之后并没有更快反而偶发资源冲突。我当时做了一组简单的对照并发 1 时需要 12 分半并发 4 时需要 4 分 10 秒并发 8 时需要 4 分 8 秒还出现了两张照片乱序的情况。所以最终我选择把并发固定在 4既能充分利用系统资源又能避免额外开销。如果你在别的地方也用到了批量写入逻辑记住一个经验并发不是越高越好最好的方式是像这样跑一小批数据做测试观察曲线拐点。3.3 失败重试与断点续跑批量处理最怕中途崩溃。2500 个文件就算处理到第 2400 个挂掉了重头再来也很痛苦。Dots 在这个项目里有两个功能帮了大忙失败重试和断点续跑。失败重试是单个文件写入失败后自动重新尝试我设置了最多 3 次重试间隔 2 秒。这种策略对 T 型杆临时锁死、系统偶发错误很管用虽然 2500 个文件里最终出现失败情况的也就 10 个左右但全部重试成功一次都没中断。断点续跑则更巧妙。整个流程里我加了一个“进度记录”节点每成功导入 50 个文件就往一个本地文本文件里追加一行。“重新运行”的时候流程会先读取这个进度文件已经记录的文件名会被条件节点过滤掉。也就是说即使中途崩溃重新跑一次也只会处理剩余文件而不是从头再来。这个思路我在很多自动化任务里都用到过不管是用什么工具设计流程时优先考虑“可恢复性”绝对能帮你省下大把时间。4. 搭建过程中最容易踩的三个坑我替你排掉了虽然整体流程很顺但中间也出现过不少让人抓狂的瞬间。这几个问题可能不是 Dots 独有的只要是做批量导入的类似工具都会遇到我把它们写出来希望能帮后来人少走几步弯路。4.1 重复导入后相册里出现两个“最近项目”第一次全量导入之后我没有马上清空源文件夹而是又跑了一次流程想验证“重复跳过”逻辑。结果跑完之后发现相册里赫然出现了两份几乎一样的照片集合时间线被挤得乱七八糟。排查之后发现问题出在我的“唯一标识”算法上。“文件名 创建时间”看起来没问题但有几个文件的创建时间在系统里是空值Dots 读出来之后返回了一个默认的 1970 年时间戳导致这些文件每次都被认为是“新文件”。解决方案很粗暴但也有效加上文件大小作为第三重校验把判断条件从“文件名 且 创建时间”改成“文件名 且 创建时间 且 文件大小”。这样就算时间戳缺失只要文件名和大小一致也依然会被识别为重复项直接跳过。4.2 单个大视频文件导致超时中断15.32GB 里有几段超过 500MB 的视频其中最大的一段约 1.2GB。在并发 4 的设置下这部分视频写入时偶尔会遇到“系统相册写入超时”的报错。起初我以为把重试次数调高就能解决但视频数据量太大每次都卡在同一段上重试到第 3 次还是失败。后来我意识到问题出在并发冲突当四个文件同时写入时如果其中一个是大视频它占用的临时存储和 IO 通道会比照片大得多容易挤压其他任务的资源。解决办法是给大文件单独开一条流程路径。我在节点里加了一个“文件大小 大于 300MB”的判断把大视频单独分流到一个串行写入的分支里串行线程设置并发 1而其他照片走并发 4 的主流程。这样跑下来大视频虽然慢一些但再也没出现过超时中断。4.3 缩略图生成拖慢了整体时间中途我发现导入速度从每 0.3 秒一个文件突然掉到每秒一个一开始以为是系统资源不足后来翻开 Dots 的执行日志才看到它默认在导入之后会触发“生成缩略图”的任务。对照片来说缩略图生成是瞬间的事但对视频来说系统要从视频流里抽取一帧作为封面这个过程遇到大视频会消耗不少 CPU。这个功能其实在写入节点的高级设置里默认是关闭的但导入完之后相册界面的缩略图往往由系统自动补齐所以并不需要 Dots 自己额外生成一遍。我把开关确认关闭后总体时间从之前可能要 8 分钟左右降到了 4 分出头。如果你做类似的项目建议先搞清楚“导入即生成完整缩略图”和“系统 lazily 生成缩略图”的区别很多时间都浪费在这种默认配置上。5. 那个 66KB 的 App后来被我扩展成了通用批处理工具这个相册导入项目跑通之后我发现 Dots 的那套“可视化流程”还能复用。66KB 的 App 本身没有改一行“代码”——准确说是没改一个节点——我只是把它复制了几份然后改了一下输入输出参数让它变成了完全不同的工具。这里分享三个实际验证过的扩展方向。5.1 把输入源从“目录读取”改成“剪贴板 / 系统文件分享”第一个扩展是把输入源换成了系统文件分享面板。原来的流程是“从指定目录读取所有文件”我把入口节点换成了一个监听系统分享事件的新节点。这样在任何应用里选中照片或文件点击“分享到 Dots 导入器”流程就会自动执行导入逻辑省去了把文件挪到特定目录这一步。这种改法特别适合处理微信里别人发来的大堆照片。以前要先“保存到手机”再进相册整理现在只要选中所有接收的照片一键分享给这个 66KB 的 App它会自动去重、自动归档、自动通知完成。我甚至为了这个场景加了一个“完成后发送本地通知”的节点这样不用一直盯着屏幕。5.2 加一个定时触发器夜间无人值守运行第二个扩展是给 App 加了定时触发器。Dots 里有一个“定时”节点可以设置每周几、什么时间自动启动流程。我把相册导入流程改成“定时扫描指定目录如果有新文件就导入没有就退出”然后把它挂在凌晨两点执行。这个场景非常实用。相机每隔一段时间会把照片自动备份到一个共享目录我设置 Dots 在每天凌晨自动把这些新照片导入相册。早上醒来打开手机相册所有素材已经整整齐齐躺在时间线里了。整个过程零干预、零出错比手动整理可靠得多。唯一需要注意的是系统在夜里可能会限制后台活动所以 Dots 的运行时必须设置为不被系统挂起或者确保设备在充电状态下运行。5.3 用同一个 66KB 文件帮家人配置同款流程最后一个让我觉得特别值钱的能力是分享。因为导入器只有 66KB我直接通过聊天软件把文件发给家人然后远程视频指导他们把“来源目录”改成手机上的 DCIM 文件夹其他配置全部沿用。家人没有任何技术背景也能照猫画虎完成配置。这里面有一个细节Dots 的 App 包在第一次打开时会要求用户授权“照片访问权限”和“文件访问权限”如果不授权后续流程会一直报错。我之前踩过这个坑所以在分享给家人之前特意在流程最前面加了一个“权限检查”节点如果权限没有开就弹窗提醒“请去设置里允许访问照片和文件”。这个小小的前置校验把无数潜在问题扼杀在摇篮里对不会写代码的用户来说尤其重要。我的最后一点体会其实把这个项目从头到尾做完我最深的感触不是“无代码工具真厉害”而是“逻辑思维永远比工具技巧重要”。那位用户完全不懂代码但他在搭建流程时很清楚我要处理什么数据、哪些情况要跳过、失败之后怎么办。这些思考方式才是解决问题的核心代码和工具只是表达这些思考的载体。如果你想复现这个项目我可以给你我在实操中觉得最关键的几条建议第一导入前先花 5 分钟建立文件清单把“唯一标识”里包含的字段想清楚第二大文件一定要单独分流不要混在并发任务里第三先拿 50 个文件做小范围测试确认正确率和速度都满意后再跑全量。这几点看起来简单但我在整个过程中踩过的坑几乎都是从这几条上长出来的。最后分享一个小技巧Dots 的执行日志里可以看到每个文件的处理时间导出日志后按耗时排序找出最慢的那一批。你会惊讶地发现几乎所有性能问题都集中在文件体积分布不均这一件事上。把这个分布理清楚你的批量导入速度至少还能再提一个档次。