Mac 开发的神秘面纱：后娘养的嫡长子

时间 2019-11-17

标签 mac 开发神秘面纱后娘长子栏目 MacBook 繁體版

原文原文链接

原本，标题是「揭开 macOS 开发的神秘面纱」，可想一想，以我目前对 macOS 开发的理解，仍是去掉「揭开」二字吧 😂html

本文不是系统性的文章，更像是随笔。回想本身过去 1.6 年的 macOS 开发历程，挑些有意思的来讲。若是想看完就去挖 macOS 这座金矿（若是是的话），你会失望的；且做佚事来读吧。git

注：严格地说，应该叫做「macOS 开发」，由于去年起，苹果将 Mac 操做系统改名为 macOS；不过，苹果电脑依旧以 Mac 命名，如 MacBookPro，故而 Mac 开发也说得过去；再加上，以小写字母开头做为文章名，总以为怪怪的，是以本文混用「Mac 开发」与「macOS 开发」github

----- 长文开始警惕线；不喜请绕行 -----objective-c

0) Mac 是后娘养的嫡长子

说 Mac 是嫡长子，是由于 苹果就是作电脑起家的。虽然说后来 iPod、iPhone 风生水起，但嫡长子的血统仍是纯正的；而 iOS 正是基于 macOS 开发的。这里的故事不少，感兴趣能够读读《乔布斯传》之类的书或文章。数据库

惋惜的是，有了 iPhone 这棵摇钱树以后，Mac 电脑靠边站了，macOS 天然也被冷落，不到万不得已，不更新；即便更新，也像挤牙膏同样。macos

Mac 哪里被冷落了？多了去了。编程

好比，我每周都会收到一款苹果给开发者的邮件，本意是告知本周 App 的活跃程度。而我每次收到的邮件内容都是这样的：小程序

由于我还没有上架 iOS 应用、只有 macOS App；而 在苹果看来，macOS App 岂能叫 App ？！是以，这里的数据是空的…swift

其它的，不胜枚举。设计模式

1) Mac 是个小市场

有多小？

先说说硬件，这是 2016 第四季度出货量对比：

设备	出货量	营收
Mac	537 万	72 亿美圆
iPhone	7,830 万	543 亿美圆

不管是出货量、仍是营收，均是零头。

再来看看 App 的数量：

从 AppShopper 的数据来看，不足 3 万的 macOS App 数量，不到 iOS App 的 1%；对，是「百分之一」，零头的零头。

固然，这里主要统计的是上架 MAS (Mac App Store) 的应用，在 MAS 以外也有不少。不过，2 个数量级的差别，没跑。

现说说操做系统占比：

据 MarketShare 的数据，macOS 仅占 6.12%，仅有 Windows 用户的 6.7%.

其中，macOS 版本的分散程度，虽比 Windows 好不少，但也 不如 iOS:

看到这里，是否是以为有些心凉，以为 Mac 好可怜有没有…

不过，Mac 电脑确实是在慢慢增长的，知名度也在变高。好比，国内现代都市剧中出现的电脑，大多都是 Mac；苹果也刚刚宣布 全球 Mac 活跃用户有 1 亿。

2) Swift or Objective-C

我开发的应用 (Klib、iPic、iPic Mover、iPaste、iTimer、iHosts)，所有基于 Swift；不过，即便你也打算基于 Swift，仍是建议对 Objective-C 有基本的了解。由于，毕竟 Objective-C 是苹果一直以来使用的开发语言，绝大多数的文档、教程，都是基于 Objective-C 的。

虽然说能够很容易地改编为 Swift、或被 Swift 调用，但这就像是：你有一本英文词典，理论上就能够直接看英文文章，由于看见不懂的单词能够查嘛；但也知道，这不现实，毕竟你总不能每一个单词都查吧？

因此：

若是你已经有 Objective-C 基础，就直接使用 Objective-C 开发 Mac 应用好了。要不要学 Swift？看你本身心情，我不提供建议；
若是你并无 Objective-C 基础，建议你先学学 Objective-C 基础，而后再学 Swift，并基于 Swift 开发。

