# 老司机 iOS 周报 #22 | 2018-06-04

![ios-weekly](../assets/ios-weekly.png)
老司机 iOS 周报，只为你呈现有价值的信息。

你也可以为这个项目出一份力，如果发现有价值的信息、文章、工具等可以到 [Issues](https://github.com/SwiftOldDriver/iOS-Weekly/issues) 里提给我们，我们会尽快处理。记得写上推荐的理由哦。有建议和意见也欢迎到 [Issues](https://github.com/SwiftOldDriver/iOS-Weekly/issues) 提出。

本周将迎来 WWDC 18，我们会在掘金上参与 WWDC 专题文章的编写，周报将停更一周。

## 新闻

### [Apple Silently Launched Creative Testing in App Store Search Ads](https://asostack.com/apple-secretly-launched-creative-testing-in-app-store-search-ads-761a9f7b8abb)

Apple 悄悄发布了针对 App Store 搜索广告的 Creative Testing 功能，移动开发者现在可以在 App Store 里测试不同的搜索广告。虽然这并不是很多人期待的 A/B 测试，但它为广告发布者提供了更多的权力，这篇文章详细解释了这个新功能的用法。

## 专栏

### 🌟 🐢 [深入 Decodable —— 写一个超越原生的 JSON 解析器](https://xiaozhuanlan.com/topic/8973560241)

老司机 iOS 专栏最新一篇文章，带大家深入 Decodable，文章分为两个部分，第一部分讲 Decoder 的抽象，分析原生 JSONDecoder 的一部分实现，第二部分带着大家自定义一个 JSONDecoder，并且针对原生的不足，做一些针对性的优化，让自定义的 Decoder 拥有更强的性能和拓展性。

## 文章

### 🌟 🐢 [Google Swift Style Guide](https://google.github.io/swift/)

这是一份非常具有实践意义的 style guide。全面、细致的介绍了各种规范，难能可贵的是有些地方还说明了为何选择了这样的规范。即使最后没有利用这份规范也可以看看一份规范包含了哪些方面，极富参考意义。

Linkedin 的 [swift style guide]( https://github.com/linkedin/swift-style-guide) 也是一份比较完整的 style guide。

### 🌟 🐢 [Core ML入门：构建一个简单的图像识别应用](http://swift.gg/2018/05/28/coreml-introduction/)

由 SwiftGG 翻译组翻译自 Sai Kambampati 的博客。文章一步一步地教大家实现一个基于 CoreML 的图像识别器，而且特别贴心的是，作者提供了一系列的 Demo 工程，让读者可以随意跳过一些准备步骤，提高学习效率。完整的 Demo 工程请在 [Github](https://github.com/appcoda/CoreMLDemo) 上查看。

### 🐢 [如何实现 App Store App 的自动下载](https://juejin.im/post/5b0a252d51882538b63af5c3)
如果 App Store 是开源的，要按照以下步骤实现自动下载，我想对于绝大多数开发者，都不会是难事：

1. 进入 App Store，切换 tab 到搜索界面
2. 设置搜索关键字、搜索
3. 进入列表页后，点击 App 进入详情页点击下载
4. 根据提示完成登陆、下载，并在下载完成以后跳转到推荐 Tab
5. 进入推荐 Tab 后，退出登陆

但不幸的是，App Store 并没有开源，这篇文章则通过逆向技术找到以上步骤所需要 API 并实现了自动下载，对于逆向初学者来说，这是一个很好的练手项目。

### 🐎 [黑苹果安装学院](https://github.com/huangyz0918/Hackintosh-Installer-University/blob/master/README-CN.md)

自从苹果采用 Intel 的处理器，OS X 被黑客破解后可以安装在 Intel CPU 与部分 AMD CPU 的机器上。从而出现了一大批非苹果设备而使用苹果操作系统的机器，被称为黑苹果（Hackintosh）。这个仓库收集了各种型号的黑苹果安装方法。我们都知道， 黑苹果其实是一个具有潜在盗版性质的行为，因为它违反了苹果公司的 EULA 法案（EULA）。 所以这个 Github 仓库只是以安装黑苹果为一个引线，进而介绍和分享关于苹果操作系统的相关知识和系统的一些安装方法。

### 🐎 [这才是 WKWebview Cookie 管理的正确方式](https://www.jianshu.com/p/163c03ed0b5e)

目前绝大多数的团队处理 WKWebView Cookie 的方式是这样子的：webview 每次发起 load url 请求前客户端塞 cookie 到请求头里传给服务器，并且通过 js 注入的方式将 cookie 同步给前端这种方案。

文中提出了新的一种方案：首次加载 url 的时候，预先加载一个 cookie webview，将 Cookie 先使用 js注入的方式写到 cookie webview 的共享 WKProcessPool。当 WKWebView 正式加载的时候就实现了 Cookie 的同步。

### 🐎 [为什么我用 Texture 来搭建 App（并且你也应该）](https://medium.com/flawless-app-stories/why-i-build-my-apps-using-texture-and-why-you-should-too-99587c73f278)

作者介绍了 Texture 被创造出来的起源，与 UIKit 的对比，并且列举了几种场景下两个框架的发挥，例如 stackView 的使用，tableView 的列表反转等等，得益于 Flexbox 布局，异步渲染等等的机制让 Texture 在这些场景下发挥得比 UIKit 更加优秀。

### 🐢 [RunLoop 源码阅读](https://juejin.im/post/5aaa15d36fb9a028d82b7d83)

现在大部分 iOS 简历上都会写「理解 RunLoop」细问之后却是一知半解。本文通过源码方式讲解 RunLoop 相关知识，包含：

- 为什么需要 RunLoop?
- 如何做到一个线程只有一个 RunLoop(Thread-specific data)
- CFRunLoopDoObservers
- 如何让线程在空闲时休眠及唤醒(mach_msg)

### 🐢 [iOS App 使用 GCD 导致的卡顿问题](http://mrpeak.cn/blog/ios-gcd-bottleneck/)

在我们通常的认知中，都认为 `dispatch_async` 非常高效不会卡顿，Peak 在实际项目中发现一个卡顿堆栈可能与 `dispatch_async` 有关， 之后利用 TSI 向 Apple 寻求 technical support，通过问答形式解释了为什么 `dispatch_async` 有时也会卡顿。

### 🐢 [高效的数据压缩编码方式 Protobuf](https://github.com/halfrost/Halfrost-Field/blob/master/contents/Protocol/Protocol-buffers-encode.md)

本文通过详细的介绍，帮助读者了解 Protocol buffers 的最新版本 proto3 基本用法和主要特性，并阐述了 Protocol buffers 的编解码流程，是一篇很详尽的 Protocol buffers 入门级学习资料。通过阅读本文，读者能够明白以下几点：

- Protocol Buffer 利用 varint 原理压缩数据以后，二进制数据非常紧凑，option 也算是压缩体积的一个举措。所以 pb 体积更小，如果选用它作为网络数据传输，势必相同数据，消耗的网络流量更少。但是并没有压缩到极限，float、double 浮点型都没有压缩。
- Protocol Buffer 比 JSON 和 XML 少了 {、}、: 这些符号，体积也减少一些。再加上 varint 压缩，gzip 压缩以后体积更小！
- Protocol Buffer 是 Tag - Value (Tag - Length - Value)的编码方式的实现，减少了分隔符的使用，数据存储更加紧凑。
- Protocol Buffer 另外一个核心价值在于提供了一套工具，一个编译工具，自动化生成 get/set 代码。简化了多语言交互的复杂度，使得编码解码工作有了生产力。
- Protocol Buffer 不是自我描述的，离开了数据描述 .proto 文件，就无法理解二进制数据流。这点即是优点，使数据具有一定的“加密性”，也是缺点，数据可读性极差。所以 Protocol Buffer 非常适合内部服务之间 RPC 调用和传递数据。
- Protocol Buffer 具有向后兼容的特性，更新数据结构以后，老版本依旧可以兼容，这也是 Protocol Buffer 诞生之初被寄予解决的问题。因为编译器对不识别的新增字段会跳过不处理。

扩展阅读

[iOS 中使用 Protocol Buffer](https://juejin.im/post/5a2fe22851882510b2755b23)

[Protobuf 中 set_allocated_xxx 排雷](https://juejin.im/entry/5aa338416fb9a028c675516b)

[Protobuf3 进阶系列](https://blog.csdn.net/hry2015/article/category/6885899)

[Protobuf 应用实践之RPC框架：Google gRPC](https://juejin.im/post/5b01ec866fb9a07aca7a7289)

[随手记实践 Protobuf 经验分享](https://mp.weixin.qq.com/s/y0dyK47_sirCteAkbh_ebw)

### 🐕 [iOS-factor](https://ios-factor.com/)

12-Factor 是软件即服务应用（SaaS）的一个著名方法论集合。iOS-factor 则从这个项目得到灵感，提炼出 iOS 开发相对应的方法论。本文则是阐述了这一方法论。目前总共有：依赖管理，配置，开发环境与线上环境等价，部署，本地优先于远端，向后兼容的 API，版本号，持久化数据这八个类别。

### 🐢 [Static linking vs dyld3](https://allegro.tech/2018/05/Static-linking-vs-dyld3.html)

优化应用启动时间是 app 开发中必不可少的一个环节。Allegro 的开发工程师在文中总结了他们如何通过静态链接优化减少启动时间的实践过程。以及遇到了如下几个问题：

- 如何解决 Xcode8 不支持 Swift 静态链接的问题
- 如何解决静态链接后资源文件管理问题
- 如何解决一个静态库被多个库引用的问题

在文章的第二本部分，Allegro 的开发工程师描述了他如何绕过系统限制让 app 用上 dyld3，并且通过冷热启动的方式对比了 dyld2、dyld3、静态链接三个之间方式的启动速度对比。

### 🐕 [不必要的 HTTP 头信息](https://www.fastly.com/blog/headers-we-dont-want)

作者统计了 30 个最常见的 HTTP 头信息，其中很多并没有使用的必要。例如并没有什么用，只是起到注释作用的 Server、X-Powered-By、Via。有实际效果，但并不是实现该效果的最佳方式的 P3P、Expires、X-Frame-Options、X-UA-Compatible。在标准之外的不会被任何浏览器识别的 X-ASPNet-Version，X-Cache。 而一些更有用的头信息却很少网站使用，例如提高安全性的 Content-Security-Policy 和 Strict-Transport-Security，提升性能的 Link rel=preload。

### 🐕 [Writing self-documenting Swift code](https://www.swiftbysundell.com/posts/writing-self-documenting-swift-code)

我们应该尽可能使我们的代码和我们设计的 API 更容易被理解，可以拆分复杂的方法，使用清晰明了的 API， 为标识符创建新类型或别名。写好自解释代码，可以让我们的注释专注于架构设计，而不是经常变化的实现细节。

## 工具

### [Crunch](https://github.com/chrissimpkins/Crunch)
一款超好用的 PNG 图片无损压缩工具，提供了三种方便的使用方式：CLI、GUI 和右击服务，虽然与其他大多数压缩工具一样都是基于 Google 的 [zopfli](https://github.com/google/zopfli) 算法，但 Crunch 会根据不同的图片，动态调整压缩参数，以达到最好的压缩效果。

另外，如果对压缩率要求不高，但是希望有个万能的 CLI 压缩工具的话，[Leanify](https://github.com/JayXon/Leanify) 会是个不错的选择，它支持多达 20 多种文件格式的压缩。

## 代码

### [KTVVideoProcess](https://github.com/ChangbaDevs/KTVVideoProcess)

KTVVideoProcess 是唱吧开源的一个视频处理框架，整体的设计灵感（Source -> Filter Pipeline -> Output）参考了 GPUImage，但其声称提供了比 GPUImage 更高的性能。和作者简单交流得知其中核心提升就是加入了 concurrent 的能力，GPUImage 只有一个 video process queue 来串行的执行 filter，没有最大限度压榨 CPU/GPU 的性能。对于视频处理的场景，我们需要对每一帧都应用同一组 filter，如果 filter 处理时间太久就会导致丢帧。KTVVideoProcess 针对该场景，实现了并行处理多个帧的机制，较好的解决了极端情况丢帧的问题。

为了提升串行 filter 队列的性能就写一个全新的框架，是不是最好的解决办法呢？这点我持保留意见。一般情况下多 Filter 性能问题可以通过合并 filter、优化 shader 算法的实现的方式来解决。

初步看了一下，目前完成度还不算高，提供的内置 Filter 还比较少，而且缺少 TwoInputFilter 这样的常用的基础 Filter，如果使用免不了会有较多场景需要手写 shader 来完成。不过框架的代码简洁清晰，如果有希望学习 GPUImage 内部实现的同学倒是可以考虑从这个框架学起。


### [The unofficial WWDC app for macOS](https://github.com/insidegui/WWDC)

macOS 平台上的 Unofficial WWDC app for macOS 这款第三方 WWDC 应用更新了，新版本加入了对 iCloud 同步、Touch Bar 和日历集成等功能的支持。该应用完全开源，感兴趣可以到它的 [GitHub 项目页面](https://github.com/insidegui/WWDC)看看。

## 音视频

### 🚧 [WWDC 97](http://bslabs.net/2018/05/28/wwdc-1997-videos/)

有网友意外发现 WWDC 97 的 session 居然发行过光盘，发布到了 youtube。有怀旧情节的朋友可以看看。

推荐两个视频：

- [Closing Keynote - Steve Jobs Fireside Chat](https://www.youtube.com/watch?v=KWJ6rGiopvo)

  乔帮主和开发者的闲聊，阐述了他对科技产品、软件的一些思考，魅力依旧。

- [Session 500 - Apple Hardware Roadmap](https://www.youtube.com/watch?v=ekkSkuY1EcI)

  苹果硬件路线介绍，20年前的 **Phil Schiller** 看起来和现在并没有什么区别。还有现在已经不太露面的  **Jonathan Ive**（32 分钟开始）。


## 内推

[深圳头条研发中心诚招各路 iOS 好手一起做取悦自己的项目](https://job.toutiao.com/2018/spring_referral/?token=alPR8WCv8nnnc5QqtsyKjw%3D%3D&key=MTY1MDMsMTg0MTQsMjA1MjAsMTk1NjEsMTU2ODksMTc0ODk%3D)

## 关注我们

我们开通了公众号，每期发布时公众号会推送消息，欢迎关注。

![](https://github.com/SwiftOldDriver/iOS-Weekly/blob/master/assets/qrcode_for_wechat.jpg?raw=true)

同时也支持了 RSS 订阅：https://github.com/SwiftOldDriver/iOS-Weekly/releases.atom 。

## 本期编辑

[@没故事的卓同学](https://weibo.com/1926303682/profile)，[@四娘](https://kemchenj.github.io)，[@mmoaay](https://weibo.com/u/1302422271)，[@享耳先森](https://github.com/iblacksun)，[@Damonwong](https://weibo.com/damonone)，[@折腾范儿_味精](http://weibo.com/agvicking)，[@张嘉夫](https://weibo.com/2949394297)，[@AidenRao](https://weibo.com/AidenRao)，[@Parsifal](https://weibo.com/parsifalchang)，[@aaaron7](https://weibo.com/aaaron7)，[@方秋枋](https://weibo.com/100mango)，kyo，[tom510230](https://xiaozhuanlan.com/u/6682065345)

## 说明

🚧 表示需翻墙，🌟 表示编辑推荐

预计阅读时间：🐎 很快就能读完（1 - 10 mins）；🐕 中等 （10 - 20 mins）；🐢 慢（20+ mins）


