什么是客户端(客户端架构基础知识)

市面上关于产品经理的书基本都是入门书。我之前一直在想，为什么没有产品经理的进阶书？

过了一会儿，我觉得我有答案了:其实产品经理的进阶书已经有了，只是没有产品经理的进阶标签。

这些书可能是营销书、项目管理书、心理学书、统计学书、设计书、建筑学书、算法书。总而言之，需要广泛的参与。

当然，这些书中有优先顺序。不同的人需要根据自己的工作需要来调整自己的阅读优先级。如果更直白一点:在工作中，谁不想被骂成白痴，那就去读其他领域的书。

总之，本章将总结客户端基础架构的一些知识，并给出一个具体的设计示例。

1.客户端的架构

当客户端被访问时，一些非固定元素需要请求API。

客户端数据可能来自各个业务线，API请求各个业务线的接口，并将其组织成APP所需的格式返回给API。

对于业务线的服务器，其数据也来自基础数据库，需要根据基础数据库的变化进行更新。

2.举个例子

我的专栏在客户端页面上的展示:

顶部:后退按钮、标题栏、操作按钮；标题:标识、栏目名称、栏目关注号；底部:文字卡片流程。

卡片流程包括:头像、昵称、文章图片、文章标题、文章导语、文章审批数量、文章评论数量、文章发布时间。

可能会请求两个接口:第一个API接口和列基本信息接口。第二个API接口，卡流接口。

在文章基本信息的API界面，需要返回标题、logo、关注人数。API会请求对应的服务接口，可能是一个通用的接口，带有栏目的更多基本信息，比如栏目所有者的昵称和头像。API根据客户端的应用场景进行处理。

在卡流的API界面，需要返回头像、昵称、文章图片、文章标题、文章导语、文章审批数量、文章评论数量、文章发表时间。同样，请求的界面中可能有更多的数据，请求的时间是UNIX时间，需要处理成客户端需要的时间格式。

同时，在基础数据更新时，服务器数据也会按照一定的规则进行更新。

3.基本设计示例

当我们理解了基本原理，我们就可以在设计产品时考虑更长远的东西:例如，可扩展性。简单来说，对于客户端来说，尽量不要做太多的逻辑处理，只显示API给出的数据。如下图所示，客户端只负责划定显示区域，不显示任何文本，这样更有利于扩展性。

比如你想显示喜欢、评论、时间显示栏、需求调整，想增加收藏号的显示，那么在这个显示逻辑下，你可以直接在API中增加收藏号的显示。如果客户端处理为:x赞x评论x天前(赞，评论，为客户端写死天前)，如果修改时间格式或者增加收藏号的显示，则需要发布版本。

4.结论

为什么需要了解客户的架构知识？除了尽可能避免被工程师骂之外，在设计之初还可以考虑长远。很多时候，熟悉业务的产品经理更有前瞻性的去预测功能的后续发展方向，能够提前做出前瞻性的设计；可以和R&D商量，避免过于僵化的实现模式，后续一些突然扩大的运营功能需要通过发布来解决；也可以避免基于对发展需求的不了解而做出不必要的冗余设计去猜测未来的需求。

最后，了解一些基本的技术知识，避免被骂成白痴，其实效果有限。毕竟程序员骂产品经理。大多数情况下，句型是:“这个白痴改成了需求”，而不是“这个白痴对技术一窍不通”。