吃早饭的时候，同事随意问了一句：你知道 CSS 是怎么解析的吗？我一头雾水。对哦，作为前端，每天都在与 CSS 打交道，我竟然忽视了最基本的原理。

一、浏览器渲染

开篇，我们还是不厌其烦的回顾一下浏览器的渲染过程，先上图：

正如上图所展示的，我们浏览器渲染过程分为了两条主线：

其一，HTML Parser 生成的 DOM 树；

其二，CSS Parser 生成的 Style Rules ；

在这之后，DOM 树与 Style Rules 会生成一个新的对象，也就是我们常说的 Render Tree 渲染树，结合 Layout 绘制在屏幕上，从而展现出来。

本文的重点也就集中在第二条分支上，我们来探究一下 CSS 解析原理。

二、Webkit CSS 解析器

浏览器 CSS 模块负责 CSS 脚本解析，并为每个 Element 计算出样式。CSS 模块虽小，但是计算量大，设计不好往往成为浏览器性能的瓶颈。

CSS 模块在实现上有几个特点：CSS 对象众多(颗粒小而多)，计算频繁(为每个 Element 计算样式)。这些特性决定了 webkit 在实现 CSS 引擎上采取的设计，算法。如何高效的计算样式是浏览器内核的重点也是难点。

先来看一张图：

Webkit 使用 Flex 和 Bison 解析生成器从 CSS 语法文件中自动生成解析器。

它们都是将每个 CSS 文件解析为样式表对象，每个对象包含 CSS 规则，CSS 规则对象包含选择器和声明对象，以及其他一些符合 CSS 语法的对象，下图可能会比较明了：

Webkit 使用了自动代码生成工具生成了相应的代码，也就是说词法分析和语法分析这部分代码是自动生成的，而 Webkit 中实现的 CallBack 函数就是在 CSSParser 中。

CSS 的一些解析功能的入口也在此处，它们会调用 lex , parse 等生成代码。相对的，生成代码中需要的 CallBack 也需要在这里实现。

举例来说，现在我们来看其中一个回调函数的实现，createStyleRule(),该函数将在一般性的规则需要被建立的时候调用，代码如下：

CSSRule* CSSParser::createStyleRule(CSSSelector* selector) { CSSStyleRule* rule = 0 if (selector) { rule = new CSSStyleRule(styleElement) m_parsedStyleObjects.append(rule) rule->setSelector(sinkFloatingSelector(selector)) rule->setDeclaration(new CSSMutableStyleDeclaration(rule, parsedProperties, numParsedProperties)) } clearProperties() return rule }

从该函数的实现可以很清楚的看到，解析器达到某条件需要创建一个 CSSStyleRule 的时候将调用该函数，该函数的功能是创建一个 CSSStyleRule ，并将其添加已解析的样式对象列表 m_parsedStyleObjects 中去，这里的对象就是指的 Rule 。

那么如此一来，经过这样一番解析后，作为输入的样式表中的所有 Style Rule 将被转化为 Webkit 的内部模型对象 CSSStyleRule 对象，存储在 m_parsedStyleObjects 中，它是一个 Vector。

但是我们解析所要的结果是什么？

通过调用 CSSStyleSheet 的 parseString 函数，将上述 CSS 解析过程启动，解析完一遍后，把 Rule 都存储在对应的 CSSStyleSheet 对象中；

由于目前规则依然是不易于处理的，还需要将之转换成 CSSRuleSet。也就是将所有的纯样式规则存储在对应的集合当中，这种集合的抽象就是 CSSRuleSet；

CSSRuleSet 提供了一个 addRulesFromSheet 方法，能将 CSSStyleSheet 中的 rule 转换为 CSSRuleSet 中的 rule ；

基于这些个 CSSRuleSet 来决定每个页面中的元素的样式；

这里描述了大致过程，深入阅读可以查看如下链接：

Webkit CSS 引擎分析CSS 样式表解析过程Webkit CSS实现

三、CSS 选择器解析顺序

可能很多同学都知道排版引擎解析 CSS 选择器时是 从右往左 解析，这是为什么呢？

1.HTML 经过解析生成 DOM Tree（这个我们比较熟悉）；而在 CSS 解析完毕后，需要将解析的结果与 DOM Tree 的内容一起进行分析建立一棵 Render Tree，最终用来进行绘图。Render Tree 中的元素（WebKit 中称为「renderers」，Firefox 下为「frames」）与 DOM 元素相对应，但非一一对应：一个 DOM 元素可能会对应多个 renderer，如文本折行后，不同的「行」会成为 render tree 种不同的 renderer。也有的 DOM 元素被 Render Tree 完全无视，比如 display:none 的元素。

