IM SDK 评测

这个作业属于哪个课程	https://edu.cnblogs.com/campus/fzu/2020SpringW
这个作业要求在哪里	https://edu.cnblogs.com/campus/fzu/2020SpringW/homework/10625
这个作业的目标	对腾讯的 即时通信 SDK IM 进行评测
作业正文	https://www.cnblogs.com/aahorse/p/12706898.html
其他参考文献	《构建之法》、IM 开发文档、IM Demo

一、IM SDK 评测

本次作业通过构建一个 Android 轻应用，完成腾讯即时通信 IM 的 SDK 评测。
项目地址：https://github.com/aaHorse/KotlinForAndroid/tree/master/instantmessaging
APK 下载：https://github.com/aaHorse/KotlinForAndroid/blob/master/instantmessaging/instantmessaging-release.apk

• 应用的功能描述
  这个应用的功能是提供一个即时通信的问题讨论系统。

  
  

  应用场景如下： ① 讨论的问题需要记录和整理，② 讨论的问题过程需要复用，③ 存在很多需要讨论的问题。

  
  

  解决用户痛点： QQ、微信等聊天通信工具生成的聊天记录仅有时间线并且无法就地整理，亟需一个相对专业的应用来完成问题讨论和讨论结果整理。

  
  

  a、登录界面

  
  
  

  b、主界面

  
  
  

  c、聊天界面

  
  
  

  d、聊天记录

  
  
  

• 设计实现
  以活动图的形式展示设计实现过程。注意：考虑到首要目标是对这一个 SDK 进行评测，对于创建群聊、加入群聊、设置加群方式等东西都放到了后台，直接通过代码完成配置，目前在前台界面并没有展示出来。

  
  

  登录

  
  
  

  主界面加载

  
  
  

  发送消息

  
  
  

  接收消息

  
  
  

  聊天

  
  
  

• 展示关键代码
  在打代码过程中，我遇到的一个最大的问题是，如何获取到新消息 → 获取到的新消息如何解析 → 如何将获取到的新消息与群聊对应。对于这个问题，在文档当中并没有具体的能复制粘贴的例子。后面我通过阅读源代码得到了解决办法。以下展示这一信息处理过程。

  
  

  注册监听器
  （使用 EventBus 通知聊天界面更新）

  
  
  

  接收新消息

  
  
  

  更新聊天界面

  
  
  

• BUG1
  描述： 这是使用文档的一个 BUG。在（文档中心 -- 即时通信 IM -- 常规集成（无 UI 库）-- 消息收发（Android）-- 接收消息 -- 消息解析 ）中，并没有给出如何判断接收到的新消息来源 id，仅给出了获取发送者的昵称，在开发者回溯消息来源时，造成了很大的困扰。

  
  

  文档给出的例子

  
  
  

  代码中的使用例子

  
  
  

  我的看法：
  应该站在开发者的角度去撰写文档，对于一些基本的调用过程，文档中应该详细地给出，或者在使用 Demo 中给出详细的注解说明。开发人员没发现的原因我认为是没有及时收取用户的反馈信息，对文档做出更新处理。

  
  

• BUG2
  描述： 群消息漫游问题（或许这个问题充钱升级可以解决）。当然，这个目前只能算是我的应用中的 BUG，但是源头出在 IM 这边。

  
  

  文档中的描述

  
  
  

  我的看法： 这个 BGU 并不是 IM 产生的，而是我在需求分析时，没有考虑到这个问题，在后面测试的时候才意识到。不过这个应用就是在评测范畴里面的，这样也就无可厚非了。我们应该在评测当中发现更多的问题，选择最优的方式应用到真正的项目开发当中。

  
  

二、我想要利用 IM SDK 开发的产品

• 产品功能： 提供一个即时通信的问题讨论系统。具体包括：问题发布、问题讨论、问题整理、问题查看。

• 面向用户： 目前主要面向的用户是大学生（或者说就是身边的同学）。

