纯HTML5APP和原生APP有什么区别？:1.动画种类繁多，比如侧边栏菜单的滑入滑出、元素响应动画、页面切换之间的过渡等等，很多H5下的实现方式都没有办法做到纯原生的表现。一般这几个字有几种不同的选择：css3动画javascript动画原生动画css3动画是很耗性能的，如果某个元素使用css3动画可能不可见，但是大面积使用css3动画或者过场动画会让该应用程序低端移动体验非常差。最好的选择一般是通过框架来调用底层动画，但是不管怎样，都相当于在原来的代码上包裹了一层，性能难免会受到影响。比如加载新页面时，如果调用底层动画，需要考虑两个问题，一是资源页面本身的渲染，二是远程数据的获取。即使这些动画能够快速响应，大量的css页面也会造成渲染卡顿，滑入时可能会出现白屏/机器卡顿。为了解决这些性能问题，必须使用预加载或者模拟动画。即便如此，在低端安卓机上的滑入滑出动画还是存在不少问题。如果获取服务器端数据处理的方式不当，卡顿白屏的现象会更加严重。详情见下文数据采集方法。2、获取服务端数据，首先要接受的是这里的数据获取是在资源页面异步完成的，因为只有这样才能预加载或者渲染这些资源页面。但是异步获取的数据在填写页面的时候可能会涉及到DOM操作。众所周知，DOM操作是非常消耗性能的。页面小的话还好，页面大了数据就复杂一点。频繁的DOM操作会导致明显的闪烁。而且最重要的一点是，如果页面加载后数据更新速度太慢，也会让页面模板等待很长时间，对用户体验不友好。总不能每次打开都像浏览器一样等着刷新吧？.如果不解决这个问题，H5APP难以承载大规模的数据页，频繁的切换更是难上加难，那肯定有人会想到用MVVM。其实我也写过一些基于MVVM的，相对来说，他们获取和更新数据的方式更加敏捷和科学，但是在写的过程中，一定要注意很多H5特有的问题。这些问题将在下面的页面切换中讨论。3.页面切换上面我们看到了几种很好的实现方式，预加载和模拟动画，甚至是批量预加载，批量截图模拟动画等，虽然看起来很友好，也解决了很多问题，但事实是，另一方面，如果有足够的页面，会导致另一个问题——页面的生命周期。试想一下，如果引导页或者主页面缓存了5个子页面的资源，然后在跳转到对应的子页面时，再缓存这些子页面的子页面的资源。如此反复肯定会占用大量内存，降低APP体验。那么怎么知道需要哪些页面，最多缓存多少个页面，哪些页面的生命周期什么时候结束呢？我用过的很多H5APP框架都没有完美的回答这些问题，所以在页面多、内容多的APP中，可能会因为这些资源分配问题而导致性能下降。这个时候我们回过头来看看MVVM的数据加载问题。其实无论是哪种MVVM框架，写过的人都知道，管理这种新型的前端代码最主要的问题就是内存的问题。必须保证代码写得足够优雅，没有任何内存泄漏，同时还要考虑他们的controller/page资源是否在页面生命周期结束时释放，这对全局情况有没有影响，并在多个请求时合理分配资源。甚至复用这些父页面传递过来的缓存资源等等。较小的应用程序可能没有这些问题。如果你想用纯HTML5开发一个大型应用程序，很可能会浪费你很多时间——而且结果不会让你满意。4、Android/iOS的区别很多人说，一个纯H5的APP，一次可以编译出两个不同的Android/iOSAPP，大大降低了成本。其实这个观点本身就值得商榷。如果你写过这样的应用程序，你就会明白我在说什么。它们并不容易，而且有很多错误，调试时特别麻烦。举个很简单的例子，A??ndroid和iOS在返回上一页的处理方式上有明显的区别。全屏模式下iOS的topbar如何处理，Android机出现智能条时如何处理页面的布局，调用底层硬件时如何区分不同的场景等等，都需要写model和系统判断一个接一个，然后分别在Android和iOS下debug，但是最后你发现这个没用，累到什么都没学到。一堆不知道什么时候会过时的经验。现在做H5混合APP开发的人很多，但是纯H5还很年轻，很多问题都没有解决好。这些都是我在做这些app的时候考虑最多的问题。当然，您不必担心。随着ES6的实施，硬件发展越来越快，纯H5APP可能没有立足之地。最后说一下H5的一个很少有人注意到的优点。大家说起H5APP，都是开发速度快、成本低、多平台等，但我觉得它和很多APP开发方式相比有一个不同点——图文混排。正是这些复杂多变的CSS样式消耗了性能，却带来了排版的多样性，而能够细化每个字宽、行高和样式的像素级处理正是H5的过人之处。
