2010年8月29日 星期日

替MBP換裝新硬碟

MBP的250GB的硬碟快不夠用了, 加上, 這顆原廠出貨隨機的硬碟似乎不快, 所以昨天心一橫就去買了顆Seagate Momentus XT

這顆硬碟是顆SSD hybrid的硬碟, on board有4G SSD, 依照Seagte的說法是會針對常用的資料做最佳化, 但價格還真是高呀, 雖然沒真正的SSD高貴但也比一般2.5 inch的硬碟高出一倍, 不過我心想還是速度快一點比較好, 畢竟以一個軟體工程師來說, 電腦太慢是種痛苦

Tom's hardware的review

查過一些討論, 除了快以外, 對於這顆的評價不外乎是震動, 7200RPM的速度, 我想震動應該挺正常

首先, 安裝前得備份舊資料, 不過在網路上搜尋到的資料, 大多都用Timemachine備份還原, 由於我手邊並沒有夠大的硬碟來備份, 所以我只好用clone的, 所幸找到這個免費軟體 Carbon Copy Cloner

接上外接硬碟後就可以把原本電腦內的硬碟跟新硬碟做一對一copy....真是方便

硬體的拆解就要參考ifixit網站了: Installing MacBook Pro 13" Unibody Hard Drive Replacement

有個工具一定要有的, 那就是六角星形的起子(規格T6), 為了找這起子折騰了我一整天, 沒這起子就無法把硬碟上的四顆支架螺絲打開

上面那組還特別去五十元商店買的, 找了兩家五金行還找不到... = ="

拆解出的MBP像這樣, 其實還有些灰塵, 順便做清潔吧...

就是他了, 傳說中的硬碟, 不過是made in China就是了

拔下來的舊250GB HD是Fujisu的

 

換裝後

第一次開機, 開到login畫面前, 沒明顯感覺變快了, 但login之後, 哇~~~平常沒這麼快呀!!!

第二次開機, 真的都有比較快了

試了幾個平常要開很久的程式: Aperture, Eclipse, Starcraft 2....Aperture以前開是每次都讓我等了很久, 結果換裝硬碟後, 開的速度讓我有驚豔到, 一下子就冒出來了, 感覺比以前快了十倍, Eclipse第一次開, 開到workspace等他build完workspace感覺是有比以前快但沒快很多, 但第二次開之後, 越開越快, 真的是名副其實, SC2呢?以往都人家等我load地圖...結果今天居然我變成會等人家, 真是讓我訝異呀

至於網路上說的震動問題, 在我還沒鎖上支架螺絲前, 的確很明顯的微震動, 有點不舒服, 鎖上之後....根本完全沒感覺, 硬碟運轉時熱量應該跟舊的相當, 也很安靜, 平常就算貼近電腦也聽不到聲音, 硬碟全速運轉時才會聽到一點點嘰嘰的聲音(但要耳朵貼近)

雖然貴, 似乎很值得, 多用幾天應該會更明顯吧...

2010年8月28日 星期六

人生無常

這週岳母突然中風送加護實在是很突然,不過也能感受到人生無常,很多事都有可能發生的很突然
回到家被老爸數落了一番,我能體諒他們這年紀所面臨的,或許我陪他們太少了,不過其實也對他們之前沒讓我知道阿公送急診的事,之前突然接到外婆的過世通知很突然,但真正難過的是到她過世我才知道她已經住院了好幾個月,一直對在她生前住院沒能去看她耿耿於懷,雖然我一直沒說出來
後來想到了瑋筌,他爸爸倒的也很突然,很多未知在他爸爸倒下後接二連三襲來,這時讓我想到當一個他的leader我只有簽簽他的假單,卻沒去幫他打打氣,於是想到找Sam一起去,但大家也都非常想去,所以整個部門一起去
說實在的,我也不知道該說什麼,只能儘可能的幫他跟他媽媽加油打氣,發現他們都好堅強,尤其是瑋筌,受到如此打擊還是很可靠的當了全家支柱,真佩服他
人生變化無常,實在很難預料老天那天要我們做啥,能夠把握當下才是重要的吧! 祝福所有人

2010年8月27日 星期五

[Android] 謹慎使用Bitmap來避免OutOfMemoryError

一般行動裝置像是手機, 記憶體(RAM)是有限的, 不像PC上可以動不動就有2G以上的記憶體可用, 既然是這樣, 在手機上就不可能任意隨我們揮霍記憶體, 在Android上, 對每個程式能使用的記憶體也有其限制, 每隻程式, 能用的Java heap, 除非手機廠商有特別改過, 要不然HVGA的裝置一支程式就只能使用16MB的Java Heap, WVGA則只能使用32MB

通常佔用記憶體一個很大的元兇就是圖, 圖在載入顯示後, 在記憶體中是未經壓縮的Bitmap, 所以佔用了相當大的heap空間,而且在開發初期不太容易注意到這問題, 除非開發初期你就是碰巧拿到一張很大的圖擋(比如說千萬像素級相機拍的照片, 一般手機尚未有千萬以上等級, 所以單用手機拍的照片, 還真不容易試到問題)

當然, 把圖片縮小就是一個最直覺的解法

翻了API doc你可能會發現Bitmap裡面有個method是用來做rescale bitmap用的:

 

public static Bitmap createScaledBitmap (Bitmap src, int dstWidth, int dstHeight, boolean filter)

 

但其實, 這method並不適用節省memory這目的, 他本身有個陷阱, 也就是你必須要先載入一張原始圖, 才能針對這張圖檔做rescale的動作, 所以除了原始圖外還會有一份縮好的圖檔, 反而更佔空間

正確的解法是, 你必須要從檔案載入時就已經先把它縮小了, 

 

        //Only decode image size. Not whole image

        BitmapFactory.Options option = new BitmapFactory.Options();

        option.inJustDecodeBounds = true;

        BitmapFactory.decodeFile(imagePath, option);

 

        //The new size to decode to 

        final int NEW_SIZE=100;

 

        //Now we have image width and height. We should find the correct scale value. (power of 2)

        int width=option.outWidth;

        int height=option.outHeight;

        int scale=1;

        while(true){

            if(width/2<NEW_SIZE || height/2<NEW_SIZE)

                break;

            width/=2;

            height/=2;

            scale++;

        }

        //Decode again with inSampleSize

        option = new BitmapFactory.Options();

        option.inSampleSize=scale;

        return BitmapFactory.decodeFile(imagePath, option);

 

BitmapFactory可以在載入圖時指定scale的比例, 這樣載入後就不會是原先的大圖了, 缺點是, 要decode兩次, 第一次要使用option.inJustDecodeBounds = true; 讓它不是decode整張圖而是只取得圖的寬高, 第二次才是真正把整張圖decode放到記憶體內, 第二個缺點是, 它的scale算法是以1/2的次方, 沒辦法剛好是你指定的大小

如果把這方式跟createScaledBitmap加起來應用, 那就可以在不造成OutOfMemoryError狀況下, 又可以取得一張符合程式需要顯示大小的圖片了