随着 互联网的蓬勃发展，并且伴随着产品功能的越来越复杂，对于技术人员来说最大的挑战就是如何在保证业务快速发展的同时，也可保证不断复杂的业务对用户体验的影响，其中对用户来说最重要的体验指标是如何快速、稳定的访问业务网站以及产品功能，既是网站的性能。本系列文章将会从前后端性能指标定义、性能工具使用、产品业务核心性能指标、前后端性能解决方案出发对这个性能优化体系进行完整的阐述。

建议阅读人群：

前端工程师、后端工程师、产品经理

核心性能定义介绍：

由于涉及前后端的性能指标、定义非常多，本文将重点介绍对前后端影响比较大的指标，让大家对性能优化的核心指标有个整体的认识与了解

后端性能定义

CSS3 的 3D 变换

transform 属性

@transfrom 兼容性

IE10，firefox 以及 Opera 支持 @keyframe，而 chrome 和 safari 需要加浅醉-webkit-，IE9 及早期 IE 版本是不支持的，所以这些功能一般是在移动端使用.

一个 demo

这个 div 会沿着 Y 轴旋转 130deg

一个 H5 上的应用场景

实现一个旋转木马的效果，这里列出核心代码，完整的后续放在 github 上

核心是 css 代码

一个 div 作为舞台的

perspective 800px 是一个视角的位置，表示屏幕距离 3d 变化中心点的位置，一般是这个经验值，可以设置大一点，这样你看到的动画什么的就会离你很远。。。。

一个容器

preserve-3d 是透视属性，有了这个用户看到的效果才有空间感，没有的话看到的效果就和 2d 没区别了。

所有卡片给到一个旋转的角度

用模板实现是很方便的一件事情

默认情况下上面所有的卡片效果看起来是旋转了，但是都挤到一起去了，上面的 translateZ 是让每个卡片向它们的正前方平移一个具体的，这样看来才会形成一个类似立体圆柱的效果，也就是旋转木马的效果了

要让它动起来，js 也少不了，在每次滑动结束后触发每个卡片的旋转

CSS3 @keyframe 规则

属性

@keyframe 兼容性

IE10，firefox 以及 Opera 支持 @keyframe，而 chrome 和 safari 需要加浅醉-webkit-，IE9 及早期 IE 版本是不支持的，所以这些功能一般是在移动端使用

一个 demo

该 demo 的作用是使 div 的背景从红色变成绿色，整个动画时间是 5s

一个 H5 上的应用场景

H5 页面分屏的时候，底部一般会有一个小三角上下移动，表示还有一页内容的。
代码如下：

可直接套用运行

最后的最后

在经历上面一番折腾之后，其实最终实现了的是另一种效果，感兴趣的同学可以用手机访问这里，看看第二页的效果。动画没什么特别，主要是变来变去的过程中用到了一些新的东西。

react 是 facebook 推出一个用来构建用户界面的 js 库。官方介绍的三大特性如下：

just the ui

把 react 只当作一个 ui 组件就好，等同于传统 mvc 中的 view。

virtual dom

react 在编程模型和传统 dom 之间添加了一层，称之为虚拟 dom。好处非常多，性能更好，可以在 node 环境下完成渲染（解决 seo 问题），可以更好的用于开发 native apps。

data flow

反应式的单向数据绑定，比传统数据绑定更简单，简单的使用 js 事件触发改变组件状态也可以实现双向绑定的效果。

什么是 angularjs

angularjs 是 google 推出的一个前端 js 框架，面世已有几年时间，非常成熟，目前已经有非常多的第三方模块，基本上可以解决前端工程领域的各方面的问题。网上的资料也非常多，这里就不做过多介绍。

reactjs 和 angularjs

reactjs 是非常纯粹的组件式开发，所有的页面元素均由各大小组件组合而成。再插上虚拟 dom 的翅膀，实现了一处代码多平台执行的效果，关键是这货性能还不错。但是呢，除了组件以外，这货其他什么功能也没有，你需要重新造出所有的缺失的轮子或者选择第三方的轮子。

