Horia Dragomir谈论移动设备上的HTML5

个人简介 Horia Dragomir是一名界面开发工程师，现就职于Berlin的Wooga公司，主要从事于HTML5手机游戏的开发。他把大部分工作时间用来在分布式团队上采用敏捷的方法，发掘团队协同合作的新途径。

哥本哈根的GOTO会议由Trifork 和DANSK IT共同举办，它是一个厂商独立的会议并且由一个项目委员会筹划实施。GOTO会议的主要受众是软件开发工程师，IT架构师和项目管理者。

   

1. 我们现在位于2012哥本哈根GOTO会议的现场，现在在我身边的就是Horia Dragomir。请介绍一下你自己，好吗？我对你名字的发音没错吧？

大家应该管我叫Horia Dragomir，我是一名罗马尼亚籍的界面开发工程师。求知若渴，虚心若愚的我现就职于柏林一家名叫Wooga的公司。

   

2. Wooga是家什么样的公司？

Wooga是一家专门从事社交游戏开发的公司。这个名字是游戏的世界（World of Gaming）的简称，因为我们坚信游戏就是应该为大众所设计的，它不仅要服务于那些发烧级玩家，还要服务于那些闲暇时打发时间的人。我们就是这样定义游戏，也是这样开发游戏的，对于大多数闲暇的人来说，我们职责就是使他们享受更多的休闲和乐趣。

   

3. 在iPhone上，你使用什么样的技术开发游戏？

我们大部分开发的还是FaceBook上的Flash游戏。同时在移动市场上我们也取得了巨大的进展，因为我们相信下一个潜在的市场就是移动领域，而事实也证明确实如此。所以我们在移动设备上开发了一些本地应用程序，网页应用程序和网页游戏。

   

4. 你们确实在移动设备上使用JavaScript和HTML5开发过性能密集型的游戏吗？你是怎么做到的？它们真的可以运行吗？

当你在构建一些东西，特别是游戏的时候，总是有些东西需要你时刻关注，性能就是其中之一。你完成每一步的优化工作从而找到了应用程序的痛苦根源，你试图缓解这些痛苦，所以你只能提高性能，就像在应用程序上的那些传统做法。

是的，它通常都是一个很大的障碍，我们有时候会因为它运行得不够流畅而不得不放弃一些好的想法。因此，即使它可能产生很好的效果，但也不能真正的起到作用，因为它会让人感觉不真实。

   

5. 你刚刚提到了流畅性，响应能力就是你现在的工作重心吗？

是的，我现在确实很热衷于流畅性和响应能力。如果你所构建的程序不能让用户使用起来觉得很自然，那么用户就会时刻认为他是在使用某些东西。但对于游戏或者应用程序，如果它们可以有一个很完美的响应表现，或者在某种程度说是一种无缝的体验，那么用户就会全身心的投入其中，而忘记在他和他要达成的目标之间有另一个层次的互动。

   

6. 使用HTML5和CSS，你觉得做移动程序开发或提高响应能力最大的障碍在哪里？你觉得有没有一些事情是不可能的，或者说它们有可能性，但是仅仅是在某些很细小的层面？你对此有什么看法？

我有个很坚定的信念，那就是你不应该问一个工程师什么是可能的，什么是不可能的。因为答案永远都是可能，因为任何事都是有可能的，确确实实也是如此。只是通常所花费的时间和精力不同而已。但是基本上这些障碍现在只跟硬件相关。随着科技的进步，当iPhone 4S的问世的时候，它的确比iPhone 4快了许多，我们利用它性能的提升开发了更多的动画效果，在游戏中使用了更好的帧速率。这么看来，障碍的根源就在于硬件问题，软件是永远都可以跟上硬件的步伐的。

   

7. 硬件问题——你指的就是硬件的局限性吗？

是的，处理器每秒能处理的点击次数和运转次数。在屏幕上同时能展现的画面个数都是性能的表现。你不得不对这些内容都进行测试，从而来发现你的性能瓶颈在哪里，这样你就知道你的应用程序能表现到什么程度。有时候这些还不够，你可能要进行更多的测试，但这是有好处的，我觉得这也是在推动整个产业的进步。

   

8. 当你在开发移动游戏的时候，你在浏览器上使用了什么样的技术，你使用Canvas还是用SVG，或者其他技术？

我不明白为什么人们不使用SVG这门技术，我觉得它是一门好的技术，但是我也不明白自己为什么不使用，好吧，我确实是没有使用。我使用的是Canvas。自从去年开始，Canvas的性能就有很好的表现，但除了Android系统，但是总的来说，它的表现还是不错的。即使在Android系统上，它的表现也是不俗的，这样你就可以获得相当好的性能体验，相当好的动画效果和其他诸如此类的体验。你不再需要进行大幅度的改进工作。我是Canvas的忠实粉丝，所以即使是在桌面程序上我也使用它，它的确是一门不错的技术。

   

