app跨平台开发会淘汰原生开发吗为什么如果不会，那何时使用跨平台开发何时使用原生开发

在本文中我们将为您展示在开发iOS平台(iPhone、iPad和iPod)应用前，您可能想问的10个问题。

1 我们目标应该是哪个平台

只有iOS (iPhone and iPad) 以及Android有足够的下载量、购买量以及使用量。其他平台也都有应用程序，但用户大部份都太少，或者应用程序的下载量都不足以支撑。也许未来可能会改变，但是以今日来说，这是不争的事实。

也许有人会争辩WP、Bada都可撑起一片江山，但在没有真切的放大量出来，不会建议一下子就冒进。

2 我们需要针对不同平台来开发不同的应用程序，或者是说有跨平台一次解决的框架

是的，你需要针对不同的平台开发不同的原生性应用程序。在市面上的确有许多的跨平台解决方案，但没有一个是够强大的，这些方案里包含了Sencha、SproutCore、Titanium。

长期来说，HTML 5将会拥有最强的产业支持并提供很棒的框架给应用程序开发。但这在接下来的18个月并不会发生。请记得一件最重要的事，一个iPhone应用程序必须看起来并使用起来像是一个iPhone应用程序;而Android应用程序必需像是一个Android应用程序;如果想要跨平台，先确保你要先知道原生应用程序的样子，才不会牺牲掉使用者经验。

我也认为HTML5终将会引领潮流，但整体应用与接受并不是迫在眉睫。是不是利用HTML 5跨平台或者使用原生应用程序，都不是重点，重点是在于使用者经验。

过去一年的经验里，不管是Foursquare、Viber、Instagram都已经作出最好的证明，他们都是以单一平台成功立基，强调单一平台「使用者经验」成功;如果只想一次搞定多平台，但却忽略在各平台里使用经验的差异，就已经是失败的开始。

3 每增加另一个平台，我们所需要多花费的开发时间会多上多久

这需视你开发的应用程序类型是哪种，但一般来说，大概是30～50%的时间。

4 有可能在内部布署应用程序，而不用透过公开的应用程序商店吗

是的，每个平台都有不同的解决方案，而且相当常见。

以笔者较为熟悉的iOS来说，一般做法可以使用 iOS Developer Enterprise Program，而当然，Adhoc Distribution也是另一种解法。

5 我们可以再利用在网站已经完成的系统介接吗

是的，应用程序应该尽可能利用现成的系统，通常在JSON的架构上，是不用再迭床架屋的。

6 iPhone 以及 Android 的学习曲线对比上，Objective C 会比 Java难学

这跟语言无关，这跟你锁定SDK有关(Cocoa Touch 或 Android SDK)，学习曲线差不多。

7 可以透过应用程序卖东西吗金流怎么走

可以的，以iPhone来说，Apple不会让询问使用者的xyk号，如果你选择使用苹果的账号，苹果会取走30%的手续费，大部份的在线零售业者会选择让使用者先建立一个使用者账号，然后让他们透过应用程序登入，这个账号可以用来开收据/登入xyk账号。这限制不存在Android应用程序上。

8 为什么不是一个网站，然后可以做一个适应手机浏览器的版本

应用程序为主的手机用户，偏好透过使用应用程序的功能来消费内容，IDG的数据支持此一观点，并显示应用程序驱动8倍于手机网站的流量。

就如同知名的LBS服务GoWalla CEO指出，使用者「压倒性」使用的就是原生性应用程序。在「强大」的html 5普及前(这包含了开发人力的普及以及所有网络服务的转向)，手机浏览器版本只能说是一个暂时解药，比没有好一些的方式。

9 App专案通常怎么运作

就像所有的软件开发项目：目的/用途、愿景、草图、可视化、设计、开发，测试以及上线。我们喜欢类似Scrum的开发方式，应用程序项目特别专注在用户经验以及接口上的设计。

10 通常一般的公司都从哪一类型的应用程序开始着手

一般都从他们网站上的既有功能开始着手，并开始加上应用程序属性的功能(像是GPS定位以及摄影)

