这本来应该是个基于markdown的聊天软件，奈何最后被我搞蹦了，其实markdown不论便捷还是显示效果都还可以，只是这次真的翻车了。。

现在版本换成了没有markdown，没有后台接收消息的版本。。

但是还是来介绍一下我这几天的心血吧。。

对于每一个操作真的非常用心了，花了非常多的时间在**细节处理**上，想把用户体验提高。

因为我太过于展示两个activity之间的过渡，ui写的有点乱，操作感觉是有点不清晰，先说一下最基本的操作。

• 如何添加好友

  聊天界面右上角查找用户或发起群聊，点击item进入对话，点item左侧的头像就可以添加好友了，当然也可以在聊天对话中点击好友的头像添加好友。

• 如何删除好友或聊天记录

  当然是item左滑删除，分组长按删除。（没有任何提示，感觉不会有人知道可以有这个操作O__O "…）

• 可以录音，可以传多张照片，拍摄照片或视频
• 有未读消息，进入对话中清除
• 在和A对话时不提示A发来的消息通知，在和B对话时toast提示A的通知
• 设置有自己的缓存策略，加载数据的时候减少了很多流量开销
• 每条消息有时间，根据不同时间间隔显示不同提示，如今天，一分钟前，星期几。
• 如果聊天记录很多的话，顶部会有“点击加载更多”的按钮出现，如果聊天记录不多则会自动隐藏。
• 如果两个对话消息时间间隔超过3分钟，则在对话中显示时间。否则视为持续聊天，不显示时间

这是聊天的gif演示

• 可以群聊

  群聊时显示其他人的昵称，隐藏自己的昵称，大大节省屏幕空间，群聊可以使用以上所有功能

• 还有好多好多，一下子我也不能全部想起。。

所有activity跳转采用共享元素动画过度，本来是想自己撸更多动画的，结果时间没有这么多

这个想法来源于两张官方的GIF演示，用官方的话来讲，这是张会不断变换大小的魔法纸片

我觉得谷歌的意思应该是想把ui基于一张圆润方正的CardView来做界面，于是我在这次考核中全程使用CardView，变换又代表着transition动画，所以我在处理页面跳转逻辑时全部是从一个cardView共享元素跳转到另一个activity的cardview，这样一来，所有的用户操作看起来就像是在将纸片进行缩放，同时动画改变纸片内容。

于是我这次考核的ui写成了这样子

我也不知道这样好不好看，我觉得还行吧，效果虽然达不到我的预期，实力有限，但是还是有点想要的感觉

因为目前几乎所有app都还是以前那样的fade,explode，这些常见且没有特色的跳转，让我觉得完全不符合谷歌所展示的魔法纸片的效果。于是这次考核我决定自己来写这么一个基于魔法纸片的app。于是最开始我把包名定做MagicCard，后来为了特色和符合考核主题，换成了MarkChat。

当然，也因为这样的ui，让交互逻辑变得有点迷。。以后可以好好改进一下

• 消息发送机制

  一条消息要如何发送很简单，但是要如何发送了之后显示在屏幕上就需要思考了

  如果说发送了一条消息，在服务器上拉取该对话中最近的10条消息显示在对话列表里，那么就不太好。

  首先是因为这样会有比较大的延迟，拉取10条消息，还要重新加载用户头像图片，肯定会耗费不少时间，其次这样子我发现流量开支比较大，这样拉消息一次大概会耗费100k左右流量，看起来不怎么多，但实际上一次聊天怎么也要发几条消息吧？那一次聊天就有1m流量消耗，这肯定有问题。

  解决方案

  如果是发送消息，那么不从服务器上拉取消息。我选择了在本地创建一个消息对象，添加到对话列表中刷新，这样子就只有发送的流量开销，几乎没有延迟感了。

• 消息接收机制

  消息接收很简单，但是要考虑的东西也有很多

  首先消息有不同的分类

  这次考核中有文字，语音，照片，视频这4中消息类型，左边4种，右边4种就有8种，算上两个人对话和群聊的话，就有8x2=16种。于是如何复用item和adapter就需要花时间思考了。当然这只是对程序员有帮助，用户也看不见这里面的辛苦。

  那么这16种消息类型，文字简单就不说了。

  语音需要显示时间长度，而且要保证语音播放流畅度，这里我先下载后播放（一条语音大概200k，下载很快）。然后需要考虑如果用户在播放一条语音的同时，如果想要暂停怎么办，这里我选择再点击语音消息结束播放。再然后，如果在播放上一条语音的同时再播放下一条语音，需要暂停上一条再播放下一条。

  照片需要考虑压缩到合适的分辨率显示，需要点击可以看大图，并且可以缩放，这里我使用了glide和photoview

  视频必须要能在线播放，而且必须控制发送视频的大小。leancloud上传速度比较慢，经测试如果发送视频比较大会上传很久。

  所以我在发送视频的时候压缩的特别厉害，一段10秒的视频大概只有1m左右大小，很模糊，考核完之后会恢复高画质。

  群聊和普通聊天肯定也不会一样的，群聊需要显示好友的头像和昵称，二两个人之间的对话是不需要显示昵称的，这个逻辑我是参考了ios版QQ。

  ​

  和消息发送一样，消息接收也需要减少流量开支。接收到的消息直接组装成对象放在列表里，不要去获取消息记录，这样体验会好很多。

• 理清消息逻辑

  消息的种类一多，消息逻辑就会特别混乱，这个时候就需要封装。。刚开始两天做的时候就打算先试试，没封装，结果思路特别乱，后来封装了一下思路清晰了很多。但是消息种类多了还是会特别难理思路。最后一天的时间我做了MarkDown编辑器（之前写过，所以有把握一天搞定），效果什么的都感觉很不错，结果晚上的时候在催着交了，有点慌了，逻辑就很随便了，到处复制粘贴，弄出来可以发了，以为可以了。结果最后检查的时候出了消息发送的bug，时间只有一个小时了，我赶快修bug。。结果逻辑很乱，加上比较慌，硬是没有修复好bug，最后交了前一天写的软件。。很多东西都没搞好的那个版本。。

• 要学会怀疑服务器

  绝大部分的错误逻辑都是自己造成的，但是这种情况下，和服务器交互的比较多的情况，就需要检查服务器端问题了。一直以为云服务器不会有任何问题的，结果这次发现还是有很多报错是由于服务器造成的。比如说历史消息查询，服务器有时候会卡，消息很久收不到，我之前就去检查代码了，改了很久没有修复，还把其它正确的代码改乱了，过一会儿手机上直接显示了消息。。这就很得不偿失。

  因此遇到错误要冷静，慢慢思考错误的原因，理清楚思路，同时也要怀疑一下是不是硬件方面的问题