《跨终端web》读后感

首先吐槽一下，这大概是我看到有奖试读那么多期图书里试读样章中实际内容最少的一本了，本来就只有20几页，一大半是目录和序言，唯一的一章充其量只能算是导读，而且“导读”中还包括了好几张半页篇幅的大图 = =，剩下的文字中还有一半是在讲解并非本书核心的“响应式编程”。因此与其说是这本书的试读，不如说是一篇关于跨终端web介绍性的博文。

就是在这样一篇篇幅稍长的“博文”中，还是能找到两个核心点：
1、多站点和多模板的响应式解决方案
2、采用Webview可以降低APP的开发和上架周期

第一点，书中的笔墨不多，但是分析得比较透彻。我谈谈我的理解，多站点是一种主动形态的“响应式”。通过不同的域名维护不同的页面模板，引导用户选择适合自己设备分辨率的入口。这在当时已经是一种非常牛叉的用户体验。但是带来的负面影响除了书中所说的带来了维护二级域名的成本之外，还会有如下影响：

1、网站结构问题。比如为终端设备而设置的wap.baidu.com/3g.baidu.com/iphone.baidu.com明显不应该和以业务线设置了music.baidu.com/tieba.baidu.com等同时处于二级域名这个维度下。
2、响应式无法涵盖到各个页面，造成用户体验不一致。经常会在手机上看到某些域名下的确适配了当前分辨率，但是一旦点击某些链接到了别的域名下则会使用默认分辨率页面下，用户体验瞬间大打折扣。

至于多模板，我猜想的流程是这样，先判断当前用户的user agent，选定调用模板，再根据分辨率进行微调。书中提到会造成DOM冗余的问题，所以更适合主体性非常强的页面，比如某些活动专题页面。

第二点，webview带来的有点在于，内容和客户端的解耦和，比如一些活动页面不再是客户端的一部分，在多数情况不需要用户“升级到最新客户端”后才能参加活动。这种做法从设计角度上来说非常好，带来的问题主要是在于容易被一些稍微懂得抓包技巧的人得到活动的漏洞。首先毕竟不是客户端的一部分，可以通过抓包获取页面真实地址，所有的传输数据一览无余，然后通过程序模拟请求就可以批量刷奖。即便很多参数通过客户端本身产生，无法直接构造参数，依然可以通过植入自定义js的方式通过webview在执行过程中自动提交请求。如果不使用webview则可以在很大程度上避免这种情况的发生。

发现谈的比较多的还是个人对于试读内容的理解，我看目录发现history API等等是我比较感兴趣的话题。而且后面几章的一些实践可能能从某种程度上解决我的困惑，希望能有得到赠书的机会。

-------------------分割线---------------------
关于webview的问题，后来想了下，将活动写进客户端里应该是弊大于利的，比如一个一旦有了bug之后，用户可以选择不升级，就可以一直利用上个版本的漏洞了，更不用说app的上架周期。我的想法在于，能否使用类似webview的方式，但是嵌入的不是web html？