近来喜欢看些闲书，于是在周末的临睡前和闲隙看完了这本书。刘同和郭敬明还有韩寒一样，都是用淡淡忧伤的文字触摸人们内心最柔软的轨迹。曾经知道他有一本《谁的青春不迷茫》，而且还配有极其文艺的插图，但是单看书名，总觉得是对于青春无奈的一种无病呻吟而已，多少会有一些消极的成分在，而我是最厌恶消极和负面的，所以一直不曾接触过这本书，而这一本，应该更多的是一种激励和共勉吧。事实证明，确实如此。

书的内容主要是涉及作者本人33岁之前的回忆，通过回忆来剖析和讲解各种孤单，有和父母之间的，上级之间的以及和同龄人之间不被理解的经历，除此之外，还有一些作者遇到的人或者事带给他的关于孤独的思考。孤独呢，有关于爱情，亲情，友情还有同事之情的，可以说，这本书可以称之为一本回忆录。而我最喜欢的就是他回忆毕业后大学同学聚会的场景。他以一种过来人的视角在品味人生，而我却是以一种正在经历的视角在寻找某些雷同。我从不曾想像过毕业10年的班级聚会会是怎样的一番场景，但是我知道时间会改变很多东西，譬如梦想，譬如友谊。很是被里面的一些独具一格的人所感动，包括小五，二毛，都是人群中特立独行的人，在他们的人生轨迹里，诠释着一种special。但是青春总是这样匆匆，还来不及回味就已经消失殆尽，只有年龄的不停增长在说明你已经走过了这段最为绚丽的日子。

“在人生的旅途中，回首张望需要勇气，直视而悠长，像是某种神圣的仪式”就像刘同在书中说的，有的时候，回忆需要很大的勇气，无论是那些别人给的伤还是美好，每回想一遍都会引发物是人非的惆怅，与其这样让自己心累，还不如永远没心没肺地一往直前，这样会更显示出一种潇洒。

不知道为什么，很难给孤单下一个定义，不能说独自一人就是孤单，但是之于我，孤单这个词太遥远，无论何时何地，我都有东西陪着，或者是电脑，或者是音乐，即使独自一人。很喜欢里面的一句话：

要相信这些年你都能一个人度过所有，当时你恐慌害怕的最终会成为你面对这个世界的盔甲“。

是的，或许你现在正在一个人奋斗着，没有与你并肩作战的人，但是这只是你现在能看到的风景，因为，孤独之前是迷茫，孤独之后就是成长，你用你最好的时光在犯错，那么以后犯的错就会变少，而年龄越大，犯错就越无法被原谅，因为每个人都要经历这些，只是时间早晚的问题。只有学会享受孤独的人才会建立起内心最为强大的精神堡垒，以至于被扔在人流中的时候，可以最早地被别人所看到。

"30 岁之后，风景于我只是几道走马观花得残影，少有流连忘返的停留”

我不知道，30岁的我会是什么样一番景象，但是我现在可以做到，等那个时候再来回忆这段时光的时候，我可以问心无愧地说：我尽力了。

你的孤独，虽败犹荣，为自己点个赞！！！

redux-saga 是一个管理 Redux 应用异步操作的中间件，功能类似redux-thunk + async/await, 它通过创建 Sagas 将所有的异步操作逻辑存放在一个地方进行集中处理。

redux-saga 的 effects

redux-saga中的 Effects 是一个纯文本 JavaScript 对象，包含一些将被 saga middleware 执行的指令。这些指令所执行的操作包括如下三种：

• 发起一个异步调用（如发一起一个 Ajax 请求）
• 发起其他的 action 从而更新 Store
• 调用其他的 Sagas

Effects 中包含的指令有很多，具体可以异步API 参考进行查阅

redux-saga 的特点

• 方便测试，例如:

assert.deepEqual(iterator.next().value, call(Api.fetch, '/products'))

• action 可以保持其纯净性,异步操作集中在 saga 中进行处理
• watch/worker（监听->执行） 的工作形式
• 被实现为 generator
• 对含有复杂异步逻辑的应用场景支持良好
• 更细粒度地实现异步逻辑，从而使流程更加清晰明了，遇到 bug 易于追踪和解决。
• 以同步的方式书写异步逻辑，更符合人的思维逻辑

从 redux-thunk 到 redux-saga

假如现在有一个场景：用户在登录的时候需要验证用户的 username 和 password 是否符合要求。

使用 redux-thunk 实现

获取用户数据的逻辑（user.js):

// user.js

import request from 'axios';

// define constants
// define initial state
// export default reducer

export const loadUserData = (uid) => async (dispatch) => {
    try {
        dispatch({ type: USERDATA_REQUEST });
        let { data } = await request.get(`/users/${uid}`);
        dispatch({ type: USERDATA_SUCCESS, data });
    } catch(error) {
        dispatch({ type: USERDATA_ERROR, error });
    }
}

验证登录的逻辑(login.js):

import request from 'axios';
import { loadUserData } from './user';

export const login = (user, pass) => async (dispatch) => {
    try {
        dispatch({ type: LOGIN_REQUEST });
        let { data } = await request.post('/login', { user, pass });
        await dispatch(loadUserData(data.uid));
        dispatch({ type: LOGIN_SUCCESS, data });
    } catch(error) {
        dispatch({ type: LOGIN_ERROR, error });
    }
}

redux-saga

异步逻辑可以全部写进 saga.js 中：

export function* loginSaga() {
  while(true) {
    const { user, pass } = yield take(LOGIN_REQUEST) //等待 Store 上指定的 action LOGIN_REQUEST
    try {
      let { data } = yield call(loginRequest, { user, pass }); //阻塞，请求后台数据
      yield fork(loadUserData, data.uid); //非阻塞执行loadUserData
      yield put({ type: LOGIN_SUCCESS, data }); //发起一个action，类似于dispatch
    } catch(error) {
      yield put({ type: LOGIN_ERROR, error });
    }  
  }
}

export function* loadUserData(uid) {
  try {
    yield put({ type: USERDATA_REQUEST });
    let { data } = yield call(userRequest, `/users/${uid}`);
    yield put({ type: USERDATA_SUCCESS, data });
  } catch(error) {
    yield put({ type: USERDATA_ERROR, error });
  }
}

难点解读

对于 redux-saga， 还是有很多比较难以理解和晦涩的地方，下面笔者针对自己觉得比较容易混淆的概念进行整理：

take 的使用

take 和 takeEvery 都是监听某个 action, 但是两者的作用却不一致，takeEvery 是每次 action 触发的时候都响应，而 take 则是执行流执行到 take 语句时才响应。takeEvery 只是监听 action, 并执行相对应的处理函数，对何时执行 action 以及如何响应 action 并没有多大的控制权，被调用的任务无法控制何时被调用，并且它们也无法控制何时停止监听，它只能在每次 action 被匹配时一遍又一遍地被调用。但是 take 可以在 generator 函数中决定何时响应一个 action 以及 响应后的后续操作。
例如在监听所有类型的 action 触发时进行 logger 操作，使用 takeEvery 实现如下：

import { takeEvery } from 'redux-saga'

function* watchAndLog(getState) {
  yield* takeEvery('*', function* logger(action) {
      //do some logger operation  //在回调函数体内
  })
}

使用 take 实现如下：

import { take } from 'redux-saga/effects'

function* watchAndLog(getState) {
  while(true) {
    const action = yield take('*')
    //do some logger operation  //与 take 并行 
  })
}

其中 while(true) 的意思是一旦到达流程最后一步（logger），通过等待一个新的任意的 action 来启动一个新的迭代（logger 流程）。

阻塞和非阻塞

call 操作是用来发起异步操作的，对于 generator 来说，call 是阻塞的操作，它在 Generator 调用结束之前不能执行或处理任何其他事情。，但是 fork 却是非阻塞操作，当 fork 调动任务时，该任务会在后台执行，此时的执行流可以继续往后面执行而不用等待结果返回。

例如如下的登录场景:

function* loginFlow() {
  while(true) {
    const {user, password} = yield take('LOGIN_REQUEST')
    const token = yield call(authorize, user, password)
    if(token) {
      yield call(Api.storeItem({token}))
      yield take('LOGOUT')
      yield call(Api.clearItem('token'))
    }
  }
}

若在 call 在去请求 authorize 时，结果未返回，但是此时用户又触发了 LOGOUT 的 action,此时的 LOGOUT 将会被忽略而不被处理，因为 loginFlow 在 authorize 中被堵塞了，没有执行到 take('LOGOUT')那里

同时执行多个任务

如若遇到某个场景需要同一时间执行多个任务，比如 请求 users 数据 和 products 数据, 应该使用如下的方式：

import { call } from 'redux-saga/effects'
//同步执行
const [users, products] = yield [
  call(fetch, '/users'),
  call(fetch, '/products')
]

//而不是
//顺序执行
const users = yield call(fetch, '/users'),
      products = yield call(fetch, '/products')

当 yield 后面是一个数组时，那么数组里面的操作将按照 Promise.all 的执行规则来执行，genertor 会阻塞知道所有的 effects 被执行完成

源码解读

在每一个使用 redux-saga 的项目中，主文件中都会有如下一段将 sagas 中间件加入到 Store 的逻辑:

const sagaMiddleware = createSagaMiddleware({sagaMonitor})
const store = createStore(
  reducer,
  applyMiddleware(sagaMiddleware)
)
sagaMiddleware.run(rootSaga)

其中 createSagaMiddleware 是 redux-saga 核心源码文件 src/middleware.js 中导出的方法：

export default function sagaMiddlewareFactory({ context = {}, ...options } = {}) {
 ...
 
 function sagaMiddleware({ getState, dispatch }) {
    const channel = stdChannel()
    channel.put = (options.emitter || identity)(channel.put)

    sagaMiddleware.run = runSaga.bind(null, {
      context,
      channel,
      dispatch,
      getState,
      sagaMonitor,
      logger,
      onError,
      effectMiddlewares,
    })

    return next => action => {
      if (sagaMonitor && sagaMonitor.actionDispatched) {
        sagaMonitor.actionDispatched(action)
      }
      const result = next(action) // hit reducers
      channel.put(action)
      return result
    }
  }
 ...
 
 }

这段逻辑主要是执行了 sagaMiddleware()，该函数里面将 runSaga 赋值给 sagaMiddleware.run 并执行，最后返回 middleware。 接着看 runSaga() 的逻辑：

export function runSaga(options, saga, ...args) {
...
  const task = proc(
    iterator,
    channel,
    wrapSagaDispatch(dispatch),
    getState,
    context,
    { sagaMonitor, logger, onError, middleware },
    effectId,
    saga.name,
  )

  if (sagaMonitor) {
    sagaMonitor.effectResolved(effectId, task)
  }

  return task
}

这个函数里定义了返回了一个 task 对象，该 task 是由 proc 产生的，移步 proc.js：

export default function proc(
  iterator,
  stdChannel,
  dispatch = noop,
  getState = noop,
  parentContext = {},
  options = {},
  parentEffectId = 0,
  name = 'anonymous',
  cont,
) {
  ...
  const task = newTask(parentEffectId, name, iterator, cont)
  const mainTask = { name, cancel: cancelMain, isRunning: true }
  const taskQueue = forkQueue(name, mainTask, end)
  
  ...
  
  next()
  
  return task

  function next(arg, isErr){
  ...
	  if (!result.done) {
	    digestEffect(result.value, parentEffectId, '', next)
	  } 
  ...
  }
}

其中 digestEffect 就执行了 effectTriggerd() 和 runEffect(),也就是执行 effect，其中 runEffect() 中定义了不同 effect 执行相对应的函数，每一个 effect 函数都在 proc.js 实现了。

除了一些核心方法之外，redux-saga 还提供了一系列的 helper 文件，这些文件的作用是返回一个类 iterator 的对象，便于后续的遍历和执行, 在此不具体分析。

参考文档

• Redux-saga 中文文档
• 从redux-thunk到redux-saga实践

之前一直听说这本书很出色，朋友也是力推这本书，于是就下载了电子版的三部曲，真正看下去之后，就不能自拔了，这本书确实写得很精彩，如果没有一定的科学方面的知识和人文方面的素养，是绝不会有这样的著作的。在首页的导读中，姚海军写到：

**科幻与美国科幻的差距。在科幻作品方面，**虽然需求很大，但是可以摆在市面上的作品确是寥寥无几。

但是刘慈欣的这部作品确是给**的科幻作品添上了浓墨重彩的一笔，值得赞叹和喝彩。

实习的生活还是比较忙的，而且我也不想贪恋着一口气读完，所以一般是利用早上挤地铁的时候来欣赏一下，看到动情处，总是感叹作者的想象力和文笔，惊叹这么浩渺磅礴的场景描述。

第一部的主人公是汪淼，一个研究纳米材料的教授。却被卷入一场阴谋当中，一个处于地球之外的三体文明，策划着一场即将侵蚀和禁锢地球文明的阴谋。故事在一开始是很悬疑的，汪淼被一个诡异的倒计时折磨着，就像幽灵，在他所在之处跳跃着。

这种感觉，让人害怕和惊悚。之后，杨冬和一些著名科学家的死更加增添了这层诡异。汪淼在三体世界这个游戏中体验的一些三体世界的生活更是让人惊讶。人可以在乱纪元中脱水储藏，在恒纪元中浸泡让自己复活，这种“异想天开”的想象让我佩服，这种因为自然环境的因素而演化出来的存活和死亡，居然是这样地神奇。随着汪淼在三体游戏玩的次数越来越多，故事的真相也在慢慢揭晓。最后水落石出是叶文洁说出来的

自己在红岸基地上研究，并且向三体文明发出了地球文明的回应，除此之外，她还亲手杀了她的丈夫杨卫宁和一名军官雷志成。最后伊文斯知道了叶文洁的秘密之后，居然建立了地球上的三体组织，他们把三体文明奉为主，并且在地球上建立起拥护三体文明的组织，并通过这个组织不断地向远在地球之外的三体人发送着地球上一切。这还不算什么，在从伊文斯被截断的船上获取最新的他们和三体人的最后一次交流中可以获知，三体人已经研发出一种叫做"质子"的东西，它可以监视地球上的一举一动，阻碍地球上的物理学领域的发展，甚至因此让地球上一些出色的科学家在精神上迷乱甚至因此自杀，只有这样，地球上的科学才会停滞不前。

戳穿了三体人民的阴谋之后，一切都真相大白了。但是面对如此强大的敌人，地球人显得手足无措甚至恐慌，这太不可思议了，在宇宙之中，居然还存在着除了地球文明之外的文明，并且这个文明即将毁灭地球文明。知道真相的汪淼和丁仪感到很挫败，