跨平台，或者平台无关，是指程序代码在不同环境下具有完全相同的预期功能，可以互相替换。C语言的跨平台一般含义是：在指定的硬件和软件平台下能够正常编译的C语言源代码，在代码满足一定跨平台性的要求后，无需修改即可在另一硬件或软件下编译生成目标文件。这样，源代码是跨平台的。目标代码一般都是对应平台的本地代码，不能跨平台（例如obj和elf就不能直接混用；Windows和Linux上的可执行文件一般也不互相兼容）。C语言程序跨平台的实现必需编译环境的支持。对于库，提供源文件，或者提供不同平台下对应编译环境支持的目标文件（例如lib/a），可以实现跨平台开发。无法跨平台的部分，是平台相关的接口（例如一些 *** 作系统API），库通过实现一定的兼容层可以克服平台障碍（前提是硬件支持）。注意C语言的标准库在任何支持相同版本标准上的平台上的行为都是一致的（除了标准定义implemention defined或者undefined的部分，这些部分应该尽量避免使用），是跨平台的；同其它跨平台库一样，是实现跨平台开发的有力用具。在Win/Linux下进行跨平台开发，编译器主要用GCC；可以使用经过配置的MinGW、Cygwin环境；跨平台GUI开发可以考虑wxWidgets等库。

至于Java，它事实上就是一个平台（JVM，Java虚拟机），所谓的“一次编译，到处执行”的跨平台支持是通过不同的Java编译器和JVM来实现的。Java程序的源代码和目标代码都可以跨平台。但是不同的JVM可能实现了不同的特定功能，基于特定功能的部分无法保证跨平台。此外，native的本机代码和JVM之外的平台相关，和C一样，也无法保证跨平台。

多个平台可以使用多种跨平台软件，如：

1 PhoneGap：一款开源的移动应用开发框架，用于开发和打包跨平台的应用程序。

2 Xamarin：一款C#编程语言的跨平台开发工具，可用于开发Android、 iOS及UWP应用程序。

3 Qt：一款C++编程语言的跨平台开发工具，用于开发各种移动应用程序和桌面应用程序。

4 React Native：一款JavaScript语言的跨平台开发框架，可用于开发Android和iOS应用程序。

5 Weex：一款实用的跨平台开发工具，用于开发Android、iOS和Web应用程序。

理论上是可行的。

比如现在比较热门的uniapp、react-native都是跨平台的，都可以通过websocket的形式来开发即时通讯程序的。

HTML5中新增的websocket特性，可以实现服务端和客户端之间的双向通信，特别适合用来开发即时通讯功能。

不过自行搭建websocket服务会比较难，稳定性也不会太好。

推荐你使用我们当前项目正在使用的GoEasy提供的websocket推送框架，我们用来开发了我们自己的聊天室、在线客服等功能，目前使用情况不错。

目前来说做桌面应用程序最好的是C#Net，但是如果您要求跨平台的话，貌似只能选择使用java了。但是JavaSwing对于C/S架构的程序编写来说还是比较困难的。如果可能的话，尽量舍弃跨平台。

Windows及Mac OS X在 *** 作系统架构、开发环境、API、图形环境等环节上的相近处与不同的地方，也简单提出了跨平台应用程序开发的两种策略。事实上在两种平台上开发所需要了解的概念跟技能没有太大的不同，两种平台在性能上的差异也不大。大体说来，Windows和Mac OS X都是为桌面应用环境、图形用户接口(GUI)而设计的 *** 作系统。虽然不同平台细节各有特色，但两者相近的抽象概念，其实远远多于相左之处。本文试图指出方向上明显的异同所在，而非详细列举各种细项差别。最后，我也将简短分享自己在开发跨平台软件时的一些技巧和心得。

系统架构与开发环境的差异

用最简单的话来说，Mac OS X与Windows在架构与开发环境上最大的不同点在于：OS X是UNIX也不是UNIX；OS X主要开发工具Xcode使用GCC作为编译程序，与其他种类的UNIX相同；不过OS X也有独树一格的"bundle"软件包装格式这样的东西，成为它与其他 *** 作系统不同之处。

