先了解这些 Web App ，你可以少走很多弯路

　　最近几年，随着前后端分离、单页面应用的崛起，网页正变得越来越应用化。移动互联网端的发展更是助长了这个趋势——对于交互、性能不敏感的场景，Web App在开发成本、跨平台兼容上有着明显优势。

　　但在这火爆的行情背后，很多时候从产品经理到设计甚至开发，对Web平台的特性并没有足够的了解与警觉，导致最终产品成了既不App也不Web的四不像，不仅拖累用户体验，开发团队也容易无所适用。

　　这篇文章希望围绕着Web的特性，探讨Web App与Native App的不同，帮助读者在项目中尽早地识别出可能出现问题的场景。

　　Web App is NOT App

　　Web App 也要按照基本法

　　Web App或者单页面应用（Single Page Application），名字里带个App，听起来颇有鸟枪换炮的味道，无论是工程师还是利益关系人（产品经理、客户），难免会有 和尚摸得我摸不得，App做得我做不得？ 的错觉。更有甚者，把原生App的设计稿P上个浏览器地址栏就丢给团队，让照着做个Web App出来。如果这是你遇到的情况，那么恭喜，你已经在被坑的路上了

　　俗话说入乡随俗，既然运行在浏览器上，即使Web App能很大程度上提供 接近 App的体验，但有几点，是从根本上不同于App而又必须考虑的：

　　1. 应用入口与访问路径

　　App对用户的访问路径拥有近乎绝对的控制权：用户从哪些地方进入应用（图标、通知栏、分享链接）有限且可预测。而每一页提供的操作入口之和，都是用户当前可访问的子路径的 全集 。

　　而 Web对用户的访问路径控制权近乎为0 ：任何页面的URL都是对用户可见的，用户可以添加书签，分享给亲友——任何页面都可能被直接访问， 必须 在设计和架构层面考虑。

　　鉴权和被访问并不矛盾：本文中被访问严格来讲是被用户请求，而鉴权或重定向则是对请求的处理

　　2. 刷新、后退、前进

　　这三个操作是所有Web浏览器工具栏的标准配置，而App多数情况下只需要考虑返回操作。

　　最麻烦是刷新：它会清空页面内存、重新发起请求、重新执行脚本。这意味着 Web端跨页面的内存数据是不可靠的 ，如果A页面依赖了B页面放在内存中的数据，下次刷新时得到的只会是 undefined 。

　　3. 上下文隔离

　　用户可能在应用或站点上进行一系列的、跨页面的操作，这些用户行为称为 上下文 ，而操作产生的数据（比如用户选择或表单输入），本文接下来称作 上下文数据 。

　　由于App对路径拥有绝对的控制权且不考虑刷新，某种程度上说App打开新的视图和在网页上打开模态窗的成本是一样的，下游页面可以假定上游页面生成的内存数据一定存在，而这些数据完全通过代码存取，对数据结构没有限制，因此 App端的上下文数据是复杂、可依赖的 。

　　反观Web，由于每个页面都可以被直接访问、刷新、甚至是复制链接到另一台设备上访问，存储在内存、LocalStorage中的数据都因此变得不可依赖，唯一能可靠传递的上下文信息 仅限于URL可以表征的数据 ， 在没有服务器帮助的情况下，Web端的上下文数据是简单或不可依赖的 。

　　现代移动端浏览器提供了一种 应用模式 ，可以屏蔽浏览器工具栏，让页面更像原生App。然而现阶段真实应用的案例并不多见，并且至少有两个问题：

　　后退无法完全屏蔽：安卓平台的系统 返回 键等同于浏览器的 后退 。

　　移动端随时吃紧的内存可能导致当前不活动的页面被内存回收，下次打开时重新加载——相当于一次刷新。

　　为什么URL重要？

　　上面三点其实都围绕着核心——URL，某种程度上说， 整个Web世界都是被URL标识并驱动的，每个URL都应该定位到相应的资源

　　而现实的情况是：可能你在做一个面向消费者（以下称 2C ）的项目，但需求方压根就没提URL和刷新的事；也可能你做的只是一个后台管理系统，不会有人在乎这东西，甚至会有一些和URL的定位特性相悖的需求。

　　这是最可怕的事，也是我写这篇文章的初衷：在真正遇到麻烦前，很少有人（甚至包括资深的前端工程师）会全面的思考这类问题，等掉到坑里的时候才发现积重难返。

原标题：先了解这些 Web App ，你可以少走很多弯路

关键词：web