甚至产生了失败主义，他们不知道怎么去对付这个强大的质子和三体文明的入侵，但是大史带着他们去他家乡看蝗虫的繁衍，将人和蝗虫之间的对峙和人与三体人民的对峙进行对比

“是地球人和三体人的技术水平差距大呢，还是蝗虫和咱们人的技术水平差距大？”

这句话让汪淼和丁仪顿时自惭形秽，于是第一部就在这种未知胜负的结局中结束了。。。
看完第一部之后，真的很震撼，这部书中，充满着很多的物理知识以及一些其他领域的知识，比如宇宙领域的，文学领域的，三体游戏中出现的各种场景，不论是**历史还是外国历史，作者都很熟悉并很自然地结合自己的想象力揉在字里行间中，简直是太神奇了。看完之后很赞叹。

故事的帷幕在一点点拉开，期待和第二部的相见。。。。。

看到这本书的时候就想买了，因为喜欢白岩松。而且去年的时候，白岩松刚好在我学校演讲过，对他的仰慕更深了一层。看到这本书更是惊喜，然后就毫不犹豫地买了，当然，也很值得。

由于在实习，大多数的时间都占据在需求上面，只有周末陆陆续续的时间来看一下这本书，但是说到底还是挤时间看完了，收益良多。在字里行间里感受到的是白岩松的睿智和从容，那是一种**，一种成熟。除此之外，他的经历和人生都是那么地精彩，在他的经历中，每一件都和国家大事挂钩，那是一种将自己融入到国家的伟岸。而且即使在收获了那么多的赞誉和仰慕之后，他还是可以做到宠辱不惊和淡定，这是一种怎样平淡和从容的心。

这本书是基于作者的经历和思考写成的，配有很清晰的图，让读者在阅读的时候思考人生，他的思考永远是建立在大格局上面的，不是一种小商小贩的庸俗，也不是一种妇人的短浅，他是站在国家的甚至世界的角度诉说着世界的好与坏，没有一丝做作和犹豫，相对于很多人，他活得更明白和清楚，从他的文字里，我看到的是一种理性，理性中带着厚重，带着对未来的思考，让人很容易静下心来，思考自己的人生。。。。
下面摘录一些经典的话：

• 首先要解决人和物的问题，接下来要解决人和人的问题，最后一定要解决人和自己内心的问题。
• 不平静，就不会幸福，也因此，当下的时代，平静才是真正的奢侈品。
• 人的一生，不管贫富贵贱，最后加减乘除，一算分，都一样。
• 如果让人感动的人，负责获奖，而让人愤怒或者厌倦的人们，却获得利益，那么，感动，又有何意义？
• 过去了的终究过去，当初的期待实现与否，也同样被时光带走，不管你愿不愿意，一个新的起跑线又画在这里。人们之所以可以忍受苦难，在于还可以拥有希望。

还有很多比较鞭辟入里的思考，虽然尖锐，但是却可以引发读者的思考。“幸福”这个东西，说大就很大，说小也很容易，每个人对幸福的定义不同，自然人生也就不一样。对于幼童来说，一个微笑就是幸福，但是对于很多人来说，幸福往往是那么遥不可及，因为金钱，私欲，诱惑占据着人们的全部神经，在这个物欲横流的世界，节奏快得让人不能静下心来思考，其次，现在的人缺少一份责任心，因为个人的私欲已经凌驾于对国家和社会的责任之上了，所以就会有那么多的犯罪和欺凌。。。这是个人的幸福。对于整个**来说，她的幸福就建立在一个很大的环境之下了，作者通过剖析**最近几年发生的几件大事：汶川大地震，申奥成功，举办北京奥运会，包括**足球，与日本和美国以及**的关系，作者通过自己的采访经历剖析出**该怎么对待这些事情以及在未来的发展中应该以什么姿态前进。

“有人形容说：**想一辆自行车，只要保持一定速度向前骑行，它就会稳定，而一旦有一天，向前的动力慢下来，它就左右摇摆，速度再慢下来，它就终会倒下。”

读白岩松的书，会增长见识，最重要的是他会引导你以一种新的高度来思考人生，而不是始终觊觎自己的一己私利。人生短短十几载，随着年龄的增长，你对太阳和温暖的感觉都会不一样，在不断经历过程中，你会渐渐走向成熟，那么到了那个时候，所有让你苦苦追求的东西都会成为过眼云烟。
人生，最重要的是看透，然后拥有一份属于自己的豁达。。。。

dva 初探

前言： 最近正在学习 dva ,整理出一些学习笔记，笔者默认阅读此文的读者有一定的react , redux , redux-saga 基础，如果没有，可先自行了解这些技术，本文不再赘述。

什么是 dva

dva是基于现有应用框架（redux+react-router+redux-saga等）封装的一个框架（不是库），基本上没有引入新概念，也没有创建新语法，对于熟悉前言中涉及的技术栈的童鞋来说会非常容易上手。详细介绍可移步dva介绍

为什么会有 dva

在处理复杂异步请求的业务中，一开始我们是使用 redux-thunk + async/await 结合使用，比如在异步登录的逻辑中，使用 redux-thunk 处理如下：

// action/auth.js

import request from 'axios';
import { loadUserData } from './user';

export const login = (user, pass) => async (dispatch) => {
    try {
        dispatch({ type: LOGIN_REQUEST });
        let { data } = await request.post('/login', { user, pass });
        await dispatch(loadUserData(data.uid));
        dispatch({ type: LOGIN_SUCCESS, data });
    } catch(error) {
        dispatch({ type: LOGIN_ERROR, error });
    }
}

这种处理之后，组件调用的是dispatch(action creator)，此时的 action 被赋予了太多的逻辑功能，不再是一个 pure action 。为了保持 action 的简洁性，继而引入 redux-saga ,它提供了一个 saga 文件用来存放异步逻辑，引入 redux-saga 之后，上面的验证用户登录逻辑就变成如下：

// sagas/index.js
import { take, call, put } from 'redux-saga/effects'
import Api from '...'

export function* login(user, pass) {
  try {
    const data = yield call(Api.authorize, user, pass)
    yield put({type: 'LOGIN_SUCCESS', data.uid})
  } catch(error) {
    yield put({type: 'LOGIN_ERROR', error})
  }
}

使用 redux-saga 之后，action 又回归其纯粹性。并且将异步操作全部抽离在 sagas 中一层进行处理，这样方便我们进行多种异步处理操作。
redux-saga 虽然在处理较为复杂的异步逻辑时提供了比较好的解决方案，但是当业务变复杂时，随着模块的逐渐增加，由于项目通常要分 reducer, action, saga, component 等等,所以项目中的文件个数也会变得很多，如下：

    + src
      + actions
        - user.js
        - detail.js
      + reducers
        - user.js
        - detail.js
      + sagas 
        - user.js
        - detail.js
      + components

这样在项目开发过程中，就需要不断地切换文件目录，大大影响开发效率。于是 dva 应运而生，dva 的主要解决的项目开发中的痛点：

• reducer, saga, action 之间来回切换的开发成本
• saga 创建麻烦
• 主文件中的入口逻辑变得很复杂

上面的例子使用 dva 来实现如下：

// models/login.js

import Api from '...'

export default {
  namespace: 'login',
  state: {
    user: null
  },
  effects: {
	 *login(){
	   const data = yield call(Api.authorize, user, pass)
       yield put({type: 'LOGIN_SUCCESS', data.uid})
	 },	
  },
  reducers: {}
}

其中，reducers 可以看成是同步的请求逻辑，effects 可以看成是异步的请求逻辑，所有的逻辑都放在了 models 目录下的文件中，省去了文件之间的切换成本，让开发人员可以专注于业务逻辑。
具体可以参考支付宝前端应用架构的发展和选择

dva 的相关知识点

dva中只有5个 API，8个新的概念，其中所有的 API 如下：

• app = dva(Opts) 创建应用，返回 dva 实例
• app.use(Hooks) 配置 hooks 或者注册插件
• app.model(ModelObject) 注册 model
• app.router(Function) 注册路由表
• app.start([HTMLElement], opts) 启动应用

具体的使用可以移步这里

8个概念如下所示：

• State 表示应用的所有数据层，其中全局的 state 由所有 model的 state 组成
• Action 表示应用的所有事件，包括同步的和异步的，格式如下：

{
  type: String,
  payload: Any?,
  error? Error,
}

调用的时候有如下两种方式：

• dispatch(Action);
• dispatch({ type: 'todos/add', payload: 'todo content' });
• Model 用于将数据相关的逻辑进行聚合
  • Reducer 和 redux 中的 reducer 概念相同，接受 state，action 作为参数，返回新的state
  • Effect 用来处理异步逻辑，使用 generator实现
  • Subscription 表示订阅，用于订阅一个数据源，然后按需 dispatch action。
• Router 路由的配置信息
• RouteComponent 表示 Router 里匹配路径的 Component，通常会绑定 model 的数据

dva 的使用

如何基于 dva 开发一个项目，dva 的作者给出了一个一步步开发 dva 项目的教程, 笔者仿照该教程，并且基于 dva2.0, 做出了一个 demo，该 demo 类似于 dva中的范例，只是初步体验一下 dva 的开发。

深入 dva

借用描述 dva 数据流动的一张图，如下所示：

如图所示：用户在浏览器中访问某个 URL，由此渲染一个页面，该页面可能包含多个 Components, 当用户在页面进行操作的时候，由此 dispatch 某个 action，同步的 action 逻辑放在 Reducer 中，异步的 action 逻辑存放在 Effect 中。通过 model 中的数据处理，将新的 state 传入页面中，从而触发页面数据的更新。

dva 源码解读

这次的解读主要是针对 [email protected] 和 [email protected]。

首先是 dva 中的入口文件所暴露出来的方法，主要是const app = dva();这行代码的作用,返回一个 app实例。该方法如下:

export default function (opts = {}) {
  const history = opts.history || createHashHistory();  //history默认是HashHistory
  const createOpts = {
    initialReducer: {
      routing,
    },
    setupMiddlewares(middlewares) {
      return [
        routerMiddleware(history),
        ...middlewares,
      ];
    },
    setupApp(app) {
      app._history = patchHistory(history);
    },
  };

  const app = core.create(opts, createOpts);
  const oldAppStart = app.start;
  app.router = router;
  app.start = start;
  return app;
}
// 此处略去一些方法的定义

这个函数很简单，主要是调用了 dva-core 里面的 create 方法，并且返回了一个包含如下方法的 app 对像：

  var app = {
    _models: [(0, _prefixNamespace2.default)((0, _extends3.default)({}, dvaModel))],
    _store: null,
    _plugin: plugin,
    use: plugin.use.bind(plugin),
    model: model,
    start: start
  };

对 app 的初始化定义在 dva-core/lib/index.js 文件中。在这个文件中，实现了 app 对象的所有方法。接下来一个一个进行分析：

model()

这个方法比较简单，只是将传进来的 model push 进 _models 这个属性中。这就意味着每次我们注册 model 时，只能单个进行传递，不能以数组的形式进行传递，例如：

app.model(Model1); app.model(Model2);
//而不是
app.model([Model1,Model2])

injectModel()

其实 app.model 在调用 app.start 之后会变成 injectModel（）, 它的源码如下：

  function injectModel(createReducer, onError, unlisteners, m) {
    model(m);

    var store = app._store;
    if (m.reducers) {
      store.asyncReducers[m.namespace] = (0, _getReducer2.default)(m.reducers, m.state);
      store.replaceReducer(createReducer(store.asyncReducers));
    }
    if (m.effects) {
      store.runSaga(app._getSaga(m.effects, m, onError, plugin.get('onEffect')));
    }
    if (m.subscriptions) {
      unlisteners[m.namespace] = (0, _subscription.run)(m.subscriptions, m, app, onError);
    }
  }

这个函数里面调用了上面的 model() ，除此之外，该函数还将 model 定义的 reducers，effects, subscriptions 进行分别处理。

• reducers 分支 是调用 redux 的原生 api 对 model 中的 reducers 进行处理
• effects 分支是调用 redux-saga 中的 sagaMiddleware.run() 来执行管理一部 action，在这之前，先调用了 app._getSaga()方法：

export default function getSaga(resolve, reject, effects, model, onError, onEffect) {
  return function *() {
    for (const key in effects) {
      if (Object.prototype.hasOwnProperty.call(effects, key)) {
        const watcher = getWatcher(resolve, reject, key, effects[key], model, onError, onEffect);
        const task = yield sagaEffects.fork(watcher);
        yield sagaEffects.fork(function *() {
          yield sagaEffects.take(`${model.namespace}/@@CANCEL_EFFECTS`);
          yield sagaEffects.cancel(task);
        });
      }
    }
  };
}

这个方法主要实现了 saga 那一套的watch/worker（监听->执行） 的工作形式。其中该函数传入的 resolve,reject 是 createPromiseMiddleware.js 这个文件生成的。之所以有这个文件，主要是提供一种机制，提供给某些需要 effect 返回 resolve, reject 等方法的场景。

• subscriptions 分支调用了同级目录下 subscription.js 中的 run(), run() 的逻辑是把所有的 listener 遍历执行一遍并返回不同分类（是函数或不是函数）的集合。

start()

这个函数用来启动整个应用, 其中 dva 中的 start() 主要是根据传入的 container 容器来渲染页面，核心代码如下：

  if (container) {
      render(container, store, app, app._router);
      app._plugin.apply('onHmr')(render.bind(null, container, store, app));
    } else {
      return getProvider(store, this, this._router);
    }

如果传入的参数是 DomElement 或者 DomQueryString，那么直接启动应用，渲染页面，否则就返回一个 <Provider /> (React Component)。
除此之外，dva-core 中的 start(), 则是将 dva 的所涉及的一些概念全部整合到一个 store 的对象中，并执行一些赋值操作，具体源码移步这里

create()

这是 dva-core 中唯一暴露的一个函数，里面包含了上面介绍的三个函数，并且还夹杂了一些其他的逻辑。比如插件的使用，关于插件，它的主要逻辑是放在了 dva-core/Plugin.js 这个文件里面，这个文件提供了一个插件管理类，提供了 apply(), get(), use() 成员方法，这个类主要对钩子函数进行了一些处理，并且限制了钩子函数的几个可选项：

const hooks = [
  'onError',
  'onStateChange',
  'onAction',
  'onHmr',
  'onReducer',
  'onEffect',
  'extraReducers',
  'extraEnhancers',
];

关于 hooks 的概念，可以移步这里进行查阅

总结

