每周读点英文技术文章

[ShannonChenCHN]

为什么要读英文技术文章？

• 平时开发工作需要阅读外文文章、文档，所以有必要锻炼英文阅读能力
• 从文章内容本身的角度来看，很多高质量的内容都来自于外文，所以，这是一扇通往新世界的窗户
• 虽然有翻译的文章，但是，从源头去找内容，才不会失去原汁原味（当然，这也取决于你的当前情况，如果想要快速获取知识、信息，而你又不能很畅通地理解原文，那就最好是译文优先，结合原文阅读）
• 有输入才会有输出，如果你平时已经很习惯英语环境了，那么当需要跟老外交流时，你就不会觉得畏手畏脚了

[ShannonChenCHN]

• A History of Ruby inside iOS Development
• React Native: Bringing modern web techniques to mobile
• React Native: A year in review
• State of React Native 2018
• Dive into React Native performance
• Building Compassionate Software
• How to write a good software design doc
• The Best Career Advice From Dev Chats
• Advice for a Beginner Coder
• Automating iOS: How Pythonista Changed My Workflow

[ShannonChenCHN]

『React Native: Bringing modern web techniques to mobile』

React Native 是在 F8 2015 上推出的。

一切始于 React

• React 于 2013 年发布
• React 改变了传统的 web 前端开发方式，将应用拆成了各个独立的组件
• React 带来的好处：
  • 让开发者更专注于业务开发
  • 提升了迭代速度
  • 更易于扩展业务、扩大团队
• 在 Web 开发方面，基于 React 构建了很多优秀的产品和 js 库，比如 Relay。
• 但是除了 Web 之外的 native 开发，都有属于自己的独立的技术栈，这也就意味着开发一个产品，不得不分别为不同的平台专门开发

为什么 native 开发更困难

• native 开发不如 web 开发那么简单，移动原生开发带来的最大影响就是大大减低了开发速度
  • 拿 view 布局来说，原生开发中需要精确设置每个 view 的 frame，而 web 开发中借助 React 等框架来布局 view 要简单的多
  • web 开发时，只需要保存修改，刷新浏览器即可看到效果，而原生开发中，每次修改都需要重新编译
• 另外，在发布频率方面，web 网站可以一天发布两个版本，这样可以快速获得 AB 测试实验的反馈并进行调整，而原生开发，尤其是 iOS，每次发布需要提交 App Store审核，一般一次发布需要几周甚至超过 1 个月。
• 但是，native 是现在的主角。为什么？因为更好的用户体验、平台一致性

为什么 native 是必需的

• web 中达不到原生的用户体验（UI、交互、手势识别、性能）
• web 中不支持多线程、并发

鱼和熊掌可以兼得吗？

我们的理想目标是能够兼得原生平台的用户体验和使用 React 开发 web 的开发者体验。

目前为止的一些尝试：

• 使用 web view
  • 优点：可以充分发挥 web 开发的优势——现有的 React 生态基础，迭代速度快
  • 缺点：性能和用户体验不够好
• 移植 React 到原生中来
  • iOS 中的实现：ComponentKit
  • 优点：可以发挥 React 开发方式的优势，拥有声明式的、所见即所得的 UI 开发体验，使用 flexbox 布局更方便，同时还能具有原生开发本身的优势
  • 缺点：iOS only；不能应用现有的一些基于 React 开发的 web 基础设施；并没有从根本上提升开发速度，每次修改仍然需要重新编译
• 使用脚本调用原生 API
  • 优点：兼具 web 开发体验、迭代速度和原生的用户体验，能够利用现有的 JS 基础设施，而且还能跨平台
  • 缺点：并没有比较完美的实现

使用脚本调用原生时面临的挑战

• 现实问题：如果只是 JS 和原生之间的通信是同步执行的，最终会导致 UI 线程因为执行 JS 而被阻塞。

• 如何解决？-> 在后台线程执行 JS 代码，但是这样做实现起来会非常难，因为：

  • 第一，资源竞争，如果 JS 代码需要访问另一个线程的数据时，系统就需要给这个数据加锁，这样就会导致 UI 阻塞
  • 第二个原因是，JS 虚拟机和原生通信的效率问题。

