Library on Chen

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 Service 的 Target

Codable && Tuple

Mon, 10 Jun 2019 23:50:54 +0800

While learning Swift, I keep finding interesting things. Codable is one of them.

Today, I defined a model with a tuple type, then Xcode gave me an error. The code might look like this:

You may want Xcode to automatically complete all the codable stuff. However, life is hard. Code like this cannot even be compiled. Xcode will tell you that it cannot synthesize Codable for Person because of FullName.

How to generate a NSViewController without a Nib?

Mon, 03 Jun 2019 20:55:54 +0800

Recently, I created all the ViewControllers through the storyboard or the Nib (for views). Today, when I created a demo project without any Nib file, the ViewController did not show as I expected.

WTF, Can you believe that? I cannot even create a ViewController now.

There exist some differences between iOS and macOS.

iOS

In the previous development on the iOS platform, creating a ViewController — specifically a UIViewController instance — is dead simple, as below.

一道 Swift Quiz

Tue, 14 May 2019 16:01:54 +0800

这两天在 Twitter 上看到一道题目，主要是考察 overload 和 type(of:) 的知识点，本文仅做记录，关于 MetaType 会单独写一篇文章来总结。

// Swift Quiz

class View {}
class A: View {}
class B: View {}

func add(_ v: View) { print(type(of: v)) }
func add(_ v: A) { print(type(of: v)) }
func add(_ v: B) { print(type(of: v)) }

func build() -> View { return B() }
add(build())

// What is the output?
- "View"
- "A"
- "B"

答案的分布说明，大家对这个输出结果还是有一定的疑惑🤔

关于 Library 和 Framework

Fri, 26 Apr 2019 00:35:30 +0800

Library 和 Framework 的概念大家应该脑海里都有一些，本文旨在讲述下基本概念，没有对每个字节都了如指掌。关于基本的编译过程在 Build Process 一文中也大概讲述了一些。

在链接 Library 以及 Framework 之前，我们需要先了解一下 Mach—O。

提到 Mach-O ，需要明确下 object file（目标文件）的概念，其实质上是指那些由源代码编译之后生成的，还未进行链接的中间文件（比如 Linux 下的 .o 以及 Windows 下的 .obj），它和可执行文件的内容和结构很相似，所以一般上会跟可执行文件格式采用一样的格式存储。

那在 Unix 系统上的 COFF 是当时发明的在 Unix 表示一个目标文件的存取格式，后来 Linux 基于 COFF 发明了 ELF，而 Windows 基于 COFF 发明了 PE 格式。广义上来说，目标文件与可执行文件几乎一样。在 Linux 下统称为 ELF 文件，Windows 上统称为 PE-COFF 文件，而在 iOS/macOS 上我们的目标文件就是 Mach-O 格式，其在目标文件的大体组成上和其他两种很相似。而 Mach-O 的全称就是 Mach Object 的缩写。

我们以 Linux 上 ELF 结构的一张图来大概说明一下情况，不同的源文件通过分类，将代码和数据，以及变量放入不同的职责段，代码段 _TEXT，数据段 _DATA 等。

而 Mach-O 文件格式如下图（源自于 Apple 文档）, 和 ELF 格式类似，其也是将不同职责的代码和数据放置于不同的 Section 段，然后再集中成一个一个的 Segment，而 Load Commands 是用来控制每一个 Segment 是如何被加载的，数据是从哪里取的，等等。