Process 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

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 是如何被加载的，数据是从哪里取的，等等。

Build Process

Thu, 25 Apr 2019 11:30:30 +0800

编程语言的处理过程大致会有五个阶段，其每个阶段均有对应的工具：

预处理器 Preprocessor
编译器 Compiler
汇编器 Assembler
链接器 Linker
加载器 Loader

我们以一个简单的源文件，来看看具体这几个步骤都做了哪些事情。

//
// main.m
// MachO
//
// Created by chen he on 2019/4/22.
// Copyright © 2019 chen he. All rights reserved.
//

#import <stdio.h>

int main(int argc, const char * argv[]) {
 printf("Hello World.\n");
 return 0;
}

预处理器 Preprocessor

符号化
宏定义展开
头文件引入展开

在命令行执行如下命令，我们导出输出到本地文件

xcrun clang -E helloworld.c > preprocessed.txt

打开 preprocessed.txt 看输出如下：

# 1 "helloworld.c"
# 1 "<built-in>" 1
# 1 "<built-in>" 3
# 361 "<built-in>" 3
# 1 "<command line>" 1
# 1 "<built-in>" 2
# 1 "helloworld.c" 2
# 1 "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/stdio.h" 1 3 4
# 64 "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/stdio.h" 3 4
# 1 "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/_stdio.h" 1 3 4
# 68 "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/_stdio.h" 3 4
# 1 "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/sys/cdefs.h" 1 3 4


// 省略一万字

extern int __vsnprintf_chk (char * restrict, size_t, int, size_t,
 const char * restrict, va_list);
# 412 "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/stdio.h" 2 3 4
# 2 "helloworld.c" 2

int main(int argc, char *argv[])
{
 printf("Hello World!\n");
 return 0;
}

可以看到预编译处理之后的源文件，仅仅只有几行的源文件进行头文件展开之后能增加到几百行，而我们仅仅只引入了 stdio.h 一个头文件。当然，你可以使用 Xcode 来执行预处理命令。

写个小工具 Swwwitch

Sat, 30 Mar 2019 11:29:54 +0800

最近看到开发圈某热点，做了个小工具，总结下最近的几个 CocoaApp 上的功能，仅做练手。现在只包含了两个开关：切换系统主题和隐藏桌面 icon 的功能。

功能点

切换系统主题
显式或者印象桌面图标
完全的 Menu Only 应用
开机自启动

关于第三点的实现在另外一篇文章有讲过，第四点的实现在这一篇中有讲。

系统主题切换

关于系统主题切换主要是基于 AppleScript 所写，

tell application "System Events"
 tell appearance preferences
 set dark mode to not dark mode
 end tell
end tell

你完全可以自行执行这段 Apple Script 来切换主题，你可以点击下面链接尝试。

Click Here to run

显式/隐藏桌面图标

关于隐藏桌面图标，实际上是执行系统的 Command 来实现的，Cocoa 应用可以显式使用 Process（也就是 NSTask）来执行任务，我们也是通过 NSTask 执行了一段如下的命令行达到的目的：

defaults write com.apple.finder CreateDesktop false
killall Finder

你可以自行点击以下链接尝试。

Click here to hide Desktop Icons

Click here to show Desktop Icons

感兴趣可以去看下代码，领会意思即可。 Releases

TODO

Add more switch
Add User-Customized switch setting

Links

Checkout all command lines macOS Support