編輯:Android開發實例
閱讀Android Frameworks中的C++代碼時,經常會碰到在條件判斷語句中使用了LIKELY和UNLIKELY這兩個宏,找到這兩個宏的定義如下:
- #define LIKELY( exp ) (__builtin_expect( (exp) != 0, true ))
- #define UNLIKELY( exp ) (__builtin_expect( (exp) != 0, false ))
long __builtin_expect (long exp, long c) 是GCC的內建函數,解析如下:
你可以使用__builtin_expect給編譯器提供分支預測的信息,通常,你因該明確使用這個編譯選項(‘-fprofile-arcs’),因為很多程序員在如何預測他們編寫的代碼實際如何執行方面都很糟糕,使用這個宏可以很方面地讓編譯器優化分支跳轉的代碼。
這個函數的返回值就是exp:一個整形表達式,c必須是一個常量,該內建函數從語義上是表明:我們期望exp == c。
所以,如果你不考慮程序執行的效率,加不加LIKELY和UNLIKELY宏,執行的結果是一樣的:
- if( LIKELY(exp) )
- {
- }
- else
- {
- }
和
- if(exp)
- {
- }
- else
- {
- }
執行的結果是一樣的。
那為什麼還要使用這兩個宏定義? 以汽車的速度為例子,如果速度超過200公裡/小時表示有異常發生,代碼可以這樣寫:
- if(speed >= 200){
- //異常處理代碼
- .....
- stop();
- }else{
- //正常處理代碼
- continue();
- }
也可以這樣寫:
這兩個方案執行後都是正確的,但是顯然效率是不一樣的,因為大多數情況下,汽車的速度不會超過200公裡/小時,當采用第一個方案時,大多數情況下,代碼執行到這裡時CPU都要執行分支跳轉的操作,這破壞了CPU的指令執行流水線,對性能的影響是顯而易見的。而第二個方案則避免了這一問題,因為大多數時候都是順序執行的。
對於第一種方案,我們可以加上UNLIKELY宏來讓編譯器來優化:
- if(UNLIKELY(speed >= 200)){
- //異常處理代碼
- .....
- stop();
- }else{
- //正常處理代碼
- continue();
- }
加上UNLIKELY宏後,相當於告訴編譯器:速度大於200是很少出現的。這樣編譯器在編譯代碼時,會適當地調整條件判斷的方式,讓CPU的指令執行順序盡可能不被打亂,已達到優化性能的效果。
所以,對於第二種方案,我們同樣可以加上LIKELY宏:
- if(LIKELY(speed < 200)){
- //正常處理代碼
- continue();
- }else{
- //異常處理代碼
- .....
- stop();
- }
一般來說。熟悉Android程序設計的人都知道Android有三個基礎組件Activity,Service和BroadcastReceiver,他們都是依賴Int
一、首先,我們來看一下效果圖,這是新浪微博的Tab滑動效果。&nbs
這篇文章主要為大家詳細介紹了Android輸入框控件ClearEditText實現清除功能,感興趣的小伙伴們可以參考一下 本文給大家帶來
在移動應用滿天飛的時代,隨著移動支付的盛行,很多應用中都集成了支付功能。之前的支付一直不是我負責,近期這個項目我負責訂單模塊少不了要做支付,每每提起