angularjs 则是一个完整的框架，意味着不需要太多的工作，就可以使用于大部分的业务场景。
简单好用的 module 和依赖注入系统，controller 中定义的数据和事件，service 实现不同组件之间共享数据，filter 处理筛选数据，forms 支持表单和复杂的表单验证，简单的动画模块 animations，强大的 directive 实现指令和指令的嵌套，可以很轻松的实现 reactjs 的组件及组件组合功能。ui 组件有 bootstrap for angular，路由有 ui-router，还有 promise 模块 $q，还有原生的 $resource 模块直接支持标准的 restful 接口，集成的单元测试，等等，哇哇，功能好多的样子，又到但是的环节，话说很多初学者会被很多 angularjs 的名词折磨的晕头转向。。。

如果要拿 reactjs 来开发应用，你还需要做很多额外的工作。而如果使用 angularjs 的话，就可以直接开始工作了。

两者之间其实无法直接拿来比较，毕竟 react 只是 view 的解决方案，而 angularjs 是包含 mv*的完整框架。

抛开跨平台和性能因素，就功能而言，angularjs 已经包含了 reactjs 的功能，只需要一个自定义 directive 加 controller 就可以轻松实现组件效果。

如果是一个大型项目，使用 angularjs 无疑更可靠。强大的功能带来一定的学习成本，但这一切都是值得的。
而使用 react 的话，你首先需要考虑一个问题，数据怎么管理？用哪个 mvc 库？接下来还有一堆问题等着你。

如果只是一个小型项目，那就看心情吧。

再单独说下关于数据的问题，react 还搞出了一个叫做 flux 的概念。简单看了一下 react 的 flux 模型，这不就是个观察者模式嘛。而 angular 至少支持了三种数据共享方式，包括 service，事件，rootScope 直接添加一个 object，可以分别适应各种不同的场景。

我们来看看 react 和 angular 实现组件的方式有什么不一样。。

组件实现

很多人包括我刚看到 jsx 时会想一个问题，我靠，这货是什么玩意？

js 已经有了 coffeescript、typescript 等，以后还有 es6，难道还要学一个这玩意？

还好，除了 jsx 外，我们也可以直接用 js 甚至 coffee 来编写，虽然麻烦了点。

你只要记住，在 react 的世界，jsx 的语法比 js 写起来更方便更容易理解就好了，具体用什么取决于你自己。

第一个组件，hello 系列，先看 react 的实现

看一看 angular 正常的方式：

template.html

controller

再看一看用 angular 式组件，使用 directive

html:

组件组合

react 的组件组合非常简单，使用 React.createElement 方法即可。
例如给上面定义的 HelloMessage 的外层添加一个 div，可以这样写：

angular 也很简单，直接写 html 即可

react 对 dom 的封装都在 React.DOM 命名空间下，而 coffeescipt 支持解构赋值语法，所以用 coffee 的写法也可以媲美 jsx 的语法，例如：

为什么用 react

虽然目前 react 非常之火爆，但说实话，我也不知道在现在环境中用 react 有什么意义。
在使用 angularjs 开发几个项目之后，如果需要转向 react，只有以下几点可能会吸引我：

1. 足够好的性能
2. 跨平台开发的统一体验。这个还得等 react-android 出来后才知道。
3. 兼容其他 js 库，在现有项目中就可以使用

而对于 angularjs，我认为目前 angularjs 已经足够好用了，除了以下几个显著的问题：

1. 性能问题，目前 angularjs 在移动端的性能确实不够，因为它实在太大了。这个问题是最致命的。
2. 只能在 angular 的框架下开发，第三方库要兼容 angular 都需要做一些工作。

对于 angularjs 其他所谓的缺点，其实大多可以解决，只是难易程度不同，例如 SEO/构建等都可以解决。
上手难易程度来说，angularjs 确实比 react 难很多，但这和一个工具是否好用没有关系，例如正则。

