原生APP，web APP , 纯h5开发比较

1.目前APP开发有4中方式：a.纯原生  b.纯原生 + 远端 h5页面（目前采用策略） , c.H5 + 原生(内置) d.H5应用页面

a.纯原生(开发成本大)：

    优点：

1.提供最佳的用户体验，最优质的用户界面，最华丽的交互 

2.每一种移动操做系统都须要独立的开发项目，针对不一样平台提供不一样体验

3.可以与移动硬件设备的底层功能，可访问本地资源

    劣势：

1.维持多个版本的成本比较高

2.安卓碎片化严重，致使有可能不兼容的问题

3.移植性差

b.纯原生 + 远端 h5页面（目前采用策略）

     优点：

1.H5页面多设备一套UI，大大下降UI开发的成本。

2.因为H5页面在服务端，调试比较方便

     劣势：

1.H5页和原生页面混搭使用。可能会形成相似于回退同样的状况(H5和原生交互少形成的混搭使用)

2.每次从服务端请求页面，都会形成流量的消耗

3.流畅性不如原生

c.H5 + 原生(内置)

     优点：

1.H5页面多设备一套UI，大大下降UI开发的成本。

2.因为全部的UI都是由H5来实现的，让手机端开发人员以及后端开发人员更加关注业务逻辑的功能实现

3.因为UI组件都是内置的，所以能够减小大部分的流量消耗。

4.向比b,d方案 用户体验更佳

5.可以与移动硬件设备的底层功能，可访问本地资源

     劣势：

1.调试的时候，双前段可能比较麻烦。

2.流畅性不如原生

3.若是H5页面做用于设备浏览器，将不适用.不适用的缘由：页面中可能有3/1的事件是在调用原生的方法，不可能移植到第三方去

d.H5应用页面

     优点：

1.只适合提供设备浏览器使用。

推荐使用c方案,若是使用c方案，将使用mui和zepto框架结合native来进行开发,APP开发人员则更多的是webapp框架的研发。

注：

1.本地图片适配的问题？

答：图片的尺寸采用向上靠的策略

2.IOS:页面跳转过多致使内存溢出？

答：采用js调用本地native方法进行跳转。

3.JS文件是否增量更新？

答：是，只须要更新新增的JS文件便可.(说明:否，每次须要提交app store进行审核)

固然，也可使用相似于appcan, phonegap, hbuilder, apicloud 等 webapp框架

appcan（免费） :

     优点：

1.苹果在2014年10月20号发布了一条消息：从2015年的2月1号开始，提交到App Store的应用必须支持64-bit。（已经支持，第三方SDK也已经支持）.注意事项：平台支持64-bit ARM之后，适配的设备固件版本最低为iOS 5.1.1

2.可根据本身须要写扩展插件，适应不一样的开发方向

3.已经开源，有在线中文文档，应用内置了丰富的窗口 交互、UI控件库、原生插件库，本地化支持比较好，学习成本低。

4.懂HTML+CSS+Javascript就能开发，自带的api还算比较全，开发周期短，开发成本低，并且跨平台，可同时支持andriod和ios系统，不用开发两次

5.Appcan模拟器，调式方便

6.相比phonegap流程度稍高点，请求数据速度高点

7.IOS审核有优点

     劣势：

1.要用就得用一套。

2.流畅度不够。

apicloud（公测阶段全免费） ：

优点:

1.流畅性超高，请求数据也快，和原生差很少

2.网上说该框架的内核比appcan的要高级，不知道是真是假

3.本地化支持

4.模拟器，调式方便

劣势：

1.出现的时间不长

2.使用的人群没有其余2个多

注：如今是免费的，好像是端开发 （开发移动应用）永久免费，云服务如今是免费，后续会收费。不过能够只用端开发，那就永远不用给钱了

phonegap：

优点：

1.国外的东西

2.模拟器，调式方便

劣势：

1.组件没有appcan多，流畅度没有appcan高，数据请求没有appcan快

2.英文文档，本地化支持不够，出现问题比较难解决

hbuilder(mui的一个打包开发工具)：

优点：

1.轻量，小巧,流畅度比appcan高

2.模拟器，调式方便

劣势：

1.不少组件都没有，须要本身开发

---

目前当前项目中使用的策略为b策略，发现不少问题，流程性不高，体验性不高，请求数据慢， 最近项目组中在考虑换一种策略，以上是本身搜集好了。也在以上的官网上下载了一些案例，测试下来以后得出的结论。发现这个apicloud很亮眼，决定本身先作一个小demo。最后再决定使用哪一个吧