前言

现在工作中基本离不开requireJS这种模块管理工具了，之前一直在用，但是对其原理不甚熟悉，整两天我们来试着学习其源码，而后在探寻其背后的AMD思想吧

于是今天的目标是熟悉requireJS整体框架结构，顺便看看之前的简单demo

程序入口

源码阅读仍然有一定门槛，通看的做法不适合我等素质的选手，所以还是得由入口开始，requireJS的入口便是引入时候指定的data-main

<script src="require.js" type="text/javascript" data-main="main.js"></script>

在js引入后，会自动执行指向data-main的js函数，这个就是我们所谓的入口，跟着这条线，我们就进入了requirejs的大门

首先，引入js文件本身不会干什么事情，那么requirejs内部做了什么呢？

① 除了一些初始化操作以为第一件干的事情，值执行这段代码：

//Create default context.
req({});

这段代码会构造默认的参数，其调用的又是整个程序的入口

req = requirejs = function (deps, callback, errback, optional) {}

这里具体干了什么我们先不予关注，继续往后面走，因为貌似，这里与data-main暂时不相干，因为这段会先于data-main逻辑运行

然后，进入data-main相关的逻辑了：

//Look for a data-main script attribute, which could also adjust the baseUrl.
if (isBrowser && !cfg.skipDataMain) {
  //Figure out baseUrl. Get it from the script tag with require.js in it.
  eachReverse(scripts(), function (script) {
    //Set the 'head' where we can append children by
    //using the script's parent.
    if (!head) {
      head = script.parentNode;
    }

    //Look for a data-main attribute to set main script for the page
    //to load. If it is there, the path to data main becomes the
    //baseUrl, if it is not already set.
    dataMain = script.getAttribute('data-main');
    if (dataMain) {
      //Preserve dataMain in case it is a path (i.e. contains '?')
      mainScript = dataMain;

      //Set final baseUrl if there is not already an explicit one.
      if (!cfg.baseUrl) {
        //Pull off the directory of data-main for use as the
        //baseUrl.
        src = mainScript.split('/');
        mainScript = src.pop();
        subPath = src.length ? src.join('/') + '/' : './';

        cfg.baseUrl = subPath;
      }

      //Strip off any trailing .js since mainScript is now
      //like a module name.
      mainScript = mainScript.replace(jsSuffixRegExp, '');

      //If mainScript is still a path, fall back to dataMain
      if (req.jsExtRegExp.test(mainScript)) {
        mainScript = dataMain;
      }

      //Put the data-main script in the files to load.
      cfg.deps = cfg.deps ? cfg.deps.concat(mainScript) : [mainScript];

      return true;
    }
  });
}

因为requireJS不止用于浏览器，所以这里有一个判断，我们暂时不予关注，看看他干了些什么

① 他会去除页面所有的script标签，然后倒叙遍历之

scripts() => [<script src="require.js" type="text/javascript" data-main="main.js"></script>]

这个地方遇到两个方法

eachReverse

与each一致，只不过由逆序遍历

 
  
 View Code 

scripts

便是document.getElementsByTagName('script');返回所有的script标签

然后开始的head便是html中的head标签，暂时不予理睬

 
  
 View Code 

dataMain = script.getAttribute('data-main');

然后这一句便可以获取当前指定运行的文件名，比如这里

dataMain => main.js

如果不存在就不会有什么操作了

PS：我原来记得默认指向main.js，看来是我记错了......

然后下来做了一些处理，会根据指定的main.js初步确定bashUrl，其实就是与main.js统一目录

最后做了关键的一个步骤：

cfg.deps = cfg.deps ? cfg.deps.concat(mainScript) : [mainScript];

将main放入带加载的配置中，而本身不干任何事情，继续接下来的逻辑......然后此逻辑暂时结束，根据这些参数进入下一步骤

req/requirejs

根据上一步骤的处理，会形成上面截图的参数，而后再一次执行入口函数req，这个时候就会发生不一样的事情了

/**
* Main entry point.
*
* If the only argument to require is a string, then the module that
* is represented by that string is fetched for the appropriate context.
*
* If the first argument is an array, then it will be treated as an array
* of dependency string names to fetch. An optional function callback can
* be specified to execute when all of those dependencies are available.
*
* Make a local req variable to help Caja compliance (it assumes things
* on a require that are not standardized), and to give a short
* name for minification/local scope use.
*/
req = requirejs = function (deps, callback, errback, optional) {

  //Find the right context, use default
  var context, config,
          contextName = defContextName;

  // Determine if have config object in the call.
  if (!isArray(deps) && typeof deps !== 'string') {
    // deps is a config object
    config = deps;
    if (isArray(callback)) {
      // Adjust args if there are dependencies
      deps = callback;
      callback = errback;
      errback = optional;
    } else {
      deps = [];
    }
  }

  if (config && config.context) {
    contextName = config.context;
  }

  context = getOwn(contexts, contextName);
  if (!context) {
    context = contexts[contextName] = req.s.newContext(contextName);
  }

  if (config) {
    context.configure(config);
  }

  return context.require(deps, callback, errback);
};

