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