为什么java中有很多android的应用程序，而windows的应用程序很少？

android 的哪些特性（与 windows 相比）使 java 的开发优先于本地语言？

答案很简单——这些特性是 android 的多平台特性和 Windows 的单平台特性。

也就是说，如果你用 C++ for Windows 编写，那么你给用户一个可执行文件，一切都可以在所有 Windows 上运行。如果你用 C++ 为 android 编写代码，那么你必须为现在 android 所在的所有移动平台重新翻译你的可执行文件，并且已经有五个（如果我没记错的话）。此外，如果 android 被移植到其他平台（这种情况令人羡慕的规律性发生），您将不得不为新平台重新翻译您的程序。

但是，如果您使用 Java 编写代码，那么您只需为 Java 机器制作一个字节码文件。当在特定平台上启动时，Java 机器要么解释您的字节码。特定平台上的 android 中的 JIT 编译器将您的字节码转换为本机代码并运行它。因此，在使用 Java 时，您不需要为 android 所在的所有目标平台制作可执行文件（并将在未来存在）。

有一个选项可以在 C++ 翻译后生成字节码。而且似乎这样的系统甚至存在。但它们不是主流。到目前为止，移动应用程序并没有特别加载，Java 性能足以打开一个窗口、绘制 5-10 个按钮、访问磁盘、访问网络和启动一个有趣的动画。

UPD1：

移动平台就是移动设备现在正在做的事情，所有这些智能手机、平板电脑、导航器等等。这是指移动设备中使用了哪些处理器。如果您查看维基百科，您会发现：“Android 可用于各种硬件平台，例如 ARM、MIPS、x86”。但即使是 ARM 架构也不是一个处理器，而是一堆不同的处理器，其中的指令系统已经从 ARMv6 发展到现代的 Cortex。因此，不同的移动设备内部有完全不同的处理器。并且使用 Java 机器可以让您不必为整个动物园制作可执行文件，而只需使用一个字节码文件即可。

UPD2：

但 Windows 也安装在具有不同处理器的计算机上。来自 wiki “Windows 在 x86、x86-64、IA-64 和 ARM 平台上运行。

放点东西，但没有字节码，就不可能有一个可执行文件在平台之间移植。我们必须为硬件平台的所有可能变体翻译程序，这很不方便。实际上，您的问题和我的答案中的问题是什么。

此外，ARM 和其他人的 Windows 不是 Windows，而是 Windows CE。在那里，只保留了 Windows 的名称，并且所有 API 都不同。来自同一个维基百科：

Windows Embedded 是一系列实时操作系统，专为在各种嵌入式系统中使用而设计。系统内核与 Windows CE 家族共享，支持 ARM、MIPS、SuperH 和 x86 处理器。

至于 x86、x86-64、IA-64 平台，则

1. IA-64 - 实际上死了
2. x86、x86-64 具有不同的位深度。我认为即使是字节码也不能让不同位深度的程序具有可移植性，也就是说，字节码在这种情况下是没有用的。

尽管如此，我们看到微软在.Net平台上也开始以Common Language Runtime和Common Intermediate Language的形式使用字节码。也就是说，微软也试图在未来的技术中依赖多平台。当然，Windows 本身与 x86 架构紧密相关，包括在使用 Intel 处理器寄存器参数的 API 函数调用级别，Windows 不太可能在其他平台上运行。所以所有这些通用中间语言都是未来的首选，或者他们可以使用通用中间语言来使网络技术具有可移植性。

同时，GCC 为 Windows x86、x86-64 立即原生生成代码，无需任何字节码且不知悲痛。

是的，仅在 Windows 的示例中，我们看到字节码的缺乏使 Windows 多平台的支持变得复杂。字节码的存在简化了多平台支持。对于移动设备，多平台是相关的，因此带有字节码的 Java 在 Android 中变得很流行，并得到了 Android 制造商的支持。

只是当 DOS 开始，然后 Windows 作为 DOS 的继任者时，没有人想到任何其他平台，也没有字节码和任何 JIT 编译器的资源。然后，当每个人都明白了，事实证明处理器不仅可以来自英特尔，他们开始要求软件技术支持多平台，Java 及其字节码的响应程度比立即生成本机代码要大得多。

