PWA(Progressive Web App)初探总结

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/qq_19238139/article/details/77531191
PWA

        今天开始 Research 一个新的前端技术,PWA( 全称:Progressive Web App )也就是说这是个渐进式的网页应用程序。这个技术的呢是 Google 公司于2015 年提出的,2016 年 6 月才推广的项目。针对这一项技术目前在国外似乎已经很流行了,目前应用这项技术最火热的应用是在印度( 大家或许会疑惑为什么是在印度最流行呢吧,下文中会告诉大家哦 ),既然 PWA 这项技术在国外已经非常的流行了,那么在国内或许会不远了( Angular 5 中新增的功能中,重点在于能够更轻松的构建渐进式网络应用程序,也就是 PWA 了。作为Google 和 mozilla 的产物,肯定会越来越重视啦 )我引用一下关于PWA技术的一篇最早的博客文中的一句话吧: “ escaping tabs without losing our soul “( 翻译一下哈:逃避选项卡而不丢失我们的灵魂 )。

        官网上给出 PWA 的宣传是 : Reliable ( 可靠的 )、Fast( 快速的 )、Engaging( 可参与的 )( 官网:https://developers.google.com/web/progressive-web-apps/     ps:需要翻墙哦  )。简单的说一下这三个特性:

                 Reliable : 为什么他是可靠的呢,当用户从手机主屏幕启动时,不用考虑网络的状态是如何,都可以立刻加载出 PWA。

     
                                                                

                 Fast:这一点应该都很熟悉了吧,站在用户的角度来考虑,如果一个网页加载速度有点长的话,那么我们会放弃浏览该网站,所以 PWA 在这一点上做的很好,他的加载速度是很快的。


                                                              
                                    
        
                 Engaging : PWA 可以添加在用户的主屏幕上,不用从应用商店进行下载( 似乎省了下载流量哦!)他们通过网络应用程序 Manifest file 提供类似于 APP 的使用体验( 在 Android 上可以设置全屏显示哦,由于 Safari 支持度的问题,所以在 IOS 上并不可以 ),并且还能进行 ”推送通知” 。

                                               


         这三个主特性似乎能解释我在前言中所说的 ”在印度最流行“ 。小小的普及一下,根据2016年第三季度的 IDC统计数据显示,印度的智能手机的出货量达到了3亿,同时也超过了美国,成为了全球第二大只能手机市场。皮尤斯数据报告 2015 年曾统计过“全球智能手机拥有率”。印度只有 17% 的人口用的是智能手机。虽然绝大部分人有手机用,但为非智能机,另有 22% 的人没有手机。针对印度的移动网络流量来说,网络状况是非常不佳的,根据16年的 GSMA 印度移动经济报告显示,网络覆盖率为34.8% 。主要集中在城镇,印度广大的农村还处于网络盲区,城乡数字化鸿沟很大。在印度,2G/3G 最主流,且 2G 占比还远高于 3G , 所以针对这种状态来说,PWA 技术最适合不过了。 

        在我对 PWA 技术的研究中发现 PWA 其中有三个关键的技术:

                Service Worker( ps:就叫做服务工厂吧,文章最后一条 URL 是 SW 的全面进阶,可以研究研究哦 )
               
                Manifest (应用清单)

                Push Notification(推送通知)

        下面我一一介绍着三个关键的技术:

                Service Worker( 以下用SW来代替 ) :

                SW 是什么呢?这个是离线缓存文件。我们 PWA 技术使用的就是它!SW 是浏览器在后台独立于网页运行的脚本,它打开了通向不需要网页或用户交互的功能的大门,因为使用了它,才会有的那个 Reliable 特性吧,SW 作用于 浏览器于服务器之间,相当于一个代理服务器( 用一张图来表示一下他的位置 )
                        
                                         

                为什么会用到 SW 呢?原声 App 拥有Web应用通常所不具备的富离线体验,定时默认更新,消息推送等功能,而 SW 标准让在 Web App 上拥有这些功能成为可能!
                跟 SW 相同的 API 还有 App Cache ,为什么不使用它呢? App Cache 是有局限性的,比如说:它很容易得解决 single web page application ( 单页面应用 )的问题,但是在多页面应用上会很麻烦, SW 解决的这个 App Cache 的缺点!

         下面我简单而详细的说一下 SW :

              1、 浏览器支持
                        
                        顺便带一句:目前只能在 HTTPS 环境下才能使用SW,因为SW 的权利比较大,能够直接截取和返回用户的请求,所以要考虑一下安全性问题。

                        

               2、事件机制
                                                    
               3、 功能
                     SW的功能还是比较逆天的!
                     
  • 后台数据的同步
  • 从其他域获取资源请求
  • 接受计算密集型数据的更新,多页面共享该数据
  • 客户端编译与依赖管理
  • 后端服务的hook机制
  • 根据URL模式,自定义模板
  • 性能优化
  • 消息推送
  • 定时默认更新
  • 地理围栏
        
               4、 生命周期

                           
            
                      Parsed ( 解析成功 ): 首次注册 SW 时,浏览器解决脚本并获得入口点,如果解析成功,就可以访问到 SW 注册对象,在这一点中我们需要在 HTML 页面中添加一个判断,判断该浏览器是否支持 SW 。
    
                      Installing ( 正在安装 ):SW 脚本解析完成之后,浏览器会尝试进行安装,installing 中 install 事件被执行,如果其中有 event.waitUntil ( ) 方法,则 installing 事件会一直等到该方法中的 Promise 完成之后才会成功,如果 Promise 被拒绝,则安装失败,SW会进入 Redundant( 废弃 )状态。

                      Installed / Waiting (安装成功/等待中):如果安装成功,SW 将会进入这个状态。

                      Activating ( 正在激活 ):处于 waiting 状态的 SW 发生以下情况,将会进入 activating 状态中:
                                
                              当前已无激活状态的 worker 、 SW脚本中的 self.skipWaiting()方法被调用 ( ps: self 是 SW 中作用于全局的对象,这个方法根据英文翻译过来也能明白什么意思啦,跳过等待状态 )、用户已关闭 SW 作用域下的所有页面,从而释放了当前处于激活状态的 worker、超出指定时间,从而释放当前处于激活状态的 worker 

                      Activated ( 激活成功 ):该状态,其成功接收了 document 全面控制的激活态 worker 。

                      Redundant ( 废弃 ):这个状态的出现时有原因的,如果 installing 事件失败或者 activating 事件失败或者新的 SW 替换其成为激活态 worker 。installing 事件失败和 activating 事件失败的信息我们可以在 Chrome 浏览器的 DevTools 中查看:
    
                                                         ( ps:我这个是正常的状态下的 ,错误的话会有 error 提示的 )
                        

              5、主要依赖

                    SW 作为现代浏览器的高级特性,依赖于 fetch 、promise 、CacheStorage、Cache、等浏览器的基础能力, Cache 提供了 Request / Response 对象对的存储机制。CacheStorage 则提供了存储 Cache 对象的机制。

                                                    

            6、安全性问题

                 跨域请求支持:  SW 可以拦截它作用域内的所有请求,跨域资源也不例外,但是浏览器默认对跨域资源发起的是 no-cors 请求,得到的 response 是 opaque 的, 所以会导致我们无法判断跨域请求是否成功,以便进行缓存,因此我们需要修改 fetch 请求头部信息,添加 mode:’cors’ 标记。

                ( 名词解释一下喽,这部分知识是关于 fetch API 的,想了解更多的同学,自行搜索相关的知识哈 )
                no-cors:该模式允许来自 CDN 的脚本、其他域的图片和其他一些跨域资源,但是首先有个前提条件,就是请求的 method 只能是 HEAD 、GET 、POST 。此外,如果 ServiceWorkers 拦截了这些请求,它不能随意添加或者修改除这些之外 Header 属性。第三,JS 不能访问 Response 对象中的任何属性,这确保了跨域时 ServiceWorkers 的安全和隐私信息泄漏问题。
                opaque:Response 对象中 type 属性的值 , 在 ‘no-cors’ 模式下请求了跨域资源,依靠服务端来做限制。

            分享给大家一个 SW 全面进阶的博文:

        Manifest ( 应用清单 )

              Web App Manifest 是一个 W3C 规范,它定义了一个基于 JSON 的 List 。Manifest 在 PWA 中的作用有:
                   
                  能够将你浏览的网页添加到你的手机屏幕上
                  在 Android 上能够全屏启动,不显示地址栏 ( 由于 Iphone 手机的浏览器是 Safari ,所以不支持哦)
                  控制屏幕 横屏 / 竖屏 展示
                  定义启动画面
                  可以设置你的应用启动是从主屏幕启动还是从 URL 启动
                  可以设置你添加屏幕上的应用程序图标、名字、图标大小

        Push Notification ( 消息通知 )

              Push 和 Notification 是两个不同的功能,涉及到两个 API 。

              Notification 是浏览器发出的通知消息。
            
              Push 和 Notification 的关系,Push:服务器端将更新的信息传递给 SW ,Notification: SW 将更新的信息推送给用户。

        缺点:
                
              1、浏览器的支持度问题,尤其是 Safari 浏览器,这样就会导致我们在 IOS 系统手机上没办法体验 PWA 。( 谁让 ‘ 果果 ’ 不是开源的呢 )
                
              2、根据国情来看哈,目前 Native App 的使用用户都已经习惯了,虽然会下载一下,但是现在 WiFi 到处都是了,毕竟 WiFi 的普及太快了。让用户使用 PWA 来替代 Native App 短时间会不适应的。
            
              3、消息推送问题,PWA的消息推送走的是 GCM( FCM )通道。而国内 Google 是无法访问的。(只能翻墙了,但是工信部已经禁止使用 VPN 了。) 
              总体来说:
                    Google 的技术在国内推进比较缓慢,所以 PWA 在国内的发展是有多困难吧。

Demo

           首先呢,我们用到有 Node 和 Ngrok 。Node 的使用以及安装我就不说啦,作为一名前端开发工程师肯定会使用的啦。不会使用也米有关系啦,我们有度娘呢,Ngrok 的安装以及使用我就直接共享一个URl吧:http://blog.csdn.net/tomcat_2014/article/details/68944066( ps:我就偷懒一下 )
           对了,我使用的是 Mac 本(我司配的啦),所以我接下来的流程和截图都是 Mac 本上的。
           
           我们先创建一个关于 PWA 的项目文件夹,
                   
                进入文件夹下我们准备一张 120x120的图片一张,作为我们的应用程序图标。
                创建一个 index.html  文件
                创建一个 index.css 文件
                创建一个 manifest.json 文件
                创建一个 sw.js 文件
                利用终端,安装一下 http-server 服务
                下面我们看一下每个文件中的代码是什么吧:

                index.html
       
        
                index.css
                 

                manifest.json
                    
                    short_name: “ " 用户主屏幕上的应用名字
                    display : “standalone"  设置启动样式,让您的网络应用隐藏浏览器的 URL 地址栏
                    start_url : “/“ 设置启动网址,如果不提供的话,默认是使用当前页面
                    theme_color : “ “  用来告知浏览器用什么颜色来为地址栏等 UI 元素着色
                    background_color: “ ” 设置启动页面的背景颜色
                    icons:””  就是添加到主屏幕之后的图标

                

                sw.js

                处理静态缓存,首先定义需要缓存的路径,以及需要缓存的静态文件的列表。
                借助 SW 注册完成安装 SW 时,抓取资源写入缓存中。使用了一个方法那就是 self.skipWaiting( ) 这个方法我在前边介绍的时候也说了,为了在页面更新的过程当中,新的 SW 脚本能够立刻激活和生效。

                
                
                 处理动态缓存,我们监听 fetch 事件,在 caches 中去 match 事件的 request ,如果 response 不为空的话就返回 response ,最后返回 fetch 请求,在 fetch 事件中我们可以手动生成 response 返回给页面。
                 更新静态资源,缓存的资源会跟随着版本的更新会过期的,所以会根据缓存的字符串名称清除旧缓存。在新安装的 SW 中通过调用 self.clients.claim( ) 取得页面的控制权,这样之后打开页面都会使用版本更新的缓存。旧的 SW 脚本不在控制着页面之后会被停止,也就是会进入 Redundant 期。
 
                

                以上截图中最左侧是我文件下的列表喽,下面我们来运行一下,终端启动 http-server 服务,我们以关闭缓存的方式进行启动。

                

                接下来我们使用 ngrok 这个工具,进行内网穿透。在上边启动 http-server 服务的时候我们使用默认的端口号 8080 。所以我们在 ngrok 中我们绑定 端口 8080 。输入命令 : ./ngrok http 8080 之后我们看一下。(记得再打开一个终端哦,在另一个终端中进行操作)

                

                我们看到绿色的字母 online 表示内网穿透成功了,我们看最后一个 Forwarding     https:// 的,因为我们在上边介绍了,SW 的权利比较大,为了保证信息的安全性,我们使用 https 协议来进行访问。我们把它复制下来在 chrom 浏览器中打开,-> 符号后边的就不用复制了哈。( 每个人的 ‘隧道’ 都是不一样的哦,这一点同学们可以在 ngrok 官网中进行查询哦 )。
                 我们打开 chrom 的调试工具,打开 application ,点击 service workers 之后我们会发现 sw.js 脚本已经存到了 SW 中 。

                

                我们打开 Network 刷新页面一下,看看,我们的页面资源来自 SW 而不是其他的地方,在 Console 中也打印出了我们在 index.html 中判断的语句,浏览器支持就会打印出这一句话哦。

                

                接下来我们断网操作,在 Application 中给 Offline 打上对勾就行啦。然后刷新页面,我们仍然能看到之前的页面,原因就是我们在上图看到,他的资源是从 SW 上获得到的。当我们第一次打开这个页面的时候,Resopnse 对象被存到了 Cache Storage ( 定义在 SW 规范中 ,相关资料请同学们自行查询啦 )中,我们看下图:

                
                
                通过存放到 Cache Storage 中,我们下次访问的时候如果是弱网或者断网的情况下,就可以不走网络请求,而直接就能将本地缓存的内容展示给用户,优化用户的弱网及断网体验。

                这个时候肯定会有同学在想,如果内容更新了,那么页面展示的内容是新内容呢还是旧内容呢?下面我们操作一下,打开 index.html 文件,我们在 body 中添加一个 p 标签 ,然后回到页面刷新。

                
                

                我们看到,页面上的内容并没有显示出我刚刚添加的那个 p 标签。这说明了,我们拿到的数据还是从 Cache Storage 中获取到的,Cache Storage中的内容并没有更新,那么我们怎么才能让我刚刚添加的那个 p 标签显示出来呢。
                我们打开 sw.js 脚本文件,我们修改一下 cacheStorageKey。

                
                
                我们关闭一下浏览器,然后再次打开该网址,页面出现了我们刚刚添加的那个 p 标签。我们再看一下 Cache Storage 中的缓存名字,已经被修改。

                

【 总结 
        
        总结一下吧,在研究这个 PWA 的过程中,搜索了相关的一大部分知识,就怕自己的脑洞不够大。感觉 PWA 涉及到的 API 比较多。要想研究透彻 PWA 还需要研究它所涉及到的 API ,慢慢研究吧。npm 中已经有这个包了哦。想真实的对 PWA 做深入研究的同学,可以应用到实际项目中。( 我感觉,会有很多坑 ),不过呢,作为一名前端开发工程师,对于这种技术研究来说,当然是有坑就补,没坑挖坑补。我会在接下来的日子中,抽出时间对 PWA 进行深入研究的。当然也会共享给大家。

        上文中如果有说错的,或者错误的,欢迎各位大神指出!可以直接加我 QQ :568815707 ,说明意图哦,不然会拒绝的。
        
     
                                            
                

参考URL( 有的是需要翻墙的哦 ):

                https://75team.com/post/lifecycle.html
                https://www.w3ctech.com/topic/866
                http://dongcoder.com/detail-397355.html
                https://www.npmjs.com/package/web-pwa
                https://www.villainhr.com/tag/SW

没有更多推荐了,返回首页