算法的时间复杂度和空间复杂度合称为算法的复杂度。

1.时间复杂度

（1）时间频度

一个算法执行所耗费的时间，从理论上是不能算出来的，必须上机运行测试才能知道。但我们不可能也没有必要对每个算法都上机测试，只需知道哪个算法花费的时间多，哪个算法花费的时间少就可以了。并且一个算法花费的时间与算法中语句的执行次数成正比例，哪个算法中语句执行次数多，它花费时间就多。一个算法中的语句执行次数称为语句频度或时间频度。记为T(n)。

（2）时间复杂度

在刚才提到的时间频度中，n称为问题的规模，当n不断变化时，时间频度T(n)也会不断变化。但有时我们想知道它变化时呈现什么规律。为此，我们引入时间复杂度概念。 一般情况下，算法中基本操作重复执行的次数是问题规模n的某个函数，用T(n)表示，若有某个辅助函数f(n),使得当n趋近于无穷大时，T（n)/f(n)的极限值为不等于零的常数，则称f(n)是T(n)的同数量级函数。记作T(n)=Ｏ(f(n)),称Ｏ(f(n)) 为算法的渐进时间复杂度，简称时间复杂度。
时间频度不同，但时间复杂度可能相同。如：T(n)=n2+3n+4与T(n)=4n2+2n+1它们的频度不同，但时间复杂度相同，都为O(n2)。
按数量级递增排列，常见的时间复杂度有：常数阶O(1),对数阶O(log2n),线性阶O(n), 线性对数阶O(nlog2n),平方阶O(n2)，立方阶O(n3),…， k次方阶O(nk),指数阶O(2n)。随着问题规模n的不断增大，上述时间复杂度不断增大，算法的执行效率越低。

（3）最坏时间复杂度和平均时间复杂度

　最坏情况下的时间复杂度称最坏时间复杂度。一般不特别说明，讨论的时间复杂度均是最坏情况下的时间复杂度。 这样做的原因是：最坏情况下的时间复杂度是算法在任何输入实例上运行时间的上界，这就保证了算法的运行时间不会比任何更长。
在最坏情况下的时间复杂度为T(n)=0(n)，它表示对于任何输入实例,该算法的运行时间不可能大于0(n)。 平均时间复杂度是指所有可能的输入实例均以等概率出现的情况下，算法的期望运行时间。
指数阶0(2n)，显然，时间复杂度为指数阶0(2n)的算法效率极低，当n值稍大时就无法应用。

配置项

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80

//处理图片
fis.match('::image', {
 // useHash: true
});
// fis.hook('commonjs')
//
// fis.hook('module', {
//   mode: 'amd' // 模块化支持 amd 规范，适应 require.js
// });
// fis.hook('cmd', {
//   baseUrl: '',//标示模块打包的基础路径
// });
fis.hook('relative');
//让所有文件，都使用相对路径。
fis.match('**', { relative: true })
//处理图片雪碧图  引用图片家 ?__sprite
fis.match('::package', {
  spriter: fis.plugin('csssprites')
})
fis.match('css/*.{css,less,scss}', {
  preprocessor: fis.plugin('autoprefixer', {
    "browsers": ["Android >= 2.1", "iOS >= 4", "ie >= 8", "firefox >= 15"],
    "cascade": true
  })
})
//压缩图片
fis.match('images/*.png', {
    optimizer: fis.plugin('png-compressor', {
      type : 'pngquant'
    })
 });
 fis.hook('commonjs', {
     extList: ['.js', '.coffee', '.es6', '.jsx'],
     umd2commonjs: true
 });
// 压缩js
fis.match('js/*.js', {
  optimizer: fis.plugin('uglify-js'),
  parser: fis.plugin('es6-babel')
});
// 处理sass转换
fis.match('css/*.scss', {
  parser: fis.plugin('node-sass'),
  rExt: '.css'
});
// 所有js, css 加 hash
fis.match('*.{js,css,scss}', {
  useHash: true
});
// 合并文件
fis.match('::package', {
  postpackager: fis.plugin('loader', {
    allInOne: true,
    resourceType: 'commonJs'
  })
});
//
//
// fis.hook('module', {
//   mode: 'amd' // 模块化支持 amd 规范，适应 require.js
// });
// 生产环境
fis.media('production');

脚手架

1

yo react-webpack

目录结构

- cfg
- dist
- node_modules
- src
    - actions
    - components
    - config
    - model
    - routers
    - sources
    - store
    - styles
    - themes
    - utils
    - index.html
    - index.js
    - logo.png
- test
- .babel
- .eslintrc
- .yo-rc.json
- karma.conf.js
- package.json
- server.js
- webpack.config.js

