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