01-整体生态概况

2019-02-18 本文已影响1人砌墙的民工

技术栈概览

RN技术栈

JavaScript & TypeScript

目前前端技术栈主要都使用 JavaScript 开发。JavaScript 是一种动态语言，对于长期使用 Java 或者 Objective-C 作为工作语言的同学来说，快速上手 JavaScript 其实是一件略有难度的事情。在开始接入 React-Native 的时候，我们就考虑了端的团队去采用一个不熟悉的而且很灵活的语言去开发业务，如何降低学习成本以及保障代码质量。

我们的选择是 TypeScript.

TypeScript 是 JavaScript 的超集, 而且直接混用也没有关系。最新版的 React-Native 脚手架工具也支持直接创建 TypeScript 模板的工程。

TypeScript 支持静态类型, 类、接口、枚举等等概念和 Java 也都很像，套用面向对象的思想去理解是很方便的。因为支持静态类型检测，所以在 IDE 中的代码提示也非常方便。如果 Android 的同学了解 Kotlin 的话，上手难度就更低了。

TypeScript 因为是 JavaScript 的超集，在编译之后还是转成了 JavaScript。这里列出几处 JavaScript 特有的语法特性，能够帮助快速理解。

解构赋值

let o = {p: 42, q: true};
let {p, q} = o;
 
console.log(p); // 42
console.log(q); // true

扩展运算符

let state = {
    name: "yangxlei",
};
  
let newState = {
    ...state,
    age: 28
};

箭头函数

(参数1, 参数2, …, 参数N) => { 函数声明 }
(参数1, 参数2, …, 参数N) => 表达式（单一）
//相当于：(参数1, 参数2, …, 参数N) =>{ return 表达式; }

// 当只有一个参数时，圆括号是可选的：
(单一参数) => {函数声明}
单一参数 => {函数声明}

// 没有参数的函数应该写成一对圆括号。
() => {函数声明}

Bind

分析以下三种写法有什么区别？

class Demo extends React.Component {
    color: 'red';
    onHandleClick = (event) => {
        console.log(`color is ${this.color}`);
    }
  
    render() {
        return (
            <View>
                <Button title="test1" onPress={this.onHandleClick}/>
                <Button title="test2" onPress={this.onHandleClick.bind(this)}/>
                <Button title="test3" onPress={event => this.onHandleClick(event)}/>
            </View>
        );
    }
}

开发环境

主要是几点：

包管理器 NPM & Yarn。这两个工具主要作用都是一致的，都能达到你的目的。但是在 Yarn 做了很多优化，速度更快。依赖处理的策略也不一样，在这个地方踩过一个坑，更推荐使用 Yarn。
IDE 推荐 VSCode。神器，不解释。
VSCode 有丰富的插件可以使用，集成 React-native-dev-tools 可以方便实现 debug 等操作。

React & React-Native

React 是一套 JavaScript 的组件化框架，它本身是平台无关性的。在运行时，会根据 Component 的组织关系，生成一个 V-Dom 树。可以理解 v-dom 就是一个动态的配置，例如，配置里面描述了一个 View 组件，它的背景色是 #fff, width 100, height 200. 内部有一个 Text， Text 的 title 是 "Hello World", 等等。

这个配置会根据你的数据或者状态的变化而自动更新。然后将这个配置交给所在的平台, 如 react-dom、react-native、react-ar 去渲染。

所以 React 是 Learn Once, Write Anywhere。而不是 Learn Once, Run Anywhere。

Flexible

react-native 统一了 iOS 和 Android 平台，跨端的一个重要前提是布局怎么做到一致性。

iOS 和 Android 在布局处理上有巨大差异。其实布局说白了就是通过一个计算规则，把一个控件放到屏幕上的某个位置上。iOS 早期屏幕单一，只需要直接指定位置就可以了，后来屏幕尺寸多了，开始使用相对布局，动态计算；Android 由于为了更好的适配丰富的屏幕尺寸，提供了各种各样的布局规则：Linear/Relative/Frame/Constraint 等。

所以统一布局的方式就是采用统一的布局规则的问题。Flex 布局在前端领域已经是成熟的方案，facebook 将它搬移过来，并实现了 yoga 引擎来负责 Flex 的解析。目前业界的各种跨端方案基本都采用 yoga 作为底层布局引擎。

开发框架

如果你的业务比较复杂，考虑到扩展性和可维护性，需要设计好一套开发框架。这是业务开发的基础设施。
这个框架核心需要解决两个问题：

模块的组织方式
数据的组织方式

在 react-native 生态范围内，第一个问题主要采用 react-navigation 方案，第二个问题主要采用比较火的 redux。

构建

facebook 针对 react-native 的构建单独实现了一套 Metro 工具。react-native bundle 命令的具体实现都在 Metro 内部。

由于 react-native 框架本身的问题，构建出来的包巨大。基础框架部分就有 800k+左右，包大小的问题会直接影响到加载速度。所以为了提升体验，拆包成了绕不过去的问题。而 Metro 并没有直接提供拆包的功能，只能自己想办法实现，后面的章节会详细讲解具体的实现方案。

构建之后的上线，微软提供了 CodePush 方案。但是一个重要的问题， CodePush 的 Server 部分并没有开放，只部署在了微软自己的服务器上。小团队可以直接使用，大公司不可能把代码托管在第三方公司的。Github 上有人基于 CodePush 的机制开源了一个 CodePush Server，也是一种解决方案。其实简单一点，自己搞个服务器托管 bundle，端上去拉取下来，能完成整个流程基本就可以了。

性能优化

我们在实践过程中，整体的性能表现是比一开始预期要高的，并没有如一开始网上一些资料所描述的那么严重。但是在一些核心问题上，还是遇到了一些性能瓶颈，这些问题有些解决了，有些还需要投入资源继续解决。例如：

模块加载耗时。解决方案：拆包 + 预加载
FlatList 长列表。解决方案：第三方 JS 列表方案，自行实现 NativeList。

原理

了解一些底层实现原理，可以帮助我们更好的理解上层逻辑。后面的章节会针对几个主要场景，分享一下底层的具体实现过程。