2.在建立 Render Tree 时（WebKit 中的「Attachment」过程），浏览器就要为每个 DOM Tree 中的元素根据 CSS 的解析结果（Style Rules）来确定生成怎样的 renderer。对于每个 DOM 元素，必须在所有 Style Rules 中找到符合的 selector 并将对应的规则进行合并。选择器的「解析」实际是在这里执行的，在遍历 DOM Tree 时，从 Style Rules 中去寻找对应的 selector。

3.因为所有样式规则可能数量很大，而且绝大多数不会匹配到当前的 DOM 元素（因为数量很大所以一般会建立规则索引树），所以有一个快速的方法来判断「这个 selector 不匹配当前元素」就是极其重要的。

4.如果正向解析，例如「div div p em」，我们首先就要检查当前元素到 html 的整条路径，找到最上层的 div，再往下找，如果遇到不匹配就必须回到最上层那个 div，往下再去匹配选择器中的第一个 div，回溯若干次才能确定匹配与否，效率很低。

对于上述描述，我们先有个大概的认知。接下来我们来看这样一个例子，参考地址：

<div> <div class="jartto"> <p><span>111 </span></p> <p><span>222 </span></p> <p><span>333 </span></p> <p><span class='yellow'>444 </span></p> </div></div>

CSS 选择器：

div >div.jartto p span.yellow{ color:yellow}

对于上述例子，如果按从左到右的方式进行查找：

1.先找到所有 div 节点；

2.在 div 节点内找到所有的子 div ,并且是 class = “jartto”；

3.然后再依次匹配 p span.yellow 等情况；

4.遇到不匹配的情况，就必须回溯到一开始搜索的 div 或者 p 节点，然后去搜索下个节点，重复这样的过程。

这样的搜索过程对于一个只是匹配很少节点的选择器来说，效率是极低的，因为我们花费了大量的时间在回溯匹配不符合规则的节点。

如果换个思路，我们一开始过滤出跟目标节点最符合的集合出来，再在这个集合进行搜索，大大降低了搜索空间。来看看从右到左来解析选择器：

1.首先就查找到 的元素；

2.紧接着我们判断这些节点中的前兄弟节点是否符合 P 这个规则，这样就又减少了集合的元素，只有符合当前的子规则才会匹配再上一条子规则。

结果显而易见了，众所周知，在 DOM 树中一个元素可能有若干子元素，如果每一个都去判断一下显然性能太差。而一个子元素只有一个父元素，所以找起来非常方便。

试想一下，如果采用从左至右的方式读取 CSS 规则，那么大多数规则读到最后（最右）才会发现是不匹配的，这样会做费时耗能，最后有很多都是无用的；而如果采取从右向左的方式，那么只要发现最右边选择器不匹配，就可以直接舍弃了，避免了许多无效匹配。

浏览器 CSS 匹配核心算法的规则是以从右向左方式匹配节点的。这样做是为了减少无效匹配次数，从而匹配快、性能更优。

深入阅读，请移步：

jQuery 源码解析CSS 选择器从右向左的匹配规则CSS 选择器

四、CSS 语法解析过程

CSS 样式表解析过程中讲解的很细致，这里我们只看 CSS 语法解释器，大致过程如下：

1.先创建 CSSStyleSheet 对象。将 CSSStyleSheet 对象的指针存储到 CSSParser 对象中。

2.CSSParser 识别出一个 simple-selector ，形如 “div” 或者 “.class”。创建一个 CSSParserSelector 对象。

3.CSSParser 识别出一个关系符和另一个 simple-selecotr ，那么修改之前创建的 simple-selecotr, 创建组合关系符。

4.循环第3步直至碰到逗号或者左大括号。

5.如果碰到逗号，那么取出 CSSParser 的 reuse vector，然后将堆栈尾部的 CSSParserSelector 对象弹出存入 Vecotr 中，最后跳转至第2步。如果碰到左大括号，那么跳转至第6步。

6.识别属性名称，将属性名称的 hash 值压入解释器堆栈。

7.识别属性值，创建 CSSParserValue 对象，并将 CSSParserValue 对象存入解释器堆栈。