Windows和OS X都属于现代的 *** 作系统，所以Windows在 *** 作系统层级所提供的功能──执行文件与链接库加载、多任务与多线程、内存管理──在OS X上都找得到对等的API和作法。不过，相较于Windows在微软独力开发下，架构和API都维持着相对的一贯性（另一方面，也背负着各种历史遗迹和向下相容的包袱），Mac OS X则是底层源自NeXTSTEP的Mach微核心（现在称为XNU），而应用层（用准确的UNIX术语来说叫userland）来自FreeBSD 4。这件事情相当重要：OS X透过这样的`架构，才拥有和一般Linux/FreeBSD相似的UNIX应用环境。有相当多Mac软件开发者喜欢在UNIX shell下工作，使用各种UNIX工具。在Windows上，必须加装Cygwin之类的环境才能办到。

Apple几年前有则广告是「把其他牌子的UNIX送进/dev/null里」（用过UNIX的朋友应该不难体会其中的吹嘘意涵）。平心而论，OS X受益自UNIX环境之处不少。尤其，Apple使用了大量的open source工具。举例来说，Apple不像微软，没有自己的C语言编译工具，Apple用的是UNIX业界的标准──open source的GCC（其中当然有不少OS X的扩展功能就是）。虽然Apple有自己的开发环境Xcode，但是底层采用GCC这件事对开发者来说是相当重要的。同时，Apple的C/C++链接库用的也是GCC标准的stdc/stdc++。了解这个差异，在遇到与Microsoft C/C++ compiler不同的地方时，就更容易能找到解答的资源（这类型问题往往不限于OS X，其他UNIX平台也会发现）。

但是Mac OS X并不完全是UNIX。它的GUI环境（Aqua）就完全不是一般Linux/FreeBSD所使用的X11。而在UNIX层之下的微核心也和其他UNIX不同。接下来这一点很重要：OS X虽然有和Windows EXE和DLL相对应的文件（OS X跟其他UNIX一样，可执行文件一般不加扩展名，UNIX系的动态加载链接库则冠以dylib），但更重要的架构差异是bundle。

Bundle概念承袭自NeXTSTEP。简单来说，就是由 *** 作系统提供一种类似对象封装的文件包裹。OS X上最常见的bundle要属app结尾的应用程序了。虽然app外观上是个文件，在UNIX shell下看就能发现它其实是个目录，内含各种metadata（通常至少会有一个名为Infoplist的数据文件）、可执行文件、动态链接模块、各种资源等。除了app外，OS X的各种框架档（以framework结尾，是一种同时包含头文件及链接库的包装）、应用程序的外挂模块（通常以bundle结尾）等等，都是以bundle形式呈现的。了解这个差异，才能了解为什么OS X上很少有程序需要额外的安装程序，也鲜少听说有所谓的"DLL hell"（因共享链接库版本不兼容造成的困扰）。

多的IT经理停滞了他们对系统的更新的需求，他们希望在自己的PC升级上配合他们的Windows 7部署。"

一旦Windows 7开始了面向公众的发布，使IT店铺部署Windows XP的比率毫无疑问将出现下降。在其发布的18个月中，或者说在第一个Windows 7版本服务包的发布之后，"OEM许可证与每台PC的绑定将不再进行面向Windows XP的降级。"这就是说，基本上，在企业或SMB（中小型企业）内部署的XP将需要在未使用任何属于Windows XP的批量许可证或购买XP的批量许可证复制从而使用XP。这增加了一个额外的步骤，面向采购过程的IT管理人员可能不愿意参加。

对于Windows XP的支持也将结束，这对那些想继续使用旧版 *** 作系统的IT部门来说增加了不小的复杂性。对Windows XP SP 2、SP 3进行扩展支持的服务将于2014年4月结束，在该日期之后将不再有任何面向XP的更新或补丁。

是。

Qt支持下列 *** 作系统:MicrosoftWindows95/98，MicrosoftWindowsNT，Linux，Solaris，SunOS，HP-UX，DigitalUNIX(OSF/1，Tru64)，Irix，FreeBSD，BSD/OS，SCO，AIX，OS390，QNX等等。

Qt是一个1991年由QtCompany开发的跨平台C++图形用户界面应用程序开发框架。它既可以开发GUI程序，也可用于开发非GUI程序，比如控制台工具和服务器。Qt是面向对象的框架，使用特殊的代码生成扩展（称为元对象编译器(MetaObjectCompiler,moc)）以及一些宏，Qt很容易扩展，并且允许真正地组件编程。

以上就是关于app跨平台开发会淘汰原生开发吗为什么如果不会，那何时使用跨平台开发何时使用原生开发全部的内容，包括:app跨平台开发会淘汰原生开发吗为什么如果不会，那何时使用跨平台开发何时使用原生开发、跨平台C，C++代码注意的事项及如何编写跨平、平台商家发送多个平台叫什么软件等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！