同时，当 Unix 操作系统启动时，提供多平台支持的不是字节码和 JIT 编译器，而是因为在将 Unix 操作系统移植到新平台时必须重写大约 10% 的代码，包括重写翻译器的代码生成。但这与问题本身无关，只是一个题外话，作为一个事实的例子，即可以快速而廉价地（通过字节码）或缓慢而昂贵地提供多平台（通过为另一个硬件平台重写代码或翻译）另一个硬件平台的程序）。

java从硬件中提供了非常强大的抽象——所以要感到惊讶。这是Android下的主要语言。考虑到不同设备的数量，几乎不值得。此外，这种语言最初是为 Android 系统选择的，这也是它在那里占主导地位的原因。

Java 还提供了对操作系统的强大抽象，这对于不想与一个供应商绑定的公司来说是一个很大的优势。企业环境中的 Java 主要用于编写可以运行数十年的程序，在几代硬件和操作系统的变化中幸存下来。Java 中的桌面应用程序不太常见 - 因为与 GUI 相关的操作系统本身的功能更难以集成，Java 进入了一个已经占据的市场（C++、Delphi，然后是 C#）因此，份额更小。但是如果你需要编写一个可以在不同操作系统的桌面上运行的应用程序，那么真的没有那么多选择——如果你不想长时间学习 C++，那就更少了。但这样的任务并不那么频繁。

其他答案已经解释了为什么 Java 非常适合 Android。我将尝试解释 Java 不适合在 Windows 上进行桌面开发的原因之一。在我看来，这与速度无关，而是因为 Java 与本机库的交互相当不便。

当我们编写一个特定于 Windows（而不是跨平台）的应用程序时，我们显然希望使用它的一些特定 API：例如，用于图形的 DirectX、用于文件资源管理器集成的 Shell API，或用于高级键盘和鼠标交互。否则，何苦呢。所有这些 API 都是原生的（“原生”——即，它们在当前架构的机器代码中实现为二进制文件，并通过函数上的 C 接口或使用组件对象模型与外界交互）。此外，当您需要与某些特殊设备（例如财务登记员或条形码扫描仪）进行交互时，制造商为此提供的库通常也是本机的。问题是，Java (JNI) 中与本机代码交互的机制需要在 C++ 中为所有被调用的函数创建带有 JNICALL 声明的相当繁琐的包装器，而在 C# 中，例如，添加 P / Invoke 声明就足够了C# 代码本身的一行。此外，Java 中根本没有函数指针的类似物（C# 中的委托），这在本机库使用它们的情况下也是一个很大的缺点。使用 COM 时，差异更大。在 C/C++ 中，与本机库的交互更加容易，原因很明显。当本机库使用它们时。使用 COM 时，差别就更大了。在 C/C++ 中，与本机库的交互更加容易，原因很明显。当本机库使用它们时。使用 COM 时，差异更大。在 C/C++ 中，与本机库的交互更加容易，原因很明显。

当然，这些问题对于 Web 应用程序或简单的控制台实用程序来说并不重要，因此它们也可以在 Windows 下用 Java 编写。但复杂的 Windows 桌面应用程序通常使用 C/C++ 或 .NET 语言。

这与语言的速度或便利性无关，而与金钱有关。

Windows 应用程序是什么意思？一个典型的桌面，您需要安装、更新、与防病毒和防火墙交朋友。不要忘记检查许可证。而且您可能还必须与手鼓一起跳舞，也许请在那里的萨满使之起作用。通常，您用于我们程序的硬件已经过时 - 购买新的。

那么，为什么我，一个有钱的叔叔，需要这一切呢？有一个网络，在现代版本中可以做所有相同的事情，同时支持成本要低很多倍。不需要强大的计算机，不需要与用户数量成比例的管理员更改。

你看不到 JavaFx 的空缺，因为 95% 的市场是企业开发，而那里不再需要桌面，因为几乎所有任务（文档流、物流、ERP）都可以在 Web 上完成更有利可图。

好吧，关于android没什么好说的，原则上，你不能写Java以外的东西（或转换为java字节的代码）。