原生app和web app的区别

原生app和web app的区别为：来源不同、开发成本不同、流畅度相对不同。

一、来源不同

1、原生app：原生app是与移动设备所安装的操作系统所使用的同一种编程语言开发的APP。

2、web app：web app是由html5所做的网站通过一些打包平台或者使用工具打包而成的软件。

二、开发成本不同

1、原生app：原生app开发成本高，需要使用单独的开发工具进行开发。

2、web app：web app开发成本低，不需要使用单独的开发工具进行开发。

三、流畅度相对不同

1、原生app：原生app完美适配移动设备，流畅度相对较高。

2、web app：web app兼容适配移动设备，流畅度相对较低。

WebApp是指基于Web的系统和应用，其作用是向广大的最终用户发布一组复杂的内容和功能。

从一个简单的帮助消费者计算汽车租借费用的网页，到为商业人员和度假者提供全套旅游服务的大型复杂的WEB站点，都是WebApp。它包括一些完整的WEB站点，WEB站点的专门功能以及在Internet、Intranet或ExtraNet上的信息处理应用。

webapp 框架是一种简单的与WSGI兼容的网络应用程序框架，可以与 App Engine 配合使用。不必为了使用 App Engine 而使用 webapp：网络服务器支持任何使用 CGI 的 Python应用程序。webapp 提供一种简单的方式来开始为 App Engine 开发应用程序。

响应式网页设计的大部分技术，是可用在WebApp开发中的。

移动端Web App和WAP有什么不同？最直接的区别就是功能层面。WAP更侧重使用网页技术在移动端做展示，包括文字、媒体文件等。而Web App更侧重“功能”，是使用网页技术实现的App。总的来说，Web App就是运行于网络和标准浏览器上，基于网页技术开发实现特定功能的应用。

1开发方面

原生APP：每一种移动操作系统全部须要独立的开发项目，iphone版本、WP版本、安卓版本。每种平台全部须要独立的开发语言。Java(Android),Objective-C(iOS)等等，必须要使用各自的软件开发包，开发工具乃至各自的控件。开发费用高、开发速度慢、维护费用高。三个平台（IOS、安卓、windows）的规则、推广、运营全部不一样。官方应用商店对APP上线审核过程相对复杂并且慢长，严重影响APP的发布上线。

WebApp：因为运行在移动设备的浏览器上，于是只须要一个开发项目。能够通过HTML、CSS或许JavaScript来实行WebAPP的开发。开发费用低、开发速度快。

2功能方面

原生App：原生APP就是一个系统性的应用程序，能够类比在电脑上的软件。原生app能够调用移动终端的硬件设备，好比：麦克风、摄像头、短信、GPS、蓝牙、重力感应等。完成功能丰富

WebApp：WebAPP能够类比在电脑上的网页。WebAPP很多就是页面展示类的APP。只可以使用有限的移动硬件设备功能。很多用来页面展示，侧重在简单的交互，没办法使用很多硬件设备独特的功能。

3应用安装使用方面

原生App：须要通过应用商店会原生app下载到手机上或移动终端上。以独立的应用程序运行，用户必需手动去下载并安装这些原生App，原生应用能够节约宽带费用，能够访问本地资源、缓存。

WebApp：通过移动设备上的浏览器访问，软件更新只须要更新服务器就够了，用户层面不须要做一切操作。不须要安装客户端，能够节省手机终端的内存空间。

4版本控制方面

原生App：用户能够自由地选取能否更新软件版本，于是能显现不一样用户一起使用不一样版本的状况。一起同样能引起维护费用相对比较高。使用旧版本的用户没办法体验新版本的完整功能。

WebApp：全部的用户全部就是使用同样的版本，全部用户得到的功能全部就是一样的。版本更新相对比较便利，马上在服务器侧更新数据就可以。一个功能做好了就可以上线，1天更新几十次全部毫无压力。假如客户端不过是个浏览器，那所有都会变得非常简单。其它web统一性高，跨平台实用时开发量少。因为其入口不显著（浏览器导航或许随意点击链接进入），令用户记住的门槛同样随之拔高，每次推广导入的流量全部也许沦为一次性努力，用户留存率低。