这个时候我们的第一个参数deps就不再是undefined了，而是一个对象，这里便将其配置放到了config变量中保持deps为一数组，然后干了些其他事情

这里有个变量context，需要特别注意，后面我们来看看他有些什么，这里有一个新的函数

function getOwn(obj, prop) {
  return hasProp(obj, prop) && obj[prop];
}
function hasProp(obj, prop) {
  return hasOwn.call(obj, prop);
}
hasOwn = op.hasOwnProperty

这里会获取非原型属性将其扩展，首次执行时候会碰到一个非常重要的函数newContext 因为他是一个核心，我们这里暂时选择忽略，不然整个全部就陷进去了

经过newContext处理后的context就变成这个样子了：

if (config) {
  context.configure(config);
}

这里就会将我们第一步的参数赋值进对象，具体干了什么，我们依旧不予理睬，main.js干了两件事情：

① 暂时性设置了baseUrl

② 告诉requireJS你马上要加载我了

于是最后终于调用require开始处理逻辑

return context.require(deps, callback, errback);

require

因为context.require = context.makeRequire();而该函数本身又返回localRequire函数，所以事实上这里是执行的localRequire函数，内部维护着一个闭包

因为nextContext只会运行一次，所以很多require实际用到的变量都是nextContext闭包所维护，比如我们这里便可以使用config变量

这里依旧有一些特殊处理，比如deps是字符串的情况，但是我们暂时不予关注.......

PS：搞了这么久很多不予关注了，欠了很多帐啊！

他这里应该是有一个BUG，所以这里用到了一个settimeout延时

PS：因为settimeout的使用，整个这块的程序全部会抛到主干逻辑之后了

然后接下来的步骤比较关键了，我们先抛开一切来理一理这个newContext

newContext

newContext占了源码的主要篇幅，他也只会在初始化时候执行一次，而后便不再执行了：

if (!context) {
  context = contexts[contextName] = req.s.newContext(contextName);
}

现在，我们就目前而知来简单理一理，requireJS的结构

① 变量声明，工具类

在newContext之前，完全是做一些变量的定义，或者做一些简单的操作，里面比较关键的是contexts/cfg对象，会被后面无数次的用到

② 实例化上下文/newContext

紧接着就是newContext这洋洋洒洒一千多行代码了，其中主要干了什么暂时不知道，据我观察应该是做环境相关的准备

③ 对外接口

上面操作结束后便提供了几个主要对外接口

requirejs

require.config

虽然这里是两个函数，其实都是requirejs这一关入口

而后，require自己撸了一把，实例化了默认的参数，这里便调用了newContext，所以以后都不会调用，其中的函数多处于其闭包环境

接下来根据引入script标签的data-main做了一次文章，初始化了简单的参数，并将main.js作为了依赖项，这里会根据main.js重写cfg对象

最后requirejs执行一次reg(cfg)，便真的开始了所有操作，这个时候我们就进入newContext，看看他主要干了什么

PS:所有require并未提供任何借口出来，所以在全局想查看其contexts或者cfg是不行的，而且每次操作都可能导致其改变

要了解newContext函数，还是需要进入其入口

if (!context) {
  context = contexts[contextName] = req.s.newContext(contextName);
}

从script标签引入require库时候，会因为这段代码执行一次newContext函数，从此后，该函数不会被执行，其实现的原因不是我等现在能明白的，先看懂实现再说吧

//Create default context.
req({});

所以上面说了那么多，看了这么久，其实最关键的还是首次加载，首次加载就决定了运行上下文了

整体结构

newContext的基本结构大概是这样：

① 函数作用域内变量定义（中间初始化了一发handlers变量）

② 一堆工具函数定义

③ Module模块（这块给人的感觉不明觉厉...应该是核心吧）

④ 实例化context对象，将该对象返回，然后基本结束

进入newContext后，第一步是基本变量定义，这种对外的框架一般都不会到处命名变量，而是将所有变量全部提到函数最前面

一来是js解析时候声明本身会提前，而来可能是到处命名变量会让我们找不到吧......

开始定义了很多变量，我们一来都不知道是干神马的，但是config变量却引起了我们的注意,这里先放出来，继续往下就是一连串的函数了，值得说明的是，这些变量会被重复利用哦

一眼看下来，该函数本身并没有做什么实际的事情，这个时候我们就需要找其入口，这里的入口是

//首次调用
req({}) 
=> 
//触发newContext，做首次初始化并返回给context对象
context = contexts[contextName] = req.s.newContext(contextName)
=>
//注意这里require函数其实处于了mackRequire函数的闭包环境
context.require = context.makeRequire();
=>
//首次调用newContext返回对象初始化变量
context.configure(config);

所以，在首次初始化后，并未做特别的处理，直到configure的调用，于是让我们进入该函数

 
  
 View Code 

