随着macromedia在flash lite方面的大力推广，这支mobile新军看来终于要展露头角了。不可避免的，众多的开发者会将它与现有的技术放在一起品评比较一番，而这次被推上擂台的，是已经在移动开发领域有着坚实基础的j2me。

技术的比较有的时候很盲目，大家唇枪舌剑、旁证博引了半天，却发现两种技术根本就没有可比性。

而那些狂热的拥护者则往往要追求一个“a最终会代替b”的极端。

那么，j2me和flash lite到底有没有可比性？而flash lite的是否会代替j2me原有地位而成为移动应用开发的首选。

我的观点是：j2me和flash lite在某些领域存在交集，因此如果flash lite可以被广泛支持，确实给了开发者相对于j2me而言更好的选择。但在大部分时候，它们适用于不同需求，因而不存在flash lite代替j2me的可能。

首先来说说j2me和flash lite的“交集”在哪？flash lite/j2me让我们可以充分的利用移动设备的计算能力，而无需借助网络和服务器，即便需要连接网络，我们也可以将大量的工作交由客户端完成，从而减低服务器的压力和网络带宽的耗费，这是与wap的技术最大的区别，也是优势所在。因此，从理论上讲，j2me和flash lite都可以用于在移动设备上实现商务、娱乐、管理等功能。

但是，flash lite和j2me两者都具备自身的优势和劣势，这种优势和劣势也导致了两者必将在不同的领域发挥作用。http://www.design-nation.net/en/archives/000453.php这篇文章中谈到的几点我不再赘述，以下是我对二者区别的补充：

1.flash lite拥有统一的规范，即flash lite player，任何安装了flash lite player的设备都可以播放flash lite文件而不需要加以编译修改。j2me尽管在基础规范（midp/cldc）上相对统一，但是大量的可选包使得程序的兼容性下降。更何况各个厂商的kvm实现还有众多bug。

2.flash lite无疑会提供更好的用户体验，摆脱了midp lcdui甚至是手机底层的mmi实现，开发者可以自由的设计应用程序的界面，同时也避免了使用api的困扰。相对而言，midp的ui框架过于丑陋，而且功能简单。（我现在正在试图解决这一问题）。当然，绘制复杂美观的界面也会带来资源和性能的耗费，因此开发者需要在两者之间寻找平衡点。

3.flash lite支持svg，同时本身也是矢量格式，因而在分辨率多样化的移动平台上可以更好的施展拳脚。j2me开发者则需要人为解决分辨率适应的问题。在某些状况下，为了适应分辨率而进行的工作可能非常繁复。而且使用j2me制作mtv类动画也几乎不太可能，逐桢绘图方式在j2me上不可能毫无顾虑的使用。

4.flash cast??现有资料太少，不知道他究竟能发挥多大的威力，但无论如何是值得期待的。相反，sun并没有推出与j2me完美整合的服务器技术，但事实上，j2me可以和任何一种服务器技术整合。

（中场休息 ~__~）

5.flash lite从现在看来，功能还过于单薄。j2me则由jcp推动其发展，新规范曾出不穷，从对手机底层的访问，到多媒体的支持，从svg到g3d。尽管很多规范真正在手机上实现还需要一段时间，但至少我们知道，j2me真的可以做很多事。

6.flash lite目前并不是以native方式存在于手机中，而是用应用程序扩展的方式，尽管安装一个.sis文件并不是难事，但如果厂商可以将flash lite player绑定在手机中，相信推广程度会更好。

7.flash lite仍然不适合作复杂的应用，包括商务和娱乐方面，从安全机制，存储能力，网络连接等层面，flash lite都比较薄弱，而且可能难以改进，而在这几个方面j2me要强得多。

8.尽管签下了nokia和samsung，但是flash lite推广的路还很长。而且，非智能手机仍然占据了大部分市场，nokia虽然致力于发展s60等智能手机平台，但s40手机仍然是主要盈利点。因此，如果flash lite只能出现在s60一类的中高端智能手机上，对flash lite的普及可能并不是十分有利。

作为一个开发者，最重要的是了解各种技术的优势劣势，用最适合的工具完成适当的工作。至于“那种技术最强”的问题，大可不必争个你死我活。

注：文本中的j2me实际上特指（midp/cldc规范，不包含cdc和personaljava）