| 这个作业属于哪个课程 | 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 进行评测，对于创建群聊、加入群聊、设置加群方式等东西都放到了后台，直接通过代码完成配置，目前在前台界面并没有展示出来。
a、登录
b、主界面加载
c、发送消息
d、接收消息
e、聊天
-
展示关键代码
在打代码过程中，我遇到的一个最大的问题是，如何获取到新消息 → 获取到的新消息如何解析 → 如何将获取到的新消息与群聊对应。对于这个问题，在文档当中并没有具体的能复制粘贴的例子。后面我通过阅读源代码得到了解决办法。以下展示这一消息处理过程。
a、注册监听器
（使用 EventBus 通知聊天界面更新）
b、接收新消息
c、更新聊天界面
-
BUG1
描述： 这是使用文档的一个 BUG。在（文档中心 -- 即时通信 IM -- 常规集成（无 UI 库）-- 消息收发（Android）-- 接收消息 -- 消息解析 ）中，并没有给出如何判断接收到的新消息来源 id，仅给出了如何解析消息的内容，在开发者回溯消息来源时，造成了很大的困扰。
文档给出的例子
代码中的使用例子
我的看法：
应该站在开发者的角度去撰写文档，对于一些基本的调用过程，文档中应该详细地给出，或者在使用 Demo 中给出详细的注解说明。开发人员没发现的原因我认为是没有及时收取用户的反馈信息，对文档做出更新处理。
-
BUG2
描述： 群消息漫游问题（或许这个问题充钱升级可以解决）。当然，这个目前只能算是我的应用中的 BUG，但是源头出在 IM 这边。
文档中的描述
我的看法： 因为我的项目非常依赖 IM 的消息漫游功能，所以这个 BUG 非常的致命，但是 BGU 并不是 IM 产生的，而是我在需求分析时，没有考虑到这个问题，在后面测试的时候才意识到。不过这个应用就是在评测范畴里面的，这样也就无可厚非了。我们应该在评测当中发现更多的问题，选择最优的方式应用到真正的项目开发当中。
二、我想要利用 IM SDK 开发的产品
-
产品功能： 提供一个即时通信的问题讨论系统。具体包括：问题发布、问题讨论、问题整理、问题查看。
-
面向用户： 目前主要面向的用户是大学生（或者说就是身边的同学）。
-
用户场景举例：
① 对于大一的 C 语言初学者，我们可以在应用当中发布一些入门的程序，并且附上整理过的讨论过程，初学者可以在这些讨论过程当中获取教训，这样子可以尽量避免在一个分号、一个星号上 DEBUG 一整天，可以减少初学者对于编程的陌生感。通过一届又一届地整理，聊天记录会基本覆盖初学者在编写这些入门程序遇到的问题。
② 对于通过 QQ 群上网课的老师和学生（比如我们目前的密码学、编译原理、人机交互等课程），如果通过我们的应用进行，在当天的课程结束后，可以就地整理出知识点（移去多余的消息、修改已有的消息），从而得到有效的上课记录。
三、采访潜在用户
-
采访对象的背景和需求：
所采访的对象是我们的陈同学，和我们拥有同样的课程，包括 C 语言、密码学、编译原理、人机交互（这些课程里面有我们的用户场景）。陈同学渴望能拥有一份整理好的老师在 QQ 群中的上课记录，以便对课程有更深刻的理解。因为目前 QQ 群中的聊天记录夹杂着很多没有用的消息，这个愿望是奢侈的。
-
采访对象使用 Demo 图片：
-
采访过程（语音形式）：
-
用户使用腾讯即时通信 Demo 体验：
使用 Demo 后，陈同学认为，腾讯的即时通信 Demo 没有解决他的需求。并且发表了自己的看法：腾讯的 SDK 做得非常好，但是如果要解决需求，需要做较大的改动。
-
用户对 SDK 的意见：
SDK 的开发文档做得不是很友好，存在很多困扰开发者的地方。对于实现小功能的场景，这个 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 核 8G*2
后端服务器配置：8 核*16G*3
关系型数据库：MySQL（读 1、写 1、备份 1）
缓冲数据库：Redis（主 1、备 1）
网站安全性：WAF、DDOS（上面的设备主要使用云服务器）在用户增加时，可以进行扩容。