您的位置：
&›&盘点当年Java上那些久玩不腻的游戏
盘点当年Java上那些久玩不腻的游戏
来源：趣机网
发布时间：
Java，曾经手机界的霸主，比塞班还早，安卓也是基于Java建造的，给很多人带来无限的欢乐，相信大家都有玩过Java游戏吧iOS。。。。。。没什么关系，Java游戏曾经也给大家留下了深刻的印象，是手机游戏的开国元勋，大家都玩过轩辕剑，仙剑等等国产的和外国的Java游戏，但你们玩过这些吗？ 1.现代战争4现代战争4决战时刻~没错，就是现代战争4，Java也有，不过，它已经不是fps游戏了，直接变成2D游戏。。。。。。不过游戏性还是妥妥的。&2.近地轨道防御3近地轨道防御3~你也没听错，就是Nova3，同样也从fps变为了2D游戏，嗯！感觉上有点像街机游戏那种3.cscs~对头，就是反恐精英，不过在这个俄国人做的游戏还是良心的做成了fps，俄国人做得游戏都很不错，游戏性也是很棒的，我记得这个还可以用蓝牙对战，最后boss是直升机。&4.湛蓝的回忆湛蓝的回忆，这个是恋爱养成游戏，当年这个游戏很火的，结局非常感动，有两个结局，好多玩家当年玩这个都哭了。&5.时光八宝盒同样是恋爱养成游戏，当年堪称神作来着，相信很多人都有玩过吧&6.天降少女天降少女系列，这游戏一出来就火了，大部分玩家都是冲着美女玩的，当然，这游戏没让大家失望，女主确实很漂亮，剧情也很不错。是回合制游戏，还可以钓鱼，开通结局需要找齐所有地图碎片。7.荣誉勋章20112011年还出Java游戏，也是有心8.里约热内卢：圣徒之城自由度很高，载具很多，武器也不少，除了画面是2D外，都挺好，其实画面在Java领域也已经很精细了，主角也挺像。9.赏金猎人绝命都市这游戏画面不算最好，打击感也中规中矩，但我就是对它情有独钟~10.天使战纪后宫游戏，女主全是天使，游戏结局有好几个结局，可以选择喜欢的女主告白，回合制游戏，人设很赞。玩游戏，交朋友，尽在。更多游戏资讯，欢迎加入“趣机吐槽集中营”QQ群：
游戏评论参与评论0条
••••••••••••
网游排行榜为什么Android应用用Java开发，为什么Android大型游戏要用数据包？这里根据我的知识做一个总结
Android用java作为开发应用程序的语言，是经过深思熟虑的。作为一个开源的、被广泛使用的操作系统，它与微软的Windows系统、苹果的IPhone系统最大的区别，在于硬件差异性而不是别的。
微软的Windows系统，一统天下用的都是X86的CPU体系（即Intel和AMD两家的CPU），所以用C和C++写出的应用程序，只需要编译一次，生成X86
CPU指令的二进制执行文件，就可以在所有硬件配置的Windows系统上跑起来。其实这也是业内公认的一个潜规则，就是微软和Intel的共生关系，微软只使用Intel创立的x86架构体系的芯片（AMD的芯片为了满足这一要求也所有芯片都采用了Intel创立的x86架构），Intel新的PC芯片也都延续x86架构体系。这样做的好处是巨大的：开发者只用开发和编译一次，就可以让应用跑在所有Windows系统上，所有用户只用下同一个应用程序，就基本都能在自己的系统上跑起来。相对而言，下载过塞班手机应用程序的人都有过这种经历：下载应用时要看自己手机的型号，选择对应的才能用。开发塞班程序的人也很痛苦，要为每一种CPU型号的塞班手机都编译一套执行文件，并且没新增一种手机，就要再编译一套。
微软与Intel的这种软硬共生关系，让所有的PC厂商没了选择，只能选择x86架构芯片。有人或许会说他们的这种做法很霸道，但作为应用开发者和用户，却从微软的这种统一性中获取了巨大的方便。
相对于微软的Windows系统而言，Android面临的环境要复杂的多。谷歌是一个以开源免费为主的公司，Android将会被各种设备商所使用，运行在各种架构的CPU上（x86，ARM-7，ARM-9，ARM-11）。这就迫使谷歌不得不面对一个问题：应用开发的难度。如果仍然采用C、C++作为开发语言，那开发Android应用将面临和塞班一样的问题：开发者和使用者都不得不为每一种设备都弄一套程序。这会让开发者痛苦不堪，降低他们的开发效率，也会让习惯了Windows的用户很迷惑和不高兴，为什么我不能下一个通用的程序？？？在运行效率和开发使用方便性二者之间，谷歌选择了折中，以Java为应用开发语言。Android提供名为Dalvik的Java虚拟机，使Java语言应用运行在这个之上，从而隔离了底层设备的差异性，虽然用解释型语言牺牲了一些效率。
按这个做法，在Android上开发3D游戏的话，直接用Java语言的3D
API就行了，不需要另外再弄什么东西。那为什么Android大型3D游戏还要另外再下数据包，而且数据包还区分CPU（例如给高通CPU的数据包，给TI
CPU的数据包）？这就牵扯到游戏开发商的成本问题。由于游戏开发商希望在大部分设备上只用一套代码，所以基本是C/C++开发的以适应普遍的设备平台，只需为每个平台编译一次。如果再单独为Android开发一套Java代码，显然成本是非常高昂的。于是有了一个间接方法：将C/C++语言编写的核心代码用Android提供的DNK编译成库，再把系统相关的代码用Android
Java开发一下，通过JNI调用C/C++程序编译出的核心库，大功告成，省去了巨额的开发经费。当然也有一些3D游戏，专门为Android写的一套Java代码，不用额外数据包，这样方便了Android用户，但投入-产出是否划算？游戏开发商需要打个算盘了。
最后说苹果IOS系统。它与微软有相似也有不同。不同的是，微软有Intel这样的一个好基友，而苹果似乎在ARM分散和内斗的阵营里难以找到肯与自己长相厮守的伙伴。相似的是，都是闭源系统只给自己使用，并且自家内部使用一个CPU体系（苹果使用的是自己的A系列CPU，微软是x86系列CPU）。不管相同还是不同，最终都促成苹果的自成体系。因为没有忠实硬件伙伴，于是苹果自己开发CPU（本身苹果以前也是做硬件的）。再加上只有自家使用，苹果的IOS王国就与微软帝国一样，拥有了统一的CPU体系。这就使得它与微软一样，应用程序一次编译处处运行。而且由于是编译型语言（object-c）生成的可执行程序，效率比Java要高，这也是为什么IPhone的配置比高端的Android机低却仍然运行很流畅的原因。
最终总结一下，未来的趋势或说开发者和用户的需求，就是应用程序的硬件无关性，一次编译处处运行。而在如何满足这一要求上，有两种途径，一种是一个操作系统采用一致的向下兼容的CPU体系，另一种就是用Java、WebApp这样的平台无关开发方法。如何取舍取决于操作系统提供商本身的特性和市场策略。至于哪种趋势将占主流，在目前的市场格局下尚无法预测。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。(灰色沉默)
(地球月光)
第三方登录：为什么很多人说 Java 不适合编写桌面应用？
请大家解释一下，谢谢。
Java的桌面程序并不少，其中最为知名的莫过于Eclipse。在Linux和Mac下，Java程序的比例远高于Windows下。不过，“Java不适合写桌面应用”的说法有一定道理，论调的主要背景是供Windows下使用的企业桌面应用的开发。由于一些历史和定位的原因，对于这种GUI程序的需求，Java的优势不明显，劣势比较明显。这事还得从Java的传统，“跨平台一致性”说起。在写后台逻辑的时候，跨平台是好东西。很多公司都是在Windows下开发，在Linux下部署，方便。但涉及到GUI的时候，跨平台就成了个“看上去很美”的东西。理论上，我写个窗口，在Windows和Mac下都一样能用，那是多么美好的事啊。但实际上，每个平台提供的GUI控件多多少少有点差别，一坚持跨平台，麻烦就来了，该支持多少控件，怎么支持呢。一开始，Java的思路是：那简单啊，有原生控件干嘛不用，至于不跨平台的，就不支持呗，又坚持了原则，又回避了问题。这一代的gui库，awt，就此诞生。因为Java一开始是一根筋想推广Applet的，只是“顺便”也支持本地应用，设计成这样不能说不合适，毕竟，HTML也是同样的思路，只支持几种最基本的控件。但对于想开发复杂点界面的人来说，就有麻烦了。想来个目录树吧，对不起，不支持；想来个进度条吧，对不起，不支持。旁边放着Delphi和VB这么方便的东西，哥干吗受这气啊。这样一来，Java自己也觉得说不过去了。但又要跨平台，又要提供丰富的控件支持，那就只有另起炉灶，开始用第二种思路：自己动手、丰衣足食，自己重写一套GUI控件，代替操作系统的原生控件。这一代的gui库，叫做swing。这也是一个想“彻底”解决问题的思路，但是要付出代价。代价之一就是效率。我们可以参考一下另一个相同思路的产品----flash。为了实现矢量动画，在flash的那个小框里，图是一帧一帧地算出来的。接下来的事情我们都知道了：复杂的flash动画极耗cpu；iPhone说，您太耗电了，俺就不支持了；Adobe说，那好吧，那俺也不费心折腾移动版flash了。自己画出来的控件毕竟不能跟原生控件比效率，尤其是在早期Java优化还不够完善的时候。而且，自力更生的目的只是为了平台兼容，不是为了更好的效果，这事儿其实怎么想怎么亏。代价之二就是效果。自己画的控件毕竟只是模拟，还是会有细节差别。比如著名的毛玻璃效果，这不是简单套样式就能套出来的。而且，各个平台控件的风格本来就不一样，虽然swing提供了几种外观，但大部分程序出于偷懒或是跨平台一致考虑，还是使用默认外观。默认外观跟平台不一致倒也不是问题，主要是别比平台效果土。我用着win7，一个程序非让我感觉回到xp时代，心里特别添堵。就这样，一帮人商量着，又琢磨出个新思路：做适配。平台有这个控件，就直接用，保证效率；没有，再造轮子，保证可用。就这样，swt问世。eclipse的gui就是基于此。swt是赞，不过这属于改良，两个根本问题仍在：1. 跟操作系统api打交道不是Java的长项，效率仍然不能与c++等相提并论。2. 到底要不要跨平台。如果要跨平台，swt接浏览器控件、接ActiveX控件的功能就成了形同虚设；而要是不想跨平台，又何必使用Java呢，.Net在一旁已经恭候多时了。（补充：原生控件在各平台下还是会有些差异，感谢@冯东指点）@冯东：另一方面，即使每个平台都支持的 control 也多多少少有些差异。比如同样是文本框，Windows 和 Mac (Cocoa) 对待 non-English 输入法选词的语义就不同。再比如对 focus-lost 的处理二者也不同。所以 SWT 其实目前很难做到 Swing 那样的跨平台。跨平台么，终究还是只能做到最大公约数，比如 x86 支持 4 级，Unix 只用两级。可那是大家都同意不用的。在 UI 级别可没有人能同意不用操作系统的某个功能。 除了技术本身，还有一个产业的问题，围绕着GUI控件也存在一个生态环境，没有丰富的领域、行业控件的支持，技术本身的战斗力也会大打折扣。而Java这方面的生态较为薄弱。 综上，如果一个GUI程序使用Java，通常都是有这些特征：确实是想跨平台对界面并没有太多效果的要求，界面效率也不是瓶颈相比于其他GUI工具，开发人员对Java更为熟悉比如，一些工具的管理界面，很符合
不属实啊，Jetbrains的系列IDE全是Java开发的啊，够复杂也够好用了吧只是没有marketing，用的人不多而已
Java的GUI一开始定位就不是消费者市场， Java Applet的产生是因为当时Web还没有出现一种能够展现丰富动画效果的技术。Flash的后来居上更是加速了Java Applet技术在Web中的消亡。而AWT只是为了支持Java Applet技术存在的。后来Java技术更是被SUN定位在企业开发领域，桌面领域也变得比较小众和专业化。再后来，Swing库更是一个被叫做Amy的女人弄得一团糟....Swing/AWT说实话是比较烂的，要不然IBM不会自己开发一个SWT库替代。有兴趣可以看看这篇博客，
我觉得现在如果是写新的Java桌面，JavaFX2.0应该是基于Java的最好选择了.基于Java的RCP 主要有Eclipse Netbeans平台，他们分别依赖于SWT Swing，关于Swing，Java的方向已明确说了，不会再发展Swing，将有JavaFX慢慢取代之，而JavaFX的发展，是否在iPad 智能手机上下功夫，暂且未定。但至少是作为Java 桌面的主力了
桌面程序不是现在软件的主流。你可以观察一下，java流行之后，如果需要使用桌面程序，基本上还是会考虑java的。至于java的性能问题。我觉得这个问题在现在的计算机上，不是很大的问题。java写桌面程序的优势是它的多线程支持，不足是缺乏足够可用的控件，很多东西需要自己写。swing的继承体系挺复杂的，理解起来需要一定的时间。JavaFX能够好一点但是也有控件不够丰富的问题。
尽管我们可以用Java创建出桌面应用，但只要我们想开发真正的富桌面应用我们就无法真正使用Java而使用JNI、C/C++和平台依赖的libraries等。使用Java构建桌面应用更多的是困难和麻烦，比如即便想要在Java应用内创建一个高效的优良的web浏览器都是一件难事。而且没有用Java编写的图片处理应用，没有一个纯粹的Java web浏览器，没有数字音频应用，没有3D建模器，没有矢量图形编辑器，没有先进的光栅编辑器Java今日在桌面端所到达的高度只能满足那些服务器开发者，因为他们只需要在远程服务时使用电脑桌面上的简单界面。过去我们一直说这是因为Java太慢，无法在一个慢的平台上开发出如此复杂的应用。但我们这样说是错的。原因有两点：一，Java从来就没有慢过，即便有些部分曾经慢过，但没有人怀疑当它需要被用到服务器端时它会迅速地得到提升，比如JITs，GCs等。这一点也正是Java语言卓越的地方。二，由于Java平台的天然特性，Java应用总是第一个利用市场上新硬件和新操作系统的应用。一旦JVM被配置到了一个新系统中，几乎不需要任何编辑和调试，Java应用就可以在上面全速运行。比如你在32位的操作系统上开发了一个应用，它就可以全速运行在Windows 7 或者Solaris的64位JVM上。所以所谓的Java太慢根本不能成为Java在桌面端碌碌无为的借口。而且，如果你是一个终端用户，你甚至不需要从网站上重新下载应用，这意味着不仅终端用户和开发者得到了速度提升，甚至应用的执行性能的前边也得到了速度提升。今天，JIT在runtime为本地操作优化代码已经做得很棒了，这意味着你可以挖掘出你运行的硬件的全部的能力，这是一个静态编译语言永远也无法竞争过的性能，只是这个性能如果可以运用到桌面端和游戏领域就好了我们总是说：由于Sun总是一个服务器端公司的原因，Java在桌面端一直没有真正的机会。而Oracle的收购让这种境况看起来不会有什么改变。希望这不要再继续下去，为了Sun、Oracle和Java自身的利益，Oracle内部的知名人士应该提醒公司来让他们知道：如果缺乏了在桌面端的能力和效率，必将影响Java的普及率甚至它在服务器端的占有率。我们一直以来习惯着Sun主要提供服务器端服务，因而想象着未来更多的处理能力还是出现在服务器端，而客户端不过是连接服务器的简单服务。这种情况已被证明是绝对错误的。因为未来的桌面应用将服务、应用与硬件所有的运算能力相结合，大量的数据和解码、声音、图像、视频被开发者处理，而且用并行编程的方式来实现，既保证了丰富的性能又保证了速度。对开发者来说，未来的服务既需要他们在客户端处理也需要在服务器端处理：执行复杂的搜索、图像、视频以及虚拟3D环境需要服务器端的技术，而远程服务如医学分析、远程教育和远程会议等则需要客户端能力。只是令我们感到失望的是历史又一次地重复了，因为至今Java中还没有什么大的动作。Armin Ehrenreich 在回复中说道：说的好，我完全认同。确实迫切需要跨平台的桌面应用技术，而且我不认为C++结合Qt是个好的选择。你说阐述的问题之所以没有引起很多的共鸣，我想是文化上的问题。许多Java社区的人们包括Sun内部的负责人无法理解你所说的，所以我断言Oracle也不会对Java做出什么大的改变。客户端现在基本上被微软和Apple包揽。到Cocoa论坛中会发现他们谈论的是GUI的可用性、响应性、终端户如何处理桌面应用等而我们的论坛呢，大部分人认为应用的未来在服务器端。这就是文化上的差异。但是桌面技术需要做很多工作，Swing很慢很慢地进化，连同Netbeans平台、Java3D, JOGL等应用勉强成为了桌面端的一个选择。但Sun置此境遇于不顾，只是模仿Flash发布了一款新的脚本语言，但是那些API只有使用JavaFX才可用Jeff Martin回复道：正确的观点，但我有一点不同。Sun真正的问题是他应该吃自己的饭，用自己的力量来用Java写一些实在的桌面应用，这可以证明他们关于Java在桌面端的承诺，证明他们可以写出应用、提升框架和工具。我不认为另一个框架会帮助Java。James Sugrue回复道：我同意作者观点，我也很支持桌面端开发。看看现在处于开发中的Eclipse. e4中的一些项目，它们为桌面和浏览器提供了一个解决方案，所以我想还是有一些希望的。但我认为我们不需要过分聚焦于桌面端，JavaFX是正确方向上的一个迈进，只是无法在Swing和Java3D/JOGL中看到应用提升。Osvaldo Doederlein回复道：我认为JOGL的支持没有那么糟糕，毕竟它是JavaFX Desktop Runtime的一个依赖。实际上，我们可以写一个非JavaFX的小程序，而且不需要请求本地代码的许可性就可以配置。
Desktop Java不能广泛流行的最主要原因是，跨平台的GUI方案已经有Web了。假如没有Web，大多数Enterprise Application会采用Desktop Java开发的
Java编写小型的桌面程序还可以，编写大型的企业级应用程序是不太现实的，你不会发现哪个ERP系统是用Java写的。 至于原因，楼上的也说了很多，其实要看你的应用程序的侧重点，如果更侧重于跨平台，java可能是个很好的选择，如果更强调速度更快，那C/C++可能就是比较好的选择，如果侧重于快速开发，.NET平台也是一个选择。
@钟声 的***比较全面了。不过从 @陈昊 的并非回答的回答说开：很多学J***A的人一开始学都听过这句。。于是SE就只被人当作基础过渡算了。。结果J***A程序员很大部分都聚拢在EE 关注了 希望得到更多更全面的***那么，很多人一开始听过这句是谁说的？为什么 SE 过渡之后的终极是 EE？***是：说这话的人正是 Sun。Java 本来是作为 Web 上的 rich-client 设计的，Applet 在浏览器上失败之后，搞基于 ActiveX 的 Applet plug-in，再失败之后搞 Web Start，再失败之后，Sun 祭出 EE，宣称 GUI 它不玩了，宣称 Java 是最好的 server-side 语言。有人说这是个「见仁见智」的问题。问题就是 Sun 这位贱人是什么仁什么智啊。
因为桌面程序运行在宿主机器上，所以比如你运行java桌面程序，必然要***java虚拟机，也就是相当于在操作系统上再加一层抽象，这与直接调用api的桌面程序效率相比，或多或少低一点。因为java主要用于因特网编程和移动开发，如jsp，而这些代码是运行在服务器端的，客户端（浏览器）只需要接收html代码即可，不需要***java虚拟机，又因为java的跨平台性，语言又比较简单，还有就是背后有oracle这样的大公司支撑，其出身简直就是高富帅，堪称贵族语言。所以java的用武之地太多了，而桌面应用方面，由于微软的垄断，所以java显得有点不太出众，又加之在其他方面做的太好，把人的注意力都吸引了，所以造成了人们感觉java不适合的假象，其实如果你执意要用java开发桌面应用的，我感觉完全没有问题。
已有帐号？
无法登录？
社交帐号登录您现在的位置： >
魅族MX手机能不能玩一些J***A小游戏
　　问：魅族MX手机能不能玩一些J***A格式的小游戏啊？
　　您好！巴士魅族小编为您解答：魅族MX手机本身是不支持J***A格式的游戏***运行的，不过你可以通过下载***第三方插件来支持J***A小游戏的运行。另外，一些J***A 格式的小游戏，您在网上都可以找到对应的安卓的格式。
相关文章：魅族MX手机 J***A小游戏
图解新闻：
最新攻略：
24小时更新：
热门排行本周本月
推荐文章本周本月