java 硬件平台_如果硬件不同，那么java还能跨平台吗？

跨平台是个非常粗的概念，大概说明了写完了代码之后可以在不同的环境跑。跨平台的意义在于可以极大地降低开发成本。

但无论如何，跨平台无法保证不同平台对于同一份代码能够跑出同样的效果。不同的平台之所以叫“不同的”平台，就是因为他们的运行机制可能完全不同，底层API也不同，硬件也可能不同。这就像你无法保证北京和天津的“煎饼”代表同一个东西一样。于是能否认为一个东西跨平台完全取决于你能不能“忍受“不同的差异。如果这个差异在实际上可以忍，那就叫跨平台；不能忍，就没法跨，必须得自己动手丰衣足食。而且可以跨多少种平台可以具体问题具体分析

举个例子，Linux上和Windows上都提供了文件IO接口。用Java写读取文件的代码，普通场景下基本上感觉不到什么差异，因为此时你只关心：给一文件路径，可以读出bytes来。所以跨平台看起来毫无问题。但是如果你在做某种高性能文件IO，用普通IO接口无法支撑高性能的IO。于是你想优化IO，此时会发现Windows下的IOCP和Linux下的AIO的API完全不同。此时你必须做一个选择：

1)把二者的区别抽象，对上形成一套接口，隐藏他们的区别。此时你的代码就是“跨平台的一部分”，或者

2)放弃跨平台，只支持某种特定的系统。

至于怎么做看实际的需求和性价比。

看看实际的例子。

比如OS提供一般要求需要支持很多个硬件平台。OS自己就是跨平台的一部分。

再比如Web后端开发可以只装同一套OS/硬件做，代码又不会给别人用。因此就算用着java的“跨平台”的API，实际上只要求这套API在目标OS/硬件能够正确高效的跑就行了。跨不跨平台的无所谓(除非某天美国全面封禁x86的芯片，需要所有后台服务代码都用另外一种架构跑……)

而对于前端，因为有各种各样不同的设备，不同的渲染机制，跨平台的诉求就会大很多。但同时因为不同设备厂商也会更加强调自己的【与众不同的优势】，会提供特殊的硬件/API，反而会让跨平台变的无比艰难。这就需要跨平台技术能够找到那些技术的共同的部分，提取出来；还得把不同的部分以某种形式提供出来，让开发者自己搞定(嗯，不知道现在还有没有给IE8写前端代码的)

目前写一个App，一般厂商会开发Android的版本和iOS的版本，Android版本再去适配多种不同的Android机型。如果这俩也要跨目前可以用Flutter。但比起节省的代码量，因为踩Flutter的坑代价可能更大，并且并不是所有功能都可以用Flutter解决的，所以会给团队带来额外成本。但坑踩一次就可以了，如果后面可以反复使用，长期看成本会被摊薄。因此对于大厂就可以试试。

已知的不同可能还相对好处理。但未知的呢？你好不容易终于达到了写一套代码多设备完美运行。但突然有一天，某厂商出了折叠屏……屏幕忽大忽小，于是你不得不一边骂着MMP，一边写新的if……