从JAVA工程师成为Android工程师需要多长时间？多少技术？
Android等同于Java吗？请注意，我说的不是相等，我说的是等价，就像P = NP中一样。
等价类/字节码格式在很多层面上，Android和Java显然是等价的。Android应用程序是用Java语言编写的，并使用JDK的javac(或类似的工具，如ECJ)进行编译。这个过程生成标准的Java字节码(。类文件)。这些文件然后被转换成。Android的dex文件，这是一个Java类文件，从使用的角度来看格式不同。是的，这是一个更好的格式；孙的设计从1994开始有了很大的改进。但就像你可以把一张GIF格式的图片转换成更高级、更完美、完全等价的PNG格式，虽然它们的字节流完全不同。
等价文件格式在细节上差别很大，主要是为了优化。比如，如果我们单纯满足于低效率的视频数据流，不采用跨不同帧的高端压缩技术，那么就可以避免打MPEGLA视频解码专利的麻烦。
Android特定的类文件设计有几个动机；为了避免与Sun的知识产权保护发生冲突，这显然是一个主要因素。无论如何，谷歌离Java还不够远。这两种文件格式非常相似。它们在具体的底层数据结构上是不同的，但是这些结构在语法上是一致的，并且存储完全相同的信息。我相信在JavaSE或者JavaME VM中，很容易在他们的系统类加载器中添加一个. dex解析器来加载“Android类”。
Android SDK依赖于。Java-& gt；。class->；的事实。dex转换微不足道，没有损失。“不丢失”的事实非常重要:当GIF = PNG时，它与受损的JPG文件不同——它不能解码完全相同的信息。如果JVM和Dalvik是独立的，那么您很难编写一个相对简单的工具来将一个编译后的代码转换成另一个——没有任何损失:没有信息丢失，没有使用冗余来补偿一个特性在一个VM中是一流的而在另一个VM中不是，并且不需要额外的运行时层来在一个VM中实现另一个VM的核心API。
我知道dx转换器有多复杂。我看过它的源代码。那个字节码转换器是一个巨大的、全功能的反编译/重编译程序，是通过SSA构造完成的。但是这个转换器在概念上仍然是无关紧要的；从Java字节码到Dalvik字节码的映射在设计上是平滑的。相对于寄存器架构中的精细部分来优化堆栈；而重要的东西，比如VM层的类型体系，是完全一致的。)
很容易看出VM等同于Dalvik和JVM。不仅仅是源代码或字节码格式:它们的运行时版本也是如此。一旦一个“Android类”被加载到Dalvik VM中，它就会像Java类一样运行和工作。如果你懂Java编程(深入高级和低级细节)，你也懂Android编程。你只需要学习一些新的API和框架概念。它们是对等系统。
你还记得微软的。网？什么时候。NET刚诞生，Java阵营就迅速反击指责。Java抄袭网。我也是其中之一，但今天我把问题看得更清楚了。是的，曾经是严重抄袭的产物；C# 1.0是一个...区分一种语言和另一种语言的最简单的方法是看它们的惯用风格——例如，ToString()和toString()。但是在最重要的VM规范上，微软做了很多功课。它的CLR、CLI、核心框架都和Java有很大不同，所以不能说等式JVM = CLR。您不能使用简单的文件格式转换工具将您编译的Java类转换成可以在。NET运行时。
你想要证据吗？你只要看看IKVM就知道了。这是一个很有意思的项目，可以让Java和。NET跨平台兼容，因此您的Java代码可以在CLR(或等效的。NET运行时，如Mono)不加修改…但IKVM不是一个简单的类似dx的文件格式转换器。Java类的转换和Java核心API的适配是非常复杂的，即使对于一个简单的HelloWorld程序也是如此。每个平台的内部机制，如反射、安全性、并行性、异常处理、字节码验证、I/O以及其他核心API，在特性上基本相同，但在细节上完全不同。一些死胡同情况会迫使IKVM钻过一个又一个火圈，让Java代码继续运行。NET虚拟机。它需要依赖一个巨大的额外运行时层来适应来自OpenJDK源代码的完整JavaSE API。几年来我一直密切关注IKVM的发展——我读了这篇精彩的IKVM博客——所以我充分意识到他们为使Java程序和JavaSE应用程序适应。网。工作仍未完成；而且很多部分需要以损失一些性能为代价。)
(旧的Visual J++ Visual J#不是简单的Java-to-。网络转换器。我不想说，但是我们可以说，Visual J#与Java的兼容性并不比最早的IKVM好多少。)
我把P = NP引入讨论；有人引入图灵等价理论，说任何图灵完备的平台/语言/VM都是彼此等价的。没错，但与本题无关。图灵模型过于一般化；用这种肤浅的价值去考虑，会破坏更多的软件专利制度(虽然这不是坏事！)。我们需要在地面上为JVM等价画一条线，一条更接近实际需要而远离图灵等价的线。在我看来，这种琐碎的二进制格式转换、用尽的高级源代码和运行时兼容性，使得Android明显在Java等价的线内。
API和运行时是等价的。Android使用了相当大的JavaSE APIs子集。这些API(来自Harmony Project)都是全新的实现，但是它们是基于JavaSE建模的。如果不是TCK许可问题，Harmony本可以获得JavaSE认证。但这并不能改变Harmony和JavaSE APIs完全等价的事实——这是有意的，不是偶然的。正如著名的JRuby人物Charles Nutter最近写道:
Android支持Java 1.5类库的一个不完整(但相当大)的子集。这个子集非常大，以至于一个复杂的JRuby项目可以在Android上运行，不需要任何修改，限制也很少。
看来Dalvik离JVM这么近，还得完全兼容大部分JVM规范，包括完全详细的JMM(就像Android支持Java风格的线程和并发，已经深入到高级的java.util.concurrent包中)。但是为什么有那么多说法说Dalvik是新VM或者Dalvik不能运行Java类(讨论这个官司的论坛和博客90%都持这种观点)？
最后，这篇博客不是关于甲骨文和谷歌诉讼的法律依据。我会忽略(我会删除)那些跑题的评论(如果与Android = Java无关)。我就是讨厌“安卓与Java无关”这种废话；谷歌和安卓的拥护者必须找到一个更有意义的论点。
我会以我所有的先见之明，静观这场官司的进展，直到所有的细节和最终结果出来。不要天真，除非你有内幕消息(我没有)。保持冷静。我们不知道甲骨文或谷歌的所有真正动机和计划。我们不知道这个屏幕背后的故事。自从2007年Google第一次宣布Android诞生(导致JavaME生态环境崩溃)，孙就对其恨之入骨，但最后还是不得不夹着尾巴行动。我不相信任何一家6，543.8+0亿美元的股东控股公司会是利他的:谷歌不会，甲骨文不会，连我最喜欢的老孙公司也不会。让我们拭目以待。)
我不相信Google不能创造一个不偏离Java太远，基于Java风格的平台(as。NET做的)。Dalvik，以及Android框架，可能是权衡与大量现有Java程序、类库、Java天才、Java工具链高度兼容的愿望的最终结果。微软放弃了移植现成Java的好处，创造了一个全新的。网。谷歌没有这么做。
这个Android = Java等式显然没有包含一切(不是一一对应)。每个平台都有自己独特的API。当然，Android是一个完整的操作系统，包括一个基于Linux的内核、图形系统和电信栈等等。显然，我只说最常用的部分:以Java为中心的用户区域/应用框架，它依赖于Java源代码、Java类(不管格式如何)、Java APIs(包括成千上万常用的Java SEAAPIs)和优秀的类Java虚拟机。关于Android和其他Java平台的关系，一个准确的说法是使用版本的概念。我曾经记得有个博客说“安卓没有‘J’”。好吧，我现在说还不晚:建议安卓改名为Java GE(Java谷歌版)。这样，就再也不会导致混乱了。
希望能领养！