散漫主义

调试游戏程序的学问

亦寒 — Thu, 05 Jan 2012 21:01:03 +0800

调试游戏程序，和调试任何其它软件的代码一样，都可能是一项艰巨的任务。一般说来，有经验的程序员能迅速地识别并纠正哪怕是最难的bug，但是对于新手而言，改bug可能更像是一件难以处理的，并且容易使人灰心丧气的任务。更糟的是，当你初步着手开始寻找bug的根源时，永远也不会知道究竟要花费多长时间才能找到。此时不必慌张，要像个训练有素的程序员，集中精力寻找bug。一旦你消化了本文介绍的技巧和知识，你将能够击退最“凶猛”的bug，重获对游戏的控制。

运用本文描述的五步调试法，困难的调试过程也可能变得简单一些。训练有素地运用该方法，将确保你花费最少的时间在寻找和定位每一个bug上。在你着手对付一些有难度的bug时，牢记一些专家技巧也很重要，因此本文也收集了一些有价值的、经过时间考验的技巧。然后本文还列出了一些有难度的调试情境，解释了当遇到一些特定的bug模式时应当做些什么。因为好的工具对于调试任何游戏都很重要，本文还将讨论一些特定的工具，你可将这些工具嵌入你的游戏中，从而帮助调试一些游戏编程所独有的调试情形。最后让我们回顾一些在前期预防bug的简单技术。

1.1.1 五步调试法
老练的程序员们具有一种超能力，能够迅速地、驾轻就熟地捕捉到即使是最不可思议的bug。他们总是神奇地、近乎直觉地知道错误源自何方，这一点实在令人敬畏。他们之所以显得天才，除了因为拥有丰富的经验外，还因为他们对于勘探和减少需排查的可能的原因的方法训练有素、融会贯通。下面给出的五步调试法旨在重现他们所熟练掌握的技能，助你在跟踪bug的问题上形成一种有系统的、且注意力集中的风格。

1.1.2 第一步：始终如一地重现问题
不论是什么bug，重要的是，你应当了解如何能够始终如一地重现它。

试图纠正一个随机出现的bug常会使人感到挫败，而且通常不过是浪费时间。事实是，几乎所有的bug都会在特定的情境下可靠地重现，因此发现这个情景和规律就成为你的、或贵公司测试部同仁的工作。

让我们举一个假想的游戏bug为例，在测试员报告里写道：“有时候，游戏会在玩家杀死敌人时死机（Crash）。”不幸地，像这样的bug报告太过于含糊，而且由于这个问题看上去不是百分之百会出现的，多数时候玩家仍可以正常地摧毁敌人。因此当游戏crash时，必然还有一些其它相关因素。

对于不容易重现的bug，理想情形是创建一系列“重现步骤（Repro Steps）”，说明每次应怎样才能重现bug。例如，下面的步骤极大地改善了之前的bug报告。

重现步骤：

1．开始单人游戏。

2．选择在第44号地图上进行Skirmish也就是多人练习模式的游戏。

3．找到敌人营地。

4．在一定的距离开外，使用投射类武器（Projectile Weapon）攻击在营地里的敌人。

5．结果：90％的时候游戏死机。

显然，重现步骤是一种很好的方法，测试人员藉此帮助其他人重现bug。不过，精简可能导致bug发生的事件链（Chain of Events）的过程也是至关重要的，其原因有三。第一：对当时bug为何发生提供了有价值的线索。第二：提供了一种比较系统地测试bug是否已被彻底改正的方法。第三：可用于回归测试，确保bug不再卷土重来。

尽管这里的信息没有告诉我们bug的直接诱因，它使我们能够始终重现bug。一旦你确定了bug发生的环境，你就可以进行下一步骤，开始搜集有用的线索。

1.1.3 第二步：搜集线索
现在你能够可靠地使bug重现，下一步请你戴上侦探的鸭舌帽并搜集线索。每条蛛丝马迹都是排除一个可能的原因并缩短疑点列表的机会。有了足够的线索，bug的发源地会变得明显。因此为了明了每条线索并理解其潜台词，付出的努力是值得的。

不过有一点要注意，你应当总是在心里质疑每一条已发现的线索，是不是误导的，或不正确的。举例来说，我们被告知某个bug总发生在爆炸之后。尽管这可能是一条非常重要的线索，但它仍然可能是一个虚假的误导。时刻准备着放弃那些与收集来的信息冲突的线索。

还是以上面的bug报告为例，我们了解到游戏的crash发生在玩家使用投射类武器攻击某个特定的敌人营地的时候。究竟关于投射类武器和从远处攻击这两者，有什么特别之处？这是需要深思的重点，但也不要耗费太多时间思考。亲临其境，观察错误究竟是如何发生的，因为我们需要获取更多的确凿的证据，而留连于表面的线索是获得实际证据最不有效的方式。

在本例中，当我们进入游戏，并实际观察错误的发生时，我们会发现游戏死机发生在一个“箭”对象里，错误的症状是一个无效指针。进一步的检查显示，该指针本来是应当指向那个发射此箭的角色的。在此情况下，这支箭原本要向其发射者报告它击中了某个敌人，使发射者为该次成功的攻击获得一定的经验值。但尽管看上去找到了原因所在，我们对真实的潜原因仍然一无所知。我们必须首先找出是什么扰乱了这个指针。

1.1.4 第三步：查明错误的源头
当你认为收集到的线索已经够多时，就到了专注于搜索和查明错误的源头的时候了。有两个主要方法，第一个方法是先提出关于bug发生原因的假设，接着对该假设进行验证（或证明它不正确）；第二个方法是较为系统的分而治之的方法。

方法1：假设法
搜集了足够的线索，你会开始怀疑有些什么事情导致了bug发生。这就是你的假设（Hypothesis）。当你能够在心里清楚地陈述这假设，你就可以开始设计一些能验证该假设，或反证证明该假设不正确的测试用例。

在我们的例子里，通过测试得出了以下线索和关于游戏设计的信息：

· 当一支箭射出的时候，该箭被赋予一个指向射箭人的指针。

· 当一支箭射中某个敌人的时候，将奖励送给射箭人。

· 游戏死机发生在一支箭试图通过一个无效指针向射箭人传回奖励。

我们的第一个假设可能是这样，指针的值在箭的飞行途中被损坏。基于此种假设，我们开始设计测试，并搜集数据来支持或推翻此原因。例如我们可以让每一支箭都将射箭人的指针注册到同一个备份区域。当我们又捕捉到crash时，可以检查备份下来的数据，看无效指针的值是否与这支箭在被射出的时候所赋予的值相同。

不幸的是在我们所举的例子里，最后发现这条假设是不正确的。备份的指针和导致游戏死机的指针具有相同的值。这样一来，我们就面临着一个抉择。是再提一个假设并进行验证，还是重头寻找更多的线索？现在让我们试着再提一条假设。

如果箭的发射人指针从没有被破坏（新线索），或许从箭射出到箭射中敌人的这段时间里，这个发射人被删除了。为了检查这点，让我们记录下敌人营地里死亡的每个角色的指针。当crash发生时，我们可以将出错指针和死亡并从内存中删除的敌人的列表进行比较。这样进行，很快就证实原因正是如此。射箭人死时，箭还在飞行途中。