以上只是笔者在这几天的学习中总结的一些技术要点，由于时间比较仓促，所以有些地方可能总结得有点问题，如有错误，欢迎指正~

参考资料

• dva 源码解读
• dva 学习资料

React Hooks 进阶

前言

上一篇简单地介绍了一下 React Hooks 的背景和 API 的使用，这一篇深入探索一下 React Hooks 的实践和原理。

React Hooks 实践

模拟 Class Component 的生命周期

有的时候还是需要根据不同的生命周期来处理一些逻辑，React Hooks 几乎可以模拟出全部的生命周期。

componentDidMount

使用 useEffect 来实现，如下：

useEffect(()=> {
  	//ComponentDidMount do something
},[]);

useEffect 第二个参数传空数组时，表示只会在执行一次。

componentWillUnMount

同样可以使用 useEffect 来实现，如下：

useEffect(()=> {
	return ()=> {
    // ComponentWillUnMount do something
  }
},[])

componentDidUpdate

componentDidUpdate 生命周期在组件每次更新之后执行，除了初始化 render 的时候不执行，所以可以设置一个标志位来判断是否是第一次 render，使用 useEffect + useRef 配合就可以实现：

const firstRenderRef = useRef(true)

useEffect(()=>{
	if(firstRenderRef.current){
    // 如果是第一次 render，就设置为 false
  	firstRenderRef.current = false;
  } else {
    // componentDidUpdate do something
  }

})

getDerivedStateFromProps

getDeriverdStateFromProps 是 react 新版本中用来替代 componentWillReceiveProps，它可以感知 props 的变化，从而更新组件内部的 state，用 hooks 模拟这个生命周期，可以这样实现：

function Child(props){
	const [count,setCount] = useState(0);
  if(props.count !== count){
  	setCount(props.count);
  }
}

shouldComponentUpdate

React 16.6 引入 React.memo，是用来控制 Function Component 的重新渲染的，类似于 Class Component 的 PureComponent，可以跳过 props 没有变化时的更新，为了支持更加灵活的 props 对比，它还提供了第二个函数参数 areEqual(prevProps, nextProps)，和 shouldComponentUpdate 相反的是，当该函数返回 true 时表示不更新函数，返回 false 则重新更新，用法如下：

function Child(props){
    return <h2>{props.count}</h2>
}
// 模拟shouldComponentUpdate
const areEqual = (prevProps, nextProps) => {
   //比较
};

const PureChild = React.memo(Child, areEqual)

除了上面这种方法可以模拟 shouldComponentUpdate 之外，React Hooks 还提供一个 useMemo 用来控制子组件重新渲染的，举一个例子如下：

// Parent 组件
function Parent() {
  	const [count,setCount] = useState(0);
  	const child = useMemo(()=> <Child count={count} />, [count]);
  	return <>{count}</>
}

// Child 组件
function Child(props) {
    return <div>Count:{props.count}</div>
}

在上面的例子中，只有 Parent 组件中的 count state 更新了，Child 才会重新渲染，否则不会。

React Hooks 原理

还记得我们之前讲过的使用 React Hooks 的两条规则吗？

• 只在 React 函数和 自定义 Hooks 中使用，不要在普通 js 中使用 Hooks
• 只在顶层使用 Hook，不在循环、条件或者嵌套函数中调用 Hook

现在我们来一一剖析一下为什么会有这个限制？

只能在 React 函数和自定义 Hooks 中使用

翻到 ReactHooks 对应的源码，贴出 Hooks 的定义如下：

// useState
export function useState<S>(initialState: (() => S) | S) {
  const dispatcher = resolveDispatcher();
  return dispatcher.useState(initialState);
}
// useEffect
export function useEffect(
  create: () => (() => void) | void,
  inputs: Array<mixed> | void | null,
) {
  const dispatcher = resolveDispatcher();
  return dispatcher.useEffect(create, inputs);
}
// useRef
export function useRef<T>(initialValue: T): {current: T} {
  const dispatcher = resolveDispatcher();
  return dispatcher.useRef(initialValue);
}
...
//其他的都类似

所有的 Hooks 基本都调用了这个 resolveDispatcher()，定位到 resolveDispatcher，代码如下：

function resolveDispatcher() {
  const dispatcher = ReactCurrentDispatcher.current;
  invariant(
    dispatcher !== null,
    'Invalid hook call. Hooks can only be called inside of the body of a function component. This could happen for' +
      ' one of the following reasons:\n' +
      '1. You might have mismatching versions of React and the renderer (such as React DOM)\n' +
      '2. You might be breaking the Rules of Hooks\n' +
      '3. You might have more than one copy of React in the same app\n' +
      'See https://fb.me/react-invalid-hook-call for tips about how to debug and fix this problem.',
  );
  return dispatcher;
}

如果 ReactCurrentDispatcher.current 是空的，就会得出我们使用 Hooks 的方式不对，只有在 React 环境中才会给 ReactCurrentDispatcher 的 current 赋值，所以就可以解这个问题。

不在循环、条件或者嵌套函数中调用 Hook

为什么不能在循环、条件或者嵌套函数中调用 Hook，我们还是从源码出发寻找原因：
Hooks 的实现源码在 ReactFiberHooks.js。
在这个文件中，定义了 firstWorkInProgressHook 和 workInProgressHook 这两个全局变量，观察所有的 Hooks 实现，发现都执行了 const hook = mountWorkInProgressHook()，首先来看一下这个函数的实现：

function mountWorkInProgressHook(): Hook {
  const hook: Hook = {
    memoizedState: null,

    baseState: null,
    queue: null,
    baseUpdate: null,

    next: null,
  };

  if (workInProgressHook === null) {
    // This is the first hook in the list
    firstWorkInProgressHook = workInProgressHook = hook;
  } else {
    // Append to the end of the list
    workInProgressHook = workInProgressHook.next = hook;
  }
  return workInProgressHook;
}

我们来模拟一下定义多个 Hooks 时的流程：

• 初始时，组件还未渲染时，firstWorkInProgressHook = workInProgressHook = null；
• 初次渲染
  • 定义第一个 Hook 时：firstWorkInProgressHook = workInProgressHook = hook；
  • 定义第二个 Hook 时：workInProgressHook = workInProgressHook.next = hook；
  • 定义第三个 Hook 时：workInProgressHook = workInProgressHook.next = hook；

这种结构就是一个链表结构，而每一个 Hook 的结构如下：

type Hook = {
  memoizedState: any,
  baseState: any,
  baseUpdate: Update<any, any> | null,
  queue: UpdateQueue<any, any> | null,
  next: Hook | null,
};

type Effect = {
  tag: HookEffectTag,
  create: () => (() => void) | void,
  destroy: (() => void) | void,
  deps: Array<mixed> | null,
  next: Effect,
};

其中 memoizedState 存储当前 Hook 的结果，next 则连接到下一个 Hook，从而将所有 Hook 进行串联起来。这个链表结果存储在 Fiber 对象的 memoizedState 属性中，在 React 中，每个节点都对应一个 Fiber 对象，而 Fiber 的 memoizedState 用来存储该节点在上次渲染中的 state，这个属性是 Class Component 用来存储节点的 state 的，这也就是为什么 Hook 可以拥有 Class Component 功能的原因。
链表结构用图形显示如下：

在第二次渲染时，也就是 update 的时候，此时调用的是 Hook 对应的 update 方法，而 update 方法又分别执行了 updateWorkInProgressHook()，先来看看这个方法的实现：

function updateWorkInProgressHook(): Hook {
  if (nextWorkInProgressHook !== null) {
    // There's already a work-in-progress. Reuse it.
    workInProgressHook = nextWorkInProgressHook;
    nextWorkInProgressHook = workInProgressHook.next;

    currentHook = nextCurrentHook;
    nextCurrentHook = currentHook !== null ? currentHook.next : null;
  } else {
    // Clone from the current hook.
    invariant(
      nextCurrentHook !== null,
      'Rendered more hooks than during the previous render.',
    );
    currentHook = nextCurrentHook;

    const newHook: Hook = {
      memoizedState: currentHook.memoizedState,

      baseState: currentHook.baseState,
      queue: currentHook.queue,
      baseUpdate: currentHook.baseUpdate,

      next: null,
    };

    if (workInProgressHook === null) {
      // This is the first hook in the list.
      workInProgressHook = firstWorkInProgressHook = newHook;
    } else {
      // Append to the end of the list.
      workInProgressHook = workInProgressHook.next = newHook;
    }
    nextCurrentHook = currentHook.next;
  }
  return workInProgressHook;
}

在这个方法中，它会获取渲染时生成的 Hooks，并获取当前 update 的是处于链表的哪个节点，然后返回。
假如在条件语句中使用 Hook，如下：

let condition = true;
const [state1,setState1] = useState(0);
if(condition){
    const [state2,setState2] = useState(1);
    condition = false;
}
const [state3,setState3] = useState(2);

初始渲染时，拿到的是 state1 => hook1，state2 => hook2，state3 => hook3，再次渲染时，condition 条件不满足，那么执行 state3 时拿到的就是 hook2，那整个逻辑就乱套了...

结语

React Hooks 解决了一部分问题，但同时自身也有一定的缺陷，比如要遵守一定规则、组件嵌套层次不明显导致 bug 定位难。所以在实际的开发实践中，还是要评估再选型。

这真是一本神奇的书，在地铁上虽然被挤得只能贴近地铁门，但还是被里面的故事情节给深深吸引，所以即使沙河离西二旗算得上是很长的一段距离，有了它便觉得这段时间也是那么短。三体第二部
《黑暗森林》主要写的是地球文明和三体文明之间的战争。

在识破三体人安插质子的真正阴谋之后，人类文明开展了面壁计划，这个计划主要是挑选四位面壁者作为挑战甚至破解三体的阴谋。其他三位当然是实至名归，都是在政治或者科学方面有一定造诣的人，当罗辑被选中的时候，我也是感到很惊讶，他在科学方面没有很大的造诣，甚至在品质方面有点自我享乐的劣迹，但是当故事帷幕渐渐拉开的时候，甚至就是因为他和叶文洁在杨冬坟墓前的一次对话让事情有了真相。他甚至成为四个面壁者中对三体世界有着最大威胁的人。当然，其他三个面壁者都通过调用一定的资源开展着自己的面壁计划，唯有罗辑要求在一个世外桃源中与自己的爱人享乐，不问世事，直至联合国对他进行了强制要求，他才开始了一个所谓的咒语计划。最后的结局是，在面壁计划展开的同时，三体文明也展开了破壁计划，除了罗辑，每一个面壁者都有自己的破壁人，他们通过质子的监视对自己的面壁者进行分析，最终识破他们的计划而最终让他们的精神崩溃。从此展开了地球文明和三体文明之间的拉锯战。
结果很令人惊讶，面壁计划失败了：

• 面壁者弗雷德里克.泰勒的量子计划没有任何战略意义，并且企图攻击病消灭地球舰队
• 面壁者雷迪亚兹的水星坠落连锁计划更是邪恶，企图吧整个地球生命作为人质。
• 面壁者希恩斯的**钢印则是侵犯了人类的**自由，而罗辑则被视为只会为自己营造享乐生活。

在罗辑和其他人被冬眠后苏醒的世界里，真正的三体和地球的世界末日之战并没有来临，罗辑醒来之后看到的生活是十分现代化的：人们生活在叶子上，各种高科技，人们的衣服是可以任意调换大小的。。。。种种高科技，让罗辑一时难以适从。之后才知道，人们在经历臆测世界末日来临的同时，经历各种恐慌和大范围的逃亡主义和失败主义的挣扎，但是最后在经历了大低谷时期之后，他们开始技术发展，让世界飞速发展，并建立了很多太空舰队。甚至在意识上认为人类是必胜的，在这种必胜信心的笼罩下，没人再谈起面壁计划，面壁计划由此而废除。然而，三体的第一颗水滴到达地球时，它在很短的时间内摧毁了人类几个世纪建立起来的几千艘舰队，这种战斗力让人们瞠目结舌。

"水滴就像一枚死神的绣花针，灵巧地上下翻飞，用一条毁灭的折线把第三队列的一百艘战舰贯穿起来。"

这是原文的描述。对于水滴撞击战舰的场景，作者的文笔和想象力真是让我敬佩，那么磅礴和宏伟的场景，让读者仿佛身临其境一样，简直精彩。就在全世界都被水滴的强大攻势所恐慌而绝望甚至开启了超级性派对的**堕落的生活时，罗辑以为水滴会来刺杀自己的时候，剧情有一次戏剧性地逆转了，罗辑之前的咒语生效了，水滴在靠近地球的时候又转向了，并没有攻击地球，而是封锁了太阳系。。。罗辑再一次被奉为救世主，面壁计划再次开始，全世界的人们都把罗辑作为整个地球的唯一救世主，但是失败的局势无法扭转，罗辑也是无能为力。但是，最后，罗辑再次用氢弹计划威胁三体，避免了地球文明的消失。。。

第二部写得很精彩，无论是故事情节还是写作手法，作者擅长用不同的视角来叙述，比如第二部开始是用一只蚂蚁的视角，然后是蜘蛛，最后变成罗辑，而且在这部中，一些人物的塑造也是很成功
的，比如章北海，丁仪，大史。让我最为惊叹的是水滴撞击战舰时候的场景，简直是神来之笔。

总之，这真是一本神书，强烈推荐。。。。

express中的路由和应用

express中的路由还是很强大的，express中的路由实现主要有如下几种形式：

应用实例路由

直接上代码：

var express = require('express');
var app = express();

// get路由
app.get('/', function(req, res) {
  res.send('get');
});

//post路由
app.post('/', function (req, res) {
  res.send('post');
});

这种是比较简单的，所以不多说

app.route()

app.route()的功能是创建路由路径的链式路由句柄，我个人觉得就是将上面那种方法的分开写转化为一种链式形式，示例代码如下：

app.route('/Article')
  .get(function(req, res) {
    res.send('获取文章列表');
  })
  .post(function(req, res) {
    res.send('添加文章');
  })
  .put(function(req, res) {
    res.send('更新文章');
  });

express.Router()

express中的Router实例是完整的中间件和路由系统，因此也被称为“微型应用程序"，使用示例如下：
router/index.js文件:

var express = require('express');
var router = express.Router();

//get路由
router.get('/a', function(req, res) {
  res.send('get');
});

router.post('/b',function(req, res) {
    res.send('post');
})
module.exports = router;

app.js

var index = require('./routes/index');
//....   other codes
app.use('/', routes);

使用express.Router

实现系统登录前的拦截功能，也就是说当用户未登录时，没有权限访问一些页面。只有登录后才可以访问。要实现这种功能，需要使用express-session记录当前登录的用户信息，关于这个库的详细信息，可以点击这里,下面用两种方法实现