8.将属性名称和属性值弹出栈，创建 CSSProperty 对象。并将 CSSProperty 对象存入 CSSParser 成员变量m_parsedProperties 中。

9.如果识别处属性名称，那么转至第6步。如果识别右大括号，那么转至第10步。

10.将 reuse vector 从堆栈中弹出，并创建 CSSStyleRule 对象。CSSStyleRule 对象的选择符就是 reuse vector, 样式值就是 CSSParser 的成员变量 m_parsedProperties 。

11.把 CSSStyleRule 添加到 CSSStyleSheet 中。

12.清空 CSSParser 内部缓存结果。

13.如果没有内容了，那么结束。否则跳转值第2步。

五、内联样式如何解析？

通过上文的了解，我们知道，当 CSS Parser 解析完 CSS 脚本后，会生成 CSSStyleSheetList ，他保存在Document 对象上。为了更快的计算样式，必须对这些 CSSStyleSheetList 进行重新组织。

计算样式就是从 CSSStyleSheetList 中找出所有匹配相应元素的 property-value 对。匹配会通过CSSSelector 来验证，同时需要满足层叠规则。将所有的 declaration 中的 property 组织成一个大的数组。数组中的每一项纪录了这个 property 的selector，property 的值，权重（层叠规则）。

可能类似如下的表现：

p >a { color : red background-color:black} a { color : yellow} div { margin : 1px}