方法2：分治法
两个假设使我们找出了bug，同时也表现了分而治之的概念。我们知道指针的值无效，但我们不知道它是因为值被修改过而损坏，或者这个指针在更早些的时候就已经无效。通过测试第一个假设，我们排除了两个可能性中的一个。像歇洛克·福尔摩斯（Sherlock Holmes）曾说过的：“……当你排除了不可能的情况后，其余的情况，尽管多么不可能，却必定是真实的。”[译注：绿玉皇冠案（柯南·道尔）]

有人将分而治之的方法简单形容为确定故障发生的时刻，并从输入开始回溯而发现错误。比如有一个并不会造成死机的bug，在某个时刻发生的初始错误将影响层层传递，最终导致故障发生。确定初始错误通常通过在所有输入分支上设置（有条件或无条件的）断点（Breakpoint）来进行，直到找到那个不能正常输出——也就是导致bug的输入。

当从故障发生的时刻开始回溯，你在局部变量和栈里面的上级函数中寻找任何异常。对于死机bug来说，通常你会试图寻找一个空值（NULL）或极大的数字值。如果是关于浮点数的bug，在栈上寻找NAN或极大的数字。

无论是对问题进行有根据的推测，检验假设，还是有系统地搜捕肇事代码，最终你会找到问题所在。在这个过程中你要相信自己，并保持清醒。本文接下来的部分将详细讨论一些可用于在这步骤中的专门技术。

1.1.5 第四步：纠正问题
当我们发现bug的真正根源，接下来要做的便是提出和实现一个解决方案。无论如何，修改必须对项目所处的阶段是恰当的。例如，在开发的后期，通常不能只为了纠正一个bug，就修改底部的数据结构或程序体系结构。参照开发工作所处的阶段，主程序员或系统架构师将决定应当进行何种类型的修改。在关键的时刻，个别工程师（初级或中级）常常做出不好的决定，因为他们没有全盘考虑。

此外需要特别注意的是，理想情况下，代码的编写者应当负责修改自己代码里的bug。不过如果必须修改别人的代码，你至少应当在进行修改前和原作者进行讨论。讨论将使你了解一些方面，例如在以往对于类似的问题是怎么处理的，如果实施你的方案提议可能会造成什么影响等。总之，在未彻底理解由别人编写的代码的上下文前，急于进行修改是非常危险的。

继续讨论我们的例子，死机源于一个指向了一个不复存在的对象的无效指针。对此类问题模式的一个好的解决方案是使用一层间接引用，使crash不再发生。通常，正是因为这个理由，游戏使用对象的句柄而不是直接指针。这将是一个合理的修改。

但是，如果游戏项目因为某个里程碑、或一个重要的演示版交付日迫在眉睫，而需要快速完成修改，你可能会倾向于对现有的特殊情况实现一个较为直接的修改方案（例如让射箭者在自身被删除的时候使其射出的箭中关于自身的指针失效）。如果在程序里打上了这一类的快速补丁（Quick Hack），你要记得将有关的注释文档化，以使其在这截止期限后被重新评估。开发中这样的情况屡见不鲜：快速补丁被人们遗忘，而在几个月后才造成了难于发现和解决的麻烦。

虽然看上去我们发现了bug并且确定了一种修改（使用句柄而非指针），探索其他可能造成同样问题出现的途径是很关键的。这虽然需要额外的时间，但是为了确保bug从根本上被消灭，而非只是消除了bug的一种表现形式，这努力是值得的。在我们的例子中，可能其他类型的投射类武器同样会造成游戏死机，但其它非武器对象的关系、甚至角色之间的关系也会受到同一个设计缺陷的影响。应找出所有这些相关的场合，使你的修改方案针对的是问题的核心，而非仅仅是问题的某一种征兆。

1.1.6 第五步：对所作的修改进行测试
解决方案实施后，还必须进行测试以确认它的确修补了错误。第一步要确保先前有效的重现步骤不会导致bug重现。通常应当让bug修改者以外的其他人，例如测试员，独立地确认bug被修复与否。

第二步还要确保没有新的bug被引入游戏。你应当让游戏运行一段可观的时间，确保所作的修改没有影响其它部分。这是非常重要的，因为很多时候，尤其是在项目开发周期接近尾声的时候，为修改bug所作的改动，会导致其他系统出错。在项目的后期，你还应当让主程序员或其他开发者来检视每一个修改，这额外的可靠性检验要保证新的修改不会对版本有负面影响。

1.1.7 高级调试技巧
如果你遵循以上所述的基本调试步骤，你应能找到并修复大多数bug。不过在你尝试提出假设、验证/否决一个候选的原因、或者尝试找出出错位置的时候，或许你会愿意考虑下列的技巧。

分析你的假设
调试程序的时候要保持心胸开阔是很重要的，而且不要作太多假设。如果你假设某些貌似简单的东西总是正确的，你可能就过早地缩小了搜索范围，从而完全错过了找出真相的机会。举例来说，不要总是想当然地认为你正在使用最新的软件或程序库。检验你的假设是否正确常常是值得的。

将交互和干扰最小化
有时，多个系统之间会以某种方式交互，这会使调试复杂化。试试看关闭那些你认为和问题无关的子系统（例如，关闭声音子系统），从而将系统之间的交互降到最低限度。有时候这有助于识别问题，因为原因可能就在你关闭的系统中，这样你就知道接下来该看那里。

将随机性最小化
通常，bug之所以难于重现，要归咎于从帧速率和实际随机数等方面引入的可变性。如果你的游戏没有采取固定的帧速率，试试看将“在每帧内流逝的时间”锁定为常量。至于随机数，可以关闭随机数发生器，或给它固定的常数作为随机发生种子，这样每次运行都会得到同样的序列。不幸地是，玩家会给游戏带来无法控制的显著的随机性。如果连这玩家带来的随机性也必须得到控制，请考虑将玩家的输入记录下来，从而能以可预料的方式将输入记录直接送入游戏［Dawson01］。

将复杂的计算拆分成几步进行
若某行代码含有大量计算，或许将这行拆分为多个步骤会有助于识别问题。例如，可能其中的某小段计算产生了类型转换错误，或某个函数并未返回你期望它返回的值，或运算进行的顺序并不是你所想的那样。这也使你能够检查每一步中间过程的计算。

检查边界条件
几乎我们中的每一个人都曾被经典的“差一错误”（Off-by-one）问题折磨过。要检查算法的边界条件，特别是在循环结构中。

分解并行计算
如果你怀疑程序里的竞争条件（Race Condition，不同的执行顺序会产生不同的结果），试试看将代码改写为串行的，然后检查bug是否消失。在线程中，增加额外的延迟，观察是否问题也随之变化。问题范围能缩小——若你能够确定问题是竞争条件，并通过试验将问题孤立出来。

充分利用调试器提供的工具
明白和懂得如何使用条件断点、内存watch、寄存器watch、栈，以及汇编级/混合调试。工具能帮你寻找线索和确凿的证据，这是识别bug的关键。

检查新近改动的代码
调试也可以通过源代码版本控制来进行，这真是一个令人惊讶的方法。如果你清楚地记得在某个日期前程序还是工作的，但是从某天开始就失灵了，你就可以专注于期间改动过的代码，从而较快地找到引入缺陷的代码段。至少，也可以将搜索范围缩小至某个特定子系统，或某几个文件。