第一种

• 首先创建一个login表单(由于比较简单，所以就不贴代码了)
• route/index.js路由文件中的代码如下:

// 登录页面
//如果直接访问/login时则显示登录页面
router.get('/login',function(req,res){
  res.render('login', { title:'用户登录' });
});

// 查看文章页面
//用户未登录时跳转到登录页面
router.get('/write',function(req,res){
  var user = req.session.user;  //获取session中的user信息
   if(!user){
     res.render('login',{title:'用户登录'});
   }else{
     res.render('article',{ title:'文章页面'});
   }
})

第二种

• 同样创建一个login表单
• 在app.js中进行拦截，定义一个中间件，在中间件中执行一些参数检查和登录拦截的逻辑即可，具体代码如下：

app.use(session({
    secret:"myzhibie",
    store:new MongoStore({
        mongooseConnection:db.dbCon //这里使用了connect-mongo库，
    })
}));

app.use(function(req,res,next){
    var url = req.originalUrl;
    var user = req.session.user;  //记录登录的信息
    if((url == '/article') && !req.session.user){  //在这里进行拦截判断
        req.session.error = '还没登录，请先登录';
        return res.redirect('/login');
    }
    next(); 
})

但是我个人比较倾向于第二种方法，因为具有更大的灵活性，可以根据自己的业务复杂程度添加自己的逻辑，而且使用的是中间件，对理解中间件的原理有较大的帮助

总结

express.Router()是在express4.0中才添加的，但是相比于应用路由有更大的优势，具体可以总结为如下几点：

• 多次使用express.Router()可以创建多组路由
• 可以使用中间件对request做一些验证和过滤处理

Egret是一套HTML5游戏开发解决方案,旨在为h5提供更加方便的开发体验。总的来说egret的功能还是很强大的，最近接手的一个需求的时候使用了egret，使用完之后感觉很棒，把自己的一些经验积累下来。

egret的官方文档地址在这里,API很详细。

既然是写使用总结，还是从最简单的安装到使用吧，虽然官方文档里面也写得很清楚（捂脸）。

安装

安装地址移步这里

• 按照自己的机器安装Egret Engine即可
• 安装完后打开会出现如下界面：

此时我的egret引擎有两个版本，如果你想安装新的版本，可以点击上面图片面板中的"安装其他版本",进行下载，然后将解压之后的安装包拖进安装面板即可。

还要说的一点就是建议安装一个开发egret的编辑器egret wing,安装方式如下：

点击上面图片面板中的左侧边栏的“工具”栏，就会出现对应的一些工具：

找到相对应的这个工具，并点击下载即可

新建项目

打开安装的egret wing，并且点击如下位置或者直接到“文件->新建项目"中进行建立新的项目:

此时会弹出一个项目类型的面板，根据你的需要选择一种项目类型就行。这里我选择的是Egret Eui项目，然后会弹出如下面板：

选择你所需要的库并填写相应的项目目录以及项目名称就大功告成了

运行

你可以直接在egret wing中进行构建，也可以直接在命令行中进行运行：

egret startserver 项目名称 --port 端口号 -a

-a表示会实时监听你文件的变化并且构建编译。
回车之后就会自动跳转到浏览器中，打开的就是你项目的初始的样子：

这说明项目已经运行成功了。

egret目录结构

egret使用的是typescript实现的，初始项目目录结构如下：

其中不同文件夹对应的功能如下：

• bin-debug -- 编译之后的代码目录
• libs -- 构建新项目时勾选的扩展库文件
• resource --资源文件，包括eui库的一些初始组件文件
• src -- 真正有效的用于用户开发的逻辑文件
• template -- 模板文件
• index.html -- 项目的视图文件
• egretProperties.json -- egret的配置文件
• tsconfig.json -- typescript配置文件

egret技术细节

项目的运行流程

打开main.js文件（项目的入口文件),项目运行的时候是首先执行的createChildren()函数，该函数主要功能是加载了一些资源，并且监听了配置文件加载的事件，主要是下面这行代码进行起监听作用：

RES.addEventListener(RES.ResourceEvent.CONFIG_COMPLETE, this.onConfigComplete, this);

当配置文件加载完成之后就会执行下面的onConfigComplete(),在这个函数里面你就可以load一些图片资源了。并进行监听图片资源组是否加载成功:

   RES.addEventListener(RES.ResourceEvent.GROUP_COMPLETE, this.onResourceLoadComplete, this);
        RES.addEventListener(RES.ResourceEvent.GROUP_LOAD_ERROR, this.onResourceLoadError, this);
        RES.addEventListener(RES.ResourceEvent.GROUP_PROGRESS, this.onResourceProgress, this);
        RES.addEventListener(RES.ResourceEvent.ITEM_LOAD_ERROR, this.onItemLoadError, this);
        RES.loadGroup("preload");

这里面监听了图片的"加载完成、加载中、资源组加载出错、单个资源加载出错“的事件。所以若是项目中有加载资源的进度条的要求，就可以通过onResourceProgress这个函数进行相应的处理

记住，对于已经监听的事件，若是不需要了或者监听完了，要及时取消，否则就会触发很多问题。
例如在onConfigComplete()函数里面就及时地取消了CONFIG_COMPLETE事件。

 RES.removeEventListener(RES.ResourceEvent.CONFIG_COMPLETE, this.onConfigComplete, this);

当图片资源组加载完成之后，就可以获取图片并且渲染到页面中。
移步到onResourceLoadComplete()，代码如下：

    private onResourceLoadComplete(event:RES.ResourceEvent):void {
        if (event.groupName == "preload") {
            this.stage.removeChild(this.loadingView);
            RES.removeEventListener(RES.ResourceEvent.GROUP_COMPLETE, this.onResourceLoadComplete, this);
            RES.removeEventListener(RES.ResourceEvent.GROUP_LOAD_ERROR, this.onResourceLoadError, this);
            RES.removeEventListener(RES.ResourceEvent.GROUP_PROGRESS, this.onResourceProgress, this);
            RES.removeEventListener(RES.ResourceEvent.ITEM_LOAD_ERROR, this.onItemLoadError, this);
            this.isResourceLoadEnd = true;
            this.createScene();
        }
    }

