最近发生了一些不是很愉快的事情，导致断更很长一段时间，很抱歉。“不要炫技，理解原理，对自己的代码负责，才能对团队和项目负责”--郭前辈在群里说过的语录，让我很是欢喜和受教。鄙人写第一次写blog是在2011年，那时候写技术blog的初衷是为了写日记：今天我学到了什么知识，技术，记录自己程序猿的成长点滴。随着技术的积累，写blog为了分享：傻逼，如果你也碰到这种问题，这是我的解决方案，看了这些XXX处理好的，可以“抄”这份60分的答案来解决问题。到现在这阶段，写blog是为了在share的同时，帮助一些人（你也可以理解为开始嘚瑟装逼炫技）。我想结交一些人，有相同共性的人：对技术的热爱，喜欢专研。可是在结交的时候，我又很害怕，怕我情不自禁的说错话，怕我情不自禁的想要强加自己的观点来说服别人来认可，我说的是对的，其实我很怕和别人争技术。“你怎么这么傻逼，有什么好吵的，他觉得他是对的，到时候出了问题他自己能解决就行了，你保证你自己不出bug你就是对的，做技术的不要讨论技术”--蔡前辈在一次鄙人和同事争吵的时候严厉的批评。那么——要不要讨论技术？我想我还是会选择要讨论技术。在程序员的行列中，我一直都这么看待自己：我不牛B，碰到能帮我，交给我新技术和知识的人，我都会去尊称一声大神，前辈。我也是一直这么看待向我提问的猿类：他很好学，要向他学习。知识和技术到处都是，只有学到了才是自己的。
今天下班回家看网页，看了cocoaChina发送的邮件，其中有篇看完后有点哭笑不得。作为一个关注了cocoaChina三年的铁粉，也开始对这个网站有点失望了。因为一部分的文章是错的离谱的，一部分的文章是囫囵吞枣的，一部分文章是没有阅读价值的为了完成任务的，这些都会被完成任务一样的推荐，就好比今天刚看完的MVVM，看完后根本就不知道它给我带来了什么，MVVM到底是什么都还需要去wiki查询：The Model View ViewModel (MVVM) is an architectural pattern used in software engineering that originated from Microsoft as a specialization of the Presentation Model design pattern introduced by Martin Fowler.[1]。很是怀念早一批大神的blog文章。
http://en.wikipedia.org/wiki/Model_View_ViewModel
好吧，终于可以开始今天blog的主题了：IM底层架构设计+技术准备工作
免责声明：我只是一位纯IOS 3years +的菜逼，若给你产生了误导，疑惑，中毒等不良状况，请拉你的技术上司来一起评价：这傻逼说的对不对？要不要一起去教育他一下？（教育地址：110293734@qq.com，欢迎大神教育~~~~(>_<)~~~~ ）
一.MVC &MVVM 架构
MVC MVP MVVM ...等等，我实在是说不清楚，因为我没看书，没查文档，写project也没严格要求这么去写。因为我只是知道一点，”这TMD这么多设计模式，到底是为了什么我要去用“。MVC，在从美国深造N年回来的第一任老大曾耐心的教育了我2个半小时，啥是MVC。苦逼coding了9年的另一位老大曾辛苦的写了一个demo教育我，啥是MVC。那么我只说一个东西，啥是model or module 。
http://zh.wikipedia.org/wiki/MVC
用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法。“
Model ”有对数据直接访问的权力，例如对数据库的访问。“Model”不依赖“View”和“Controller”，也就是说， Model 不关心它会被如何显示或是如何被操作。但是 Model 中数据的变化一般会通过一种刷新机制被公布。为了实现这种机制，那些用于监视此
Model 的 View 必须事先在此 Model 上注册，从而，View 可以了解在数据 Model 上发生的改变（PS：这是VM定义）。
keyword：封装，处理方法，对数据的访问，不依赖，VM需要被View注册（注射，射入，注入）
MVC的儿子（继承者），有一个叫做MVVM，长得看起来比它老爸MVC帅一点。但是干起活来，真操蛋，代码满天飞，各种protocol，各种注射，还不如它老爸干活有条理，踏实，干净，整洁。——来自 一个不用MVVM的菜逼内心独白
如果你分不清楚 数据结构、 presentTemp（一种类似于格式Struct定义和用途的Class）和 model的概念，建议你好好总结和分析一下，或者找你老大or前辈帮忙讲解讲解。我不觉得羞人，只要你讲得有道理，我就改就接受你正确的观点。
当然，你不了解设计模式，不了解架构，其实也没关系。因为我就不是很了解，但是我写的代码条理很清晰，规范，VC很轻量级，高内聚低耦合，同事好理解，用起来简单明了，那么这就是你的架构和模式。（不要为了招式华丽而不能完成和良好的维护project，做出干净整洁能良好维护的project就是好武功）。
二.技术准备工作
数据库: 1CoreData + Multi Thread强烈推荐
2 libSqlite3.0 + Multi Thread不太推荐
监听：1NSFetchedResultsController强烈推荐
2 NSNotificationCenter一般推荐
3 KVO不太推荐
多线程：1GCD强烈推荐
2NSOperationQueue & NSOperation一般推荐
3 NSThead不太推荐
不太推荐：这些技术太过于具体，不好控制，累，易错，不安全
一般推荐：部分技术实现会需要
强烈推荐：抽象、好用、不易错
做IM，对数据的存储读取，对UI的数据填充重绘都有很高的要求。特别是数据这块。若多线程数据处理效率low，那么消息响应慢。若UI数据填充、绘制差，那么即时通讯体验糟糕。使用强烈推荐技术,可以良好保证这些。
三. 实际运用
附图：架构设计
Model+XMPPService 下载地址：正在准备中...
暂时没有下期了，如果提问的人多，会考虑继续写。
正在准备model +XMPPService的简化版封装，然后传到https://github.com/XiangqiTu/XQXMPPService。一些具体的说明都会在注释里面。敬请期待
XMPP协议实现即时通讯底层书写 (三) IOS XMPPFramework --IM底层架构设计+技术准备工作
原文地址：http://blog.csdn.net/tuxiangqi/article/details/43048781
