Abstract：在PM逻辑层里，对客户端架构的理解属于基础产品逻辑。客户端<——>API<——>服务端<——>数据层。
APP客户端架构解释
客户端页面：最好只负责展现信息（即API给的数据），不要太多多余的逻辑处理。客户端页面被访问的时候，一些非固定的元素，需要去请求API。
只展示API给的数据的优点：扩展性高，即当界面展示信息的需求需要调整时，可以只改API，而不用改客户端。如果把界面信息展示的逻辑写死在客户端上，则需要发新版本才能修改。
API：客户端的数据可能来自各个业务线，API请求各个业务线的接口，各个业务线的服务端需要将数据组织成APP需要的格式返回给API。
业务线的服务端：数据来自于基础数据库，需要根据基础数据库的变化进行更新。
举例：个人知乎专栏首页信息架构分析
最顶部：返回按钮，分享按钮；专栏信息（名称，Logo，关注量，简介）
卡片流：头像，昵称，文章图片，文章标题，文章导语，文章赞同数，文章评论数，文章发布时间。
由客户端展示的信息分析，可能请求了2个API接口：
- 1.专栏基本信息接口；
- 2.卡片流接口；
API为了能够返回如上信息，会去请求对应的服务接口（可能是通用接口，有专栏的所有基础信息，超出需要展示的信息的范畴，则API需要根据客户端的应用场景进行处理）；然后服务端会去向数据层请求基础数据，把基础数据返回给API，API再对信息进行处理（数据格式+数据数量）。
服务端的数据在基础数据有更新的时候会根据一定规则进行更新.
为什么要了解客户端架构
- 前瞻性地预测功能的后续发展方向，避免实现方式过于死板，导致突发的运营功能扩展需要发版解决
- 需求最重要：懂技术知识来被避免被骂SB的作用有限，毕竟程序员骂PM的大多数情况是“这个傻逼又改需求”，而不是“这个傻逼一点技术都不懂”。
