App产品原型背后要交代的细节或要理解的原则（五）
本文接上一篇「App产品原型背后要交代的细节或要理解的原则（四）」。
18、「聊天」发表情，是怎样的机制
在微信发一个表情出来，你发现显示的是名称[调皮]，而不是一个图标。
收到表情的一方，退出到聊天信息总列表，显示的也是[调皮]。
那么为什么不是直接放一个表情在上面呢？实际这与实现原理有关系。
当发表情给对方的时候，实际上发的是这个表情对应的ID——>服务器拿到这个ID之后，再传给接收方的客户端——>接收方收到，再解码出一个表情，展示在客户端。
用图示如下：
因此，表情的发送，是发送给服务一个对应ID，而不是发送 表情文件 给对方的。
所以表情文件（图文件）需要存在客户端，而不需存在服务器。此外客户端还要存表情名称和ID。
事实上客户端需要以josn格式存储表情图-名称-表情ID，如下图这样：
注意，App正式运营阶段，需要自己制作表情，避免盗用侵权。
19、「输入框」的约束这件小事
从约束的程度看，输入框可以分两类，一类相对开放，比如作品评论框、好友留言框；另一类相对约束，比如昵称、个性签名、标签。
这两类之所以约束程度不同，主要是跟用户心理诉求以及页面的展示形式决定的。
比如个性签名一般会展示在个人资料页，不管是自己看，还是他人看，都要求美观，比如居中对齐。同时页面空间有限，所以字数需加以限制。
那么对于这类输入框，要做的是：限制字数、对齐方式、内容校验、文案提示等。
举一个个性签名输入框约束方案的例子：
（1）限制字数：字数上限尽量高，不让用户心理上感到被束缚（好比商城大厅都很高，尽管“摸着天杜千”这样的用户很少），比如40-50字。字数上限可以在右下方显示，随着输入而扣减字数；
（2）字数校验：推荐在输入的时候， 截取 到限定字数，多余的不予录入。无需语言提示，用户都看得懂；
（3）文案提示：根据（1），由于已经有显示位数了，所以可以换个提示，比如“据说签名会提升关注几率哦”；如果签名为空，为了提高体验，则建议对他人展示一个固定值，比如“欢迎关注我”；
（4）对齐方式：展示的时候，建议居中，最多显示两行，多出的省略。
在编辑环境自己看的时候，如果是下图这种样式，可以规定：满行则靠左侧对齐，不满行靠右对齐。
20、你的App用到过「音效」吗
以App「SOUL」的匹配按钮为例，匹配中有音效，匹配成功，也会有个音效。
那么音效的实现是怎么的机制呢？是不是在后台配置音频文件，通过点击按钮调用呢？
实际上一般不需要在后台存储音频文件。
一来是因为音效变动不大，比如QQ的加好友的咳嗽声用了那么多年。所以在客户端写死并不影响实际需要。
二来牵扯到触发后，对交互的时效性要求较高。对比前面提到的表情，音频文件会大很多。
以「SOUL」为例，本来已经匹配到用户了，如果因为网速等导致了延迟，迟迟没有发出匹配成功的声音，那就尴尬了。
21、分页加载，还是一次加载全部
考虑是否需要分页的时候，基本有三个特征：
- 数据需要从服务器拉取；
- 拉取的数据容量不太小；
- 拉取内容的条数不太小。
客户端是一次加载完，还是分页加，分别需要服务器提供分页或全部数据的吞吐机制。
那么采取两种措施的优劣如何呢？
从用户角度，并不能一棍子打死说全部加载就省事。
因为全部加载浪费用户流量和加载时间。很可能后面的内容是用户不需要的。这时候加载那么多反而适得其反。
但是分页加载的缺点就是增加用户操作的次数。用户看完一页需要再次加载才能看更多内容，影响用户沉浸性体验。
目前整体来说，采用分页加载的较多。根据用户的适应性，每一页给予的内容数量加以调整。比如抖音的分页瀑布流。
作为产品经理，在确认列表页（比如好友通讯录）、信息流（比如好友动态）的时候，首先要在PRD中明确是否分页加载。
若分页，则确定每页加载的大致条数。最重要的是需考虑清楚，支持分页或不分页的原因。
#相关阅读
作者：唧唧歪歪PM；公众号：唧唧歪歪PM（ID：jjyypm）
本文由 @唧唧歪歪PM 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议
作者暂无likerid, 赞赏暂由本网站代持，当作者有likerid后会全部转账给作者（我们会尽力而为）。Tips: Until now, everytime you want to store your article, we will help you store it in Filecoin network. In the future, you can store it in Filecoin network using your own filecoin.
Support author:
Author's Filecoin address:
Or you can use Likecoin to support author: