距离我退出云应用开发群，彻底放弃开发已经过了3天。3天的时间足够让我好好冷静一下了，之前产生的许多抱怨也慢慢消停了下来。

总结这次开发失败的教训，总的来说，并不是技术上，或者算法上有什么太大的问题，而是出在了最基本的可行性分析上面

云应用是什么？

简单的说，阿里云应用就是移动Web App。通过把远端服务器（也就是阿里所说的云平台）上的Web包（包括xml、JavaScript、CSS）加载到本地的“云应用中心”来启动应用。这个“云应用中心”，据我观察，不是对Android 2.2系统默认浏览器的二次开发，就是直接基于WebView的实现的应用程序。我这么说，并不是要贬低云应用，而是事实。

不管是在开发群中，还是在论坛里，常常会有人问“是否支持WebSocket”。得到的答复一般都是“暂不支持”，而且似乎也没看出来有任何后续会支持的消息。相比之下，对于WebGL，阿里云就要高调得多：在一个月前就已经放出了一段用云应用开发的WebGL 3D动画的视频。相比之下，作为HTML5核心技术之一的WebSocket，其在阿里云应用中的待遇为何还赶不上Canvas的加强版WebGL呢？如果你现在手中有一部Android手机（2.2、2.3系统均可），用它访问http://html5test.com（注意使用无线网，因为数据量超大。），你就会得到答案。

最初的吸引力

上面所述基本上是后来才发现的。虽然有马后炮的嫌疑，但是这种自己被自己马后炮的感觉，谁试谁知道。其实云应用开发一开始是对我产生了极大的吸引力的，如果不是因为此，我也不会全身心地投入一个月的时间做这种开发，想必也不会有这篇总结。

首先是10万的奖金以及貌似非常好拿的“抢滩登陆奖”。最近半年时间，我陆续参加了新浪微博创新开发大赛、淘宝开放平台创新大赛以及这次的阿里云应用开发大赛，坦白说都是冲着得奖去的，而阿里可以算是三者中最为慷慨的一家了。不仅有最高10万元的大奖，而且只要应用上线，并且足够好，就有可能得到1部阿里云手机的“抢滩登陆奖”（总共200个）。

其时我正在学习HTML5 Canvas，在博客中也陆续发表了一些学习的心得和所做的小玩具程序，正欠缺一个实战的机会。于是，这次阿里云应用大赛刚好是“瞌睡遇到枕头”，而且在最初的宣传中，阿里也表明支持Canvas，并且在不久的将来就完全支持WebGL。当时的感觉就是这个比赛简直就是为我设计的啊！当即注册账号，获取邀请码，依照教程开始开发了。

最初的阻力

阿里云应用开发最大的优势是什么呢？简单！比Android开发还要简单就是其优势所在。实际上，只要把相关的JavaScript文件和CSS文件以云应用规定的格式引入到项目中，然后安装规定的方式去调用就行了。虽然所使用的语言是前台脚本语言，但是通过云应用的规则却更偏向于Java（甚至是更偏向于Android）。这就使得开发变得非常简单，只要代码能在PC浏览器（IE6除外）中运行，稍加改变就能变成云应用。

那么，如此简单的开发为什么照样吸引不到人呢？不是我危言耸听，只要你到开发群中看一下就会发现80%的人估计都把这个群屏蔽的吧？经常能看到在发言的人也就那么聊聊可数的几个。也许是为了将积极的开发者集中起来，大概一个星期以前，论坛新建了一个官方的阿里云开发者俱乐部的群。加入的时候看到人还是挺多的，但是实际的情况其实和普通的开发群还是一样的。

说这些的原因正是为了引出我所遇到的第一个困难：找不到测试用的阿里云手机。虽然阿里云在一开始的时候就在全国设置了多个测试点，但是偏偏没有阿里的大本营杭州。这就让我非常恼火了。因为，向在阿里和淘宝的同学打听的结果表明，他们也没有阿里云手机。在阿里工作的同学的原话是：“小米手机快要上市了，大家都在等着买小米吧！”于是，阿里云手机的市场占有率到底有多低就可见一斑了。

在网上搜索了一番的结果更是让我非常失望：即便是小米（2.3系统）的价格也只要1999的情况下，已经上市半年的阿里云手机（2.2系统）仍然要2600多。这对我这么一个学生党来说简直就是悲剧啊！而且，阿里云手机如果不刷机的情况下，不支持豌豆荚，不支持安卓市场——丝毫没有让人去买的诱惑力！特别是小米论坛上一篇评价阿里云手机的帖子，更是将其打击得一无是处了。

好在群的管理员承诺会在杭州设置测试点，虽然等了有半个月，而且测试点都设在咖啡厅，消费超级高（苦逼学生党），但是好在应用能测试了。

难以逾越的障碍

到这个时候，实际上我的期望已经从最初的得大奖降低到了拿到“抢滩登陆奖”——即一台阿里云手机——就好了，因为我始终还是抱着希望继续开发新的阿里云应用。但是随着测试的进行（同时咖啡厅消费的不断增加），以及一次又一次的审核，一个技术上的障碍越发暴露出来：同屏对象过多所导致的画面不顺畅。由于我设计开发的是一个竖版飞行设计游戏，因此敌我双方的飞行器、子弹等在Canvas上绘制都是必须的；在绘制的同时，还有涉及位置变化、弹道的计算等，算法的时间复杂度大概有n的平方。于是，画面或者操作不流畅成了我每次审核不通过的原因中基本都会有的一条。为了解决这个问题，我降低了敌机出现的频率，敌方子弹的轨道也从瞄准发射改为了直接向下发射，减少循环，等等。原本我的设想是做出想东方系列那样虐心的弹幕；但实际的情况是，如果弹幕设计成那样了，帧数也就只有个位数了。尽管如此，流畅度仍然不够理想。