• 用户场景举例：

  ① 对于大一的 C 语言初学者，我们可以在应用当中发布一些入门的程序，并且附上整理过的讨论过程，这样子可以尽量避免初学者在一个分号、一个星号上 DEBUG 一整天，可以减少初学者对于编程的陌生感。

  ② 对于通过 QQ 群信息上网课的老师和学生（比如我们目前的密码学、编译原理、人机交互等课程），可以通过我们的应用进行，在当天的课程结束后，可以就地整理出知识点（移去多余的信息、修改已有的信息），从而得到有效的上课记录。

  
  

三、采访潜在用户

• 采访对象的背景和需求：

  所采访的对象是我们的黄同学，和我们拥有同样的课程，包括 C 语言、密码学、编译原理、人机交互（这些课程里面有我们的用户场景）。黄同学渴望能拥有一份整理好的老师在 QQ 群中的上课记录，以便对课程有更深刻的理解。因为目前 QQ 群中的聊天记录夹杂着很多没有用的信息，这个愿望是奢侈的。

  
  

• 采访对象使用 Demo 图片：

  
  
  

• 用户使用腾讯即时通信 Demo 体验：

  根据用户的反馈，黄同学认为，腾讯的即时通信 Demo 没有解决他的需求。并且发表了自己的看法：尽管腾讯的界面和信息处理会做得更好，但是太偏生活化了。

  
  

• 用户对 SDK 的意见：

  
  

• 用户对我开发的产品的意见：

  
  

• 结论：
  推荐

  
  

四、分析 SDK

• 时间规划：

  SDK 大概功能结构图

  
  （因为消息涉及到文本、图片、位置、语音、视频等。关系链涉及到加好友、删好友、拉黑名单等等。系统看似简单，实际上非常的复杂。）
  

  前提条件有： ① 只考虑 Android 的 SDK；② 团队为计算机系大学毕业生 6 人；③ 按照国家规定的每天 8 小时一星期工作 5 天工作制；④6 人不会离职。

  需求分析阶段： 用户和用户关系链模块 5 个工作日、消息模块 5 个工作日、群模块 5 个工作日、其他 10 个工作日

  原型设计：（开发的是 SDK，这个可以忽略）

  系统结构设计： 15 个工作日

  数据库设计： 5 个工作日

  开发： 20 到 40 个工作日

  测试： 同步进行

  
  

• 同类产品对比优劣：

  目前来说对于我们小用户的需求，各平台都能满足，我们做对比时可以侧重其他的方面。

  ① 对于网易云通信，有专业运维团队 24 小时技术服务，有技术论坛，遇到问题可以快速的定位和解决。对于腾讯云通信，只能提供工单来寻求帮助。

  ② 网易云通信的计费比较透明，且可选多种计费模式，腾讯云通信存在很多隐形计费，前期无法估计用户量的时候很难预估成本。

  ③ 较之 SDK 的稳定性方面，网易云通信使用两年的过程中基本未出现消息丢失等问题，腾讯云通信之前的 SDK 出现过，并且网易云通信的回调接口丰富，问题对应信息比较全面，方便对应。

  ④ 网易云通信 SDK 提供了 GitHub 发布仓库，此仓库包含 IM 和音视频功能。并提供了开源的聊天 UI 组件 , 通过简单的配置就可以实现聊天功能。

  （比较到这里，网易云通信在基本需求层次完胜！！！）

• 团队软件工程方面建议：

  腾讯是以聊天业务发展起来的，在聊天领域应当有当仁不让的霸气，但是看了网上的相关分析，腾讯在这方面做得并不好。建议腾讯各项目的带头人，不要在互联网大发展的浪潮中失去了初心，在团队当中做好榜样，把守好软件的质量关，推出更多更有价值的产品。

  
  

五、规划自己的产品

• 如果你是产品经历，如何让应用具有竞争性？

  作为小开发者或者说小团队，我们是很难和大企业的专业团队在正面交锋胜出的。所以，如果我是产品经理，我会带领我的团队在在某一个小领域耕耘，开发出更具有针对性的专业应用。

  这次我选择开发的问题讨论系统，服务于有问题讨论需求的大学生群体，提供具有针对性的解决方案，避开了 QQ 等通信工具的锋芒，从而具有了与 QQ 在问题讨论整理领域的竞争力。

