近期伊书突然接到一些外国用户的投诉，说伊书界面变成了中文，但他们系统语言不是中文，是法文俄文日文等，伊书只支持中文跟英文，在不支持系统所用语言的时候，理应会自动选用英文，不知为什么会选成了中文，经过艰难困苦的重重排查，终于找到原因，知道了iOS多语言备选的规则。
主要有两个影响因素，一是CFBundleDevelopmentRegion(Info.plist的一个字段)，二是iOS8新增的系统首选语言列表：
续AFNetworking2.0源码解析<一><二><三>，本篇来看看AFURLResponseSerialization做的事情。
结构
AFURLResponseSerialization负责解析网络返回数据，检查数据是否合法，把NSData数据转成相应的对象，内置的转换器有json,xml,plist,image，用户可以很方便地继承基类AFHTTPResponseSerializer去解析更多的数据格式，AFNetworking这一套响应解析机制结构很简单，主要就是两个方法：
1.-validateResponse:data:error:
基类AFHTTPResponseSerializer的这个方法检测返回的HTTP状态码和数据类型是否合法，属性acceptableStatusCodes和acceptableContentTypes规定了合法的状态码和数据类型，例如JSONSerialization就把acceptableContentTypes设为@”application/json”, @”text/json”, @”text/javascript”，若不是这三者之一，就验证失败，返回相应的NSError对象。一般子类不需要重写这个方法，只需要设置好acceptableStatusCodes和acceptableContentTypes就行了。
（更多…）
本篇说说安全相关的AFSecurityPolicy模块，AFSecurityPolicy用于验证HTTPS请求的证书，先来看看HTTPS的原理和证书相关的几个问题。
HTTPS
HTTPS连接建立过程大致是，客户端和服务端建立一个连接，服务端返回一个证书，客户端里存有各个受信任的证书机构根证书，用这些根证书对服务端返回的证书进行验证，经验证如果证书是可信任的，就生成一个pre-master secret，用这个证书的公钥加密后发送给服务端，服务端用私钥解密后得到pre-master secret，再根据某种算法生成master secret，客户端也同样根据这种算法从pre-master secret生成master secret，随后双方的通信都用这个master secret对传输数据进行加密解密。
（更多…）
本篇我们继续来看看AFNetworking的下一个模块 — AFURLRequestSerialization。
AFURLRequestSerialization用于帮助构建NSURLRequest，主要做了两个事情：
1.构建普通请求：格式化请求参数，生成HTTP Header。
2.构建multipart请求。
分别看看它在这两点具体做了什么，怎么做的。
（更多…）
最近看AFNetworking2的源码，学习这个知名网络框架的实现，顺便梳理写下文章。AFNetworking2的大体架构和思路在这篇文章已经说得挺清楚了，就不再赘述了，只说说实现的细节。AFNetworking的代码还在不断更新中，我看的是AFNetworking2.3.1。
本篇先看看AFURLConnectionOperation，AFURLConnectionOperation继承自NSOperation，是一个封装好的任务单元，在这里构建了NSURLConnection，作为NSURLConnection的delegate处理请求回调，做好状态切换，线程管理，可以说是AFNetworking最核心的类，下面分几部分说下看源码时注意的点，最后放上代码的注释。
（更多…）
iOS APP编译后，除了一些资源文件，剩下的就是一个可执行文件，有时候项目大了，引入的库多了，可执行文件很大，想知道这个可执行文件的构成是怎样，里面的内容都是些什么，哪些库占用空间较高，可以用以下方法勘察：
1.XCode开启编译选项Write Link Map File
XCode -> Project -> Build Settings -> 搜map -> 把Write Link Map File选项设为yes，并指定好linkMap的存储位置
2.编译后，到编译目录里找到该txt文件，文件名和路径就是上述的Path to Link Map File
位于~/Library/Developer/Xcode/DerivedData/XXX-eumsvrzbvgfofvbfsoqokmjprvuh/Build/Intermediates/XXX.build/Debug-iphoneos/XXX.build/
这个LinkMap里展示了整个可执行文件的全貌，列出了编译后的每一个.o目标文件的信息（包括静态链接库.a里的），以及每一个目标文件的代码段，数据段存储详情。
1
以伊书项目为例，在LinkMap里首先列出来的是目标文件列表：
# Object files: [ 0] linker synthesized [ 1] /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk/usr/lib/crt1.o [ 2] /Users/bang/Library/Developer/Xcode/DerivedData/yishu-eyzgphknrrzpevagadjtwpzzeqag/Build/Intermediates/yishu.build/Debug-iphonesimulator/yishu.build/Objects-normal/i386/TKPFileInfo.o ... [280] /Users/bang/Downloads/yishu/yishu/Classes/lib/UMeng/MobClick/libMobClickLibrary.a(UMANJob.o) [281] /Users/bang/Downloads/yishu/yishu/Classes/lib/UMeng/MobClick/libMobClickLibrary.a(UMANWorker.o) [282] /Users/bang/Downloads/yishu/yishu/Classes/lib/UMeng/MobClick/libMobClickLibrary.a(MobClick.o) [283] /Users/bang/Downloads/yishu/yishu/Classes/lib/UMeng/MobClick/libMobClickLibrary.a(UMANLaunch.o) ...
前面中括号里的是这个文件的编号，后面会用到，像项目里引用到静态链接库libMobClickLibrary.a里的目标文件都会在这里列出来。
2
接着是一个段表，描述各个段在最后编译成的可执行文件中的偏移位置及大小，包括了代码段（__TEXT，保存程序代码段编译后的机器码）和数据段（__DATA，保存变量值）
# Sections: # Address Size Segment Section 0x00002740 0x00273890 __TEXT __text 0x00275FD0 0x00000ADA __TEXT __symbol_stub 0x00276AAC 0x00001222 __TEXT __stub_helper 0x00277CCE 0x00019D9E __TEXT __objc_methname 0x00291A70 0x00012847 __TEXT __cstring 0x002A42B7 0x00001FC1 __TEXT __objc_classname 0x002A6278 0x000046A7 __TEXT __objc_methtype 0x002AA920 0x000061CE __TEXT __ustring 0x002B0AF0 0x00000764 __TEXT __const 0x002B1254 0x000028B8 __TEXT __gcc_except_tab 0x002B3B0C 0x00004EBC __TEXT __unwind_info 0x002B89C8 0x0003662C __TEXT __eh_frame 0x002EF000 0x00000014 __DATA __program_vars 0x002EF014 0x00000284 __DATA __nl_symbol_ptr 0x002EF298 0x0000073C __DATA __la_symbol_ptr 0x002EF9E0 0x000030A4 __DATA __const 0x002F2A84 0x00000590 __DATA __objc_classlist 0x002F3014 0x0000000C __DATA __objc_nlclslist 0x002F3020 0x0000006C __DATA __objc_catlist 0x002F308C 0x000000D8 __DATA __objc_protolist 0x002F3164 0x00000008 __DATA __objc_imageinfo 0x002F3170 0x0002BC80 __DATA __objc_const 0x0031EDF0 0x00003A30 __DATA __objc_selrefs 0x00322820 0x00000014 __DATA __objc_protorefs 0x00322834 0x000006B8 __DATA __objc_classrefs 0x00322EEC 0x00000394 __DATA __objc_superrefs 0x00323280 0x000037C8 __DATA __objc_data 0x00326A48 0x000096D0 __DATA __cfstring 0x00330118 0x00001424 __DATA __objc_ivar 0x00331540 0x00006080 __DATA __data 0x003375C0 0x0000001C __DATA __common 0x003375E0 0x000018E8 __DATA __bss
首列是数据在文件的偏移位置，第二列是这一段占用大小，第三列是段类型，代码段和数据段，第四列是段名称。
每一行的数据都紧跟在上一行后面，如第二行__symbol_stub的地址0x00275FD0就是第一行__text的地址0x00002740加上大小0x00273890，整个可执行文件大致数据分布就是这样。
这里可以清楚看到各种类型的数据在最终可执行文件里占的比例，例如__text表示编译后的程序执行语句，__data表示已初始化的全局变量和局部静态变量，__bss表示未初始化的全局变量和局部静态变量，__cstring表示代码里的字符串常量，等等。
3
接着就是按上表顺序，列出具体的按每个文件列出每个对应字段的位置和占用空间
# Address Size File Name 0x00002740 0x0000003E [ 1] start 0x00002780 0x00000400 [ 2] +[TKPFileInfo parseWithDictionary:] 0x00002B80 0x00000030 [ 2] -[TKPFileInfo fileID] ...
同样首列是数据在文件的偏移地址，第二列是占用大小，第三列是所属文件序号，对应上述Object files列表，最后是名字。
例如第二行代表了文件序号为2（反查上面就是TKPFileInfo.o）的parseWithDictionary方法占用了1000byte大小。
使用
这个文件可以让你了解整个APP编译后的情况，也许从中可以发现一些异常，还可以用这个文件计算静态链接库在项目里占的大小，有时候我们在项目里链了很多第三方库，导致APP体积变大很多，我们想确切知道每个库占用了多大空间，可以给我们优化提供方向。LinkMap里有了每个目标文件每个方法每个数据的占用大小数据，所以只要写个脚本，就可以统计出每个.o最后的大小，属于一个.a静态链接库的.o加起来，就是这个库在APP里占用的空间大小。
写了个nodejs版统计程序可供使用：https://gist.github.com/bang590/8f3e9704f1c2661836cd
伊书的阅读器是用CoreText排版的，在中文字体的选择上，自带的字体中只有黑体，后来发现日文字体Hiragino也是可以用于中文，而且显示效果比黑体好很多，于是选用了这个字体。但在CoreText排版中遇到个问题，用Hiragino字体排版速度非常慢，几乎是默认黑体的100倍，以下是用Instrument Time Profiler查看排版同一章内容的时间消耗：
Hiragino:
黑体：
时间都消耗在CTFramesetterCreateWithAttributedString里，CoreText又不开源，看不到内部实现，在TimeProfiler里再继续展开，到最后只能看到时间分别耗在两个TRunGlue::ComputeEndIndex()里，看不出什么头绪。
后来用Instrument Allocation查看APP的内存分配时，发现用Hiragino字体排版生成的CTRun非常多，一章内容有2万多个CTRun。按理说，若一篇文章字体格式全部一样，渲染到frame之前CTRun只会有一个，渲染到frame后一行一个CTRun，怎样都不应该出现这么多CTRun。
再测了用黑体排版生成的CTRun次数，这次符合预期，只有70多个：
可以猜测到用Hiragino字体速度慢就是因为生成了大量的CTRun，那为什么会出现这样的情况？断点进入渲染处，打出其中一行CTLine数据，如下：
发现一些文字自动被转为黑体了。原因是Hiragino只支持部分中文字体，而那些不支持的中文字体就要用黑体代替，又因为一篇文章里会交错出现很多Hiragino支持和不支持的字，于是无法用一个CTRun表示一整段文字，每个交错都用一个新的CTRun，导致CTRun非常多，排版处理逻辑变复杂，耗时变高。
终于找到问题的原因，但如果想用Hiragino字体显示中文，这个问题还是无解的。其实在iOS4.x里是没有这个问题的，估计当时CoreText还没有为字体问题拆分多个CTRun，在5.0才开始这样做。除了我使用Hiragino字体会遇到这个问题外，在中英混杂的文字里用英文字体也有这样的问题，因为英文字体不支持中文显示，还是会被拆分成很多个CTRun，用CoreText注重性能的人可以注意下这个问题。
在邮件/日历/SNS等客户端里，客户端数据要不断与服务端进行数据同步，在同步过程中，只拉取有修改的数据，称为增量更新，增量更新方案一般有两种，一是对比，二是日志。
对比
对比就是客户端请求服务端所有关键数据，跟本地已有的数据进行对比，筛选出增删改的数据进行更新。
用对比方法的好处是服务端什么都不用做，坏处是客户端逻辑复杂，耗网络流量。在这种方案里，数据的新增和删除很容易判断，根据客户端数据的id列表和服务端数据的id列表进行对比就行，若要判断哪个数据有修改则比较麻烦，需要取回数据进行对比，如果从服务端拉回所有对所有数据进行对比会很耗网络流量，有一个优化方式，就是对每个数据的修改进行标记。
以日历为例，一个日历可修改的字段很多，例如时间段，内容，邀请人等，全部拉回来对比不现实，对此可以在服务端给每个日历事件新增一个字段tag，表示这个日历事件的版本，服务端更新一个日历事件时会同时更新这个tag，客户端只需要取回每个id对应的tag，跟本地保存的tag对比，不一致表示这个日历事件已经更新，再去获取日历实体就完成更新了。
若服务端因为某些原因无法给每个数据保存一个版本标记，可以实时计算，在客户端和服务端约定一个算法，把所有可变参数拿出来，通过特定算法hash出一个值，对比这个hash值判断是否需要更新。
邮件协议IMAP，日历协议CalDAV就是用这种方式做增量更新，IMAP并没有做上述的优化，在判断邮件有没有更新时只能乖乖把所有数据请求回来对比，数据是XML，算是相当低效的协议。CalDAV给每个日历事件加了上述的tag，直接对比即可知道是否需要更新。
日志
日志指服务端记录数据的每一次增删改，用一个类似版本号的sync-key标记这次修改，客户端通过一个旧的sync-key向服务端请求，服务端返回这个sync-key与最新sync-key之间所有的修改给客户端，完成增量更新。
这个sync-key在服务端的实现上可以是时间，也可以是一个自增的id，sync-key之间有顺序关系就行。在一个数据集里，每次数据有更新，就新增一个sycn-key，并记录这次更新。图示这个过程：
这个方案客户端逻辑很简单，但服务端负担较大，每次数据更新都要记录，客户端请求时需要查询给出相应的数据。这个方案在实际操作中还有两个问题：
一是时间长了服务端保存数据量过大。可以通过限制记录的条数解决，超过限制就删除最旧的记录。这样做会出现一个问题，若客户端带着在服务端已被删除的sync-key上来请求，该如何处理？一般做法是返回一个错误给客户端，让客户端重新拉取所有数据。
二是若客户端sync-key过旧，增量数据可能过大。客户端数据太老，有太多数据需要更新，若一次性返回所有增量数据，这个请求可能会很大，请求时间太长，成功率也会很低。解决方式是分多次请求，客户端和服务端可以约定一个字段作为阀值，服务端每次返回的增量数据量不超过这个阀值，若总数据超过这个阀值，则分多次请求，通过每次请求返回的sync-key定位下次请求该返回哪些数据。例如客户端sync-key是100，服务端最新sync-key是1000，阀值是50，客户端第一次带sync-key=100请求，服务端第一次返回sycn-key 100-150这一段增量数据，并返回sync-key=150，并有一个值告诉客户端这个sync-key还不是最新，客户端再带上sync-key=150请求，以此类推，直到sync-key=1000。
微软的Exchange/ActiveSync就是用这种方式实现增量更新，ActiveSync还用WBXML压缩了数据，更适用于移动端。此外日历协议CalDAV的也有一个扩展协议RFC6578使用这种方式。ActiveSync和CalDAV扩展协议都有分多次请求增量数据的策略。
————
对于Timeline式的数据，增量更新方式多是以上两种，或者这两种的变体，可以根据业务特性修改或简化其中的逻辑，例如对于微博Timeline，它可以不考虑微博的修改，不考虑同步评论转发数的变化，不考虑同步删除的微博，并且每一条微博都有一个递增的id，那它的增量更新逻辑就很简单，只需要把客户端最新一条微博的id作为since_id传到服务端，返回比这个id更新的微博就行了，这里微博id相当于日志方式的sync-key，算是对日志方式的一种简化。
单例本来是个很简单的模式，实现上应该也是很简单，但C++单例的简单实现会有一些坑，来看看为了避免这些坑怎样一步步演化到boost库的实现方式。
方案一
class QMManager
{
public:
static QMManager &instance()
{
static QMManager instance_;
return instance_;
}
}
这是最简单的版本，在单线程下(或者是C++0X下)是没任何问题的，但在多线程下就不行了，因为static QMManager instance_;这句话不是线程安全的。
在局部作用域下的静态变量在编译时，编译器会创建一个附加变量标识静态变量是否被初始化，会被编译器变成像下面这样（伪代码）：
static QMManager &instance()
{
static bool constructed = false;
static uninitialized QMManager instance_;
if (!constructed) {
constructed = true;
new(&s) QMManager; //construct it
}
return instance_;
}
这里有竞争条件，两个线程同时调用instance()时，一个线程运行到if语句进入后还没设constructed值，此时切换到另一线程，constructed值还是false，同样进入到if语句里初始化变量，两个线程都执行了这个单例类的初始化，就不再是单例了。
（更多…）
最初
最近在开发应用时碰到使用ASIHttpRequest后在某些机器上发不出请求的问题，项目开启了ARC，代码是这样写的：
@implement MainController
- (void) fetchUrl{
ASIHTTPRequest *request = [ASIHTTPRequest requestWithURL:[NSURL URLWithString:currUrl]];
[request setCompletionBlock:^{
NSLog(@"completed");
}];
[request startAsynchronous];
}
@end
后来发现原因是request这个变量在退出这个函数后就被释放了，自然发不出请求。因为用了ARC，没法手动调用[request retain]让这个变量不被释放，所以只能把这个变量变成实例变量，让Controller实例存在的过程中一直持有这个变量不释放。
@interface MainController {
ASIHTTPRequest *request;
}
@end
@implement MainController
- (void) fetchUrl{
request = [ASIHTTPRequest requestWithURL:[NSURL URLWithString:currUrl]];
[request setCompletionBlock:^{
[self complete];
}];
[request setFailedBlock:^{
NSLog(@"failed");
}];
[request startAsynchronous];
}
@end
问题一
这下发送请求没问题了，但出了另一个问题，XCode编译后提示[self complete]这一行可能会导致循环引用。因为MainController实例持有request， request持有completionBlock，completionBlock又持有MainController，导致循环引用，MainController实例在外界引用计数为0时仍无法被释放，因为自身的变量request里持有MainController实例的引用，其引用计数永远大于1。
导致这样循环引用的原因是在completionBlock里调用的self是一个strong类的引用，会使self引用计数+1，可以保证在调用过程self不会被释放，但在这里不需要这样的保证，可以声明另一个__weak变量指向self，这样在block使用这个变量就不会导致self引用计数+1，不会导致循环引用。