无论使用什么系统与设备，只要对自动化感兴趣或者想要利用自动化提高效率，甚至亲自动手搭建过自动化任务的朋友大多遇到过这样的场景：找到/偶遇一款别人分享的，精准击中自己痛点的自动化任务配置文件，但却是专门给另一款应用/另一个系统使用的。

这种明明放在自己面前却得不到的感觉让人抓心挠肝，对于使用自动化完成大部分工作内容的我而言更是如此。当遇到这种情况，即使从未动手制作过自动化任务的朋友，也会有一种想要将任务移植到自己使用的工具上的冲动，正因为这种冲动，我已经将数个不同平台上的自动化任务移植到自己经常使用的 Tasker 上。

在这篇文章中我会讲解一下自己在移植自动化任务时的思路，如何分解优化整个过程，又是如何权衡解决其中遇到的困难的，就以最近我移植 @Minja 在 Power+ 文章《用快捷指令更智能地拼长图》中分享的拼图自动化任务为例子。

移植前后任务执行的效果，左边为快捷指令拼图任务，右边为 Tasker 拼图任务

注：下文中被色块包围的内容为通用思路，适用于任何自动化移植流程。

总的原则

相信大家都有听过「填罐子」的故事：一个空空的罐子装满了石头，表面上看它已经满了；但如果你把沙子倒进去，还可以填满石头的缝隙，现在看罐子好像也是满的；但如果你继续把水倒进去，还可以继续填补罐子的缝隙。反过来看，如果你一开始就把水倒进去，满了之后就没有办法再放沙子或者石头了。

移植自动化任务也有类似的思考方法：

直接一个动作一个动作地模仿，除非是只有一两个步骤非常简单的任务，否则不仅容易遗漏或者多做某些无用的自动化动作，另外在没有找到对应的动作时，确定大模块之后可以根据模块的作用来修改或者移除某些你不需要的操作，而照葫芦画瓢就没法确定每个操作与其他操作的联系了。

@Hum 和我说他听过一句很实用的话：

太多人在寻求捷径时浪费了大量时间，而我在充分利用时间中找到了捷径。

我们大部分时候移植自动化任务的根本目的是付出一定的时间和精力，把对应的任务移植到自己习惯使用的平台上，然后利用它给我们节省出更多的精力和时间。所以不管是前期评估还是实际制作，我们首先要思考的是结合自己最终使用移植后自动化任务的频率，这个任务本身手动完成的精力和时间等实际情况评估收益是否大于付出，某个步骤遇到困难时先思考能否避免这个困难，再思考能否绕过这个困难。如果不行最后再思考克服这个困难所需要的时间和精力是否能够获得足够的收益。否则正如上面 Hum 分享的这句话所说，把移植任务的时间拿去充分利用可能还获得更多的收益（移植自动化任务纯粹为了好玩或者练手的情况除外）。