轉(zhuǎn)自：iOS關(guān)于時(shí)間的處理
做App避免不了要和時(shí)間打交道式镐，關(guān)于時(shí)間的處理玉凯，里面有不少門道，遠(yuǎn)不是一行API調(diào)用浸颓，獲取當(dāng)前系統(tǒng)時(shí)間這么簡(jiǎn)單物臂。我們需要了解與時(shí)間相關(guān)的各種API之間的差別旺拉，再因場(chǎng)景而異去設(shè)計(jì)相應(yīng)的機(jī)制产上。
時(shí)間的形式
在開始深入討論之前棵磷，我們需要確信一個(gè)前提：時(shí)間是線性的。即任意一個(gè)時(shí)刻晋涣，這個(gè)地球上只有一個(gè)絕對(duì)時(shí)間值存在仪媒，只不過(guò)因?yàn)闀r(shí)區(qū)或者文化的差異，處于同一時(shí)空的我們對(duì)同一時(shí)間的表述或者理解不同谢鹊。這個(gè)看似簡(jiǎn)單明了的道理算吩，是我們理解各種與時(shí)間相關(guān)的復(fù)雜概念的基石。就像UTF-8和UTF-16其實(shí)都是Unicode一樣佃扼，北京的20：00和東京的21：00其實(shí)是同一個(gè)絕對(duì)的時(shí)間值偎巢。
GMT
人類對(duì)于時(shí)間的理解還很有限，但我們至少能確定一點(diǎn)：時(shí)間的變化是勻速的兼耀。時(shí)間前進(jìn)的速度是均勻的压昼，不會(huì)忽快忽慢，所以為了描述時(shí)間瘤运，我們也需要找到一個(gè)值窍霞，它的變化也是以均勻的速度向前變化的。
說(shuō)出來(lái)你可能不信拯坟，我們?nèi)祟悶榱藢ふ疫@個(gè)參考值但金，來(lái)精確描述當(dāng)前的時(shí)間值，都經(jīng)歷了漫長(zhǎng)歲月的探索郁季。你可以嘗試思考下冷溃，生活中有什么事物是隨著時(shí)間均勻變化的，它具備的數(shù)值屬性梦裂，會(huì)隨著時(shí)間處于絕對(duì)的勻速變化狀態(tài)秃诵。
前人發(fā)現(xiàn)抬頭看太陽(yáng)是個(gè)好辦法，太陽(yáng)總是按規(guī)律的“早起晚落”塞琼，而且“亙古不變”菠净，可以用太陽(yáng)在一天當(dāng)中所處的位置來(lái)描述當(dāng)前的時(shí)間。后來(lái)不同地區(qū)的文化需要交流彪杉，你這里太陽(yáng)正高空照毅往，我這可能已經(jīng)下山了，所以需要有一個(gè)公共的大家都認(rèn)可的地方派近，以這個(gè)地方太陽(yáng)的位置來(lái)做參考著攀唯，溝通起來(lái)就會(huì)方便很多。最后選擇的是英國(guó)倫敦的格林尼治天文臺(tái)所在地渴丸，以格林尼治的時(shí)間作為公共時(shí)間侯嘀，也就是我們所說(shuō)的GMT時(shí)間（Greenwich Mean Time）另凌。
UTC
太陽(yáng)所處的位置變化跟地球的自轉(zhuǎn)相關(guān)，過(guò)去人們認(rèn)為地球自轉(zhuǎn)的速率是恒定的戒幔，但在1960年這一認(rèn)知被推翻了吠谢，人們發(fā)現(xiàn)地球自轉(zhuǎn)的速率正變得越來(lái)越慢，而時(shí)間前進(jìn)的速率還是恒定的诗茎，所以UTC不再被認(rèn)為可以用來(lái)精準(zhǔn)的描述時(shí)間了工坊。
我們需要繼續(xù)尋找一個(gè)勻速前進(jìn)的值。抬頭看天是我們從宏觀方向去尋找答案敢订，科技的發(fā)展讓我們?cè)谖⒂^方面取得了更深的認(rèn)識(shí)王污，于是有聰明人根據(jù)微觀粒子原子的物理屬性，建立了原子鐘楚午，以這種原子鐘來(lái)衡量時(shí)間的變化昭齐，原子鐘50億年才會(huì)誤差1秒，這種精讀已經(jīng)遠(yuǎn)勝于GMT了矾柜。這個(gè)原子鐘所反映的時(shí)間阱驾，也就是我們現(xiàn)在所使用的UTC（Coordinated Universal Time ）標(biāo)準(zhǔn)時(shí)間。
接下來(lái)我們看下iOS里把沼，五花八門的記錄時(shí)間的方式啊易。
NSDate
NSDate是我們平時(shí)使用較多的一個(gè)類，先看下它的定義：
NSDate objects encapsulate a single point in time, independent of any particular calendrical system or time zone. Date objects are immutable, representing an invariant time interval relative to an absolute reference date (00:00:00 UTC on1January2001).
NSDate對(duì)象描述的是時(shí)間線上的一個(gè)絕對(duì)的值饮睬，和時(shí)區(qū)和文化無(wú)關(guān)租谈，它參考的值是：以UTC為標(biāo)準(zhǔn)的，2001年一月一日00：00：00這一刻的時(shí)間絕對(duì)值捆愁。
這里有個(gè)概念很重要割去，我們用編程語(yǔ)言描述時(shí)間的時(shí)候，都是以一個(gè)時(shí)間線上的絕對(duì)值為參考點(diǎn)昼丑，參考點(diǎn)再加上偏移量（以秒或者毫秒呻逆，微秒，納秒為單位）來(lái)描述另外的時(shí)間點(diǎn)菩帝。
理解了這一點(diǎn)咖城，再看NSDate的一些API調(diào)用就非常清楚了，比如：
NSDate* date = [NSDate date];
NSLog(@"current date interval: %f", [date timeIntervalSinceReferenceDate]);
timeIntervalSinceReferenceDate返回的是距離參考時(shí)間的偏移量呼奢，這個(gè)偏移量的值為502945767秒宜雀，502945767/86400/365=15.9483056507，86400是一天所包含的秒數(shù)握础，365大致是一年的天數(shù)辐董，15.94當(dāng)然就是年數(shù)了，算出來(lái)剛好是此刻距離2001年的差值禀综。
又比如简烘，此刻我寫文章的時(shí)候苔严，當(dāng)前時(shí)間為北京時(shí)間上午11:29，看看下面代碼的輸出：
NSDate* date = [NSDate date];
NSLog(@"current date: %@", date);
current date: 2016-12-09 03:29:09 +0000孤澎〗烨猓可見NSDate輸出的是絕對(duì)的UTC時(shí)間，而北京時(shí)間的時(shí)區(qū)為UTC+8亥至，上面的輸出+8個(gè)小時(shí)悼沈，剛好就是我當(dāng)前的時(shí)間了贱迟。
NSDate和市區(qū)和文化無(wú)關(guān)姐扮，所以要展示具體格式的時(shí)間，我們需要NSDateFormatter和NSTimeZone的輔助衣吠。
另外關(guān)于NSDate最重要的一點(diǎn)是：NSDate是受手機(jī)系統(tǒng)時(shí)間控制的茶敏。也就是說(shuō)，當(dāng)你修改了手機(jī)上的時(shí)間顯示缚俏，NSDate獲取當(dāng)前時(shí)間的輸出也會(huì)隨之改變惊搏。在我們做App的時(shí)候，明白這一點(diǎn)忧换，就知道NSDate并不可靠恬惯，因?yàn)橛脩艨赡軙?huì)修改它的值。
CFAbsoluteTimeGetCurrent()
官方定義如下：
Absolute time is measured in seconds relative to the absolute reference date of?Jan 1 2001 00:00:00 GMT. A positive value represents a date after the reference date, a negative value represents a date before it. For example, the absolute time -32940326 is equivalent to December 16th, 1999 at 17:54:34. Repeated calls to this function do not guarantee monotonically increasing results. The system time may decrease due to synchronization with external time references or due to an explicit user change of the clock.
從上面的描述不難看出CFAbsoluteTimeGetCurrent()的概念和NSDate非常相似亚茬，只不過(guò)參考點(diǎn)是：以GMT為標(biāo)準(zhǔn)的酪耳，2001年一月一日00：00：00這一刻的時(shí)間絕對(duì)值。
同樣CFAbsoluteTimeGetCurrent()也會(huì)跟著當(dāng)前設(shè)備的系統(tǒng)時(shí)間一起變化刹缝，也可能會(huì)被用戶修改碗暗。
gettimeofday
這個(gè)API也能返回一個(gè)描述當(dāng)前時(shí)間的值，代碼如下：
struct timeval now;
struct timezone tz;
gettimeofday(&now, &tz);
NSLog(@"gettimeofday: %ld", now.tv_sec);
使用gettimeofday獲得的值是Unix time梢夯。Unix time又是什么呢言疗？
Unix time是以UTC 1970年1月1號(hào) 00：00：00為基準(zhǔn)時(shí)間，當(dāng)前時(shí)間距離基準(zhǔn)點(diǎn)偏移的秒數(shù)颂砸。上述API返回的值是1481266031噪奄，表示當(dāng)前時(shí)間距離UTC 1970年1月1號(hào) 00：00：00一共過(guò)了1481266031秒。
Unix time也是平時(shí)我們使用較多的一個(gè)時(shí)間標(biāo)準(zhǔn)人乓，在Mac的終端可以通過(guò)以下命令轉(zhuǎn)換成可閱讀的時(shí)間：
date -r 1481266031
實(shí)際上NSDate也有一個(gè)API能返回Unix time：
NSDate* date = [NSDate date];
NSLog(@"timeIntervalSince1970: %f", [date timeIntervalSince1970]);
gettimeofday和NSDate勤篮，CFAbsoluteTimeGetCurrent()一樣，都是受當(dāng)前設(shè)備的系統(tǒng)時(shí)間影響撒蟀。只不過(guò)是參考的時(shí)間基準(zhǔn)點(diǎn)不一樣而已叙谨。我們和服務(wù)器通訊的時(shí)候一般使用Unix time。
mach_absolute_time()
mach_absolute_time()可能用到的同學(xué)比較少保屯，但這個(gè)概念非常重要手负。
前面提到我們需要找到一個(gè)均勻變化的屬性值來(lái)描述時(shí)間涤垫，而在我們的iPhone上剛好有一個(gè)這樣的值存在，就是CPU的時(shí)鐘周期數(shù)（ticks）竟终。這個(gè)tick的數(shù)值可以用來(lái)描述時(shí)間蝠猬，而mach_absolute_time()返回的就是CPU已經(jīng)運(yùn)行的tick的數(shù)量。將這個(gè)tick數(shù)經(jīng)過(guò)一定的轉(zhuǎn)換就可以變成秒數(shù)统捶，或者納秒數(shù)榆芦，這樣就和時(shí)間直接關(guān)聯(lián)了。
不過(guò)這個(gè)tick數(shù)喘鸟，在每次手機(jī)重啟之后匆绣，會(huì)重新開始計(jì)數(shù)，而且iPhone鎖屏進(jìn)入休眠之后tick也會(huì)暫停計(jì)數(shù)什黑。
mach_absolute_time()不會(huì)受系統(tǒng)時(shí)間影響崎淳，只受設(shè)備重啟和休眠行為影響。
CACurrentMediaTime()
CACurrentMediaTime()可能接觸到的同學(xué)會(huì)多一些愕把，先看下官方定義：
/* Returns the current CoreAnimation absolute time. This is the result of * calling mach_absolute_time () and converting the units to seconds. */
CFTimeInterval CACurrentMediaTime (void)
CACurrentMediaTime()就是將上面mach_absolute_time()的CPU tick數(shù)轉(zhuǎn)化成秒數(shù)的結(jié)果拣凹。以下代碼：
double mediaTime = CACurrentMediaTime();NSLog(@"CACurrentMediaTime: %f", mediaTime);
返回的就是開機(jī)后設(shè)備一共運(yùn)行了(設(shè)備休眠不統(tǒng)計(jì)在內(nèi))多少秒，另一個(gè)API也能返回相同的值：
NSTimeInterval systemUptime = [[NSProcessInfo processInfo] systemUptime];
NSLog(@"systemUptime: %f", systemUptime);
CACurrentMediaTime()也不會(huì)受系統(tǒng)時(shí)間影響恨豁，只受設(shè)備重啟和休眠行為影響嚣镜。
sysctl
iOS系統(tǒng)還記錄了上次設(shè)備重啟的時(shí)間￠倜郏可以通過(guò)如下API調(diào)用獲染漳洹：
#include?
- (long)bootTime
{
#defineMIB_SIZE 2? ?
?int mib[MIB_SIZE];
? ? size_t size;? ?
? ? struct timeval? boottime;
? ? mib[0] = CTL_KERN;
? ? mib[1] = KERN_BOOTTIME;
? ? size = sizeof(boottime);? ?
? ? if (sysctl(mib, MIB_SIZE, &boottime, &size, NULL, 0) != -1)
? ? {? ? ? ?
? ? ? ? return boottime.tv_sec;
? ? }? ?
? ? return 0;
}
返回的值是上次設(shè)備重啟的Unix time。
這個(gè)API返回的值也會(huì)受系統(tǒng)時(shí)間影響扮匠，用戶如果修改時(shí)間捧请，值也會(huì)隨著變化。
有了以上獲取時(shí)間的各種手段棒搜，我們?cè)賮?lái)看看一些場(chǎng)景之下的具體應(yīng)用疹蛉。
場(chǎng)景一，時(shí)間測(cè)量
我們做性能優(yōu)化的時(shí)候力麸，經(jīng)常需要對(duì)某個(gè)方法執(zhí)行的時(shí)間做記錄可款，就必然會(huì)用到上面提到的一些獲取時(shí)間的方法。
在做方法執(zhí)行時(shí)間的benchmark的時(shí)候克蚂，我們獲取時(shí)間的方法要滿足兩個(gè)要求闺鲸，一是精讀要高，而是API本身幾乎不耗CPU時(shí)間埃叭。
客戶端做性能優(yōu)化一般是為了主線程的流暢性摸恍，而我們知道UI線程如果遇到超過(guò)16.7ms的阻塞，就會(huì)出現(xiàn)掉幀現(xiàn)象，所以我們關(guān)注的時(shí)間的精讀實(shí)際上是在毫秒（ms）級(jí)別立镶。我們寫客戶端代碼的時(shí)候壁袄，基本上都是處于ms這一維度，如果一個(gè)方法損耗是0.1ms媚媒，我們可以認(rèn)為這個(gè)方法對(duì)于流暢性來(lái)說(shuō)是安全的嗜逻，如果經(jīng)常看到超過(guò)1ms或者幾個(gè)ms的方法缭召，主線程出現(xiàn)卡頓的幾率就會(huì)變高栈顷。
上面幾種獲取時(shí)間的方式精讀上都是足夠的，比如一個(gè)NSDateAPI調(diào)用返回的精讀是0.000004 S嵌巷，也就是4微秒萄凤，CACurrentMediaTime()返回的精讀也在微秒級(jí)別，精讀上都符合要求晴竞。不過(guò)有一種看法蛙卤，認(rèn)為NSDate屬于類的封裝狠半，OOP高級(jí)語(yǔ)言本身所帶來(lái)的損耗可能會(huì)影響最后的實(shí)際結(jié)果噩死，在做benchmark的時(shí)候不如C函數(shù)調(diào)用精準(zhǔn)，為了驗(yàn)證這一說(shuō)法神年，我寫了一段簡(jiǎn)單的測(cè)試代碼：
int testCount = 10000;
double avgCost = 0;
for (int i = 0; i < testCount; i ++) {
? ? NSDate* begin = [NSDate date];? ?
? ? NSLog(@"a meaningless log");
? ? avgCost += -[begin timeIntervalSinceNow];
}
NSLog(@"benchmark with NSDate: %f", avgCost/testCount);
avgCost = 0;
for (int i = 0; i < testCount; i ++) {?
? ? double startTime = CACurrentMediaTime();? ?
? ? NSLog(@"a meaningless log");? ?
? ? double endTime = CACurrentMediaTime();
? ? avgCost += (endTime - startTime);
}
NSLog(@"benchmark with CACurrentMediaTime: %f", avgCost/testCount);
輸出結(jié)果為：
benchmark with NSDate: 0.000046
benchmark with CACurrentMediaTime: 0.000037
可以看出CACurrentMediaTime與NSDate代碼本身的損耗差異在幾微秒已维，而我們做UI性能優(yōu)化的維度在毫秒級(jí)別，幾個(gè)微秒的差異完全不會(huì)影響我們最后的判斷結(jié)果已日。所以使用NSDate做benchmark完全是可行的垛耳，以下是我常用的兩個(gè)宏：
#define TICK NSDate *startTime = [NSDate date]
#define TOCK NSLog(@"Time Cost: %f", -[startTime timeIntervalSinceNow])
場(chǎng)景二：客戶端和服務(wù)器之間的時(shí)間同步
這也是我們經(jīng)常遇到的場(chǎng)景，比如電商類App到零點(diǎn)的時(shí)候開始搶購(gòu)飘千，比如商品限購(gòu)倒計(jì)時(shí)等等堂鲜，這種場(chǎng)景下需要我們將客戶端的時(shí)間與服務(wù)器保持一致，最重要的是护奈，要防止用戶通過(guò)斷網(wǎng)修改系統(tǒng)時(shí)間缔莲，來(lái)影響客戶端的邏輯。
比較普遍的做法是霉旗，在一些常用的Server接口里面帶上服務(wù)器時(shí)間痴奏，每調(diào)用一次接口，客戶端就和服務(wù)器時(shí)間做一次同步并記錄下來(lái)厌秒，但問(wèn)題是如何防止用戶修改呢读拆？
上面提到的NSDate，CFAbsoluteTimeGetCurrent鸵闪，gettimeofday檐晕，sysctl都是跟隨系統(tǒng)時(shí)間變化的，mach_absolute_time和CACurrentMediaTime雖然是依據(jù)CPU時(shí)鐘數(shù)蚌讼，不受系統(tǒng)時(shí)間影響辟灰，但在休眠和重啟的時(shí)候還是會(huì)被影響屠列。看上去都不太適合伞矩，這里介紹下我個(gè)人的做法笛洛。
首先還是會(huì)依賴于接口和服務(wù)器時(shí)間做同步，每次同步記錄一個(gè)serverTime（Unix time）乃坤，同時(shí)記錄當(dāng)前客戶端的時(shí)間值lastSyncLocalTime苛让，到之后算本地時(shí)間的時(shí)候先取curLocalTime，算出偏移量湿诊，再加上serverTime就得出時(shí)間了：
uint64_t realLocalTime = 0;
if (serverTime != 0 && lastSyncLocalTime != 0) {
? ? realLocalTime = serverTime + (curLocalTime - lastSyncLocalTime);
}else {? ? realLocalTime = [[NSDate date] timeIntervalSince1970]*1000;}
如果從來(lái)沒和服務(wù)器時(shí)間同步過(guò)狱杰，就只能取本地的系統(tǒng)時(shí)間了，這種情況幾乎也沒什么影響厅须，說(shuō)明客戶端還沒開始用過(guò)仿畸。
關(guān)鍵在于如果獲取本地的時(shí)間，可以用一個(gè)小技巧來(lái)獲取系統(tǒng)當(dāng)前運(yùn)行了多長(zhǎng)時(shí)間朗和，用系統(tǒng)的運(yùn)行時(shí)間來(lái)記錄當(dāng)前客戶端的時(shí)間：
//get system uptime since last boot
- (NSTimeInterval)uptime
{? ?
? ? struct timeval boottime;? ?
? ? int mib[2] = {CTL_KERN, KERN_BOOTTIME};
? ? size_t size = sizeof(boottime);? ?
? ? struct timeval now;?
? ? struct timezone tz;
? ? gettimeofday(&now, &tz);?
? ? double uptime = -1;?
? ? if (sysctl(mib, 2, &boottime, &size, NULL, 0) != -1 && boottime.tv_sec != 0)
? ? {
? ? ? ? uptime = now.tv_sec - boottime.tv_sec;
? ? ? ? uptime += (double)(now.tv_usec - boottime.tv_usec) / 1000000.0;
? ? }?
? ? return uptime;
}
gettimeofday和sysctl都會(huì)受系統(tǒng)時(shí)間影響错沽，但他們二者做一個(gè)減法所得的值，就和系統(tǒng)時(shí)間無(wú)關(guān)了眶拉。這樣就可以避免用戶修改時(shí)間了千埃。當(dāng)然用戶如果關(guān)機(jī)，過(guò)段時(shí)間再開機(jī)忆植，會(huì)導(dǎo)致我們獲取到的時(shí)間慢與服務(wù)器時(shí)間放可，真實(shí)場(chǎng)景中，慢于服務(wù)器時(shí)間往往影響較小朝刊，我們一般擔(dān)心的是客戶端時(shí)間快于服務(wù)器時(shí)間耀里。
多和服務(wù)器做時(shí)間同步，再把關(guān)鍵的時(shí)間校驗(yàn)邏輯放在Server端拾氓，就不會(huì)出現(xiàn)什么意外的bug了冯挎。
總結(jié)
關(guān)于時(shí)間處理的邏輯就總結(jié)到這里了，關(guān)鍵還在于我們對(duì)于時(shí)間本身的理解痪枫，對(duì)于表達(dá)時(shí)間的各種方式的理解织堂，理解背后的原理才能選擇合適的工具。
附：
NSDate 奶陈、CFAbsoluteTimeGetCurrent易阳、CACurrentMediaTime 的區(qū)別
