6.15.2009

在Eclipse下看framework的source code

參考: View Android Source Code in Eclipse

簡單來說,trace ADT的code會發現ADT會去android.jar同個目錄下的sources這個目錄找source code,
所以我們只要將android的java source code撿一撿,照package放到sources這個目錄就可以了。
所以參考link中的python script就是在幹這件事,不過我有兩點建議:
1. 在沒有make過的source code目錄下執行這個script:因為out這個目錄下有重複的java code
(而且out這個目錄有夠肥)
2. 把zippath = match.group(1).replace('.', '/') + '/' + file改成
zippath = 'sources/' + match.group(1).replace('.', '/') + '/' + file
這樣解出來的檔案和目錄就會放在sources目錄裡面了.

最近還在研究怎麼debug native code,之前make的gdb不能debug multi-thread的程式 = ="
看看android-ndk有沒有進展好了

6.14.2009

Eclipse JEE vs Java 6 Update 14

如果你更新到Java 1.6 Update 14, 而且原本能跑的Eclipse突然不能跑的話,
將eclipse.ini中的-Xmx512m改成--launcher.XXMaxPermSize所指定的size試看看,
我是改成-Xmx256m就能跑了

3.28.2009

不知不覺都變月刊了

這個月的頭條就是筆者找到工作了,從事Android UI的設計。最近發現API Demo的sample已經不夠參考了,因為不同的device跟輸入方式所需要的UI是大大不同,而API demo基本上是以手機的應用為主,今天如果我是要設計成Nettop或是TV用的UI,絕不是把畫面放大就能草草交差的事。雖然筆者滿懷雄心壯志,但是在業界打滾幾年後也知道公司根本不會有那個耐心等我好好設計架構、做user survey甚至是發好幾版的demo template;"time to market" kills designs,難怪路上滿滿都是山寨UI。

大家也都知道現在工作難找,筆者也被凹了。對我來說,這也就只是一份工作罷了,如果可以,我還寧願自己寫程式去賣。

2.18.2009

癮科技也有Android專屬子頻道了

網址是 http://android.cool3c.com/
這是比較偏向user端的site,開發者也可以藉此觀察使用者的需求。

順便更新一下近況,歷經過年,最近的工作機會“似乎”有那麼多了一些,所以最近忙著更新自傳履歷還有K書,不管未來是做什麼工作,基本功是一直要練的。明天又要去面試了,先這樣。

1.04.2009

[C語言] Rounding 四捨五入

前陣子有公司找我去面談,結果被打槍了,心情低落了一陣子,所以一段時間沒文章。最近在實驗室BBS有學弟妹分享如何在Matlab呼叫C寫的code(因為Matlab實在跑太慢了,更不用說Mac版的),不過這不是重點,因為我的畢業論文就用過這招了,那段程式是用inline assembly做四捨五入,所以我想就來分享一點使用C語言實作Rounding(四捨五入)的各種方法與經驗。

一般人想到用C實作四捨五入,會有幾種方法?就我所知,至少有將近10種或是更多(不好意思,學藝不精),以下分享最簡單到稍難的方法,除此以外大概還有C++專屬的用法、CPU限定的用法(跟32/64-bit有關)以及使用magic number的用法,這些我就不多著墨了,有興趣的讀者可以用我前面提供的線索去找找。

1. 利用C語言中浮點數轉整數會把小數點去掉的特性,這是ANSI C裡頭制定的規格,所以大部份的平台都可以使用(沒有浮點數的就別來亂了),程式大概長這樣:

inline int myIntRound(double dInput)
{
    if(dInput >= 0.0f)
    {
        return ((int)(dInput + 0.5f));
    }
    return ((int)(dInput - 0.5f));
}

2. 使用math.h中的round()函式,唯一要特別注意的是接回傳值是用double或int,永遠別忽略type casting所帶來的effort,使用方法很簡單,把值丟進去就行了:
double dResult = round(dInput);

3. GCC的math.h中可以找到nearbyint()這個函式,用法跟round()一樣:
double dResult = nearbyint(dInput);

4. 接下來這個方法其實有點脫褲子放屁,如果你的math.h沒有提供round()可以派上用場。一樣include math.h,我們改用floor()及ceil()來實作,程式碼如下:

inline double myFloorRound(double dInput)
{
    if(dInput >= 0.0f)
    {
        return floor(dInput + 0.5f);
    }
    return ceil(dInput - 0.5f);
}

5. 接下來要介紹的方法就比較不那麼跨平台了,我們要使用frndint這個FPU指令,並且以inline assembly實作,在使用x86 CPU的Win32上的實作上大概長得像這樣:
inline double myDoubleRound(double dInput)
{
    double dResult;
    __asm__ (
        "frndint;": "=t" (dResult) : "0" (dInput)
    );

    return dResult;
}

順道一提的是,某些math.h中的round就是這樣寫的。

6. 一樣用inline assembly,我們用到了fld及fistp這兩個指令,程式碼如下:

inline int double2int(double dInput)
{
    int nResult = 0;
    __asm {
        fld dInput
        fistp nResult
    }
    return nResult;
}
其實在使用fistp之前應該要先用fldcw設定rounding的方式,可以設定為最近的int,或是floor/ceil等。

=========== 我是分隔線 ===========
現在讓我們來測試一下各種方法的效能如何,筆者使用的環境是Mac OS X 10.5.6(Intel)、GCC 4.0.1,compile參數為-O2 -fasm-blocks,每個方法呼叫100000000次,以-3.5做為input,測試結果如下:
Math.round:     0.048509 sec, result = -4
Math.nearbyint: 0.045757 sec, result = -4
myIntRound:     0.045828 sec, result = -4
myDoubleRound:  0.045824 sec, result = -4
myFloorRound:   0.045940 sec, result = -4
double2int:     0.222163 sec, result = -4

前面的5種方法速度都在誤差範圍內,只有double2int的速度特別慢,這件事告訴我們:拔獅子的鬃毛不一定會長出頭髮,就算用inline assembly也不一定會比較快!另外不知道是不是筆者的compiler特別愛作怪,inline assembly加上volatile甚至還會拖慢,以myDoubleRound來說好了,我在__asm__後面加上__volatile__,測試結果竟然要0.457702 sec,足足慢了10倍!

小小做個總結好了,其實C語言有很多不起眼卻可以探討的主題,翻一翻GCC的code也可以挖到不少寶。以四捨五入來說,每種方法都各有優缺點,使用math.h的方法最容易實作,卻也會讓program image變大;使用myIntRound的方法如果回傳後是塞到double就需要cast的effort;採用myDoubleRound的方法需要FPU指令。要使用何種方法就見人見智囉。