2016年半年工作总结
完成方客App IM聊天功能迁移，新增投资人简约界面，重写网络层，数据层，模型层。
统一代码风格，集成tagret逐渐整理整个工程的代码结构和网络层设计和数据缓存。
App瘦身，降低App整体体积，大概5M左右。
替换云信提供的UI框架，使用runtime获取云信不暴露给我们的对象的属性列表，不必采用继承或者持有的方式扩展属性字段，踩了云信SDK一些坑，后边一一讲述。
解决了iOS10更新后的适配问题和一些刚升级后开发人员都面临的奇葩问题。
提倡界面复用，避免耽误时间在基础的UI搭建工作上，更加专注于业务逻辑。
对于团队管理有了更深的了解，以及团队技术沉淀，发挥团队人员主观能动性，以及一些开发中常见问题的探讨和总结。
方客App 下载地址：https://itunes.apple.com/cn/app/fang-ke/id967525174?mt=8
－：云信IM迁移
从项目7月1日立项，到迁移成功，上线到AppStore8月18日，整整一个半月。其中遇到了一些问题。
下边主要讲讲云信集成中遇到的坑。也算是为本团队贡献的技术文档。
#1.云信SDK 推送不稳定问题。
在项目开始之初，每天早晨都可以收到推送，一到中午过后，便收不到推送，经过一系列的包括 推送证书下载，生成，替换都无济于事。
过了半个月后，基本稳定，不再出现推送收不到或者延时的问题。相信云信在推送这方面做了一定的优化。
#2.建群隐性bug.如果不是怀疑加猜测，相信很难找到问题的所在。
- (NSArray *)ignoreTeamNotificationTypes; //需要忽略的群通知类型
假设在集成之初，我需要忽略很多类型，那么需要在SDK 初始化时候设置忽略类型。
类似如下：
/* * 群通知内容*/
@interface NIMTeamNotificationContent : NIMNotificationContent
/**
* 操作发起者ID
*/
@property (nullable,nonatomic,copy,readonly) NSString *sourceID;
/**
* 操作类型
*/
@property (nonatomic,assign,readonly) NIMTeamOperationType operationType;
我们可以看到群操作类型中，有以下几种枚举。
/** 群操作类 */
typedef NS_ENUM(NSInteger, NIMTeamOperationType){
/**
* 邀请成员
*/
NIMTeamOperationTypeInvite = 0,
/**
* 移除成员
*/
NIMTeamOperationTypeKick = 1,
/**
* 离开群
*/
NIMTeamOperationTypeLeave = 2,
/**
* 更新群信息
*/
NIMTeamOperationTypeUpdate = 3,
/**
* 解散群
*/
NIMTeamOperationTypeDismiss = 4,
｝
[[NSUserDefaults standardUserDefaults] setObject:@"1,2" forKey:@"ignore_team_types"];
[[NSUserDefaults standardUserDefaults] synchronize];
假设此时我设置忽略类型包涵 NIMTeamOperationTypeInvite 邀请成员，那么你会发现建群无论如何是不会成功的。因为没有消息生成在当前成功的session中，本地数据库也无法保存这个群。
#3.替换云信自定义导航控制器的pop,push 动画。
解决了客户在使用语音过程中，不小心拇指触碰到屏幕，导致的自动返回上一层级问题。
#4:删除所有云信IM 底层使用runtime 方式添加的导航头视图和头文字。
这点需要尤其吐槽一下，作为一个商用项目，使用runtime方式集成在框架中，对于设计感十足，特异性很强的App设计团队而言，十分不友好。反馈过很多次，但似乎好像没有愿意修改的意向，鉴于我们的UI设计基本很多个界面都不是统一的，这种统一的做法，其实相反并不利于提高我们团队的开发效率。
#5:开发中，无法在同一个对象中获取他们本身含有，却未暴露给我们的属性列表或者方法，或者本可以在界面传值或者显示名称的时候，却无法在同一个对象中添加属性，达到一个对象即包涵我需要的讯息的功能。
最初的解决方案是： 新建一个对象，使该对象持有信息SDK中的对象，在此基础上添加传递需要的属性。便于统一管理，方便赋值。
最终决定使用Object-C这门动态语言的特性，使用runtime获取所有可读写或者只读，只暴露在.m中，未公开的属性。这也为最终开发聊天功能中的收藏节约了时间成本。
#6：云信添加好友，中会出现重复添加好友的问题。鉴于我们需求团队采用的逻辑是：
当前用户收到添加好友请求，在会话列表中需要置顶一栏会话，专门提示用户处理此时此刻的用户请求。那么此时需要处理一下两个问题：
1:经过查看请求好友属于系统通知消息，而且对于相同用户多次添加当前用户，产生的SystemNotificaiton不相同。那么只有在根源上杜绝用户多次添加当前用户的可能。
2:这些系统消息展示在会话列表中，要计算在当前tabBarItem 显示的消息个数，当前通知消息必然也要归于其中。刷新和计算角标不可避免。
如何解决这两个问题，并且达到少出bug的情况呢，需要好好分析一下。云信IM的系统消息
IM系统消息类型有以下几种：
/**
* 系统通知类型
*/
typedef NS_ENUM(NSInteger, NIMSystemNotificationType){
/**
* 申请入群
*/
NIMSystemNotificationTypeTeamApply = 0,
/**
* 拒绝入群
*/
NIMSystemNotificationTypeTeamApplyReject = 1,
/**
* 邀请入群
*/
NIMSystemNotificationTypeTeamInvite = 2,
/**
* 拒绝入群邀请
*/
NIMSystemNotificationTypeTeamIviteReject = 3,
/**
* 添加好友
*/
NIMSystemNotificationTypeFriendAdd = 5,
};
鉴于我们App采用的是不能申请入群等业务逻辑，我们采用了，只过滤添加好友系统通知的系统消息。对于同一个用户请求添加我为好友，采用本地数据库存储，一旦请求添加过我为好友。
再次请求添加为好友，如果我没有同意或者拒绝，将不能再次添加为好友，我们会弹出您的请求正在处理，请勿重复添加！如果已经是好友，又将我删除好友，采用了微信的做法，即不必通过验证请求，即是好友。当用户接收到对方已经添加您为好友的请求之后，将该条消息置为已读。当用户选择拒绝添加好友或者同意的时候也将消息置为已读。这样逻辑上便不会又问题。当用户置空系统通知列表时，对于未处理的好友请求，采用全部置为拒绝添加为好友的处理方式。当对方收到拒绝添加好友的请求时，需要删除本地数据库，否则用户无法再次尝试去添加我为好友。
#7: 消息收藏功能的实现。
采用云信SDK获取sessionid messageid然后转化为对应的自定义消息等。
内部的所有信息，都是根据sessionid 和 messageid 获取整个消息的所有信息。然后展示，大大减少了工作量，起到了复用云信功能的作用。当然，UI永远都是最廉价的，所以就没有复用云信的，况且结构也不一样，强行gank是很容易出问题的。
<2>统一代码风格，集成tagret逐渐整理整个工程的代码结构和网络层设计和数据缓存
先看一下最初拿到这个项目的时候的基础模块是怎样的。
今天就拿一个最简单的项目详情界面分析，一个App的代码是怎么样被破坏殆尽的。
这样一个界面代码量达到了860行。300行或者更少的情况下就可以做到了。那么，看看究竟做了什么让整个控制器如此臃肿不堪。
效果如下：
- 经过统计： cellForRow中100行，网络请求＋ 数据容错性非空判断处理＋ 转化为Model 450行。代理方法 200行。
- 我们可以看到，要想精简代码，需要在cell赋值和处理数据上下功夫。那么怎么处理呢？
处理方法如下：
1.精简网络请求
2:cell赋值统一化
精简之后将近400行，不仅仅是代码少了，更重要的是 调理清晰，开发团队的人员看到这样的代码会很喜欢。整洁，有条理。统一数据处理，统一赋值。
最终在紧张的三个月的需求迭代中，改成了如下的模式：
另外为了提高编译速度，将很多之前就使用在工程的预编译宏都删除，重新使用常量字符串代替。
替换之后的效果展示：
最初，像这样的宏定义多达1000多个，每次更改一个宏，都需要重新编译很长时间。最终无法忍受这种情况的一直持续下去，着手开始了第三方库的精简，宏定义的删除，文件资源文件的删除等一系列的操作。之前的参与编译文件为1300多个，目前参与编译个数位980多个。代码的编译速度确实提升了。另外App的体积也有所减小。
另外整个Images.xcassets 文件进行了统一整理。每个模块的图片放在每个模块之下，便于查找，删除，替换。节省开发成本，减少因为图片管理不善，导致App体积增大问题。
忽然发现有一个首字母竟然没有大写。
解决了iOS10更新后的适配问题和一些刚升级后开发人员都面临的奇葩问题
- 1:所有在awakeFromNib中进行的layer 圆角，阴影渲染，通过self.imageView.height或者width获取的高度进行的效果渲染都将无法实现效果，同时会出现一个问题，整个列表都将被一层类似白色的遮罩所覆盖，仅当滚动视图的时候，列表中显示的cell才不会被遮盖。
原因：iOS 10 之后，cell的加载都使用了懒加载的方式。在最初初始化的时候是无法获取长宽的。
- 2: 在其中2.0.3版本中，在适配iOS10中，发现一个问题，整个加载出来的视图竟然都无法点击。我们的App采用了类似五个TabBarItem的设计方式，由于在iOS10上frame的计算是有偏移的，导致整个界面都无法点击。失去与用户交互的活性。
解决方案：
为了及时上线，采用了万能的解决方案，layoutSubViews.解决了该问题。强制重新计算高度和宽度，达到解决该问题。
- 3:复杂界面的重构：
对于复杂界面，动辄需要1500行的代码，是必须进行代码重构的。类似下列的详情结构：
- 1: 最下边还有一个横向滚动的视图没有截取，可以想象，这个界面的每最后的五个都是不确定的。
而且高度也是不确定的。都是需要根据数据去动态计算的。同时还有展开和缩放功能，还包括一些按钮也没有展示出来，上拉展示下一个项目等等总而言之，复杂度是很高的。 - 2: 这个时候才用tableView 去做，明显是不合理的。我们需要做很多cell的判断和高度的判断。还有cell个数的判断。最终导致代码冗长，且逻辑不清。不便于以后添加一个新的需求和删除一个需求。那么最好的方式就是用XIB 快速搭建。然后就是数据判断，显示UI的问题了。有兴趣的可以下载下来看看具体复杂程度。
- 3: 每个View的高度都依赖于内部View的高度，需要动态计算。
提倡团队开发使用XIB，速度应该比纯代码速度快。而且有句话说得好，越少的代码，越少的bug。其实所有的目的，只有一个，整洁的目的是： 规范，好维护。
功能尽量组件化
1:比如一下用户定位信息，需要获取用户当前地理位置，然后转化火星坐标，归为NIMSDK 高德能够识别的经纬度坐标。单独写了一个管理类来统一处理所有定位问题。
-
2:相信大家对选择标签这种控件真的是再熟悉不过了。如果你的工程中有四处到五处都在使用这个，那么真的很有必要进行组件化处理。经过组件化处理。大概即使稍微复杂的功能，也可以控制在300行以内。
Snip20161025_1.png
下边展示一下效果：
未来半年的展望
1:这半年其实写的东西也不多，主要因为太忙，要么就是太累，不想去写这些东西。趁着开发缓冲阶段，捋一下今年这半年我都干了什么。要考虑的东西其实还是很多的，未雨绸缪，想别人所不想想，做别人之不想做。业务和技术是不分家的，技术牛逼，看的很多，结合不到具体的业务逻辑，也是白瞎，或者强行结合，也是不行。要懂得什么才是最合适的。
2:逼逼叨叨了这么多，回想一下，刚进入这家公司，实现的目标也基本达成了。包括代码风格，整洁度，结构是否合理啊，都有了很明显的进步。能够把一个项目，从差到优一步一个脚印的做下去，不逼逼，我觉得这才是一个程序员真正的的价值。
另外附上所有的git commit 记录：