• 同类产品分析

  QQ，我们熟知的即时通信聊天工具。经过多年的运营，拥有大量的用户使用数据，目前的版本号为 V 8.3.0.4480 。通过版本号，我们就可以知道，经过多年上百次的迭代更新，在即时通信领域，QQ 基本立于不败之地（当然微信也立于不败之地，它们的粘性用户不同）。因为 QQ 要兼顾的用户群体多，在功能上已经很难有太大的改动，所以，我们开发的产品有信心在特定的领域与其竞争，吸引到用户。

  
  

• NABCD 分析

  
  

  N： 用户需求分析

  用户需要一个可以简单快速发布问题的平台。

  用户需要一个可以讨论问题的即时聊天平台。

  用户需要一个可以对聊天信息进行编辑的平台。

  用户需要一个可以查看问题和历史聊天信息的平台。

  
  

  A： 我们的独特招数

  对于简单快速发布问题，我们可以提供一个发布问题的编辑器，类似于富文本编辑器，在发布问题后，我们可以对问题内容进行展示。

  对于即时聊天，我们可以提供和 QQ、微信等大致相同的聊天功能。

  对于编辑聊天信息，我们可以深度定制，在消息时间线没有改变的情况下，对信息作出修改，让聊天记录发挥充分的作用。

  对于查看问题和历史信息，我们可以结合自己的服务器，保证每一条信息都被完整的保留。

  
  

  B： 我们带来的好处

  更专业，QQ、微信等更注重即时聊天，我们注重聊天过程的整理，以便让聊天信息发挥更大的作用。

  更轻便，通过使用我们的应用，可以将聊天工具解耦，回归学习的本心。

  更灵活，我们的应用服务群体小，可以提供更多量身定制的功能。

  
  

  C： 我们的竞争对手

  QQ，每个人都非常熟悉的 QQ，我们的生活、学习、工作都会通过 QQ 传达信息。但是 QQ 侧重在即时聊天，我们会避开 QQ 的优势，在问题讨论领域发掘更多的功能，吸引更多的用户。

  百度，尽管可以通过百度来解决很多问题，但是百度的东西良莠不齐，在我们发布的特定问题下，我们有信息提供更权威的问题解答。

  
  

  D： 我们如何推广

  因为我们的目标用户之一就是身边的同学，我们可以很容易地获取到这些用户。在获取到这些用户后，我们会收集他们的使用反馈，及时调整应用的功能，留住和吸引更多的用户进来。

  我们也可以和老师们合作，收集更多他们的需求，实现这些需求之后，通过老师在课堂上推广给学生们使用。

  
  

• 你会如何领导团队，会有什么不一样？

  如果我来领导这个团队，我会追求做到两点：① 开发出来的产品具有质量保证；② 开发人员可以在开发过程中成长，学到更多的知识。

• 人员安排

  如果我是产品经理接到任务要求开发这一应用，我会首先建立团队，包括：2 个后端、2 名 Android、1 名测试文档撰写。

• 16 周开发计划

  第 1 周：需求分析
  第 2 周：原型设计
  第 3 周：工具评测
  第 4、5 周：系统设计
  第 6 周：数据库设计
  第 7 周：作为缓冲，可以进行团队修整、工作优化
  第 8 周：项目架构
  第 9、10、11、12 周：编码
  第 13 周：编码，大范围测试
  第 14 周：编码，测试版部署上线
  第 15 周：联系客户，修改、优化
  第 16 周：正式版发布，交付客户

• 部署

  考虑到前期应用的客户不多，所以初步计划使用设备如下：
  应用服务器配置：4 核 8G2
  后端服务器配置：8 核16G*3
  关系型数据库：MySQL（读 1、写 1、备份 1）
  缓冲数据库：Redis（主 1、备 1）
  网站安全性：WAF、DDOS

  （上面的设备主要使用云服务器）在用户剧增时，可以马上扩容。