网上看到大家都在鼓吹 react 如何如何，又有很多人抛弃了 angular 投向 react 的怀抱。说实话有点吹的太过了。
react 只是让组件式开发和复用更加简单好用，外加逆天的性能，仅此而已。

最后，到底应该用什么，看你的心情吧，我要赶去改 bug 了。。

积木系统上线半年，取得了些成绩，也暴露出不少问题，加上 2.0 版本也准备开动，因此正是时候来个总结反思下。

项目开始之前

系统要解决的问题

产品运营在产品侧来说，是个大事，产品的冲量、用户的活跃等等一大堆指标都靠它了，有人说再好的产品不运营也是个渣渣。于此同时，产品运营对技术岗的同学来说，是无休无止的赶时间点（节假日、网络热点）以及不是很能体现技术含量的重复性的简单页面。

这个矛盾，让产品和技术双方都很沮丧，产品觉得技术不够重视，技术则觉得不应该在重复性的简单的工作上投入过多时间。

好吧，这其实就是积木系统想要解决的问题以及终极目标，让产品同学可以快速发布页面，同时技术同学沉淀组件（积木）来避免重复性工作，如下图：

系统的核心功能

分析了各方的痛点以及诉求之后，系统的核心功能其实和容易理出来：

• 简单易用的、可视化的可编辑页面
• 通用的、简便地组件接入机制

当然除此之外还要有：

• 发布系统，既然是批量的生成页面，也就没必要每次都有测试（首次发布要严格测试）来发布
• 编译系统，类似 grunt ，fis 做的事，发布之前要编译，如果资源合并、CDN 路径替换等等
• 业务管理系统，是的，这个系统不能只为腾讯课堂服务
• 权限系统，不多说
• 响应式，一次配置，多端运行
  ……

开始技术规划之前，我们有必要也必须要分析现有的解决方案，没必要重复轮子。

现有的一些解决方案

传统的后台管理系统（CMS）

不管是产品还是开发，对 CMS 应该都不陌生。

技术开发好前端页面以及后台录入系统，产品在录入系统录入和修改数据让后发布。

这个方案离我们的期望很远：

• 不能可视化的编辑页面
• 页面的路径都不容易变动，而我们的活动则是无穷多个
• 前端代码倒是可以组件化，但也也就停留在代码层面，而不是系统层面

毫不留情的 pass 。

mmrp

这是一个优秀的运营系统，地址 http://mmrp.oa.com/ 。

官方团队这样描述它：

MMRP 全称是 The MultiMedia Release Platform，数字多媒体内容发布系统。
它是一个全新理念的运营需求处理系统，通过 B/S 在线绑定数据及前端代码，录入模块库并通过按需求组合组件，生成网页发布到 CDN 服务器群，旨在推动过渡到工业化时代，避免重复劳动，节省人力资源成本输出价值最大化，同时减少版本风险，缩短研发周期，统一视觉表现。

是的，这是积木系统的前辈，运营系统的先行者。但我们在做深入分析时，也发现了一些缺陷：

• 交互复杂。产品可以在页面拖拽组件，还可以给组件绑定事件（比如 click），多个组件的之间的联动等等等等。这些操作我作为一个开发者在使用的时候都有些云里雾里，不要说产品了。产品在这里的诉求是简单配置，快速发布，绑定 click 事件什么的真的有些夸张了。
• 难以维护和移植。组件和系统是耦合的，这一点很致命。没新增一个组件，系统都要做相应调整，这对于多业务的系统来说是不可介绍的，假如我们的 tapd 也是每新建一个项目就得改下系统……太可怕了！

上面的缺陷，丝毫不影响 mmrp 的光辉，虽然它已经停止维护了，但还是要向它致敬！

积木系统的设计

现有的系统并不能满足刚需，所以，积木系统蓄势待发。
经过团队（imweb）几轮的讨论，架构如下：

可视化和组件化摆到了核心位置，也对应了积木系统的两大核心：系统本身和组件体系。

系统：

• 可视化编辑
• 发布
• 接入各种组件

组件：

• 开发过程和系统无关
• 逻辑和系统无关
• 遵照系统约定

