IOS 開發APP之關於時間處理詳細介紹_IOS

來源:互聯網
上載者:User

IOS 時間處理

做App避免不了要和時間打交道,關於時間的處理,裡面有不少門道,遠不是一行API調用,擷取當前系統時間這麼簡單。我們需要瞭解與時間相關的各種API之間的差別,再因情境而異去設計相應的機制。

時間的形式

在開始深入討論之前,我們需要確信一個前提:時間是線性。即任意一個時刻,這個地球上只有一個絕對時間值存在,只不過因為時區或者文化的差異,處於同一時空的我們對同一時間的表述或者理解不同。這個看似簡單明了的道理,是我們理解各種與時間相關的複雜概念的基石。就像UTF-8和UTF-16其實都是Unicode一樣,北京的20:00和東京的21:00其實是同一個絕對的時間值。

GMT

人類對於時間的理解還很有限,但我們至少能確定一點:時間的變化是勻速的。時間前進的速度是均勻的,不會忽快忽慢,所以為了描述時間,我們也需要找到一個值,它的變化也是以均勻的速度向前變化的。

說出來你可能不信,我們人類為了尋找這個參考值,來精確描述當前的時間值,都經曆了漫長歲月的探索。你可以嘗試思考下,生活中有什麼事物是隨著時間均勻變化的,它具備的數值屬性,會隨著時間處於絕對的勻速變化狀態。

前人發現抬頭看太陽是個好辦法,太陽總是按規律的“早起晚落”,而且“亙古不變”,可以用太陽在一天當中所處的位置來描述當前的時間。後來不同地區的文化需要交流,你這裡太陽正高空照,我這可能已經下山了,所以需要有一個公用的大家都認可的地方,以這個地方太陽的位置來做參考著,溝通起來就會方便很多。最後選擇的是英國倫敦的格林尼治天文台所在地,以格林尼治的時間作為公用時間,也就是我們所說的GMT時間(Greenwich Mean Time)。

UTC

太陽所處的位置變化跟地球的自轉相關,過去人們認為地球自轉的速率是恒定的,但在1960年這一認知被推翻了,人們發現地球自轉的速率正變得越來越慢,而時間前進的速率還是恒定的,所以UTC不再被認為可以用來精準的描述時間了。

我們需要繼續尋找一個勻速前進的值。抬頭看天是我們從宏觀方向去尋找答案,科技的發展讓我們在微觀方面取得了更深的認識,於是有聰明人根據微觀粒子原子的物理屬性,建立了原子鐘,以這種原子鐘來衡量時間的變化,原子鐘50億年才會誤差1秒,這種精讀已經遠勝於GMT了。這個原子鐘所反映的時間,也就是我們現在所使用的UTC(Coordinated Universal Time )標準時間。

接下來我們看下iOS裡,五花八門的記錄時間的方式。

NSDate

NSDate是我們平時使用較多的一個類,先看下它的定義:

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 on 1 January 2001).

NSDate對象描述的是時間軸上的一個絕對的值,和時區和文化無關,它參考的值是:以UTC為標準的,2001年一月一日00:00:00這一刻的時間絕對值。

這裡有個概念很重要,我們用程式設計語言描述時間的時候,都是以一個時間軸上的絕對值為參考點,參考點再加上位移量(以秒或者毫秒,微秒,納秒為單位)來描述另外的時間點。

理解了這一點,再看NSDate的一些API調用就非常清楚了,比如:

NSDate* date = [NSDate date];NSLog(@"current date interval: %f", [date timeIntervalSinceReferenceDate]);

timeIntervalSinceReferenceDate返回的是距離參考時間的位移量,這個位移量的值為502945767秒,502945767/86400/365=15.9483056507,86400是一天所包含的秒數,365大致是一年的天數,15.94當然就是年數了,算出來剛好是此刻距離2001年的差值。

又比如,此刻我寫文章的時候,目前時間為北京時間上午11:29,看看下面代碼的輸出:

NSDate* date = [NSDate date];NSLog(@"current date: %@", date);

current date: 2016-12-09 03:29:09 +0000。可見NSDate輸出的是絕對的UTC時間,而北京時間的時區為UTC+8,上面的輸出+8個小時,剛好就是我當前的時間了。

NSDate和市區和文化無關,所以要展示具體格式的時間,我們需要NSDateFormatter和NSTimeZone的輔助。

另外關於NSDate最重要的一點是:NSDate是受手機系統時間控制的。也就是說,當你修改了手機上的時間顯示,NSDate擷取目前時間的輸出也會隨之改變。在我們做App的時候,明白這一點,就知道NSDate並不可靠,因為使用者可能會修改它的值。

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非常相似,只不過參考點是:以GMT為標準的,2001年一月一日00:00:00這一刻的時間絕對值。

同樣CFAbsoluteTimeGetCurrent()也會跟著當前裝置的系統時間一起變化,也可能會被使用者修改。

gettimeofday

這個API也能返回一個描述目前時間的值,代碼如下:

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號 00:00:00為基準時間,目前時間距離基準點位移的秒數。上述API返回的值是1481266031,表示目前時間距離UTC 1970年1月1號 00:00:00一共過了1481266031秒。

Unix time也是平時我們使用較多的一個時間標準,在Mac的終端可以通過以下命令轉換成可閱讀的時間:

date -r 1481266031

實際上NSDate也有一個API能返回Unix time:

NSDate* date = [NSDate date];NSLog(@"timeIntervalSince1970: %f", [date timeIntervalSince1970]);

gettimeofday和NSDate,CFAbsoluteTimeGetCurrent()一樣,都是受當前裝置的系統時間影響。只不過是參考的時間基準點不一樣而已。我們和伺服器通訊的時候一般使用Unix time。

mach_absolute_time()

mach_absolute_time()可能用到的同學比較少,但這個概念非常重要。

前面提到我們需要找到一個均勻變化的屬性值來描述時間,而在我們的iPhone上剛好有一個這樣的值存在,就是CPU的刻度數(ticks)。這個tick的數值可以用來描述時間,而mach_absolute_time()返回的就是CPU已經啟動並執行tick的數量。將這個tick數經過一定的轉換就可以變成秒數,或者納秒數,這樣就和時間直接關聯了。

不過這個tick數,在每次手機重啟之後,會重新開始計數,而且iPhone鎖屏進入休眠之後tick也會暫停計數。

mach_absolute_time()不會受系統時間影響,只受裝置重啟和休眠行為影響。

CACurrentMediaTime()

CACurrentMediaTime()可能接觸到的同學會多一些,先看下官方定義:

/* 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數轉化成秒數的結果。以下代碼:

double mediaTime = CACurrentMediaTime();NSLog(@"CACurrentMediaTime: %f", mediaTime);

返回的就是開機後裝置一共運行了(裝置休眠不統計在內)多少秒,另一個API也能返回相同的值:

NSTimeInterval systemUptime = [[NSProcessInfo processInfo] systemUptime];NSLog(@"systemUptime: %f", systemUptime);

CACurrentMediaTime()也不會受系統時間影響,只受裝置重啟和休眠行為影響。

sysctl

iOS系統還記錄了上次裝置重啟的時間。可以通過如下API調用擷取:

#include <sys/sysctl.h>- (long)bootTime{#define MIB_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;}

返回的值是上次裝置重啟的Unix time。

這個API返回的值也會受系統時間影響,使用者如果修改時間,值也會隨著變化。

有了以上擷取時間的各種手段,我們再來看看一些情境之下的具體應用。

情境一,時間測量

我們做效能最佳化的時候,經常需要對某個方法執行的時間做記錄,就必然會用到上面提到的一些擷取時間的方法。

在做方法執行時間的benchmark的時候,我們擷取時間的方法要滿足兩個要求,一是精讀要高,而是API本身幾乎不耗CPU時間。

用戶端做效能最佳化一般是為了主線程的流暢性,而我們知道UI線程如果遇到超過16.7ms的阻塞,就會出現掉幀現象,所以我們關注的時間的精讀實際上是在毫秒(ms)層級。我們寫用戶端代碼的時候,基本上都是處於ms這一維度,如果一個方法損耗是0.1ms,我們可以認為這個方法對於流暢性來說是安全的,如果經常看到超過1ms或者幾個ms的方法,主線程出現卡頓的幾率就會變高。

上面幾種擷取時間的方式精讀上都是足夠的,比如一個NSDateAPI調用返回的精讀是0.000004 S,也就是4微秒,CACurrentMediaTime()返回的精讀也在微秒層級,精讀上都符合要求。不過有一種看法,認為NSDate屬於類的封裝,OOP進階語言本身所帶來的損耗可能會影響最後的實際結果,在做benchmark的時候不如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);

輸出結果為:

benchmark with NSDate: 0.000046benchmark with CACurrentMediaTime: 0.000037

可以看出CACurrentMediaTime與NSDate代碼本身的損耗差異在幾微秒,而我們做UI效能最佳化的維度在毫秒層級,幾個微秒的差異完全不會影響我們最後的判斷結果。所以使用NSDate做benchmark完全是可行的,以下是我常用的兩個宏:

#define TICK  NSDate *startTime = [NSDate date]#define TOCK  NSLog(@"Time Cost: %f", -[startTime timeIntervalSinceNow])

情境二:用戶端和伺服器之間的時間同步

這也是我們經常遇到的情境,比如電商類App到零點的時候開始搶購,比如商品限購倒計時等等,這種情境下需要我們將用戶端的時間與伺服器保持一致,最重要的是,要防止使用者通過斷網修改系統時間,來影響用戶端的邏輯。

比較普遍的做法是,在一些常用的Server介面裡面帶上伺服器時間,每調用一次介面,用戶端就和伺服器時間做一次同步並記錄下來,但問題是如何防止使用者修改呢?

上面提到的NSDate,CFAbsoluteTimeGetCurrent,gettimeofday,sysctl都是跟隨系統時間變化的,mach_absolute_time和CACurrentMediaTime雖然是依據CPU時鐘數,不受系統時間影響,但在休眠和重啟的時候還是會被影響。看上去都不太適合,這裡介紹下我個人的做法。

首先還是會依賴於介面和伺服器時間做同步,每次同步記錄一個serverTime(Unix time),同時記錄當前用戶端的時間值lastSyncLocalTime,到之後算本地時間的時候先取curLocalTime,算出位移量,再加上serverTime就得出時間了:

uint64_t realLocalTime = 0;if (serverTime != 0 && lastSyncLocalTime != 0) {  realLocalTime = serverTime + (curLocalTime - lastSyncLocalTime);}else {  realLocalTime = [[NSDate date] timeIntervalSince1970]*1000;}

如果從來沒和伺服器時間同步過,就只能取本地的系統時間了,這種情況幾乎也沒什麼影響,說明用戶端還沒開始用過。

關鍵在於如果擷取本地的時間,可以用一個小技巧來擷取系統當前運行了多長時間,用系統的已耗用時間來記錄當前用戶端的時間:

//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都會受系統時間影響,但他們二者做一個減法所得的值,就和系統時間無關了。這樣就可以避免使用者修改時間了。當然使用者如果關機,過段時間再開機,會導致我們擷取到的時間慢與伺服器時間,真實情境中,慢於伺服器時間往往影響較小,我們一般擔心的是用戶端時間快於伺服器時間。

多和伺服器做時間同步,再把關鍵的時間校正邏輯放在Server端,就不會出現什麼意外的bug了。

總結

關於時間處理的邏輯就總結到這裡了,關鍵還在於我們對於時間本身的理解,對於表達時間的各種方式的理解,理解背後的原理才能選擇合適的工具。

感謝閱讀,希望能協助到大家,謝謝大家對本站的支援!

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.