另一个利用版本控制的方法是生成游戏在bug出现之前的一个版本。当你看不清问题的时候这尤其有用。将新老版本分别在调试器中运行，将值互相比较，你就可能找出问题的关键所在。

向其他人解释bug
常常在你向他人解释bug的时候，你会追忆起一些步骤，并意识到一些遗漏或忘记检查的地方。与其他的程序员交流的益处还在于他们可能会精辟地提出别样的值得检验的假设。不要低估和他人交谈的作用，也永远不要羞于寻求他人的建议。你团队中的同事是你的伙伴，也是你与最有难度的bug战斗时最精良的武器之一。

和同事一起调试
这通常是很合算的，因为每个人在对付bug上都有自己的独门经验和策略。你也能学到新的技术，学会从从未尝试过的角度入手处理bug。让某人看着你进行调试，这可能是追捕bug最有效的方法之一。

暂时放下问题
有的时候，你已经如此接近问题，以至于无法再清楚全面地看待它。试试看改变一下环境，出门闲逛一下。当你放松，再回到问题上，你可能会有新的认识。有时候，当你决定让自己休息一下时，你的心里下意识地还在思考问题，过后答案就自然浮现了。

寻求外部的帮助
获得帮助有多种很好的途径。如果是在开发视频游戏，那么每家游戏机制造商都有一整班的人，他们将在你遇到麻烦的时候协助你。了解他们的联系方式。三大游戏机制造商现在都提供电话支持、电子邮件支持、和开发者互相帮助的新闻讨论组。

1.1.8 困难的调试情景和模式
消灭bug常有模式可循。在艰苦的调试情景中，模式是关键。在此经验起了很大作用。如果你曾经见过某个模式，你就可能迅速地找出bug所在。希望下列情景和模式能给你一些方向。

Bug仅在发布版里出现，调试版则正常
通常，Bug只出现于发布版（Release Build）中意味着这是数据未初始化，或与代码优化有关的bug。一般来说，即使你没有特地编写进行初始化的代码，调试版（Debug Build）也会自动将变量初始化为零。而这隐式初始化在发布版中是不存在的，因而出现了bug。

找出原因的另一个策略是：在调试版里，慢慢地逐一打开优化开关。对每一点优化都进行测试，你可以找到罪魁祸首。例如，在调试版里，函数一般都不是内联的。但在优化后有些函数自动进行了内联，有时某个bug就这样发作了。

还有一点值得注意的是，在发布版中也可以打开调试符号（Debug Symbol）。这使得在一定程度上（虽然一般并不）对优化过的代码进行调试成为可能，你甚至可以让一部分调试系统保持开启。举例来说，你可以让你的异常处理函数在崩溃的现场执行一个全面的堆栈回溯（这需要符号）。这是非常有用的，因为当测试员必须运行优化过的游戏版本的时候，你还是可以回溯程序崩溃。

在作了一些无害的改动后，bug不见了
如果bug在一些完全无关的改动（例如添加了一行无害的代码）后不见了，那么这就像是一个时序问题，或内存覆盖问题。尽管表面上bug已经消失了，但是实际上可能只是转移到了代码的另一个部分。不要错过这个找出bug的机会。Bug就在那儿，将来迟早有一天它肯定会不知不觉地、狡猾地害你。

确实具有间歇性的问题
像前面提过的那样，许多问题会在合适的环境下稳定地重现。但如果你无法控制环境，那就必须要趁问题抬起它丑陋的小脑袋时抓住问题。这里的关键是在捕捉到问题的时候要记下尽可能多的信息，以便随后可在必要时检查。机会可不是很多的，因此要充分利用每一次出错的机会。还有一个有效的技巧就是将程序出错时收集得到的数据和程序正常时收集的数据进行比较，发现其中差异。

无法解释的行为
有时当你在单步执行代码的时候，却发现变量自说自话地被修改了。这种真正怪异的现象通常表示系统或调试器失去了同步。解决方案是试试看“加快清除缓存的频率”，使系统重获同步。

感谢Scott Bilas为清除缓存归纳出如下的“四重”方针。

· 重试（Retry）：清除游戏的当前状态再运行。

· 重建（Rebuild）：删除已编译过的中间对象，并进行彻底的版本重建。

· 重启（Reboot）：通过硬复位，将你机器里的内存擦除。

· 重装（Reinstall）：通过重装，恢复你的工具和操作系统中的文件和设置。

在这“四重”里，“重建”是最重要的。有时候，编译器不能正确地识别代码间的依赖关系，导致受牵连的代码不能通过编译。症状常常是不可思议的怪异。一次彻底的重建有时就能解决问题。

处理这些无法解释的行为的时候，一定要预先猜测调试器会给出何种结果。通过printf函数输出并检验变量的实际值，因为调试器有时候会被迷惑，而无法准确地反映真实的值。

编译器内部错误
偶尔你会碰到这种情况，编译器承认它无法理解你的代码，从而抛出一个编译器内部错误（Internal Compiler Error）。这些错误可能显示在代码中存在合法性问题，也可能根本是编译器软件自身的问题（例如，超出了内存上限，或无法处理你如同天书一般的模板代码）。遇到编译器内部错误的时候，建议执行如下步骤：

1．进行完整的版本重建。

2．重启电脑，再进行一次完整的版本重建。

3．检查是否正在使用最新版本的编译器。

4．检查任何正在使用的库是否是最新版本。

5．试验同样的代码是否能在其他电脑上通过编译。

如果这些步骤不能解决问题，试试确定究竟是那段代码引起了错误。如果可能的话，用分治法减少编译到的代码，直至编译器内部错误消失。当故障的位置已经确定后，检视这段代码并保证它看上去没错（最好能多请几个人读它）。如果代码看上去的确合理，下一步试着重新组织一下代码，希望编译器能报告出更有意义的错误信息。最后你还可以尝试用旧版本的编译器来编译。很可能在最新版的编译器里存在bug，而使用旧版本的编译器就能顺利完成编译。

如果这些办法都不奏效，试试看在网上搜索相似的问题。如果还是没有用，向编译器的制造商寻求额外的帮助。

当你怀疑问题不是出在自己的代码里
不象话，应该总是怀疑自己的代码！不过，如果你确信不是你们的代码的问题，最好的行动方针是到网站上寻找所使用的函数库或编译器的更新补丁。详细阅读其readme文件，或者在网上搜索关于此函数库或编译器的已知问题。很多时候，其他的人也碰到了相似的问题，解决办法或补丁也已经有了。

不过，你发现的bug来自他人提供的函数库，或来自有故障的硬件（碰巧你是第一个发现它的人）的几率不大。虽然不太可能，但有时还是会发生的。最快解决方法是编写一小段例程将问题隔离开来。然后你可以把这段程序email给函数库的作者，或硬件生产商，以便他们进一步就此问题进行调查。如果这真是其他人造成的bug，由于你的帮助，他人可以快速地识别和重现问题，从而bug以最快速度得到改正。