3) Mac 文档及教程

官方文档主要有这些：

macOS 开发者中心
API Reference
Programming Guide
- 主要是对具体知识点的详细介绍，如 Table View Programming Guide for Mac
历年 WWDC 视频
Guides and Sample Code
- 这里提供了一些示例项目。好比，想学某个控件的实际用法，能够到这里搜搜看。

实际上，因为咱们通常是「面向 Google 编程」，通常遇到问题都是先搜索，不太须要记录这些网址。只是，若是你想系统性、深刻地学习某个点时，能够正向地从官方文档入手。

不过，对于 苹果的开发文档，友情提醒：并不怎么好。若是套用这句话：
「为何懂得这么多道理，却仍过很差这一辈子？」

即是：
「为何我看了全部 Mac 文档，却仍没法开发 Mac 应用？」

文档更可能是偏向对某个具体知识点的介绍，而若是想系统性地入门 macOS，最好是经过一本好的书，以及本身的练习。因为 iPhone 的热销，市面上 iOS 的书，可谓汗牛充栋。而 macOS 的书呢？呵呵。

我本身是看《Cocoa Programming for Mac OS X》这本书入门 macOS 开发的，这几乎是我在 2015 年能找到的惟一一本基于 Swift 的 macOS 开发教程。另一本是 Swift Development with Cocoa，跟这本书无法比。

其余 macOS 的书，我看的很少，也没什么好推荐的。若是你有以为哪本书不错，欢迎留言告诉我。

4) macOS 数据结构及持久化

首先要说的是，虽然说是 macOS 开发，但实际上不少基础的东西都是通用的，好比 JSON 格式、MySQL 数据库等等。

另外，macOS 和 iOS 相比，像 TouchBar 这种独有的东西，并很少；更多的是通用的，或者说是并行的两套。

使用 plist 文件存储数据：

默认仅支持简单的数据结构；此方式仅适合保存少许数据，如偏好设置中的 On/Off 选项
可以使用 UserDefaults 管理默认的 plist 文件。注意：沙盒模式和普通模式下默认的 plist 文件的位置不一样
可在命令行中使用 defaults 命令来管理 plist 文件中的数据
可以使用 Xcode 打开 plist 文件进行管理

序列化后存储：

对于自定义类型，适配 NSSecureCoding 协议后，可以使用 NSKeyedArchiver 转换为 Data 格式
进而，可存储在普通文件中，也可存储于 plist 文件中

Core Data:

Core Data 本质上是对数据访问方式的封装
对于简单的数据结构，使用 Core Data 会带来额外的复杂度，并不划算。对于复杂的应用，Core Data 能够显著减小代码量
持久化方面，Core Data 提供了对象-关系映射 (ORM) 的功能，不编写任何SQL语句，便可将数据保存在 SQLite 数据库文件中，也能还原到内存中

CloudKit:

存储方面，CloudKit 本质上相似于云端的关系数据库
除了存储，CloudKit 更有用的场景，是在多设备、macOS 与 iOS 间同步数据。好比，系统自带的 Notes 等应用，均是经过 CloudKit 来存储、同步数据。其中，通知机制能够最小化须要同步的数据量
再有，就是提供基于 CloudKit 的共享功能

注：数据持久化存储方式有很是多，也要视具体的需求而定；这里仅说起一些经常使用的方式。

5) macOS 界面开发

咱们所说 macOS 开发，一般默认指开发「有界面及交互的、能运行在 macOS 上的应用」，其核心，就在于界面及交互。

咱们也常听到 Cocoa，那 什么是 Cocoa 呢？援引《Cocoa Programming for OS X》中的介绍：

Cocoa is your application’s interface to the window server to receive events and draw to the screen. At the same time it has access to the Unix layer where it can make lower level calls.

也就是说，Cocoa 是这样一个中间环节：负责衔接你的应用与窗口系统，同时也可直接操做系统底层。