如上，首先是先取消了事件的监听(足以可见及时取消事件的监听是有多么重要），然后开始渲染页面。
根据代码逻辑直接跳转到startCreateScene(),在这个函数里面，只是获取了一些资源并且绘制了一些图案，然后add到舞台中。这样整个项目就完成的构建到渲染页面的整个过程。

容器对象

首选我们在渲染页面的函数startCreateScene()将this和this.stage进行打印，如下所示：

从上图可以看出，this.stage是包含this,至少从视图的层级上来看。7个children分别是执行this.addChild('元素')之后的结果。而且越排在后面的child深度越浅。也是官网中深度管理的这一章讲述的内容,越在后面，层级越高，也就是在z轴方向上处于最上面。当然你也可以按照如下方式自己设计元素的显示层级:

this.addChildAt(元素,层级数);

也可以如下面所以获取层级对象:

this.getChildAt(层级数);

事件

在一个h5页面中，难免少不了对事件的一些处理，比如对按钮的点击事件。
项目示例中已经列举了一个demo,如下：

let button = new eui.Button();
button.label = "Click!";
button.horizontalCenter = 0;
button.verticalCenter = 0;
this.addChild(button);
button.addEventListener(egret.TouchEvent.TOUCH_TAP, this.onButtonClick,   this);

至于点击之后要触发的逻辑可以卸载onButtonClick中。这里是引用了eui.Button这个组件，默然可以进行点击。但是不是所有的点击事件只能建立在按钮这种元素上呢，其实不是。例如对于egret.Bitmap类的元素，也可以监听其点击事件，只需要如下设置：

let BitmapObj:egret.Bitmap;
BitmapObj = this.createBitmapByName("button_png");
BitmapObj.touchEnabled = true;  //关键是这个
BitmapObj.addEventListener(egret.TouchEvent.TOUCH_TAP, this.onButtonClick, this);

对于元素是否含有点击事件，可以到官网的对应api查看。

缩放模式和旋转模式

对于这个部分的内容，我还是觉得直接使用一个文档的地址会比较直观一点。

对于不同的项目，可能需要的显示模式也不一样。
对于强制横屏显示的h5可以直接在html中设置data-orientation="landscape"即可

如何实现视频帧播放

轮播

• 加载资源

this.loadGroup('preload'）；

• 获取资源（必须保证资源已经加载完成）

resourceList: Array<RES.ResourceItem> = RES.getGroupByName(groupName);
    this.resourceTextureList = [];
    for (let item of resourceList) {
        this.resourceTextureList.push(RES.getRes(item.name));         
}

上面代码是获取资源的纹理对象，RES.getRes是针对的已经加载完成的资源,没有加载完成会显示为空。获取成功之后并存放在对应数组中。

• 监听进入页面的事件

this.stage.addEventListener(egret.Event.ENTER_FRAME, this.repeatPlaying, this);

• 不断循环

let index = 0;
let bitmap = egret.Bitmap;
this.stage.addChild(bitmap);
index ++;
bitmap.texture = this.resourceTextureList[index];
if(index >= this.resourceTextureList.length){
	index = 0;
}

不断遍历，就会重复播放。

只播一次

对于只播一次的情况，就需要在播放完最后一帧的情况下取消事件的监听即可。

this.stage.removeEventListener(egret.Event.ENTER_FRAME, this.repeatPlaying, this);

如何自定义组件

对于建立了eui项目的文件目录，就会在resource-skins中找到对应的exml文件。如果想自定义一个组件，就需要执行如下步骤：

• 需要自己新建一个exml文件就行，，然后在egret wing中进行绘画视图。如下图所示：

例如对于button控件来说，你可以自定义其他的控件，并且在2中选择需要添加的控件元素，在中间面板进行编辑，然后在 4 区域中进行设置属性（如width,height,x,y等属性），最后在 3 中就会自动生成相应的源码了。

• 在src文件夹中建立相应的ts文件，并且使其继承eui.component,代码如下：

class PopBoxPanel extends eui.Component{
   
    public constructor(orientation:string ,instance:egret.DisplayObjectContainer){
        super();

        this.addEventListener(egret.Event.COMPLETE,this.onCreateComplete,this);
        this.skinName = "resource/skins/PopBox.exml";

    }
    
     private onCreateComplete(event: any){
         this.removeEventListener(egret.Event.COMPLETE,this.onCreateComplete,this); 
       
    }

}

• 在resource-default.thm.json中按照所给格式添加你定义的组件即可

declare module skins{
	class ButtonSkin extends eui.Skin{
	}
}

• 直接仿造已有类库那样进行使用就行。

bug记录点

• 在一些低端android设备中，有些会显示不出来，需要在html中找到这一行：

egret.runEgret({renderMode:"webgl", audioType:0});

将webgl改为canvas即可

• 对于有多个视频帧播放的情况下，会出现播放重叠的情况，这是因为在播放下一个视频帧的时候没有及时取消对上一个视频帧的监听。也就是

this.stage.removeEventListener(egret.Event.ENTER_FRAME, this.repeatPlaying, this);

• 在资源未加载完成就使用RES.getRES()
  需要在资源加载完成之后的回调里面再使用，否则资源会为空。

• ios不能自动播放背景音乐
  需要给当前的stage添加一个事件（如点击事件）来设置其开始播放

• scroller组件滑动默认是可以上下左右滑动，需要设置一个属性值来控制只能在垂直方向进行滑动
  bounces : boolean是否启用回弹，当启用回弹后，ScrollView中内容在到达边界后允许继续拖动，在用户拖动操作结束后，再反弹回边界位置

• 在ios端播放音频会出现下面的问题,如下图所示：

这个egret官方给出的回应是如下：

使用格式工厂。选择 44100Hz，96kbps 转换。

• 音频在android的uc浏览器播放不出声音，需要将音频改成如下格式：

12000hz双声道mp3，比特率20kps

仍在试坑中，后续bug会补上

总结

egret对于一些h5场景还是很使用的。而且文档详尽，上手比较简单。

花一天时间看完了第二部，巨人的陨落II 主要是讲述了发动战争之后的一些事情，战争包括英德两国和俄德两国之间的战争，当然还有作为中立者的美国以及其他国家之间的战争。在这部中，一些主要的主人公都投入到战争当中，其中包括比利・威廉姆斯、格雷戈里・别斯科夫、菲茨赫伯特伯爵以及沃尔特・冯・乌尔里希。在几大国交战的过程中，他们在战争中的英勇表现以及对整个国家的影响牵动着整个故事的紧张发展。

在这部中，一些女主人公也表现出了自己坚强和向往自由的伟大精神，其中典型的就是艾瑟尔・威廉姆斯，虽然被爱的人抛弃，被父母逐出家门，但是她仍然在异国他乡坚强地战胜着一切生活赋予的苦难，不仅生下了可爱的儿子，而且和茉黛・菲茨赫伯特女勋爵一起宣传着解放女性，宣扬女性平等的运动，她们在战乱时期表现出来的那种强大的独立精神让我深深折服。

“最后，她只得忍气吞声，勉强在一向雇佣女性的行业里寻找机会，并发誓有生之年一定要改变这种不公正的制度。”

当她看到了女性受到不平等待遇的时候，在心底就萌发了要为解放女性而奋斗的决心，在那个战乱的时代，有这种觉悟和追求让我简直是不可置信，作为一个单身妈妈，虽然自己还爱着菲茨赫伯特伯爵，但是当她看到菲茨赫伯特伯爵反对英国求和的时候，认定菲茨赫伯特伯爵是一个冷漠自私的人的时候，她毅然决然地坚定了自己不再爱他的立场，这种理性而又有政治立场的态度让我为她着迷。

同样的，格雷戈里・别斯科夫也是我比较喜欢的一个男主人公，父母去世后，仍未成年的他担当着抚养弟弟的重任，甚至在弟弟拿着他的梦想跑掉的时候，他还能一如既往地照顾心仪弟弟的卡捷琳娜和她的孩子，并且从未变过心，在打仗的时候，照顾卡捷琳娜和孩子成为他努力让自己活着的信念。同时，在看到沙皇的暴政的时候，他也是时刻站在苦难群众的立场上，并最终作为领袖成为了推翻沙皇暴政的关键人物。

“格雷戈里仿佛回到了十二年前。他看见冬宫前面的广场上成百上千的男男女女跪在地上祈祷，对面的士兵端着步枪，他母亲躺倒在地，鲜血在雪地上漫开。他耳边回荡着十一岁列夫的惊叫声：“她死了！妈死了，我母亲死了！”

“他在战场上学会了先反击，再悲伤”

这些片段深刻地反映了格雷戈里・别斯科夫至始至终想为底层苦难群众谋福利的信念，因为他从小就是深受沙皇压迫长大的，他不想后一代人重复他苦难的生活，所以他必须带头革命。

于此同时，由于战争沃尔特・冯・乌尔里希和茉黛・菲茨赫伯特女勋爵已经有好长时间未见了，在第一部的时候，两人跨越国籍的爱情故事让我唏嘘不已，但是在第二部中，沃尔特・冯・乌尔里希因为家人介绍的原因，似乎开始移情别恋。

“这番碰触就像一丝温暖的电流。两年来没有任何家人之外的女人碰过他。他突然想到，如果能把莫妮卡搂在怀里，让她温暖的身体贴着自己，吻着她的嘴唇，那该多好啊。她那双琥珀色的眼睛坦诚地回应着他的目光，过了一会儿他才发觉，她一定猜出他在想什么了。”

上面这些细节足以说明沃尔特・冯・乌尔里希在精神上的出轨，这让我再一次怀疑了这世界上是否存在真正坚定的爱情，当爱情遇到了爱情和家庭的阻挠时，曾经的海誓山盟还有效么，男人似乎永远都是在爱情中容易出轨的那一方，哎，我还能说什么呢。。。

从来只是接触到**的暴政和战争，在这次通过阅读这本小说了解到外国在战争和战乱时期的人民生活的时候，让我深刻地明白了一个道理：一旦发生战争，受苦的必定是基层人民群众，但是正是这种暴乱的战争生活孕育了伟人的诞生。

这一部总体感觉还是很好的，相比第一部的背景铺垫，这一部结合战争似乎更加让我陷入其中了，期待第三部的故事情节发展。

想到要看这本书也是一个朋友推荐的，而且之前也恰巧看了东野圭吾的一部小说《嫌疑人x的献身》拍的电影。当时确实被那部电影里面设计的悬疑情节所惊叹。原本以为这本书应该不是悬疑类的推理小说，然而一口气读完后才知道也是。而且是真的一口气读完的，前后用了不到一天的时间，仿佛是一个吸铁石，没读几页就被彻底吸引住了。读完之后有一种震惊和恐怖在心头萦绕。

这部小说主要是写主人公前岛老师在女子高中教书，但他本人对教书无一点兴趣，私下被学生称作“机器”，但由于前岛三次在放学后遭人暗算，内心十分紧张。前岛是射箭社的指导老师，在一次放学后的社团活动结束时，与射箭设社长惠子同学一同前往更衣室时，发现在男更衣室中毒身亡的村桥老师，警方随即展开一系列调查，因为一直遭到暗算，所以前岛老师对此案也十分挂心，并了解到该校麻生老师与村桥老师关系密切，但案子总是并无大的进展。之后猜测出几个嫌疑人，分别是麻生老师和一个问题学生高原阳子，但是仅仅只是怀疑而已，案情并没有水落石出。然而不久后的学校运动会上，原本扮演乞丐的竹井老师提出要与前岛老师更换角色扮演小丑，却不料被小丑的道具酒瓶中的毒水毒死。而这毒刚好与村桥老师所中之毒一样，警方知情后，认为凶手真正的目标可能是前岛。没过几天，前岛又遭到一辆小轿车的撞击，幸好得到学生高原阳子的救助，同时从高原口中听到案件的真正隐情。前岛经过自己的分析与取证，终于找出了杀害那两位老师的凶手，案件已破。可是前岛却仍被暗算，被人所伤，凶手居然是他的妻子。

这部小说其实语言平实，没有很华丽的词藻，基本上行文都是采用对话来开展的。但是情节却设计得极其巧妙，一波三折，悬疑色彩凸显而出。另外，小说中的案情也是在主人公的猜测下不断深入并最终解开谜底。但在案情水落石出的过程中，却让读者一再从已经相信这应该就是事情的真相中醒悟过来：凶手原来另有其人，这事情并非如此简单。最后谁也想不到，凶手竟然是没有毫无嫌疑的惠子和慧美。刚开始的确以为是高原阳子或者麻生老师，甚至还猜测过主人公的妻子裕美子。但是最后一一被否决了。而且案情的线索设计得十分巧妙，以至于需要结合图片还有仔细研读主人公的推理以及联系前后发生的所有蛛丝马迹才能真正领悟出来。最绝的是在真相即将大白的时候，作者故意隐藏主人公内心的一切猜测，最后在主人公和慧子中的谈话中全盘抛出，让读者有一种顿悟和惊叹之感---事情原来是这样的。整本书的结构十分清晰严密，并且暗藏了好几道伏笔，这些伏笔与后面的真相前后呼应，环环相扣，让人咋舌的同时又觉得十分在理。最妙的是，故事最后的真相是在主人公和慧子一边练箭一遍道出的，一边是练箭的紧张动作，一边是案情的紧张和高潮，让读者也在主人公的一问一答中始终保持着紧张的心情，得知真相后又不免后怕，在惊叹情节的曲折的同时又不免为作者的独具匠心而拍案叫好。而且小说的结局也没有完全道破，主人公最后是否生还给读者无尽的想象和猜测，给人一种意犹未尽的感觉。

这部小说的主人公性格较为怯懦，不仅工作上是将就的‘机器’，就连婚姻也是将就的，而且在和学生的关系上也是处理得不是很恰当。书中的凶手的杀人动机是保卫住自己最纯洁的东西。这似乎在情理之中。不过这种阴谋的设计让人不免心生恐惧。小说的主题似乎是在说如何与处于青春期的少女相处，但是也有人说是在表述“当想去珍惜的时候却已来不及”，当然，每个人的想法都不一样，一千个读者就有一千个哈姆雷特。

但是不管怎样，这部小说写得还是很赞的，强烈推荐。

很少涉猎哲学和思辨的书，总觉得是在玩文字游戏而且字里行间随处可见枯燥。这本书确实出乎我意料，不仅文笔优美，又有理有据，结合古今中外的事例，将一种无形而又伟大的孤独感描述得可触可感，真实存在而又不晦涩难懂。让人拍案叫好的同时又不得不心悦诚服。
书中主要讲了6种孤独：

• 情欲孤独
• 语言孤独
• 革命孤独
• 暴力孤独
• 思维孤独
• 伦理孤独

在每一种孤独中，作者不仅阐述着自己的见解、亲身经历，还结合一些名著、现实中的事例加以佐证。原本以为，孤独无非是夜深人静，独自一人，在郁结于心的难受时刻无人倾述的一种可怜。然而读罢全书，才明白我的**过于狭隘了。孤独分为很多种，除此之外，孤独并不意味着寂寞，相反享受孤独的人，才会更加懂得透过自己的灵魂看世界。在现实生活的我们，常常叫嚣着要摆脱孤独，于是将自己置身于闹市、琴瑟和鸣的处境中，然而却发现随之而来的却是更大的孤独感。

孤独并非寂寞孤独和寂寞不一样。寂寞会发慌，孤独则是饱满的，是庄子说的「独与天地精神往来」，是确定生命与宇宙间的对话，已经到了最完美的状态。

伟大的人都是孤独的，如项羽，如屈原，亦如高渐离，这些人用自己的生命诠释着孤独如史诗般绚烂的最高境界。让读者不再猥亵孤独，不是对孤独的人投以同情的一瞥，而是以一种虔诚、仰望的姿态去尊敬他们、敬仰他们。伟大的人都是孤独的，只有在孤独中，他们才能真正知道自己内心深处的诉求并为之追求一生，不惜牺牲自己的生命。

孤独的人注定是要受到争议的，“永远也不要做第一个人和最后一个人”，这句话足以说明现在的人更愿意随波逐流而不是特立独行，不合群的人注定会受到排挤，众口铄金的现实使得我们都随着大流，隐忍着自己内心最真实的追求。于是，在我们活得都想是社会的复制品的时候，我们也就不再是最初的那个自己了。

对于孤独，我们永远排斥，孤独意味着清冷、落寞，于是很多人都去逃避孤独或者去追随其他东西从而来填满自己的孤独感。然而，孤独是自己和自己的一种对话。

有时候你会发现，速度与深远似乎是冲突的，当你可以和自己对话，慢慢地储蓄一种情感、酝酿一种情感时，你便不再孤独；而当你不能这么做时，永远都在孤独的状态，你跑得愈快，孤独追得愈紧，你将不断找寻柏拉图寓言中的另外一半，却总是觉得不对；即使最后终于找到「对的」另外一半，也失去耐心，匆匆就走了。

我更相信，我们心灵一旦不再那么慌张地去乱抓人来填补寂寞，我们会感觉到饱满的喜悦，是狂喜，是一种狂喜。就像气球，被看起来什么都没有的气体充满，整个心灵也因为孤独而鼓胀了起来，此时便能感觉到生命的圆满自足。孤独圆满，思维得以发展。

孤独并不可怕，可怕的是我们从来不愿意给自己留丝毫孤独对话的空间，然而现在快节奏的社会里，越来越多的人宁愿选择和几个陌生人一起尬聊，也不愿意真实地面对自己。

生命里第一个爱恋的对象应该是自己，写诗给自己，与自己对话，在一个空间里安静下来，聆听自己的心跳与呼吸，我相信，这个生命走出去时不会慌张

所以我说孤独是一种福气，怕孤独的人就会寂寞，愈是不想处于孤独的状态，愈是去碰触人然后放弃，反而会错失两千年来你寻寻觅觅的另一半。有时候我会站在忠孝东路边，看着人来人往，觉得城市比沙漠还要荒凉，每个人都靠得那么近，但完全不知彼此的心事，与孤独处在一种完全对立的位置，那是寂寞。

学会享受孤独，才能体会到一种精神食粮的真实存在。

异步在前端中的发展历史不是很长，但是发展的速度还是很快的

什么是异步

所谓异步，简单点说就是在做一件事情的过程中中断去做另外一件事情。js是单线程的，当然也有异步的概念。异步和同步的区别用图示表示如下：

由图示可以得出，同步过程时：业务二必须等待业务一的请求结果返回之后才可以开始，而异步过程中，在业务一的请求过程中，当前线程可以先去处理业务二，免去了等待过程中的时间浪费。

为什么要异步

为什么要引入异步的，异步有下面几点优点：

• cpu利用率高
• 用户体验更好
• 性能更高

从上面图示可以看出，在异步过程中，没有等待数据返回的过程，在请求数据的时候，当前线程又去处理其他业务了，这样就提高了cpu的利用率，cpu的性能必定也会提升。其次，在之前的网站中，我们时常要处理ajax请求，一旦采用同步思路，那么在请求数据返回之前，网页都是一片空白而得不到相应，那样会给用户一种相应很慢的感觉，导致用户体验很差。而异步就使得页面在请求数据的空隙也可以渲染页面，大大提升了用户体验。

异步的发展历程

####callback时代
回调函数是异步发展的起源，最初源自ajax，对于下面的代码，相信每一个FEer都不会感到陌生：

$.ajax('url',function () {
    //do something
})

但是这样的请求一旦嵌套过多，就会出现下面的callbacks hell

asyncOperation1(data1,function (result1) {
    asyncOperation2(data2,function(result2){
        asyncOperation3(data3,function (result3) {
            asyncOperation4(data4,function (result4) {
                //do something
            })
        })
    })
})

这种代码不仅可读性很差，而且在团队中很不好维护。
之后还衍生中一种事件监听事件，比如：

element.addEventListener('click',function(){
//response to user click    
});

也就是click事情的回调函数只在触发了click事件之后才执行，当然了，这也是回调函数的一种变种。

Promise时代

promise，顾名思义，就是承诺，这个承诺有成功初始(pending)（fulfilled）和失败（rejected）三种状态。当由pending->fulfilled状态时，会触发resolved，当由pending->rejected状态时，会触发rejected.具体规范可以参见promise/A+规范。
promise有一个then函数，它返回一个promise对象，就是因为这样，promise才可以实现链式调用。promise的链式调用可以用如下图示表示：

根据promise的概念，上面的回调函数嵌套过深的问题可以写成如下：

asyncOperation1(data)
    .then(function (data1) {
        return asyncOperation2(data1)
    }).then(function(data2){
        return asyncOperation3(data2)
    }).then(function(data3){
    return asyncOperation(data3)
})

generator/yield时代

ES6语法中引入了generator,一个普通的generator函数表示如下：

function* gen(){
    yield 1;
    yield 2;
    return 'ending';
}
var g = gen();
g.next(); //{value:1,done:false}
g.next(); //{value:2,done:false}
g.next(); //{value:ending,done:true}

调用 Generator 函数，会返回一个内部指针 。即执行它不会返回结果，返回的是指针对象。调用指针 gnext 方法，将会指向第一个遇到的 yield 语句，yield的作用是暂停此处，只有调用next函数才会执行下一个yield。每次调用 next 方法，会返回一个对象，表示当前阶段的信息（ value 属性和 done 属性）。value 属性是yield语句后面表达式的值，表示当前阶段的值；done 属性是一个布尔值，表示 Generator 函数是否执行完毕，即是否还有下一个阶段。上面的深度嵌套的例子改写为generator如下：

function* generateOperation(data1) {
    var result1 = yield asyncOperation1(data1);
    var result2 = yield asyncOperation2(result1);
    var result3 = yield asyncOperation3(result2);
    var result4 = yield asyncOperation4(result3);
    //more
}

async/await

ES7出现了async/await,从字面意思就可以看出来代码在执行过程中等待，上面的代码变成async./await形式如下：

async generateOperation(data1) {
    var result1 = await asyncOperation1(data1);
    var result2 = await asyncOperation2(result1);
    var result3 = await asyncOperation3(result2);
    var result4 = await asyncOperation4(result3);
    //more
}

generator和async虽然在形式和代码结构上很相似，但是两者还是有区别的：

• async的语义化更好
• async内置了自动执行器，之前我们说过generator需要手动调用next()方法来执行下一个yield语句，但是async会自动执行内部的异步函数,而generator需要结合co来实现自动执行所有的异步函数
  -async 扩展性更好,generator和co结合时候，要求在yield语句后面是一个thunk函数或者promise，而await后面则可以是任何数据类型，比如String，Number等

又是在一口气的情况下看完这本书的，故事情节很传奇，主要内容主要如下：该书讲述了在僻静街道旁的一家杂货店，只要写下烦恼投进店前门卷帘门的投信口，第二天就会在店后的牛奶箱里得到回答：

• 因男友身患绝症，年轻女孩月兔在爱情与梦想间徘徊；
• 松冈克郎为了音乐梦想离家漂泊，却在现实中寸步难行；
• 少年浩介面临家庭巨变，挣扎在亲情与未来的迷茫中，
• 在酒店工作的女孩寻求未来打算的意见……

他们将困惑写成信投进杂货店，并且得到了回答。而且很巧妙的，解忧杂货店让过去和现在进行相通，致使翔太、敦也、幸平这三个人可以借助现代人的角度来给过去忧愁的人提供一些意见。

整本书的行文思路很奇特，从来没有想过还有这等奇怪的想法，但是东野圭吾似乎用他的这本小说来诠释这种神奇。看完小说后，我唯一的感触就是虽然书中的文本很朴实，没有过多华丽的辞藻，大部分的行文还是一如既往地使用对话，但是故事情节的巧妙让人有点意想不到。而且让我觉得：这个世界上的每一个人的人生，似乎有它既定的方向和结局

“无论你是什么人，懦弱自恋疯狂失意；无论你做着什么工作，白领蓝领灰领，无论你身在何处，只要你相信自己，热情的用心的真诚的活着，那就是成功的；不论你在人生的岔路口怎样选择，真实的面对自己、面对现实，跟随心的脚步，心之所向，那就是你的人生，那就是你的存在。”

正如文中所说，你的人生已经就是这样存在着，仿佛有一种神秘的力量在操纵着这一切，所以无需为自己的人生太过迷茫，每个人都有每个人的宿命。作者通过6个小故事来讲解着及其奇妙的事情。构文思路上很独特，值得一看。

React Hooks 尝鲜

前言

React 在 16.70-alpha 中首次提出 Hooks 这个新特性，并且在 16.8.0 正式发布 Hooks 稳定版本。React Hooks 指的是在 Function Component 中插入一些 Hooks，通过使用这些 Hooks 可以让 Function Component 拥有 state 和生命周期等 React 特性。

为什么会有 React Hooks

React Hooks 要解决的问题是状态逻辑复用，是继 render-props 和 higher-order components 之后的第三种状态共享方案。它主要解决了如下一些痛点：

组件中的状态逻辑难以复用

在一个 React Componet 中，会在 state 中存储状态，并且在组件的各个 lifecycle 函数中执行特有的逻辑，比如在 componentDidMount 去请求数据、在 componentWillUnMount 中卸载实例、取消事件监听器等。这些 state 和 生命周期和组件强耦合，使得 state 和生命函数的逻辑无法抽离得到复用。而 Hooks 可以从组件中提取状态逻辑，从而达到复用。

复杂组件导致的 wrapper hell 和逻辑难以维护

React 的组件带来的好处是模块化，但是当逻辑比较复杂时，就会出现组件嵌套地狱，看看 Devtool 里面的嵌套，是不是有点吓人。
     
                               

除此之外，复杂组件会在不同的生命周期中执行很复杂的逻辑，比如在 componentDidMount 请求数据，或者在 componentWillReceiveProps 中根据 nextProps 改变组件 state 等等，后期维护和理解的成本会非常高。
再加上 class Component 的 this 指向问题，为了保证指向正确，需要用 bind 绑定或者使用箭头函数，如果没有绑定，就会出现各种 bug。

怎么用 React Hooks

首先使用 class Component 来实现一个最简单的组件：

import React, { useState } from 'react';
import { Button } from 'antd';

function Demo() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <Button type="primary" onClick={() => {
        setCount(count => count + 1)
      }}>Add</Button>
      <div className="number">{count}</div>
    </div>
  )
}

