一般情况有上述几种方法就够了。但预截图的能力HTML5+也是提供了的，高手可以适时使用。
预加载虽然可以避免白屏的发生，但窗体动画有时不流畅，有些新窗体移入过程中，还在不停联网获取数据，不停重绘界面，导致窗体进入动画感觉卡顿，此时还有一个高级技巧是截图动画。
5+ runtime提供了一个plus.nativeObj.Bitmap的对象，同时webview对象提供了一个截图方法，可以把webview显示区域保存到bitmap对象中。此外webview的动画方法中支持传bitmap，这样给开发者提供了一个性能调优的手段。
我们可以预载一个webview，然后把这个webview预先截图下来，然后在窗体移入时在动画参数里传入保存这个截图的bitmap对象，这样窗体移动时，移动的就不是webview，而是移动的图片，这样能让窗体动画流畅许多。
流畅度：飘nview图>飘webview>飘div。
一般场景下飘webview就够了，在特别追求极致的环境下，可以飘图，流畅度杠杠的。

mui框架的窗体函数封装\n

mui框架为了简化窗体管理的工作，把一些常用的窗体模型做了简化封装。
但对于复杂的窗体切换，仍需开发者搞明白上面提到的窗体切换原理。
mui的init方法，通过参数封装了preload，这样就可以方便的预载webview。
mui的openWindow方法，封装了显示waiting，载入新页面，处理动画，关闭waiting等工作。
mui的openWindowWithTitle()方法，封装了原生title。
mui的back样式控制，自动封装了窗体的隐藏和关闭。
这些方法具体参考mui的js API。

启动后首页的白屏\n

首页是没有预加载的概念的。
启动封面的图片如何关闭是在manifest里配置的。
默认是在首页的webview的loaded事件发生后关闭。但又提供了若干选项。
不管你的首页是白屏了还是觉得进入太慢了，都可以控制。
在工程下manifest.json里找到plus、splashscreen节点，这里有event选项，可以配置是在哪个事件时close splash，默认是loaded，也可以配成titileUpdate、rendering、rendered。
如果autoclose设置为false，即手动，可以在首页代码里写js控制封面图片的消失时机。
此时在首页合适的位置，一般在plus的ready事件后，调用js关闭封面图片，plus.navigator.closeSplashscreen();

关于如何优化启动速度，可以参考这篇文章

关于HBuilder早期版本Android手机返回时页面会先模糊后清晰的处理方法\n

为了节约系统资源，在webview不可见时，我们的引擎默认会回收掉它的渲染资源（但js仍可以正常操作）。
如果页面复杂、渲染的慢，在返回时可能会因为来不及渲染而造成先模糊后清晰的问题。
此时或者优化页面写法，加快渲染。或者使用我们提供的api，使得webview在不可见时一样不移除渲染资源。
具体API地址见plus.webview的webviewStyle对象里的render参数，render设为always即可不移除渲染，解决模糊的问题，但会占用更多内存。

关于pop-in挤压动画和slide-in-right右移动画的取舍\n

plus.webview提供了很多切换动画，上下左右平移、淡入淡出、缩放、挤压......但比较常用的动画是右移slide-in-right和挤压pop-in。
一般在iOS上，强烈推荐使用pop-in，更接近原生体验。
在Android上，pop-in体验好，但性能消耗大于slide-in-right。因为pop-in是需要前后2个webview一起做动画，而slide-in-right是只有一个webview在动画。pop-in为了达到更好的效果，需要开发者编码时注意一些写法，如果写不好，效果还不如slide-in-right
这里是pop-in动画使用注意：

关于b/s和c/s的切屏效果对比\n

有些人认为HTML5=b/s，所有页面都是要从服务器下载。
但App其实界面是本地的，联网从服务器只是取json和图片，数据量小。
这种差别引发的问题就是，c/s的app加载速度快于b/s网页，流量消耗小于b/s网页。
所以想要优化到App的体验，就使用正经的App开发模式，做c/s，减少用户流量、加快切屏速度。
DCloud同时提供了c/s的本地app的动态升级方案，相比原生App，5+App的动态更新可以做到自动化、差量化。具体见

后记\n

不管使用哪种方法，都要注意一点，手机App的HTML页面必须本身性能足够高。
页面体积要小、加载和渲染要快。
互联网上有很多提升HTML、JS、CSS性能的方案，此处不再罗列。
但再次强调，尽量避免使用js渲染页面。
在页面load那1、2秒钟，手机的压力是非常大的，加载众多资源、构建dom、渲染、还要做动画，此时大量依赖js渲染界面的做法会让手机cpu、gpu忙不过来，要不卡动画、要不阻塞js。
pc上web框架的盛行，也是后来pc浏览器性能足够高之后的事情，互联网发展初期的开发者并不像如今这般依赖框架。
手机，尤其是低端Android机的性能也很差，如果照着写pc web的思路写页面，最终的用户体验必然会非常差。
首先，AMD框架尽量不用，包括angularjs在内，js动态解析标签再替换渲染是很慢的。
其次，jquery也尽量不要使用。document.getElementById("") 、document.querySelectorAll("")、$("")，这三者性能依次下降，尤其是在低端Android上遍历dom时，当你辛辛苦苦减少白屏和用户等待时间时，你会非常愤怒这些js框架拖了你的后腿。
并且HBuilder提供了很多代码块来快速完成代码，比如敲dg就可以出document.getElementById("")，比敲$("#")要快多了。
当然个别页面为了使用一些现成的jquery插件而引用了框架，倒也不会对app整体产生太大影响，这需要开发者自己根据产品对性能追求的极致程度来把握了。