# 老司机 iOS 周报 #124 | 2020-08-17

![ios-weekly](https://github.com/SwiftOldDriver/iOS-Weekly/blob/master/assets/ios-weekly.png?raw=true)
老司机 iOS 周报，只为你呈现有价值的信息。

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

## WWDC20

本周在周报公众号上我们推送了 2 篇 WWDC20 内参专栏内的文章，每篇都很精彩！

- [App Clips 的配置及链接处理](https://mp.weixin.qq.com/s/7CY_C1Y8FSlFy5mQJH5g0g)
- [App Clip 的最佳实践](https://mp.weixin.qq.com/s/D26QI0uBa71UVQIOm2PjOg)

## 新手推荐

### 🐕 [深入理解 YYCache](https://juejin.im/post/6856665902655078407#heading-11)

[@JonyFang](https://github.com/JonyFang)：iOS 开发过程中会用到各种缓存，YYCache 也是大家所熟悉的一个缓存框架。由 YYKit 作者 @ibireme 开发，也是 YYKit 组件之一，是一个线程安全的高性能缓存框架。本篇主要是对 YYCache 内部 YYMemoryCache 和 YYDiskCache 的部分核心源码进行分析及提出了一些使用过程中的小 Tips，可以拿来借鉴使用。除了本文，也推荐看下其他的几个 YYCache 的源码分析文章。链接放到这里：

- [YYCache 设计思路](https://blog.ibireme.com/2015/10/26/yycache/)
- [YYCache 源码解析](https://juejin.im/post/6844903554214264840#heading-2)
- [从 YYCache 源码 Get 到如何设计一个优秀的缓存](https://lision.me/yycache/)

## 文章

### 🐕 [一文读懂fishhook原理](https://juejin.im/post/6857699952563978247)

[@五子棋](https://satanwoo.github.io)：一篇写的比较清晰的 fishhook 原理的解析文章，整体流程上写的比较完善，可以作为入门 fishhook 学习的一篇文章。

### 🐕 [Hook Alamofire](https://github.com/neil-wu/FridaHookSwiftAlamofire/blob/master/howto.md)

[@四娘](https://kemchenj.github.io)：这篇文章着重从 Swift Runtime 数据结构入手进行分析，面向 GitHub 上 3.3 万 star 的 Swift HTTP 网络库 Alamofire，实现一个基础版本的抓包工具，具备：打印 GET / POST 请求；屏蔽 SSL Pinning。过程中会介绍到 Swift 的内存布局，函数调用约定，参数传递，运行时函数调用。

> 推荐人：[Neil Wu](https://github.com/neil-wu)

### 🐕 [经典源码分析之 OCMock](https://juejin.im/post/6856324901419909127)

[@老驴](https://www.weibo.com/6090610445)：OCMock 作为 iOS 圈内老牌 Mock framework，一直都被大家广泛使用。在使用 OCMock 过程中，有时候会遇到一些比较难以理解的问题，这个时候，想要 debug 就不会是那么容易的一件事了。文章作者也是因为这样的原因，去阅读了 OCMock 的源码。而通过阅读源码，作者也发现并且总结了一些比较难以发现的使用点。如果你现在在用 OCMock 的话，不妨一读。

### 🐎 [Flutter+FaaS一体化任务编排的思考与设计](https://mp.weixin.qq.com/s/y-poJ5yX4t91b88PDW1o_Q)

[@Damien](https://github.com/ZengyiMa)：本文是闲鱼团队 Flutter+Serverless 三端一体研发架构中任务编排相关的介绍，从如何提高 FaaS 研发体验与研发质量问题出发，通过将具体的业务流程抽象为任务的方式来进行任务编排，以及沉淀多个任务形成云端任务中台来提高研发体验。体系化的处理异常分类、捕获异常与异常监控等多种手段来提高研发质量。对研究移动端 FaaS 一体化研发模式的同学值得一读。

### 🐕 [为什么使用汇编可以 Hook objc_msgSend（下）- 实现与分析](https://mp.weixin.qq.com/s/H6BmHEocf5jN78gfuY-tuA)

[@J_Knight_](https://weibo.com/1929625262/profile?rightmod=1&wvr=6&mod=personinfo&is_all=1)：本文介绍了使用 fishhook + 内联汇编来实现 Hook objc_msgSend 的全部实现及其内在原理，包含了以下知识点：

- 什么是 Inline Hook 技术？
- fishhook 的实现原理是什么？
- 为什么 fishhook 可以 Hook objc_msgSend 方法？
- 如何使用内联汇编来进行记录上下文和还原上下文操作？
- 如何使用内联汇编通过方法地址调用方法？
- 汇编语句模版的简单使用

### 🐕 [一文看破 Swift 枚举本质](https://mp.weixin.qq.com/s/Gx7L_Ev0DV19mLYMnH-R1Q)

[@xiaofei86](https://weibo.com/xuyafei86)：本文通过内存结构和 SIL 对 Swift 中枚举的实现进行分析，对过程感兴趣的同学可以阅读原文了解，主要结论如下：

1. 简单枚举<没有关联值>的本质就是一个整型值，整型值的大小取决于该枚举所定义的类型的数量。
2. 给枚举添加原始值不会影响枚举自身的任何结构，设置原始值其实是编译器帮我们添加了 rawValue 属性，```init(rawValue)``` 方法 RawRepresentable 协议。
3. 添加关联值会影响枚举内存结构，关联值被储存在枚举变量中，枚举变量的大小取决于占用内存最大的那个类型。
4. 添加/调用"实例方法"、"类型方法"、计算属性以及实现协议的本质都是添加/调用函数。
5. 对于没有添加关联值的枚举系统会默认帮我们实现 Hashable/Equatable 协议。

### 🐕 [面向 5G 的阿里自研标准化协议库 XQUIC](https://mp.weixin.qq.com/s/rwa-xUamJtAaIBVZj3eCNA)

[@looping](https://github.com/looping)：XQUIC 是阿里巴巴淘系架构团队根据 IETF QUIC 标准化草案版本自研的协议库。本文对 QUIC 进行了基本的扫盲，并重点介绍了 XQUIC 的设计原理，网络传输优化，以及 Multipath QUIC 技术这几块，内容十分丰富。同时项目已经有开源计划，感兴趣的同学可以持续关注。

### 🐕 [客户端稳定性优化实战，Crash率最高下降40%](https://mp.weixin.qq.com/s/jQfrxyvVtBBjUXkJuRinGA)

[@Parsifal](https://github.com/ParsifalC)：我们可以通过提高代码质量和健壮性来降低 App 在线上的闪退率，做到这一步一般就能将 App 的用户闪退率保持在可接受的范围。但对于淘宝这种超级 App，亦或是类似电商产品上，在活动旺季往往遇到更多的是 OOM 类型闪退（产品和交互天花乱坠的营销页面设计，各类 AR、视频等等技术应用，跨端方案的集成，都会带来额外的内存开销）。OOM 类型闪退通常难以定位和排查，相应地也比较难修复。大厂在做性能优化中，都会将 OOM 作为一个比较重要的指标考察，也产出来不少工具和方案。比如周报往期推荐的腾讯出品的 [OOMDetector](https://github.com/Tencent/OOMDetector)，Facebook 的 [Reducing FOOMs in the Facebook iOS app](https://code.fb.com/ios/reducing-fooms-in-the-facebook-ios-app/) 等等。淘宝团队根据这几年的沉淀，提出了三个内存优化策略：

- 精打细算，提升内存的使用率
- 兜底容灾，尽量让应用延长生命
- 提升内存上限，突破系统的天花板

对业务的内存使用精打细算这是最直接有效的方式，控制内存使用以及降级方案都能有效减少 OOM；兜底容灾得益于 iOS 框架的优势系统已经能自动管理多余内存的释放（比如 UIImageNamed 的享元模式管理、NSCache 的 LRU 等），但 `didReceiveMemoryWarning` 往往会被我们忽略；提升内存上限，对于 iOS 侧这个只能依赖于 WKWebView 独立进程的应用了。总的来说，这是一篇淘宝团队对外总结自己内存管理策略的一篇文章，理念可以参考借鉴。

### 🐕 [iOS 开发体验优化方案](https://mp.weixin.qq.com/s/f6hHl9_TLnWqB4hs99ut1Q)

[@红纸](https://github.com/nianran)：本文是闲鱼团队针对于其团队搭建环境、切换分支打包慢，做了体验上的几点有效优化。

在解决环境搭建的问题上，闲鱼团队选择了部分 docker 化，即将包管理工具 cocoapods 和 taobaoenv 等配置 docker 化，pods 缓存内容挂在在 docker 上。由于 docker 的可移植性上的先天优势，使得开发者能够更快速的构建统一环境，解决了维护的问题。

切分支后 APP 打包速度问题上，其选择了 install 前先缓存 Pods Projects 跟 Flutter 的编译产物，切换分支后，复原编译产物。

> 小编注：闲鱼文中提及的 pod 版本为 1.2.0 版本，属于比较老的 pod 版本了。在 [pod  1.3.0](http://blog.cocoapods.org/CocoaPods-1.3.0/) 中，pod 增加了增量编译的更新内容，在切换分支后，会进行增量编译，理论上能解决部分闲鱼的打包速度问题。

### 🐕 [As We May Code](https://nshipster.com/as-we-may-code/)

[@EyreFree](https://github.com/EyreFree)：本文分享了 Mattt 对于将 [语义网](https://zh.wikipedia.org/wiki/%E8%AF%AD%E4%B9%89%E7%BD%91) 应用于源代码的一些想法。语义网（semantic web）这个词这个词可能很多人没有听过，本文展望了源代码结合语义网方式进行管理后的各种优势，整体看起来比较偏向于概念，还没有实际的应用，感兴趣的朋友可以看下。

## 工具

### [远程输入法](https://github.com/remoboard/remoboard-source)

[@老峰](https://github.com/gesantung)：远程输入法是来自 [@everettjf](https://github.com/everettjf) E神的一款开源远程输入法，可以实现使用电脑给手机打字，让手机打字更快.支持 Web 、蓝牙、IP 连接，实现思路巧妙，对输入法及远程交互感兴趣的读者可以阅读[源码](https://github.com/remoboard/remoboard-source)。

### [SwiftDump](https://github.com/neil-wu/SwiftDump/blob/master/README_zh.md)

SwiftDump 是从 Mach-O 文件中获取 Swift 对象定义的命令行工具，类似大家都用过的 OC dump 工具 class-dump，SwiftDump专注于处理 Swift对象(当前只支持 Swift 5)。
工具采用 Swift编写，代码简短，可以借此一窥 Mach-O 中是如何处理 Swift 相关信息的。

> 推荐人 [@neil-wu](https://github.com/neil-wu)

## 内推

老司机周报团队联合知识小集和 SwiftGG 翻译组收录了一份靠谱的内推职位。

如果你想**找工作**，点这里：<https://www.yuque.com/iosalliance/article/bhutav>

如果你想**招人**，点这里：<https://www.yuque.com/iosalliance/article/ycyhf3>

当然，也欢迎你关注我们每一期的周报，我们会在每期周报底部及时更新编辑内推岗位。

## 关注我们

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

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

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

## 说明

🚧 表示需某工具，🌟 表示编辑推荐

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