主要负责“桩桩”app的开发和优化。桩桩是一款类似微信的企业IM应用，基础模块包括IM组件，通讯录，组织架构管理，权限管理器，公司管理器。在这些基础模块的基础上，我负责开发了考勤、任务、公告、审批等模块。

主要工作内容：

1.我负责开发了组织架构管理器。

作为一款移动办工IM应用，在提供类似微信通讯录的基础上，还需要提供组织架构管理功能。这个管理器主要为了解决公司组织架构的可视化问题以及在移动端管理组织架构的问题，方便同事之间的沟通和管理者进行管理。实现这一功能时碰到的主要问题时怎么样高效组织一个成员规模可能上万人的组织架构树，以及在相应节点加入权限管理功能和操作员工。镇对以上问题，我将部门和员工统一为相同的数据类型node构造成树，并对不可见的部分进行懒加载以节省内存开销。将权限管理接口独立出来，提供权限管理器用于查询当前登录用户对当前选中部门或者个人的操作权限，架构树管理器（即数据源）提供接口支持增/删/移动操作。通过以上分工，完成了组织架构管理这一功能。

2.优化IM模块性能。

工作过程中发现一个bug，有少数用户早上的时候到公司打开app会接收不到新消息。经调试发现，消息处理模块积压了大量待处理消息（包括一些用户不可见的推送可达3000条），单线程处理分发，效率很低，并且没有全部处理完之前不刷新页面，导致用户以为没有消息。针对以上问题，我梳理了消息从接收到处理完成的整个流程。在收到推送/打开客户端拉取未读消息时，建立包含未处理的消息数组的串行队列，针对每个获取到的未读消息数组，在消息分发器中使用多线程技术进行加速，并在每处理完一个类型的消息之后立即更新到首页的消息分组中，持续刷新消息页面，将消息处理过程反馈给用户，并仿照微信收取消息时顶端提示，告知用户正在收取消息或者正在处理消息。

开发中主要碰到几个问题：第一，处理线程过多，CPU上下文切换过于频繁导致处理效率低下，Cpu占用率高，甚至主线程不响应。针对这一问题使用3000条数据做压力测试，最终确定最大并发数为6，这样Cpu在iPhone5性能的机型下处理时占用率始终低于50%，操作响应正常。第二，消息重复问题。由于收到消息处理后需要进行上报，服务端做收取确认标记后才不会重新下发，所以在处理过程中重新拉取消息可能会重复处理消息。针对这一问题，对于每一次收到的消息处理串行执行，并在处理前在已收到消息的表中判重。第三，首页刷新问题。之前每处理完一个消息分类就会刷新，有些不支持批量处理的消息处理器每处理完一条消息就会会刷新，这样频繁的刷新tableview也造成了性能问题。针对以上问题，目标是减少tableview刷新频率，主要做以下几点：首先是单行刷新，每个消息分组对应到一个map中，需要刷新消息时只刷新对应行；其次是保证刷新时间间隔，维护一个刷新定时器，保证两次刷新间隔不少于0.5秒。

通过以上操作，优化了消息接收模块的性能，处理3000条消息的时间，从原来的一分多钟，缩短到大约10秒，并且在一开始处理消息立即对用户反馈状态，用户可以处理已经收到的消息。

3.开发了性能检测悬浮窗，用于实时检查性能问题。可以在debug模式下，及时发现掉帧，高cpu占用，高内存占用等问题，并集成了MLLeaksFinder及时发现视图控制器的内存泄露问题。及时发现问题，解决问题，有利于保证开发质量，不把问题带到测试阶段。开发完成后，没有再遇到内存泄露造成的奇怪bug，比如通知未注销导致的一些问题。

主要工作内容：

1.负责新需求的开发。负责开发了首页瀑布流，并在后续优化了首页性能问题，通过懒加载，添加缓存等，提升了交互体验。

2.负责线上bug的修复。

https://www.100chui.com/article/38141.html