Code for a better world.

app extension 让我们在用户正在使用其他 app 的时候, 拓展我们 app 的功能。

Today Extension 也叫做 widget。 它能够让一些重要的消息更快速的到达你的用户。比如说, 用户可以通过它查看天气，或者股票价格, 查看日程表等等。苹果在官方文档中说到， 一个 widget 应该有以下的特点。

• 确保内容是最新的
• 响应的用户事件
• 性能好(在iOS上占用大量内存，系统可能会kill掉这个widget)

optional, 可以说是 Swift 中最为重要的特性, 也是它跟 Objective-C 不同的关键特征。在编码的时候强制处理那些可能为空的值, 可以让程序更具有可预测性, 减少错误发生的机会。

然而在开发中我们经常会遇到一些变量, 明明是 optional 的, 但在逻辑又一定是非空的。比如说 controller 中的 view

Swift 开发中的一些小的技巧

刚开始的时候, 特别好奇大厂是怎么搞的, 他们的项目长什么样子, 他们用哪些库…想在巨人的肩膀上开发, 免得浪费时间在那些已经有很好解决方案的事情上。

四年前，我和团队中很多很厉害的人讨论过一些编程实践。今天就分享一些东西吧。

欢迎指正！🚀

这篇文章主要介绍一些很常见的语法。

闭包

1

() -> Void

也叫做 匿名函数。闭包是自包含的函数代码块，可以在代码中被传递和使用。在 C 和 OC 中有 block 与之对应。

如果你之前就有 iOS 开发经验, 你肯定看到过 UIView 动画的 API

Swift 的一大特色就是编译安全。这使得我们开发者能够更容易的编写出可预测性的代码, 并且能勾减少运行时错误的发生。但是, 在实际的情况中, 错误发生的原因是千奇百怪的。

我们今天来看一下如果正确的去处理各类错误, 以及我们有什么工具来做这件事情。上一篇文章研究了如何处理 non-optional。 在那篇文章中我使用 guard + preconditionFailure() 代替了强制解包。

之后很多人都在问 preconditionFailure() 和 assert() 有什么区别。 在这篇文章中。我们再仔细的看看这些语言特性。最重要的是在什么情况下使用哪一种？

懒加载属于让你可以在需要的时候才初始化, 而不是在初始化这个对象的时候就必须要。懒加载可以用来避免 optional 的使用, 当某个属性的初始化耗费很多资源的时候会提升性能。当然使用懒加载也能让对象的初始化方法看起来很清爽, 因为某些设置会在这个对象的生命周期中被推迟。

这周我们来学习一下 Swift 中懒加载的定义, 以及使用。

学习如何在不创建一大堆类的前提下做按钮、label、图片的动画。

掌握了足够的知识而不去使用它, 就像你长了满口的牙齿, 但是成天都喝牛奶一样。 掌握了足够的理论知识, 在项目中怎么使用 POP 呢？🤔

OOP is okay, but could’ve been better

Introduction

即使你还不知道 Class 和 Struct 基本的区别, 你也可以看这个文章。都知道 Struct 不能继承, 但是, 为什么呢？

如果你还不知道上面这个问题的答案, 花两分钟时间读一下下面这段代码。这些代码是写在 playground 上的

现在我们掌握了所有的工具, 也明确了他存在的风险以及规避的方法。现在是时候想想应该怎么样最大可能的运用它了。以 MVVM 为例。

又很多方法来写 RxSwift 的 API。 我怕的做法是: 利用 RxSwift 很酷的观察者模式和很方便的操作符, 管理异步的任务。可能不是 100% 纯正的 RxSwift。 在将我做过很多的尝试试图将两种编程思维统一起来,但是我都失败了。

下面是一些我使用 RxSwift 的方法。

RxSwift 提供了大量非常好用的工具, 让写代码更爽, 但是他也可能给你带来一些头疼的地方, 也可能是bug😱。 用了三个月之后我觉得我应该也可以给出一些建议来避免一些问题。

好了, 接下来是第三个部分。Subjects

学了之前内容. 我们可能已经发现了。之前学习的内容都是 Observables 输出事件的部分。我们可以订阅他, 就能知道他输出的事件了。但是我们还不能改变他。

我们在上一篇文章中介绍了 RxSwift 基础的部分. 现在我们来学习一些操作符, 来学习一下 FRP 中的F(unctional) 部分

RxSwift 真的是一个非常值得学习的东西。非常遗憾的是我没有研究所有的架构模式MVVM VIPER Routing。

