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