重新组织之后的数组数据为(weight我只是表示了他们之间的相对大小，并非实际值。）

selector property weight 1, a color:yellow 1 2, p >a color:red 2 3, p >a background-color:black 2 4, div margin:1px 3

好了，到这里，我们来解决上述问题：

首先，要明确，内敛样式只是 CSS 三种加载方式之一；

其次，浏览器解析分为两个分支，HTML Parser 和 CSS Parser，两个 Parser 各司其职，各尽其责；

最后，不同的 CSS 加载方式产生的 Style rule ，通过权重来确定谁覆盖谁；

到这里就不难理解了，对浏览器来说，内联样式与其他的加载样式方式唯一的区别就是权重不同。

深入了解，请阅读Webkit CSS 引擎分析

六、何谓 computedStyle ？

到这里，你以为完了？Too young too simple, sometimes naive!

浏览器还有一个非常棒的策略，在特定情况下，浏览器会共享 computedStyle，网页中能共享的标签非常多，所以能极大的提升执行效率！如果能共享，那就不需要执行匹配算法了，执行效率自然非常高。

也就是说：如果两个或多个 element 的 computedStyle 不通过计算可以确认他们相等，那么这些 computedStyle 相等的 elements 只会计算一次样式，其余的仅仅共享该 computedStyle 。

那么有哪些规则会共享 computedStyle 呢？

该共享的 element 不能有 id 属性且 CSS 中还有该 id 的 StyleRule，哪怕该 StyleRule 与 Element 不匹配。

tagName 和 class 属性必须一样

mappedAttribute 必须相等

不能使用 sibling selector，譬如：first-child, :last-selector, + selector

不能有 style 属性。哪怕 style 属性相等，他们也不共享

当然，知道了共享 computedStyle 的规则，那么反面我们也就了解了：不会共享 computedStyle 的规则，这里就不展开讨论了。

深入了解，请参考：Webkit CSS 引擎分析 - 高效执行的 CSS 脚本

七、眼见为实

如上图，我们可以看到不同的 CSS 选择器的组合，解析速度也会受到不同的影响，你还会轻视 CSS 解析原理吗？

感兴趣的同学可以参考这里：speed/validity selectors test for frameworks

八、有何收获？

1.使用 id selector 非常的高效。在使用 id selector 的时候需要注意一点：因为 id 是唯一的，所以不需要既指定 id 又指定 tagName：

Badp#id1 {color:red} Good #id1 {color:red}

当然，你非要这么写也没有什么问题，但这会增加 CSS 编译与解析时间，实在是不值当。

2.避免深层次的 node ，譬如：

Bad div >div >div >p {color:red} Good p-class{color:red}

3.慎用 ChildSelector ；

4.不到万不得已，不要使用 attribute selector，如：p[att1=”val1”]。这样的匹配非常慢。更不要这样写：p[id=”id1”]。这样将 id selector 退化成 attribute selector。

Bad p[id="id1"]{color:red} p[class="class1"]{color:red} Good #id1{color:red} .class1{color:red}

5.理解依赖继承，如果某些属性可以继承，那么自然没有必要在写一遍；

6.规范真的很重要，不仅仅是可读性，也许会影响你的页面性能。这里推荐一个CSS 规范，可以参考一下。

更多资源

CSS 解析顺序优先级详细探索简单剖析 CSS 的解析规则

赞

24个金币已到账

金币可兑换现金

立即提现

子宫肌瘤怎么办？告诉你一个调理方法！直达病灶！

webgame程序构成：

三大部分。

第一是数据流程。第二是程序。第三是美术。

其中，数据流程包括了功能。也只有在功能中才能体现数据流程。

数据流程相当的麻烦，后面再讨论。

比如最简单的卖买产品。

要实现这个功能。

那么需要有产品基础表、产品详细表、商店表、背包表。如果扩展性更强，相应的双表是少不不了的。

表的问题都简单了。关键是这个物品有什么用。这样物品的来源，一大堆数据，物品的走向，又是一大堆数据。

最后，这些数据得绕成一个圈。

绕圈是一件困难的事情。特别是功能和道具多了起来的时候。难度是2的n次方。

美术：

UI。简洁漂亮的界面总会有好处。

小图标。道具，地图，装备。一类至少10个吧？大体上百把个是需要的。

程序分5个部分：

服务器定时器。（C语言或自己设定服务器）定时循环执行某一段代码。而这段代码主要是根据数据库的数据进行更新。这个可以找个C语言程序员来做。对于C语言程序员来讲，这个功能是相当的简单。当然，具体的处理数据的判断和操作数据库，需要你自己写。让C语言程序员给你段标准代码就行了。完全支持sql语句的。

功能页面、功能函数。主要就是数据存取，判断，数据走向。

ajax函数。（可选）某些需要伪即时的功能要用到。

javascript函数。（可选）模拟客户端的数据计算。也就是webgame的与时间相关的数据。分为两部分。一部分是真实数据，是由服务器端的定时器计算的。另一部分是只有初始值，客户端显示用的。不需要即时同步，仅仅需要模拟同步就行。

数据库。一大堆基础数据表和详细数据表。基础数据表：比如等级1到等级100的用户的属性初始值。详细数据表：每个用户的具体属性。

二、一个详细的例子。

单纯的讨论数据流程是件痛苦的事情。

讨论程序而不给代码也是比较痛苦。

这里用的是php+mysql的。

那就按一个超简单的webgame的方式来讨论。配上适当的代码。应该有所帮助。不足的地方也请大家指出，对我个人也是帮助。

我们不去考虑游戏的可玩性，数值平衡等等问题。我们先只考虑一个简单例子的实现。

那么一个webgame的基本内容需要些什么呢？

数据库：玩家、地图、城市、建筑、武器、士兵。

功能：登陆、升级、个人战斗、士兵之间的战斗、与城市的战斗、修建建筑、打造武器、买卖道具。

（注意：每一个功能，必然对应1个或多个数据表。上面数据库中所列的只是基础中的基础。）

首先是地图、城市、建筑。

这里认为，地图可以有多张，城市在地图上，建筑在城市内。

地图表

Map :Map_ID ,X坐标, Y坐标,City_ID(城市ID),描述。

其中Map_ID是指地图的id。不是自动编号。一张地图就是一个Map_ID，可以重复。

城市表

City:City_ID,城市名字，城市所有人，城市等级，城市资源，描述。

建筑表

Build:ID，City_ID，建筑名称，建筑等级，建筑功能。

其中，地图表确定城市的位置，城市表确定城市的相关数据以及所有人，建筑表内的多条信息属于某一个城市。

建表后，显示出来。

一个for循环。把地图表整个取出来就ok。

跟普通网站的新闻列表没太大区别。不同的是，你需要取得X坐标和Y坐标定位。可以用tabel也可以用div。

class Map//地图类

{

var $Map_ID

function Map_bg_css($Map_ID) {

$this->Map_ID = $Map_ID

mysql_select_db($db_name,$link)

$sql=”select * from map where Map_ID=’”.$this->Map_ID.”‘ limit 1″

$result=mysql_query($sql,$link)

echo “<style type=”.”text”.”/”.”css>”

$rs=mysql_fetch_array($result)

echo “#map{”

echo “position:absolute”

echo “width:”.$rs[X坐标].”px”

echo “height:”.$rs[Y坐标].”px”

echo “z-index:0”

echo “left:0pxtop:0px}”

}

function Map_bg($Map_ID){

$this->Map_ID = $Map_ID

$sql=”select * from map where Map_ID=’”.$this->Map_ID.”‘”

$result=mysql_query($sql,$link)

while($rs=mysql_fetch_array($result))

{

echo “<div id=Layer_bg_”.$rs[X坐标].”_”.$rs[Y坐标].”>”

echo “<img src=”.$rs[Map_bg].” border=0 title=”.$rs[ID].”></div>”

}

}

}