1.1.9 理解底层系统
有时为了找到一些难度很高的bug，你必须了解底层系统。仅仅通晓C或C++还远远不够。为了成为一个优秀的程序员，你必须懂得编译器是如何实现较高层次的概念，必须懂汇编语言，还必须了解硬件的细节（尤其是对游戏机游戏开发而言）。虽然认为高级语言掩盖了所有的复杂性并没有错，但是事实是当系统崩溃时你会感觉手足无措，除非你的理解深刻至抽象以下。若要进一步讨论高层抽象会如何造成隐患，请参见“The Law of Leaky Abstractions”［Spolsky02］。

那么，有哪些底层细节需要了解呢？就游戏而言，你应当了解如下事项：

· 了解编译器实现代码的原理。熟悉继承、虚函数调用、调用约定、异常是如何实现的。懂得编译器如何分配内存和处理内存对齐。

· 了解你所使用的硬件的细节。例如，懂得与某个特定硬件的高速缓存有关的问题（缓存中的数据何时会和主存储器中不同）、内存对齐的限制、字节顺序（Endianness，高位还是低位字节在前）、栈的大小、类型的大小（如整型int、长整型long、布尔型bool）。

· 了解汇编语言的工作原理，能够阅读汇编代码。这在调试器无法跟踪源代码时，例如在优化后的版本里查找问题时，很有帮助。

如不能牢牢掌握这些知识，在对付真正困难的bug的时候，你的致命弱点就会暴露出来。所以必须理解底层的系统，熟悉其规则。

1.1.10 增加有助于调试的基础设施
没有合适的工具的帮助，在真空中调试程序必定会很费劲。解决办法是走另一个极端，直接将好的调试工具整合到游戏里。下列工具能极大地帮助修理bug。

允许在运行中修改游戏变量
调试和重现bug时，在运行中修改游戏变量的值的功能是非常有用的。实现此功能的经典界面是通过游戏中的一个调试命令行接口（CLI，Command-Line Interface）用键盘修改变量。按下某个键后，调试信息覆盖显示在游戏屏幕上，提示你用键盘进行输入。例如，当你想把游戏里的天气改成狂风暴雨，你可以在提示下输入“weather stormy”。此类界面在调节和检查变量的值或特定游戏状态的时候也很好用。

可视化的AI诊断
在调试中，好的工具是无价之宝，而标准调试器在诊断AI问题的时候总是那么力不从心。各种调试器虽然在某个具体时刻能给出很好的深度，但在解答AI系统怎样随着游戏进行而变化这个问题上完全无用。解决办法是在游戏里直接构造能够监控任意角色的诊断数据的可视化版本。通过将文字和3D线条组合起来，一些重要的AI系统如寻路（Pathfinding）、警觉边界（Awareness Boundaries）、当前目标等，会较容易跟踪和查错［Tozour02］［Laming03］。

日志的能力
通常，我们在游戏里有成堆的角色彼此交互和通讯，以得到非常复杂的行为。当交互失败，bug出现之时，关键在于能够记录导致bug的每个角色的个别状态及事件。通过对每个角色创建单独的日志，将带有时戳的关键事件记录下来，我们就可能通过检查日志来发现错误［Rabin00a］［Rabin02］。

记录和回放的能力
像前面提到的那样，找出bug的关键在于可重现性。极致的可重现性需要通过记录和回放玩家的输入来实现［Dawson01］。对于那些概率很小的死机bug，记录和回放是找出确切原因的关键工具。但是为了支持记录和回放，你必须让游戏的行为是可预料的，也就是说对于同样的初始状态，同样的玩家输入必定会得到同样的输出结果。这并不意味着你的游戏对玩家来说是可以预知的，只是意味着你应当小心处理随机数的产生［Lecky-Thompson00］［Freeman-Hargis03］、初始状态、输入等方面，并能在程序崩溃时将输入序列保存下来［Dawson99］。

跟踪存储分配事件
这样实现你的存储分配算子，使其对每次分配操作都进行全面的栈跟踪。通过不断地记录究竟是谁在申请内存，你将不再有内存泄漏问题需要解决。

崩溃时打印出尽可能多的信息
“事后调试（Post-mortem Debug）”是很重要的。程序崩溃时，理想的情况下，你会希望能够捕捉到调用堆栈、寄存器以及所有其它可能相关的状态信息。这些信息可以显示在屏幕上，写入某个文件，或自动发送至开发者的电子信箱。这一类的工具让你迅速找出崩溃的源头，只消几分钟而不是几个小时。尤其是当故障发生在美工或策划同仁的机器上，而他们并不记得是怎样触发这次崩溃的时候。

对整个团队进行培训
虽然这并非一个能够编程实现的结构，但是你应当确定团队正确使用你创建的工具。请他们不要忽视错误对话框，确信他们知道怎样搜集信息从而不会丢失已找到的bug等等。花时间来培训测试员、美工、策划是值得的。

1.1.11 预防bug
关于调试的讨论，若没有一段文字指导如何在第一时间避免bug，便不能算完整。遵照这些指导方针，你或可避免编写出有bug的代码，或可在偶然之间发现自己不知不觉写出来的bug。不论是什么结果，都会最后帮你排除bug。

将编译器的警告级别（Warning level）调到最高，并指示将警告当作错误处理（Enable warnings as errors）。首先尽可能多地排除警告，最后才用#pragma将剩下的警告关闭掉。有时，自动类型转换及其它一些警告级的问题会带来潜在的bug。

使你的游戏能在多个编译器上编译通过。如果你确保游戏用多个编译器、面向多个平台都能编译通过，不同的编译器之间在警告和错误方面的差异将保证你的代码总体上更可靠。例如，编写任天堂GameCube?游戏机上的程序的人也可以在Win32下生成一个功能稍弱的版本。这也使你能够判断某个bug是否是具体平台所特有的。

编写你自己的内存管理器。这对于游戏机游戏是至关重要的。你必须清楚地知道正在使用那几块内存，并对内存上溢进行保护。由于内存溢出会带来一些最难查处的bug，首先确保不发生溢出是很重要的。在调试版本中使用预留的上溢和下溢保护内存块能使bug更早地暴露身份。对PC开发者来说，编写自己的内存管理器不是必须的，因为VC++里的内存系统功能已经很强了，而且还有像SmartHeap之类的好工具可以用来确定内存错误。

用assert来检验假设。在函数的开头加上assert来检验关于参数的假设（例如指针非空或范围检查）。另外，如果switch语句的default情况不应该被执行到，在其中加上assert。还有，标准assert可以被扩展以得到更好的调试性能［Rabin00b］。例如，让assert将调用堆栈打印出来是很有用的。

总是在声明变量的时候初始化它们。如果你无法在声明某个变量时赋予它一个有意义的值，那么就给它赋一个将来一眼就能认出它有没有被初始化过的容易辨认的值。有时候我们会用0xDEADBEEF、0xCDCDCDCD，或直接使用零。

总是将循环体和if语句体用花括号（{}）括起来。也就是将你所想的代码老老实实地包起来，使代码所实现的功能更直观。

变量起名要容易区分彼此。例如，m_objectITime和m_objectJTime看上去几乎一模一样。此类问题的典型例子是把“i”和“j”用作循环计数变量。“i”和“j”看上去很相似，你很容易把其中一个误认为另一个。可供选择的方法是，你可以用“i”和“k”，或者干脆使用更能描述其意义的名字。更多有关变量命名的认知差异的信息可以在［McConnell93］中找到。

