㈠ 原生app和webapp的区别
原生app和webapp的区别为：来源不同、开发成本不同、流畅度相对不同。
一、来源不同
1、原生app：原生app是与移动设备所安装的操作系统所使用的同一种编程语言开发的APP。
2、webapp：webapp是由html5所做的网站通过一些打包平台或者使用工具打包而成的软件。
二、开发成本不同
1、原生app：原生app开发成本高，需要使用单独的开发工具进行开发。
2、webapp：webapp开发成本低，不需要使用单独的开发工具进行开发。
三、流畅度相对不同
1、原生app：原生app完美适配移动设备，流畅度相对较高。
2、webapp：webapp兼容适配移动设备，流畅度相对较低。
㈡ h5做app和原生app有什么区别
一、功能更强大
从以上定义中可以看出，原生APP是系统性的应用程序，可以地用手机终端的硬件设备，比如语音、短信、GPS、蓝牙、重力感应和摄像头等，但是webAPP是不可以做到这些的。所以如果你想做一个可扩展性强，而且后期功能不断完善的APP，一定要考虑原生的。 二、 加载速度更快
刚我们有提到原生APP是由 “云服务器数据+APP应用客户端” ”两部分构成，APP应有所有的UI元素、数据内容、逻辑框架都是安装在手机里的。所以用户在使用APP的时候，不需要重新加载数据，因为这些内容都安装在手机中了，虽然第一次安装的时候有点复杂，但是在实际使用会方便很多。
济南APP开发定制
但是web APP打开每一个页面，都需要重新加载，虽然现在网络情况很好了，但是在实际中可能会有各种问题，比如流量用完了、所在区域网络不好或出了问题，就很大可能出现加载慢或者加载不出来的问题，加载多了很容易出现卡死错乱的情况，用户的体验就会很差。因此考虑到用户体验和加载速度方面，原生APP的性能要远远优于web。
第三：稳定性更好
目前市场的web版的APP多为模板，这种模板价格便宜，但是功能无法拓展，而且随着市场上浏览器、技术的进步，会逐步出现各种问题，稳定性根本无法保证。相比而言原生的APP技术更加成熟，而且功能可以拓展性更强。做个简单的比喻，我们有一套房子，这个房子可以考虑自己建设，这个过程中我可以决定建几层、建成什么样的户型等等，但如果其买别人做好的，那就只能从已经有的中选择。如果遇到网络不好的情况可能就像等期房一样，只大体知道是啥样的，但具体的得等网络好了才能看到。
㈢ h5开发和原生app开发以及web开发有什么区别呢
一、开发方面
原生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以及Appcelerator 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开发的相关信息，推荐咨询猪八戒网。猪八戒网有千万服务商为企业、公共机构和个人提供定制化的解决方案，将创意、智慧、技能转化为商业价值和社会价值。2011年猪八戒网获得IDG投资并被评选为中国2011年度“最佳商业模式十强”企业；专业性值的信赖。
㈣ 微信小程序出来了，原生 App 和 Web App有什么区别
原生 App 是为了实现某项功能，针对特定设备设计的产品，他们需要安装到设备上使用，通常能都调用设备上的其他硬件功能，我们通过App Store或者各大安卓应用市场下载的App均属于原生 App范畴；而Web App直接利用设备上的浏览器访问，不需要下载安装，实现了跨平台。就目前而言原生 App可以最大程度的对手机硬件资源进行利用，在性能、交互、设计、展现效果上远远超过Web App的软件和服务，但是由于开发成本低、发布周期短、维护简单等优势，也不乏一些创业者通过这种轻量级的应用进行产品快速的市场验证。
㈤ 现在开发app是web还是原生
昆明天度APP开发模式通常分为Web APP与Native APP原生模式两种，这两种模式均各自有自己的优势，到底是采用Native App开发还是采用Web App开发一直是业界争论的焦点，但是随着HTML5的发展及云服务普及，采用HTML5进行Web App开发正在成为一种趋势，用户可以根据应用特点和需求进行选择，亦可选择两者混合模式： Native App开发 Native App开发即我们所称的传统APP开发模式（原生APP开发模式），该开发针对IOS、Android等不同的手机操作系统要采用不同的语言和框架进行开发，该模式通常是由“云服务器数据+APP应用客户端”两部份构成，APP应用所有的UI元素、数据内容、逻辑框架均安装在手机终端上。 Web App开发 Web App开发即是一种框架型APP开发模式（HTML5 APP 框架开发模式），该开发具有跨平台的优势，该模式通常由“HTML5云网站+APP应用客户端”两部份构成，APP应用客户端只需安装应用的框架部份，而应用的数据则是每次打开APP的时候，去云端取数据呈现给手机用户。 原生APP开发及Web APP开发模式的区别 Web APP需开发“html5云网站”和“APP客户端”，昆明天度网络公司总结这类型APP应用呈现以下特点： （1）每次打开APP，都要通过APP框架向云网站取UI及数据； （2）手机用户无法上网则无法访问APP应用中的数据。 （3）框架型的APP无法调用手机终端的硬件设备（语音、摄像头、短信、GPS、蓝牙、重力感应等） （4）框架型APP的访问速度受手机终端上网的限制，每次使用均会消耗一定的手机上网流量； （5）框架型APP应用的安装包小巧，只包含框架文件，而大量的UI元素、数据内容刚存放在云端； （6）APP用户每次都可以访问到实时的最新的云端数据； （7）APP用户无须频繁更新APP应用，与云端实现的是实时数据交互； 适用企业：电子商务、金融、新闻资讯、企业集团需经常更新内容的APP应用。 Native App（原生型APP）需要开发“云服务器数据中心”和“APP客户端”，昆明天度网络公司总结这类型的APP应用呈现以下特点： （1）每次获取最新的APP功能，需要升级APP应用； （2）原生型APP应用的安装包相对较大，包含UI元素、数据内容、逻辑框架； （3）手机用户无法上网也可访问APP应用中以前下载的数据。 （4）原生型的APP可以调用手机终端的硬件设备（语音、摄像头、短信、GPS、蓝牙、重力感应等） （5）APP应用更新新功能，涉及到每次要向各个应用商店进行提交审核。 适用企业：游戏、电子杂志、管理应用、物联网等无需经常更新程序框架的APP应用。 到底该如何选择Web App和Native App开发模式 移动Web无所不在，移动Web是目前唯一的支持各种设备访问的平台，与桌面Web一样，移动Web支持各种标准的协议。移动Web也是唯一一个可供开发者发布移动应用的平台，它将各种移动交互与桌面任务有效地连接了起来；而开发Native App可以充分利用设备的特性，而这一点往往是Web浏览器做不到的，所以对一个产品本身而言，Native App是最佳的选择。下面几节将讨论一下Native App的一些主要功能。 什么时候应该选择Native App 1.为应用收费 没有任何地方规定开发者不能对一个移动Web App收取使用费，但是由于某些原因，人们常常认为不能或是不应该对一个Web App收取费用。由于历史原因，导致移动设备上付费服务遭遇两大阻力： 2.付款方式 在移动设备上输入信用卡号相当麻烦，而且在许多老式设备上也没有安全保障。一种典型的方式是，如果你需要对你的应用收费，你可以与运营商达成协议，让运营商代为为你的服务收费。这也意味着，你需要和多个运营商达成合作。这通常是首选的方法，因为许多手机用户可能根本就没有信用卡，比如青少年。 另一种方法是将用户的信用卡信息保存在一个安全的网站上。用户可以通过登录到该网站购买应用服务。这个过程不算特别理想，因为这意味着用户不能直接通过他们的移动设备购买服务了。 3.强制分成 移动运营商是会提成的。App无论是通过运营商还是通过移动设备发布，他们都为应用提供了一套收费机制。这些运营商和移动设备将会提取部分收益，然后将剩余的部分交给应用开发商，这也意味着，开发人员必须遵守他们的市场规则。适应运营商的市场规则通常是非常困难的，需要投入大量的人力资源。相比而言，移动设备的市场规则则简单许多，但是也存在不少的困难。 妨碍运营商和移动设备开发商利益的应用以及服务都将受到阻扰。过去，那些不靠运营商和移动设备开发商运作的网站如果收入过于显眼的话，都逃脱不了被关闭的命运，但是最近，这样的事情鲜少发生了。 如果你想为你的Native App收费，那么你就必须接受这个现实——你必须遵守别人的市场规则，还得放弃部分收益。 4.开发游戏 如果你是想开发一个移动游戏（移动游戏是移动市场上最大的一块），那么你需要开发一个Native App。游戏对资源的占用很大，并且需要使用许多设备API或平台API。虽然，现在有几款完全使用Web技术开发的游戏占有了一定的市场份额，但是和Native App市场的占有情况相比，还是微不足道的。游戏用户对应用的视觉和操作效果要求很高。移动Web虽然提供了一些仿真体验，但还远远不能满足用户的需求。 在开发移动游戏时，你需要慎重考虑你的应用需要支持哪些平台。幸运的是，现在有许多工具能够帮助你将你的游戏推向多个平台，但是完成这些工作，还是需要花费大量的人力和物力。 5.使用定位功能 下一个功能就是定位功能，可以通过GPS或者是信号检测确定用户当前的位置信息。以前只能通过Native App的APIs查看用户的位置信息，但现在大多数主流移动浏览器上都嵌入了W3C Geolocation API。像iPhone或Android这样安装了WebKit的设备，或是配置了Opera或Mozilla浏览器的设备，都可以获取用户的位置信息。 我相信定位功能会为Web技术带来许多全新的应用。如果能够合理利用Web浏览器，Web开发商就能使用用户的位置信息和其他内容开发出更加有趣的应用。虽然这在技术上没有太大的困难，但却受到隐私保护条例的限制。我们将Web浏览器当做是用户进入World Wide Web的入口。加入定位功能，意味着在网站中引入了一些敏感信息，这有可能导致严重的后果。但是位置感知应用中显示的位置信息必须经过用户的授权，用户当然有权禁止应用发布自己的位置信息。 6.使用摄像头 摄像头可以为你的应用提供丰富的可能性。以往移动MMS（Multimedia Messaging Service）被用于处理移动照片。换言之，你拍了一张照片后，需要使用MMS将它传送给一个服务器，服务器对照片做出相应的处理，并将处理完成的结果通知给你。这个过程是非常耗时的，而且相当复杂，也没有可靠性保障。 通过访问摄像头，Native App开发者能够简化拍照的过程。用户可以直接在客户端对照片做一些简单的处理，只有在有需要的时候才将照片上传给服务器，而且是通过可靠的HTTP传输。W3C正在开发一个访问摄像头的API，但现在还没有将这部分工作正式整合到浏览器中。 在许多类型的移动Apps中，摄像头是非常有用的，比如快拍应用、短片拍摄应用等等，摄像头可以用来捕捉许多重要的瞬间。不久的将来，我们可以看到——只要通过摄像头拍摄某个标识，应用程序就能自动完成对标识上的语言转换工作——这个技术在日本已经开始流行起来了。 7.使用感应器 现在越来越来越多的移动设备上都新增了感应器功能，该装置可以感知设备的物理速度以及重力，并将感知的数据结果传送给设备。这个装置常被用来感应设置是否被翻转，应用根据接受到的信息自动调节画面的方向。 感应器可以用来帮助用户提升与设备交互时的真实感；大多数移动设备都是手持的，应用能够根据设备的方向调整内容画面，比如翻转屏幕，或是检测物理移动，并能据此猜测用户所处的环境。举一个简单的例子：比如用户正在走路，那么感应器能够检测到一个轻缓的移动或是速度，这时可以为用户提供一个大字体的用户界面，从而使得用户更容易看清屏幕上的内容。 然而，开发者也不能过分依赖感应器，因为感应器无法区分究竟哪些交互是有意的，而哪些是没有意义的。每个移动交互都需要通过“传输测试”。设计你的交互时必须考虑用户在一个拥挤的汽车或是火车上的场景。考虑一下如果用户正身处拥挤的地铁或是正在驾车时，你的应用能否正确处理用户摇晃移动设备的动作。通常，大多数开发者都没有考虑这些因素。确保为每个任务设计一个备用方案以处理特殊场景中的移动交互。 8.访问文件系统 如果你的应用需要将数据保存在本地，那么你需要开发一个Native App。比如你要保存用户的地址簿、电话或E-mail信息，或是保存从其他设备上获取的数据。 访问文件系统常常会涉及到安全和用户隐私保护的问题。恶意应用程序可能会修改或是删除你的移动设备上的数据。一个携带病毒的应用程序可以利用移动设备上的关系网将病毒扩散到许多其他的手机上，在采用移动应用认证机制以前，这种事情是常常发生的。 另一方面，移动设备正变得越来越私人化，移动设备上保存了大量用户的个人信息，以及用户的朋友信息和商业信息。针对这些私人信息开发应用是一个不错的想法。但是这也存在一定的风险，使用保存在移动设备上的数据可以为用户提供更加有针对性的服务。 开发者必须谨记，只有在获得用户的授权后才能访问用户的私人数据。我们看到许多应用在没有得到用户授权的情况下使用了大量的用户私人数据，而被误认为是垃圾信息或是钓鱼应用，即使这些应用原本是在提供一些非常有用的服务。人们对你的应用的误解将会影响到你的服务的推广，如果运营商收到过多关于你的应用的投诉，那么你的服务可能将被终止，甚至会牵连其他的应用。 访问文件系统时至关重要的一点就是在没有获得用户授权的情况下，不要访问任何用户的私人数据。而这一点，往往被大多数应用忽略了。W3C正在为移动开发商开发相关的标准API，但目前该工作尚未完成。 9.离线用户 最后一个需要开发Native App的理由就是，用户有可能是离线的或者无法接入移动网络。这在城市可能很少发生，即使是在农村，网络的覆盖也已经逐步普及了。但是短暂的网络连接中断还是时常发生的，你的应用程序应该考虑如何处理这种情景。 想想用户通常在什么时候，在哪里会使用你的App。如果是一个移动游戏，那么用户很可能在飞机上使用这个App。跟踪地图应用常在偏远且网络覆盖不佳的地方使用。移动旅游向导常在一个国外的网络中访问，往往需要支付漫游和国际网络费用。这时，应用程序最好能够为用户提供离线服务，保证用户在不接入网络的情况下，仍然能享受同等的服务。 现在支持HTML5的浏览器也能实现脱机访问功能，但对用户来说可能不太明显。随着越来越多的浏览器都开始支持脱机访问，应用需要明确地告诉用户网络连接中断时，他们仍然可以访问移动Web Apps。 Native Apps常常假设网络连接是可靠的。App通常只考虑了网络状况良好的情景，想当然地认为网络是封闭的，并且网速足够快。移动设备从网络良好的环境突然进入一个网络糟糕的环境并不少见。Native Apps应该在网络状况最差的情况下测试。比如用户启动任务时可能还是全信号覆盖，而在任务结束时可能已经完全没有网络信号了。 用户在安装Native Apps时，根本不会考虑是在线访问还是离线访问——他们期望的是不管在任何状况下，Native Apps都能正常工作。而这也是开发者的职责。 什么时候应该选择Web App 只要你的应用程序不满足之前提到的Native App条件之一，那么你就没有必要开发一个Native App，而应该选择开发一个Web App。正如文章之前提到的，我是一个Native App的拥护者，我认为Native App有许多优秀的特质，并且具有很大的市场潜力，但是Web Apps是唯一一个经久不衰的移动内容、服务、应用开发平台。 Native App并不能明显地为用户提供更好的服务；它反而会增加项目的成本，减少了应用发布的渠道，增加了App升级的复杂度，削弱了开发者对应用的控制和利润，并且可能会给设备带来麻烦。Native App可以为开发者带来短期的效益，但这是有一定风险的，甚至可能会影响到移动市场的可持久发展。 移动Web App的优势在前文中已经提到过了。如果上一节提到的几点功能是促成你选择Native App的唯一原因，那么如果能够在移动浏览器上屏蔽这些障碍，你是否还会坚持选择Native App呢？Palm的webOS已经着手解决了上述的部分问题。他们基于WebKit构建了一个全移动操作系统，将手机变成了一个Web浏览器。所谓的“Native Apps”实际上就是一个Web Apps。 PhoneGap也是一个类似的项目，这个开源项目用于帮助开发者在iPhone、Android以及BlackBerry设备上开发Native Apps，并且能够模拟设备上的功能（如定位功能和文件系统）供Web Apps调用。这些代码可以在各个设备的应用商店中发布并且出售，但是他们使用的通用代码和设计是可以共享的。由于开发的是一个Web App，开发者可以为低端的移动浏览器开发一个简化版的应用。只用开发一次，就可以部署在多个平台上了， 对于那些有着丰富的移动开发经验的程序员来说，一提到“要开发一个功能丰富的应用”时，可能首先想到的就是Native App。虽然在很多设备上，这一想法仍然适用，但是现在移动Web Apps上也提供了足够丰富的功能接口供开发者调用。这使得Web App不仅可以像Native App一样被设计得功能丰富界面绚丽，而且还能在各个平台上迁移，甚至不用修改一行代码。 现在在移动设备开发中，移动Web Apps的创新进入了前所未有的高潮时期。但更重要的是，这是有史以来第一次，移动设备开发商决定共同制定一个移动Web开发的标准，就像是桌面Web上的标准一样。不仅如此，那些支持移动Web App创新功能的设备或是支持第三方浏览器的移动设备都受到消费者的欢迎。
㈥ H5和原生APP之间的区别
实际上他们的底层都是一样的。
H5写的APP是基于html、js等语言编写的。原生APP用原生的语言与java、c等编写的。
H5写的APP调用机子的一些设备时仍是需要通过底层接口实现的。H5写的APP在不同系统的机子上兼容性更好。
原生APP调用一些接口的速度一般比H5的快，不过现在智能机处理速度都很快，因此用户基本上都看不出来。
㈦ 如何选择Web APP与Native App原生开发模式的区别，APP开发模式比较
APP开发模式通常分为Web APP与Native APP原生模式两种，这两种模式均各自有自己的优势，到底是采用Native App开发还是采用Web App开发一直是业界争论的焦点，但是随着HTML5的发展及云服务普及，采用HTML5进行Web App开发正在成为一种趋势，用户可以根据应用特点和需求进行选择，亦可选择两者混合模式：
Native App开发
Native App开发即我们所称的传统APP开发模式（原生APP开发模式），该开发针对IOS、Android等不同的手机操作系统要采用不同的语言和框架进行开发，该模式通常是由“云服务器数据+APP应用客户端”两部份构成，APP应用所有的UI元素、数据内容、逻辑框架均安装在手机终端上。
Web App开发
Web App开发即是一种框架型APP开发模式（HTML5 APP 框架开发模式），该开发具有跨平台的优势，该模式通常由“HTML5云网站+APP应用客户端”两部份构成，APP应用客户端只需安装应用的框架部份，而应用的数据则是每次打开APP的时候，去云端取数据呈现给手机用户。
原生APP开发及Web APP开发模式的区别
Web APP需开发“html5云网站”和“APP客户端”，昆明天度网络公司总结这类型APP应用呈现以下特点：
（1）每次打开APP，都要通过APP框架向云网站取UI及数据；
（2）手机用户无法上网则无法访问APP应用中的数据。
（3）框架型的APP无法调用手机终端的硬件设备（语音、摄像头、短信、GPS、蓝牙、重力感应等）
（4）框架型APP的访问速度受手机终端上网的限制，每次使用均会消耗一定的手机上网流量；
（5）框架型APP应用的安装包小巧，只包含框架文件，而大量的UI元素、数据内容刚存放在云端；
（6）APP用户每次都可以访问到实时的最新的云端数据；
（7）APP用户无须频繁更新APP应用，与云端实现的是实时数据交互；
适用企业：电子商务、金融、新闻资讯、企业集团需经常更新内容的APP应用。
Native App（原生型APP）需要开发“云服务器数据中心”和“APP客户端”，昆明天度网络公司总结这类型的APP应用呈现以下特点：
（1）每次获取最新的APP功能，需要升级APP应用；
（2）原生型APP应用的安装包相对较大，包含UI元素、数据内容、逻辑框架；
（3）手机用户无法上网也可访问APP应用中以前下载的数据。
（4）原生型的APP可以调用手机终端的硬件设备（语音、摄像头、短信、GPS、蓝牙、重力感应等）
（5）APP应用更新新功能，涉及到每次要向各个应用商店进行提交审核。
适用企业：游戏、电子杂志、管理应用、物联网等无需经常更新程序框架的APP应用。
到底该如何选择Web App和Native App开发模式
移动Web无所不在，移动Web是目前唯一的支持各种设备访问的平台，与桌面Web一样，移动Web支持各种标准的协议。移动Web也是唯一一个可供开发者发布移动应用的平台，它将各种移动交互与桌面任务有效地连接了起来；而开发Native App可以充分利用设备的特性，而这一点往往是Web浏览器做不到的，所以对一个产品本身而言，Native App是最佳的选择。下面几节将讨论一下Native App的一些主要功能。
什么时候应该选择Native App
1.为应用收费
没有任何地方规定开发者不能对一个移动Web App收取使用费，但是由于某些原因，人们常常认为不能或是不应该对一个Web App收取费用。由于历史原因，导致移动设备上付费服务遭遇两大阻力：
2.付款方式
在移动设备上输入信用卡号相当麻烦，而且在许多老式设备上也没有安全保障。一种典型的方式是，如果你需要对你的应用收费，你可以与运营商达成协议，让运营商代为为你的服务收费。这也意味着，你需要和多个运营商达成合作。这通常是首选的方法，因为许多手机用户可能根本就没有信用卡，比如青少年。
另一种方法是将用户的信用卡信息保存在一个安全的网站上。用户可以通过登录到该网站购买应用服务。这个过程不算特别理想，因为这意味着用户不能直接通过他们的移动设备购买服务了。
3.强制分成
移动运营商是会提成的。App无论是通过运营商还是通过移动设备发布，他们都为应用提供了一套收费机制。这些运营商和移动设备将会提取部分收益，然后将剩余的部分交给应用开发商，这也意味着，开发人员必须遵守他们的市场规则。适应运营商的市场规则通常是非常困难的，需要投入大量的人力资源。相比而言，移动设备的市场规则则简单许多，但是也存在不少的困难。
妨碍运营商和移动设备开发商利益的应用以及服务都将受到阻扰。过去，那些不靠运营商和移动设备开发商运作的网站如果收入过于显眼的话，都逃脱不了被关闭的命运，但是最近，这样的事情鲜少发生了。
如果你想为你的Native App收费，那么你就必须接受这个现实——你必须遵守别人的市场规则，还得放弃部分收益。
4.开发游戏
如果你是想开发一个移动游戏（移动游戏是移动市场上最大的一块），那么你需要开发一个Native App。游戏对资源的占用很大，并且需要使用许多设备API或平台API。虽然，现在有几款完全使用Web技术开发的游戏占有了一定的市场份额，但是和Native App市场的占有情况相比，还是微不足道的。游戏用户对应用的视觉和操作效果要求很高。移动Web虽然提供了一些仿真体验，但还远远不能满足用户的需求。
在开发移动游戏时，你需要慎重考虑你的应用需要支持哪些平台。幸运的是，现在有许多工具能够帮助你将你的游戏推向多个平台，但是完成这些工作，还是需要花费大量的人力和物力。
5.使用定位功能
下一个功能就是定位功能，可以通过GPS或者是信号检测确定用户当前的位置信息。以前只能通过Native App的APIs查看用户的位置信息，但现在大多数主流移动浏览器上都嵌入了W3C Geolocation API。像iPhone或Android这样安装了WebKit的设备，或是配置了Opera或Mozilla浏览器的设备，都可以获取用户的位置信息。
我相信定位功能会为Web技术带来许多全新的应用。如果能够合理利用Web浏览器，Web开发商就能使用用户的位置信息和其他内容开发出更加有趣的应用。虽然这在技术上没有太大的困难，但却受到隐私保护条例的限制。我们将Web浏览器当做是用户进入World Wide Web的入口。加入定位功能，意味着在网站中引入了一些敏感信息，这有可能导致严重的后果。但是位置感知应用中显示的位置信息必须经过用户的授权，用户当然有权禁止应用发布自己的位置信息。
6.使用摄像头
摄像头可以为你的应用提供丰富的可能性。以往移动MMS（Multimedia Messaging Service）被用于处理移动照片。换言之，你拍了一张照片后，需要使用MMS将它传送给一个服务器，服务器对照片做出相应的处理，并将处理完成的结果通知给你。这个过程是非常耗时的，而且相当复杂，也没有可靠性保障。
通过访问摄像头，Native App开发者能够简化拍照的过程。用户可以直接在客户端对照片做一些简单的处理，只有在有需要的时候才将照片上传给服务器，而且是通过可靠的HTTP传输。W3C正在开发一个访问摄像头的API，但现在还没有将这部分工作正式整合到浏览器中。
在许多类型的移动Apps中，摄像头是非常有用的，比如快拍应用、短片拍摄应用等等，摄像头可以用来捕捉许多重要的瞬间。不久的将来，我们可以看到——只要通过摄像头拍摄某个标识，应用程序就能自动完成对标识上的语言转换工作——这个技术在日本已经开始流行起来了。
7.使用感应器
现在越来越来越多的移动设备上都新增了感应器功能，该装置可以感知设备的物理速度以及重力，并将感知的数据结果传送给设备。这个装置常被用来感应设置是否被翻转，应用根据接受到的信息自动调节画面的方向。
感应器可以用来帮助用户提升与设备交互时的真实感；大多数移动设备都是手持的，应用能够根据设备的方向调整内容画面，比如翻转屏幕，或是检测物理移动，并能据此猜测用户所处的环境。举一个简单的例子：比如用户正在走路，那么感应器能够检测到一个轻缓的移动或是速度，这时可以为用户提供一个大字体的用户界面，从而使得用户更容易看清屏幕上的内容。
然而，开发者也不能过分依赖感应器，因为感应器无法区分究竟哪些交互是有意的，而哪些是没有意义的。每个移动交互都需要通过“传输测试”。设计你的交互时必须考虑用户在一个拥挤的汽车或是火车上的场景。考虑一下如果用户正身处拥挤的地铁或是正在驾车时，你的应用能否正确处理用户摇晃移动设备的动作。通常，大多数开发者都没有考虑这些因素。确保为每个任务设计一个备用方案以处理特殊场景中的移动交互。
8.访问文件系统
如果你的应用需要将数据保存在本地，那么你需要开发一个Native App。比如你要保存用户的地址簿、电话或E-mail信息，或是保存从其他设备上获取的数据。
访问文件系统常常会涉及到安全和用户隐私保护的问题。恶意应用程序可能会修改或是删除你的移动设备上的数据。一个携带病毒的应用程序可以利用移动设备上的关系网将病毒扩散到许多其他的手机上，在采用移动应用认证机制以前，这种事情是常常发生的。
另一方面，移动设备正变得越来越私人化，移动设备上保存了大量用户的个人信息，以及用户的朋友信息和商业信息。针对这些私人信息开发应用是一个不错的想法。但是这也存在一定的风险，使用保存在移动设备上的数据可以为用户提供更加有针对性的服务。
开发者必须谨记，只有在获得用户的授权后才能访问用户的私人数据。我们看到许多应用在没有得到用户授权的情况下使用了大量的用户私人数据，而被误认为是垃圾信息或是钓鱼应用，即使这些应用原本是在提供一些非常有用的服务。人们对你的应用的误解将会影响到你的服务的推广，如果运营商收到过多关于你的应用的投诉，那么你的服务可能将被终止，甚至会牵连其他的应用。
访问文件系统时至关重要的一点就是在没有获得用户授权的情况下，不要访问任何用户的私人数据。而这一点，往往被大多数应用忽略了。W3C正在为移动开发商开发相关的标准API，但目前该工作尚未完成。
9.离线用户
最后一个需要开发Native App的理由就是，用户有可能是离线的或者无法接入移动网络。这在城市可能很少发生，即使是在农村，网络的覆盖也已经逐步普及了。但是短暂的网络连接中断还是时常发生的，你的应用程序应该考虑如何处理这种情景。
想想用户通常在什么时候，在哪里会使用你的App。如果是一个移动游戏，那么用户很可能在飞机上使用这个App。跟踪地图应用常在偏远且网络覆盖不佳的地方使用。移动旅游向导常在一个国外的网络中访问，往往需要支付漫游和国际网络费用。这时，应用程序最好能够为用户提供离线服务，保证用户在不接入网络的情况下，仍然能享受同等的服务。
现在支持HTML5的浏览器也能实现脱机访问功能，但对用户来说可能不太明显。随着越来越多的浏览器都开始支持脱机访问，应用需要明确地告诉用户网络连接中断时，他们仍然可以访问移动Web Apps。
Native Apps常常假设网络连接是可靠的。App通常只考虑了网络状况良好的情景，想当然地认为网络是封闭的，并且网速足够快。移动设备从网络良好的环境突然进入一个网络糟糕的环境并不少见。Native Apps应该在网络状况最差的情况下测试。比如用户启动任务时可能还是全信号覆盖，而在任务结束时可能已经完全没有网络信号了。
用户在安装Native Apps时，根本不会考虑是在线访问还是离线访问——他们期望的是不管在任何状况下，Native Apps都能正常工作。而这也是开发者的职责。
什么时候应该选择Web App
只要你的应用程序不满足之前提到的Native App条件之一，那么你就没有必要开发一个Native App，而应该选择开发一个Web App。正如文章之前提到的，我是一个Native App的拥护者，我认为Native App有许多优秀的特质，并且具有很大的市场潜力，但是Web Apps是唯一一个经久不衰的移动内容、服务、应用开发平台。
Native App并不能明显地为用户提供更好的服务；它反而会增加项目的成本，减少了应用发布的渠道，增加了App升级的复杂度，削弱了开发者对应用的控制和利润，并且可能会给设备带来麻烦。Native App可以为开发者带来短期的效益，但这是有一定风险的，甚至可能会影响到移动市场的可持久发展。
移动Web App的优势在前文中已经提到过了。如果上一节提到的几点功能是促成你选择Native App的唯一原因，那么如果能够在移动浏览器上屏蔽这些障碍，你是否还会坚持选择Native App呢？Palm的webOS已经着手解决了上述的部分问题。他们基于WebKit构建了一个全移动操作系统，将手机变成了一个Web浏览器。所谓的“Native Apps”实际上就是一个Web Apps。
PhoneGap也是一个类似的项目，这个开源项目用于帮助开发者在iPhone、Android以及BlackBerry设备上开发Native Apps，并且能够模拟设备上的功能（如定位功能和文件系统）供Web Apps调用。这些代码可以在各个设备的应用商店中发布并且出售，但是他们使用的通用代码和设计是可以共享的。由于开发的是一个Web App，开发者可以为低端的移动浏览器开发一个简化版的应用。只用开发一次，就可以部署在多个平台上了，
对于那些有着丰富的移动开发经验的程序员来说，一提到“要开发一个功能丰富的应用”时，可能首先想到的就是Native App。虽然在很多设备上，这一想法仍然适用，但是现在移动Web Apps上也提供了足够丰富的功能接口供开发者调用。这使得Web App不仅可以像Native App一样被设计得功能丰富界面绚丽，而且还能在各个平台上迁移，甚至不用修改一行代码。
㈧ 嵌入已有的 Web 页面的“Web”小程序和使用微信小程序框架开发的“原生”小程序相比，有哪些区别呢
在这之前，如果有人问我，在微信中做一个产品，是用小程序还是 Web 页面 (严谨，既不是 HTML5 更不是 H5…) 的时候，我会这么说：
产品上，Web 上能做的，小程序中大部分都能做。小程序上能做的，Web 上不一定能做。
营销上，Web 能用到的入口，除了朋友圈以外，小程序都可以用。小程序能用到的若干入口，Web 不能使用。
产品上，Web 上能做的，小程序中大部分都能做。小程序上能做的，Web 上不一定能做。
营销上，Web 能用到的入口，除了朋友圈以外，小程序都可以用。小程序能用到的若干入口，Web 不能使用。
“原生”小程序，整个小程序是提前下载的，不会有 Web 页面打开时的页面加载感。我们过去的可用性研究表明，这是用户对一个界面是“Web”还是“原生”的最主要判断标准。对于偏工具型的小程序，“原生”的感受应该会更好。
“原生”小程序对体验的控制更完整，自己要做的事情也更多。例如 Web 页面中用户可以选择页面上的文字复制，而在“原生”小程序界面中，这是需要单独添加的功能。
“原生”小程序提供了一些专属的控件和 APIs（接口），如展示群信息、发送推送等，这些只有使用小程序框架开发才能使用。
关于后一点，朋友圈分享现在普遍会用海报来做，在这点上 Web 和小程序的能力其实是一样的，都是只能帮你保存图片到相册，再请用户手动发送到朋友圈。而小程序独有的发现 - 小程序、搜索框快捷方式等对用户回访特别重要的入口，Web 页面是不能使用的。
那么，昨天的发布意味着什么？简单地说，小程序的开发成本有了很大的下降。
微信小程序刚刚上线的时候，由于小程序使用类似 HTML、CSS 和 JavaScript 等 Web 语言的方式进行开发，让一些媒体误以为小程序就是 Web 开发，欢呼将“迎来 Web 开发的春天”。我自己的第一份工作就是 Web 开发工程师，Web 开发入门确实比较容易；可是尽管小程序使用了 Web 语言，那只是语法上的一致，整个开发模式完全不同，更接近于原生 App 的开发而不是 Web。打个比方，对在看这篇文章的大多数人来说，读中文要比读英文更容易，但假如你看不懂英文版的《量子力学导论》，翻译成中文版你也不一定能看懂。开发小程序，需要有专门的、独立于 Web 团队之外的团队，按小程序的规范重新设计、重新开发，不能将已有的产品直接迁移过来。
可以理解微信当初做这个决定，是希望开发者按照微信的要求，为微信的用户重新去思考、设计一套全新的用户体验，而不是将已有的 Web 页面搬进来。历史上，包括 Microsoft 的 Windows Phone 平台、Google 的 Chrome Packaged App 都冒过类似的险，而其实 Apple 也做过类似的决定——Steve Jobs 2010 年 4 月亲笔写过一篇文章，解释为何 iPhone 不支持 Flash (Thoughts on Flash)，其中最重要的原因是，Apple 不希望第三方开发者将已有的产品直接搬过来，而是希望开发者能直接在 iOS (当年还叫 iPhone OS) 进行开发，为 iPhone 的用户提供最好的体验。这些决定赌的是，新平台 (小程序或 iOS) 带来的商业上的好处，最终会让开发者们愿意付出这个成本。
那时候的 iPhone 还很弱小，但后来的历史证明 Steve Jobs 赌对了——Adobe 公司今年 7 月宣布，将在 2020 年最终停止 Flash 的更新和分发。
微信，则在昨天支持了开发者直接嵌入已有网页。
所以，如果你已经有一个网站，可以直接在小程序中套个壳，把网站中的 Web 页面摇身一变成一个小程序。至于这和直接分发 Web 页面有什么区别——
细心的你可能已经注意到了，上面这两条并没有任何变化…对，在小程序的用法上其实没有任何变化，只是开发成本下降了。
那么，在今天之后，使用微信小程序框架开发的“原生”小程序，和嵌入已有的 Web 页面的“Web”小程序，在用户感受上会有什么区别呢？
所以，如果需要和微信生态整合得更紧密，可以使用“原生”方式开发；如果追求快速迁移已有 Web 产品，嵌入 Web 页面更快。
㈨ 原生APP和Web APP的区别
html5封装的app与原生态app有什么区别呢？
html5又和app有什么区别呢？
为什么大型网络公司还是倾向于推广原生态app呢？
html5是有跨平台的优势，但是为什么还是不温不火，或者我们仍称之为轻应用app呢？
查找了相关的资料，梳理了一下，发现有如下区别：
1.html5的app如轻型小炮，原生态app如正规大炮，html5实现的功能有限，只能实现一些轻型的交互场景，而app则可以完美解决。
2.html5虽然可以跨平台，可是浏览器有个加载速度，对于用户体验上说，有个加载的等待，就比如你用qq浏览器打开网络，和直接使用网络app是两种体验。浏览器打开网络，还得有个加载，而网络app则ang的出下了输入框界面。
3.html5的app对于导航来说，目前有个弊端。而原生态app则在页底固定悬浮着导航菜单。我给截图，大家可以看看区分：看我红线画圈和蓝色画圈的区别。
4.html5 app也有自己的优势，比如有的app页面想要分享出来，则采用html5
app。也比如滴滴打车集成在微信里一样，如果手机中没有滴滴打车的app，则直接可以在默认浏览器上加载出来，进行打车。对于公司整体的运营来说不可少。
html5 app在设计时需要注意的一些要点，我也简单概括了一下：
1）各手机浏览器的兼容测试
2）底层服务的调取（能调取，但只有当其是核心功能时才保留 eg：新浪、美团等皆去掉了头像上传功能）
3）注意离线数据存储，减少数据请求频率。
4）考虑保存用户的哪些数据：设置、个人数据、阅读锚点、跳出页面等。【这点一般说的就是导航菜单】
5）避免动效与浏览器的交互冲突
6）按顺序 异步加载eg： 腾讯视频
㈩ web app与原生app有哪些交互设计区别
从使用场景上，Web App用户面临比原生APP用户更严峻的问题：
1、页面跳转更加费力，不稳定感更强
思考点：如何减少跳转（扁平结构、页面布局技巧），增加数据及展示的流畅流程及稳定性（技术）
2、更小的页面空间（由于浏览器的导航本身占用一部分屏幕空间），更大的信息记忆负担
移动设备的屏幕要小得多。这种如同透过门缝进行的阅读增加了认知的负担。人脑的短期记忆是不稳定的，用户在滚动屏幕的过程中需要临时记忆的信息越多，他们的表现就会越差。——《贴心设计：打造高可用性的移动产品》
思考点：排版更清晰、信息更简练 （可在原生APP基础上去掉一些丰富、复杂的视觉表现）
3、导航不明显，原有底部导航消失，有效的导航遇到挑战
思考点：如何有效的提供导航？有哪些形式？
4、交互动态效果收到限制，影响一些页面场景、逻辑的理解。
思考点：比如登录注册流程的弹出、完成及异常退出，做好文字提示。