上面是一个很简单的地图类。代码可能不太正确，意思是正确的。就是根据map表中的坐标，生成了一组div层，以及这一组层的css。

你可以改为table的。你可以也把坐标放到一个字段里，用数组的形式取。

使用的时候，用

new map

map(N)

其中N是map表里的地图Map_ID.

城市内的建筑也类似。如果要显示出来的话。

有了地图和城市后。

涉及到的问题就是城市里资源的产生。

这时候，City表里需要有可供判断的时间和数量的字段。

比如：产生资金量Money,产生资金花费的时间Action_Time,上次产生资金时间Money_time。

这两个字段的数值应该在City_base表里出现。（即城市基础表，不同等级，不同类型城市的对应数值。这是给策划填数据用的，建好表后就等策划去头痛吧。如果你身兼数职。。。）

如何自动产生资源呢？

我们可以在城市所有人改变的时候，写入一个时间。或者在城市初始化的时候写入一个时间。

$Now_Time=date(’Y-m-d H:i:s’)

(说明：$开头是变量的意思。php里特有的。如果是asp的话可以写成。Now_Time=Now() )

把$Now_Time写入到Money_time里。

update(”UPDATE City SET Money_time=’$Now_Time WHERE City_ID=’$City_ID’ LIMIT 1”)

$City_ID是你自己定义的。指某一个城市。如：$City_ID=1

我们假定当前城市产生资金量为100。即$Money=100；（具体的数值，应该是由City_base表里取出的。）

假设间隔时间为$Action_Time,我们再假定是每小时执行一次。即$Action_Time=3600；（具体的数值，是根据你的初始化表里取得的。也可以根据城市等级或者用户等级取得。反正随便你自己怎么设定。）

这时候，有基础时间了。有基础资金产量了。有间隔时间了。

让它循环执行起来就行了。

上面说过，服务端用C语言定时器。客户端用javascript。

服务端，资源定时器设定为5分钟执行一次。那么我们的误差就是5分钟。对网页游戏来说，可以接受。（战斗的定时器得1分钟吧。当然服务器够牛的话，几秒钟都可以。）

每次执行什么代码呢？

首先得新建一个定时器任务的表。目的就是让定时器知道需要执行哪些程序和数据的更新。表内容比如：城市资源更新。当然，这个表可要可不要。建立的好处是方便处理类似保护状态不产生资源之类的问题。

服务端程序：

获得当前服务器时间。

获得当前需要更新城市。

判断服务器时间与$Money_time的时间差。（时间戳，具体的时间戳网上资料满多的。）

判断时间差是否大于$Action_Time。

大于，则更新资源。同时更新$Money_time。

小于，则无操作。

客户端程序：

获得当前服务器时间。

获得当前城市的$Money,$Money_time,$Action_Time。

使用javascript显示剩余时间的倒计时，以及增加的资源量。

客户端特殊情况触发：

因为客户端显示的资源情况是伪同步，所以当客户端使用该资源的时候。需要服务端将当前的实际资源更新，属于定时器处理的时间也需要更新。

即，当客户端触发涉及资源的情况时，立即更新当前资源。同时更新定时器中会用到的$Money_time。这样才不会造成，看的资源用不到，或者定时器重复产生资源。

总体来说。这部分程序都很简单。难点在C语言定时器的制作，以及前台javascipt倒计时的写法上。

C语言定时器，找个C语言程序员，超简单；前台的javascipt，网上有很多倒计时的代码，找个来改改就能用。

<SCRIPT LANGUAGE=”JavaScript”>

var maxtime = 这里是你的时间差///一个小时，按秒计算，自己调整!

function CountDown(){

if(maxtime>=0){

minutes = Math.floor(maxtime/60)

seconds = Math.floor(maxtime%60)

msg = “你的文字说明”+minutes+”分”+seconds+”秒”//动态显示剩余时间。

document.all["timer"].innerHTML=msg

//if(maxtime == 3) document.all["timer"].innerHTML=’只剩3秒！’

–maxtime

}

else{

clearInterval(timer)

document.all["timer"].innerHTML=’时间到’

}

}

