产品狗要懂的技术原理（1）

写在前面的话：
我其实是一个特别不想也不愿意屈服于权威或者以往经验的人。从事产品狗四年来，唯一认怂的一件事就是，每当别人说，产品经理懂技术最好的时候，我虽然满怀愤慨，但是竟无语凝噎。

但是，本着事物总是变化的原理，我觉得这些门槛和障碍并不是不可以克服的。大多数的时候，被运营说不懂业务，然后花时间了解业务数据，商家需求，业务也就懂了；被交互视觉逼视审美太低，而多看看高逼格的产品学习借鉴，便也就有审美了；而作为门槛最高的技术，一直隐忍在心。事实上，愿意花时间，理解技术，整理其中原理，拨开神秘的面纱，也不会有什么难的事情。

这一个栏目，专门分享遇到过的技术原理。
献给同样不是计算机出身的产品汪～

客户端和服务端分工

这张图是我在手淘整理的客户端和服务端各自的分工，跟开发讨论和查阅一些资料获得的宝图。

一般来说，由于客户端受发布的限制，移动端的发布工期其实是1月／次，但是如果有什么问题，客户端不太好在发布版本，特别是苹果的审核周期是一个不明确的时间。所以，一般一些复杂的逻辑和计算都会做到服务端，这样修改起来不会特别麻烦，客户端主要在于前台界面展示和一些简单的逻辑：

客户端：
1）数据缓存，举例：
在大多浏览导购型的app，一般会做缓存，目的是便于在离线情况有内容可看，或者在在线的时候可以非常迅速的获取常用的数据（登录信息）。
2）数据请求，举例：
在配送app里，会把配送员的坐标上传，但是在客户端并不做任何逻辑处理，比如去噪等逻辑，只是获取信息。
3）展示规则，举例：
就是绘制app的页面，长，宽，高度，字体，颜色，图片，等等，传说中的高端词汇：渲染 －在某些格式无法识别的情况，需要对各个元素进行位置或者样式计算，从而“画”出样式，也包括一些高端的动画展示。
4）交互，举例：
点击，hover，下划，等常见的app操作。
5）简单跳转，举例：
页面和页面之间的跳转逻辑，其实这里还遗漏了一个数据埋点，包括页面埋点和控件埋点，通过这些埋点，可以获知用户的uv、pv以及路径的信息，来作为下一次优化的理论依据。

服务端：
1）开关，举例：
在某些大型活动的时候，会有一些次级的功能会消失，来提升页面的承载量，这个时候，会用到开关，或者有一些时候，发布点早于服务端发布，于是会在客户端先把功能上线，服务端后续开发完成测试通过后，打开开关上线功能。就类比一个后台的功能阀门一般。
2）逻辑计算，举例：
淘宝的购物，到交易页面，你究竟要付多少钱呢，这个是后台经过交易系统，营销系统计算得出，商品价格，各种优惠价格叠加或者不叠加，邮费（也包括地区判断邮费），得到一个总结果。凡事设计跨系统，并且计算特别复杂的时候，都是有服务端来负责。当然客户端也可以做，比如输入手机，校验下数字位数，是否纯数字等简单的逻辑，作为第一道防线。
3）数据存储，举例：
一般客户端缓存的数量不会特别大，不然app会占用太大空间。而你的交易，以前淘宝的交易要提供全部搜索查询的功能，这个数据的存储都在于服务端。一般都会以数据表的形式，需要大致了解其中的字段。而且服务端也是需要做一个阶段性清理存档，毕竟资源永远都是不够的。
4）展示内容，举例：
进过服务端的计算最后得出的结果将有服务端输出，其实这里是涉及到服务端与客户端交互的过程，它们之间需要定义接口字段，简单来说就是，服务端传a＝3，客户端可以知道这个意思是，a代表运费，3是3块钱。

客户端和服务端的交互
客户端上传服务端数据，服务端下发数据他们之间的交互方式也有轮询，长链接等方式。而这里，我们主要介绍，这个数据交互的过程是很消耗流量的。所以，一开始我们所提到的，将逻辑尽量做到服务端代表着服务端和客户端会有大量的数据交互，体验虽好，但是流量消耗较大，所以一个功能在客户端或者服务端实现也是一个需求平衡的过程，尽量保证逻辑沉淀在服务端，也要降低两者之间的交互次数。

文章来自微信：枣乐子