避免在多处重复同样的代码。一模一样的代码同时出现在几个不同的地方，这是不利的。如果对其中一处代码作了改动，其余几个地方不一定也会被改动。如果看上去重复代码是必要的，重新考虑一下其核心功能，尽量将大多数的代码集中到一处。

避免使用那些中固定写死的“神奇数”（Magic numbers）。当单独一个数字出现在代码中，其意义可能是完全不为人知的。如果没有写注释，就无法让人理解之所以选择这个数字的理由，及这个数字代表什么。如果必须使用神奇数，将它们声明为有字面意义的常量或define。

测试的时候要注意代码覆盖率。在编写完一段代码之后，应验证它的每一个分支都能正确地执行。若其中一个分支从未被执行过，那么很可能其中正潜伏着bug。在测试不同分支的过程中你可能会发现这样一个bug，即其中某个分支是根本不可能被执行到的。这样的bug越早发现就越好。

1.1.12 结论
本文向你介绍了有效率地调试游戏所需的工具。调试有时候被形容为一门艺术，但那只是由于人们越有经验就做得越好。当你把五步调试法融会贯通，又学会了识别bug模式，并将自己的调试工具集成到游戏中，再形成自己在调试上的个人风格和绝招，很快地，你将熟练地有系统地追捕到并且消灭最困难的bug。最后再加上一点预防，我想你的游戏开发会一帆风顺，一个bug都没有也说不定。

1.1.13 致谢
感谢Scott Bilas和Jack Matthews，他们提了极好的建议，并为本文贡献了一些个人经验和智慧。人们看待调试有各自的角度，因此他们的意见在推敲本文建议的时候起了非常大的作用。

作者：Steve Rabin, Nintendo of America Inc.

邮箱：steve@aiwisdom.com

译者：沙鹰

校对：万太平

兔子跳铃铛的极致

程序员的本质

亦寒 — Tue, 03 Jan 2012 22:48:06 +0800

Computers are useless. They can only give you answers. – Picasso
计算机没有什么作用。他们只能告诉你答案。——毕加索

很多人（包括我岳母）认为计算机变得如此智能，所以在不久的未来将不再需要程序员。另外一些人认为程序员是天才，他们在电脑前能不断地解决复杂的数学难题。甚至不少程序员对他们是做什么的都没有清晰的概念。

在这篇文章中，我想给不知情的人解释一下程序员到底是做什么的：

程序员是将人类想法翻译成计算机语言的译者。

他们是两种世界之间的纽带。你认为维护这个纽带很容易吗？

人类世界的背景

The problem with people is that they’re only human. – Bill Watterson
人类的问题是，他们只是人而已。——比尔·沃特森

人类是生物进化的产物，并且拥有独特而宝贵的器官——大脑，它能为程序员提供想法。大脑有组合复杂的新大脑皮层（对人类而言是独特的），还有从哺乳动物和爬行动物继承的旧结构。旧的大脑结构主要负责生殖（性）和生存（寻找食物或者躲避危险）。新大脑皮层进化成能够更好地支持这些功能，但是，它开始产生奇怪的副作用——意识、思考和好奇心。幸亏这些副作用的影响，人类产生了文明并在数千年后发明了计算机。

一些人相信经过数千年的发展，人类应该变成完全沉闷的、理性的、可预测的生物，但是这并没有发生。人类旧的大脑结构、复杂的心理和社会行为往往使人们不理性，不可预测并带有欺骗性。并且，人类有糟糕的记忆力、强烈的情感和个人兴趣。但是，程序员没法选择与更理性的物种工作，他们不得不与人类共事并且把人类的想法翻译成计算机语言。

计算机世界背景

Part of the inhumanity of the computer is that, once it is competently programmed and working smoothly, it is completely honest. – Isaac Asimov
计算机非人性的一部分表现是，一旦完成编译并且顺利运行，它将忠实地完成工作。——艾萨克·阿西莫夫

计算机是人类文明的最佳发明。它由CPU、主板、内存、硬盘驱动器、显示器和其他部分构成。计算机将我们的文明推入一个新的水平，使我们的生活更有意义并充满乐趣，还弥补了我们大脑的缺陷。很可能计算机比人类更聪明。（不过，我有点关心如果这成为现实后，计算机还需要人类程序员吗？）

现代计算机具有完全逻辑性、直接性和顺从性。如果你知道它应该做什么并且知道如何命令它，那么和计算机一起工作是快乐的。唯一的问题是，计算机只会做你告诉它去做的。因此，你应该有清晰的思路并且在见你的上司或客户时保证计算机不出岔子。

在人类和计算机之间的翻译

翻译中会遇到三个主要的挑战：

1. 语言歧义。人类语言是模糊、复杂并且双关的，例如：“这个程序不能提供良好的用户体验”。文化、背景和上下文语境都会对沟通和含义造成影响。与之相反，所有计算机语言都是准确、直接的，与上下文无关。
2. 细节层次。人类的沟通是笼统而不带有过多细节的，例如：“我想让这该死的程序运行起来”。这样可以节省时间与精力，但由于缺少详细信息，会产生两个比较大的问题——误解和不确定性。而计算机需要所有细节——每件事都要说清楚。
3. 思维模式。人类习惯于思考需求、结果与解决方案之间的关系，例如：“这份报告应该在2秒内运行，而不是2个小时”。然而，计算机需要算法——按照步骤去达到想要得到的结果。

为了写出优秀的软件，程序员们必须克服这些困难，理解人们的想法并将之转换成计算机语言。

一名优秀程序员所具备的能力

我们可以看到，一名优秀程序员应该具备应付两个不同世界的两套技能。

理解人类的需求并提出解决方案：

1. 沟通——与人建立联系的能力，能够同他人亲密的交谈，并有勇气去尝试分享自己的观点。
2. 意图——从谈话中提取有用的信息，理解并使之有意义。
3. 逻辑——为不懂让步的计算机整理、剔除那些人类思想中含糊而有争议的内容。
4. 创造力——挖掘、转变人类的想法，从而创建优秀的解决方案。
5. 构思——利用人类友好的接口和便捷的互动性来包装编程思想。
6. 大局观——清楚解决方案是如何适应全世界的用户、企业以及其他，从而使你的程序更有用。

告诉计算机该做什么，并建立解决方案：

1. 逻辑（再次强调）——把程序员的想法组织整理成有凝聚力的软件思想和计算机指令
2. 技术——发现并理解科技黑箱（对于99%的人来说是黑箱）。
3. 编程语言——学习美观的、富有逻辑的、清晰明了的语言，从而把程序员的想法提供给电脑。
4. 算法——精通让计算机完成任务最高效的方法。
5. 建模——在软件代码中建立抽象和模型，从而掌握并操控想法。
6. 实践（比如代码重构、单元测试、持续集成）——周期性活动，以保持系统可靠、健康与可改变。（关于代码重构，可参见伯乐在线职场博客《明星软件工程师的10种特质》这篇文章中的第3点。）

面向人类和面向硬件对象/系统的程序员有很大不同。

不与人沟通的程序员不是好程序员。一个优秀的解决方案需要计算机世界与人类世界的双重技能。只有连接起两个世界，才能成为一个真正的优秀程序员。

译文出处：伯乐在线

