小米应用商店Hybrid性能优化实践商业课件.ppt

在说优化之前，我们先看几张图，这是我们我们手机web站在不同平台的加载渲染图，第一个页面只花了600ms就加载了，减少请求：合并，缓存，base64，lazyload，减少体积：js，css压缩，gzip 结论是，系统webview是性能很糟糕的一个容器环境，性能很差。第二，移动端的硬件越来越强，逐步在缩小差距，小米5标准版系统webview parse：215-235 第一个特性是：单线程， 第三个特性是 于是我们对Hybrid架构中的web容器有了一个大致的认知，1，糟糕的性能， 2，单线程执行环境，3，性能不稳定， 有了这点前提，我们提出了几个优化原则，第一个是 100-200ms 第二个优化加载速度的地方在于图片，通常页面图片是请求是大头，通常一个页面js css加起来也就100k左右，而一个banner图可能就几百k，根据木桶原则，我们应该把最短的一环补上来。 体积，image decode 为什么说要集中资源做渲染了，主要是基于webview的性能差这个前提提出的，为了更快的渲染和流畅性，我们在渲染页面的时候应该尽量避免做其他没必要的工作。 第二个webview的特性是： 因为webview 也属于安卓view组件，所以我们需要关心webview的suface更新。suface更新是native的特性，可以理解为web渲染这个过程 图片请求失败唤起 示例 虽然是H5页面，但是要想Native那样可靠 H5对内存的优化是个非常大的劣势， 大部分情况都是合成层引起的，这里面的情况比较复杂，建议大家对不必要用合成层的地方慎用，并且少用动画 Hybrid应用性能优化 杨伟贤 江湖ID：babyzone2004 TAG: 前端，设计，产品，游戏开发 应用商店 千万级的日活 十亿级的应收（排除游戏） 单日最高下载量高达1.8亿次，分发量突破500亿 应用商店 改版Hybrid的意义 开发效率高 版本发布快，覆盖全 天然跨平台 由Native过渡到Hybrid 逐个页面改造 严谨的A/B test 首页 排行 分类 搜索 … 移动Webview和PC浏览器 性能对比 不同的平台访问：/home PC Chrome parse ：90-120ms 小米4系统Webview parse：280-307ms 一个线程 android应用中的所有webView共用同一个render线程 在多tab webview中，如果一个webview 页面阻塞，另一个webview中的页面也会被阻塞 不稳定的性能 cpu和gpu过度的使用会导致手机发热 手机过热会触发系统对cpu降频处理 cpu降频会降低页面流畅性 移动Webview和PC浏览器 Webview性能很差 多个Webview共用一个线程 性能不稳定 “更快的加载速度” 更快的加载速度 页面缓存到本地，离线包(减少网络IO) 优先加载渲染当前webview （单线程） js/css inline到HTML页面（减少IO） 图片合并代替图片base64 （减少IO） 更快的加载速度 png 1080*495 1.3MB png 720*330 621KB jpeg 720*330 114KB webp 720*330 77.2KB webp 720*33 q80 44.1KB /thumbnail/png/l1080/AppStore/09efa55fce1d43c7698ab300e1c2500cb1c42743c 图片优化的好处 减少网络加载时间 减少image decode时间 减少内存占用 “集中资源做渲染” 集中资源做渲染 非当前页面停止动画或者其他加载渲染工作 reflow/repaint，动画使用合成层 避免触发多余合成层 避免不必要的suface更新 android view的suface更新 Android view的suface更新 suface更新需要调度cpu gpu资源 页面的任何变化（合成层动画）会导致suface更新 可视区域之外的动画也会导致suface更新 集中资源做渲染 非当前页面停止动画或者其他加载渲染工作 reflow/repaint，动画使用合成层 避免触发多余合成层 避免不必要的suface更新 “力争一致的交互” 一致的交互 一致的界面 一致的交互 稳定可靠的连接 … 内存优化 图片是耗内存的大头 长列表及时回收内存 JS内存泄漏，DOM内存泄漏 利用chrome开发者工具查找内存泄漏 Hybrid Web问题 内存占用较多 白屏 滚动卡顿 Hybrid和Native对比 THANKS 大家下午好，我今天分享的主题是 Hybrid应用的性能优化，主要围绕如何提高web页面的用户体验来展开。 先自我介绍，我叫杨伟贤，2011年开始加入百度