Swift的map/reduce/filter的用法

函数式编程的常用方法

2016-2017年在吹AI之前，一堆人对着函数式编程一阵狂吹，导致各家语言都加入了函数式编程的基本支持，其中三个基本方法就是map/reduce/filter

名词 概念 原理
lambda 函数式编程的基本方法 其实就是一个回调方法的语法糖，代表着一个匿名方法
map 数学中的映射概念 将一组数据集通过一个逻辑转换成另一个数据集，逻辑就是传入的lambda表达式，就是一个方法
reduce 数学中的归约概念 将一组数据集通过一个逻辑转化成一个结果
filter 过滤 将一个数据集中符合条件的筛选出来，很容易理解

Filter & Map

假设存在一个数组1-9，我们可以通过两个Lambda表达式进行筛选和映射，其实就是两个Block，入参是 number 返回值分别是Bool类型和Int类型

1
2
3
4
5
6
7
8
9
10
11
12
13
let original = [1,2,3,4,5,6,7,8,9]
var result : Array<Int>? = nil

result = original.filter({ (number) -> Bool in
    return number%2 == 0
})
print(result!) //[2, 4, 6, 8]

result = original.map({ (number) -> Int in
    return number + 1
})
print(result!) //[2, 3, 4, 5, 6, 7, 8, 9, 10]

Reduce

归约的思路稍微复杂一点，就是把数组1-9变为一个数，即数组中所有的元素都参与运算，reduce接收两个参数

  1. 函数运算的初试值
  2. 函数运算的逻辑(即lambda表达式)
1
2
3
4
5
var sum: Int = original.reduce(100, { (temp, number) -> Int in
    return temp + number
})
print(sum) // 145

其中lambda表达式有两个参数

  1. 上次运算的结果temp，由于第一次运算不存在上次运算结果，所以使用初始值
  2. 这次进入的元素number

所以sum就是 100+1+2+3+4+5+6+7+8+9

展开全文 >>

Swift的defer用法

synchronized在Swift中

互斥对象锁synchronized在OC中的用法是

1
2
3
@synchronized(self) {

}

但是在swift中变成了

1
2
3
4
5
6
7
objc_sync_enter(self)

if (condition) {

}

objc_sync_exit(self)

如果函数在 if 循环内进行了return可能会导致 objc_sync_exit无法执行 导致死锁，为了解决这种情况，可以使用 defer

1
2
3
4
5
6
7
objc_sync_enter(self)
defer { objc_sync_exit(self) }

if (condition) {

}

defer

defer在函数结束后按照入栈顺序逆向执行，无论以何种形式结束都不会跳过执行，官方文档参考Defer Statement与之对应的概念在C++中有个叫RAII的设计模式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

func testDefer() {
    print("First....")
    print("Second...")

    defer {
        print("Last...") //先入栈，后出栈，倒数第一个执行
        print("End defer....")
    }

    defer {
        print("Last Second...")   //后入栈，先出栈，倒数第二个执行
    }

    print("If Logic....")  //早于任何defer逻辑进行执行
}

打印结果

1
2
3
4
5
6
7
First....
Second...
If Logic....
Last Second...
Last...
End defer....

展开全文 >>

Swift的where用法

where关键词

Swift用where关键词来指定一些特殊情况

指定Generic Type 和 where的AND用法

代表入参数必须同时是UIView和NSObject

1
2
3
4
5
func genericFunc<T>(param:T) where T:UIView, T:NSObject{
        print("Input parameter is enter")
}

genericFunc(param: UIView()) //可以执行

如果使用另外一个入参，将会提示错误

1
2
3
4
genericFunc(param: NSObject())

// error: cannot convert value of type 'NSObject' to expected argument type 'UIView' genericFunc(param: NSObject()) as! UIView

指定Protocol的Extension类型

针对同一个Protocol和不同的Class进行公用时，来完成不同的实现

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
protocol SomeProtocol {
    func protocolFunc()
}

extension SomeProtocol where Self: UIView {
    func protocolFunc() {
        print("This Extension for UIView")
    }
}

extension SomeProtocol where Self: CALayer {
    func protocolFunc() {
        print("This Extension for CALayer")
    }
}