timer = setInterval(”CountDown()”,1000)

</SCRIPT>

<div id=timer></div>

这个是网上找的代码。稍微修改就可以用的。这里只是显示了倒计时。也可以改为显示资源的增加情况。

C语言里操作mysql数据库。

// TODO: Add your control notification handler code here

bool bRes = m_dbConn.Connect(”数据库ip地址”, 3306 , “用户名”, “[email=d203!@#ghj]密码[/email]“, “数据库名”)

if(!bRes)

{

AfxMessageBox(”connect fail”)

return

}

string strSql = “select * from city limit 1″//所有显示或取值类的都用这段。中间的sql语句可以自己构造。

ResultSet* rs = m_dbConn.ExecuteQuery(strSql)

while(rs->Next())

{

string str = rs->GetString(”username”)

AfxMessageBox(str.c_str())

}

/*

strSql = “update city set money=money +100 where City_ID=’xxx’”//所有的增加、删除、更新都用这段，中间的sql语句可以自己构造。

bRes = m_dbConn.ExecuteUpdate(strSql)

if(!bRes)

{

AfxMessageBox(”ExecuteUpdate fail”)

}

*/

m_dbConn.Close()

定时器的主函数。

void CBeiLiDlg::Go()

{

while(true)

{

// AfxMessageBox(”go”)

Sleep(5*1000)//毫秒。定时器刷新时间。

}

}

//相当的简单..。

当然。这里的C的代码不能直接用。只是一部分。

地图、城市、基本上算是有了。

接下来是城市里的建筑。

上面讲的资源增加，其实定位在建筑上更准确。不过建筑的分类和数值会复杂很多。那是策划考虑的问题。

建筑上，只讲一个前台的修建效果。

当然，这个效果是可有可无。你可以直接给个类似新闻列表的显示，再加个倒计时就行。

显示的效果就是，点修建后。不刷新页面，调入一张动画图片。并在时间到后自动转换为其他图片。

<script language=’javascript’>

function xiujian()

{

top.abc.document.getElementById(’前台建筑位置所在图片的id’).src=’修建后建筑的图片地址’

//显示修建后的建筑图片。可以加上后台时间判断。其中abc，是建筑所在层的id，

}

function xiujian1()

{

setTimeout(’xiujian()’,5000)//动画时间5秒。这里也可以加入时间判断。当时间不到的完成的时候，继续调用动画。

}

function donghua()

{

top.abc.document.getElementById(’前台建筑位置所在图片的id’).src=’建筑动画所在的地址’//显示修建动画。

}

donghua()

xiujian1()

</script>

后台部分，把时间到增加资源的代码改为时间到增加或更新建筑就行了。又是增加N个表。。

建筑基础表：产出，类型，图片等等。。

建筑详细表：属于哪个城市，可以在城市表里关联。关联的方式不同会对程序有很大的影响。各种关联方式都行，但是一旦关联方式确定后，最好别改动。

现在建筑也有了。用类似的定时方式，打工，征兵等等都可以实现。

战斗，

兵的参数：兵种，数量，攻击，防御等等。

战斗的临时表：谁的兵，打谁，出发时间，战斗时间，战斗结果。

这里的几个字到是简单。实际的表会复杂一些。

webgame中，战斗的过程分两种，

一种是给出双方参数，时间到，就根据公式计算结果。

一种是半即时或者即时的战斗，可以边打边喝药边用技能的那种。

第一种流程。

点出兵。这时候，兵的参数，出发时间，到达时间，都记录进战斗临时表。

定时器中，处理战斗的部分，判断时间是否到开打的时候。到开打的时间了，则取得被攻击方的兵的参数。然后通过几个公式计算结果。处理结果，比如谁的兵挂了多少，战场掉落了多少钱，城市被谁抢到了。一大堆判断以及updata。（这里的定时器处理和获得资源的定时器处理是很类似的。）

最后把结果分别发给双方。（又涉及到一个短信息系统。）

第二种流程。

点攻击。马上就处理数据。打打npc好做。玩家之间对战，也可以把被攻击的玩家当成npc来处理。

两个人或两人以上即时战斗。需要用到ajax了。目前在技术上和理论上是没问题的，还没实际写代码，所以不好讲。

很简单的公式，两种战斗都可以用到：

intval(sqrt($User_B_AP)-sqrt($User_A_DP))

根号下攻击-根号下防御=伤害。