5加载速度方面

原生App：原生APP由“云服务器数据APP应用客户端”两个别构成，APP应用全部的UI元素、数据内容、逻辑框架均安装在手机终端上。访问的时刻，不须要重新下载加载应用页面框架，只须要加载数据就可以。于是加载速度更快，页面响应更快。

WebApp：而WebAPP开启一个页面，全部需要重新加载页面的全部元素，访问速度受手机终端性能与网络环境的限制，引起加载速度慢，并且操作频繁容易卡死。

总结

原生App偏向在交互，注重用户体验（导航切换、勾选选项、相片、视频等操作），WebAPP偏向和浏览与简单的交互。一些功能须要访问硬件（摄像头、传感器等），使用原生App,WebAPP用来信息展示。费用有限时，中心的功能使用原生APP，周边辅助的功能能够使用WebApp。

现状：相对比较流行的技巧便是会原生App和WebApp实行融合，就是说应用大的框架就是原生的，其余详细的内容就通过网页封装，如此做的好处便是在方便更新的时候，同样可以确保中心功能的交互体验。

商领云可以定制开发APP以及h5网站，也可以入驻商领云SAASpaas系统进行在线制作APP、小程序、移动网站和微商城等。

通俗的讲，Web服务器传送(serves)页面使浏览器可以浏览，然而应用程序服务器提供的是客户端应用程序可以调用(call)的方法(methods)。确切一点，你可以说：Web服务器专门处理HTTP请求(request)，但是应用程序服务器是通过很多协议来为应用程序提供(serves)商业逻辑(business logic)。

下面让我们来细细道来：

Web服务器(Web Server)

Web服务器可以解析(handles)HTTP协议。当Web服务器接收到一个HTTP请求(request)，会返回一个HTTP响应(response)，例如送回一个HTML页面。为了处理一个请求(request)，Web服务器可以响应(response)一个静态页面或，进行页面跳转(redirect)，或者把动态响应(dynamic response)的产生委托(delegate)给一些其它的程序例如CGI脚本，JSP(JavaServer Pages)脚本，servlets，ASP(Active Server Pages)脚本，服务器端(server-side)JavaScript，或者一些其它的服务器端(server-side)技术。无论它们(译者注：脚本)的目的如何，这些服务器端(server-side)的程序通常产生一个HTML的响应(response)来让浏览器可以浏览。

要知道，Web服务器的代理模型(delegation model)非常简单。当一个请求(request)被送到Web服务器里来时，它只单纯的把请求(request)传递给可以很好的处理请求(request)的程序(译者注：服务器端脚本)。Web服务器仅仅提供一个可以执行服务器端(server-side)程序和返回(程序所产生的)响应(response)的环境，而不会超出职能范围。服务器端(server-side)程序通常具有事务处理(transaction processing)，数据库连接(database connectivity)和消息(messaging)等功能。

虽然Web服务器不支持事务处理或数据库连接池，但它可以配置(employ)各种策略(strategies)来实现容错性(fault tolerance)和可扩展性(scalability)，例如负载平衡(load balancing)，缓冲(caching)。集群特征(clustering—features)经常被误认为仅仅是应用程序服务器专有的特征。

应用程序服务器(The Application Server)

根据我们的定义，作为应用程序服务器，它通过各种协议，可以包括HTTP，把商业逻辑暴露给(expose)客户端应用程序。Web服务器主要是处理向浏览器发送HTML以供浏览，而应用程序服务器提供访问商业逻辑的途径以供客户端应用程序使用。应用程序使用此商业逻辑就象你调用对象的一个方法(或过程语言中的一个函数)一样。

