资讯专栏INFORMATION COLUMN

上云采购季！| 爆款云服务器低至4.6元/月，首单享0.9折

免费试用
首页/文章专栏/解读 React 的 pooledClass.js

解读 React 的 pooledClass.js

Chiclaim / 1654人阅读

摘要：对象池类的成员应该都是静态的。事实上，由于对象池技术将对象限制在一定的数量，也有效地减少了应用程序内存上的开销。对生成时开销不大的对象进行池化，反而可能会出现维护对象池的开销大于生成新对象的开销，从而使性能降低的情况。

前言

在学习 React 事件系统的时候，在事件分发的 dispatch方法发现了调用了一个 pooledClass 方法，一时半会没看明白这个方法的用意。

我们先看一下是怎么用的：

// step1
function TopLevelCallbackBookKeeping(topLevelType, nativeEvent) {
  this.topLevelType = topLevelType;
  this.nativeEvent = nativeEvent;
  this.ancestors = [];
}
Object.assign(TopLevelCallbackBookKeeping.prototype, {
  destructor: function() {
    this.topLevelType = null;
    this.nativeEvent = null;
    this.ancestors.length = 0;
  },
});
PooledClass.addPoolingTo(
  TopLevelCallbackBookKeeping,
  PooledClass.twoArgumentPooler
);

// step2
var bookKeeping = TopLevelCallbackBookKeeping.getPooled(
  topLevelType,
  nativeEvent
);
// bookKeeping 是 TopLevelCallbackBookKeeping 的实例
try {
  // Event queue being processed in the same cycle allows
  // `preventDefault`.
  ReactUpdates.batchedUpdates(handleTopLevelImpl, bookKeeping);
} finally {
  //释放
  TopLevelCallbackBookKeeping.release(bookKeeping);
}

那么这里为什么不直接 new 一个 TopLevelCallbackBookKeeping, 而要通过这个 PooledClass 来返回 TopLevelCallbackBookKeeping 的实例呢

对象池 
单例模式是限制了一个类只能有一个实例，对象池模式则是限制一个类实例的个数。对象池类就像是一个对象管理员，它以Static列表（也就是装对象的池子）的形式存存储某个实例数受限的类的实例，每一个实例还要加一个标记，标记该实例是否被占用。当类初始化的时候，这个对象池就被初始化了，实例就被创建出来。然后，用户可以向这个类索取实例，如果池中所有的实例都已经被占用了，那么抛出异常。用户用完以后，还要把实例“还”回来，即释放占用。对象池类的成员应该都是静态的。用户也不应该能访问池子里装着的对象的构造函数，以防用户绕开对象池创建实例。书上说这个模式会用在数据库连接的管理上。比如，每个用户的连接数是有限的，这样每个连接就是一个池子里的一个对象，“连接池”类就可以控制连接数了。
如果说每次触发 dispatch 的时候都用 new TopLevelCallbackBookKeeping 来 new 一个对象，那么当触发很多次 dispatch 的时候，就会导致生成多个对象无法销毁（多个bookKeeping的引用次数一直为1），导致内存溢出。
对象池技术的基本原理

对象池技术基本原理的核心有两点：缓存和共享，即对于那些被频繁使用的对象，在使用完后，不立即将它们释放，而是将它们缓存起来，以供后续的应用程序重复使用，从而减少创建对象和释放对象的次数，进而改善应用程序的性能。事实上，由于对象池技术将对象限制在一定的数量，也有效地减少了应用程序内存上的开销。

对象池使用的基本思路是

将用过的对象保存起来，等下一次需要这种对象的时候，再拿出来重复使用，从而在一定程度上减少频繁创建对象所造成的开销。React 的 pooledClass.js 就是一个例子：

var invariant = require("invariant");

/**
 * Static poolers. Several custom versions for each potential number of
 * arguments. A completely generic pooler is easy to implement, but would
 * require accessing the `arguments` object. In each of these, `this` refers to
 * the Class itself, not an instance. If any others are needed, simply add them
 * here, or in their own files.
 */
var oneArgumentPooler = function(copyFieldsFrom) {
  var Klass = this;
  if (Klass.instancePool.length) {
    var instance = Klass.instancePool.pop();
    Klass.call(instance, copyFieldsFrom);
    return instance;
  } else {
    return new Klass(copyFieldsFrom);
  }
};

...
var standardReleaser = function(instance) {
  var Klass = this;
  invariant(
    instance instanceof Klass,
    "Trying to release an instance into a pool of a different type."
  );
  instance.destructor();
  if (Klass.instancePool.length < Klass.poolSize) {
    Klass.instancePool.push(instance);
  }
};

var DEFAULT_POOL_SIZE = 10;
var DEFAULT_POOLER = oneArgumentPooler;