系统不求花哨，但求实用。更多的细节有时间在单独来篇文章，这里就不赘述。

取得的成绩

接入的业务

• 腾讯课堂
• QQ 电影票

发布的活动

总数将近 50 个，其中响应式 30 个。响应式如果走开发流程的话，工作量翻倍。
换算成工作量 (20 + 30 * 2) * 3 = 240 天。这是保守估计，一个活动算了 3d 工作量，同时这也仅仅是算了前端开发，没有算上后台、cgi 、视觉等等。

存在的问题以及 2.0 版特性

问题同样不少，比如接入其他业务还是不够方便、组件与系统联调也不是非常简单，为了解决遇到的问题，让系统更容易接入、开发和移植，积木系统 2.0 已经在规划中！

2.0 的新特性包括但不限于以下几点：

1. 系统和业务分离，业务逻辑以插件的形式接入系统，方便业务接入。
2. 组件开发套件，无需搭建系统来 debug 组件。
3. 更多的表单类型支持，这里的表单是编辑页产品配置表单，包括单选、多选等等常用表单，颜色选择器优化以及能展现复杂数据结构的组件 型表单。
4. 更易定制的、易于业务优化的编译、打包系统。

1. iconfont 简介

什么是 iconfont？正如字面意思，就是图标字体，下面我给大家慢慢道来

web 页面包含什么元素？

• 文字
  • 链接
• 流媒体
  • 视频
  • 音频
• 图片
  • 背景图（大）
  • 插图（中，例如照片集，课程封面等）
  • 图标（小）

在所有包含 ui 的程序架构中，以上不同的 ui 元素在各种环境中都会遭遇到不同的问题，同时也都有与之对应的解决方案
iconfont 就是一个解决【图标】问题的解决方案之一

1.1 图标问题

首先来看一下图标会有什么难题：

• 图标的大小会变，在两种情况下：
  • 每次 ui 改版，那些厌倦一成不变喜欢尝鲜的设计师们总是会淘气地改变图标大小，图标一般是点缀其他事物，例如文字，有时候设计会把某个图标从一段描述文字改成标题的点缀，这时候图标就需要变大
  • 自适应页面，整个页面的大小都在变，难道图标还能独善其身吗？
• 图标会经常换，这点还是那些设计师的问题，他们说不好看要换，作为开发我们还能说什么？
• 图标自身也会变，“来把那个图标改成红色吧，鲜艳点！”，“那个谁，把那个图标的底色改成蓝色吧~”，“…”

背景图和插图一般不会有这些问题，他们偏向于主体内容而不是点缀，一般不会改变。背景图一般是平铺，插图一般也是定宽，所以大小也不怎么需要改变。

1.2 图标解决方案

图标的解决方案有：

• 使用 png 图片，这是最传统的方案，兼容性最好，使用方面基本不会有技术问题。但是它不够方便，主要有以下两个问题：
  • 只要图标稍有改动都必须换新的图片，即使只是换个颜色或者透明度
  • 图标大小改变问题，不管是改图标还是需要自适应。使用大图片会造成两个问题：缩放效率和大图流量浪费加载慢
• 使用 svg 图片可以很好的解决图片大小的问题，但是兼容性是这个解决方案的致命问题，svg 不兼容 IE6~8，svg 不兼容 Android2.3
• css，对于一些简单的图标，比如箭头，叉叉等，可以使用 css 来绘制而成，这也是现在移动端经常使用的方式，毕竟移动端对 css3 兼容性较好，但是利用 css 绘制的图片的问题是不能支持自适应，自适应的 css 会出现小数点，图标本身就是小的，所以当位置相差 1px 看起来都会很明显

1.3 iconfont 解决方案

iconfont 是图标的另一种解决方案，它是把一些简单的图标制作成字体，然后让图标变成和字体一样使用
iconfont 有以下优点：