原文：Andriy Solovey　　翻译：敏捷翻译 – 魏哲

如需转载，但请注明原文/译文出处、译文超链接和译者等信息，否则视为侵权，谢谢合作！

随机日志

千江有水千江月，万里无云万里天

亦寒 — Tue, 03 Jan 2012 22:33:44 +0800

一直很喜欢这句佛家偈语：“千江有水千江月，万里无云万里天。”水是水，月是月，因了月光的照射，水中有了月，月在水中．但，水中的月，不是月，只是水的幻像；月在水中，是水的反射．何等开阔的境界，每当想起这句话，心里的一切烦恼皆烟消云散。
传说鸟窠禅师在一棵枝叶茂盛、盘屈如盖的松树上栖止修行，好像小鸟在树上筑巢一样。时常有人来请教佛法。

    有一天，大文豪白居易来到树下拜访禅师，抬头一望，道：“禅师住在树上，太危险了。”
   禅师答曰：“太守，你的处境才危险。”
   白居易不以为然：“下官是当朝重要官员，有什么危险呢？”
   禅师说：“薪火相交，纵性不停，怎能说不危险呢？
   白居易领悟到他是指官场浮沉、勾心斗角，转个话题又问道：“如何是佛法大意？”
   禅师回答：“诸恶莫作，众善奉行，自净其意，是诸佛教。”
   禅师回答：“诸恶莫作，众善奉行，自净其意，是诸佛教。”
   白居易听了很失望，说：“这是三岁孩儿也知道的道理”。
   禅师道：“三岁孩儿虽道得，八十老翁行不得。”

    白居易顿时悟道。以偈语请教禅师：
   “特入空门问苦空，敢将禅事问禅翁；为当梦是浮生事？为复浮生是梦中？”
   禅师也以偈回答：“来时无迹去无踪，去与来时事一同；何须更问浮生事，只此浮生是梦中。”

人生如幻如化，短暂如朝露。然而，如果你能在有限的生命中体悟到“无生”的道理，认识到“动静一如”、“生死一体”、“有无一般”、“来去一致”的人生真谛，放宽胸怀，空出心智，合于自然，从而超越智勇奇巧，超越悲喜荣辱，超越沉浮生灭，超越时间“去”、“来”的限制，那么，你的人生将会于无尽的空间中绵延而去，直至进入生命本真永恒的圆满之境。

“千江有水千江月”–月只有一个，可是因为水的不同而折射出千差万别的倒影。未开悟之人，一丝不苟地遵循佛门戒律，在遵循中得到心灵的平静；将开悟之人，自遵循的过程中渐渐领悟佛家的精义；顿悟之人，已然参透了佛家的真谛，超然物外，不再为规则所囿。”今日之月绝非古时之月，明日之月也殆非今日之月，每个人眼中的世界各不相同。人之所以生，是为了追求幸福。宗教存在的意义，在于让人们在追求幸福受阻时保持心理的平衡和希望。

假作真时真亦假，无为有时有还无。佛性，在若有若无之间；世事，在虚实两界徘徊．如是，月也罢，水也罢，梦也罢，愁也罢，到了佛家那里，偈语曰：一切水印一月，一月印一切水。何等的境界！

随机日志

兔子跳铃铛的极致

亦寒 — Fri, 21 May 2010 21:17:43 +0800

兔子跳铃铛，追求的不是能跳多少分，而是能不间断地流畅地快速地跳出一个不错的成绩，一个一个地跳纵然出来高分也是不怎么漂亮的。对，要把“跳得巨好看并且较高”而非“跳得巨高”做为无聊时的目标。

下面这个视频只是个人的最高成绩，跟极致还挂不上边，要达到极致，等下个无聊的时间吧——

调试游戏程序的学问

茶喻人生咖啡若梦

亦寒 — Tue, 02 Mar 2010 20:16:26 +0800

顶级咖啡与茶给人们带来奢华富贵的享受，浸一缕香茗，清雅的香气驱散世俗的尘埃；煮一壶咖啡，甘醇的味道唤醒灵魂的喜悦，在唯美的意境里，心灵开始飞翔……

早在15、16世纪，意大利人这样定义奢侈品：“奢侈品就是甜品、糖、可可、咖啡与茶。”今天奢侈品的范围远远超出了当初意大利人的定义，珠宝、名车、服饰、名表等的加入壮大了奢侈品的豪华阵营。虽然顶级咖啡与茶在今天仍是奢侈品，但是意义已然不同，他们不仅意味着独特、稀缺、珍奇，更展现了一种与众不同的另类精神奢侈。

精神奢侈，是一种姿态，是对生活和自我最完美的领悟，是高贵灵魂的魅力所在。咖啡与茶，是彰显和认知精神奢侈的另类奢侈品。咖啡文化是一种持久的魅力，茶精神是一种深远的动力。巴尔扎克谁：“一旦咖啡进入肠胃，全身就开始沸腾，思维就摆好阵势，仿佛一支伟大军队的连队，在战场上开始投入战斗。”拿破仑说：“大量的咖啡会使我兴奋，同时赋予我温暖和异乎寻常的力量。”凡·高希望有一天能在咖啡馆里举办一次个人展览，也许凡·高觉得，那是最接近灵魂的地方。

茶和咖啡的魅力很大程度上作用于人的情感需求，他们通过独有的氛围、香气或味道唤起人们某种精神活动，如美好的梦幻、深奥的思想、独特的领悟、难忘的回忆……茶和咖啡也因承载着这些花费的精神建筑而变得感性和富有生命力。

不论是优雅的英国下午茶，还是清寂的日本茶道，都作为一个阶层的生活方式在流行，这种生活方式才是最高贵的本真，而不是把镶金家具当做一种时尚。传统的奢侈定义正随着新经济的崛起而被彻底打破，学者们将蔚蓝的奢侈品定义为时间、注意力、空间、闲适、环境、安全。如此，咖啡和茶将重新做回奢侈品的领头羊。这种趋势已经初露端倪，现在，闲适成了一种越来越难满足的奢望。要想逃避无处不在的喧嚣，静心品一壶茶，必须要费钱费力才能够办得到。

当你足够富有时，你才能不必为衣食奔忙，有时间从从容容地品一道下午茶；当你足够富有时，你才能为自己营造一个有意境的空间，让自己悠闲地磨一捧咖啡豆；当你足够富有时，你才能得到最顶级的咖啡和茶——你可以在顶级设计师那里定制无数套独一无二的晚礼服，只要你足够富有，但是你却不能得到任意多的好咖啡和好茶，也许在世界的某个山脉的某个山峰上才出产这种极品，而它的年产量只有几千克，全世界只有这么多，有的还不出售，他们是上天赐予的恩物。

你无法完全仰仗金钱来亲近它，这就是精神奢侈的不同。要知道。泡好一壶茶的难度绝不亚于在月桂树下约到你的心上人。首先，要了解各个地方出产的茶的特性，接下来还要选择适宜的茶具，注意水的温度、泡制方式、泡制时间，再往后是繁复的品饮方式和礼节……这是需要花费心思的消遣，这虽然比给表上弦难得多，但是你从中得到的也更多。世界上没有任何一场演出，能像君山银针茶在玻璃杯中的舞蹈那样，让人心驰神往，不知不觉迷醉其中；世界上没有任何一种响声，能像咖啡壶沸腾的节奏那样，令人心灵安静。