项目路径

https://github.com/SeasonSu/react-antd

写在前面

现在视频业务越来越流行了，播放器也比较多，作为前端工程师如何打造一个属于自己的播放器呢？最快最有效的方式是基于开源播放器深度定制，至于选择哪个开源播放器仁者见仁智者见智，可以参考开源播放器列表选择适合自己业务的播放器。

我们的播放器选择了排名第一的video.js播放器，截至目前该播放器在Github拥有13,991 star, 4,059 fork，流行程度可见一斑。为了让大家更多的了解它，我们细数下优点：

• 免费开源
  这个意味着什么就不多说了，附上项目地址

• 兼容主流浏览器
  在国内的前端开发环境往往需要支持到低级版本的IE浏览器，然后随着Flash的退化，很多公司没有配备Flash开发工程师，video.js提供了流畅的Flash播放器，而且在UI层面做到了和video的效果，实属难得，比如全屏。

• UI自定义
  不管开源项目在UI方面做的如何漂亮，对于各具特色的业务来说都要自定义UI，一个方便简单的自定义方式显得格外重要，更何况它还自带了编译工具，只能用一个”赞“字形容。具体怎么实现的，这里先简单描述下是使用JavaScript（es6）构建对象，通过Less编写样式规则，最后借助Grunt编译。

• 灵活插件机制
  video.js提供一个插件定义的接口，使插件开发简单易行。而且社区论坛也提供了一些好用的插件供开发者使用。附插件列表

• 比较完善的文档
  完善的文档对于一个稳定的开源项目是多么的重要，video.js提供了教程、API文档、插件、示例、论坛等。官方地址

• 项目热度
  开源作者对项目的维护比较积极，提出的问题也能很快给予响应。开发者在使用过程中出现问题算是有一定保障。

查看、添加、提交、删除、找回，重置修改文件

git help # 显示command的help

git show # 显示某次提交的内容 git show $id

git co – # 抛弃工作区修改

git co . # 抛弃工作区修改

git add # 将工作文件修改提交到本地暂存区

git add . # 将所有修改过的工作文件提交暂存区

git rm # 从版本库中删除文件

git rm –cached # 从版本库中删除文件，但不删除文件

git reset # 从暂存区恢复到工作文件

git reset – . # 从暂存区恢复到工作文件

git reset –hard # 恢复最近一次提交过的状态，即放弃上次提交后的所有本次修改

git ci git ci . git ci -a # 将git add, git rm和git ci等操作都合并在一起做　　　　　　　　　　　　　
git ci -am “some comments”

git ci –amend # 修改最后一次提交记录

git revert <$id> # 恢复某次提交的状态，恢复动作本身也创建次提交对象

git revert HEAD # 恢复最后一次提交的状态

MIT协议

MIT协议相对宽松但还是抓住了要点的。此协议允许别人以任何方式使用你的代码同时署名原作者，但原作者不承担代码使用后的风险，当然也没有技术支持的义务。jQuery和Rails就是MIT协议。

Apache协议

如果你的作品中涉及到专利相关。

Apache协议也是个相对宽松与MIT类似的协议，但它简单指明了作品归属者对用户专利上的一些授权（我的理解是软件作品中含有专利，但它授权你可以免费使用）。Apache服务器，SVN还有NuGet等是使用的Apache协议。

GPL协议

如果你在乎作品的传播和别人的修改，希望别人也以相同的协议分享出来。

GPL（V2或V3）是一种版本自由的协议（可以参照copy right来理解，后者是版本保留，那copyleft便是版权自由，或者无版权，但无版权不代表你可以不遵守软件中声明的协议）。此协议要求代码分发者或者以此代码为基础开发出来的衍生作品需要以同样的协议来发布。此协议的版本3与版本2相近，只是多3中加了条对于不支持修改后代码运行的硬件的限制（没太明白此句话的内涵）。

一、一个页面上两个div左右铺满整个浏览器，要保证左边的div一直为100px，右边的div跟随浏览器大小变化（比如浏览器为500，右边div为400，浏览器为900，右边div为800），请写出大概的css代码。

1.使用flex

//html
<div class='box'><div class='left'></div> <div class='right'></div></div>

//css
.box {
    width: 400px;
    height: 100px;
    display: flex;
    flex-direction: row;
    align-items: center;
    border: 1px solid #c3c3c3;
}
.left {
    flex-basis：100px;
    -webkit-flex-basis: 100px;
    // Safari 6.1+ 
    background-color: red;
    height: 100%;
}
.right {
    background-color: blue;
    flex-grow: 1;
}