0.前言
作为产品经理，不想被技术骂成傻逼，那就看一点关于技术的书，不需要掌握，知晓原理就成，知道自己设计的产品在技术层面如何进行运作的，这十分有必要。Ok，写篇文章简单介绍一下客户端架构的基本原理，但不涉及具体的代码实现。另外，“架构”这个词听起来很牛逼，这里装逼用一下，真正的架构会比这复杂的多！
1.客户端架构原理
客户端即前端，就是我们平时使用的APP、打开的网页等，主要是对数据的展示，一切用户进行可视化操作的统称为客户端。当我们使用一款APP，在把玩的过程中，会与后端进行通信，把用户想要的东西展现出来，其原理如下图：
拿我经常使用的手机“凤凰新闻客户端”为例，当你对新闻客户端里面的某条新闻感兴趣并点击这条新闻，客户端立马组织数据请求，这时用户界面开始展示loading（表明客户端在向后端请求数据），经过几百毫秒的时间，这个时候请求数据已经到了服务器，服务器开始查看客户端想要请求哪方面的数据（是请求的哪条新闻），服务器看到你请求的是“XX新闻”，并通过API接口将查到的数据返回给客户端，传回的数据被客户端接收，loading消失，你将会看到“XX新闻”的具体内容。对于服务端而言，他的数据来源于基础数据库，基础数据库的数据如果有变动，他也需要随着基础数据库的变化而更新。
2.前端和后端如何进行数据传输
现在流行的做法通常有两种，一种是类似于PB（Protocol Buffer，Google定义的一个数据传输协议，以简洁，省流，易用出名）的二进制数据（二进制数据的意思就是你打开这个文件你只能看到0和1组成的数字串，是没办法和你生活中任何认识的字母联系在一起的）传输，这种格式的好处是包小，重复的字段会被节省。另一种是JSON（JavaScriptObject Notation），这也是一种轻量级的数据传输格式，就是用一堆中括号把数据组织起来，不像二进制，这种格式是人可读的，并且比较轻巧，所以也有大量的应用场景。
3.实例说明
以我现在做的一个电商APP的“订单确认”界面（与后端进行数据通讯最多的一个界面）为例：
这个订单确认界面需要与后端进行数据通讯，需要通讯的数据有：收货地址、支付方式、红包选择、发票、商品金额、运费、优惠、满减、最终需支付金额。这些与服务端进行数据交互都需要接口来实现。
在收货地址的API接口里，需要返回收货人姓名、电话、收货详细地址，这个API会请求对应的服务接口；在红包接口当中，需要回传红包的面额、使用期限、红包名称，一旦用户选择了某个红包，客户端会通过API接口向服务端请求这些业务数据。红包数据请求过来后，界面在极短极短的时间内刷新，并在再次向后端请求最后支付金额的基础数据，通过这一前端和后端的交互，最终的支付金额数据被传回来。其他的几个接口也基本是这样的交互形式。
4.设计注意事项
我们知道客户端架构的基本原理之后，在做产品设计的时候就可以考虑的更长远一些，比如我们一直强调的系统可扩展性！简单来说，对于客户端而言，尽可能不要做太多逻辑处理，而只是展示API给的数据，逻辑处理尽量后台来完成。客户端只负责划定显示区域、数据的显示以及页面与页面之间的交互，这样怼扩展性会更加好。这就需要前端不要把“程序写死”，一旦写死，以后需要对现在写死的内容进行修改，那就要重新发布版本了，要知道，重新发布一个版本（特别是发布到APPstore）成本是较大的。
