昨天我們說(shuō)到HTC發(fā)布了新系統(tǒng)Brew MP新機(jī)Smart(昨日回顧),今天小編搜集到了這款新機(jī)的真機(jī)圖,以及一段試玩視頻,下面為大家奉上:
隨著舉世矚目的美國(guó)國(guó)際消費(fèi)電子大展CES2010在美國(guó)拉斯維加斯展覽中心拉開帷幕,各大手機(jī)巨頭都紛紛展示了自己在新年里的第一款機(jī)型。除了東道主摩托羅拉發(fā)布全球首款后翻蓋手機(jī)之外,HTC也在本次展會(huì)上正式推出了旗下首款Brew Mobile Platform(Brew MP)系統(tǒng)新機(jī)HTC Smart。 眾所周知,HTC過(guò)去推出的智能手機(jī)Windows Mobile和 Android系統(tǒng)為主,而這次問(wèn)世的HTC Smart則是HTC在智能手機(jī)系統(tǒng)領(lǐng)域的又一次新的嘗試。所謂的Brew Mobile Platform(Brew MP)系統(tǒng)平臺(tái)是高通公司在去年推出的移動(dòng)操作系統(tǒng)平臺(tái),可支持幾乎所有流通于市場(chǎng)上及使用各種3G技術(shù)的手機(jī)與移動(dòng)裝置。借助Brew移動(dòng)平臺(tái)軟件開發(fā)套件可以讓軟件開發(fā)商與設(shè)計(jì)者輕易地為手機(jī)與手持移動(dòng)裝置打造新的應(yīng)用軟件、Widgets工具應(yīng)用程序以及定制的操作接口。不過(guò),由于市場(chǎng)定位的緣故,HTC Smart在整體功能配置上并沒(méi)有表現(xiàn)出多少過(guò)人之處,裝載的是2.8英寸QVGA分辨率觸控屏,內(nèi)置300萬(wàn)像素?cái)z像頭,但沒(méi)有提供自動(dòng)聚焦功能,至于3.5毫米耳機(jī)接口、藍(lán)牙技術(shù)和存儲(chǔ)卡擴(kuò)展等功能還是一應(yīng)俱全。
至于人們比較關(guān)心的手機(jī)處理器規(guī)格方面,該款手機(jī)或許也會(huì)讓你感到失望。HTC Smart這次內(nèi)置的是300MHz處理器,同時(shí)256MB的RAM與256MB ROM的存儲(chǔ)組合也似乎讓人回到了過(guò)去。盡管該機(jī)支持GSM/WCDMA/HSDPA網(wǎng)絡(luò),可提供3.6Mbps的高速下行速率,但卻比較遺憾的沒(méi)有具備WLAN無(wú)線局域網(wǎng)功能,在整體實(shí)力上只能用乏善可陳來(lái)形容。不過(guò),HTC 這次為該機(jī)搭載了頗受好評(píng)的 HTC Sense 接口,其所提供的“HTC Scene”的功能,可讓用戶儲(chǔ)存桌面樣式設(shè)置到不同環(huán)境,并能夠隨意切換。并且在聯(lián)系人部分也支持完整的檢索功能,包括最近與該聯(lián)系人的通話記錄、短信、電子郵件等等,甚至還支持與 Facebook 的整合。
HTC Smart的機(jī)身尺寸104×55 ×12.8 mm ,重108克,在配備1100毫安時(shí)電池的情況下,可獲得600小時(shí)的待機(jī)時(shí)間(WCDMA)和370分鐘的連續(xù)通話時(shí)間(WCDMA)。據(jù)悉,該款手機(jī)將于今年春天僅在歐洲和亞洲上市銷售,但HTC沒(méi)有公布其零售價(jià)格。但根據(jù)官方表示將會(huì)讓手機(jī)的價(jià)格更具競(jìng)爭(zhēng)力的說(shuō)法來(lái)看,HTC Smart的銷售價(jià)格應(yīng)該會(huì)比較的便宜。
golf分析的很透徹阿。不過(guò)我認(rèn)為還應(yīng)該加上一點(diǎn)。聯(lián)通對(duì)于BREW的定位不明確。可以說(shuō)還沒(méi)想好怎么利用brew
現(xiàn)在有這么多行業(yè)需求(公安工商銀行行政等傳統(tǒng)的就不多說(shuō)了。其他的醫(yī)療教育等也是很有潛力的),卻沒(méi)有任何行業(yè)應(yīng)用。我覺得:BREW的發(fā)展靠的是渠道用戶和行業(yè)用戶。而不僅僅依靠個(gè)人用戶。
舉個(gè)簡(jiǎn)單的例子好了,2001-2002年時(shí)中國(guó)的國(guó)產(chǎn)手機(jī)怎么樣?一個(gè)字:爛!
價(jià)格和同樣性能的產(chǎn)品相比,又非常高。
那么銷量呢?卻又非常出色?
正是如此的銷量使得部分有實(shí)力的手機(jī)廠商可以發(fā)展,到目前這個(gè)規(guī)模。
這種現(xiàn)象絕對(duì)不失偶然的,主要還是歸功于銷售渠道的問(wèn)題。只要有了良好的銷售渠道,brew必然發(fā)展。
所幸的是聯(lián)通也意識(shí)到了這種情況,目前準(zhǔn)備籌劃一個(gè)類似于高交會(huì)的活動(dòng),把開發(fā)商和行業(yè)用戶直接安排見面。對(duì)開發(fā)商是機(jī)會(huì),對(duì)行業(yè)用戶來(lái)說(shuō)是solution。
壟斷總是有的,不過(guò)我覺得這是技術(shù)上的壟斷。目前TI、Nokia、Sony-Ericsson等都和Qualcomm簽訂了技術(shù)授權(quán)。使得WCDMA的核心專利權(quán)被完全的掌握在Qualcomm手中。
恐怕以后只要沾CDMA邊的技術(shù)(我們自己的標(biāo)準(zhǔn)TD-CDMA很不幸得是已經(jīng)和Qualcomm簽了專利互換協(xié)議……)都要向Qualcomm交錢……
Qualcomm的MSM7000系列芯片還內(nèi)置了ATI的3D顯示芯片……哎~恐怖啊~
以三星sch 339來(lái)說(shuō),可以用神奇寶典,但不能顯示很多游戲,因?yàn)楝F(xiàn)在針對(duì)這款手機(jī)所制做的軟件并不多。所以顯示的游戲或軟件和其他手機(jī)比起來(lái)不是很多。
現(xiàn)在游戲最多的應(yīng)該是京瓷 KZ 820和LG CU8280,8280和8188、8180是一樣的,在這4款手機(jī)中,KZ 820 屏幕遠(yuǎn)比不上LG 8180和LG 8188,和8280比就更差了。而其他支持Brew的手機(jī)雖然多,但目前有的軟件和游戲并不多。和以上所說(shuō)的機(jī)型一比就是大巫見小巫了。
這里推薦選購(gòu)8180手機(jī),和81880相比,價(jià)錢便宜了好多,而功能完全一樣。而8280相比之下雖然屏幕效果好很多,但也貴很多。如果需要經(jīng)常換待機(jī)畫面和鈴聲的話,8280是不錯(cuò)的選擇。用彩E把圖片和鈴聲發(fā)給8280,就可以免費(fèi)下圖片和鈴聲了。
在使用神奇寶典的時(shí)候,可以下載神奇小鏡子,讓屏幕變成鏡子,和三洋 580的特色功能一樣,不過(guò)可能效果稍有不如,也可以下載迷你卡拉OK,讓手機(jī)變成卡拉ok,也讓手機(jī)有moto V730的功能 ^_^.還有好多好玩的游戲等著你去玩呢。剩下的就看你的手機(jī)電池能堅(jiān)持多長(zhǎng)時(shí)間了:)
]]>移植應(yīng)注意的常見問(wèn)題:
在多個(gè)真機(jī)進(jìn)行程序的移植時(shí) 建議最好是能查閱手機(jī)的DDS參數(shù)表,了解相關(guān)參數(shù)設(shè)置避免以后工作的累贅重復(fù)
并在移植時(shí)進(jìn)行移植機(jī)型的實(shí)際測(cè)試。
1.屏幕尺寸、色深(最基礎(chǔ)的考慮東東)
2.按鍵定義 (AVK_SOFT2)注意不同手機(jī)定義
3.字體的大小對(duì)UI界面的影響
4.SUSPEND事件的處理方式
5.某些API接口是否支持,及限制
6.屏幕的刷新速度不同
7.手機(jī)的CPU處理能力不同
8.手機(jī)的堆棧,內(nèi)存, Flash大小差別明顯
9.手機(jī)本身的軟硬件問(wèn)題.
對(duì)于圖片和鈴聲產(chǎn)品,則更需要注意如下幾個(gè)問(wèn)題:
1.墻紙?jiān)O(shè)置的位置、張數(shù)、圖片格式(譬如超低端手機(jī)CU-Huawei C2281只支持
bmp)、設(shè)置的過(guò)程(譬如最新推出的一個(gè)款手機(jī)LG KG90C在設(shè)置墻紙時(shí)就會(huì)多
一個(gè)步驟如果不注意,則會(huì)產(chǎn)生刪除不同步的問(wèn)題)
]]>
HTC新款Verizon定制Android手機(jī)現(xiàn)身
HTC快速啟動(dòng)技術(shù) Android手機(jī)5秒開機(jī)
HTC昨日在英國(guó)召開了新品發(fā)布會(huì),發(fā)布Desire HD 和Desire Z 兩款手機(jī)!
]]>學(xué)習(xí)研究.NET早期經(jīng)常碰到些學(xué)習(xí)C#/.NET朋友問(wèn)要屬性這種華而不實(shí)東西做什么?后來(lái)做項(xiàng)目時(shí)也時(shí)常接到team里人抱怨反饋為什么不直接放個(gè)public字段?如:
Card
{
public Name;
}
而非要做個(gè)private字段+public屬性?
Card
{
private name;
public Name
{
get { this.name;}
{ this.name=value;}
}
}
我記得在早期個(gè)項(xiàng)目里team中個(gè)朋友甚至厭煩了寫private字段+public屬性尤其是碰到大堆臃腫data object 時(shí)候索性自己寫了個(gè)小工具來(lái)提供個(gè)類字段名和類型然后自動(dòng)為該類生成相應(yīng)private字段+public屬性
我在編程時(shí)候是個(gè)徹底實(shí)用主義者用稍微高雅點(diǎn)話說(shuō)叫“不喜歡過(guò)度設(shè)計(jì)”如果真像上面那樣寫Card而且在將來(lái)沒(méi)有什么改變需求我也不喜歡像上面第2段那樣把事情故意搞得復(fù)雜但如果從component角度來(lái)講總有些是要供外部長(zhǎng)久地使用也潛在地在將來(lái)有被改變需求這時(shí)候提供屬性就很有必要了
這就是這個(gè)Item試圖要?dú)w納使用屬性理由:
1.可以對(duì)賦值做校驗(yàn)、或者額外處理
2.可以做線程同步
3.可以使用虛屬性、或者抽象屬性
4.可以將屬性置于erface中
5.可以提供get-only或者-only版本甚至可以給讀、寫以區(qū)別訪問(wèn)權(quán)限(C# 2.0支持)
個(gè)人感覺3、4條是屬性最大優(yōu)點(diǎn)可以填補(bǔ)沒(méi)有“虛字段”或“抽象字段”缺憾在設(shè)計(jì)組件時(shí)候非常有用也體現(xiàn)了C#這樣component-oriented語(yǔ)言精神內(nèi)涵
但如果沒(méi)有上述理由而且日后對(duì)做大改動(dòng)可能性比較小時(shí)我想也大可不必非要把每個(gè)public字段都要變成屬性比如在設(shè)計(jì)些輕型struct用于互操作時(shí)候直接使用public字段沒(méi)什么不好所以感覺本條目Bill Wagner先生使用“Always Use Properties Instead of Accessible Data Members”顯得太過(guò)強(qiáng)硬
其實(shí)這里討論也表明閱讀Effective C#書時(shí)需要注意地方即Effective原則并不是放的 4海而皆準(zhǔn)區(qū)別項(xiàng)目(組件化、復(fù)用程度較高項(xiàng)目?還是“次編寫、N年都run”項(xiàng)目)區(qū)別角色(類庫(kù)/組件開發(fā)人員?還是應(yīng)用開發(fā)人員?)有著區(qū)別Effective準(zhǔn)則事實(shí)上書中很多Items都是從類庫(kù)/組件開發(fā)人員角度來(lái)考慮
有關(guān)屬性性能問(wèn)題需要談點(diǎn)如果僅僅是簡(jiǎn)單地以存取模式來(lái)使用屬性在相當(dāng)程度上是沒(méi)有性能損失在JIT編譯過(guò)程中已經(jīng)做了inline處理不過(guò)inline處理還是有些基本條件有些情況下JIT編譯器不會(huì)inline比如虛思路方法IL代碼長(zhǎng)度過(guò)長(zhǎng)(目前CLR規(guī)定是超過(guò)32s為代碼長(zhǎng)度過(guò)長(zhǎng))有復(fù)雜控制流邏輯有異常處理等這些條件都是要么根本不能使用inline(比如虛屬性)要么inline代價(jià)太大容易導(dǎo)致代碼bloat要么是inline起來(lái)很費(fèi)時(shí)間——已經(jīng)喪失了inline意義.NETinline機(jī)制發(fā)生在JIT過(guò)程中使用屬性有個(gè)別讓人感覺不舒服地方比如它影響開發(fā)人員開發(fā)效率但對(duì)代碼運(yùn)行效率不產(chǎn)生影響
明辨值類型和引用類型使用場(chǎng)合
這個(gè)條款討論是類型設(shè)計(jì)時(shí)候tradeoff——是將類型設(shè)計(jì)為結(jié)構(gòu)還是類Bill Wagner先生給出了個(gè)原則“值類型用于存儲(chǔ)數(shù)據(jù)引用類型用于定義行為(value types store values and reference types behavior)”
如何判斷這個(gè)原則適用性Bill Wagner也給出了個(gè)思路方法那就是首先回答下面幾個(gè)問(wèn)題:
1.該類型主要職責(zé)是否用于數(shù)據(jù)存儲(chǔ)?
2.該類型公有接口是否都是些存取屬性?
3.是否確信該類型永遠(yuǎn)不可能有子類?
4.是否確信該類型永遠(yuǎn)不可能具有多態(tài)行為?
如果所有問(wèn)題答案都是yes那么就應(yīng)該采用值類型這樣判斷確實(shí)有很好理由支撐但是我個(gè)人認(rèn)為“將這4個(gè)問(wèn)題回答為yes”還不足以構(gòu)成采用值類型全部理由在很多項(xiàng)目實(shí)戰(zhàn)中我發(fā)現(xiàn)值類型帶來(lái)性能問(wèn)題不可小視值類型帶來(lái)性能問(wèn)題主要有兩個(gè):
1.由于值類型例子在棧和托管堆的間轉(zhuǎn)換而導(dǎo)致box/unbox以及由此帶來(lái)托管堆上垃圾
2.值類型默認(rèn)情況下采用是值拷貝語(yǔ)義如果是比較大值類型在傳遞參數(shù)和返回值時(shí)同樣會(huì)帶來(lái)性能問(wèn)題
有關(guān)第1條Bill Wagner在本條款中提到了“引用類型會(huì)給垃圾收集器帶來(lái)負(fù)擔(dān)”這個(gè)表面看似正確判斷但是由于box/unbox效應(yīng)有些情況下反倒是值類型給垃圾收集器帶來(lái)了更多負(fù)擔(dān)比如將些值類型放到個(gè)集合中然后又頻繁地對(duì)其進(jìn)行讀寫操作如果碰到這種情況我想“放棄結(jié)構(gòu)而采用類”未嘗不是種更好做法事實(shí)上將個(gè)用作數(shù)據(jù)存儲(chǔ)值類型(比如.Drawing.Po)添加到個(gè)集合(.Collections.ArrayList)中是個(gè)太常見不過(guò)操作不過(guò)C# 2.0中新引入泛型技術(shù)對(duì)box/unbox問(wèn)題有極大改善
有關(guān)第2條Scott Meyers先生在Effective C第22條“盡量使用pass-by-reference(傳址)少用pass-by-value(傳值)”中講比較清楚雖然由于C#中結(jié)構(gòu)類型具有默認(rèn)深拷貝語(yǔ)義沒(méi)有拷貝構(gòu)造器而且結(jié)構(gòu)類型也沒(méi)有子類因此在某種程度上來(lái)講不具有多態(tài)性也就沒(méi)有C對(duì)象傳值時(shí)可能出現(xiàn)切割(slicing)效應(yīng)但是值拷貝成本仍然不小尤其是在這個(gè)值類型比較大情況下問(wèn)題就比較嚴(yán)重實(shí)際上在.NET框架Design Guidelines for Class Library Developers文檔中在介紹說(shuō)明什么時(shí)候應(yīng)該使用結(jié)構(gòu)類型時(shí)候其中提到了項(xiàng)原則(還有其他些并行原則)——類型例子數(shù)據(jù)大小要小于16個(gè)字節(jié)該文檔主要是從類型運(yùn)行效率層面來(lái)考慮而Bill Wagner先生這里條款主要是從類型設(shè)計(jì)層面來(lái)考慮
從上述兩條討論來(lái)看我個(gè)人傾向于對(duì)結(jié)構(gòu)類型采取更為保守設(shè)計(jì)策略而對(duì)于類則可以積極大膽地使用“將結(jié)構(gòu)類型不適當(dāng)?shù)卦O(shè)計(jì)為類”帶來(lái)不良后果要遠(yuǎn)遠(yuǎn)小于“將類不適當(dāng)?shù)卦O(shè)計(jì)為結(jié)構(gòu)類型”所帶來(lái)不良后果就目前經(jīng)驗(yàn)來(lái)看我甚至認(rèn)為只有和非托管互操作打交道情況才是使用結(jié)構(gòu)類型最充足理由其他情況都要“ 3思而后行”當(dāng)然在C# 2.0中引入泛型技術(shù)的后box/unbox將不再是個(gè)沉重負(fù)擔(dān)應(yīng)付些非常輕量級(jí)場(chǎng)合結(jié)構(gòu)類型依然有自己席的地
]]>
TOP
以下內(nèi)容含腳本,或可能導(dǎo)致頁(yè)面不正常的代碼 |
---|
說(shuō)明:上面顯示的是代碼內(nèi)容。您可以先檢查過(guò)代碼沒(méi)問(wèn)題,或修改之后再運(yùn)行. |