常用排序算法
这里我们大概按照重要性的先后顺序介绍
快速排序是不稳定的，其时间平均时间复杂度是O ( nlgn )。
快速排序采用的思想是分治思想。
思路:快速排序是找出一个元素（理论上可以随便找一个）作为基准(pivot),然后对数组进行分区操作,使基准左边元素的值都不大于基准值,基准右边的元素值 都不小于基准值，如此作为基准的元素调整到排序后的正确位置。递归快速排序，将其他n-1个元素也调整到排序后的正确位置。最后每个元素都是在排序后的正 确位置，排序完成。所以快速排序算法的核心算法是分区操作，即如何调整基准的位置以及调整返回基准的最终位置以便分治递归。
概念：数据元素相互之间的关系称为结构。
有四类基本结构：集合、线性结构、树形结构、图状结构;
集合结构:除了同属于一种类型外，别无其它关系
线性结构:元素之间存在一对一关系常见类型有: 数组,链表,队列,栈,它们之间在操作上有所区别.例如:链表可在任意位置插入或删除元素,而队列在队尾插入元素,队头删除元素,栈只能在栈顶进行插 入,删除操作.
树形结构:元素之间存在一对多关系,常见类型有:树(有许多特例:二叉树、平衡二叉树、查找树等)
图形结构:元素之间存在多对多关系,图形结构中每个结点的前驱结点数和后续结点多个数可以任意
总结+实战+方案
做了这么久ios开发，由于最近发现自己在性能和底层相关方面，还有有待提高，一句话总结就是：知其然，而不知其所以然。
最近也一直在研究相关方面的技术，包括ios相关技术的底层实现，但是这还是远远不够的，一个真正的程序员是必须做到“学无止境”。
经过这几年的开发与学习，包括和同行朋友的了解，作为一个程序员，必备的技术有以下四种。
iOS开发常用技术底层实现（精简概述）
本章将对ios开发技术底层实现的总结，其实关于ios开发中各种底层的实现，网上相关文章多到数不过来，而不且非常不错，我也没有自信我能比他们做的更好，因为毕竟每个人专研的东西不一样，本文主要正对三类用户！
好了，废话也不多说了，我们开始吧。。。。。
微信红包
本文摘自简书大牛east520.
别告诉我你对红包不感兴趣，如果真的是这样，那么请绕道，哈哈。
现在由于微信和QQ的普及，几乎所有用户都会使用红包这个功能，但是对于一个程序员来说，每看到一个好的功能都会努力试着研究一下，哪怕不能成功，由于看到了一篇比较看的文章，所以就专门花时间去搞一顿，结果大吃一惊。
最近有不少朋友找我要红包尾数的功能，我也不知道他们为什么要这个，可能是笔者太年轻了。但是我觉得这个可能不简单，而且这样的功能做好了也不能外漏，不然笔者的程序员职业生涯估计就到头了！
前言：最近笔者在研究iOS逆向工程，顺便拿微信来练手，在非越狱手机上实现了微信自动抢红包的功能。
题外话：此教程是一篇严肃的学术探讨类文章，仅仅用于学习研究，也请读者不要用于商业或其他非法途径上，笔者一概不负责哟~~
好了，接下来可以进入正题了！
重整之道（面试+技术+底层+高级）
不要问我为什么写这篇文章。
我，就是这么有尿性。。。。。。。。。。
前面三部分已经基本上完成，后面部分会陆续更新，敬请期待。但是光靠一篇这么短的文章想将通这些事不可能的，这里主要正对面试族，或者健忘族，亦或者是装逼族。好了废话不多说，我们开始吧！
进程是指在系统中正在运行的一个应用程序
每个进程之间是独立的，每个进程均运行在其专用且受保护的内存空间内
比如同时打开QQ、Xcode，系统就会分别启动2个进程
通过“活动监视器”可以查看Mac系统中所开启的进程
概览
在iOS开发中数据存储的方式可以归纳为两类：一类是存储为文件，另一类是存储到数据库。例如前面IOS开发系列—Objective-C之Foundation框架的文章中提到归档、plist文件存储，包括偏好设置其本质都是存储为文件，只是说归档或者plist文件存储可以选择保存到沙盒中，而偏好设置系统已经规定只能保存到沙盒的Library/Preferences目录。当然，文件存储并不作为本文的重点内容。本文重点还是说数据库存储，做过数据库开发的朋友应该知道，可以通过SQL直接访问数据库，也可以通过ORM进行对象关系映射访问数据库。这两种方式恰恰对应iOS中SQLite和Core Data的内容，在此将重点进行分析:
这段时间公司一直比较忙，和组里小伙伴一起把公司项目按照之前逻辑重写了一下。由于项目比较大，还要兼顾之前项目的迭代和其他项目，目前为止只写完第一阶段。
之前项目本地持久化方案主要用的是SQLite，这次重写项目打算换一种持久化方案，于是我们经过讨论选择了苹果的“亲儿子”CoreData。
在使用CoreData的过程中，我也是一边学习一边实践。在学习的过程中，一些写的质量比较高的博客对我的帮助也很大，例如objc.io等博客，在这里就不一一列举出来了，非常感谢这些作者。
前言：
在自己开发中，每次用到数据库都会纠结是使用CoreData还是FMDB。CoreData虽然Api简单，但是调用栈非常复杂，要初始化一个Context需要至少20行代码。。。
显然，对于这种这么恶心的情况，我们的大Github必须有人会跳出来解决这种问题。于是就出现了MagicRecord这个对CoreData的封装库。一开始遇到这个库的时候，好用到几乎让我想把所有项目的数据库都换成CoreData了。两句话解决CoreData调用栈的初始化，一句话完成数据库版本升级和自动数据合并更新（虽然我们很少用到）。
然而这并不能解决一个根本性的问题，CoreData中的每个Object都要和一个context进行绑定，导致我们很多业务需求需要创建自己的私有context，然后再需要更新的时候保存到主context中。这又导致了我们在controller中或者在自己的业务类中维护多一个私有context属性。