What

1. 开发者需要自己实现聊天界面
2. 开发者需要接入消息云安全认证
3. 开发者需要自己定义消息体格式

Why

1. 为什么不提供聊天界面
  1. 我们不提供统一的聊天UI，基于以下理由：
  2.     1. APP都有自己的风格，万紫千红才是春，一套UI显然不能满足大家需求
  3.     2. UI对于开发者而言，开发成本并不高
  4.     3. 开发者自行开发UI，可100%自定义界面和功能
  5. 所以，我们认为由开发者根据自己APP的风格来自定义UI比较合适
2. 为什么需要开发者自定义消息格式
  1. 我们不提供统一的消息格式，而由开发者自定义消息格式，基于以下理由：
  2.     1. APP所需消息功能各异
  3.        有的需要已读，有的则不需要已读功能，所以我们提供了推荐的消息格式，
  4.        由开发者根据自己情况定义最适合自己的消息格式
  5.     2. MIMC(小米即时消息云)应用场景广泛
  6.        IM聊天只是MIMC的一个特殊使用场景，还存在IoT信令传递等各种消息传递场景
  7. 所以，我们认为由开发者根据自己APP的实际需求，参考我们推荐的消息格式，来定义消息体格式比较合适
3. 为什么开发者不需要维护帐号映射
  1. MIMC用户登录/消息收发等都使用APP帐号系统里的账号ID，MIMC帐号体系对APP开发者透明！
  3. APP开发者接入其他IM提供商时，要访问IM提供商服务，主动为每一个appAccount注册一个新的ID，
  4. 开发者还需要在自己的后台系统储存以下信息：
  5.     1. appAccount --> IM提供商系统内ID
  6.     2. IM提供商系统内ID + IM提供商系统内登录密码(明文)
  7. 这样做有以下弊端：
  8.     1. 开发者维护帐号映射成本高，一旦出错难以修正
  9.     2. 明文存储登录密码，安全性极差，开发者承担极高的安全风险
  11. 所以，MIMC(小米即时消息云)没有采取以上方案，MIMC自维护帐号映射，保证MIMC ID对开发者透明
  12. 这不仅降低了开发者负担，增强了帐号安全性，还能让开发者感觉MIMC就是"自己的"消息系统
举例说明：
  1.     假设开发者拥有某APP叫"言士文学"，集成了MIMC(小米即时消息云)服务
  2.     假设"言士文学"在小米开放平台注册的appId为"580012345678"
  3.     某用户A登录"言士文学"所用帐号名为手机号"13800000001"
  4.     某用户B登录"言士文学"所用帐号名为手机号"13800000002"
  6.     当用户A首次登录"言士文学":
  7.         userA = new User("580012345678", "13800000001");
  8.         userA.login();
  9.     MIMC后台服务会为A创建MIMC ID("8049600000000001")，并维护以下映射：
  10.             "580012345678" + "13800000001" --> "8049600000000001"
  12.     然后，用户A给用户B发消息:
  13.         userA.sendMessage("13800000002", "Hello B");
  14.         由于B还未登录过"言士文学"，所以MIMC会自动为B创建创建MIMC ID("8049600000000002")
  15.     并维护以下映射：
  16.             "580012345678" + "13800000002" --> "8049600000000002"
  17.     并将消息"Hello B"暂存在服务器(七天后过期)
  19.     用户B登录"言士文学"时：
  20.         userB = new User("580012345678", "13800000002");
  21.         userB.login();
  22.         因为B在MIMC已经有了ID，所以MIMC后台服务不会再为其分配新ID
  23.         MIMC后台服务检测到B登录，下发离线消息"Hello B"给B