发布前调整。

Author: ParsifalC

Reports/2019/#63-2019.04.15.md

@@ -57,33 +57,13 @@
 
 [@kyo](https://github.com/KyoLi)：在移动互联网时代，对于各家公司而言，什么东西最重要呢？我想大多数的答案应该是流量。本文当然不是讨论如何获取更多的流量等问题，毕竟那更多是产品运营的事情，而为流量做保驾护航的，就是网络。所以，如何优化网络，也是各厂纷纷探索的方向。对于流量越大的 App 而言，网络优化所带来的收益也越大。本文由百度 App 研发团队所写的[百度 App 网络深度优化系列]的第一篇，DNS 的优化，从百度这个亿级日活的 App 自身的实践中总结出来的，非常值得好好看下。
 
-### 🌟 🐢 [Let’s write Swift code to intercept SSL Pinning HTTPS Requests](https://medium.com/@kennethpoon/lets-write-swift-code-to-intercept-ssl-pinning-https-requests-12446303cc9d)
+### 🌟 🐎 [Pure protocol factory for Interface Builder-based views](https://blog.hal.codes/ib-constructible)
 
-[@含笑饮砒霜](http://chinafish.news)：现在几乎绝大部分的 iOS App 都使用了 HTTPS 请求，这极大提升了我们使用的安全性，但也不意味着这就是绝对安全的。
-
-如果想检查 iOS 应用中的 HTTPS 请求，最常用的方法就是中间人（MITM）攻击，这种技术需要使用某台主机作为代理服务器，为客户端提供服务。为了保证攻击成功，客户端需要将代理服务器的证书安装到设备的全局信任存储区中。这样处理后，客户端就会将证书添加到白名单中，允许与代理服务器之间的 HTTPS 通信。
-
-如果想保护应用免受 MITM 攻击影响，可以使用 SSL 校验证书绑定，此时受信任服务器的证书副本会打包到 iOS 应用中，还有一些附加代码可以确保应用只与使用特定证书的服务器通信。当 SSL 证书绑定处于激活状态时，应用不会将任何请求发送到不受信任的服务器上。
-
-即便如此，也依然可以绕过 SSL 证书绑定。也就是在具体请求通过受保护的 HTTPS 通道发送之前，尝试拦截这个请求，这需要将代码植入到应用中，这里会用到代码注入的相关知识。
-
-如果想更细致的了解如何拦截 HTTPS 请求，本文不可错过，绝对深度好文。
-
-### 🐎 [JSON as configuration files: please don’t ](https://arp242.net/weblog/json_as_configuration_files-_please_dont)
-
-[@olddonkey](https://github.com/olddonkey)：这是一篇 2016 年的老文章，但是其中的观点直到今天依然具有参考价值。
-
-很多公司，很多团队使用 JSON 文件作为 App 的配置文件，不论是从远程下发，还是本地加载。
-
-但是，在实际的项目中，用 JSON 来作为配置文件解决方案并不是个完美的方案，它存在的很多问题，这些问题会在实际中逐渐暴露。
+[@looping](https://github.com/looping)：多人协作引起的代码合并冲突是我们使用 Storyboard 进行开发时常会遇到的比较头疼的问题了。避免这类协作问题的常用解决方案就是制定规范，规定一个界面用一个 Storyboard，并由单人维护。这样虽然解决了协作问题，但假如在写实例化代码时不进行优化，还是会存在一些不太友好的冗余代码，甚至硬编码。例如，`let controller = UIStoryboard(name: "MyViewController", bundle: Bundle(for: MyViewController.self)).instantiateInitialViewController() as? MyViewController`。
 
-文章作者围绕这他心中的几个缺点展开论述：
-1. 注释容易缺失。
-2. 可读性差。
-3. 过分严格的格式。
-4. 缺乏可编程性。
+本文作者就分享了一种优化思路，他通过设计一个 UIViewController 的协议（protocol）IBConstructible —— 带有 nibName 和 bundle 这两个属性，利用 Swift 允许通过扩展（Extension）为协议提供默认实现的特性，使得最终实例化代码变得非常简洁，`let controller = MyViewController.fromNib`。
 
-本文虽本意是针对 Web 开发提出观点，但是对 Mobile 开发也一样适用。
+如果有在使用 Storyboard 进行开发的团队，但还没有对相关代码进行优化的话，可以参考本文提供的方案来处理，让代码变得更加简洁。如果已经优化过的，不妨也分享下自己的思路。同时本文的优化技巧也是可以用在很多代码重构的场景上的。
 
 ### 🐎 [RunLoop 实战：实时卡顿监控](https://juejin.im/post/5cacb2baf265da03904bf93b)
 
@@ -100,31 +80,10 @@
 
 > 由 [yuhanle](https://github.com/yuhanle) 推荐
 
-### 🐢 [干货 | 近万字长文详述携程大规模应用RN的工程化实践](https://mp.weixin.qq.com/s?__biz=MjM5MDI3MjA5MQ==&mid=2697268025&idx=1&sn=2d197c4cf7a338246abe0d3111e16002)
-
-[@Damonwong](https://github.com/Damonvvong): 如果谈起 React Native 在国内的业务落地，我可能第一个会想起的就是携程和赵辛贵老师。在上次听完赵兴贵老师分享的专题《携程无线持续交付平台工程实践》之后，意犹未尽，一直想更加深入了解一下携程在 RN 方面的技术探索。今天终于等到了携程的 RN 建设及他们设计的 CRN 的分享。这篇文章主要讲了下面几个事情：
-
-1. RN 在携程中的使用情况
-2. 携程基于 RN 优化的 CRN 框架的设计及使用
-3. CRN 做了哪些性能优化及实际效果比较
-4. 如何发布及运维
-
-比较可惜的是没有看到这套系统相比较于原生开发，对业务增长，开发效率有哪些优化，所以比较期待后续能有这方面的分享。
-
-最后，在文中提到将要开源的 CRN，也已经开源了，感兴趣的同学移步 [携程开源RN开发框架CRN](https://mp.weixin.qq.com/s/r6mB5Zq3jIf-K2YQi_AS8Q) 查看。
-
 ### 🐎 [一篇文章读懂 HTTPS 及其背后的加密原理](https://mp.weixin.qq.com/s/3gI8avaaaEaBJjOKitN7Fw)
 
 [@J_Knight_](https://github.com/knightsj)：作者以使用 HTTPS 的缘由为切入点，从对称加密和非对称加密的对比，数字证书，数字签名，以及 HTTPS 通信的建立流程这几个方面介绍了 HTTPS。
 
-### 🐎 [Pure protocol factory for Interface Builder-based views](https://blog.hal.codes/ib-constructible)
-
-[@looping](https://github.com/looping)：多人协作引起的代码合并冲突是我们使用 Storyboard 进行开发时常会遇到的比较头疼的问题了。避免这类协作问题的常用解决方案就是制定规范，规定一个界面用一个 Storyboard，并由单人维护。这样虽然解决了协作问题，但假如在写实例化代码时不进行优化，还是会存在一些不太友好的冗余代码，甚至硬编码。例如，`let controller = UIStoryboard(name: "MyViewController", bundle: Bundle(for: MyViewController.self)).instantiateInitialViewController() as? MyViewController`。
-
-本文作者就分享了一种优化思路，他通过设计一个 UIViewController 的协议（protocol）IBConstructible —— 带有 nibName 和 bundle 这两个属性，利用 Swift 允许通过扩展（Extension）为协议提供默认实现的特性，使得最终实例化代码变得非常简洁，`let controller = MyViewController.fromNib`。
-
-如果有在使用 Storyboard 进行开发的团队，但还没有对相关代码进行优化的话，可以参考本文提供的方案来处理，让代码变得更加简洁。如果已经优化过的，不妨也分享下自己的思路。同时本文的优化技巧也是可以用在很多代码重构的场景上的。
-
 ### 🐕 [Stubbing in pair with Swift compiler: a spy registration](https://medium.com/flawless-app-stories/stubbing-in-pair-with-swift-compiler-a-spy-registration-bbfdc1cf87a1)
 
 [@zvving](https://twitter.com/zvving)：45 期我们曾介绍过 [Unit tests 中轻量级 stubbing 实现](https://medium.com/@londeix/stubbing-in-pair-with-swift-compiler-c951770a295b)，其中测试用例执行前注册 stub body 的过程略显繁琐。
@@ -166,7 +125,7 @@ LeetCode 已入驻国内，中文名[『力扣』](https://leetcode-cn.com)，
 
 ## 书
 
-### 🐎 [Swift 5.0 中文版官方文档](https://swiftgg.gitbook.io/swift/swift-jiao-cheng)
+### 🌟 🐎 [Swift 5.0 中文版官方文档](https://swiftgg.gitbook.io/swift/swift-jiao-cheng)
 
 [@老峰](https://github.com/GesanTung)：上个月 [Swift 5.0](https://mp.weixin.qq.com/s/-fLVdoTz3lT5Kxnea0-Avg) 正式发布了，这是 Swift 发展史一次重要的迭代。SwiftGG 翻译组最近也更新了 [Swift 5.0 中文版官方文档](https://swiftgg.gitbook.io/swift/swift-jiao-cheng)，内容覆盖了 Swift 的基础语法结构以及各种高级特性，感兴趣的读者快来学习吧。
 

Reports/2019/#64-2019.04.22.md

@@ -0,0 +1,97 @@
+# 老司机 iOS 周报 #1 | 2019-03-25
+
+![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) 提出。
+
+## 新闻
+
+> 行业相关的新闻、趣事、看法
+
+## 新手推荐
+
+> 收集一些对新手友好且质量不错的文章
+
+## 文章
+
+### 🌟 🐢 [Let’s write Swift code to intercept SSL Pinning HTTPS Requests](https://medium.com/@kennethpoon/lets-write-swift-code-to-intercept-ssl-pinning-https-requests-12446303cc9d)
+
+[@含笑饮砒霜](http://chinafish.news)：现在几乎绝大部分的 iOS App 都使用了 HTTPS 请求，这极大提升了我们使用的安全性，但也不意味着这就是绝对安全的。
+
+如果想检查 iOS 应用中的 HTTPS 请求，最常用的方法就是中间人（MITM）攻击，这种技术需要使用某台主机作为代理服务器，为客户端提供服务。为了保证攻击成功，客户端需要将代理服务器的证书安装到设备的全局信任存储区中。这样处理后，客户端就会将证书添加到白名单中，允许与代理服务器之间的 HTTPS 通信。
+
+如果想保护应用免受 MITM 攻击影响，可以使用 SSL 校验证书绑定，此时受信任服务器的证书副本会打包到 iOS 应用中，还有一些附加代码可以确保应用只与使用特定证书的服务器通信。当 SSL 证书绑定处于激活状态时，应用不会将任何请求发送到不受信任的服务器上。
+
+即便如此，也依然可以绕过 SSL 证书绑定。也就是在具体请求通过受保护的 HTTPS 通道发送之前，尝试拦截这个请求，这需要将代码植入到应用中，这里会用到代码注入的相关知识。
+
+如果想更细致的了解如何拦截 HTTPS 请求，本文不可错过，绝对深度好文。
+
+### 🌟 🐢 [干货 | 近万字长文详述携程大规模应用RN的工程化实践](https://mp.weixin.qq.com/s?__biz=MjM5MDI3MjA5MQ==&mid=2697268025&idx=1&sn=2d197c4cf7a338246abe0d3111e16002)
+
+[@Damonwong](https://github.com/Damonvvong): 如果谈起 React Native 在国内的业务落地，我可能第一个会想起的就是携程和赵辛贵老师。在上次听完赵兴贵老师分享的专题《携程无线持续交付平台工程实践》之后，意犹未尽，一直想更加深入了解一下携程在 RN 方面的技术探索。今天终于等到了携程的 RN 建设及他们设计的 CRN 的分享。这篇文章主要讲了下面几个事情：
+
+1. RN 在携程中的使用情况
+2. 携程基于 RN 优化的 CRN 框架的设计及使用
+3. CRN 做了哪些性能优化及实际效果比较
+4. 如何发布及运维
+
+比较可惜的是没有看到这套系统相比较于原生开发，对业务增长，开发效率有哪些优化，所以比较期待后续能有这方面的分享。
+
+最后，在文中提到将要开源的 CRN，也已经开源了，感兴趣的同学移步 [携程开源RN开发框架CRN](https://mp.weixin.qq.com/s/r6mB5Zq3jIf-K2YQi_AS8Q) 查看。
+
+### 🐎 [JSON as configuration files: please don’t ](https://arp242.net/weblog/json_as_configuration_files-_please_dont)
+
+[@olddonkey](https://github.com/olddonkey)：这是一篇 2016 年的老文章，但是其中的观点直到今天依然具有参考价值。
+
+很多公司，很多团队使用 JSON 文件作为 App 的配置文件，不论是从远程下发，还是本地加载。
+
+但是，在实际的项目中，用 JSON 来作为配置文件解决方案并不是个完美的方案，它存在的很多问题，这些问题会在实际中逐渐暴露。
+
+文章作者围绕这他心中的几个缺点展开论述：
+1. 注释容易缺失。
+2. 可读性差。
+3. 过分严格的格式。
+4. 缺乏可编程性。
+
+本文虽本意是针对 Web 开发提出观点，但是对 Mobile 开发也一样适用。
+
+## 工具
+
+> 开发过程中常用的工具，及一些新工具的介绍
+
+## 代码
+
+> 库，代码段，开源app
+
+## 书
+
+> 比较不错的书的推荐和书评
+
+## 音视频
+
+> 比较不错的书的推荐和书评
+
+## 内推
+
+老司机周报团队联合知识小集和 SwiftGG 翻译组收录了一份靠谱的内推职位。
+
+如果你想**找工作**，点这里：https://www.yuque.com/iosalliance/article/bhutav
+
+如果你想**招人**，点这里：https://www.yuque.com/iosalliance/article/ycyhf3
+
+当然，也欢迎你关注我们每一期的周报，我们会在每期周报底部及时更新编辑内推岗位。
+
+## 关注我们
+
+我们开通了公众号，每期发布时公众号（OldDriverWeekly）会推送消息，欢迎关注。
+
+![](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）