于是，我不得不去怀疑是不是手机本身的问题。我所使用的是Moto ME525手机（Android 2.2），性能上比阿里云手机略微差一些。在我的手机上用默认浏览器测试的时候，也会有比较严重的丢帧和画面不流畅，情况和在阿里云手机上测试的效果相差无几。于是我开始怀疑是Android 2.2系统本身对HTML5支持上的问题了。第一个发现就是前面所述的WebSocket和WebGL的支持问题，也因此让我推测出所谓“云应用中心”其实就是基于Android 2.2系统默认浏览器或者WebView开发的。其实不仅仅是2.2系统，就连2.3系统也不支持WebSocket，4.0系统似乎也不支持，也就难怪论坛和开发群里没有对WebSocket做过多的解释了。

那么对于已经支持的Canvas和WebGL，阿里云手机的情况如何呢？Hi WebGL网站曾经发表了一篇比较各个浏览器Canvas、WebGL游戏性能的文章（http://www.hiwebgl.com/?p=618），里面提供了几个链接来测试Canvas和WebGL的性能。如果用手机浏览器访问的话同样可以看到手机浏览器中Canvas和WebGL的性能：

Canvas2D性能测试：http://www.scirra.com/labs/perftest-2d/

WebGL性能测试：http://www.scirra.com/labs/perftest-webgl/

我用小米手机（2.3系统，性能优于阿里云手机）测试的结果是：无论是Canvas还是WebGL，帧数都在14到33之间波动，同时渲染的对象在97到280之间波动。而我所使用的PC（四核，4G内存，集成显卡）测试结果为：仅是Canvas，帧数维持在30，同时渲染的对象在2400到2800之间波动。这是我第一次意识到HTML5在移动端的支持情况如此之差。在没有任何额外计算，纯粹是绘制的情况下，同屏对象都只能达到280的情况下，时间复杂度已经达到n的平方岂不是已经宣告了悲剧？

然后再回头来看看现在已经得到“抢滩登陆奖”的应用。时至今日只有4个：迷字点点点、推箱子、巧关电灯、俄罗斯方块。最初我信心满满地参加比赛的原因也是因为看到已经得奖的应用（当然只有第一个，后来慢慢有了第二和第三个）实在是太简单了，我弄个竖版射击游戏一定直接秒杀了它。我太天真了，我没把别人秒杀，手机环境已经直接把我秒杀了。以这样一种硬件条件，Canvas处理如此吃力的情况下，想做出一个流畅的动作/射击游戏简直就是痴人说梦啊！更不要提Android浏览器对JavaScript touch事件糟糕的响应了。

其实在开发的时候我注意到还有另外一个朋友在做一个塔防的游戏，不知道他的情况如何了？反正到我最后一次去测试点的时候还没看到有塔防的应用上线。现有的云应用基本上不是益智游戏，就是一些供查询用的应用。不知道最终的大奖会是个什么货。

决定放弃

最后一次去测试点的时候，恰好有一个老板模样的人和别人在那里聊天。他听到我问服务员关于阿里云测试手机的事情的时候，直言：“阿里云手机没前途”。其实在此之前我也已经有这种想法了。如前所述，阿里云应用其实就是在Android的基础上再弄了一个Web App的平台，来加载以JavaScript和CSS为基础的应用。其实Android的性能没有iOS高已经是共识了，还要在Android的基础上再弄一个解释型语言的平台，这简直就是完全舍弃性能因素了。但是Android的性能还算过得去的，更何况有仍在不断增长的用户市场，因此有大量的Android开发者无可厚非。而阿里云应用这样既没有性能，又没有市场，实在是找不出继续开发下去的理由。因为，如何一种应用，用Java编写，在Android市场发布，无论是哪方面都远超阿里云。我估计这次比赛的参赛者多数都是在校或者应届的大学生开发者了，冲着的也是奖金。那么以后呢？

言归正传，最终让我彻底放弃的原因还是因为操作不流畅的问题。本月16号我最后一次提交审核，审核依旧没有通过，这次的原因仍然是操作不流畅。显然阿里云的审核人员也没有意识到阿里云手机的硬件本身就有问题，或者他们本身就知道，但是希望我们用软件去解决。于是我意识到为什么这么长时间了只有4款益智游戏拿了“抢滩登陆奖”，云应用平台真心不是属于动作/射击类游戏的。

带着这样的想法，我退出了两个开发群。

失败是成功之母

上软件过程管理课的时候，老师说，需求分析很重要，可行性分析很重要，不做的话到了软件做完以后就会发现悲剧了。然后举了一大堆例子。老师，我对不起你，你教的我这么快就还给你了。

给基友袁二说起这件事的时候，丫只引用了伊利丹的一句经典台词：“You are not prepared!”

总结这次的经验教训，最重要的就是没有在开始的时候做好相应的可行性分析。觉得好就上了，但是测试的时候才发现硬件根本跟不上需求，于是不得不放弃了。

但是，也不是完全没有收获的。虽然阿里云应用开发的那一套完全不适用与其它的开发，但是好在它还是支持第三方JS类库的。我在开发中也是先在PC浏览器中进行canvas游戏的开发，然后再移植到云应用平台的。总的来说，我把之前所用到过的canvas开发的元素都用到了这之中，实战的目的还是达到了。

下一篇博文我将把我的代码共享出来，也算是作为我的HTML5 Canvas 2D开发的终章了。

转自：http://blog.csdn.net/sadfishsc/article/details/7084183