关于JMessage SDK使用感受

很开心收到我们极小光的同学邀请参加极光征文活动，原文主要是以SDK开发为主题的文章，会略有不同。
最近在独立开发一款 iOS IM App，主要是为了熟悉 Swift3.0，踩下坑，然后过渡到 Swift。这里我使用的是 极光 JMessage 的SDK进行开发，说下使用 Swif
t 调用 JMessage SDK 方法遇到的一个坑：

在 JMessage 里面的 JMSGConversation 类里有两个方法：

/*!
 * @abstract 返回 conversation 列表（异步,已排序）
 *
 * @param handler 结果回调。正常返回时 resultObject 的类型为 NSArray，数组里成员的类型为 JMSGConversation
 *
 * @discussion 当前是返回所有的 conversation 列表，默认是已经排序。
 * 我们设计上充分考虑到性能问题，数据库无关联表查询，性能应该不会差。
 * 但考虑到潜在的性能问题可能，此接口还是异步返回
 */
+ (void)allConversations:(JMSGCompletionHandler)handler;

/*!
 * @abstract 返回 conversation 列表（异步,没有排序）
 *
 * @param handler 结果回调。正常返回时 resultObject 的类型为 NSArray，数组里成员的类型为 JMSGConversation
 *
 * @discussion 返回所有的 conversation 列表，返回是没有排序的列表。
 */
+ (void)allConversationsByDefault:(JMSGCompletionHandler)handler;

这两个方法从 OC 的命名规范角度的看并没有什么问题，问题是如果通过 Swift 来调用这两个方法时：

8B98BD59-1409-4813-A2D6-FD829EFCD75D.png

这两个方法名就会给系统转换成一样的，Swift 就无法识别你调用的到底是谁了：

BFE3A3AC-BB11-4B5A-B590-539A598B1E70.png

Swift 会将 OC 中方法处的 At 、 With 、 By 、 At 后面的内容转换成为方法的参数，像上面的那两个方法，前缀是一样的，参数都是 JMSGCompletionHandler，这个时候，通过 Swift 来调用该方法时就无法识别了。

那么如何来解决这类问题呢？没办法，只能通过混编来处理了：

72993DD8-BA51-496C-8475-D7DE217EC249.png

创建一个桥接器，然后通过实现一个 OC 的类来对上面两个方法进行重命名，然后通过该类实现的方法对上面两个方法进行调用，问题解决~~

问题虽然解决了，但也太折腾人了，我只想简单调用别人 SDK 的方法，结果还要搞个混编，重写方法名等等......这也太折腾人了，所以说在设计 SDK 方法名时需要考虑兼容 Swift，毕竟 Swift 是大势所向。

需要怎样使 OC 方法名兼容 Swift 调用，通过上面的内容大概也知道怎么去处理了，这里就不啰嗦。Swift 是大势所向了，有空还是多学习下。

关于JMessage SDK使用感受

首先，这里只指针 iOS SDK，我从事iOS开发，安卓并不熟悉太多，不讨论安卓。

1. 产品修复版本迭代过快，这里指的不是功能迭代，指的bug修复版本发出过快，导致部分中间版本是无法使用的，必须及时更新，但有时候苹果的上架并不是那么友好的，幸运的是苹果的审核的速度加快了，但这也是无形之中给开发者加大压力。从中也体现出，测试在整个开发过程中的重要性。只有稳定的产品，才能真正吸引开发者来使用。
2. 在使用JMessage iOS SDK的时候，我参考了JMessage 提供的jChat，怎么说呢，代码竟然可以这么烂，不说功能也不说性能，更不说UI，就看代码结构，就一堆代码，杂乱无章，一个最直接体现产品的东西，竟然可以做得这么烂，这个是否应该反思一下。这里也让我想起百度语音开发者平台，连注册都没有办法成功，社区很多人反馈，但问题却一直还在，我折腾了一个多小时，还是没有测试成功，这就注定了这个产品与我无缘了，不敢说一定不用，除非迫不得已的情况。。。这里就不贴jChat的代码结构了，毕竟还是推荐来参加征文的。

这里就先分享这一些使用感受，后面继续使用后发现更多时再更新，该文同时发布在我的简书，也欢迎关注，简书会同步更新。