界面的开发，是个无底洞；能够是个简单的单窗口应用，也能够是 Pages、iMovie 这样复杂的应用。

对于初学者，建议从菜单栏程序入手。能够暂时绕开窗口、控件这些复杂的话题，又能够建立出能解决实际问题的一些应用。好比，iPic 主交互即位于菜单栏：

这部分，可参见我以前写的教程：Status Bar App 教程是 16 年 4 月写的，如今来看有些可能已通过时，好比当时是基于 Swift 2.2；不过总体仍是能够参考的。

回到界面的开发。首先，要理解 App 的总体生命周期。尤为是 App 启动时，都作了哪些事、前后顺序及依赖是什么。

而后，实际的工做，就是搞定界面布局，以及熟悉一个个控件的用法，如 NSButton、NSTextField、NSTableView 等等。建议的学习步骤：

先随意玩玩，能让控件跑起来；一些控件复杂，跑不起来也不用以为沮丧
若是官方有 Programming Guide，认真读一遍
若是官方有示例程序，学习之，熟悉正确的用法
过一遍 API Reference，了解控件全部的可能性和局限
解决本身实际的问题，真正用起来

我通常的开发步骤：

想清楚数据结构
堆 UI
完成业务逻辑

6) macOS 设计模式之解耦

随着程序变得复杂，代码变多，也很容易交织在一块儿。对于进一步开发和维护，是很是头痛的事。

怎么避免这样的状况呢？其中一个思路是：解耦。

抽象的说，就是 把复杂的东西拆成一个个独立的模块，而后经过一些方式让这些模式有机地组合在一块儿。

有哪些方式呢？顺着这个思路，我列出一些概念。

MVC模式 (Model-View-Controller)

这一模式在界面开发里大量使用，好比你常常看到的 XXViewController，就是其中的 Controller 部分
简单的说，就是 把界面与逻辑分离。界面部分，如布局、样式等。一般，代码量最多的，都是在 Controller 中。View 与 Controller 之间，经过引用、绑定来传递数据，即将数据显示在界面中、从界面读取用户产生的数据

Delegate

有两个角度来理解代理。以 NSWindowDelegate 为例，可理解为 Window 自己有丰富的可定制性，程序可选择性地实现某些功能、特性
另外一个角度是，一样对于 NSWindowDelegate，对事件（如窗口即将关闭）的响应，Window 自己是不知道的，或者说是具体的业务相关的。Window 本身作不到，只能委托给本身的「代理」去决定。好比，当窗口即将关闭时，程序提示用户保存未保存的数据

Callback

对于非实时的操做，可使用 Callback 回调的方式，来解耦调用者和执行者之间的等待
好比，程序在从网络下载图片时，可能须要 1ms，也可能须要 2s，程序总不能傻等着。因而，程序告诉下载的模块：我去忙别的事了，你下载好了告诉我。怎么告诉？就是经过 Callback 回调机制实现
与之关联的概念，如代码块

Notification

对于「若是…就…」这样的逻辑，比较适合的是通知机制
这里的通知，不止是从网络上推送下来的通知，也能够是程序内部的通知
好比，用户在偏好设置的界面中完成帐户升级后，在程序内发出帐户类型变动的通知；程序的主窗口以前注册以监听这一通知，即可根据帐户类型实时调整界面

7) 发布 macOS 应用

本身辛苦开发的程序，一般是愿意让更多人来用的。若是能赚点小钱，固然更好啦。

7.0) macOS 应用签名

对于简单的程序，能够复制到别的电脑上运行，但最好仍是要对程序进行签名。尤为是使用 CloudKit 等一些苹果特性的程序，必须签名。

怎么签名呢？前提是交钱。也就是，必须每一年交给苹果 $99 的人头税，才能成为苹果开发者，进而给应用签名。

7.1) MAS 与沙盒模式

在 MAS (Mac App Store) 上提交的应用，必须运行在沙盒模式中。