class ViewTest: UIView, SomeProtocol {}
class LayerTest: CALayer, SomeProtocol {}

let tempView: ViewTest = ViewTest()
let tempLayer: LayerTest = LayerTest()

tempView.protocolFunc()  //"This Extension for UIView"
tempLayer.protocolFunc() //"This Extension for CALayer"

与其他控制流函数结合

也可以用于过滤控制流里的某些条件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

//do....catch...
do{
    try throwError()
}catch ExceptionError.httpCode(let httpCode) where httpCode >= 500{
    print("server error")
}

//switch
switch value {
case let x where x < 60:
default:
}

//for
for i in numbers where i > 3 {
}

展开全文 >>

循环引用与闭包逃逸

循环引用与闭包逃逸

在一年前的一个文章里循环引用提到了在某下情况下可以在闭包中安全使用 self 而不引起循环引用的问题

当时的分析是错误的，确实没有引起循环引用，但是对于原因的定位是错误的

但是万幸当时知道了Block存在三种 StackBlock MallocBlock GlobalBlock 最近详细研究了一下。

Block类型 解释
StackBlock 函数盏内的Block，除了该Block存在的类对其进行了Retain之外，别的对象不会Retain它
MallocBlock 内存中的Block，本身可以被其它对象持有，RetainCount不定
GlobalBlock 全局Block，并不被特定的对象持有，相当于全局变量

Block的实质

以下面的Block为例子,根据Mach-O文件分析，其实质相当于一个对象的方法

1
2
3
4
5
6

- (void)someMethod {
  [self someFuncWithBlock:^{
     //Block
    }];
}

将会在符号表中生成一个类似这个名字的函数

1
2
3
00000436 t -[Class someMethod]
......
00000634 t ___45-[Class someMethod]_block_invoke

当我们使用A对象，调用当B对象当B中的 someFuncWithBlock 并且传入一个Block时，OC会在Runtime的过程中创建一个Block Object

闭包逃逸

Escaping

那么这个Block到底是 StackBlock 还是 MallocBlock 决定于 someFuncWithBlock 内部的实现，而内部实现决定了

1
2
3
4
5
6
7
8
9
10
//StackBlock
- (void)someFuncWithBlock:(void (^)())block {
    block();
}

//MallocBlock
- (void)someFuncWithBlock:(void (^)())block {
      self.inner = block;
}

在 StackBlock 的实现中，Block的接收对象并没有对其进行任何Retain，直接进行执行

而 MallocBlock 则是对传入对象进行了 持有，对其Retain Count +1 此时Block的对象由Stack逃出(Escaping)到Malloc上，内存模型如下

  • StackBlock

image01

  • MallocBlock

image02

当Autorelease时

当前线程的Runloop执行完一次，调用AutoreleasePool对象执行了drain方法后，StackBlock由于引用计数为零，将会被释放，而MallocBlock由于引用计数不为零，则不会被释放

  1. StackBlock: Block释放–>A Retain -1 –>A释放–>B释放
  2. MallocBlock: Block无法释放–>A不会释放–>B不会释放–>Block无法释放

此时发现，如果在MallocBlock中调用了self，则会导致循环引用 Cycle Retain

结论

循环引用Retain Cycle是存在的，但是在StackBlock下可以安全的使用self，Swift中加强了这个概念，引入了@escaping来提醒码农不可以安全使用self

Swift中所有的Block默认都是 @unescaping 的，在Swift 3.0之后生效

展开全文 >>

模块化与Unity(28)：DynamicHeapAllocator和MKMapKit渲染的冲突

意外收获

在制作模块化的过程中，发现了一个Unity模块和苹果MapKit的内存管理冲突的BUG，可以通过framework化来解决

表现

每当地图进行缩放操作，整个App就进入半卡死状态，通过Profile分析，CPU占用爆满超过半分钟，大量调用以下函数

1
DynamicHeapAllocator......

原因

  1. Unity导出的iOS项目存在一个线程锁DynamicHeapAllocator
  2. 对某个OC的原生函数加了切面
  3. 地图在进行Context渲染时会同时并发大量线程
  4. 地图的渲染线程会被互相锁住，导致CPU爆炸

分析

