怎么区分html5与原生开发的app
推荐于2017-05-18
展开全部
问题,主要聚集在以下几个方面:
1、动画
动画有很多种,比如侧边栏菜单的滑入滑出、元素的响应动画、页面切换之间的过场等等,在H5之下的众多实现方法都没有办法达到纯原生的性能。一般这些的话有几种不同的选择:css3动画、javascript动画、原生动画。
css3动画非常的消耗性能,如果某一个元素用到css3动画可能还看不出来,但大面积或过场使用css3动画会让app低端手机体验非常差。最好的选择一般是通过框架调用底层的动画,但不管怎么样等于在原来的代码上包上了一层,性能还是不可避免的受到影响。
比如在一个新页面的载入上,如果调用底层动画要考虑的问题有两个,一个是本身资源页面的渲染问题,另一个是远程数据的获取。即便是这些动画能够很快的响应,但大量的css页面会导致渲染卡顿,滑入时可能会有白屏/机器卡顿的现象。为了解决这些性能问题又必须要用到预加载或模拟动画。即便是这样,滑入滑出的动画在低端的安卓机器上还是有很多问题,如果获取服务端数据处理的方式不合适,卡顿白屏的现象会更严重。具体看下面的数据获取方式。
2、获取服务端数据
首先要接受的是,这里的数据获取都是在资源页面上异步完成的,因为只有这样才能让这些资源页面完成预加载或者渲染。但是异步拿到的数据在填入页面中时可能会涉及DOM操作,众所周知,DOM操作非常消耗性能,如果页面小还好,页面稍大数据稍微复杂一点,频繁的DOM操作会导致明显的闪白。而且最重要的一点是,如果页面加载进来之后数据更新的速度太慢,也会让页面模板等待很长时间,对用户体验又不友好,总不能每次打开都像浏览器一样等待刷新是吧。
这个问题如果没有得到解决,H5APP是很难承担大规模数据的页面,在它们之中频繁切换更是难上加难,那么肯定有人也会想到用MVVM的方式,其实我也写过一些基于MVVM的H5APP,相对来说它们获取数据和更新数据的方式更敏捷更科学,但写的过程中又要注意很多H5独有的问题,这些问题在下面的页面切换里来讲。
3、页面切换
上面我们看到了几种不错的实现方式,比如预加载和模拟动画,甚至有批量的预加载,批量的截图模拟动画等等,虽然看起来很友好解决了不少问题,但事实上如果页面足够多就会引发另一个问题——页面的生存周期。
试想一下,如果引导页或者主页面缓存了5个子页面的资源,在跳转到响应的子页面时又会缓存这些子页面的下级页面资源,如此反复肯定会占据大量内存使APP的体验下降。那么怎么知道那些页面是需要的,最多缓存多少页面,什么时候结束哪些页面的生存周期呢?在我用过的很多H5APP的框架里都没有对这些问题有一个完美的解答,因此在页面较多内容较多的APP中可能会因这些资源分配的问题降低性能。
1、动画
动画有很多种,比如侧边栏菜单的滑入滑出、元素的响应动画、页面切换之间的过场等等,在H5之下的众多实现方法都没有办法达到纯原生的性能。一般这些的话有几种不同的选择:css3动画、javascript动画、原生动画。
css3动画非常的消耗性能,如果某一个元素用到css3动画可能还看不出来,但大面积或过场使用css3动画会让app低端手机体验非常差。最好的选择一般是通过框架调用底层的动画,但不管怎么样等于在原来的代码上包上了一层,性能还是不可避免的受到影响。
比如在一个新页面的载入上,如果调用底层动画要考虑的问题有两个,一个是本身资源页面的渲染问题,另一个是远程数据的获取。即便是这些动画能够很快的响应,但大量的css页面会导致渲染卡顿,滑入时可能会有白屏/机器卡顿的现象。为了解决这些性能问题又必须要用到预加载或模拟动画。即便是这样,滑入滑出的动画在低端的安卓机器上还是有很多问题,如果获取服务端数据处理的方式不合适,卡顿白屏的现象会更严重。具体看下面的数据获取方式。
2、获取服务端数据
首先要接受的是,这里的数据获取都是在资源页面上异步完成的,因为只有这样才能让这些资源页面完成预加载或者渲染。但是异步拿到的数据在填入页面中时可能会涉及DOM操作,众所周知,DOM操作非常消耗性能,如果页面小还好,页面稍大数据稍微复杂一点,频繁的DOM操作会导致明显的闪白。而且最重要的一点是,如果页面加载进来之后数据更新的速度太慢,也会让页面模板等待很长时间,对用户体验又不友好,总不能每次打开都像浏览器一样等待刷新是吧。
这个问题如果没有得到解决,H5APP是很难承担大规模数据的页面,在它们之中频繁切换更是难上加难,那么肯定有人也会想到用MVVM的方式,其实我也写过一些基于MVVM的H5APP,相对来说它们获取数据和更新数据的方式更敏捷更科学,但写的过程中又要注意很多H5独有的问题,这些问题在下面的页面切换里来讲。
3、页面切换
上面我们看到了几种不错的实现方式,比如预加载和模拟动画,甚至有批量的预加载,批量的截图模拟动画等等,虽然看起来很友好解决了不少问题,但事实上如果页面足够多就会引发另一个问题——页面的生存周期。
试想一下,如果引导页或者主页面缓存了5个子页面的资源,在跳转到响应的子页面时又会缓存这些子页面的下级页面资源,如此反复肯定会占据大量内存使APP的体验下降。那么怎么知道那些页面是需要的,最多缓存多少页面,什么时候结束哪些页面的生存周期呢?在我用过的很多H5APP的框架里都没有对这些问题有一个完美的解答,因此在页面较多内容较多的APP中可能会因这些资源分配的问题降低性能。
推荐律师服务:
若未解决您的问题,请您详细描述您的问题,通过百度律临进行免费专业咨询