沙盒模式有诸多限制，好比，默认不能访问用户的任何文件、一些接口没法使用等等。和 iOS 的沙盒模式相比，macOS 的沙盒模式仍是宽松不少的。以访问文件的权限为例，应用能够申请访问如 Downloads 等指定目录。向谁申请呢？苹果，而不是用户。一旦经过（虽然并不容易），即可直接访问该目录，无需用户受权。

事实上，沙盒模式确实限制了程序的发挥空间，一些应用（如屏幕取词翻译、截图工具）干脆没法上架，或者额外开通「Accessibility」权限才能正常工做。而听说苹果已再也不放行须要此权限的应用上架。

7.2) MAS 付费方式

苹果支持多种内购方式，要想经过应用收费，最简单的方式是：设置程序必须付费才能下载。这样，程序内无需区分免费版与高级版，无需作任何功能限制，代码简单。苹果系统保证了，使用哪一个 Apple ID 下载的应用，只能在使用哪一个 Apple ID 上登陆的电脑上使用。好比，你本身购买了某个付费应用，直接把 .app 复制到朋友的电脑上，是没法运行的。

不过，这一方式也有局限：用户在付费以前，没法体验到产品的全部功能，也就很难决定是否要付费。对于这一局限，一些程序的作法时：在产品官网提供一个全功能、但仅能运行一段时间（如 7 天）的 体验版。这样，用户能够在体验全部功能后，决定是否购买。

再进一步，就是 免费版 + 内购的模式。用户可免费下载应用，但应用仅开放基础功能，须要内购才能使用高级功能。这样，既能最大化地获取用户，又能适时地收费，个人全部应用都采用此方式，相信也是将来一段时间的趋势。

对于内购，又分为一次性购买和订阅制。一次性购买容易理解；订阅制能够有按月、季度、年等不一样周期。对于订阅制，又分为自动续订和手动续订。目前，苹果对于订阅制、尤为是自动续订的订阅制，审核较严。

另外，还有 消耗型内购，这种在游戏中较为常见，好比花钱买装备，或者为帐户充值等。

对于内购的开发，仍是比较繁琐的，好比要处理展现、购买、用户购买后退款、恢复、订阅续订、订阅未续订致使过时等等逻辑。好在，我封装了 IAPHelper，能够很方便地处理这些逻辑（以下代码为购买部分）；开源，能够 Pod 方式集成，已经在个人产品中应用多年，你们可放心使用。

IAP.purchaseProduct(productIdentifier, handler: { (productIdentifier, error) in
    if let identifier = productIdentifier {
        // The product of 'productIdentifier' purchased.

    } else if let error = error as? NSError {
      if error.code == SKError.Code.paymentCancelled.rawValue {
        // User cancelled

      } else {
        // Some error happened
      }
    }
})复制代码

7.3) 不完美的 MAS

以前苹果与微信怒怼的打赏分红事件，想必让更多朋友知道了：凡是应用从用户收到的钱中，苹果均要收 30% 的拔毛费。

MAS 的诸多限制，以及不菲的拔毛费，让不少知名的 macOS App 纷纷下架，如 Sketch、Dash 等等。

不过，要在 MAS 以外发布，仍是要作不少事情的，好比下载、支付、退款、激活码等等。对于小程序，仍是挺繁琐的，并不划算。另外，毕竟 MAS 还能带来一些天然流量。

若是在 MAS 以外发布，还有一点须要注意：.app 程序本质上是一个文件夹。若是须要在网络上传送（如做为邮件的附件），最好是进行压缩，甚至是制做 .dmg 文件，我使用的是 create-dmg 这个小工具，很是方便，生成的样式也简单大方。

基于上面的缘由，目前个人应用所有在 MAS 上发布，还没有在 MAS 以外发布。

尾巴

macOS 开发的话题还有很是多，好比 Storyboard、绑定、动画、并发、Undo、Pasteboard、Drag & Drop、本地化、单元测试等等，本文不可能所有说起。而且，写起来也好累，毕竟必须对这些点有彻底的掌握，才可能写出来。暂且挖坑，之后再填。

对 macOS 开发感兴趣？欢迎留言交流。

原文：「自在开发」公众号