客户端架构基础知识
前言：市面上关于产品经理的书，基本是都是入门书。之前我一直在想，为什么没有产品经理进阶的书籍。过了一段时间之后，我感觉有了答案：其实产品经理进阶的书早就有了，只是没有一个产品经理进阶的tag。这些书，可能是营销的书，可能是项目管理的书， 可能是心理学的书，可能是统计的书，可能是设计的书，可能是架构的书，可能是算法的书。总而言之，需要广泛的涉猎。
当然，这些书里面也有优先级，不同的人，需要根据自己的工作需要，去调整自己的阅读的优先级。如果说的更直白一些：工作中，你最不想被谁骂傻逼，那就看对方领域的书。
言归正传，这一章节会汇总一些客户端基础架构的知识，同时也会举个具体的设计实例。
1. 客户端的架构
客户端页面被访问的时候，一些非固定的元素，需要去请求API。
客户端的数据可能来自各个业务线，API请求各个业务线的接口，并组织成APP需要的格式返回给API。
对于业务线的服务端而言，它的数据也来自于基础数据库，也需要根据基础数据库的变化进行更新。
2. 举个例子
我的专栏在客户端页面的展现：
最顶部：返回按钮，标题栏，操作按钮；头部：logo，专栏名称，专栏关注人数；底部：文字卡片流。
而卡片流包括：头像，昵称，文章图片，文章标题，文章导语部分，文章赞同数量，文章评论数量，文章发布时间。
可能请求了两个接口：第一个API接口，专栏基本信息的接口。第二个API接口，卡片流接口。
在文章基本信息的API接口里，需要返回标题，logo，关注人数。而API会请求对应的服务接口，这个服务接口可能是个通用接口，有更多专栏的基础信息，比如有专栏拥有者的昵称和头像。而API则根据客户端的应用场景进行处理。
在卡片流的API接口里，需要返回头像，昵称，文章图片，文章标题，文章导语部分，文章赞同数量，文章评论数量，文章发布时间。同样的，可能请求的接口中数据更多，而请求到的时间则是UNIX时间，需要处理成客户端需要的时间格式。
同时，服务端的数据在基础数据有更新的时候也会根据一定规则进行更新。
3. 基础设计实例：
当我们了解了基础原理了之后，在做产品设计的时候就可以考虑的更长远一些：比如，扩展性。简单来说，对于客户端而言，尽可能不要做太多逻辑处理，而是只展示API给的数据。如下图，客户端只负责划定显示区域，不做任何文字的展现，这样对于扩展性更好。
比如：如果想在展示赞、评论，时间的展示栏，需求调整，希望增加收藏数的显示，则这种显示逻辑下，直接在API增加收藏数的显示即可。而如果客户端处理为：X赞·X评论·X天前（赞，评论，天前为客户端写死），则修改时间格式或者增加收藏数的显示，就需要发版本。
4. 结语：
为什么要了解客户端的架构知识？除了尽量避免不被工程师骂傻逼之外，也是在设计之初就可以往长远考虑。很多时候熟悉业务的产品经理更能前瞻性的预测到功能的后续发展方向，可以提前做好前瞻性设计。可以和研发共同讨论，避免实现方式过于死板，后续的一些突发的运营功能扩展需要发版解决；也可以避免研发在缺少对需要发展了解的基础上，做出不必要的冗余设计来猜测未来的需求。
最后要说的是，懂一些基础的技术知识，来避免被骂傻逼其实作用比较有限。毕竟程序员骂产品经理，大多数情况句式是：“这个傻逼又改需求”，而不是“这个傻逼一点技术都不懂”。
既然来了，说些什么？