小时电话
17620848827
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。最后再决定使用哪个吧