代码链接

在上面这个例子中，useState 就是一个 Hook，它接受一个参数作为 state 的初始值，返回一个数组，结构为 [value,setValue]，其中 value 对应的 state，相当于 Class Component 中的 this.state，setValue 是修改 state 的函数，相当于  class Component 中 this.setState。 其他的就按照 Function Component 写就好了，是不是看起来很清爽？

API 介绍

现在介绍一下 React 内置的几种 Hooks 以及它们的用法。

useState

上面的例子就是用的 useState，当然是最简单的用法，总结一下 useState 的特性，如下：

• 首次渲染时，将传入的参数作为 initialState 使用，当再次 render 时，使用最新的值渲染。如果 initialState 的逻辑比较复杂，可以传入一个函数，并返回计算后的初始值，该函数只在初始渲染时才会被调用。

const [complexState, setComplexState] = useState(()=> {
  const initialValue = complexFunction(props);
  return initialValue;
})

• 返回一个 state 和更新 state 的函数，且该函数接受一个新的 state 值
• 多个 state 使用多个 useState，并且 useState 之间相互独立。

function Demo() {
  const [count, setCount] = useState(0);
  const [type, setType] = useState('default')
  const [list, setList] = useState([1])
  ....
}

useEffect

useEffect 是用来执行副作用操作的，通过这个 Hook，可以执行一些组件渲染之后的逻辑，比如事件监听、设置标题等。它相当于是 Class Component 中的 componentDidMount、componentDidUpdate、componentWillUnMount 这三个生命周期的集合。举个最简单的例子，如下：

import React, { useEffect, useState } from 'react';
import axios from 'axios'

function UseEffectDemo() {
  const [list, setList] = useState([]);

  useEffect(() => {

    async function fetchData() {
      const result = await axios('https://hn.algolia.com/api/v1/search?query=react');
      setList(result.data.hits);
    }
    fetchData()

  }, [])

  return <div className="movie-container">
    {list.map(item => {
      return <div className="item">{item.title}</div>
    })}
  </div>
}

代码地址

这个 Hook 的特性如下：

• 组件首次渲染和之后更新的每次渲染都会调用 useEffect。
• 允许传入第二个参数来决定是否执行 effect 里的逻辑，这可以减少一些不必要的性能损耗，如果传入一个 []，则只会在 componentDidMount 和 componentWillUnMount 时期才执行，传入 state，则表示只有当 state 发生改变的时候才触发。如下：

useEffect(() => {
  // do something
}, [type]); // 只有 type 发生改变才执行 useEffect 里面的逻辑

• 在 useEffect 中返回一个函数可以执行一些清理操作，比如取消订阅等，这些逻辑会在前一次 effect 执行之后下一次 effect 执行之前以及 componentWillUnMount 的时候执行。如下：

useEffect(() => {
  //do something
  return function cleanup(){
    //do something clean up
  }
})

useContext

useContext 主要是为了使用 context，而且不用像以前一样用 Provider、Consumer 包裹组件，可以大大提高代码的简洁性。使用 createContext 实现一个简单的例子，如下：

const themeContext = React.createContext('light')

// App 组件
class App extends React.Component {
  state = {
    theme: 'red'
  }

  changeThme = (type) => {
    this.setState({ theme: type })
  }

  render() {
    return (<themeContext.Provider value={this.state.theme}>
      <Button onClick={this.changeThme.bind(this, 'black')}>黑色</Button>
      <Button onClick={this.changeThme.bind(this, 'red')}>红色</Button>
      <Consumer />
    </themeContext.Provider>);
  }
}

// Consumer 组件
class Consumer extends React.Component {
  render() {
    return <themeContext.Consumer>
      {theme => {
        return <div>{theme}</div>
      }}
    </themeContext.Consumer>
  }
}

代码地址

使用 context，就可以避免 props 的多层传递。对上面的例子使用 useContext 进行改造，代码如下：

export const ThemeContext = createContext('light')

// App组件
function UseContextDemo() {
  const [theme, setTheme] = useState('red');

  return (<ThemeContext.Provider value={theme}>
    <Button onClick={() => setTheme('black')}>黑色</Button>
    <Button onClick={() => setTheme('red')}>红色</Button>
    <Consumer />
  </ThemeContext.Provider>);
}

// Consumer 组件
function Consumer() {
  // 直接通过 useContext 获取值即可，不需要使用 Context.Consumer 包裹
  const theme  = useContext(ThemeContext)
  return <div>{theme}</div>
}

代码地址

使用 useContext 可以直接获取值，不需要用 ThemeContext.Consumer 包裹组件。代码看起来更加简洁。

useReducer

useReducer 主要是 useState 的语法糖，主要是针对复杂 state 或者下一个 state 依赖之前 state 的场景，主要有如下特点：

• 和 useState 返回很像，返回 state 和 dispatch 函数
• 接受三个参数，第一个参数是 reducer，类 redux 的 reducer，第二个参数是 initialState，如果你想重置，state，可以传入第三个参数-- init 函数，此时第二个参数作为 init 函数的参数。reducer 的形式如下：

function reducer(state, action) {
  switch (action.type) {
    case "increment":
      return {
        ...state,
        count: count + 1
      };
    default:
      return state;
  }
}

举个🌰如下：

const initialState = { count: 0 }

const init = (initialState) => {
  return initialState;
}

const reducer = (state, action) => {
  switch (action.type) {
    case 'ADD':
      return { ...state, count: state.count + 1 };
      break;
    case 'DEC':
      return { ...state, count: state.count - 1 };
      break;
    case 'RESET':
      return init(action.payload)
    default:
      return state;
  }
}

function UseReducerDemo() {
  const [state, dispatch] = useReducer(reducer, initialState, init)

  return (
    <div>
      <div>Count: {state.count}</div>
      <button onClick={() => dispatch({ type: 'ADD' })}>Add</button>
      <button onClick={() => dispatch({ type: 'DEC' })}>DEC</button>
			// 传入 initialState，进行复位
      <button onClick={() => dispatch({ type: 'RESET', payload: initialState })}>RESET</button>
    </div>
  );
}

代码地址

如上例子所示，定义一个 reduce 函数，接收一个 state 和 action 参数，返回一个新的 state。通过传递 init 初始化函数，可以对 state 进行复位。

useCallback 和 useMemo

在 Class Component 中，我们可以使用 shouldComponentUpdate 来控制组件重新渲染的条件，从而避免复杂逻辑带来性能性能上的损耗，而在 Function Component 中没有 shouldComponentUpdate 这个生命周期，怎么办？useCallback 和 useMemo 就是用来解决这个问题的。
useCallback 和 useMemo 会在组件首次渲染的时候执行，然后会根据依赖项是否发生改变而再次执行，并且这两个 Hook 都返回缓存的值，useCallback 返回缓存的函数，useMemo 返回缓存的变量。
首先举一个🌰，如下：

function UseMemoDemo() {

  const [count, setCount] = useState(1);
  const [value,setValue] = useState('')

  //第一种，没有使用 useMemo
  const computing = () => {
    let sum = 0;
    for(let i=0;i<count*100;i++){
        sum += i;
    }
    console.log(sum, 'computing')
    return sum;
  }

   // 第二种使用 useMemo
   const computing =useMemo( () => {
    let sum = 0;
    for(let i=0;i<count*100;i++){
        sum += i;
    }
    console.log(sum, 'computing')
    return sum;
  },[count])

  return <div>
    <div>Count: {count}</div>
    <div> SUM: {expensive}</div>
    <button onClick={() => setCount(count + 1)}>Add</button>
    <input className="input" onChange={(e)=>setValue(e.target.value)}/>
  </div>
}

代码地址

如上所示：expensive 是计算量很大的函数，并且当 state 发生改变时，组件就会重新渲染，从而导致 computing 函数重新执行，而 computing 只和 count 相关，但是 value 发生改变，computing 还是会重新计算。这是没必要的，所以我们可以使用 useMemo 来控制没必要的执行，第二个参数表示依赖项，只有依赖项发生改变时才会执行。

useCallback 和 useMemo 不同的是，它返回一个缓存的函数，并且 useCallback(fn,deps) = useMemo(()=>fn(),deps)，它有什么作用呢，举一个例子：

function UseCallbackDemo() {
  const [count, setCount] = useState(0);
  const [value, setValue] = useState('')

  // 第一种，没有使用 useCallback
  // const callback = () => {
  //   return count + 1;
  // }
  
  // 第一种，没有使用 useCallback
  const callback = useCallback(() => {
    return count + 1
  }, [count]);
  
  return (<div>
    <div>Parent Count: {count} </div>
    <button onClick={() => { setCount(count + 1) }}>Add</button>
    <input className="input-container" onChange={(e) => { setValue(e.target.value) }} />
    <Child callback={callback} />
  </div>)
}

// Child 组件
function Child(props) {
  const [value, setValue] = useState(0)

  useEffect(() => {
    setValue(props.callback())
  },[props.callback])
  return <div>Child Count: {value}</div>
}

代码地址

如上所示，父组件将 callback 函数传递给子组件，然后子组件在 useEffect 中判断 callback 是否发生改变，从而更新自身的 state，当父组件的 value state 发生改变是，并不会触发 useEffect 的更新操作，所以使用 useCallback 可以避免子组件不必要的重复渲染。

useRef

useRef 相当于是一个存储属性的地方，它在组件的整个生命周期内都保持不变，它的特性如下：

• 接受一个参数，并且作为属性 current 的初始值。
• 比 ref 更有用，可以存储任何可变值。
• 当 ref 的 current 属性变化时，不会触发组件的重新渲染

它的用法如下：

function UseRefDemo() {
  const inputRef = useRef(null)

  const onClick = () => {
    inputRef.current.focus()
  }
  return <div>
    <input ref={inputRef}></input>
    <button onClick={onClick}>Focus</button>
  </div>
}

代码地址

如上，在点击 button 时，设置 inputRef 获取焦点，其中 input 这个实例就保存在 inputRef 中。

useImperativeHandle

useImperativeHandle 用于自定义暴露给父组件的 ref 属性，该 hooks 需要和 forwardRef 一起使用，例子如下：

function UseImperativeHandleDemo() {
  const parentRef = createRef()
  return (<div>
    <Child ref={parentRef} />
    <br />
    <button onClick={() => { parentRef.current.focus() }} >获取焦点</button>
  </div>)
}

//Child 组件
import React, { useRef, useImperativeHandle, forwardRef } from 'react';

const Child = (props, ref) => {
  const inputRef = useRef(null);

  useImperativeHandle(ref, () => ({
    focus: () => {
      inputRef.current.focus();
    }
  }))
  return <input ref={inputRef} />
}
export default forwardRef(Child)

代码地址

如上面所示，父组件可以直接调用在 Child 里面定义的 Ref.current.focus 方法。

useLayoutEffect

useLayoutEffect 和 useEffect 类似，两者不同的地方是：

• useEffect 是被 react-scheduler 调度，异步执行，不会阻塞浏览器的渲染
• useLayoutEffect 在 DOM 变更之后同步执行，比较适用于 DOM 更新后，立刻去执行变更 DOM 副作用的场景，和以往的 componentDidMount 和 componentDidUpdate 的表现一致。

useDebugValue

用户在 react devtools 中显示 hooks 属性，第二个参数可以进行格式化能力，例子如下：