应用程序服务器的客户端(包含有图形用户界面(GUI)的)可能会运行在一台PC、一个Web服务器或者甚至是其它的应用程序服务器上。在应用程序服务器与其客户端之间来回穿梭(traveling)的信息不仅仅局限于简单的显示标记。相反，这种信息就是程序逻辑(program logic)。 正是由于这种逻辑取得了(takes)数据和方法调用(calls)的形式而不是静态HTML，所以客户端才可以随心所欲的使用这种被暴露的商业逻辑。

在大多数情形下，应用程序服务器是通过组件(component)的应用程序接口(API)把商业逻辑暴露(expose)(给客户端应用程序)的，例如基于J2EE(Java 2 Platform, Enterprise Edition)应用程序服务器的EJB(Enterprise JavaBean)组件模型。此外，应用程序服务器可以管理自己的资源，例如看大门的工作(gate-keeping duties)包括安全(security)，事务处理(transaction processing)，资源池(resource pooling)， 和消息(messaging)。就象Web服务器一样，应用程序服务器配置了多种可扩展(scalability)和容错(fault tolerance)技术。

一个例子

例如，设想一个在线商店(网站)提供实时定价(real-time pricing)和有效性(availability)信息。这个站点(site)很可能会提供一个表单(form)让你来选择产品。当你提交查询(query)后，网站会进行查找(lookup)并把结果内嵌在HTML页面中返回。网站可以有很多种方式来实现这种功能。我要介绍一个不使用应用程序服务器的情景和一个使用应用程序服务器的情景。观察一下这两中情景的不同会有助于你了解应用程序服务器的功能。

情景1：不带应用程序服务器的Web服务器

在此种情景下，一个Web服务器独立提供在线商店的功能。Web服务器获得你的请求(request)，然后发送给服务器端(server-side)可以处理请求(request)的程序。此程序从数据库或文本文件(flat file，译者注：flat file是指没有特殊格式的非二进制的文件，如properties和XML文件等)中查找定价信息。一旦找到，服务器端(server-side)程序把结果信息表示成(formulate)HTML形式，最后Web服务器把会它发送到你的Web浏览器。

简而言之，Web服务器只是简单的通过响应(response)HTML页面来处理HTTP请求(request)。

情景2：带应用程序服务器的Web服务器

情景2和情景1相同的是Web服务器还是把响应(response)的产生委托(delegates)给脚本(译者注：服务器端(server-side)程序)。然而，你可以把查找定价的商业逻辑(business logic)放到应用程序服务器上。由于这种变化，此脚本只是简单的调用应用程序服务器的查找服务(lookup service)，而不是已经知道如何查找数据然后表示为(formulate)一个响应(response)。 这时当该脚本程序产生HTML响应(response)时就可以使用该服务的返回结果了。

在此情景中，应用程序服务器提供(serves)了用于查询产品的定价信息的商业逻辑。(服务器的)这种功能(functionality)没有指出有关显示和客户端如何使用此信息的细节，相反客户端和应用程序服务器只是来回传送数据。当有客户端调用应用程序服务器的查找服务(lookup service)时，此服务只是简单的查找并返回结果给客户端。

通过从响应产生(response-generating)HTML的代码中分离出来，在应用程序之中该定价(查找)逻辑的可重用性更强了。其他的客户端，例如收款机，也可以调用同样的服务(service)来作为一个店员给客户结帐。相反，在情景1中的定价查找服务是不可重用的因为信息内嵌在HTML页中了。

总而言之，在情景2的模型中，在Web服务器通过回应HTML页面来处理HTTP请求(request)，而应用程序服务器则是通过处理定价和有效性(availability)请求(request)来提供应用程序逻辑的。

警告(Caveats)

现在，XML Web Services已经使应用程序服务器和Web服务器的界线混淆了。通过传送一个XML有效载荷(payload)给服务器，Web服务器现在可以处理数据和响应(response)的能力与以前的应用程序服务器同样多了。