品味顶级咖啡和茶的奢侈性还源自于咖啡具、茶具的高品位。液体与器具的相遇是一次价值和艺术的契合，是一次诗意和美丽的邂逅。对于英国皇冠德贝瓷等奢华的杯具，不必抱怨其高昂的价格，因为任何美好的事物都可以看做是财富积累的直白且彻底的表达。真正尊贵的人无需借用他物来彰显自己的高贵，其本身内质美丽的散发就是最有力的证明，在煮一杯苏门答腊曼特宁咖啡，或泡一壶安溪铁观音时，其奢华的气质以及超然的品味从举手投足间散发出来，这是一种由内向外扩张的高贵气质，具有震撼人心的力量，让最璀璨的钻石黯然失色。

咖啡心情

征婚启示

亦寒 — Mon, 15 Feb 2010 17:13:45 +0800

本人打娘胎起开始博览群书，20岁的时候达到顶峰，没有任何人能够超过我。

往前推三百年，往后推三百年，六百年之内不会有第二个人超过我。

以我个人的智慧，以我个人的长相，我觉得我可以找一个非常完美的伴侣。

空室长夜独眠，问星空，逾弱冠之年你何在，若缘至千年，待到山花烂漫时，我在丛中笑。

本人找伴侣，一不求沉鱼落雁、闭月羞花，二不求家产丰厚、富可敌国，但求同甘共苦、患难与共。

有意者请拨打114查找联系方式，若查不到请直接拨110。

夜朦胧，人惆怅，青春将逝无奈何，月朦胧，君何在？

凤姐宇宙无敌经典语录

凤姐宇宙无敌经典语录

亦寒 — Sat, 06 Feb 2010 17:15:27 +0800

电灯是爱因斯坦发明的。
“爱因斯坦也不及我聪明，差远了。他是一名科学家，我不知道他所知道的东西，我不能发明电灯，我也不知道相对论，相对论应该是爱因斯坦提出来的吧？啊，相对论其实我懂得。如果没有爱因斯坦发明电灯，在他过去20年、30年、40年之后，一定会有第二个人发明电灯或者别的可以照明的东西。”

爱因斯坦是可以复制的。
“他（爱因斯坦）的聪明可以复制，我的聪明是没有人可以复制的，他（爱因斯坦）不发明电灯，以后肯定会有人发明电灯，所以他的才能可以复制；而我的能力是没人可以复制的，至于为什么，要等我死了之后才能知道。”

HR是什么东西？
“HR？什么意思？”

我前男友只是群众演员。
“吴勇林不是我男友，那是他们不知道从哪里抓的，只是个演员。其实我蛮嫌弃那个人的。”

国际视野我也没多加研究，我认为国际视野就是对所有国家和跨国公司的分析。
“国际视野（凤姐的择偶标准之一），其实是一个招聘广告上面的一个名词，我把它借用过来，我也没有多加研究。我自己的看法就是可以站在一个高度，对所有国家的整体实力进行分析；对所有的跨国公司的整体情况、走向进行分析。”

新闻在百年后才有价值。
“对于国际上的实时政治、新闻，我是不会关心的，因为新闻在过了一百年、两百年之后才可能有价值。”

冷落家人才能交到朋友。
“跟家人，跟父母减少联系，这样就能交到更多别的朋友。”

我很漂亮。
“我弟弟长得不错，很阳光很帅气，跟我很像，别人一看就知道是我弟弟。”

我有预知能力。
“300年以后的事情，我可以通过现在对这个事件的了解往后面进行推断，就是我有预知的能力。”

我是个大人物。我预言未来不会有大事发生。
“明天（指未来）基本情况和今天（指现在）一模一样，不会有什么大事发生，今天有了我这个大人物，明天继续会有。”

我是一个公众人物。
“我去那边是晚上，我在想我去和他见面会不会……因为我是一个公众人物嘛，会不会影响他的工作什么的。”

知识点纠正：

1、电灯是爱迪生发明的。

2、HR：human resource 人力资源

3、国际视野，或者说国际意识，是一种向先进看齐的意识，在政治，经济，文化，体育，教育，甚至农业等诸多领域相互学习与借鉴，共同提高。具有国际意识保证了一种向世界最先进的力量学习的能力，保证了在对比之中找出差距从而不断前进的动力；

国际意识还可以理解为一种情感和价值取向，要求我们有一种宽广、开放、平等的心态、主动自觉地了解世界、了解人类社会历史发展的多样性，公正客观地对待和尊重世界各国、各地区、各民族的文化传统，学习汲取人类创造的优秀文明成果。良好的国际意识体现的是一种积极、平和、理性参与国际活动和国际竞争的高品质思维能力。

4、新闻：在我国新闻学术界，最权威的新闻定义，是1943年陆定一提出的，“新闻的定义，就是新近发生事实的报道。”

新闻的基本特点主要是：真实性、及时性、准确性。

新闻的三要素：时效性、新奇性、重要性。

英文把新闻称作News，有两种解释：一说这是由北(North)、东(East)、西(West)、南(South)四个字的第一个字母拼起来的；一说是由新（New）这个词的意思引申出来的。综合这两种说法，News就是新的、东南西北发生的事情，这就是新闻。

新闻概念有广义与狭义之分。广义的新闻，是消息、通讯、特写、速写、报告文学、采访手记、群众来信等多种新闻文体的总称；狭义的新闻则专指消息。

新闻在构建和谐社会中的功能：导向功能、监测功能、协调功能、监督功能。

国际经济新闻的功能：一、深入浅出地介绍和评析宏观经济形势；二、及时、准确地传播重要的、有价值的经济信息；三、揭露和批评经济活动中出现的问题，发挥公众舆论的监督作用；四、传播经济知识；五、指导经济生活；

文化新闻的主要功能：一、满足人们精神层面的需求；二、传递知识；三、促进文化交流；四、反映社会心态；五、引导审美情趣。

5、公众人物，亦称公共人物，是指一定范围内具有重要影响，为人们所广泛知晓和关注，并与社会公众利益密切相关的人物。其以社会知名度和社会公共利益相关性为构成要件，二者缺一不可，共同体现了公众人物的特性。如知名人士、明星等。

曾经有一个条文草案，详细地说明了公众人物的界定，就是“领导人、艺术家、影视明星、体育明星、社会活动家等”。

凤姐语录经典赏析——

采访实录：

http://movie.joy.cn/movie/detail/78937/2.htm

征婚启示

《一人静》响起的这一刻，仿佛灵魂都被洗涤……

亦寒 — Mon, 18 May 2009 17:12:31 +0800

空灵，飘逸，略带优伤。沉寂的曲调，仿佛是来自梦中的声音，一点点侵入灵魂深处，轻轻地敲击着心灵。满是尘世杂念的心头，第一次变得空灵通透。仿佛置身幽谧的山谷，听，流水飞溅，看，云雾飘渺。

静逸的夜晚，一盏清茶，独自一人，坐于窗前。看，月光拥吻星星，听，乐曲长出翅膀，背着绵绵思绪穿越天涯海角，在寂静的夜里，不断回旋，不断飘散，仿佛回到了千年之前，所有的感觉也终于悠远绵长……

