JAVA外媒评论:android等于java?

　　在很多层面上， android和java都有明显的相当。 android使用顺序是用java(tm)言语写成的， 使用jdk的javac(或等效工具， 例如ecj)来编译。 这个进程发生标准的java字节码(. class文件)。 这些文件再转化成android的. dex文件， 从使用的角度来看， 它就是一种不同格式的javaclass文件。 不错， 这是一种更优秀的格式;对sun自从1994年以来的设计有了很大的改进。 但就如你可以把一个gif格式的图片转换成更初级的完满的完全等效的png格式， 虽然它们的字节流完全的不同。

　　等效的文件格式在细节的实现上十分的不同， 次要是为了优化。 就好比， 如果我们复杂的满足于低效率的视频数据流， 没有采用高端的、跨不同框架的紧缩技术， 那我们就可以防止跟mpegla视频解码专利做斗争的麻烦了。

　　JAVAandroid特异的classfile设计有好几种动机;而为了防止和sun的知识产权维护冲突显然是一个次要的要素。 不论怎样， google并没有走的离java足够远。 两种文件格式十分的相似。 它们在特定的底层数据结构上有区别， 但这些结构体在语法上分歧的， 存储完全相反的信息。牛尔 我置信在javase或javamevm里可以随便的在它们的系统classloader里添加一个. dex分析器来加载androidclasses。

　　androidsdk依赖于. java-. class-. dex转换的理想情况既微乎其微也毫无损失。 毫无损失的理想很重要：当gif=png时， 跟受损的jpg文件就不等了它解码不出完全相反的信息。 如果jvm和dalvik都各自独立， 你很难写出一个相对复杂的工具将一种编译过的代码转换成另一种而且不做任何妥协：不丧失信息， 不使用冗余来补偿某种特征在一种vm中是first-class而在另一种中却不是的情况， 不需求额外的runtime层上在一种vm中实现另一种vm的中心api。

　　(我知道dx转换器有多么的复杂。 我看过它的源代码。 那个字节码转换器是一个巨大的， 全功能的反编译/重编译器， 经过ssa结构完成。 但是这个转换器在概念上仍然是无足轻重的;从java字节码到dalvik字节码的映射在设计上是很平滑的。 堆栈相关于寄存器架构中细节上进行了优化;而重要的东西， 例如vm层的类型系统是完全分歧的。 )