另外，现在大多数应用程序服务器也包含了Web服务器，这就意味着可以把Web服务器当作是应用程序服务器的一个子集(subset)。虽然应用程序服务器包含了Web服务器的功能，但是开发者很少把应用程序服务器部署(deploy)成这种功能(capacity)(译者注：这种功能是指既有应用程序服务器的功能又有Web服务器的功能)。相反，如果需要，他们通常会把Web服务器独立配置，和应用程序服务器一前一后。这种功能的分离有助于提高性能(简单的Web请求(request)就不会影响应用程序服务器了)，分开配置(专门的Web服务器，集群(clustering)等等)，而且给最佳产品的选取留有余地。

参考资料：

H5开发的web APP和原生APP的区别有以下几个方面：

一、开发方面

原生App

⊙ 每一种移动操作系统都需要独立的开发项目

⊙ 每种平台都需要独立的开发语言。Java(Android), Objective-C(iOS)以及Visual C(Windows Mobile)等等

⊙ 需要使用各自的软件开发包，开发工具以及各自的控件

移动Web App

⊙ 因为运行在移动设备的浏览器上，所以只需要一个开发项目

⊙ 这种应用可以使用HTML5,CSS3以及JavaScript以及服务器端语言来完成（PHP,Ruby on Rails,Python）

⊙ 这里可没有标准的SDK，基本任意选择别忘了有一些跨平台的开发工具，比如PhoneGap, Sencha Touch 2，APPcan以及 Titanium等等。

二、能力方面

原生App

⊙ 能够与移动硬件设备的底层功能，比如个人信息，摄像头以及重力加速器等等

移动Web App

⊙ 只能使用有限的移动硬件设备功能。

三、获取方法

原生App

⊙ 直接下载到设备

⊙ 以独立的应用程序运行(并不需要浏览器)

⊙ 用户必须手动去下载并安装这些原生App

⊙ 有一些商店与卖场来帮助用户寻找你的App，目前app市场不计其数

移动Web App

⊙ 从移动设备上的浏览器访问

⊙ 不需要安装额外的软件

⊙ 软件更新只需要服务器就够了

⊙ 因为现在没有什么商品或卖场提供这种App，所以如何搜索这些移动Web App相当不简单。

四、版本控制

原生App

⊙ 用户可以自由地选择是否更新软件版本，所以会出现不同用户同时使用不同版本的情况

移动Web App

⊙ 所有的用户都是用同样的版本

五、优势

原生App

⊙ 比移动Web App运行快

⊙ 一些商店与卖场会帮助用户寻找原生App

⊙ 官方卖场的应用审核流程会保证让用户得到高质量以及安全的App

⊙ 官方会发布很多开发工具或者人工支持来帮助你的开发

移动Web App

⊙ 跨平台开发

⊙ 用户不需要去卖场来下载安装App

⊙ 任何时候都可以发布App，因为根本不需要官方卖场的审核

⊙ 如果你已经有了一个Web App，你可以使用 responsive web design来辅助改进

六、缺陷

原生App

⊙ 开发成本高，尤其是当需要多种移动设备来测试时

⊙ 因为是不同的开发语言，所以开发，维护成本也高

⊙ 因为用户使用的App版本不同，所以你维护起来很困难

⊙ 官方卖场审核流程复杂且慢，会严重影响你的发布进程

移动Web App

⊙ 无法使用很多移动硬件设备的独特功能

⊙ 要同时支持多种移动设备的浏览器让开发维护的成本也不低

⊙ 如果用户使用更多的新型浏览器，那问题就更不好处理了

⊙ 对于用户来说，这种App很难被用户发现

附：原生App 与 移动Web App:您如何选择？

所以在你准备做移动App时，你应该先问问自己以下几个问题：

1 你的应用是否需要使用某些设备的特殊功能，比如摄像头，摄像头闪光灯或者重力加速器

2 你的开发预算是多少？

3 你的应用是否一定需要网络

4 你的应用的目标硬件设备是所有的移动设备还是仅仅只是一部分而已

5 你自己已经熟悉的开发语言

6 这个应用对于性能要求是否苛刻

7 如何靠这个应用赢利