LetsMove 中的几个点

Thu, 04 Jul 2019 01:19:10 +0800

当我们从网络上下载某个 mac app 之后，一般都会默认在 Downloads 目录里，但是某一些 App 是需要放置到 Application 目录才行，最常见的就是自更新功能是受到当前所处目录的限制的，这时候很多下载到本地的 .app 文件打开之后都会弹出提示框，让用户选择是否移动到 Applications 目录，LetsMove 就是大部分 mac app 参考或者集成的开源库，封装了这套逻辑。

这个库已经好多年了，最近的一次 Commit 是 2017年，其中有几个点可以学习借鉴。

大致思路

虽然叫 Move，实际上是先行 Copy 一份当前的 App Bundle 到 Application 目录，然后杀掉自己并删除源目录的 App 文件。

Move to Applications Folder 确认之后
复制当前 App 文件到 /Applications 目录中
删除当前已经打开 App （Mac 上是可行的，不同于 Windows，不存在占用文件句柄的情况）
执行子进程执行重启过程，具体后文会讲。

权限获取（提权）

检查文件路径是否可以写入的方法是 NSFileManager 的 isWritableFileAtPath ，如果返回 false，LetsMove 会主动进行权限获取。

获取权限所使用的接口是 AuthorizationExecuteWithPrivileges，该接口实际在 OSX 10.7 Lion 之后就已经标记废弃了，但是一直到目前的 macOS 10.14 还一直可以使用。

而作者为了避免苹果直接移除该代码导致提权接口不可用，使用了动态查找方法的形式，利用 dlsym 查找方法指针来获取，从而避免如果完全移除该方法导致功能不稳定的情况发生。

XPC Services

Thu, 04 Jul 2019 01:01:10 +0800

关于 XPC

因为最近在做的工作涉及到这一块，就大致的记录一下，针对 XPC 技术也做个总结。

XPC 是 macOS 上一种进程间通信的技术统称，其使得我们可以将 Mac 应用的功能模块拆分成不同的多进程模式，关于进程之间的通信也被系统封装完整了，你只需要按照既定的模式做即可。其带来的最大的好处是

提高 App 自身的稳定性
进行权限隔离

拿我目前在做的工作来讲，确实有针对以上这两点的需求。上层业务通过执行脚本命令获取执行结果，执行脚本命令使用的就是 NSTask，大概结构如下：

对于执行 NSTask 的这层命令行执行模块来讲，拆分到独立的进程中使得安全性得以提高，即使 XPC 进程挂掉，一般情况下再次向 XPC 通信，系统会自行恢复启用新的 XPC 进程，而主应用无感知。

XPC 架构

在 Apple 官方文档中有如下图，很清楚的展示了整个 NSXPC 的架构。

主应用和 XPC Service 之间是通过 NSXPCConnection 对象保持通信的，其通信接口由 Protocol 定义，然后暴露给外界一个符合了该协议的对象。

所有的 XPC Service 本身是由系统级别程序 launchd 来管理和维护的。

开发过程

整体上主应用和 XPC 通信是标准的 Client-Server 模式。客户端询问 Server 端数据，Server 端应答即可。这之间的数据序列化完全交由系统管理。

Xpc on Chen