const [date] = useState(new Date());
useDebugValue(date, date => date.toDateString());

自定义 Hooks

除了上面提到的官方已有的 hooks，我们还可以自定义 hooks，通过自定义，可以将组件逻辑提取到可重用的函数中。并且自定义的 hooks 之间也是相互独立的，举个例子：

function CustomHookDemo() {
  const [hoverRef, isHover] = useHover();
  return <div ref={hoverRef}>{isHover ? 'I am hovered' : 'I am not hovered'}</div>
}

//useHover 的 hook
import React, { useState, useRef, useEffect } from 'react';

const useHover = () => {
  const [isHover, setIsHover] = useState(false)
  const ref = useRef(null);

  const handleMouseOver = () => {
    setIsHover(true)
  }
  const handleMouseOut = () => {
    setIsHover(false)
  }
  useEffect(() => {
    const node = ref.current;
    if (node) {
      node.addEventListener('mouseover', handleMouseOver);
      node.addEventListener('mouseout', handleMouseOut);

      return () => {
        node.removeEventListener('mouseover', handleMouseOver);
        node.removeEventListener('mouseout', handleMouseOut);
      };
    }
  }, [ref.current]);

  return [ref, isHover]
}

export default useHover

代码地址

如上所示，我们把 hover 的逻辑抽离到 useHover 这个 hook 中，并且把 hover 的 DOM 实例和 isHover 的值返回，这样其他组件想要这个逻辑就可以直接复用。
自定义 Hooks，需要遵循如下规则：

• 自定义 hook 是一个函数，必须以 use 开头
• 自定义 hook 可以调用官方提供的 Hooks

使用 Hooks 需要注意的点

虽然 Hooks 比较强大，但是在使用过程中，还是有一些点需要注意，比如：

• 只在顶层使用 Hook，不在循环、条件或者嵌套函数中调用 hook
• 只在 React 函数和 自定义 Hooks 中使用，不要在普通 js 中使用 Hooks

本来是来实习了的，并且加上论文的压力，应该是没有时间再看闲书的了。但是由于暂住在华南理工附近，恰巧在华南理工还有同学，于是就借看了这本书。第一次看日本作家写的书，之前也有很多人推荐过我看日本作家的书，但是一直都没有去尝试，这次看完后，确实还是有一种不一样的体会。恰巧前一阵子看了《东京女子图鉴》这部剧，对日本的一些风土人情和生活习性算是有一些概念上的铺垫了。

说实话，这部书并没有什么很深刻的内容，甚至可以说是对生活琐碎的一种碎碎念，再加上及其丰富的心理活动的描写，让我更加觉得这本书像是在对心理剖析的书。但是在细碎中有很真实，让人觉得仿佛书中的主人公就是自己，因为你知道他的所有想法甚至一些腹诽。

书中的主要内容是主人公相木悠介放弃了大学医院医生的工作，然后抛家弃子和情人来到东京开始半医半写作的生活，最后慢慢走上文坛之路，在上京后的一年内，先后和三个女人之间爱恨纠葛的故事。写的大多都是生活的琐事外加很详细的心理展示，说实话，对于这本书的感觉，并没有很深的感触，排除不怎么健康的精神实质，文中情节也是很一般。并没有给我一种很惊叹的感觉。所以对这本书并没有很高的评价。

但是文中还是有些许亮点的。比如说第一章中悠介刚来东京的时候，原本以为脱离了原先那种忙碌的生活，会有更多的时间投入到写作当中，但是最后发现时间总是被一些琐碎的日常给霸占，或者被自己的惰性心理给浪费掉了。

“事实上，辞去大学医院医生工作的一个理由就是想有充足的事件可以写小说。这个愿望现在实现了，可现实却是游手好闲的过着每一天”。

这是他内心挣扎的真实写照。之后又描写到他怀念自己过去的生活。

“人类在习惯新的事物的时候，往往会怀念旧的；在习惯新的生活的时候，往往会怀念过去。当每天规定应做的事情持续不断的时候会觉得厌烦透顶，而当它停止发生的时候，却又眷恋无比”

这一段感慨说得很在理。仿佛有一种很强烈的共鸣。确实，我也是这样，当在学校那种规律的生活过久了之后，那种每天上完课就吃饭，然后睡觉的生活让我觉得无比没劲，然后强烈出来实习，但是当真正出来实习的时候，又特别想回学校。人的心理及其矛盾。我曾经以为是不是只有我才这么纠结，当读到这段的时候仿佛找到了知音一样，或者说证明了似乎不是只有我才这么病态。

文中在写到和几名女子的情感纠葛时，似乎暴露了一位男性血液里真实丑陋的一面：花心。但是他最后也为此付出了代价。

“若把女人比做洋葱，那自己则只是剥开了表层窥探了一下而已，并不是越往里剥越了解女人，也有剥得泪流满面，头晕目眩的时候啊”

这句话却是说得也很经典啊。

总之，这本书很成功地从人物心理入手，通过心里活动来剖析了人物的性格，也很好反应了日本人的一些生活习惯。有兴趣的还是可以看一下的。

从前一本书中看到萧红的前世今生，比较凄惨，恰好之前也看过汤唯演的关于萧红和萧军的电影，很是凄惨，然后一个文学素养很高的同学和我讨论了一下萧红的凄惨生活，而且向我推荐了她的《生死场》，然后才有了这篇读后感。

读完这本书给我的第一感觉就是深深的沉重感，这本书描述了乡村人民的贫苦生活。萧红为人们展示的是一幅旧**东北农村的风俗画，画面中，贫苦无靠的农民背向蓝天，面朝黑土，辛勤操劳，累弯了腰，累跛了腿，还是得不到温饱，受着饥饿和疾病的煎熬，生存十分艰难。其中的女主人公王婆，是一个饱受磨难的妇人，她的第一个丈夫虐待她，抛弃了她和孩子，独自跑进关内去了。她为了生存，不得不嫁给第二个丈夫，这个丈夫却病死了。她又不得不嫁给第三个丈夫赵三。可在她老年的时候，儿子因为反抗官府，被枪毙了，她觉得生活无望，愤而自杀，就在将要埋葬的时候，她又活过来了。另一个贫农家的少女金枝，只有十七岁，梦想着青春和幸福。她还没有过门就怀了孕，受到母亲和同村妇女们冷落和嘲讽。嫁过去之后，丈夫嫌她和刚出生的女儿拖累自己，竟把不满一个月的小金枝活活摔死了。还有一个贫农家的少妇月英，本来是村里最美丽、性情最温和的妇女，因为患了瘫病，成了丈夫的累赘，不给她饭吃，不给她水喝，后来死了。

好惨啊！这幅画中圈定的是呼兰还是别的地方，可以不假思索，但这个“场”是旧**地主的天堂，农民的地狱。读着这些人物，感悟画面中的风俗，思考着人物的命运，心头涌出不尽的忧伤。也为萧红将自己坚强背后的敏感，嬴弱背后的率真，通过笔端将她对“人生荒凉感”与女性的悲剧巧妙地融为一体，由衷地赞叹，我想这样一种对人生痛楚的绝妙稀释，让我感到了“活着”的悲哀。

书中的字里行间里面处处充斥着一种坚强和挣扎的感觉，在这里，人的命是那么卑微，

“母亲一向是这样很爱护女儿 可是当女儿败坏了菜棵 母亲便去爱护菜棵了 ! 农家无论是菜棵 或是一株茅草也要超过人的价值 ”

从这段文字里面，还有一个月大的小金枝被摔死的惨景，种种这些，都暗示着生命在那个年代的卑微。但是他们并没有放弃，他们在生的坚强和死的挣扎里面仍在坚持战斗，在最后，赵三变成了找三爷，他老了，但依然鼓励年轻人起来反抗，去参加革命。还有二里半，他在最后毅然决定去找革命军，他们的精神代表着那个年代人们不屈的一致与反抗日军的斗志和民族气节。

萧红的文字，体现着当时人们悲苦的生活场景，让现今处于幸福生活的我们显得更加幸运。。。。

接触到这本书和白鹿原电视剧，完全归功于我的闺蜜，她强烈推荐这部被誉为秦川史诗的电视剧，一时兴起，我翻出了这本小说。

这本小说主要是以陕西关中地区白鹿原上白鹿村为时代背景，讲述了白鹿两家长达半个多世纪的恩怨纠葛以及当时社会的一些世事变化。以主人公白嘉轩为核心，白嘉轩代表着原上的宗法家族制度和道德伦理，一生为人耿直。他一生娶过7个女人为妻，这也是故事的开头。最终娶了仙草为妻并生下三男一女。作为族长，白嘉轩无疑是具有标榜作用的，无论是为人处世，还是胸襟谋略，他都是以一种以声作则的态势赢得了白鹿村全体乡民的尊重和爱戴。而与白家相对的鹿家，祖先是通过轮勺伺候人而发家致富的，祖人鹿马勺一直希望后代能逃脱这种命运，一旦后人有考上秀才为官的都要到他坟上放铳。然而不幸的是，鹿家子孙鹿子霖却心胸狭隘，有着一身的毛病，这也奠定了鹿家永远不能赢得了白家的命运。

小说一边描述着白鹿原上的一些家常琐事，一边反映着整个社会的态势，比如刚开始清朝皇帝下架，然后废除一些旧习如男人留辫子，女人裹脚，再接着是百灵上学堂，鹿兆鹏参共，鹿兆海参加国民党、百灵参共反映国共两党之间的合作和对立，最后到共产党完全胜利。整本小说以一种朴实无华接地气的手法真实地展现了陕西地区的人们在当时的生活情况和风土人情，他们勤劳朴实，通过自己的双手面朝黄土背朝天，只求农作物丰收日子越过越好，那时候的人们没有太多的欲望，没有浮躁的病态心理，只有一心过日子的满足和殷实。。。

书中有很多让我感动的地方，比如鹿三和白嘉轩主仆之间深厚的，不分你我的感情，犹记得白嘉轩腰被黑娃打弯的时候，为了尊严白嘉轩依然下地干活的时候,鹿三担心他所以一直站在他身边：

“你跟在我旁边我不舒服，你走开去抽你的烟！”鹿三无奈挺住脚步，研究紧紧瞅着渐渐融进霞光里的白嘉轩，还是攥着空烟袋记不起来装烟。

不仅仅是鹿三对白嘉轩关心备至，白嘉轩对鹿三也是没当外人。当鹿三被小娥鬼混缠绕的时候，他开始变得疯癫混沌，儿子白孝义和鹿三儿子兔娃都对他很嫌弃，唯有白嘉轩仍然对鹿三嘘寒问暖，甚至教育他们要改变对鹿三的态度。虽然鹿三是白嘉轩家里的长工，但是白嘉轩从来没有将鹿三当成是雇佣关系的工人，而是任何时候都当成是自己家里的一份子，农作物丰收了先送到鹿三那里，一起做农活，一起闹农民起义，连最后鹿三去世的时候，两人也是喝醉后在一个炕上畅聊到深夜的。。。。

同样让人感动的还有朱先生的两袖清风，他的一生是传奇的，不仅可以占卜未来，而且可以化解灾难。他一生都被人爱戴和尊崇，从来不接受贿赂，宁愿在自己的白鹿书院舞文弄墨，也不愿成为权大势大的大官。即使死了，也是极为简朴，不要棺材，不穿洋装，只带书籍，让人感叹。

小说的内容虽然平凡朴实，但是真实地揭示了一些道理，而这些道理不仅在当时那个时代受用，在以后乃至任何时候都是至理名言：

你看，个个人都是哇哇大哭着来这世上，没听说哪个人落地一声不是哭是笑。咋哩？人都不愿意到世上来，世上大苦情了，不及在天上清净悠闲，天爷就一脚把人蹬下来......既是人到世上来注定要受苦，明白人不论遇见啥样的灾苦都能想得开.....

好好活着！活着就要记住，人生最痛苦最绝望的那一刻是最难熬的一刻，但不是生命结束的最后一刻；熬过去挣过去就会开体验呼唤未来的生活

人行事不在旁人知道不知道，而在自家知道不知道，自家做下好事刻在自家心里，做下瞎事也刻在自家心里，都抹不掉；其实天知道地也知道，既在天上刻在地上，也是抹不掉的。

这些道理虽然简单易懂，但是不是每个人都能深知其中奥秘，唯有经历过，体会过，才会得知其中酸甜苦辣。
整本书极其真实地反映了秦川人民的质朴无华，让我们在领略那个时代的风土人情的同时，也受到了人生的启迪。担当得起秦川史诗这个称号，强推。。。。

process对象是一个global（全局变量），它对于Node.js应用程序始终是可用的，所以在使用时无需使用require()。

对于process部分的API,这里不详细讲，具体可移步这里

node 中的 console.log

js中的console.log和node中的console.log还是有一些区别的。
js中的console.log在一些情况下执行时存在异步情况，根据《你不知道的JavaScript中卷》中的描述：

并没有什么规范或一组需求指定console.* 方法族如何工作——它们并不是JavaScript 正式
的一部分，而是由宿主环境（请参考本书的“类型和语法”部分）添加到JavaScript 中的。因此，不同的浏览器和JavaScript 环境可以按照自己的意愿来实现，有时候这会引起混淆。

尤其要提出的是，在某些条件下，某些浏览器的console.log(..) 并不会把传入的内容立即输出。出现这种情况的主要原因是，在许多程序（不只是JavaScript）中，I/O 是非常低速的阻塞部分。所以，（从页面/UI 的角度来说）浏览器在后台异步处理控制台I/O 能够提高性能，这时用户甚至可能根本意识不到其发生。

下面这种情景不是很常见，但也可能发生，从中（不是从代码本身而是从外部）可以观察到这种情况：
PS:可以试试这个

var a = {
    index: 1
};
// 然后
console.log( a ); // ??
// 再然后
a.index++;

我们通常认为恰好在执行到console.log(..) 语句的时候会看到a 对象的快照，打印出类
似于{ index: 1 } 这样的内容，然后在下一条语句a.index++ 执行时将其修改，这句的执
行会严格在a 的输出之后。

多数情况下，前述代码在开发者工具的控制台中输出的对象表示与期望是一致的。

但是，这段代码运行的时候，浏览器可能会认为需要把控制台I/O 延迟到后台，在这种情况下，等到浏览器控制台输出对象内容时，a.index++ 可能已经执行，因此会显示{ index: 2 }。

到底什么时候控制台I/O 会延迟，甚至是否能够被观察到，这都是游移不定的。

如果在调试的过程中遇到对象在console.log(..) 语句之后被修改，可你却看到了意料之外的结果，要意识到这可能是这种I/O 的异步化造成的。

