多进程，在app的主进程之外执行：
WKWebView为多进程组件（网络加载和UI渲染在其他进程中执行），也意味着会从App内存中分离内存到单独的进程中。 当内存超过了系统分配给WKWebView的内存时候，会导致WKWebView浏览器崩溃白屏，但是App不会Crash。(app会收到系统通知，并且尝试去重新加载页面)。 相反的，UIWebView是和app同一个进程，UIWebView加载页面占用的内存被计算为app内存占用的一部分，当app超过了系统分配的内存，则会被操作系统crash。
出现Cookies在App端不同步的问题 拼接Cookies的方式（常用）： 因为WKWebView的Cookies是WebKit的，和NSHTTPCookieStorage不是同步的，所以WKWebView加载url时候要拼接上去。 同样为了解决跨域问题，在代理中decidePolicyForNavigationAction每次跳转之前拼接Cookies 注入JS代码的方式： 通过document.cookie同步到NSHTTPCookieStorage，简单方便。 WKWebsiteDataStore：iOS11.0以上 [WKWebsiteDataStore defaultDataStore].httpCookieStore; 同步NSHTTPCookieStorage和WKWebView的Cookies，但是目前只支持iOS11.0以上的系统。
加载工作：
初始化 webview -> 请求页面 -> 下载数据 -> 解析HTML -> 请求 js/css 资源 -> dom 渲染 -> 解析 JS 执行 -> JS 请求数据 -> 解析渲染 -> 下载渲染图片
前后端优化：
- 降低请求量：减少 HTTP 请求数, 合并资源，minify / gzip 压缩，webP，lazyLoad。
- HTTP 协议缓存请求，离线缓存 manifest，离线数据缓存localStorage。
- 加快请求速度：预解析DNS，减少域名数，并行加载，CDN 分发。
- 渲染：JS/CSS优化，加载顺序，服务端渲染模板直出。
对首屏启动速度影响最大的就是网络请求，包括请求 HTML、css、image 等静态资源和展示数据的请求。客户端内，优化最关键的其实就是如何缓存这些网络资源，也就是离线包缓存方案。
离线包缓存方案：
- 基于 LocalWebServer 实现 WKWebView 离线资源加载 在打开APP后直接启动Webserver，H5的链接直接替换成本地localhost+端口号链接的地址。
- 使用WKURLSchemeHandler实现 WKWebView 离线资源加载 APP在启动时开始下载静态资源zip包并解压到本地。WKWebview通过WKURLSchemeHandler拦截并加载本地资源文件。 离线包的分发，就是普通的zip离线包和一个版本控制的json文件，每次打离线包会修改json文件里的版本号，并附有离线包下载地址。
