随着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）