首次传入的是空对象，所以开始一段代码暂时没有意义，这里使用的config变量正是newContext维护的闭包，也就是上面让注意的

config = {
  //Defaults. Do not set a default for map
  //config to speed up normalize(), which
  //will run faster if there is no default.
  waitSeconds: 7,
  baseUrl: './',
  paths: {},
  pkgs: {},
  shim: {},
  config: {}
},

下面用到了一个新的函数：

eachProp

这个函数会遍历对象所有非原型属性，并且使用第二个参数（函数）执行之，如果返回true便停止，首次执行时候cfg为空对象，便没有往下走，否则config变量会被操作，具体我们暂时不管

 
  
 View Code 

这个所谓的入口执行后实际的意义基本等于什么都没有干......

但是，这里可以得出一个弱弱的结论就是

configure是用于设置参数滴

所以所谓的入口其实没有干事情，这个时候第二个入口便出现了

context.require

return context.require(deps, callback, errback);

参数设置结束后便会执行context的require方法，这个是真正的入口，他实际调用顺序为：

context.require = context.makeRequire();
=>
localRequire

所以真正调用localRequire时候，已经执行了一番makeRequire函数了，现在处于了其上下文，正因为localRequire被处理过，其多了几个函数属性

除此之外，暂时没有看出其它变化，所以这里在某些特定场景是等价的

 
  
 View Code 

过程中会执行一次intakeDefines，他的意义是定义全局队列，其意义暂时不明，然后进入了前面说的那个settimeout

在主干逻辑结束后，这里会进入时钟队列的回调，其中的代码就比较关键了，只不过首次不能体现

context.nextTick(function () {
  //Some defines could have been added since the
  //require call, collect them.
  intakeDefines();

  requireMod = getModule(makeModuleMap(null, relMap));

  //Store if map config should be applied to this require
  //call for dependencies.
  requireMod.skipMap = options.skipMap;

  requireMod.init(deps, callback, errback, {
    enabled: true
  });

  checkLoaded();
});

这段代码事实上是比较奇特的，他会完全脱离整个require代码，比如整个

 return context.require(deps, callback, errback);

执行了后上面才会慢慢执行

PS：require这段比较重要，留待明天分析，今天先看整体逻辑

下面的主要逻辑又到了这里

requireMod = getModule(makeModuleMap(null, relMap));

我们这里主要先看getModule先，首先makeModuleMap比较关键，他会根据规则创建一些模块唯一标识的东西，暂时是什么当然是先不管啦......

PS：其规则应该与加载的require数量有关，最后会形成这个东西

 
  
 View Code 

然后是我们关键的getModule函数

function getModule(depMap) {
  var id = depMap.id,
            mod = getOwn(registry, id);

  if (!mod) {
    mod = registry[id] = new context.Module(depMap);
  }

  return mod;
}

可以看到，一旦我们加载了一个模块便不会重新加载了，这是一个很重要的发现哦

registry

该全局变量用于存储加载模块的键值对

第一步当然是加载啦，但是首次应该会跳过，因为当然事实上没有需要加载的模块，一起跟下去吧

Module

然后进入我们关键的Module类模块了

 
  
 View Code 

总的来说，这个模块还是很长的，首先是其构造函数

这里仍有很多东西读不懂，所以就全部过吧，反正今天的主要目的是熟悉整体框架

这里实例化结束后便形成了一个模块暂存于requireMod变量中，函数执行结束后变量会销毁，该模块会存与全局registery对象中

这里会执行其init方法干具体业务的事情

requireMod.init(deps, callback, errback, {
  enabled: true
});

这里又会执行

this.enable();

 
  
 View Code 

然后又会调用 this.check();这个家伙操作结束后接下来checkLoaded就会创建script标签了......

 
  
 View Code 

然后今天累了，明天继续吧......

结语

今天的目标是熟悉requireJS的整体结构，如果没有错觉或者解读失误，我们应该大概了解了requireJS的整体结构，于是让我们明天继续吧

PS：尼玛这个框架还真是有点难，小钗感觉有点小吃力啊，估计要读到下周才能真正理解一点的了.......

本文转自叶小钗博客园博客，原文链接：http://www.cnblogs.com/yexiaochai/p/3632580.html，如需转载请自行联系原作者

【requireJS源码学习01】了解整个requireJS的结构

前言

程序入口

eachReverse

scripts

req/requirejs

require

newContext

整体结构

eachProp

context.require

Module

结语

热门文章

最新文章

相关课程

相关电子书

相关实验场景

热门

活动广场

任务中心

开发者评测

高校计划

乘风者计划

训练营

阿里云MVP

话题

直播

下载

镜像站

技术资料

插件

【requireJS源码学习01】了解整个requireJS的结构

前言

程序入口

eachReverse

scripts

req/requirejs

require

newContext

整体结构

eachProp

context.require

Module

结语

热门文章

最新文章

相关课程

相关电子书

相关实验场景