9. 我碰到过的Canvas的众多问题之一就是抗锯齿，你对此好像有些自己的看法？

的确是的，在基于iOS系统的设备上，虽然它的表现还是不错的。但始终还是会有一些问题。在Android系统上，抗锯齿更加显而易见，你需要注意的就是在你第一次创建图片的时候要处理好这些图片，虽然这些图片并没有多少抗锯齿的地方，另一方面，如果你面对的是视网膜显示屏，那么你所面对的问题可能只有以前的一半。对于老式的设备，它并没有这么多的不同，再加上如果你真的需要一些出色的图片或者类似的东西，你完全可以使用DOM来实现。抗锯齿并不会真的成为一个很棘手的问题——最起码是实践中不会。

   

10. 你真的是使用Canvas来绘画线条和路径吗，或者你主要还是使用它来处理sprite。

我大部分使用它来处理sprite。但是我们对于处理抗锯齿的圆角和Canvas上其他元素都没有什么问题。我们感觉没什么困难，包括我和整个团队。我还依然记得在早些时候我们看到的使用Canvas的一些经历。它确实看起来有点飘忽不定，而且可能会占用更多的处理器性能。但是我想，我只是对于它背后的整个技术框架有点茫然而已。

   

11. 在Canvas上使用动画，那现在可以使用requestAnimation的API吗？

还不能，在桌面程序上是可以的，但是对于移动设备，现在还做不到。我们现在十分期待，因为Apple已经承诺很快就会提供相关的支持。可能在最新的版本中已经实现了，只是我还没有求证。但是我觉得这并不能帮助到Canvas，因为Canvas是运行在一个独立的线程。你可以使用它来进行图像绘制而独立于浏览器的动画循环，这是一件好事。Canvas自身进行绘制操作是一个耗时耗能的过程，所以你只能自己对它进行优化操作。

   

12. 采用什么样的方式优化呢？

你可能会想到缓存一些大的图片，然后重绘那些要修改的地方，最后将它们刷新到你所展示的Canvas上。我们就是这么做的，我们有一个脱离显示屏的Canvas，然后在那里操作所有事情，包括处理所有的点击事件。接着我们只需要更新那些要修改的地方就可以了，我们获取到图片然后绘制它，大概我们每秒做30次的这样更新操作，而且它也确实有效。

   

13. 在某种程度上，它是一种双缓冲区的方式吗？

是的，如果Canvas不需要任何的更新，那么我们也不会去做任何操作，如果不是迫不得已的话，我们也不会进行重画操作，这也是对电池一个好的保护措施。

   

14. 我想谁适合你的游戏呢，因为....？

我希望人们都可以玩这些游戏，大家到最后都会有邮箱，有手机。
Werner Schuster：二十分钟以后。
Horia Dragomir：是的是的。即使电池对于每个人来说很重要或者应该很重要。现在在Firefox 里有很好的API用来显示电池的电量或者正在充电的状态。如果电池没有充电你就该考虑是否应该显示那些动画效果。我希望这些API可以在全平台都可用，因为我觉得它们是很有帮助的。

   

15. 你是怎样为移动平台开发程序的？你是在电脑上通过模拟器来开发的吗,或者说你是怎么测试这一切的？

对大部分而言，主要只有两个不同的模块，确切的来说，是界面和图像部分，你必须是在手机或者模拟器上进行测试。我使用Adobe Shadow在七台设备上同时加载一个测试，这是节省时间的一个好方式。如果我只是做一些很小的修改我会使用模拟器，因为它更加快捷，但是对于逻辑部分，你可以在任何地方进行实现，通常我们都是在Chrome上，对于更高级的工具，虽然还有Safari可供选择，但是我们还是喜欢Chrome。我们就是在那些地方进行逻辑位，、逻辑部分，、业务逻辑的开发，不管你们怎么称呼它们，我觉得它们应该是平台无关的开发内容。
Werner Schuster：如果你想测试或者是在实际设备上发现一个问题...?
Horia Dragomir：在部门内部我们是有一些真实的设备。

   

16. 好吧，你个人对在真实设备上进行调试和测试有什么看法？

这曾经是一段很痛苦恐怖的经历，但是现在，那些协助人们工作的工具已经有了很大的进步，在真实设备上调试和测试不再是那么痛苦的事情了。就如我所说的，我们现在有了Adobe的Shadow工具，它本身就非常好用。还有远程检查器，Apple已经允许本地应用程序可以做类似的事情。如果你正在做调试工作，你可以直接将Safari的检查器连接到你的手机上，或者是模拟器上。Opera已经专注于这方面的工作很多年了，但那时并没有人提到它们，也没有人给予它们关注，但是我却十分关注它。Opera大概是从2008年开始就从事于移动设备的远程调试工作。现在整体环境越来越好了，从而最终调试工作成为了现实。这很好，而且它还会越来越好。

   