一个人，
在如豆孤灯旁静坐参禅，于一啄一饮，一花一物中修炼自己的平静心;
一个人，
渐行渐远，在急速行走中回味生活，学会怀有空旷悠远的心境面对自己、面对朋友、面对虚虚实实的生活。

一人静，
在繁忙的生活中给自己一份的闲暇，
给跋涉的心灵作一次反省的机会。

一人静，
学会与自己相伴，不受干扰、不受约束，
自由自在，享受翱翔于心灵世界的那份轻灵。

一人静，
在静谧的夜晚，轻柔，空灵，优美。
醉于姬神的乐韵，寂寞着，芳芬着，
渴望那一点一滴的温暖在心间里绽放……

相关：
专辑《千年回廊》
你从遥远的地方穿越森林而来，带着千年的祝福。在晴空下，你那苍穹之声绕过千年回廊，犹如诸神之诗唱起。向上看，花瓣如雪漫漫空下。你一人静立独想，勘破十三春的月砂，终如一朵青花飞向遥远的旅路……

2000年秋，Himekami 姫神为了在埃及和以色列举办音乐会，事先到当地采风，后来把当时的印象进行总结进而制作了这张《Sennen Kairou 千年回廊》。在音响方面，多多少少汲取了当地的民族乐器的特点，采用没有修饰的音乐路线。

姬神 (Himekami)，原名星吉昭，自七一年Victor电子音乐比赛中获得最优秀奖后作品风格以日本岩手县具有代表性的民谣，及东北的传统民族音乐为主，开拓出既崭新亦别具神韵的音乐。

他是一名用音乐为现代人祈祷的祭师，用纯粹的电子合成器，表达着人类最原始的赞颂，却不是对具体的自然，而是对自然中孕育的神。喜多郎继承了神道教的精神，姬神则沿袭了神道教的传统与文化。他试图用音乐，滋润现代人干涸的心田，唤醒他们对自然的敬畏尊崇之情。

他也是一名民俗学家，将几乎已经被人们所遗忘的绳文音乐挖掘出来（“绳文”意指结绳记事，是日本文明尚处于雏形的遥远年代），让这种古老的文化遗产在世界的眼前重放异彩。或许你会奇怪这和现在的日本音乐大相径庭，但是这才是日本文明真正的音乐源头，是共属于人类的宝贵财富。

Tears of the Sun – The Journey / Kopano Part III

亦寒 — Sat, 02 May 2009 10:11:11 +0800

在每一场战争当中，真正能体验个中滋味的，除了手握真枪实弹的士兵，就是那些饱受涂炭的无辜百姓。无论是出于什么目的，那些挑起战争的人无疑都是最可耻的，冠冕堂皇的理由无法掩埋良心的力量。影片《Tears of The Sun》（太阳的眼泪），讲的就是一个原本顽固的军人，在惨烈的战斗中唤醒内心良知的故事。在看到这部影片之前，我有幸先听到了它的原声，曾经以《The Lion King》（狮子王）一片夺得“学院奖”的Hans Zimmer，用非洲音乐元素作为基调，恢弘壮阔的旋律中再次触发悲天悯人的人性良知。

在这部影片的原声碟正式推出前，有关方面就曾经声称它将是Hans Zimmer近年来最有野心的作品之一，制作班底就是当年让Hans成功摘取小金人的《The Lion King》中的老搭档Lebo M.。
和《The Lion King》一样，《Tears of The Sun》中的配乐，人声所占的比重非常大，尤其是专门为影片创作的《The Journey/Kopano Part III》(旅程/科帕诺第三乐章)这段结尾组曲，堪称完整流畅的灵魂诗篇。充满生命脉动的节奏中，雄浑的大合唱勾勒出一览无余的非洲原野，Lebo M.愤懑中蕴涵着伤感的呐喊，充满了撕扯的力量，从中可以听到主人公的良知在哭泣。电影中，音乐原本是为视觉服务的，但是这段曲子即便是单独抽离出来，也是一段完整的人性悲歌，让人禁不住感叹，原来活在没有战火的世界竟然是如此幸运。

但是战争的挑起者，恐怕并不这么看，在他们的世界里，可以充满了金钱的奢华和情色的诱惑，而根本不去理会那是在一堆堆战争的白骨中构筑起来。影片《Tears of The Sun》并不是纯粹的艺术片，所以，大量的战争动作场面必不可少。而Hans Zimmer创立的“视觉音乐”也在这部影片再度被派上了用场，最典型的要数《The Jablonsky Variations On A Theme By HZ/Cameroon Border Post》(汉斯季默创作的主题杀戮变奏/喀麦隆边境哨)这段组曲，当凌厉的电子合成器与壮阔的管弦乐融合成一片听觉霹雳的时候，你已经身在子弹横飞，生死一线的战场，奇怪的如此激烈的听觉轰炸，也无法Lebo M.嘹亮的歌声，预示着人性的良知是任何武器无法摧毁的。
Hans Zimmer在为这部影片创作音乐的时候，在展现人性良知的同时，也不忘直面那些人性中丑恶的阴暗面。从主题旋律到每段旋律，调子始终在阴郁的区域徘徊。在《Small Piece For Doumbek And Strings/Kopano Part 1》(小段针线/科帕诺第一乐章)这段同样以主题旋律也中轴衍生的段落中，Hans加大了管乐的比重，低沉浑厚的音色，犹如在心头压上了一块大石，几乎到了让人窒息的地步。这种心灵上的煎熬，恐怕要比任何一种肉体上的伤痛更让人难以忍受，基于这个原因，我认为这段音乐并适宜经常聆听。

关于Hans Zimmer已经谈得太多了。不可否认，他的创作为这部影片起到了推波助澜的作用，但是在我个人看来，真正画龙点睛的神来之笔，大都是来自Lebo M.的和声。正是他编写的这些人声段落，为原本充满杀气和阴郁色彩的音乐增加了人性的亮色。这一点在专集开篇的《Yekeleni Part 1/Mia‘s Lullabye》(耶克里尼第一乐章/米亚的催眠曲)，就得到了印证。非洲土着的打击乐器在贝斯的配合下，轻盈而不失稳重，Lebo M.的歌声也要温柔了许多，就象晨曦中洒下的第一缕阳光，清凉中渗透出丝丝的暖意。

为什么这种希望之音永远都有？可以说都是人们的良知在发挥着它的力量。也许有一天，真的能没有战争，而在这一天到达之前，相信还会有更多的人，用他们手头的音乐去唤醒沉睡在心灵深处的声音，“我要安宁……”

Never Grow Old

亦寒 — Sun, 05 Apr 2009 17:10:02 +0800

淡淡的快乐与忧伤，很难拒绝这种体验。

歌词浅显到小孩子都可以懂，而对生命和生活态度的理解又是人一辈子寻求的一个答案。

抛开所有，细细品味这首《Never Grow Old》，也许你会得到一些东西……

这首歌的演唱者正是大名鼎鼎的小红莓（又称卡百利乐队）。一句 Hope you never grow old，承载了永恒的美好祝愿。看着自己爱的人，有一天终将老去，死去，内心的触动也许比自己面临岁月的无情来地更加真切。蓝天、微风，加上心里有个人可以祝福，还奢望什么呢?生活其实真的可以这么简单和美好。