纯H5的APP，虽然开发起来要比纯原生开发畅快的多，但最终效果和性能还是和原生比起来还是有很多问题，主要聚集在以下几个方面：
1、动画
动画有很多种，比如侧边栏菜单的滑入滑出、元素的响应动画、页面切换之间的过场等等，在H5之下的众多实现方法都没有办法达到纯原生的性能。一般有这几种不同的选择：css3动画，javascript动画，原生动画。
css3动画非常的消耗性能，如果某一个元素用到css3动画可能还看不出来，但大面积或过场使用css3动画会让app低端手机体验非常差。最好的选择是通过框架调用底层的动画，但不管怎么样等于在原来的代码上包上了一层，性能还是不可避免的受到影响。
比如在一个新页面的载入上，如果调用底层动画要考虑的问题有两个，一个是本身资源页面的渲染问题，另一个是远程数据的获取。即便是这些动画能够很快的响应，但大量的css页面会导致渲染卡顿，滑入时可能会有白屏/机器卡顿的现象。为了解决这些性能问题又必须要用到预加载或模拟动画。即便是这样，滑入滑出的动画在低端的安卓机器上还是有很多问题，如果获取服务端数据处理的方式不合适，卡顿白屏的现象会更严重。具体看下面的数据获取方式。
2、获取服务端数据
首先要接受的是，这里的数据获取都是在资源页面上异步完成的，因为只有这样才能让这些资源页面完成预加载或者渲染。但是异步拿到的数据在填入页面中时可能会涉及DOM操作，众所周知，DOM操作非常消耗性能，如果页面小还好，页面稍大数据稍微复杂一点，频繁的DOM操作会导致明显的闪白。
而且最重要的一点是，如果页面加载进来之后数据更新的速度太慢，也会让页面模板等待很长时间，对用户体验又不友好，总不能每次打开都像浏览器一样等待刷新是吧。
这个问题如果没有得到解决，H5APP是很难承担大规模数据的页面，在它们之中频繁切换更是难上加难，那么肯定有人也会想到用MVVM的方式，相对来说它们获取数据和更新数据的方式更敏捷更科学，但写的过程中又要注意很多H5独有的问题，这些问题在下面的页面切换里来讲。
3、页面切换
上面几种不错的实现方式，比如预加载和模拟动画，甚至有批量的预加载，批量的截图模拟动画等等，虽然看起来很友好解决了不少问题，但事实上如果页面足够多就会引发另一个问题：页面的生存周期。
试想一下，如果引导页或者主页面缓存了5个子页面的资源，在跳转到响应的子页面时又会缓存这些子页面的下级页面资源，如此反复肯定会占据大量内存使APP的体验下降。那么怎么知道哪些页面是需要的，最多缓存多少页面，什么时候结束哪些页面的生存周期呢？在很多H5APP的框架里都没有对这些问题有一个完美的解答，因此在页面较多、内容较多的APP中可能会因这些资源分配的问题降低性能。
这时再看看MVVM的数据加载问题，实际上不管哪个MVVM框架，写过的人都知道管理这种新型的前端代码最重要的问题是内存的问题，你既要保证代码写的足够优雅没有任何内存泄露问题，也要考虑到在页面生存周期结束时它们的控制器/页面资源是否得到释放，这对全局有没有什么影响，在多个请求时也要合理的分配资源，甚至是复用这些父级页面传过来的缓存资源等等。较小的APP可能并不会有这些问题，如果你想用纯H5来开发大型APP，这很可能会浪费你很多时间——而且结果还不会让你满意。
HTML5有多少坑可以分为3大点和7小点，3大点上文有详细的介绍了，下面说说7小点。
1.过分依赖网络
2.渲染性能较弱
3.页面过多
4.标签太多，代码量也不少
5.不能调用移动硬件设备的功能
6.不支持离线模式
7.消息推送不够及时
虽然H5 APP有很多缺点，但不得不承认，存在必然有其作用，正如前几年流行的混合开发模式，通过原生和H5结合也是不错的方案，比如淘宝、京东等电商类App，
HTML5 的优势在于他的排版，要做出相同效果的 Native 界面排版成本又太大，
JavaScript由于其复杂的文档对象模型（DOM）、糟糕的实现和调试工具、不一致的浏览器实现而不受开发者的待见。而随着技术的发展， JavaScript变得越来越强大、完善，比如， Ajax技术可以创建更加迷人的Web应用，Angular JS提供web应用的架构支持整个开发进程，Node.js将JavaScript的应用范围扩展到了服务器端，imag.js将JavaScript延伸到移动端，各种层出不穷的框架使得JavaScript的开发更加简捷。尤其是近几年node.js和imag.js以及react.js的发展，将 JavaScript提升到了前所未有的高度。
我们也可以看看用imag.js开发的微信页面（支持Android和iOS）
[url=http://blog.csdn.net/mojingxuan/article/details/51444812]点击链接[/url]
1、动画
动画有很多种，比如侧边栏菜单的滑入滑出、元素的响应动画、页面切换之间的过场等等，在H5之下的众多实现方法都没有办法达到纯原生的性能。一般有这几种不同的选择：css3动画，javascript动画，原生动画。
css3动画非常的消耗性能，如果某一个元素用到css3动画可能还看不出来，但大面积或过场使用css3动画会让app低端手机体验非常差。最好的选择是通过框架调用底层的动画，但不管怎么样等于在原来的代码上包上了一层，性能还是不可避免的受到影响。
比如在一个新页面的载入上，如果调用底层动画要考虑的问题有两个，一个是本身资源页面的渲染问题，另一个是远程数据的获取。即便是这些动画能够很快的响应，但大量的css页面会导致渲染卡顿，滑入时可能会有白屏/机器卡顿的现象。为了解决这些性能问题又必须要用到预加载或模拟动画。即便是这样，滑入滑出的动画在低端的安卓机器上还是有很多问题，如果获取服务端数据处理的方式不合适，卡顿白屏的现象会更严重。具体看下面的数据获取方式。
2、获取服务端数据
首先要接受的是，这里的数据获取都是在资源页面上异步完成的，因为只有这样才能让这些资源页面完成预加载或者渲染。但是异步拿到的数据在填入页面中时可能会涉及DOM操作，众所周知，DOM操作非常消耗性能，如果页面小还好，页面稍大数据稍微复杂一点，频繁的DOM操作会导致明显的闪白。
而且最重要的一点是，如果页面加载进来之后数据更新的速度太慢，也会让页面模板等待很长时间，对用户体验又不友好，总不能每次打开都像浏览器一样等待刷新是吧。
这个问题如果没有得到解决，H5APP是很难承担大规模数据的页面，在它们之中频繁切换更是难上加难，那么肯定有人也会想到用MVVM的方式，相对来说它们获取数据和更新数据的方式更敏捷更科学，但写的过程中又要注意很多H5独有的问题，这些问题在下面的页面切换里来讲。
3、页面切换
上面几种不错的实现方式，比如预加载和模拟动画，甚至有批量的预加载，批量的截图模拟动画等等，虽然看起来很友好解决了不少问题，但事实上如果页面足够多就会引发另一个问题：页面的生存周期。
试想一下，如果引导页或者主页面缓存了5个子页面的资源，在跳转到响应的子页面时又会缓存这些子页面的下级页面资源，如此反复肯定会占据大量内存使APP的体验下降。那么怎么知道哪些页面是需要的，最多缓存多少页面，什么时候结束哪些页面的生存周期呢？在很多H5APP的框架里都没有对这些问题有一个完美的解答，因此在页面较多、内容较多的APP中可能会因这些资源分配的问题降低性能。
这时再看看MVVM的数据加载问题，实际上不管哪个MVVM框架，写过的人都知道管理这种新型的前端代码最重要的问题是内存的问题，你既要保证代码写的足够优雅没有任何内存泄露问题，也要考虑到在页面生存周期结束时它们的控制器/页面资源是否得到释放，这对全局有没有什么影响，在多个请求时也要合理的分配资源，甚至是复用这些父级页面传过来的缓存资源等等。较小的APP可能并不会有这些问题，如果你想用纯H5来开发大型APP，这很可能会浪费你很多时间——而且结果还不会让你满意。
HTML5有多少坑可以分为3大点和7小点，3大点上文有详细的介绍了，下面说说7小点。
1.过分依赖网络
2.渲染性能较弱
3.页面过多
4.标签太多，代码量也不少
5.不能调用移动硬件设备的功能
6.不支持离线模式
7.消息推送不够及时
虽然H5 APP有很多缺点，但不得不承认，存在必然有其作用，正如前几年流行的混合开发模式，通过原生和H5结合也是不错的方案，比如淘宝、京东等电商类App，
HTML5 的优势在于他的排版，要做出相同效果的 Native 界面排版成本又太大，
JavaScript由于其复杂的文档对象模型（DOM）、糟糕的实现和调试工具、不一致的浏览器实现而不受开发者的待见。而随着技术的发展， JavaScript变得越来越强大、完善，比如， Ajax技术可以创建更加迷人的Web应用，Angular JS提供web应用的架构支持整个开发进程，Node.js将JavaScript的应用范围扩展到了服务器端，imag.js将JavaScript延伸到移动端，各种层出不穷的框架使得JavaScript的开发更加简捷。尤其是近几年node.js和imag.js以及react.js的发展，将 JavaScript提升到了前所未有的高度。
我们也可以看看用imag.js开发的微信页面（支持Android和iOS）
[url=http://blog.csdn.net/mojingxuan/article/details/51444812]点击链接[/url]
扫一扫
4768
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
