1

由于 iPhone/iPad 的巨大渗透率，我们的合作伙伴有了新的要求。

我们可以使用 AppleScript（即发送 iMessages）解决这些问题，但是这个脚本系统企业准备好了吗？我是说，

  • 首先是一个愚蠢的问题：它是沉默的吗？或者它会显示 1000 个窗口来发送 1000 封电子邮件？
  • 它稳定耐用吗？（即发送 2000 个屏幕截图和 1500 个图像可以吗？）
  • 是“成熟”吗？我的意思是，如果我使用 PowerShell，那么我会觉得自己很安全。没有太多的监督，也没有太平坦的学习曲线。

请分享您的经验和见解。

4

3 回答 3

2
  • 是否静音，取决于应用程序和您的脚本，很多应用程序都希望在屏幕上打开一个窗口等，AppleScripts 支持应用程序的级别和类型可能会有很大差异。
  • 它是否稳定耐用，有点​​问题是AppleScripts不是很快，它用AppleEvents做所有事情，所以你可能会遇到AppleEvents的超时问题，或者AppleScripts需要很长时间，尽管我不得不承认我最近没有使用 AppleScript，但是当我使用现代更快的 CPU 时，这不像过去那么大。
  • 它是否成熟，它比 Mac OS X 存在的时间更长，我发现 AppleScripts 的最大问题是该语言看起来像自然语言，这给您的印象是您可以编写符合其自然语言模式的东西并且它会起作用，但事实并非如此，并且由于其类似于语法的自然语言需要一段时间才能知道什么会起作用，它与其他语言不同，您可以在其中制定语法，然后几乎任何符合该语法的组合都会起作用。我仍然对列表上的操作感到沮丧，该语言给您的印象是您可以在任何列表上执行一些过滤操作，而实际上它取决于您是 AppleScripting 的应用程序来为您提供该功能，例如您可以询问 finder从每个活动应用程序中获取具有某些属性的每个正在运行的应用程序，

AppleScript 是一种您可以轻松尝试的语言，所以我会尝试一些东西，看看它是否按您想要的方式工作，然后如果成功则充实。人们曾使用 AppleScripts 编写完整的 Cocoa 应用程序，但我从未想过它适合这样的事情。

于 2013-05-02T10:49:23.890 回答
2

内森戴的答案是正确的。但还有更多。

AppleScript 可以分为两层——开放脚本架构层和语言 AppleScript。

开放脚本架构有助于发送和响应 Apple 事件，这是跨应用程序发送的内容。使用开放脚本架构，有多种方法可以在不使用 AppleScript 的情况下使用相同的功能。

例如，Apple 提供了 Scripting Bridge 框架，您可以使用它在 Objective-C 和 Cocoa 中编写此代码（以及扩展为其他可以桥接到 Cocoa 的代码）。

还有其他语言的其他库，例如Ruby rb-appscript 和 ruby​​osa 库以及Python 库 appscript。

所有这些都是学习 AppleScript 的可行替代方案，并且可能更适合手头的经验和能力，因为 AppleScript 委婉地说，是一种后天习得的品味，掌握的时间比其语法看起来要长，而且很难有效地掌握用于 OSA 脚本以外的其他用途。

于 2013-05-02T11:06:21.637 回答
2

@Jesper：脚本桥有问题，appscript 和 RubyOSA 实际上已经死了，所以你不应该推荐它们。

...

@boj：询问 AppleScript 语言本身是否“企业就绪”是一个错误的问题，因为到目前为止，这是您最不担心的问题。你应该问的是：

“我可以用在桌面硬件上运行的桌面软件构建高可靠性的无头系统吗？”

和：

“Apple 是服务器端的正确选择吗？”


iOS 可能是一个很好的面向消费者的移动平台，而 OS X 可能是一个不错的桌面操作系统，但就服务器机房而言，我不会用 bargepole 碰它们，除非它们是绝对最后也是唯一的选择（例如，你被卡住了）使用 OS X Server 的专有服务之一，别无选择）。虚拟化不是一个好主意 IME 和 LOM 和机架就绪机箱等企业基础知识都不是初学者。并且不要忘记苹果公司倾向于在很少或根本没有提前警告的情况下突然/彻底修改其产品线、功能和服务。如果您想要企业级的稳定性、可预测性和支持，请坚持使用 Linux 和/或 Windows boxen。

在您的情况下，您正在谈论使用 iMessage，因为那是 1. 专有协议，以及 2. Apple 迄今为止尚未公开底层 API，那么这确实会缩小您的选择范围。您可能应该问自己的第一件事：您确定无法使用 SMS 实现合适的解决方案，它既是开放的，又在企业级已经得到很好的支持？我认为您可以为此制定一个强有力的商业案例：运行它可能会花费更多，但指出他们正在为稳定性和可靠性以及（您希望）专业构建的系统付费。

相比之下，您围绕 Messages.app 构建的任何东西都将是业余爱好者的补充。如果你被迫走上这条路，你最好做你的研究，不要提前做出任何承诺。例如：

  • 什么可能导致您的系统失败（例如，在无头盒子上弹出的应用程序对话框是一个严重的 PITA，并且不排除应用程序崩溃、连接问题和其他可能性，直至并包括盒子本身死亡）？

  • 您正在考虑什么样的停机时间，任何故障的成本影响是什么？（即，您对该服务的预期 SLA 是多少？）如果它是远程关键业务或公司要求的超过 2 个 9 的正常运行时间，则运行，不要走，现有的解决方案。

  • 当出现问题时，您有哪些恢复/重新启动系统的选项（例如，您是否会尝试进行一些自动故障转移，或者让某人远程进入盒子尝试修复它，或者是否有现场管理员来循环电源），是否有任何数据丢失或您需要担心的其他问题？（例如，您可能希望将业务逻辑和数据库保存在单独的 Win/Linux 机器上，以便系统不会丢失 OS X 机器播放/重新启动时所在的位置。）

  • 关于系统维护的问题是什么：如果您无法访问或不再存在，其他人是否能够在没有您的情况下维护代码和/或部署的系统？


顺便说一句，WWDC 和 10.9 现在离我们不远了，所以我建议先看看 iMessage API 是否会在 10.9 中公开，然后再花时间在 AppleScript 和 Messages.app 上。如果/当消息传递 API 打开时，它将允许您在 ObjC 中构建更强大的服务，但请注意，您仍将被绑定到 OS X 以开发和运行它。

于 2013-05-03T15:20:03.387 回答