可见，js中的console.log并不是严格同步或者异步，而是取决于执行环境和I/O之间的异步化。

在node中，console.log的底层实现代码如下：

Console.prototype.log = function log(...args) {
  write(this._ignoreErrors,
        this._stdout,
        util.format.apply(null, args),
        this._stdoutErrorHandler,
        this[kGroupIndent]);
};

底层使用的是process.stdout.write。node中的console.log是同步还是异步的呢，也就是process.stdout.write是同步的还是异步的。官方文档给出的解释是：

写操作是否为同步，取决于连接的是什么流以及操作系统是 Windows 还是 POSIX :

• Files: 同步 在 Windows 和 POSIX 下
• TTYs (Terminals): 异步 在 Windows 下， 同步 在 POSIX 下
• Pipes (and sockets): 同步 在 Windows 下， 异步 在 POSIX 下

process 的 child_process

child_process是node中一个比较重要的模块,众所周知，node有一个一直被人诟病的地方就是“单进程单线程”，但是有了child_process之后，node就可以实现在程序中直接创建子进程，除此之外，子进程和主进程之间还可以进行通信，这样就榨干了cpu的资源，使资源得到了充分地利用。

如何创建一个子进程，创建同步进程：

• child_process.execFileSync(file[, args][, options])
• child_process.execSync(command[, options])
• child_process.spawnSync(command[, args][, options])

创建异步进程：

• child_process.exec(command[, options][, callback])
• child_process.execFile(file[, args][, options][, callback])
• child_process.fork(modulePath[, args][, options])
• child_process.spawn(command[, args][, options])

各个不同的方法之间的关系如下：
exec、execFile、fork都是通过spawn封装而成,由此可见，spawn是最基础的，它只能运行指定的程序，参数需要在列表中列出，但是exec在执行时则衍生出一个shell并在shell上运行。和exec类似的是execFile,但它执行命令，无需衍生出一个shell，所以execFile比exec更加安全，也更高效。fork也是在spawn中封装出来的，专门用于衍生新的Node.js进程，跟 child_process.spawn() 一样返回一个 ChildProcess 对象。 返回的 ChildProcess 会有一个额外的内置的通信通道，它允许消息在父进程和子进程之间来回传递。

详细的可以参见官方文档

孤儿进程和僵尸进程

在unix/linux中，子进程是父进程创建的，子进程的结束和父进程的运行是一个异步过程,即父进程永远无法预测子进程 到底什么时候结束。 当一个 进程完成它的工作终止之后，它的父进程需要调用wait()或者waitpid()系统调用取得子进程的终止状态。

• 孤儿进程：一个父进程退出，而它的一个或多个子进程还在运行，那么那些子进程将成为孤儿进程。孤儿进程将被init进程(进程号为1)所收养，并由init进程对它们完成状态收集工作。init进程会循环wait()它的退出的子进程并进行善后工作，所以孤儿进程并不会带来什么实质性的危害。
• 僵尸进程：一个进程使用fork创建子进程，如果子进程退出，而父进程并没有调用wait或waitpid获取子进程的状态信息，那么子进程的进程描述符仍然保存在系统中。这种进程称之为僵死进程。任何一个子进程(init除外)在exit()之后，并非马上就消失掉，而是留下一个称为僵尸进程(Zombie)的数据结构，等待父进程处理。一旦有很多只处理少量任务的子进程完成任务后就退出，然后父进程又不管子进程的退出，然后就会产生很多的僵死进程，这样会对程序产生一定的危害。

node中 的 cluster

cluster是node内置的一个模块，用于node多核处理,它的工作进程由child_process.fork()方法创建，因此它们可以使用IPC和父进程通信，从而使各进程交替处理连接服务。cluster中创建worker的源码如下：

function createWorkerProcess(id, env) {
  //省略一些代码

  return fork(cluster.settings.exec, cluster.settings.args, {
    env: workerEnv,
    silent: cluster.settings.silent,
    execArgv: execArgv,
    stdio: cluster.settings.stdio,
    gid: cluster.settings.gid,
    uid: cluster.settings.uid
  });
}

而且手动传了一些环境变量的参数值。如下是根据cluster.isMaster标识来fork子进程的代码：

if (cluster.isMaster) {                                    
  for (var i = 0; i < numCPUs; i++) {           
    cluster.fork();                            
  }  
  //master和worker之间的通信     
  cluster.on('fork', function (worker) {
    console.log('[master] ' + 'fork: worker' + worker.id);
  });
	
  cluster.on('online', function (worker) {
	 console.log('[master] ' + 'online: worker' + worker.id);
  });
		
  cluster.on('listening', function (worker, address) {
	 console.log('[master] ' + 'listening: worker' + worker.id + ',pid:' + worker.process.pid + ', Address:' + address.address + ":" + address.port);
  });
	
  cluster.on('disconnect', function (worker) {
    console.log('[master] ' + 'disconnect: worker' + worker.id);
  });
	
  cluster.on('exit', function (worker, code, signal) {
    console.log('[master] ' + 'exit worker' + worker.id + ' died');
  });                                     
                                            
} else {                                               
  http.createServer((req, res) => {            
    res.writeHead(200);                        
    res.end('hello world\n');                  
  }).listen(8000);                             
}                                             
                                               
console.log('hello');  

cluster模块支持两种连接分发模式（将新连接安排给某一工作进程处理）。

第一种方法（也是除Windows外所有平台的默认方法），是循环法。由主进程负责监听端口，接收新连接后再将连接循环分发给工作进程。在分发中使用了一些内置技巧防止工作进程任务过载。

第二种方法是，主进程创建监听socket后发送给感兴趣的工作进程，由工作进程负责直接接收连接。

理论上第二种方法应该是效率最佳的，但在实际情况下，由于操作系统调度机制的难以捉摸，会使分发变得不稳定。我们遇到过这种情况：8个进程中的2个，分担了70%的负载。

总结

这里只是集合一些知识点，结合饿了么前端面试整理了一些自己对这一块不太清楚的知识点，权当笔记用了，以后可以方便回顾~

参考文档：

• 我来回答饿了么大前端的问题（2）
• 孤儿进程和僵尸进程
• Node.js cluster 踩坑小结
• node.js使用cluster实现多进程

花了一天的时间看完这本书。这本书里，萧红给我们描述的是她童年里对呼伦河这个村庄里的种种回忆。有慈祥的祖父，有可怜的团员媳妇，有古怪的有二伯，还有老实的冯歪嘴子。她笔下记录的一切关于这个村庄的，有人性丑陋的一面也有善良的一面，萧红在这里度过了她的童年。

• 第一章主要是讲整个呼兰河村庄的波澜不惊的生活
• 第二章是叙述村庄里面的一些热闹的风俗
• 第三章讲的是她的后花园，在这里她享受着她和祖父以及和大自然的一切美好。
• 第四章描述的是小院里的日常，
• 第五六七章则分别描述的是团员媳妇、有二伯和冯歪嘴子的故事。

童年是萧红过得比较幸福的一段人生时期了。在这里，她的祖父给了她早期的启蒙教育，祖父对她的爱让萧红在悲凉的人生里面寻找到了一丝安慰。小镇的人们过着日复一日年复一年的生活，虽然悲凉，虽然贫穷，但是依然不悲不喜地过着人生的一个个春夏秋冬。在直言不讳地描述着小镇的日常的同时，字里行间又及其明显地透露着封建农民无知愚昧的性情。他们喜欢成为看客，对于周围中发生的人和事，他们喜欢看热闹，即便自己很害怕，也是非要看的。

后三章描述的三个典型的人物也是及其具有震撼力的。比如团员媳妇的惨死。作为一个12岁的童养媳，本该好好享受生活的幸福的美好时光的，却被婆婆虐待，最后因为各种迷信的偏方致死。婆婆毒打她，用针刺她，并且用烧红的烙铁烙她的脚心。最后因为信大神的所谓的偏方，三次用滚烫的热水浇浸团员媳妇，最后惨死的故事。在那个时代，人的生命有如草芥一般。而有二伯古怪的性格则是对坎坷的命运的一种愤怒。当他不小心踢到路边的石块时，总要对着石块说让下次去撞穿着鞋和袜的人。这里看出有二伯是痛恨那些地主阶级的。而冯歪嘴子呢，则作为勤奋老实的代表，即使生活再怎么艰难，还是很乐观坚强地活着。当村里的人一直在对他风言风语的时候，或者他的老婆因为难产而死的时候，他还是照例地过好自己的生活，几年如一日地磨磨。

“他觉得在这个世界上，他一定要生根的。要长得牢牢的。他不管他自己有这份能力没有，他看看别人也都是这样做的，他觉得他也应该这样做”

这句话虽然无奈，但是诠释出了冯歪嘴子面对现实，仍在不断坚持着的品性。而这一点正是难能可贵的地方。

萧红的一生是坎坷的，但是在她的童年回忆里，始终充斥着祖父浓浓的爱，在呼伦河这个小村庄里，她以小孩子的视角，间接披露着小村庄的一切黑暗与美好的地方。人性的冷漠和封建，让人感到窒息，作为读者的我们，也能深深感受到这种悲凉和凄惨。这本书很值得一读。。。

继上一次的koa源码解读，今天来聊一下koa-router。

文件结构及内容关联

从源码文件中可以看到，koa-router只有两个文件，layer.js和router.js,分别定义了Router和Layer两个对象。相对于express的内置路由，koa-router少了一个route对象，使得逻辑更加简单，下面通过一张图来解释Router和Layer对象之间的关系。

正如上图显示，Router对象中有一个stack的成员属性，而stack又是一个由Layer组成的数组，这样就使两者关联起来了。两个对象之间的原型函数函数也列举出来了，比较直观和简单。

运行流程

在我们的项目路由文件中引入koa-router的时候，如下：

const router = require('koa-router')()

然后执行定义如下路由的时候：

router.get('/', async (ctx, next) => {
   await ctx.render('users/index',{
     title:'用户中心'
   })
})

其实首先调用的是router.js/routes这个入口函数。下面为routes函数的源码:

Router.prototype.routes = Router.prototype.middleware = function () {
  var router = this;

  var dispatch = function dispatch(ctx, next) {
    debug('%s %s', ctx.method, ctx.path);

    var path = router.opts.routerPath || ctx.routerPath || ctx.path;
    var matched = router.match(path, ctx.method); //通过path=users/index和method=GET来判断匹配
    var layerChain, layer, i;

    if (ctx.matched) {
      ctx.matched.push.apply(ctx.matched, matched.path);
    } else {
      ctx.matched = matched.path;
    }

    ctx.router = router;

    if (!matched.route) return next();

    var matchedLayers = matched.pathAndMethod
    var mostSpecificLayer = matchedLayers[matchedLayers.length - 1]
    ctx._matchedRoute = mostSpecificLayer.path;
    if (mostSpecificLayer.name) {
      ctx._matchedRouteName = mostSpecificLayer.name;
    }

    layerChain = matchedLayers.reduce(function(memo, layer) {
      memo.push(function(ctx, next) {
        ctx.captures = layer.captures(path, ctx.captures);
        ctx.params = layer.params(path, ctx.captures, ctx.params);
        return next();
      });
      return memo.concat(layer.stack);
    }, []);

    return compose(layerChain)(ctx, next);
  };

  dispatch.router = this;

  return dispatch;
};

其中定义了一个dispatch函数用来处理路由。其中this对象为当前文件定义的路由对象。例如w我的项目文件中定义了一个路由的user.js文件，并且内容如下：

const router = require('koa-router')()

router.prefix('/users')

router.get('/', async (ctx, next) => {
   await ctx.render('users/index',{
     title:'用户中心'
   })
})

router.get('/register/:id', async (ctx, next) => {
    await ctx.render('users/register',{
      title:'用户注册'
    })
})

router.get('/login',async (ctx,next) => {
   await ctx.render('users/login',{
     title:'用户登录'
   })
})

router.get('/setting',async (ctx,next) => {
   await ctx.render('users/setting',{
     title: '用户设置'
   })
})

module.exports = router

那么这个router对象结构如下：

其中method为Router对象构造函数中定义的：

  this.methods = this.opts.methods || [
    'HEAD',
    'OPTIONS',
    'GET',
    'PUT',
    'PATCH',
    'POST',
    'DELETE'
  ];

stack数组就是user.js中定义的四个Layer，接下来就是进行遍历并且匹配。找到可以匹配当前path和method的layer并且放到layerChain中。最后将这个layerChain交由compose去处理，也就是遍历中间件。
值得一提的是，在调用compose之前，会首先给matchedLayers添加一个中间件，具体代码如下：

 layerChain = matchedLayers.reduce(function(memo, layer) {
      memo.push(function(ctx, next) {
        ctx.captures = layer.captures(path, ctx.captures);
        ctx.params = layer.params(path, ctx.captures, ctx.params);
        return next();
      });
      return memo.concat(layer.stack);
    }, []);

这一段代码主要是给先给中间件数组添加一个中间件函数，用于获取路由中的参数并且赋值给ctx中的params。此时传入compose的middleware数组结构如下:

其中function(ctx,next)就是上面我们push进去的函数，然后下面的async (ctx,next) =>{}就是我们传入的中间件函数。

例如，对于下面这种情况:

router.get('/register/:id', async (ctx, next) => {
    await ctx.render('users/register',{
      title:'用户注册'
    })
})

如我们访问127.0.0.1:3001/users/register/id=123就可以得出ctx.params为{id:123}的这个参数对象。
所以koa中首先会给每个路由添加一个获取路由参数的中间件，然后依次处理后面自定义的中间件。

总结一下，正常的路由流程大概是如下图所示：

router.prototype.register()

代码如下：

Router.prototype.register = function (path, methods, middleware, opts) {
  opts = opts || {};

  var router = this;
  var stack = this.stack;

  // support array of paths
  if (Array.isArray(path)) {
    path.forEach(function (p) {
      router.register.call(router, p, methods, middleware, opts);
    });

    return this;
  }

  // create route
  var route = new Layer(path, methods, middleware, {
    end: opts.end === false ? opts.end : true,
    name: opts.name,
    sensitive: opts.sensitive || this.opts.sensitive || false,
    strict: opts.strict || this.opts.strict || false,
    prefix: opts.prefix || this.opts.prefix || "",
    ignoreCaptures: opts.ignoreCaptures
  });

  if (this.opts.prefix) {
    route.setPrefix(this.opts.prefix);
  }
  // add parameter middleware
  Object.keys(this.params).forEach(function (param) {
    route.param(param, this.params[param]);
  }, this);

  stack.push(route);

  return route;
};