要非常好的讲出来RxSwift到底是个什么东西，我也说不好。毕竟他能做太多的事情了。普遍认为，他是函数响应式编程中非常重要的观察者模式。在最初的定义中,他并不就是函数响应式编程。他最初的设计灵感就是来自于函数响应式(FRP), 所以也可以说它包含了函数响应式的特性。

如果你不知道什么是 FRP 的话, 不用担心, 在这个教程中你会自然而然的理解什么是 FRP。

通过对 RXSwift 的深入研究, 我得到了很多的启发, 同时也被很多的问题困扰。相信你也会这样。

需要花很多个小时的时间来适应新的思维模式，唯一能确定的是，一旦你适应了，你就再也不想回到从前了。

在这个教程中，我会尽可能的节约你的时间，并且解释的尽可能的详细。想教幼儿园的小朋友一样。

开始学习之前, 请确定你已经掌握了 Swift 和 UIkit 的基础知识.

本文翻译自(http://lukagabric.com/mvvm-design-pattern-and-rxswift/)

MVVM

MVVM 是一种设计模式。他是程序的代码分离成三个部分: Model、View、ViewModel。 Model 代表数据的表现, View 代表用户看到的界面，ViewModel 代表着模型层和视图层的主要关联关系。

本文翻译自国外的美女工程师 Kenza Iraki 的文章 RxSwift and the awesome things you can do with Reactive Programming — Part I

第一次听见响应式编程，我的表情是这样的

接下来的几次几次接触, 也并没有什么改变。整整两个星期之后,即使我在项目中写了一些响应式代码。我依然是这种感觉。

现在我才知道有很多的人在第一次遇见响应式编程的时候跟我有一样的感觉。我也知道很多人看过响应式的代码之后再也不想再见到它了，因为她的学习曲线太过陡峭了。但是我能告诉你一个事实, 我还没听说过一个人， 在最终理解了他是怎么回事之后,后悔学习响应式编程。

我知道网上有很多关于响应式编程理论和思想还有 RxSwift 的的资源, 也有很多教你用Rx来做各种事情的教程(文末我会给出一些链接)。这篇文章不是是一个教程, 也不会解释 stream 和 observables 是怎么回事。 我要做的是提供一个直接、明确并且尽量少的理论总结来告诉你 RxSwift 能做什么, 并且告诉你为什么你会喜欢上它。由于 Rx 的世界深似海, 所以我打算写三篇文章来讨论这件事情, 这是第一篇。

Part1: Data Binding, control events and gesture recognizers

Data Binding

数据绑定看起来像是一个高端的词语, 但是它却是一件非常简单的事情。假如你有一个 App 需要用户在 UITextField 中输入它们的名字。当他们在打字的时候, 用 “你好 + 用户输入的文字” 展示在界面上。这样一个很基本的场景。如果在不是响应式的程序中, 我们需要遵守 UITextFieldDelegate 这个协议, 然后在 ViewController 中实现 textFieldDidEndEditing 这个方法, 来监听用户用户的行为，然后给 Label 赋值。

虽然很简单，但是假如有很多的 UITextField 我们还要在代理方法中判断, 又或者, 我们需要用户在输入的过程中时时的刷新 Label。这种场景, 我们的代码，看起来就会很糟糕。至少不会很优雅吧。

在响应式中, 这种情况就可以用数据绑定来实现。说白了,就是将用户在 UITextField 中输入的文字绑定到 UILabel 上。在 RxSwift 的世界里, 没有什么比处理数据绑定更简单的了。刚才描述的需求, 我们只需要通过以下代码就可以实现了。

基础用法

• 创建信号
• 订阅信号
• 发送信号

1
2
3
4
5
6
7
8
9
10

// 1.创建信号(cold)
RACSignal *signal = [RACSignal createSignal:^RACDisposable * _Nullable(id<RACSubscriber>  _Nonnull subscriber) {
    // 3.发送信号
    [subscriber sendNext:@"hello, RAC."];
    return nil;
}];
// 2.订阅信号(hot)
[signal subscribeNext:^(id  _Nullable x) {
    NSLog(@"%@", x);
}];

在创建 RACSignal 的时候,

1

+ (RACSignal<ValueType> *)createSignal:(RACDisposable * _Nullable (^)(id<RACSubscriber> subscriber))didSubscribe;

方法传入的 block 会返回一个 RACDisposable 对象。

将以上代码中的 return nil； 替换成如下代码

如果我们将水龙头拧紧知道水是以水滴的形式流出, 不难发现, 每隔一段时间, 就会有一滴水流出来。

如果我们预先设置一个执行周期, 当第一次调用动作(滴水)和第二次调用动作之间的间隔大于执行周期, 则执行这个动作。反正, 不执行。

直接翻译 throttle 这个单词。

1
2
3
4
5

throttle
n.	节流阀; 喉咙，气管; [机] 风门;
vt.	扼杀，压制; 勒死，使窒息; 使节流; （用节汽阀等） 调节;
vi.	节流，减速; 窒息;

不难理解, throttle 其实就是一种控制数据或者流量大小的机制。

MrPeak 曾经写的文章中介绍过 I/O Throttle 在 DISPATCH_QUEUE_PRIORITY_BACKGROUND queue 的使用场景。在没有非常严苛的实时性要求的情况下, 对于重度依赖磁盘的后台任务, 使用 DISPATCH_QUEUE_PRIORITY_BACKGROUND 的 queue 会更加友好。文中也引用了官方文档的一段话

Items dispatched to the queue run at background priority; the queue is scheduled for execution after all high priority queues have been scheduled and the system runs items on a thread whose priority is set for background status. Such a thread has the lowest priority and any disk I/O is throttled to minimize the impact on the system.

意思是说, 这种 Global Queue 会在其他所有的 queue 结束之后才会在后台执行。 这是最低优先级的。并且一些磁盘 I/O 操作会因为最小化对系统的影响而被节流。

对象间的交互, 主要有 target-action、Notification、KVO、Delegate

target-action

1
2
3
4

[[self.loginBtn rac_signalForControlEvents:UIControlEventTouchUpInside] subscribeNext:^(UIButton *btn) {
 // btn, 即 self.loginBtn
 // 这里执行点击之后的操作
}];

可以用 BlocksKit 替代

KVO

1
2
3
4

[RACObserve(self, name) subscribeNext:^(NSString *name) {
  // name 即 self.name
  // 一旦 name 属性改变就立即进入到这个 block
}];

1
2

// self.myLab.text 随着 self.myTF.text 的改变而改变
RAC(self.myLab, text) = self.myTF.rac_textSignal;

Notificaiton

1
2
3
4
5
6
7

[[[[NSNotificationCenter defaultCenter] 
rac_addObserverForName:UIKeyboardWillChangeFrameNotification object:nil] 
  // 这句不可少，表示 当 self 将要 dealloc 的时候，就要释放 通知
  takeUntil:self.rac_willDeallocSignal] 
  subscribeNext:^(NSNotification *notification) {
      NSLog(@"-----%@", notification.description);
}];

不要忘了还是原来的方法发送通知。

通知已经通过 RAC 内部得到了释放，所以不需要额外在 - dealloc 添加移除的代码

RACCommand

A command, represented by the RACCommand class, creates and subscribes to a signal in response to some action. This makes it easy to perform side-effecting work as the user interacts with the app.

简单的使用RACCommand 实现一个 viewModel 的网络请求。

每个稍微有点开发经验的 iOS 工程师都很容易的发现一下几点:

1. 几乎每个 iOS 的项目都适用了 Cocoapods
2. 几乎每个 ObjC 的 iOS 项目是使用 AFNetworking 、 SDWebImage等三方框架。
3. 几乎每个 Swift 的 iOS 项目都是用了 Alamofire、 Kingfisher等三方框架
4. 每一次这些框架更新之后, 无数个工程师只需要在终端执行一下’pod update’ 或 pod install就能对应的更新自己项目中的代码

这几乎都是每个 iOS 工程师经常都会遇到的事情。目前几乎所有优秀的 iOS 开源框架都支持了 CocoaPods。 几乎所有的 iOS 项目都集成了 CocoaPods

但是我们在日常的开发中也常会遇到这样的问题:

1. 很多公司都有好 App 同时在进行开发。
2. 这些 App 或多或少在业务或者 UI 都很很多的重合。

着就意味着有很多的代码在这些 App 中都是可以复用的。由于各种各样的原因,同个公司的不同 App 可能更新不同步。 app A 可能已经升级到新版本 app B 可能还在老版本。每个 App 分别管理势必会出现混乱的局面。一起管理又存在新旧交替的问题。如果每个 App 又不同的工程师负责, 即使可能有交叉 review 的机制, 但也很难保证公司代码的统一。很多逻辑都存在多段代码。

如何管理公司的公共代码库就成了一个比较麻烦的问题。

集成 IJKMediaPlayer 的时候,想到了使用git来区别版本,然后使用 framework 来管理共有代码。然而在出现了你的代码需要使用到其他的 Framework 的时候, 或者好几个 Framework 都需要使用同一个第三方框架的时候, 这么做确实也是件恼火的事情。

这个系列的文章是用来记录我学习 python 爬虫的。这是第一篇。