17. 你刚才提到了iOS和Android系统和这些平台上的一些不同表现。你对此有什么经验吗？你有开发过基于HTML5的移动应用吗？你只开发过iOS平台应用而没有涉及其他平台吗？

在Windows Phone、Android和iPhone之间还是有很多共同点的。但是对于不同的平台你还是需要做一些平台性的调整，请允许我称呼它们为平台性的调整，因为事情并不是总是一成不变的，我们应该习惯如此。我是一名专业的网页开发者，这是我的背景。所以通常我都很习惯于处理浏览器之间的差异，对不同的浏览器做一些基于它们自身特性的调整。这不是什么新鲜事情，我想对于在这个行业工作的人来说，没人会觉得这个很奇怪。如果什么都可以一成不变固然很好，但这是不现实的，我觉得这也没什么问题。

   

18. 但对于你自己，你还是使用Flash的是吧？

是的，特别是在桌面程序上我都是使用Flash，因为它十分好用，而且不必担心什么副作用。

   

19. 但现在的GOTO会议，我们讨论的主旨是Google新推出的语言——Google Dart。你有想过什么时候切换到该语言进行开发吗？

切换？我从没想过要切换。我从来没有切换到CoffeeScript上进行开发，但是我依然使用CoffeeScript，我只会在开发大型项目时才会使用Dart。不要误会我，游戏就属于大型的项目，但是我们构建的很快，我们并没有在原型和自然实现上做一个合适的过渡。而是直接在原型的基础上进行构建，这就是为什么我们开发的这么快。在我看来，Dart只有在需要多人协作的大型代码库上才有意义，在那个时候，你就可以忽略语言本身的问题，而享受它所提供的语法和构造器所带来的好处。对于一个星期式的编程马拉松，我不会选择Dart，特别是我还需要重新学习这门语言，我会使用CoffeeScript来替代它。

   

20. 那么你是使用CoffeeScript 来进行快速开发咯？

是的，那是种享受，也是个很愉快的事情。
Werner Schuster：那么CoffeeScript都为你做了些什么呢？是不是修复了JavaScript上的所有问题？
Horia Dragomir：哦不，没有谁可以完全修复JavaScript上的所有问题。但这也是为什么我喜欢它的原因。而CoffeeScript 更像是我要从事某项工作的一个捷径。比如完成某项工作我需要一百行的JavaScript 代码，而CoffeeScript 只需要二十行代码就可以完成同样的工作。这样我就可以少写很多行代码，而且CoffeeScript的代码更简洁一些，它可以直接编译成JavaScript代码而我不需要做任何语法检查，这是很好的一点，因为我很不擅长语法。

   

21. 你只需要记住CoffeeScript 的语法吗？

是的，它更加简单一些，再加上我在大学的时候有一些口齿不清，你基本上都听不清我在说什么。所以我很喜欢它，因为它不会使代码变得模糊不清。它很像Python 和Ruby，但是它更易于阅读。

   

22. 那 ClojureScript呢？

我不是很喜欢它，但是我并不讨厌它，我也不反对它。我喜欢更多样化的选择，但是我没有真正考虑过使用它来做一些有意义的事情。所以这就是为什么我不是很喜欢它。我觉得我需要好好的尝试一下。

   

23. 那你对那些可以编译成JavaScript的语言有什么看法？比如，GWT？你会将它作为一个备选方案吗？就像对于大型团队你会将Dart作为备选方案一样？

我偏向于在呆在这里因为我不喜欢在大型的团队里工作。如果一项工作需要超过20个人来进行编码，那么我就会选择离开那里。对我个人而言，它并没有什么吸引力，这只是我个人的问题。我知道而且我也承认，在大学里它还是拥有一定的生存空间，但我并不在那种地方。所以在实际产品中我不会选择那些可以编译成JavaScript的大型框架。

   

24. 最后总结一下，除了现有的这些平台以外你还有关注其他类型的平台吗？还有什么有趣的移动平台即将出现吗，或者我们只能受限于现存的这些平台？

我们当然没有被限制住，如果你知道Mozilla，他们总会推出一些神奇的东西。他们的Boot2Gecko平台，我觉得它迟早会变得很受欢迎。我不认为它像其他的技术一样会分割整个web，它只是给了大家一个可选方案，如果你可以编写JavaScript和简单的HTML应用并将他们插入到操作系统里面，从而直接访问电池的电量，立即知晓屏幕的方向，那么我觉得将会出现很多有趣的应用，发展出很多以前由于各种限制而无法实现的功能。所以我当然会不断关注Boot2Gecko。