/**
 * Augments `CopyConstructor` to be a poolable class, augmenting only the class
 * itself (statically) not adding any prototypical fields. Any CopyConstructor
 * you give this may have a `poolSize` property, and will look for a
 * prototypical `destructor` on instances (optional).
 *
 * @param {Function} CopyConstructor Constructor that can be used to reset.
 * @param {Function} pooler Customizable pooler.
 */
var addPoolingTo = function(CopyConstructor, pooler) {
  var NewKlass = CopyConstructor;
  NewKlass.instancePool = [];
  NewKlass.getPooled = pooler || DEFAULT_POOLER;
  if (!NewKlass.poolSize) {
    NewKlass.poolSize = DEFAULT_POOL_SIZE;
  }
  NewKlass.release = standardReleaser;
  return NewKlass;
};

var PooledClass = {
  addPoolingTo: addPoolingTo,
  oneArgumentPooler: oneArgumentPooler,
  twoArgumentPooler: twoArgumentPooler,
  threeArgumentPooler: threeArgumentPooler,
  fourArgumentPooler: fourArgumentPooler,
  fiveArgumentPooler: fiveArgumentPooler,
};

module.exports = PooledClass;

具体分为三步

addPoolingTo 添加对象到池子

调用的时候发现是否有缓存，有缓存就pop()出来用， 没有缓存就新增一个

使用完成之后，释放对象，缓存进去

说的再简单一点就是

创建对象 addPoolingTo()

借取对象 getPooled()

归还对象 release()

总结

并非所有对象都适合拿来池化――因为维护对象池也要造成一定开销。对生成时开销不大的对象进行池化，反而可能会出现“维护对象池的开销”大于“生成新对象的开销”，从而使性能降低的情况。但是对于生成时开销可观的对象，池化技术就是提高性能的有效策略了。

GPU服务器 服务器托管 报告解读 解读 源码解读 解读3

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/97921.html

相关文章

  • 开发工具心得：如何 10 倍提高你的 Webpack 构建效率

    摘要：在项目架构中这两个东西基本成为了标配，但的模块必须在使用前经过的构建后文称为才能在浏览器端使用，而每次修改也都需要重新构建后文称为才能生效，如何提高的构建效率成为了提高开发效率的关键之一。 0. 前言 showImg(https://segmentfault.com/img/remote/1460000005770045); 图1：ES6 + Webpack + React + Bab...

    用户83 评论0 收藏0

  • React 源码深度解读（四）：首次自定义组件渲染 - Part 1

    摘要：本篇开始介绍自定义组件是如何渲染的。组件将自定义组件命名为，结构如下经过编译后，生成如下代码构建顶层包装组件跟普通元素渲染一样，第一步先会执行创建为的。调用顺序已在代码中注释。先看图，这部分内容将在下回分解 前言 React 是一个十分庞大的库，由于要同时考虑 ReactDom 和 ReactNative ，还有服务器渲染等，导致其代码抽象化程度很高，嵌套层级非常深，阅读其源码是一个非...

    Warren 评论0 收藏0

  • React 源码深度解读（三）：首次 DOM 元素渲染 - Part 3

    摘要：在学习源码的过程中，给我帮助最大的就是这个系列文章，于是决定基于这个系列文章谈一下自己的理解。到此为止，首次渲染就完成啦总结从启动到元素渲染到页面，并不像看起来这么简单，中间经历了复杂的层级调用。 前言 React 是一个十分庞大的库，由于要同时考虑 ReactDom 和 ReactNative ，还有服务器渲染等，导致其代码抽象化程度很高，嵌套层级非常深，阅读其源码是一个非常艰辛的过...

    U2FsdGVkX1x 评论0 收藏0

  • React 源码深度解读（六）：依赖注入

    摘要：依赖注入和控制反转，这两个词经常一起出现。一句话表述他们之间的关系依赖注入是控制反转的一种实现方式。而两者有大量的代码都是可以共享的，这就是依赖注入的使用场景了。下一步就是创建具体的依赖内容，然后注入到需要的地方这里的等于这个对象。 前言 React 是一个十分庞大的库，由于要同时考虑 ReactDom 和 ReactNative ，还有服务器渲染等，导致其代码抽象化程度很高，嵌套层级...

    glumes 评论0 收藏0

  • React 源码深度解读（一）：首次DOM元素渲染 - Part 1

    摘要：调用栈是这样的这里生成的我们将其命名为，它将作为参数传入到。整个的调用栈是这样的组件间的层级结构是这样的到此为止，顶层对象已经构造完毕，下一步就是调用来自的方法，进行页面的渲染了。通过表达的结构最终会转化为一个纯对象，用于下一步的渲染。 欢迎关注我的公众号睿Talk，获取我最新的文章：showImg(https://segmentfault.com/img/bVbmYjo); 一、前言...

    daydream 评论0 收藏0

发表评论

登陆后可评论

0条评论

Chiclaim

男|高级讲师
我要私信

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<