• 目标

  • 从根本上改变编程模型
  • 跨线程异步“发送消息”
  • 尽可能逐帧地批量处理消息，将线程间通信的消耗最小化

• React 提供的编程模型
  

React Native 的诞生

• React 组件是纯粹的、无副作用的函数，随时都可以返回描述 view 的内容。所以我们不需要读取已经渲染好的 view 再进行修改。
• 在浏览器环境中，对于 DOM 来讲，React 是非阻塞的。但是 React 是抽象的、跟 DOM 解耦的，因此 React 可以封装任何命令式的 view 系统，比如 iOS 中的 UIKit。
• 与浏览器中的 React.js 唯一不同的是，在移动开发环境中，支撑 React 运转的是 JavaScriptCore，最后渲染成的是原生的 view。
• React Native 既可以在新项目中使用，也可以直接在现有应用中使用。

React Native 是行得通的

• 我们的目标是 “learn once, write anywhere.” 而不是 “write once, run anywhere”
  • 这是因为不同的平台

开源

[ShannonChenCHN]

『A History of Ruby inside iOS Development』

• Ruby 于 1993 正式发布，至今有 25 年的历史了
• Ruby 是被一个叫 Yukihiro “Matz” Matsumoto 的日本人发明的
• Ruby 的特点是动态、易学、“时髦”
• iOS 开发中的应用：包管理、自动发布、Xcode 项目管理

究竟是什么使得 Ruby 如此受欢迎呢？

• 很多其他语言的一些库、工具、最佳实践都是借鉴 Ruby 的
• Ruby 如此受欢迎的原因无非是：简洁、社区和生态。

iOS 开发中的 Ruby 工具

• nomad-cli

  • 一个打包工具，推测是因为作者 Matt 早期是 Ruby 资深开发者，所以选用了 Ruby 作为开发语言。

• CocoaPods

  • 一个依赖管理工具集，根据作者在 Twitter 上的评论，使用 Ruby 的开发原因主要有下面几点：
    • 借助 Bundler/RubyGems 很容易共享代码
    • 早期阶段借助 MacRuby 很方便读写 Xcode 工程文件
    • Ruby 很容易让使用者自己去实现自定义
    • 使用 Ruby 编写的 CLI 工具时处理大量字符串时很方便
    • OS X 系统自带了 Ruby 环境

• Fastlane

  • 打包构建工具，作者 Felix 自己也在 Twitter 上说了使用 Ruby 开发的原因：
    • mattt 的 nomad-cli 带来的启发
    • Felix 想直接复用 CocoaPods 中已经实现了的轮子

• Danger System

• xcpretty

• xcov

iOS 开发中可以没有 Ruby 吗

单纯从技术角度上来讲，完全可以。但是你要么自己去理解和使用苹果自家所提供的复杂、难用的工具，要么自己去实现一套 CocoaPods 和 Fastlane 的替代品，但是这样要求很高，你需要对脚本和苹果提供的技术非常了解，所以很费工夫，既浪费时间又浪费钱，而且现有的轮子已经帮你把坑都踩过了，你自己去实现的话还不一定足够完善。

就拿 CocoaPods 来说，目前 Carthage 和 Swift Project manager 可以做到替代 CocoaPods 依赖管理的一部分功能，但是依然还有很多缺陷。

结论

• Ruby 主要解决的问题是通过构建 CocoaPods 等工具来替代复杂的苹果开发者工具，让开发流程更方便、简单。
• 现在对于绝大多数 iOS 者来说， Ruby 已经成为了 iOS 开发工作流中不可或缺的一部分了，短时间内不离不开的。
• 每个 iOS 开发者都值得学习一下 Ruby 这门语言。

个人感受

上面所列的工具中，我使用过 CocoaPods，经常听说过 Fastlane，国内曾经见过饿了么物流团队使用 Ruby 编写了一些自动化工具。另外，7 月份听过一次美团的技术沙龙，他们就提到过自己修改了 CocoaPods 的依赖分析机制，要做到这点，想必也一定要对 Ruby 有所了解吧。

就我自己的经历来讲，没用过 Ruby（除了修改 Podfile 之外），倒是用 Python 写过一些工具。Anyway，Ruby 还是值得学习下的。