• 字体是矢量的，所以可以随意改变大小
• 因为它是字体，所以所有字体的 css 都可以使用，比如 font-size，color，background，opacity 等
• iconfont 的制作也很简单，现在有很多线上制作 iconfont 的站点，只要上传 svg 的图标设计稿，就能线上生成 iconfont 字体文件，而且连使用代码都直接生成
• iconfont 没有兼容性问题，IE6，Android2.3 都能够兼容

2. 使用 iconfont

虽然使用 iconfont 没有图片那么简单，但也没有想象中那么难，下面来看看怎么使用 iconfont
首先，你需要制作 iconfont，现在有许多 iconfont 的站点，比如 fontello
我们随便选择一个图标：

然后我们可以自定义字码：

最后我们就可以下载字体文件了：

下载完，解压出来，我们可以看到有 demo，有字体文件，也有使用代码：

可以看到使用代码里面已经把各种兼容性考虑到了：

使用代码也给到，注意使用类名也是可以在站点中自定义的：

另外注意的是，字体文件也是可以内链的，在 fontello-embedded.css 文件里面：

基本上，利用提供的代码，基本我们就可以完全兼容的使用 iconfont，下面介绍移动端使用 iconfont，在移动端只需要如下代码：

在移动端，只需要 truetype 类型

效果如下：

使用 iconfont，我们可以应用许多字体样式，现在我们改变一下样式：

效果如下：

可以发现，改变一个图标的颜色，背景色，大小都是非常方便的一件事

另一方面，当需要改一个图标的时候，我们可以在制作 iconfont 的时候，替换掉一个图标即可，使用的类名和字码都是可以定制的，这样就可以在不用修改业务使用代码的情况下，只需要替换掉内链的字体代码就可以完成替换图标的工作

以上代码经过实机测试，兼容 IOS4，Android2.3
在移动端，iconfont 也可以使用外链形式，这里就不再赘述

3. 小结

在解决图标的问题上，不管是兼容性，灵活性，扩展性，iconfont 都是一个很好的解决方案

3.1 iconfont 优势

• 灵活性，改变图标的颜色，背景色，大小都非常简单
• 兼容性，兼容所有流行的浏览器，不仅 h5 可以使用 iconfont，app 也可以使用 iconfont，关于这方面可以查看其它线上分享
• 扩展性，替换图标很方便，新增图标也非常简单，也不需要考虑图标合并的问题，图片方案需要 css sprite
• 高效性，iconfont 有矢量特性，没有图片缩放的消耗高

• 在使用上字体文件和普通的静态资源一样，既可以外链也可以内链，并且字体文件也可以使用 gzip 压缩
• 在移动端上，可以只使用 truetype 类型，非常灵活小巧
• 现在很多项目已经在使用 iconfont，先不说国外，比如国内，阿里巴巴各个平台（不仅 pc，h5，还有 app）已经全面使用 iconfont，并且阿里巴巴还搭建了一个线上 iconfont 站点，这是一个很完善的站点，上面有阿里几个主要业务的图标资源库，也可以让用户自己制作图标，完善用户自身的图标库，让用户之间可以共享形成生态，同时站点的使用说明也非常完整，从图标设计，iconfont 制作和 iconfont 使用（里面包含了各个平台的使用方法）都有很完善的说明

3.2 iconfont 缺点

• 制作 iconfont 需要 svg 设计稿，对于开发来说没有图片来的方便
• iconfont 有些特有的问题，详情可参考 @font-face and performance，不过许多问题在移动端是不存在的

3.3 结语

总的来说，iconfont 是可以应用的，特别是在移动端，如果不兼容 Android2.3，使用 svg 图片也是可以接受的，实际上制作 iconfont 也是需要 svg 资源的，所以两者其实很类似

另外，阿里巴巴主要业务都已经广泛应用 iconfont，并且还有成熟的线上站点支持，最起码在可行性方面是可以不用过多考虑的，虽然在使用 iconfont 的过程中可能会遇到许多问题，但是鉴于 iconfont 应用广泛的前提下，线上的资源也会非常丰富，应该不需要过多的担心

最后想说，我们业务是可以考虑使用的！如果要应用 iconfont，我们还需要设计们的支持！