如果Unity以Static Mach-O的形式加载进入项目，主体App的地图的某些函数做出切面拦截，主要是因为Unity的 C++ 代码符号和主体App在同一个Mach-O里

解决方案

Unity的显示部分以 Dynamic Framework的形式挂载到App上，做到和主工程的Mach-O分离

参考文章Mach-O的加载，可以防止MapKit的函数被 DynamicHeapAllocator 切面拦截到

展开全文 >>

模块化与CocoaPods(27)：使用FrameworkPod协调多工程

提醒

因为Pods对Project的更改具有入侵性，为了防止这个入侵，可以 准备一个 Pods-Bridge.xcodeproj 用来引入Cocoapods

这个解决方案感觉有点取巧。。。希望模块化有经验的人士可以在Github的issue给予指导

目的

  1. 可以使用Pods管理的第三方库为了方便引用
  2. 不能需要对每个Project都配置一个Podfile
  3. 每个Project在脱离了Podsfile的管理时也可以单独编译通过
  4. 而不会因为Podfile产生的脚本Not Found在Build时报错

对现有项目进行Frameworks改造

需要使用到Pods的模块，仅需通过Framework的形式引入Cocoapods生成的第三方库即可，步骤如下

  1. 新建 Pods-Bridge.xcodeproj
  2. 为 Pods-Bridge.xcodeproj 准备Podfile
  3. 为 Pods-Bridge.xcodeproj 进行 pod install
  4. 新建自己的 workspace AppGroup.xcworkspace
  5. 将自己的 SharedLib.xcodeproj 和 pod install生成Pods.xcodeproj 拖入AppGroup.xcworkspace
  6. 配置SharedLib.xcodeproj 的 Framework Search Path为 Podfile中的 EXPORT_DEST_DIR

完成以上操作后，在整个AppGroup.xcworkspace 中的任何Project都可以以Framework的形式引入 Cocoapods管理的第三方库

使用Bridge后 Xcode头文件联想问题

可以在 Build Settings———— Framework Search Path 输入编译目录，则会再Framework编译后正常联想

1
$(TARGET_BUILD_DIR)

Podfile

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
# 这里标记使用Framework
use_frameworks!

#设定Workspace
workspace 'Playground'

# 该工程仅用于生成Pod.xcodeproj
target 'Pods-Bridge' do
  project "Pods-Bridge/Pods-Bridge.xcodeproj"

  #Net
  pod 'Masonry', '1.0.2'

end

# 加入脚本 将Pods生成的Frameworks
# 1. 拷贝到指定目录 EXPORT_DEST_DIR
# 2. 拷贝到 CODESIGNING_FOLDER_PATH的根目录 保证模拟器可以正常运行

EXPORT_PHASE_NAME = "Frameworks Export"
EXPORT_DEST_DIR = "$SRCROOT/../../Frameworks/"
EXPORT_ASSIGN_DEST = "cp -r $CODESIGNING_FOLDER_PATH #{EXPORT_DEST_DIR}"
EXPORT_BUILD_ROOT = "cp -r $CODESIGNING_FOLDER_PATH $CODESIGNING_FOLDER_PATH/../.."

post_install do |installer|
  installer.pods_project.targets.each do |target|

    # add build phase
    phase = target.shell_script_build_phases.select{ |bp| bp.name == EXPORT_PHASE_NAME }.first ||
      target.new_shell_script_build_phase(EXPORT_PHASE_NAME)

    phase.shell_path = "/bin/sh"
    phase.shell_script = "#{EXPORT_BUILD_ROOT}\n#{EXPORT_ASSIGN_DEST}"
    phase.show_env_vars_in_log = '0'
  end

end

备注

如果仅有一个App的情况，Pods-Bridge.xcodeproj可以是App的工程 App.xcodeproj,那么上文的 AppGroup.xcworkspace 和由 Podfile生成的 Pods-Bridge.xcworkspace就是一个Workspace

展开全文 >>

模块化与CocoaPods(26)：管理多Project

一份Podfile同时处理多个本地Project

根据CocoaPods官网给出的编写指南，我们可以使用一个Podfile文件来管理不同的Project

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
platform :ios, '8.0'

workspace 'Playground'

target 'SharedLib' do
  project '../SharedLib/SharedLib'
  pod 'Masonry'
