React Native性能优化红宝书

发布于:2024-06-21 ⋅ 阅读:(74) ⋅ 点赞:(0)

一、React Native介绍

React Native 是Facebook在React.js Conf2015 推出的开源框架,使用React和应用平台的原生功能来构建 Android 和 iOS 应用。通过 React Native,可以使用 JavaScript 来访问移动平台的 API,使用 React 组件来描述 UI 的外观和行为。

JS实现调用的能力中间的适配层提供了一些桥接方案

1、RN优势

1.1 HTML/CSS/JS开发成本低,用统一的代码规范开发移动端程序,不用关注移动端差异

1.2 天然跨平台,开发一次,可以生成Android和ios两个系统上的APP,这减少了开发人员需要编写不同版本的应用程序的时间和工作量。

1.3 无审核热更新

1.4 可扩展

1.5 易学易用:React Native 基于 React,开发人员可以使用熟悉的 JavaScript 和 React 组件模型来构建应用程序,因此很容易学习和上手。

RN的本质是把中间的这个桥Bridge给搭好,让JS和native可以互相调用。

RN为我们提供了JS的运行环境,所以前端开发者们只需要关心如何编写JS代码,

画UI只需要画到virtual DOM 中,不需要特别关心具体的平台。

至于如何把JS代码转成native代码的脏活累活,RN底层全干了

2、RN劣势

2.1 不成熟,项目版本更新维护较频繁,学习成本高,试错成本高,有些问题较少解决方案,开发进度慢

2.2 性能:整体性能仍不如原生

2.3 兼容性:涉及底层的功能,需要针对Android和ios双端单独开发

2.4 有限的第三方库:尽管 React Native 社区不断增长,但相对于其他混合应用框架,第三方库和插件的数量还是有限的。这可能使开发人员在某些方面受到限制。

2.5 有些原生功能需要自己实现:虽然 React Native 提供了大量原生组件,但某些原生功能需要开发人员自己实现,这可能需要额外的时间和工作量。

3、跨平台框架比较

开发模式 

原生开发 

混合开发 

Web开发 

运行环境

Android、iOS、Windows

混合App、

React Native,Weex、Flutter

浏览器、WebView

编程语言

Java,Objective-C

JavaScript、Dart

HTML、CSS、JavaScript

可移植性

一般

开发速度

一般

性能

一般

学习成本

一般

4、Hybrid App 优势

4.1  跨平台开发

4.2  离线访问

4.3  原生应用程序的用户体验

4.4  快速开发和迭代

混合应用程序结合了Web应用程序和本地应用程序的优点,既能够在原生应用程序环境中运行,也能够在 Web 浏览器中运行,并且具有更好的用户体验和功能。这种开发方式可以大大减少开发时间和成本,提高开发效率。

5、React Native 0.68之前的架构

5.1、整体UI渲染太过于依赖JsBridge,容易出现阻塞影响整体UI体验

5.2、性能和问题反馈最大的组件:

        ScrollView:一次渲染不做任何回收,启动性能慢,占用内存大

        FlatList:做了组件回收,快速滑动中容易出现白屏和卡顿

        Shadow层最终呈现到原生的UI是异步的,滑动太快会有大量的UI

5.3、事件阻塞在JsBridge,导致了长时间白屏的出现

6、RN中的视图渲染

