我为什么放弃了 Tasker？
还得从最开始接触自动化工具的时候说起。那时我还在用 iPhone 6，欧博abg尽管当时手上这款最为畅销的 iPhone 机型早已垂暮，但坚持让我用下去的主要原因之一是「捷径」这款自动化操作应用（注：该应用前身名为 Workflow，被 Apple 公司收购后不久更名为「捷径」，之后再度改名为如今的「快捷指令」）。
捷径在那段时间一直以来都是我很喜欢的应用，因为在折腾手机的过程中免不了会有一些解决重复性操作流程的需求，而捷径提供许多自动化功能，运用得当可以略过繁复的步骤，节省了不少个人时间。
后来我切换到了 Android 系统，可在 Android 应用商店中像「捷径」这样的精品应用较为罕见，偶然间发现了呼声较高的 Tasker——被称为是足够媲美快捷指令的 Android 自动化应用——于是又激起了我求索的兴趣。
Tasker 一直都是名声在外，得益于 Android 的开放与灵活也拥有比快捷指令有过之而无不及的能力，比如 Root 之后可以直接操作系统底层、拥有丰富的插件体系等，可谓是折腾之利器、搞机必备之良品。
遗憾地是，不论是彼时还不懂敲代码的我，还是此刻有了开发背景的我，几经接触 Tasker 之后，最后都悻悻而归，选择放弃。心里一直留着一个疙瘩：「为什么我就是用不明白？」
在我发现了 MacroDroid——一款简单易用、拥有中文界面且类似于 Tasker 的自动化应用——之后，我找到了答案。
因为相比于 MacroDroid 而言，Tasker 虽然很强大，但总存在这样或那样、让我无法适应的地方：
在界面上设计得并不太直观，而且很多选项都藏在的二级或是三级页面中；
操作逻辑会稍微有点让人困惑，比如在设置一个任务项必须要设置参数、无法通过侧滑取消还要点击取消才行；
最开始使用时让人捉摸不透「配置文件」这个概念到底是指什么等等。
以上也是在我体验了 MacroDroid 之后得出的一些结论，因为 MacroDroid 不论是在界面还是操作逻辑上都让我觉得它就是一个「更易用的 Tasker」，也是那个唯一让我重新找回捷径体验的心仪之选。
为什么会是一个「更易用的 Tasker」？把 MacroDroid 和 Tasker 放在一起对比时，相信你能得到答案。
更为直观、有序的 UI 界面在使用 Tasker 时我经常性会被其隐藏的选项绕晕，欧博官网因为它的 UI 界面中除了必要的选项卡页面之外，其他内容都隐藏在了右上角的选项按钮中，并且当中的个别选项还包含多层级菜单操作，甚至无法回退到上一级菜单中。
反观当我第一次打开并体验 MacroDroid 时，不仅让我觉得 MacroDroid 的 UI 界面设计得要比 Tasker 精美，同时也没有让我体会到上述 Tasker 的繁复，因为所有选项或是设置都直观地给用户展示出来，即便有多层级菜单操作你也可以滑动回退到上一级菜单中。
MacroDroid 大部分功能或选项卡也都直接被拆分成了一个个方块，这会比 Tasker 那种隐藏的选项按钮好上不少，因为我们只需要首屏页面中就可以直接找到而无须层层查找。
更懂用户的 UX 设计UX（User Experience）也叫用户体验，它泛指用户与产品、系统或者服务进行交互和体验的一种综合表现，通常体现在易用性、使用效率等方面，换而言之即「如何让用户用得舒服」。
好的用户体验能够提高用户对该产品或是应用的积极期望，也有利于竖立品牌形象与口碑并扩大宣传的影响力；反之，则只会「声名远扬」。
想想为什么我们会那么憎恶有些开屏广告？因为它们让用户体验变得很糟糕。
在 iOS 上虽然开屏广告很恼人，但最起码你可以手动点击跳过；但是在 Android 上厂商们反而是玩出了花：一不小心就自动下载某个「砍一刀」的应用、手机摇一摇就自动跳转等等，这才是让人嗤之以鼻的地方。
Tasker 中有许多提示会直接以对话框的形式展示在界面之上，这就意味着用户必须要强制处理这个提示，否则无法进行其他操作。
虽然我们可以关闭提醒，但要知道记忆并不可靠，因为如果我们想下次再了解这个选项主要是做什么时还要想着找怎么开启。
那么 MacroDroid 是怎么做的呢？以一种更为温和的方式通过选项卡来给用户提示。
我们可以在 MacroDroid 中的多个选项页面中见到这样类似的提示，但只要我们不点掉提示，那么它永远只是当前界面中的一个内容，也不会影响到我们后续的操作，好像就是说「你见，或者不见我。我就在那里，欧博不悲不喜」。
相比于开屏广告「就让你看看」那种简单粗暴的方式而言，这种选项卡的方式就好比是微博时间线或微信朋友圈的广告，虽然它已经出现在了你眼前，但表现得却是较为含蓄。
除此之外，和强制处理提示信息一样，我们在 Tasker 中设置自动化操作时，也必须要把内容填好才可以通过侧滑操作返回上一级，否则只能通过点击右上角的取消选项来放弃操作，而在 MacroDroid 上就完全不会有这样的任何问题，在没想好怎么做的情况下你可以随时通过侧滑键取消。
相信有不少人和我一样在最开始使用 Tasker 并进入界面时，会这个所谓的「配置文件」感到一头雾水。
我最开始以为它指的就是我们所编写的自动化步骤，但实际上它仅仅只是一个类似于入口或启动装置的概念，也即我们在接下来提到的触发器概念；只有我们配置好了配置文件之后才能设置自动化步骤，也即「任务」，一个任务中所包含的则是我们自动化的多个操作。
让我们看看 MacroDroid 是怎么设计的。
MacroDroid 不同于 Tasker 将触发器与任务相分离的设计，正如其名中「Macro」一词所指出的那样，它将所有操作都装在了一起共同构成了所谓的宏。
「宏」一词在技术上经常被使用，但它却不容易理解，因为它表示一种抽象的集合概念，比如 Excel 中的宏通常是由 VBA（即 V8isual Basic for Applications 的缩写）代码所构成的脚本、Rust 或 C++ 编程语言中的宏其实是一种预先定义的指令集或模板，甚至是我们经常听到的「外挂」中都有宏的身影。
而 MacroDroid 中的宏也是某种集合，我们可以将其近似理解为是一个脚本、文件夹又或是压缩包这类带有「包含」性质的东西。
那么它当中包含了什么呢？与我们自动化密切相关的三个东西：触发器、行为与约束。
触发器（Trigger）顾名思义就是一个启动装置或步骤，它通常作为一种条件来决定后续的步骤是否该运行。例如手枪上的扳机实际上就是一个 Trigger，只有当扣动扳机时子弹就会被射出，否则就什么都不做。
因此不论是 Tasker、MacroDroid 还是快捷指令，运行时都必须要满足至少一个条件。
而触发器的具体表现有很多种，欧博娱乐比如传感器温度、消息通知、定位、日期时间等等，当我们在 MacroDroid 的宏编辑界面按下触发器的添加按钮时，就会看到 MacroDroid 为我们提供的所有触发器选项。
所以为了让 MacroDroid 帮我们完成自动化操作，我们往往都会挑选一个符合自己需要的触发器作为运行宏的开始，也即传感器温度达到了几度、是否有消息通知、现在是否处于定位地点、此刻是否是指定的日期时间等等。
MacroDroid 的触发器会暗含一个条件判断逻辑，即默认情况下我们所编写的宏，只有触发器达到触发条件时才会运行；而 MacroDroid 也支持在一个宏之中添加多个触发器，那么在这个逻辑之上延伸就是只要有一个触发器达到了触发条件，那么这个宏才会运行并进行后续操作。
注：MacroDroid 中有少部分触发器需要对设备进行 ROOT 或 ADB 才能使用并触发。
行为行为（Action）就表示当触发器达到触发条件时我们要做什么，它是一种「动作」的概念，代指一个或多个操作步骤，比如在前一小节手枪的例子中，「射出子弹」就是对应着「扳机被扣动」被触发时的行为。
我们编写的自动化内容大部分都与行为有关，因为当中包含了我们需要去进行的步骤或操作，比如下述例子：
自动化流程描述 触发器 行为所以我们在使用 MacroDroid 过程中会将大量精力都放在包含若干操作的行为步骤上，在触发器的基础之上进一步明确我们想要实现的自动化操作，正如上述表给出的示例一样。
约束（Constraint）即限制之意，在 MacroDroid 中可以被视为是「一道锁」，不论是触发器、行为还是宏，我们都可以为其添加约束。由于约束的存在，在执行步骤前会判断当前的设备状态是否符合约束条件，也即只有在约束条件范围内才会「开锁」并运行，否则就不会触发（如果你有编程经验，直接可以将约束理解为是条件语句）。
比如在前一节中的「当我到达烧麦网络科技有限公司时，就自动打卡」打卡流程，单单只有「定位显示到达烧麦网络科技有限公司时」的触发器可能还不行，因为我们可能只有每个工作日早上才需要打卡，而非工作日时间（假设东西落在公司周末去拿）则不需要打卡，又或者是超过了限定的打卡时间段之后就不再打卡。
所以我们还可以为其加上几条约束，比如「只有在周一到周五」和「只有在 9 点至 10 点时间段」两个约束，这样自动化打卡的流程就会变成：
只有在周一到周五且在 9 点至 10 点时间段内，当我到达烧麦网络科技有限公司时，就自动打卡。
需要注意的是，一个宏中绿色色块所表示的「约束」部分是作用于整个宏，如果仅仅只是针对单个触发器或者行为，那么就需要点击到具体步骤后单独添加。
不过你可能也会好奇，似乎新增的这两个约束条件似乎看起来就像是触发器？
本质上讲约束也可以理解为是特殊的触发器，即「触发器的触发器」，只有当约束被触发了之后才会进行后续的操作。区别在于，当 MacroDroid 的宏存在多个触发器时，只要满足其中一个即可运行；而约束则不完全一样，我们既可以让约束像触发器一样，保持只要满足其中一个即可运行的「或」逻辑，又可以设置只有当所有约束都满足时才运行的「和」逻辑。所以上述修改我们是要完全保证「只有在周一到周五」和「只有在 9 点至 10 点时间段」两个约束都同时满足，而这只有约束能做到。
更具区分度的变量设置对于像我一样有编程经验的读者而言，对「变量」一词并不陌生，它表示了用于保存某一种内容的代号或标记，比如当我们想保存或记录当前的时间、今天的气温、账户密码等等都会用到变量。
而变量又可以基于可用范围划分为「局部变量」或「全局变量」，这里的可用范围也就是编程中常说的作用域（Scope）。我们在编程时往往会偏好于使用局部变量，因为全局变量可以在多处被使用、修改，这也就意味着如果你一不小心在某个地方修改了一个全局变量，而恰好这个全局变量又在多个其他地方被用到，那么程序或脚本就很有可能因这次改动造成「牵一发而动全身」的错误，也就是俗称的 Bug。
不论是 Tasker 还是 MacroDroid 都提供了设置局部变量和全局变量的方式，但后者显然要比前者在使用体验上会好得多。
在 Tasker 中，如果我们需要设置全局变量，那么就必须同时满足以「%」百分比符号开头、首字母为大写且字符长度大于等于 3 这三个条件；而局部变量的设置只能是在设置任务时进行，其要求除了首字母必须为小写之外，和全局变量的设置要求一致，比如：
%Token # Global Variable %password # Local Variable %ab # Invalid Variable对于全局变量 Tasker 会专门将其放在一个单独的「变量」页面中列出以便查找，但在任务中设置的局部变量不会统一列出，这也意味着当我们变量较多的时候很难一目了然地知道当前任务中有哪些局部变量。
那么 MacroDroid 是怎么设计的？在全局变量上，MacroDroid 和 Tasker 一样也是用一个单独页面来集中展示，但 MacroDroid 在设置变量时不仅没有过多的命名限制，还支持中文命名，甚至还像编程一样为变量提供了可以指定的数据类型以便满足不同的存储需要；相应地，展示时也会直观地列出该变量的数据类型、默认值以及在哪个宏中被使用了等信息。
全局变量的设置规则也同样适用于局部变量，当然 MacroDroid 的局部变量也和 Tasker 的类似，将其与宏放在了一起，但是 MacroDroid 却单独为局部变量预留出了明显的展示区域（默认情况下为最底部），尤其是当我们点击宏右上角的选项按钮，然后选择「局部变量显示」，接着将其设置为「显示内联」展示方式时就会发现在界面上除了触发器、行为和约束三个色块之外还多出了一个局部变量的色块。
并且 MacroDroid 还贴心为局部变量进行标记，即便我们局部变量与全局变量重名，在选择时也能一清二楚。
集成度更高的一体化设计尽管说 Tasker 有着这样或那样让我感到不满意的地方，但不可否认它也是一个强大的自动化工具，尤其是某个应用提供了 Tasker 插件时简直如虎添翼。
据 Tasker 官方给出的列表，目前 Tasker 的插件体系支持了多达 258 款应用，如果你目前在用的应用有在其中，那么就可以与 Tasker 联动去实现自动化操作。
但是列表当中最前面一批以「Auto」开头的应用出自于 Tasker 作者之手，这些应用在我看来应该都是从 Tasker 单独剥离出来以扩展的形式存在，部分需要额外付费，并且如果我们想使用还需要额外进行下载。虽然我能理解 Tasker 的作者想要增收的想法，但是这样分裂式的设计我自认为倒不如内购解锁让人更容易接受。
除此之外，Tasker 也允许我们下载由社区第三方所编写好的自动化内容，但这部分内容并不是直接在 Tasker 界面中直接查看，而是需要通过右上角选项切单独换到「Tasky」模式（翻译为云端例程）才能进行筛选或下载，可当中的具体步骤展示我认为倒不如 MacroDroid 直观。
MacroDroid 所有支持的功能都集成在了一个应用当中，虽然遗憾的是 MacroDroid 并没有拥有自己的插件体系，但是 MacroDroid 作者却别出心裁地让 MacroDroid 兼容 Tasker 插件体系！这就表明只要提供了 Tasker 插件接口的应用，我们也可以直接集成 MacroDroid，也即直接在设置行为时找到「应用程序」列表并点击「Tasker/本地插件」即可。
类似地，MacroDroid 也提供了像 Tasky 那样的社区第三方用户的内容分享模块，也即底栏的「模板」页面。在模板页面中除了搜索之外我们也可以根据不同排序方式来展示分享的自动化内容，并且当我们点击某一个钟意的自动化内容时还能以直截了当的宏界面清楚地展示当中有哪些详细步骤，做到一览无余。
虽然说 MacroDroid 在应用设计上有许多优于 Tasker 的地方，但它也依旧也有不如 Tasker 的地方，其中触发器的数量和插件的兼容性是我最在意的两点。
Tasker 相比于 MacroDroid 而言提供了众多的触发器，很多是 MacroDroid 所不具备的，就拿「事件」来说，Tasker 还提供了存储卡卸载、移除或装入，以及系统设置相关的壁纸更改、设备启动、设备存储空间不足等等触发器，尽管 MacroDroid 的界面设计很讨喜，但是当我们浏览所有触发器时就会明显感觉到数量是少于 Tasker；除此之外，Tasker 作者虽然将其他以「Auto」开头的扩展都做成单独 App 的形式我不是很喜欢，但这些扩展某种程度上也是扩充了触发器的可选项。
同时，尽管说 MacroDroid 是兼容 Tasker 插件的，但是在使用过程中还是出现了两种截然相反的情况发生。比如当我使用 Termux 这款安卓上的终端模拟器时进行测试时，同一个命令设置，在 Tasker 中是可以直接运行并获取到输出结果，反观 MacroDroid 则不然，运行之后仅有日志显示却无法获取到终端的输出结果。
正如我在文章开头所说的那样「得益于 Android 的开放与灵活也拥有比快捷指令有过之而无不及的能力」，Tasker 也甚至像我之前介绍的 Auto.js 一样可以运行 JavaScript 和 Java 代码，所以在可编程性方面更是一骑绝尘。
所以为什么我会认为 MacroDroid 是一个「更易用的 Tasker」？
它在本文列举的某些方面上都和 Tasker 存在高度的相似性，加之精美的界面和符合直觉的逻辑操作方式，在基本上能还原 80% 到 90% 的 Tasker 使用体验的同时也让人用得舒心。虽然略有缺憾，但至少在日常编写自动化操作时能用 MacroDroid 的情况下我肯定不会用 Tasker。
毕竟体验过 MacroDroid 之后再去用 Tasker，就不由自主地会有种「由奢入俭」的不适。
> 少数派请你做地图：城市声音收藏夹火热征集中，期待你创作的城市之声 🎧
