共计 5236 个字符，预计需要花费 14 分钟才能阅读完成。
本文来源于：数据体验技术团队 - 凤萧
前言
很多企业都会特地重视本人产品的体验，尤其是挪动端，那挪动端的体验为什么这么重要？首先体验自身就很重要，好的体验带给用户的感触是截然不同的，用户抉择应用一个产品除了产品自身性能满足需要之外，还有一个更重要的起因就是产品用起来“爽”，产品整个应用流程必然是舒服天然，能力受到公众青睐；此外，产品体验已成为市场竞争力之一，借用人人都是产品经理上面对体验的阐述：
当技术已不再是产品外围竞争力时，产品竞争的本质就是用户体验之争。
如果产品不能让用户身心感到愉悦和舒服，他们很可能会迅速应用其余替代品，对于 toC 的产品尤为显著，产品体验蹩脚必然会被市场淘汰。然而体验是一个很宏大的话题，有很多方面会影响产品的体验，如性能、UI、交互以及人性化的性能等等，本文抛砖引玉，只从技术层面的某几个方面聊聊挪动端的体验优化，次要以 Android 为切入点，IOS 大部分优化方向与 Android 相似。思考到市面上绝大多数 APP 都是 Native+H5 相结合的利用，且自己我的项目中也大量应用 H5 页面，因而将从 Native 端和 H5 端别离总结如何优化体验。
Native 端体验优化
始终在思考从技术层面上，Native 端什么样才称得上是体验佳的产品，有什么评判规范，从过往教训来看，集体感觉应该具备以下根本特质:
- 启动速度要快
- 交互晦涩不卡顿
- 有离线缓存
- 反对弱网环境
- 敌对的用户提醒
作为技术人须要重点把控的是前 4 点，第 5 点可能更多须要设计同学染指，依据以往的教训，能够从以下几个方面着手：启动优化，内存优化、UI 渲染优化、网络优化等，内存和 UI 渲染的优化次要针对卡顿问题，网络优化中一个重点波及的对象是缓存和弱网反对，每一个方面都能够独立成文进行专门的摸索，本文只提供一些支流的优化思路供参考，不具体开展。
内存优化
尽管当初手机内存配置越来越好，然而内存仍然是很吃紧的资源，因为系统对 APP 内存占用有限度（具体大小依不同手机厂商而异）。内存的优化首先要防止大量的内存泄露，能够应用 leakcanary 进行自动检测，若要深入分析，能够应用 AndroidStudio 手动 dump 内存下来用 MAT 工具进行剖析，发现其中潜在的内存泄露对象。其次是尽量应用成熟的图片开源框架，如 Glide 或者 Picasso 等展现图片或者 Gif。
内存优化除了留神 内存泄露，还要关注 内存的抖动，呈现的起因个别是大量频繁的创建对象，导致频繁触发 GC，以致于 APP 应用卡顿，比方常见的场景是在自定义控件的 onDraw 办法创建对象，因为 onDraw 办法会频繁调用，在 onDraw 办法中创立大对象会导致内存急剧增长，触发 GC 导致卡顿。因而要尽量避免在循环体中创建对象，能够思考应用对象池一次创立多处复用来躲避内存抖动。
UI 渲染优化
UI 渲染性能关系到 APP 的晦涩度，16ms 内未能实现一次绘制就会呈现掉帧，给人感觉就是页面卡顿，响应不及时。挪动端上导致渲染性能降落的起因和解决的个别套路：
布局不合理
布局要防止不必要嵌套，以应用 Hierarchy View 进行辅助查看布局层级关系，来辨认嵌套是否正当；同时要依据具体场景正当应用哪一种布局，如 RelativeLayout 不能滥用，对于简单布局能够用 ConstaintLayout 代替；此外还能够应用 viewstub 进行提早加载布局，用 merge 和 include 进行布局复用。
适度绘制（overdraw）
适度绘制的呈现是因为在重叠的层级构造中，一些不可见的局部因为某些起因，如设置了背景色，也会呈现在绘制操作中，导致这块重叠区域的像素被屡次绘制，那显著是节约计算资源。能够应用简略办法辨认适度绘制是否重大，在 Android 零碎中开发主菜单外面关上「调试 GPU 适度绘制」开关就能看到界面 UI 元素被不同的色彩块标注（如下图）
色彩从原色——蓝色——绿色——粉色——红色顺次代表适度绘制重大水平从低到高，一般而言须要关怀红色的色块 UI 元素，因为它有重大的适度绘制，是有优化空间的。我的个别解法是去掉布局背地不必要的背景色，当然还有其余因素会导致适度绘制，如包装的自定义控件，自身因为不留神防止适度绘制的影响，在应用的时候就自带重大的适度绘制问题。
主线程有简单耗时工作
主线程（UI 线程）不能有简单耗时的计算工作，否则会导致 UI 无响应，卡顿，最终导致 ANR 的产生。
网络优化
- 保障接口设计的合理性，必要时合并网络申请，缩小申请次数；
- 网络缓存，针对服务端返回的数据设置无效工夫，在无效工夫内不走网络申请，缩小流量耗费，能够依照本人业务的个性自定义缓存的实现。在弱网或者是无网络的状况下，因为有缓存的反对，不至于 APP 关上一片空白，这给用户更好的体验。
- 数据压缩，如 Gzip 压缩 request 和 response，缩小网络流量传输。
启动优化
最次要的思路防止把全副的初始化工作放在 Application 中，能够应用子线程或者懒加载的形式来解决初始化工作；另外惯例套路是会给第一个 Activity 设置 theme，这样关上 APP 霎时看到不是白屏，给用户的感觉就是启动速度失去改善。
H5 页面减速优化
挪动互联网时代，H5 页面无处不在，简直 80% 以上的 APP 都有 H5 页面的影子，一份代码多端运行且能疾速部署的劣势，让 Hybrid 开发成为很多 APP 的标配。尽管 Hybrid 在体验上总是赶不上 Native 的体验，甚至在处理不当的状况下，蹩脚的体验会让很多企业抉择应用其余技术栈，然而 Hybrid 仍然是很多公司应用的支流技术。集体认为，在对页面体验没有太高要求的状况下，Hybrid 仍然是当下最佳的开发方式。要实现较好的体验，须要破费心理对 H5 页面进行优化，我感觉有三个方向能够进行优化：
- 页面启动白屏工夫
- H5 页面的交互体验，如响应晦涩度
- 页面渲染性能
本文只从影响体验最重要的指标——白屏工夫来聊聊如何进行优化，响应晦涩度和页面渲染性能因为不足实践经验，这里就不班门弄斧。
耗时拆解
先剖析下在挪动端从用户点 H5 链接到页面渲染实现展现给用户，须要经验的粗略过程，示意如下图：
- Webview 初始化
- 下载动态资源（html、js 和 css 等）
- 数据申请
- 渲染（解析、组装、绘制）
这里的渲染蕴含了 html、js、css 的解析，组装成 Render Tree 以及最初的绘制。粗略的估算，能够将耗时拆解为：
总耗时(t) = Webview 初始化耗时(t1) + 下载动态资源耗时(t2) + 数据申请耗时(t3) + 渲染耗时(t4)
其中 Webview 初始化、动态资源加载以及数据申请占用的耗时是比拟多的，且这个耗时页面肯定处于白屏阶段，以下对这三块给出一些惯例的优化计划，渲染的耗时优化本文不阐述。
动态资源的优化
动态资源次要指 html，js 和 css 资源，对于单页利用而言次要是 js 和 css，下图是我参加的我的项目中页面第一次关上时的动态资源申请状况（无浏览器缓存）：
从页面申请能够看到，其中 1.js 的下载是比拟耗时的，是利用比拟外围的 js 文件，必须期待此文件下载实现，才有可能持续前面的页面渲染。在简直零优化的状况下能够看到耗时靠近 800ms，还是有很大的优化空间的。上面从前端视角和客户端视角来解说下动态资源优化的思路。
前端视角
从前端的角度动手，能够有以下几个优化伎俩：
- 资源压缩，前端有成熟的工具能够对生成的 js、css 等产物进行压缩，若有必要能够还思考 gzip 压缩，取得更大的压缩比。
- 资源申请合并，过多扩散的资源包会产生过多的网络申请，但也不能随便合并，最佳的形式是依照页面或者模块进行划分，并配置 async 属性来异步加载 script 脚本。
- 配置浏览器缓存，次要指强缓存和协商缓存，能够大大减少网络时延，缩小服务器压力。
- 按需加载，对于单页利用，如果在首页就把整个站点的资源全副下载，其实是不合理的，应用按需加载（懒加载）的形式能够无效进步首页性能。
- 骨架屏也是在挪动端页面首屏优化的一个重要伎俩，在页面数据未筹备好的状况，相比与干燥的白屏页面而言，展现骨架屏能给用户一个好的感官体验。然而如何生成品质高的骨架屏也是一个难点，须要综合思考 ROI 来抉择是否应用骨架屏。
客户端视角
从客户端角度动手，其实是客户端预加载动态资源或者提前内置到手机本地，因而客户端须要保护要加载到本地的动态资源列表，当页面关上时，拦挡 webview 资源申请，依据资源 URL 路由到本地对应资源，这样的速度是极快的。本人去实现该过程会比拟繁琐，上述过程的实现其实就是离线包计划，离线包机制能帮忙做好动态资源更新、治理、拦挡、重定向以及异样链路，如支付宝的 nebula 容器自带离线包解决方案。然而单个离线包不宜过大，个别 0-4M，对于较大利用有时候会冲破这个限度，理论我的项目中将一些共用通用的框架资源（如 React、lodash、moment）提取进去，提前预置 APP 中来解决单个离线包大小限度，除此之外成熟的离线包计划自带公共包机制，也能够解决离线包过大的问题。下图是通过优化后资源申请状况，
能够看到应用离线包外加预置公共资源计划之后，动态资源的申请耗时间接降到 200ms 以下，简直所有的动态资源在首次关上页面就全副走本地存储，优化成果还是很显著的。
数据申请优化
一些在浏览器中关上的 web 页面可能不太重视数据申请的优化，在挪动端，因为谋求极致体验，往往数据申请也是有很大优化空间的。以下总结几点数据申请的优化思路。
申请合并
单页面数据申请接口压缩到 1—2 个，过多的网络接口申请，一是会有过多建链和断链的网络耗时，二是会进步接口申请失败率。尤其是相互依赖的接口，能够思考将申请进行合并。
申请提前
数据申请提前。首屏的数据如果在关上 webview 的霎时曾经筹备结束，那根本很快能够将页面展现进去。因而在对首屏性能要求较高的场景下，能够思考将接口申请提前在页面关上前，如 APP 关上后就提前开始缓存用户可能要关上的页面数据，在用户关上页面时从本地缓存获取数据。在理论我的项目中申请提前波及两个事实的问题，申请具体机会以及缓存问题。
- 申请机会。我参加的我的项目中，用户可能要关上的页面很多，无奈提前预知要缓存哪个页面的数据，初期应用粗犷的办法是在 APP 首页列表关上时把所有页面数据全副提前缓存，列表数据太多时性能很差，最终优化计划是应用局部缓存的形式，只对列表可见项进行提前缓存，用户在滑动页面时，只缓存可见项的页面数据，性能有显著晋升。
- 缓存问题，客户端提前缓存页面数据，会遇到缓存一致性问题，如何更新缓存在体验和正确性之间须要做衡量。我参加的我的项目没有健全的推送机制，服务端无奈被动告诉缓存更新，在这种状况下，何时更新客户端缓存是一个难题，个别客户端不会抉择短时间轮询形式进行缓存更新，因为轮询会大量耗费手机电量，也会造成服务端压力。最初应用一个折中形式，就义极少概率的正确性换取更好的体验，客户端会依据用户的一些行为来更新缓存，如杀过程、下拉刷新等，同时给缓存设定一个固定的有效期，有效期依据 APP 单次应用均匀时长（如 15 分钟）来设定，保障下次关上 APP 绝大多数用户缓存能更新。
webview 初始化
webview 是挪动端浏览器实例，简直具备 PC 端浏览器的绝大多数能力，客户端在应用 webview 关上 H5 页背后，须要实例化 webview 对象，其初始化的过程在 android 零碎中须要大概 500ms 以上的工夫。有一种伎俩是应用对象复用机制，提前创立 webview 对象池，须要应用 webview 时间接从池中获取初始化结束的对象，这种相似于线程池的形式能够防止每次关上 H5 页面都要初始化 webview 实例，从而晋升页面关上速度。
其余
还有另外一个齐全不同思路来优化挪动端 H5 页面关上速度，那就是服务端渲染，也称之为 SSR，简略来讲就是服务端将页面的 html 和数据提前组装好再传递给浏览器，浏览器只负责解析 html 和展现，因而首屏渲染较快。然而会给服务端减少压力和复杂度，事实中须要综合思考利弊以及 ROI 来抉择是否应用 SSR 计划。
实际成果
自己参加的我的项目在 H5 页面只针对动态资源和数据申请进行了优化，实现后取得成果还是较为理想的，见下图绿色线是优化之后页面关上的均匀白屏工夫，蓝色是优化前的均匀白屏工夫，能看到优化功效还是相当可观的，如果能将 webview 的初始化工夫也优化掉，基本上能达到页面秒开。
总结
以上是联合本人我的项目以及以往的经验总结的较为惯例的针对挪动端体验优化的思路，比拟通俗，其实每一个优化思路尽管说起来简略，然而在实践中会因为各种因素（如投入产出比，前后端资源协调等）导致夭折，而且优化思路也须要分场景，须要就地取材选用不同的计划。每一个优化思路都能够写长文进行深入探讨，体验优化是一个马拉松，须要长期继续的投入，有趣味的欢送一起交换。
逆锋起笔是一个专一于程序员圈子的技术平台，你能够播种最新技术动静、最新内测资格、BAT 等大厂的教训、精品学习材料、职业路线、副业思维，微信搜寻逆锋起笔关注！