javascript:JS代码的执行线程,将源码通过Metro打包后传给JS引擎进行解析:

        结构 样式 属性

  1. Main线程(UI线程或原生线程):主要负责原生渲染(Native UI)和调用原生模块(Native Modules 
  2.  Shadow 线程Layout线程:创建Shadow Tree来模拟Reac结构树(类似虚拟DOM),再由Yoga引擎将Flexbox等样式,解析成平台的布局方式:

                宽高  位置

7、RN架构设计--新旧架构对比

7.1、JavaScript层: 

支持React 16+新特性

增强JS静态类型检查(CodeGen)

引入JSI允许替换不同的JavaScript引擎

 7.2、Bridge层:

划分了Fabric和TurboModules,分别负责管理UI和Native模块

 7.3、Native层:

精简核心模块,将非核心部分拆除去,作为社区模块,独立维护

8、从 0.68 版本开始React Native 的新架构

8.1、JSI (JavaScript Interface) 

        一个用 C++ 写成的轻量级框架

        实现JS引擎的互换

        通过JS直接调用Native

        减少不必要的线程通信,省去序列化和反序列化的成本,

        减轻了通信压力,提高了通信性能

8.2、CodeGen

        FaceBook推出的代码生成工具

        加入了类型约束后,减少了数据类型错误

        自动将 Flow 或 TS 有静态类型检查的 JS 代码转换为 Fabric 和 TurboModules 使用的原生代码

8.3、优化Bridge层

        Fabric是整个框架中的新UI层,简化了之前的渲染

        Turbo Modules通过JSI可以让JS直接调用Native模块,实现同步操作,实现Native模块按需加载,减少启动时间,提高性能

8.4、精简核心代码(LEAN Core)

        将React Native核心包进行瘦身,非必要包移到社区单独维护

9、React介绍

Facebook,Learn Once,write anywhere

数据驱动,状态决定界面的变化,虚拟dom(抽象层)

虚拟dom的好处,首先是性能的优化,不直接操作Dom先进行一些比较,计算找出需要变化的部分,在实际的dom中进行操作

        其次,这个抽象层,还提供了逻辑代码跨平台移植的可能性

虚拟dom的下方对接的,是网页,是移动端,是电视端,任何一个可以渲染的端,都可以做接口的适配,使得代码在任何地方使用

主要四个部分:

组件:类组件、函数式组件

属性Props

状态State

jsx:React 和 React Native 都使用JSX 语法,这种语法使得你可以在 JavaScript 中直接输出本质上也就是 JavaScript,所以你可以在其中直接使用变量元素,JSX 

hook api: todo补充

生命周期: todo补充

二、性能优化点

1、RN加载的主要时间消耗

todo:补充

2、RN性能优化-拆包、分包

React Native 页面的 JavaScript 代码包是热更新平台根据版本号进行下发的,每次有业务改动,我们都需要通过网络请求更新代码包。

因此,我们在对JavaScript 代码进行打包的时候,需要将包拆分成两个部分:

2.1、Common 部分,也就是 React Native 源码部分;

2.2、业务代码部分,也就是我们需要动态下载的部分

具体操作:

  • JavaScript 代码包中 React Native 源码相关的部分是不会发生变化的,所以我们不需要在每次业务包更新的时候都进行下发,在工程中内置一份就好了。
  • Common 包内置到工程中
  • 业务代码包进行动态下载
  • 利用 JSContext 环境,在进入载体页后在环境中先加载 Common 包,再加载业务代码包就可以完整的渲染出 React Native 页面

todo:代码示例?

3、首屏渲染

通过拆包的方案,已经减少了动态下载的业务代码包的大小。但是还会存在部分业务非常庞大,拆包后业务代码包的大小依然很大的情况,依然会导致下载速度较慢,并且还会受网络情况的影响。

因此,我们可以再次针对业务代码包进行拆分

将一个业务代码包拆分为一个主包和多个子包的方式

在进入页面后优先请求主包的 JavaScript 代码资源,能够快速地渲染首屏页面,

紧接着用户点击某一个模块时,再继续下载对应模块的代码包并进行渲染,就能再进一步减少加载时间。

4、减少渲染的节点-通过组件懒加载提高应用性能

组件懒加载可以让 react 应用在真正需要展示这个组件的时候再去展示,有效的减少渲染的节点数,提高页面的加载速度

React 官方在 16.6 版本后引入了新的特性:React.lazy 和 React.Suspense,这两个组件的配合使用可以比较方便进行组件懒加载的实现

React.lazy 该方法主要的作用就是可以定义一个动态加载的组件,这可以直接缩减打包后 bundle 的体积,

并且可以延迟加载在初次渲染时不需要渲染的组件

 Suspense组件中的 fallback 属性接受任何在组件加载过程中你想展示的 React 元素。

你可以将 Suspense 组件置于懒加载组件之上的任何位置,你甚至可以用一个 Suspense 组件包裹多个懒加载组件。 代码示例如下:

import React, {Suspense} from 'react';
const OtherComponent = React.lazy(() => import('./OtherComponent));
const AnotherComponent = React.lazy(() => import('./AnotherComponent));
function MyComponent() {
    return(
        <div>
            <Suspense fallback={<div> loading...</div>}>
                <section>
                    <OtherComponent/>
                    <AnotherComponent/>
                </section>
            </Suspense>
        </div>
    )
}

使用懒加载可以减少bundle文件大小,

不同的文件打包到不同的页面组件当中,加快组件的呈现

import React, {lazy, Suspense} from 'react';
const OtherComponentLazy = lazy(() => import('./OtherComponent));
const AnotherComponentLazy = lazy(() => import('./AnotherComponent));
function Suspensed(lazyComponent) {
    return (props) {
        <Suspense fallback={<div></div>}>
            <lazyComponent {...props} />
        </Suspense>
    }
}
export const OtherComponent = Suspensed(OtherComponentLazy)
export const AnotherComponent = Suspensed(AnotherComponentLazy)

5、提交阶段优化-避免重复无限渲染

当应用程序状态发生更改时,React会调用render方法。

如果在render方法中继续更改应用程序状态,就会发生render方法递归调用,导致应用报错。

Render方法应该作为纯函数,render方法的执行要根据状态的改变,保持组件的行为和渲染方法一致。

执行提交阶段钩子,会阻塞浏览器更新页面。

如果在提交阶段钩子函数中更新组件 State,会再次触发组件的更新流程,造成两倍耗时。

一般在提交阶段的钩子中更新组件状态的场景有:

  • 类组件应使用 getDerivedStateFromProps 钩子方法代替,函数组件应使用函数调用时执行 setState的方式代替。
  • 使用上面两种方式后,React 会将新状态和派生状态在一次更新内完成。
  • 根据 DOM 信息,修改组件状态。在该场景中,除非想办法不依赖 DOM 信息,否则两次更新过程是少不了的,就只能用其他优化技巧了。

6、组件卸载前执行清理操作

React 组件性能优化的核心是减少渲染真实DOM节点的频率,减少Virtual DOM 比对的频率

在组件中为window注册的全局事件,以及定时器,在组件卸载前要清理掉,防止组件卸载后继续执行影响应用性能

import React,{
  Component
} from 'react';
 
export default class Hello extends Component {
  componentDidMount() {
    this.timer = setTimeout(
      () => { console.log('把一个定时器的引用挂在this上'); },
      500
    );
  }
  componentWillUnmount() {
    // 如果存在this.timer,则使用clearTimeout清空。
    // 如果你使用多个timer,那么用多个变量,或者用个数组来保存引用,然后逐个clear
    this.timer && clearTimeout(this.timer);
  }
};

7、通过使用占位符标记提升React组件的渲染性能

使用Fragment不对应具体的视图,减少了包含的额外标记的数量

仅仅是代表可以包装而已,跟空的标识符一样,视图层级关系减少有利于视图渲染,

满足在组件顶级具有单个父级的条件

<div>
...
</div> 
// 上面会多出一个无意义标记
// 应该改为 
<fragment>
...
</fragment>
// 或者写成下面这样也是可以的
<>
...
</>

8、缩小状态影响范围-状态下放到使用组件的内部

React不直接操作DOM,它在内存中维护一个快速响应的DOM描述,render方法返回一个DOM的描述

React能够计算出两个DOM描述的差异,然后更新浏览器中的DOM,这就是著名的DOM Diff。

就是说React在接收到属性(props)或者状态(state)更新时,就会通过前面的方式更新UI。所以React整个UI渲染是比较快的。但是这里面可能出现的问题是:

假设我们定义一个父组件,其包含了5000个子组件。我们有一个输入框输入操作,每次输入一个数字,对应的那个子组件背景色变红。

父组件更新默认触发所有子组件更新,子组件的props为空对象,{} === {} 永远会返回false

优化思想:将变的和不变的分开(state,props,context)

我们需要先手动创建一个有严重渲染性能的组件,如下所示:

import { useState } from 'react';

export default function App() {
  let [color, setColor] = useState('red');
  return (
    <div>
      <input value={color} onChange={(e) => setColor(e.target.value)} />
      <p style={{ color }}>Hello, world!</p>
      <ExpensiveTree />
    </div>
  );
}

function ExpensiveTree() {
  let now = performance.now();
  while (performance.now() - now < 100) {
    // Artificial delay -- do nothing for 100ms
  }
  return <p>I am a very slow component tree.</p>;
}

很显然,当 App 组件内的状态发生了改变,ExpensiveTree 组件会 re-render, 事实上 ExpensiveTree 组件的 props、state 并未发生改变,这并不是我们期望的结果。

export default function App() {
  let [color, setColor] = useState('red');
  return (
    <div>
      <input value={color} onChange={(e) => setColor(e.target.value)} />
      <p style={{ color }}>Hello, world!</p>
      <ExpensiveTree />
    </div>
  );
}

我们可以看到以上 ExpensiveTree 组件并不依赖 App 组件内部的状态,因此我们是否可以考虑,将依赖 color 的元素抽离到一个依赖 color 的组件中呢?

export default function App() {
  return (
    <>
      <Form />
      <ExpensiveTree />
    </>
  );
}

function Form() {
  let [color, setColor] = useState('red');
  return (
    <>
      <input value={color} onChange={(e) => setColor(e.target.value)} />
      <p style={{ color }}>Hello, world!</p>
    </>
  );
}

此时,将依赖 color 的元素提取到了 Form 组件中,Form 组件内部的状态不再影响 ExpensiveTree 组件的渲染,问题便得到了解决。

9、跳过不必要的组件更新-通过纯组件提升性能

  • 类组件中使用PureComponent
  • 函数式组件中使用React.memo

在 React 工作流中,如果只有父组件发生状态更新,即使父组件传给子组件的所有 Props 都没有修改,也会引起子组件的 Render 过程。

如果子组件的 Props 和 State 都没有改变,那么其生成的 DOM 结构和副作用也不应该发生改变。

纯组件会对组件输入数据进行浅层比较,如果当前输入数据和上次输入数据相同,组件不会重新渲染。

比较引用数据类型在内存中的引用地址是否相同,比较基本数据类型的值是否相同

为什么不直接进行diff操作?而要先进行浅比较?

浅比较只操作当前组件的state和props,diff操作会重新遍历整个VirtualDOM树

10、跳过不必要的组件更新-通过shouldComponentUpdate

纯函数只能进行浅层比较,要进行深层比较,

使用shouldComponentUpdate,它用于编写自定义比较逻辑

ShouldComponentUpdate(nextProps,nextState){
        if(nextProps……){

           return true

        }
        return false
}

11、跳过不必要的组件更新-通过memo纯组件提升性能

Memo基本使用:将函数组件变为纯组件,当前props和上一次的props进行浅比较,如果相同就阻止组件重新渲染

Memo函数是浅层数据比较,如果遇到引用数据类型,需要传递自定义比较逻辑,传给Memo函数的第二个参数

memo的第二个参数示例如下:

// 给memo传递第二个参数,自定义比较逻辑
import React, { memo, useEffect, useState } from 'react'
function App () {
  const [person, setPerson] = useState({ name: '张三', age: 20, job: 'waiter' })
  const [index, setIndex] = useState(0)
  useEffect(() => {
    let timer = setInterval(() => {
      setIndex(prev => prev + 1)
      setPerson({ ...person, job: 'chef' })
    }, 1000)
    return () => {
      clearInterval(timer)
    }
  }, [index, person])
  return (
    <div>
      {index}
      <ShowName person={person} />
    </div>
  )
}
function compare (prevProps, nextProps) {
  if (
    prevProps.person.name !== nextProps.person.name ||
    prevProps.person.age !== nextProps.person.age
  ) {
    return false
  }
  return true
}
const ShowName = memo(function ({ person }) {
  console.log('render...')
  return (
    <div>
      {person.name} {person.age}
    </div>
  )
}, compare)
export default App

12、跳过不必要的组件更新- useMemo、useCallback缓存优化

useMemo、useCallback 实现稳定的 Props 值

useMemo 缓存上次计算的结果,当 useMemo 的依赖未发生改变时,就不会触发重新计算,一般用在非常耗时的场景中,

如:遍历大列表做统计信息。

useCallback ,将父组件传递给子组件时,子组件会因为重新render发生改变的时候,缓存一个值

useCallback 是 React 的一个 Hook,它用于记住函数的引用,避免在每次渲染时都创建一个新的函数实例。这可以帮助优化性能,因为避免不必要的重渲染和子组件的重新渲染。

使用场景:

当你有一个函数,它依赖于某些 props 或 state,但你不希望它在这些依赖发生变化时重新创建,你可以使用 useCallback 来保持引用不变。

如果你有一个子组件,它是纯的(不依赖外部状态,只依赖于传入的 props),并且你希望避免非必要的重渲染,你可以使用 useCallback 来保证传递给子组件的函数引用保持不变。

例子代码:

import React, { useCallback } from 'react';
function ParentComponent() {
    const [count, setCount] = useState(0);
    // 使用 useCallback 来避免在每次渲染时都创建一个新的函数实例
    const incrementCount = useCallback(() => {
     setCount(count + 1);
}, [count]);
return (
 <div>
      <p>Count: {count}</p >
      <button onClick={incrementCount}>Increment</button>
         ChildComponent onIncrement={incrementCount} />
 </div>
);
}
function ChildComponent({ onIncrement }) {
// 这里我们不需要每次 ParentComponent 渲染时都创建一个新的函数实例
// 因为 onIncrement 引用没有变化
        return <button onClick={onIncrement}>Increment from Child</button>;
}

在这个例子中,incrementCount 是一个函数,用于增加计数。我们使用 useCallback 来保证在 ParentComponent 的多次渲染中,incrementCount 函数的引用是不变的,这样 ChildComponent 就不会因为 ParentComponent 的渲染而不必要地重新渲染。

13、列表使用Key属性

遍历展示视图时使用 key,key 帮助 React 识别哪些元素改变了,比如被添加或删除。因此你应当给数组中的每一个元素赋予一个确定的标识

const numbers = [1, 2, 3, 4, 5];
const listItems = numbers.map((number) =>
<li key={number.toString()}> {number} </li>);

使用 key 注意事项:

这个元素在列表中拥有的一个独一无二的字符串。通常,我们使用数据中的 id 来作为元素的 key

14、不要使用内联函数定义:

如果使用内联函数,函数是引用数据类型,在内存中的地址不会相同,则每次render函数时,都会创建一个新的函数实例

在渲染阶段会绑定新函数并将旧实例扔给垃圾回收,因此绑定内联函数,需要额外的垃圾回收和绑定到DOM的工作

1.Render(){
        Return (<input type=“button” onClick={(e)=>{this.setState({inputVal:e.target.value})}}>)
}

2.setNewState=(e)->{this.setState({inputVal:e.target.value})}
//箭头函数被添加到类的实例对象属性而不是原型对象属性,如果组件被多次重用,每个实例都会有一个相同的函数实例,降低了函数实例的可重用性,造成了资源的浪费
Render(){
        Return (<input type=“button” onClick={(e)=>{this.setNewState}/> )
}

3.Export default class a extends React.Component{
    constructor(){
        this.handleClick = this.handClick.bind(this)//构造函数只执行一次
    }
}
handleClick(){xxxxx}
<input type=“button” onClick={this.handleClick}/>
//render方法每次执行时都会调用bind方法生成新的函数实例
<input type=“button” onClick={this.handleClick.bind(this)}/>

15、避免使用内联样式

使用内联样式时,会被编译为JavaScript代码,JavaScript将样式规则映射到元素上,浏览器需要花费更多时间处理脚本和渲染UI。

它是在执行时为元素添加样式,而不是在编译时为元素添加样式。

因此,性能非常的低,更好的办法是将CSS文件导入组件。能通过css直接做的事情,就不要通过JavaScript去做,因为JavaScript操作DOM非常慢

16、事件节流和防抖

利用debounce、throttle 避免重复回调

节流:

意味着不会立即执行,在触发事件之前会加上几毫秒延迟,

throttle 更适合需要实时响应用户的场景中更适合,

如通过拖拽调整尺寸或通过拖拽进行放大缩小(如:window 的 resize 事件)。实时响应用户操作场景中,如果回调耗时小,

甚至可以用 requestAnimationFrame 代替 throttle。

页面滚动到底部的时候,使用节流,否则触发多个网络请求调用,导致性能问题

防抖:

在输入框中键入数据,直到用户不再输入数据为止,兼容网络调用提升性能

在搜索场景中,只需响应用户最后一次输入,无需响应用户的中间输入值,

debounce 更适合使用在该场景中。