end

target 'Playground' do
  project 'Playground'
  pod 'AFNetworking', '~> 3.0'
  pod 'Masonry'
end

在这种情况下 SharedLib.xcodeproj 所在的目录不会存在任何和Pods相关的文件，但是Prject本身被Pod执行了 4-6 步骤 ，此时打开 Playground.xcworkspace 可以得到正确的引用关系，但是会带来一些其它的问题

Project单独无法编译通过

由于 Podfile 执行完毕，其对 SharedLib.xcodeproj 产生了更改，会导致其单独打开编译无法通过，报错信息

1
ld: library not found for -lPods-SharedLib.a

可以看到原因是由于 -lPods-SharedLib.a 被Pods加入 Link Libraries

但是其存在于 Playground.xcworkspace 下 Pod.xcodeproj 的 Product目录中，单独打开 SharedLib.xcodeproj 在可视范围内找不到该库，导致无法进行正确的Link

Pods之间不共存

假设存在另外一个工程 Playsecond.xcodeproj 也想通过同样的方法引用 SharedLib.xcodeproj , 即使让SharedLib.xcodeproj 存在两个Target用于不同的引用

Target Podfile PODS_ROOT 被Pods添加的虚拟库
SharedLibA.a Playground/Podfile SharedLib/../Playground/Pods lPods-SharedLibA.a
SharedLibB.a Playsecond/Podfile SharedLib/../Playsecond/Pods lPods-SharedLibB.a

即使在这种情况下，也会出现Pods不共存的情况，现象为

  1. 在 Playground 下执行 pod update ， Playground.xcworkspace 里编译通过
  2. 在 Playsecond 下执行 pod update ， Playsecond.xcworkspace 里编译通过
  3. 回到 Playground 下，Playground.xcworkspace 编译不通过， 提示如下错误
  4. 进行步骤1 之后，会发现 Playsecond.xcworkspace 编译不通过，提示相同错误
1
The sandbox is not in sync with the Podfile.lock. Run 'pod install' or update your CocoaPods installation.

提示pod和 Podfile.lock 原因猜测 是因为每次Pod完成后会做一次Hash，如果当前工程的Hash值和Podfile.lock对不上，就会要求Update Pods的文件结构

由于 Playground.xcworkspace 和 Playsecond.xcodeproj 都会对 SharedLib.xcodeproj 进行更改，导致Hash值产生变化，所以会导致需要重新Update

展开全文 >>

模块化与CocoaPods(25)：StaticLib和Framework两种方式引入Pods

CocoaPods的原理

CocoaPods的原理就是通过脚本完成以下工作，假设存在 Playground.xcodeproj 的 Project

  1. 对所有库的头文件创建软连接，并且放入Pods目录
  2. 创建 Pods.xcodeproj 把所有的静态库打包在一起，形成一个虚拟的 lib-pods.a 的 Target
  3. 然后创建一个WorkSpace加入 Playground.xcodeproj 和 Pods.xcodeproj
  4. 配置 Playground.xcodeproj 的 Header Search Paths 引入所有Pod目录下库的头文件软连接
  5. 配置 Playground.xcodeproj 的 Linked Binary With Libraries 加入lib-pods.a
  6. 配置 Playground.xcodeproj 的 Build Phase 添加一系列脚本,类似 XX Pods XXX

使用Framework引入Pods

正常的情况下，Pods都是通过Static Lib来加载，根据CocoaPods官网可以使用指令 use_frameworks!

让Cocoapods以Framewrok的形式加入工程

1
2
3
4
use_frameworks!
platform :ios, '8.0'

........

CocoaPods 1.2.1版本的BUG

CocoPods的1.2.1版本无法将Static Lib的工程作为target，使用Pods，会报错如下,GitHub上说已修正

1
2
3
4
5
6
7
[!] Unable to find host target(s) for SharedLib. Please add the host targets for the embedded targets to the Podfile.
Certain kinds of targets require a host target. A host target is a "parent" target which embeds a "child" target. These are example types of targets that need a host target:
- Framework
- App Extension
- Watch OS 1 Extension
- Messages Extension (except when used with a Messages Application)

展开全文 >>

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

我写的，大概率是错的。。。。。