什么是APP混合开发？

是指介于web-app、native-app这两者之间的app,它虽然看上去是一个Native App，但只有一个UI WebView，里面访问的是一个Web App。

在为某奢侈品牌集团旗下的彩妆护肤连锁零售客户搭建APP的时候，我们采用了混合开发模式，原因主要有以下几点

所有页面都用native的话，工作量巨大，而且后期维护成本很高, 对一处页面的调整，需要同时修改Mobile站点(以下简称M站)和app

M站已经成型，checkout ，支付 等核心流程都已经在页面中实现好了，开发周期可以被大大缩短

Sounds good！我们来看看实际开发中会遇到什么吧

通过User-Agent来显示不同的页面

虽然说页面会复用M站, 但是页面的细节部分还是会有区别，例如 title, 跟踪代码什么的， 鉴于APP可以监听所有的请求，

所以很自然的想到可以让APP修改User-Agent(以下简称UA), 即在默认UA 后面加个后缀，前台通过UA判断请求是是来自M站还是APP。

想法听上去没有什么问题，本地测试也是OK的，结果到了Stage环境却不生效了，分析了半天，发现忽略了一个重要的东西--缓存

虽然我们的页面可以通过UA来区分请求来源，但是缓存还是按URL来缓存的，好在目前主流的缓存设备(CDN, varnish)都支持根据不同

的UA来缓存，但是，如果缓存设备不支持呢？那就只有通过加参数或者新建一个新的URL来区分了。

结论: 通过UA判断请求来源的方法是effort最小的方法，但是需要考虑到当前网站的缓存方式是否也同样支持按UA区分

JS动态修改还是页面直接生成？

上一个问题解决判断请求来源的问题，那么采用何种方式来修改页面元素， 在是页面onReady事件中动态替换还是通过JSTL的方式在

页面生成时就确定好， 一开始我们选择的前者，因为前者的改动量最小，但是在后来的测试中发现通过JS修改页面元素有个致命的问题

页面修改后会闪一下，用户体验会很差，所以只能选择后者

结论: 页面直接生成的方式虽然effort高，但是用户体验比JS动态修改好

webview性能瓶颈

在测试中，我们发现当页面元素很多(例如首页,PDP页面)， 或者服务器需要长时间处理的(例如订单提交页面) 用户的体验会非常差，即使

增加了loading遮罩，效果也不是很理想，有时还会出现遮罩去不掉的情况，所以当遇上以上2中情况时，最好能抽成native的页面，通过接口

的方式提交，这样用户体验会更好

结论：在设计时，需要考虑页面元素很多(例如首页,PDP页面)， 或者服务器需要长时间处理的(例如订单提交页面) ，看看是否可以抽成Native页面+接口的方式，另外动静分离也是一个不错的选择

如何实现支付?

因为本项目之前已经有个M站，所以一开始的想法是所有支付都走网页版的移动支付， 不走APP版的移动支付，但是在实际测试中发现如果走网页版的移动支付，

第三方的支付网关会提示你是否使用app支付，当你选择app支付并支付成功后，无法返回原来的app中，只能依靠用户通过回到桌面再点开APP的方式重新打开APP，

显然这种用户体验会比APP版的移动支付差太多

结论：从用户体验出发，APP版的移动支付比网页版的移动支付好太多了

混合开发一定是未来的主流，因为没有一个客户会为了APP 和微信各开发一个native版和一个H5版的移动网站，但是如何做到既能兼顾用户体验和开发进度是个很困难的问题，

只有从项目中慢慢总结了