by Dianne Hackborn

(Edit: there have been a number of comments treating this as being written as an excuse for Android or not mattering to users or such. I’d just like to clarify that I wrote this solely to address a lot of incorrect information that I see posted around [...]]]> https://plus.google.com/105051985738280261832/posts/2FXDCz8x93s

by Dianne Hackborn

How about some Android graphics true facts?

(Edit: there have been a number of comments treating this as being written as an excuse for Android or not mattering to users or such. I’d just like to clarify that I wrote this solely to address a lot of incorrect information that I see posted around the web as truth. This is no attempt to excuse anything, and it is solely for those who already have an interest in writing and reading the often factually incorrect technical information out there.)

I get tired of seeing so much misinformation posted and repeated all over the place about how graphics rendering works on Android. Here is some truth:

• Android has always used some hardware accelerated drawing. Since before 1.0 all window compositing to the display has been done with hardware.

• This means that many of the animations you see have always been hardware accelerated: menus being shown, sliding the notification shade, transitions between activities, pop-ups and dialogs showing and hiding, etc.

• Android did historically use software to render the contents of each window. For example in a UI likehttp://www.simplemobilereview.com/wp-content/uploads/2010/12/2-home-menu.png there are four windows: the status bar, the wallpaper, the launcher on top of the wallpaper, and the menu. If one of the windows updates its contents, such as highlighting a menu item, then (prior to 3.0) software is used to draw the new contents of that window; however none of the other windows are redrawn at all, and the re-composition of the windows is done in hardware. Likewise, any movement of the windows such as the menu going up and down is all hardware rendering.

• Looking at drawing inside of a window, you don’t necessarily need to do this in hardware to achieve full 60fps rendering. This depends very much on the number of pixels in your display and the speed of your CPU. For example, Nexus S has no trouble doing 60fps rendering of all the normal stuff you see in the Android UI like scrolling lists on its 800×480 screen. The original Droid however struggled with a similar screen resolution.

• "Full" hardware accelerated drawing within a window was added in Android 3.0. The implementation in Android 4.0 is not any more full than in 3.0. Starting with 3.0, if you set the flag in your app saying that hardware accelerated drawing is allowed, then all drawing to the application’s windows will be done with the GPU. The main change in this regard in Android 4.0 is that now apps that are explicitly targeting 4.0 or higher will have acceleration enabled by default rather than having to put android:handwareAccelerated="true" in their manifest. (And the reason this isn’t just turned on for all existing applications is that some types of drawing operations can’t be supported well in hardware and it also impacts the behavior when an application asks to have a part of its UI updated. Forcing hardware accelerated drawing upon existing apps will break a significant number of them, from subtly to significantly.)

• Hardware accelerated drawing is not all full of win. For example on the PVR drivers of devices like the Nexus S and Galaxy Nexus, simply starting to use OpenGL in a process eats about 8MB of RAM. Given that our process overhead is about 2MB, this is pretty huge. That RAM takes away from other things, such as the number of background processes that can be kept running, potentially slowing down things like app switching.

• Because of the overhead of OpenGL, one may very well not want to use it for drawing. For example some of the work we are doing to make Android 4.0 run well on the Nexus S has involved turning off hardware accelerated drawing in parts of the UI so we don’t lose 8MB of RAM in the system process, another 8MB in the phone process, another 8MB in the system UI process, etc. Trust me, you won’t notice — there is just no benefit on that device in using OpenGL to draw something like the status bar, even with fancy animations going on in there.

• Hardware accelerated drawing is not a magical silver bullet to butter-smooth UI. There are many different efforts that have been going on towards this, such as improved scheduling of foreground vs. background threads in 1.6, rewriting the input system in 2.3, strict mode, concurrent garbage collection, loaders, etc. If you want to achieve 60fps, you have 20 milliseconds to handle each frame. This is not a lot of time. Just touching the flash storage system in the thread that is running the UI can in some cases introduce a delay that puts you out of that timing window, especially if you are writing to storage.

• A recent example of the kinds of interesting things that impact UI smoothness: we noticed that ICS on Nexus S was actually less smooth when scrolling through lists than it was on Gingerbread. It turned out that the reason for this was due to subtle changes in timing, so that sometimes in ICS as the app was retrieving touch events and drawing the screen, it would go to get the next event slightly before it was ready, causing it to visibly miss a frame while tracking the finger even though it was drawing the screen at a solid 60fps. (Edit: for those who need this made clear, yes of course this particular issue is fixed.)

• When people have historically compared web browser scrolling between Android and iOS, most of the differences they are seeing are not due to hardware accelerated drawing. Originally Android went a different route for its web page rendering and made different compromises: the web page is turned in to a display list, which is continually rendered to the screen, instead of using tiles. This has the benefit that scrolling and zooming never have artifacts of tiles that haven’t yet been drawn. Its downside is that as the graphics on the web page get more complicated to draw the frame rate goes down. As of Android 3.0, the browser now uses tiles, so it can maintain a consistent frame rate as you scroll or zoom, with the negative of having artifacts when newly needed tiles can’t be rendered quickly enough. The tiles themselves are rendered in software, which I believe is the case for iOS as well. (And this tile-based approach could be used prior to 3.0 without hardware accelerated drawing; as mentioned previously, the Nexus S CPU can easily draw the tiles to the window at 60fps.)

• Hardware accleration does not magically make drawing performance problems disappear. There is still a limit to how much the GPU can do. A recent interesting example of this is tablets built with Tegra 2 — that GPU can touch every pixel of a 1280×800 screen about 2.5 times at 60fps. Now consider the Android 3.0 tablet home screen where you are switching to the all apps list: you need to draw the background (1x all pixels), then the layer of shortcuts and widgets (let’s be nice and say this is .5x all pixels), then the black background of all apps (1x all pixels), and the icons and labels of all apps (.5x all pixels). We’ve already blown our per-pixel budget, and we haven’t even composited the separate windows to the final display yet. To get 60fps animation, Android 3.0 and later use a number of tricks. A big one is that it tries to put all windows into overlays instead of having to copy them to the framebuffer with the GPU. In the case here even with that we are still over-budget, but we have another trick: because the wallpaper on Android is in a separate window, we can make this window larger than the screen to hold the entire bitmap. Now, as you scroll, the movement of the background doesn’t require any drawing, just moving its window… and because this window is in an overlay, it doesn’t even need to be composited to the screen with the GPU.

• As device screen resolution goes up, achieving a 60fps UI is closely related to GPU speed and especially the GPU’s memory bus bandwidth. In fact, if you want to get an idea of the performance of a piece of hardware, always pay close attention to the memory bus bandwidth. There are plenty of times where the CPU (especially with those wonderful NEON instructions) can go a lot faster than the memory bus.

EDIT:

Wow this has generated a lot more discussion, and I won’t be able to address nearly everything that has been raised. But I’ll try to expand on things a bit here to better address what I think are some of the more interesting points.

Some have raised points along the lines of Samsung Galaxy S2 phones already having a smoother UI and indicating that they are doing something different vs. the Galaxy Nexus. When comparing individual devices though you really need to look at all of the factors. For example, the S2′s screen is 480×800 vs. the Galaxy Nexus at 720×1280. If the Nexus S could already do 60fps for simple UIs on its 480×800, the CPU in the S2′s is even better off.

The real important difference between these two screens is just that the Galaxy Nexus has 2.4x as many pixels that need to be drawn as the S2. This means that to achieve the same efficiency at drawing the screen, you need a CPU that can run a single core at 2.4x the speed (and rendering a UI for a single app is essentially not parallelizable, so multiple cores isn’t going to save you).

This is where hardware accelerated rendering really becomes important: as the number of pixels goes up, GPUs can generally scale much better to handle them, since they are more specialized at their task. In fact this was the primary incentive for implementing hardware accelerated drawing in Android — at 720×1280 we are well beyond the point where current ARM CPUs can provide 60fps. (And this is a reason to be careful about making comparisons between the Galaxy Nexus and other devices like the S2 — if you are running third party apps, there is a good chance today that the app is not enabling hardware acceleration, so your comparison is doing CPU rendering on the Galaxy Nexus which means you almost certainly aren’t going to get 60fps out of it, because it needs to hit 2.4x as many pixels as the S2 does.)

To be complete, there is another big advantage that the GPU gives you — many more drawing effects become feasible. For example, if you are drawing a bitmap in software, you basically can’t do anything to it except apply an offset. Just trying to scale it is going to make rendering significantly slower. On a GPU, applying transformations well beyond simple scales is basically free. This is why in the new default Holo themes in Android we have background images — with hardware accelerated drawing, we can afford to draw (and scale) them. In fact, if the hardware path is not enabled by the app, these background images will be turned off.

[譯]關於Android圖形系統的一些事實真相

翻譯 by Ying Dai

現在網上滿天飛的各類關於Android圖像渲染的水文實在讓我不爽，下面給大家一些關於Android硬體渲染的事實真相，硬體加速並非大家想的那麼完美，而我們也一直在改進！

1. Android 一直在使用硬體加速。實際上從1.0版本之後，所有的視窗元素的合成與顯示都是通過硬體完成的。

2.這意味著許多你所看見的動畫都是被加速過的：按鈕的顯示、通知欄下拉的陰影、不同Activity之間的切換動畫、快顯視窗以及提示框的顯示和隱藏等等等等。

3.Android以前使用軟體方式(與硬體加速相對應)來控制各個視窗元素的渲染，例如下圖的UI，其中包括四個視窗元件：狀態條、壁紙、桌面上的的啟動器、以及菜單。如果其中一個元素更改了自身的內容，例如高亮一個功能表條目，對於3.0之前的版本，系統使用軟體方式來繪製新的內容，然而並非所有的元素都需要被重新繪製，同時各個視窗元素的拼接也是通過硬體方式完成的。類似的，任何視窗的移動：例如功能表的上下運動是完全通過硬體方式渲染的。

4. 現在我們來關注視窗元素的內部渲染，實際上為了達到每秒60幀的FPS,你並不一定需要硬體加速。幀速取決於要顯示的圖元的數量以及CPU的速度。比如說，二兒子完全可以以60FPS的速度在它800*480解析度的螢幕上完成任何普通的原生UI動畫，例如列表的滾動等，完全沒有問題。而最初的Droid系列卻很難達到這樣的速度。

5.在Android3.0中可以實現視窗的”完全”的硬體加速繪製。而在Android 4.0中也沒有引入更多的功能。 從3.0開始，如果在你的應用中設置了一個標誌允許硬體加速，那麼此時所有的視窗的繪製都會交給GPU來完成。在Android 4.0中最主要的改變就是：在面向Android4.0或更高版本的應用中，硬體加速是被預設開啟的，再也不需要在設定檔中設置 android:handwareAccelerated=”true”.(而我們不允許之前的應用預設打開硬體加速，是因為光靠硬體加速，無法很好的完成某些特殊的繪製操作；同時在應用需要其中一部分UI更新的時候，會影響其的一些表現。對於目前現有的很多應用，強制開啟硬體加速，會明顯的中斷應用的運行)

6.硬體加速並不如大家所認為的那樣完美。例如在基於PVR驅動的設備上(比如二兒子跟三兒子)，光是在進程中開啟OpenGL就得佔用8M的RAM。對比一般進程的2M的開銷實在是巨大。RAM是有限的，一大部分被拿去繪製，那麼其他正在運行的進程就會因為缺少記憶體而出問題，比如降低應用間切換的速度。

7.由於OpenGL的額外開銷，我們最好不要過多的使用其進行繪製。比如我們現在在做的一些工作，就是為了讓Android 4.0能在不使用硬體加速的情況下流暢的在二兒子上使用：這樣我們就不需要在系統進程中浪費8MB的記憶體用，也不需要在手機進程中浪費額外的8M記憶體，或者是在系統UI進程中的8MB記憶體 等等等等。相信我，你不會注意到——用OpenGL來繪製一些類似狀態列或是華麗的動畫是完全沒有好處的。

8.硬體加速並非流暢UI的“解藥”。我們為了UI的流暢嘗試了很多不同的方法，比如說在1.6中引入的對前臺/後臺進程的調度策略，在2.3中的對輸入系統的重寫，”嚴厲模式”的使用，併發的垃圾回收機制，載入器等等。如果你想達到60fps的幀速，你只有20毫秒的時間來處理每幀的內容。這時間實在不長，光是在UI進程中讀取存儲卡的操作產生的延時就會大於這個時限，尤其是在寫操作的時候。

9.舉些最近發現的一些影響UI流暢度的例子：我們注意到在二兒子上，使用4.0時列表的滾動就不如使用2.3時流暢。而導致這個現象的原因則是計時器的輕微漂移：有些時候應用正在接收觸摸事件並在螢幕上繪製，而在上一個動作還沒完成的的時候，就接受到下一個事件並開始繪製，導致它丟失了當前這幀。儘管發生這種現象的時候，幀速能達到穩定的60FPS.(當然，這個問題已經修正)

10.當人們比較Android跟IOS上流覽器的滾動流暢度的時候，他們所看見的差別並非開沒開啟硬體加速所導致。 最初的時候，Android使用了一種完全不同的渲染策略，並做了一些折中：網頁被轉換成一個”顯示清單“，持續的在螢幕上進行繪製，而非使用塊(Tiles)的形式。它有一個優點：就是在滾動或是縮放的時候不會發生有的塊還沒被渲染出來的現象(譯者注：早期的IOS上這種現象非常明顯，快速滾動到底部時要等一會網頁才會一塊一塊的繪製出來)。 而這個方法的不給力之處就在於頁面複雜的時候，幀速就明顯低了。例如Android3.0，流覽器中現在開始使用塊的方式進行渲染，於是它可以在滾動或是放大的時候保持一個穩定的幀速，自然也會出現新的塊沒有被立即渲染出來的情況。 而每個塊都是以軟體方式繪製的，我相信在IOS中也是這樣的。(在3.0之前的版本中，沒有開啟硬體加速，基於塊的策略也可以使用。而且如我之前提到的，二兒子可以很容易的達到60FPS)

11.硬體加速不能如大家所想奇跡般的讓繪製的問題統統消失。GPU的性能就是一個很重要的限制。最近一個很有趣的例子：基於英偉達的Tegra2的平板可以很容易的以60FPS的速度訪問2.5次1280*800解析度的螢幕中的任何一個圖元。現在考慮到在Android 3.0中切換到所有應用列表的情形：你需要繪製背景(1x 所有的圖元)、接著是快捷方式和桌面小工具(假設內容不多，花費0.5x)，接著是所有應用的黑色背景(1x)，接著是所有應用的ICON(0.5x)。顯然，我們已經超過了原先的預算了，而此時我們還沒完成各個獨立視窗元素的拼接並做最後的顯示。想要取得60FPS的動畫，Android 3.0以及後續版本使用了一系列的小技巧。 其中主要的一個就是： 它將所有的視窗元素平鋪在一個層中，而不是挨個拷貝到CPU的緩存中。但即使是這樣，我們已然超出預算，幸好我們使用另一個技巧：因為Android中的背景是一個獨立的視窗元素，我們可以將它設置的比螢幕更大來放置整幅點陣圖，現在，用戶開始滑動，背景跟著運動，此時並不需要任何特殊的繪製，僅僅是移動視窗即可，而由於這個視窗是在一個平鋪層上，我們甚至不需要用GPU來將這個視窗元素組織到螢幕中輸出。

12.隨著螢幕解析度的不斷升高，能否達到60FPS跟GPU的速度尤其是記憶體匯流排頻寬息息相關。事實上，如果你想要提升硬體的效力，特別注意要提升記憶體匯流排的頻寬。很多時候CPU(特別是帶有完美的NEON指令集的CPU)會比記憶體匯流排塊的多。

UPDATE：下面居然有這麼多討論，但是我木有能力解釋清楚相關的所有問題了。不過我會盡力在這裡提供一些我認為比較有趣的觀點。

有些人認為蓋世兔已經有了一個非常流暢的UI並指出他們已經超越三兒子並做了很多改進。事實上，大家忽略了很多設備的差異，蓋世兔的螢幕是480*800而三兒子是720*1280。如果二兒子在它480*800的螢幕上都能達到60FPS，擁有更NB的CPU的蓋世兔必須得同樣流暢嘛。

而兩者之間最大的差別就是三兒子需要同時繪製2.4倍於蓋世兔的圖元。這相當於在單核上提升到2.4倍的速度。(需要指出 在UI渲染的時候，多核是沒有意義的，因為渲染必須要在一個進程中完成，無法並行)

這就是為什麼硬體加速非常重要：隨著圖元的提升，GPU通常能更好的處理圖像的運算。事實上，這是我們在Android中引入硬體加速的最大動力。在720*1280的螢幕上，現有的ARM CPU達到60FPS很吃力，但是通過GPU渲染就不同了。同樣，在與蓋世兔的比較中，同時打開沒有硬體加速的應用，在三兒子中無法達到蓋世兔同樣的60FPS，是因為它得渲染2.4倍於蓋世兔的圖元。

在最後，還得提及GPU的另外一個優勢：許多繪製的效果變得更加容易。比如你要以軟體形式繪製一個點陣圖，你除了設置一個位移，不能做任何事。僅僅是縮小就得花上相當多的時間進行渲染。而在GPU中，此類轉換則相當容易。這就是為神馬新的預設主題Holo使用硬體加速繪製背景。而在沒有開啟硬體加速的應用中，此類背景會自動去掉~

原文地址：https://plus.google.com/105051985738280261832/posts/2FXDCz8x93s
(說明：後面的很多評論認為我寫這個只是為Android不如IOS卡亂找藉口或是不體貼用戶等等，我在這裡需要澄清一下：我之所以寫這篇文章，僅僅是為了糾正網上傳播的關於Android的各種錯誤認知。我並非是為了解釋什麼，只不過是想給那些關注Android卻又被網上各種錯誤認知困擾的童鞋提供參考)

People who looked at this item also looked at…

• Dianne Hackborn explain the Android MMI performance issues. #2
• ARM總裁：Medfield很好但是沒ARM好
• 聯想發第一款英特爾芯智慧手機LenovoK800
• 穀歌官方資料：Android 4.0僅占0.6%使用份額
• 英特爾發力，全面推動智慧手機、平板電腦和超極本創新

Related items

• Dianne Hackborn explain the Android MMI performance issues. #2
• 穀歌官方資料：Android 4.0僅占0.6%使用份額
• 手機作業系統之爭：為什麼穀歌快微軟慢
• 一位內核開發者的見聞
• Android 4.0遭破解 可在HTC G1中運行

Dianne Hackborn

A few days ago I wrote a post trying to correct a lot of the inaccurate statements I have seen repeatedly mentioned about how graphics on Android works. This resulted in a lot of nice discussion, but unfortunately has also lead some people to come up with new, novel, and often technically inaccurate complaints [...]]]> https://plus.google.com/105051985738280261832/posts/XAZ4CeVP6DC

Dianne Hackborn

A few days ago I wrote a post trying to correct a lot of the inaccurate statements I have seen repeatedly mentioned about how graphics on Android works. This resulted in a lot of nice discussion, but unfortunately has also lead some people to come up with new, novel, and often technically inaccurate complaints about how Android works.

These new topics have been more about some fundamental design decisions in Android, and why they are wrong. I’d like to help people better understand (and judge) these discussions by giving some real background on why Android’s UI was designed the way it is and how it actually works.

One issue that has been raised is that Android doesn’t use thread priorities to reduce how much background work interrupts the user interface. This is outright wrong. It actually uses a number of priorities, which you can even find defined right herehttp://developer.android.com/reference/android/os/Process.html#THREAD_PRIORITY_AUDIO in the SDK.

The most important of these are the background and default priorities. User interface threads normally run at the default priority; background threads run in the background priority. Application processes that are in the background have all of their threads forced to the background priority.

Android’s background priority is actually pretty interesting. It uses a Linux facility called cgroups to put all background threads into a special scheduling group which, all together, can’t use more than 10% of the CPU. That is, if you have 10 processes in the background all trying to run at the same time, when combined they can’t take away more than 10% of the time needed by foreground threads. This is enough to allow background threads to make some forward progress, without having enough of an impact on the foreground threads to be generally visible to the user.

(You may have noticed that a “foreground” priority is also defined. This is not used in current Android; it was in the original implementation, but we found that the Linux scheduler does not give enough preference to threads based on pure priority, so switched to cgroups in Android 1.6.)

I have also seen a number of claims that the basic Android design is fundamentally flawed and archaic because it doesn’t use a rendering thread like iOS. There are certainly some advantages to how iOS work, but this view is too focused on one specific detail to be useful, and glosses over actual similarities in how they behave.

Android had a number of very different original design goals than iOS did. A key goal of Android was to provide an open application platform, using application sandboxes to create a much more secure environment that doesn’t rely on a central authority to verify that applications do what they claim. To achieve this, it uses Linux process isolation and user IDs to prevent each application from being able to access the system or other application in ways that are not controlled and secure.

This is very different from iOS’s original design constraints, which remember didn’t allow any third party applications at all.

An important part of achieving this security is having a way for (EDIT: It has been pointed out to me that iOS does in fact use multiple windows and multiple GL contexts. Lesson to me, just don’t talk about anything I haven’t directly verified. That still doesn’t change things for Android, though, where as I mention later we simply did not have hardware and drivers that could do multiple GL contexts until fairly recently.)
individual UI elements to share the screen in a secure way. This is why there are windows on Android. The status bar and its notification shade are windows owned and drawn by the system. These are separate from the application’s window, so the application can not touch anything about the status bar, such as to scrape the text of SMS messages as they are displayed there. Likewise the soft keyboard is a separate window, owned by a separate application, and it and the application can only interact with each other through a well defined and controlled interface. (This is also why Android can safely support third party input methods.)

Another objective of Android was to allow close collaboration between applications, so that for example it is easy to implement a share API that launches a part of another application integrated with the original application’s flow. As part of this, Android applications traditionally are split into pieces (called “Activities”) that handle a single specific part of the UI of the application. For example, the contacts lists is one activity, the details of a contact is another, and editing a contact is a third. Moving between those parts of the contacts UI means switching between these activities, and each of these activities is its own separate window.

Now we can see something interesting: in almost all of the places in the original Android UI where you see animations, you are actually seeing windows animate. Launching Contacts is an animation of the home screen window and the contacts list window. Tapping on a contact to see its details is an animation of the contacts list window and the contacts details window. Displaying the soft keyboard is an animation of the keyboard window. Showing the dialog where you pick an app to share with is an animation of a window displaying that dialog.

When you see a window on screen, what you are seeing is actually something called a “surface”. This is a separate piece of shared memory that the window draws its UI in, and is composited with the other windows to the screen by a separate system service (in a separate thread, running at a higher than normal priority) called the “surface flinger.” Does this sound familiar? In fact this is very much like what iOS is doing with its views being composited by a separate thread, just at a less fine-grained but significantly more secure level. (And this window composition has been hardware accelerated in Android from the beginning.)

The other main interesting interaction in the UI is tracking your finger — scrolling and flinging a list, swiping a gallery, etc. These interactions involve updating the contents inside of a window, so require re-rendering that window for each movement. However, being able to do this rendering off the main thread probably doesn’t gain you much. These are not simple “move this part of the UI from X to Y, and maybe tell me when you are done” animations — each movement is based on events received about the finger on the screen, which need to be processed by the application on its main thread.

That said, being able to avoid redrawing all of the contents of the parts of the UI that are moving can help performance. And this is also a technique that Android has employed since before 1.0; UI elements like a ListView that want to scroll their content can callhttp://developer.android.com/reference/android/view/View.html#setDrawingCacheEnabled(boolean) to have that content rendered into a cache so that only the bitmap needs to be drawn as it moves.

Traditionally on Android, views only have their drawing cache enabled as a transient state, such as while scrolling or tracking a finger. This is because they introduce a fair amount more overhead: extra memory for the bitmap (which can easily total to multiple times larger than the actual frame buffer if there are a number of visual layers), and when the contents inside of a cached view need to be redrawn it is more expensive because there is an additional step required to draw the cached bitmap back to the window.

So, all those things considered, in Android 1.0 having each view drawn into a texture and those textures composited to the window in another thread is just not that much of a gain, with a lot of cost. The cost is also in engineering time — our time was better spent working on other things like a layout-based view hierarchy (to provide flexibility in adjusting for different screen sizes) and “remote views” for notifications and widgets, which have significantly benefited the platform as it develops.

In fact it was just not feasible to implement hardware accelerated drawing inside windows until recently. Because Android is designed around having multiple windows on the screen, to have the drawing inside each window be hardware accelerated means requiring that the GPU and driver support multiple active GL contexts in different processes running at the same time. The hardware at that time just didn’t support this, even ignoring the additional memory needed for it that was not available. Even today we are in the early stages of this — most mobile GPUs still have fairly expensive GL context switching.

I hope this helps people better understand how Android works. And just to be clear again from my last point — I am not writing this to make excuses for whatever things people don’t like about Android, I just get tired of seeing people write egregiously wrong explanations about how Android works and worse present themselves as authorities on the topic.

There are of course many things that can be improved in Android today, just as there are many things that have been improved since 1.0. As other more pressing issues are addressed, and hardware capabilities improve and change, we continue to push the platform forward and make it better.

One final thought. I saw an interesting comment from Brent Royal-Gordon on what developers sometimes need to do to achieve 60fps scrolling in iOS lists: “Getting it up to sixty is more difficult—you may have to simplify the cell’s view hierarchy, or delay adding some of the content, or remove text formatting that would otherwise require a more expensive text rendering API, or even rip the subviews out of the cell altogether and draw everything by hand.”

I am no expert on iOS, so I’ll take that as as true. These are the exact same recommendations that we have given to Android’s app developers, and based on this statement I don’t see any indication that there is something intrinsically flawed about Android in making lists scroll at 60fps, any more than there is in iOS.

People who looked at this item also looked at…

• 穀歌官方資料：Android 4.0僅占0.6%使用份額
• ARM總裁：Medfield很好但是沒ARM好
• 聯想發第一款英特爾芯智慧手機LenovoK800
• How about some Android graphics true facts?
• 英特爾發力，全面推動智慧手機、平板電腦和超極本創新

Related items

• How about some Android graphics true facts?
• 穀歌官方資料：Android 4.0僅占0.6%使用份額
• 手機作業系統之爭：為什麼穀歌快微軟慢
• 一位內核開發者的見聞
• Android 4.0遭破解 可在HTC G1中運行

http://tech.sina.com.cn/t/2012-01-05/11356604217.shtml

新浪科技訊 北京時間1月5日上午消息，穀歌週三發佈了Android系統各版本的最新市場份額資料。資料顯示，Android 4.0“冰淇淋三明治”系統仍未被太多用戶接受。 　　手機廠商在升級至最新版Android系統的過程中步伐緩慢。根據穀歌的資料，目前55.5%的已啟動Android設備採用Android 2.3“薑餅”系統。該版本系統的發佈已超過1年時間。另一方面，Android 4.0“冰淇淋三明治”系統在所有已啟動Android設備中僅占0.6%。 　　谷歌於2011年11月14日發佈了“冰淇淋三明治”系統。自那時以來，只有Galaxy Nexus、Nexus S和其他數款廉價平板電腦採用該系統。而在“冰淇淋三明治”系統發佈的一個月內，Galaxy Nexus甚至沒有在美國開始銷售。 　　與此相比，蘋果於2011年10月12日發佈了最新版的iOS 5。第三代和第四代iPod Touch、iPhone 3GS、iPhone 4、iPad和iPad 2的用戶隨後可以立即升級至該系統，而無需任何等待。 　　資料表明，目前大部分Android用戶使用“薑餅”系統。如果這些用戶希望升級至“冰淇淋三明治”，那麼要麼花費300美元購買一台Galaxy Nexus，要麼只能等待未來幾個月現有的手機支持最新版Android。(維金)

三星Galaxy S將無法支持Android 4.0

http://tech.sina.com.cn/mobile/n/2011-12-28/11516574709.shtml

　【賽迪網訊】12月28日消息，據三星官方消息，三星Galaxy S智慧手機將無法獲得穀歌Android 4.0作業系統，即“冰激淋三明治”的更新。 　　主要問題在於三星Galaxy S硬體方面的限制，因此不能在Android 4.0作業系統中使用自訂的TouchWiz使用者介面。 　　但是，與三星Galaxy S與Nexus S配置幾乎相似，但Android 4.0卻只能對Nexus S支持，這是因為Nexus S採用1GHz的Hummingbird 處理器並提供了足夠的記憶體來支援ICS的運行。

http://tech.sina.com.cn/t/2012-01-09/11276617440.shtml

《第一財經週刊》 同為智能手機的後入者，為什麼Google在3年間發佈9個重要版本，而微軟卻才有一個？ 　　文｜CBN記者 董曉常 　　最近Android用戶最關心的一件事可能就是三星(微博)宣佈Galaxy S不升級Android4.0了。因為大部分手機不能升級到最新系統是Android使用者最糾結的一件事情。為了解決這個問題，Google去年5月份聯合數家手機廠商和運營商發佈了一個公告，承諾18個月內新舊用戶都能升級到最新系統。三星這下算是把這個聯盟瓦解了。 　　不過這事不全是三星的問題，細說起來還是Google自己惹的禍。從2008年10月發佈了第一個官方版本以來，Android已經發佈了9個重大的版本。與蘋果iOS增加新功能的版本更替不同，Android每次版本更新基本上都是修改各種Bug。 　　在跟隨蘋果推出手機作業系統這件事上，Google表現得像是個衝動無比的年輕人：看起來沒有做好準備，倉促地推出了一個非常不完善的玩意。以佩奇和謝爾蓋這種Geek的角度，他們應該會預見到現在的問題，但他們為什麼還要如此衝動呢？ 　　1985年的比爾•蓋茨恐怕會很理解他們。當時蘋果推出了大受歡迎的圖形介面作業系統，但只能在價格昂貴的蘋果電腦上運行，於是市場中的其他電腦公司便需要一種類似的作業系統。那是一個稍縱即逝的巨大機會，作業系統本身也許並不需要太好，但需要的是速度：儘快推向市場，儘快成為大部分電腦廠商的首選。 　　2007年上市後大火的iPhone又在智慧手機市場提供了一個同樣的機會。Google實際上是在以微軟(微博)當年的方式搶佔智慧手機市場，目前Android設備的啟動量已超過2億。據comScore的資料，Android占了智慧手機作業系統47%的市場份額。實際上如果不統計蘋果，Android占了65.8%的市場份額，其次是RIM的23%，微軟只有7%。 　　那麼這麼做會有哪些好處呢？ 　　消費者。普通消費者其實對作業系統並不挑剔，他們想要的只是一部價格公道的智慧手機。而大部分的消費者都是第一次真正使用智慧手機，這意味著消費者本身對作業系統也投入了學習成本。只要新的作業系統不是好得驚天動地，消費者較少會投入更多精力適應新的作業系統。 　　廠商。手機廠商同樣也已經在Android這個平臺上投入了太多的成本，Android手機已經成為大部分手機廠商的核心業務，企業內部的資源、人力和外部的行銷、推廣資源都在圍繞Android運轉。即使有一個更好的手機作業系統免費提供，手機廠商恐怕也比較難將主要精力轉移出去。 　　開發者。開發者的選擇更是簡單：要麼為賺錢最多的平臺開發，要麼為用戶最多的平臺開發，前者是核心業務、現金流，後者是未來。相對于消費者和廠商，開發者面對的是三個選擇，而不是兩個。開發者通常都是小規模的公司和團隊，它們恐怕更難分配資源到新的平臺上去。 　　既然速度對於手機作業系統的成敗如此重要，那麼微軟為什麼這麼慢呢？雖然早在2003年就推出了手機作業系統，但微軟2010年才推出了基於觸屏的手機作業系統Windows Phone，直到去年10月底才發佈了第一款重要的產品諾基亞(微博)Lumia 800。 　　實際上根本的原因在於微軟錯過了追求速度的時機。直到2009年初，微軟才發現原有的Windows Mobile框架不理想，採用新架構重新開始設計了Windows Phone，2010年推出第一個版本已經是很快的速度了。而之前Google已經搶先推出了雖然問題不斷但還能應付的Android系統。等到Windows Phone第一個版本出來的時候，Android勢頭已經大好，市場上顯然已經不需要另一個倉促推出的手機作業系統了：如果以這種方式與Android競爭，微軟沒有勝出的機會。所以微軟的選擇只能是用更多的時間，做一個更加完善的作業系統與Google競爭。所以說，並不是Google喜歡倉促做粗糙的東西，而微軟喜歡慢工出細活，不同的時機造就了企業間不同的策略，商業就是這樣。

http://www.beareyes.com.cn/2/lib/201201/12/20120112088.htm

作者：小熊河南 鄭州 在剛剛結束的英特爾主題演講上，我們見識很多英特爾帶來的新科技。似乎要比昨天微軟的主題演講生動了不少！除了超級本的無限誘惑之外，我們終於見到了英特爾智慧手機！更讓我們高興的是，第一款採用英特爾Medfield的智慧手機將由聯想生產，命名為LenovoK800，這用聯通使用的3G網路，在HSPA+網路上能夠達到21.1Mbps的下載速度，預計在今年的第二季度上市。

英特爾向我們展示了這款樣機，採用8百萬圖元的攝像頭，4.5英寸的HD 720p的顯示幕。從外形看，這款手機塊頭很大，霸氣十足。更是內置近距離無線通訊技術（NFC)，英特爾更是展示了用智慧手機和超級本直接在網路付款的便捷操作。（很便捷，很酷！）其他高度智慧手機有的參數配置，K800更是一個也不能少！

這款手機另一個突出的特點就是這款手機能夠一秒內快速10連拍。英特爾專門針對安卓4.0系統進行了優化和性能提升，並確信這款手機的性能表現在安卓智慧機中的表現卓越！

http://www.beareyes.com.cn/2/lib/201201/12/20120112031.htm

作者:業界動態

英特爾公司今天宣佈了圍繞智慧手機業務的多項進展，包括與摩托羅拉移動*結成長期移動戰略合作夥伴開發多種設備，以及基於全新的英特爾®淩動™處理器平臺推出聯想*手機。多款基於全新淩動處理器的智慧手機預計將在2012年上市。 英特爾公司總裁兼首席執行官保羅•歐德寧（Paul Otellini）表示：“我們與聯想、摩托羅拉移動的合作，將有助於開發基於英特爾處理器的智慧手機，為2012年以及更長遠的產品計畫打下堅實的基礎。” 英特爾首席執行官重點介紹了英特爾®淩動™處理器Z2460平臺，此前研發代號為“Medfield”，這是專門為智慧手機和平板電腦設計的產品，可提供領先的性能以及具有競爭力的能源效率。 基於英特爾架構的智慧手機和平板電腦 作為實現這個願景的第一步，歐德寧重點介紹了用於智慧手機和平板電腦的全新低功耗32納米系統晶片（SoC）平臺。 這個之前研發代號為“Medfield”的英特爾®淩動™處理器Z2460平臺，專門針對智慧手機和平板電腦而設計，具備有競爭力的高能效和領先的性能。 摩托羅拉移動主席兼首席執行官桑傑•賈（Sanjay Jha）在歐德寧主題演講中登上講臺，兩人介紹了雙方結成長期移動戰略合作夥伴，致力於開發多種移動設備的詳細情況。這一合作涵蓋智慧手機，摩托羅拉將會在今年下半年開始發佈採用英特爾淩動處理器和Android*平臺的智能手機。這一合作也涵蓋平板電腦，將英特爾在矽技術和計算創新方面的領先性，與摩托羅拉在移動設備設計方面的專長強強結合。 聯想集團高級副總裁、聯想移動互聯及數位家庭業務集團總裁劉軍在歐德寧演講中登臺亮相，首次展示了基於英特爾架構、運行Android*平臺的聯想K800*智慧手機。劉軍說，K800智慧手機將於第二季度在中國上市，用於中國聯通的21Mbs移動通信網路。這一智慧手機基於內置英特爾®超執行緒技術的低功耗英特爾®淩動™處理器Z2460，以及英特爾®XMM™6260平臺並支援HSPA+，結合聯想LeOS使用者介面，為中國使用者提供當地語系化體驗。 歐德寧表示，實現最佳的移動體驗是英特爾的當務之急。英特爾移動與通信事業部總經理邁克爾•貝爾（Michael Bell）在歐德甯演講時上臺展示了英特爾®智慧手機參考設計，它旨在幫助手機OEM廠商和運營商縮短設備開發的週期和成本。這個全功能的智慧手機擁有圓潤的外形、4.03英寸高解析度LCD觸控式螢幕（帶來清晰的文本和鮮亮的圖像）以及兩個提供先進成像功能的攝像頭。在爆發模式下拍攝快動作照片時，使用者可以用800萬圖元在1秒內拍攝15幅圖片。 通過在這款手機上演示廣受歡迎的憤怒的小鳥*應用軟體，貝爾指出，廣泛的Android*應用支援，可使基於英特爾技術的智慧手機能夠運行絕大多數的Android*應用程式，甚至包括為其它架構而編寫的應用程式。 歐德寧表示，通過相容已有的數百萬應用軟體和設備，提供即時的軟體與應用體驗，並支援Metro*使用者介面，英特爾提升了平板電腦應用體驗。他在臺上還首次公開展示了即將上市的研發代號為“Clover Trail”的32納米英特爾淩動系統晶片，它可用於運行基於微軟*Windows* 8的平板電腦和混合型計算設備。 超極本徹底再定義PC 通過創造全新類別的超極本設備，英特爾正在引領整個行業再次重新塑造個人計算，在纖薄和雅致的PC設計中提供毫不妥協的計算體驗。 在誕生之後的短短8個月時間內，超極本已深受廣大消費者喜愛並贏得了廣泛的生態系統支援，展現出強勁的發展態勢。預計行業合作夥伴2012年將出貨超過75款以上極致設計、極高回應性和安全性的超極本系統。 戴爾*全球運營與終端使用者計算解決方案副主席傑夫•克拉克（Jeff Clarke）也在歐德甯演講時上臺，宣佈了戴爾首款超極本——採用了英特爾®酷睿™ i7處理器的全新產品XPS 13*。這款計畫在2012年2月上市銷售的產品，擁有精緻時尚的設計，僅重2.99磅（換算成1,356克），電池續航時間長達8個小時。 英特爾致力於繼續加速提升使用者體驗。採用英特爾革命性的22納米3-D三柵極電晶體，研發代號為“Ivy Bridge”的第三代智慧英特爾酷睿處理器將在2012年推出。通過該處理器，英特爾工程師將在2012年進一步加快超極本的創新步伐。 這種下一代設備將使目前已有的計算體驗提升至全新水準。在主題演講中，歐德寧還展示了兩款基於“Ivy Bridge”的超極本概念設計。 歐德寧承諾，這些設備將更加安全並提供毫不妥協的計算體驗，例如外觀設計、使用者介面或性能。他還表示，超極本將為毫不妥協的高標準環境提供旗艦平臺，這將幫助微軟*Windows* 8實現重塑Windows的目標。 英特爾AppUpSM center是一個提供最新PC應用的一站式商店，也會提供專門針對超極本的應用。英特爾宣佈與Technicolor*建立圍繞M-GO的戰略關係。這個由英特爾AppUp支持的應用，將為超極本設備和其他配置Intel® Insider™的英特爾設備，提供從電視、電影、音樂到應用軟體的高清和高檔數位內容。在2012年第二季度，M-GO將提供好萊塢主要工作室製作的電影和電視節目，還可以通過單一的直觀且安全的使用者介面，説明管理多種設備和平臺上的高清優質數位內容。

http://www.beareyes.com.cn/2/lib/201201/13/20120113160.htm

BEAREYES.COM 北京 [ 原創 ] 作者:小熊線上-Dart ARM公司總裁，一位移動處理器的頂尖開發者近日表示，英特爾最新的移動平臺晶片Medfield是智慧手機 不錯的選擇，現在公司開始把英特爾作為公司的真正的競爭的對手。ARM還聲稱英特爾永遠也不會成為移動晶片的領袖，因為英特爾的晶片功耗還是太高。 "很明顯英特爾的晶片能夠在智慧手機市場取得一些成功。我們把英特爾作為真正的競爭對手。在晶片功耗方面他們能夠領先我們嗎？不，當然不會。但是他們也會提供很多新的功能。"Warren East在接受路透社採訪時說。 ARM將繼續為一系列移動設備提供低功耗和低成本的晶片，既包括功能簡單的手機，也包括功能強大的多媒體平板。目前，ARM構架處理器授權給275家晶片廠商生產。英特爾的一款移動晶片不會改變這種大趨勢。更重要的是，這款處理器的功耗仍比ARM系統級晶片要高，由於手機電池續航時間越來越成為廠商關注的重點，因此要廠家大量採用這款高功耗的處理器尚不現實。 "英特爾把一些根本就不是為移動晶片研發的設計直接移植過來，這樣做的結果就是，這樣的晶片的性能自然不是問題。人們想用手機做更多的事情，但是電池的容量仍然有限。這就像汽車，每款車的油箱容量是固定的，你的車要想多走一百米，那麼你就要想辦法讓它更省油。這也是我們所擅長的。"East補充說。 既然ARM都已經把英特爾當成真正的競爭對手了。那麼，我們很有理由相信英特爾這次是動真格的了。

http://www.beareyes.com.cn/2/lib/201201/31/20120131094.htm

作者:小熊線上-Davy07 如果你能徹頭徹尾的把這篇文章讀完，你就會同意我說說的英特爾將會在三年之內超越高通的看法。儘管目前上市的智慧手機中還沒有採用英特爾的晶片技術，而高通卻在上個季度實現了40億美元多的營收，似乎有點癡人說夢的意思，看完本文，你就會大大改變對於Intel在移動市場未來地位的看法（高通第四季度41.2億美元。）

所以，來論證我們的觀點，我們文章的第一部分稱為"展望"，這是我們寫文章的常規做法：談論一下CPU的構架。相信任何一個編輯團隊都能勝任這項工作。第二步叫做"轉折"，我們用正常的文章來做一些不同尋常的事情。在這一部分裡我們著重討論晶片生產工藝的細節以及移動CPU晶片的歷史。相信讀者們都能從這篇文章中有所收益。 三年前，IE是流覽器市場的絕對王者。今日，穀歌Chrome則是當之無愧的領跑者。而移動晶片市場中（SoC)，高通現在無疑是絕對的王者，但是在短短三年內，英特爾將會取而代之！ 這一定是一個很大膽的論斷。我們也明白。但是我們的團隊緊隨科技界15年之多，這段經歷作給予我們的便是看待事物的不同視角。我們已經見證了AMD和英特爾的短兵相接，ARM超越MIPS和Super-H,以及PowerVR和BitBoys的捲土重來！ 移動系統級晶片（MSoCs)將會成為未來三年的熱點話題。因此你會看到很多很多類似的預測，這其中不乏瘋狂的預測，比如預測英特爾將會收購高通！ 然而根據我們的分析論斷，英特爾會最終在移動市場證明自己。

觀點差異 各抒己見 產品技術白皮書和構架分析與現實應用以及實際測試有著很大的差距。大多數的科技作者在討論公司的發展前景的時候，他們都喜歡用抽象的數字和概念。但是有一點需要明白：不是公司創造了技術，而是公司中的人才創造了技術。 就以體育為例。洛杉磯湖人隊在某些年份裡要比其他球隊優秀，但是正是有了像科比布萊恩特這樣的球員和非爾.傑克迅這樣的主教練才是得他們成就了一個冠軍夢之隊。說的再簡單一些，當一個公司被收購，買家其實並不是真正需要公司的所有資產。相反，買家可能是想通過支付高昂收購費來得以使用某些專利而已，當然更重要的是，買家能夠把關鍵性技術人才收之麾下。 因此未來移動系統級晶片（MSoCs)的發展勝出將會依靠如下三點：其一，系統級晶片構架，其二，優秀的生產工藝。其三，超越同輩的圖形晶片技術。 很多人都認為所有的移動系統級晶片都一樣。某家公司把ARM公司授權的晶片設計買來，（比如說是Cortex-A9 或者 Cortex-A15），然後把採用Mali或者是PowerVR 公司的技術圖形處理器組合在一起，再加上記憶體以及I/O介面，然後就可以進行生產了。

很多認為所有採用ARM設計的晶片的功能自然也是一樣。但是略微懂行讀者們則知道ARM僅僅是一種指令集。而有的公司可以從ARM公司購買完整的CPU核心。佈局設計（Intrinsity公司為蘋果以及三星公司設計的產品屬於此列，注：蘋果已經收購Intrinsity公司。）則可以改善性能。而有的公司則是設計全新的晶片，而不採用ARM公司提供的公版設計方案。高通公司生產的Scorpion CPU核心就是採用此種方式。而其最新的"Krait"同樣是高通自己設計的產品解決方案。英偉達的"丹佛計畫"（Project Denver)自然也屬於這一類別。（英偉達通過收購PortalPlayer, Transmeta以及 ULi公司獲得研發產品的關鍵專利以及專業研發團隊。） 但是值得注意的是，CPU核心在整體產品性能表現中的比重並不是很大。還有很多因素需要考慮，例如記憶體的頻寬，匯流排的結構，緩存設計等等。就單拿頻寬來說，頻寬是一個重要指標，但是記憶體的延遲也起著同等重要的角色。這就是為什麼AMD Athlon 64晶片的性能要優於英特爾的奔騰4晶片的原因之一。同理，這也是為什麼蘋果的iPad [...]]]> 移動晶片市場：英特爾三年超越高通！

http://www.beareyes.com.cn/2/lib/201201/31/20120131094.htm

作者:小熊線上-Davy07
如果你能徹頭徹尾的把這篇文章讀完，你就會同意我說說的英特爾將會在三年之內超越高通的看法。儘管目前上市的智慧手機中還沒有採用英特爾的晶片技術，而高通卻在上個季度實現了40億美元多的營收，似乎有點癡人說夢的意思，看完本文，你就會大大改變對於Intel在移動市場未來地位的看法（高通第四季度41.2億美元。）

所以，來論證我們的觀點，我們文章的第一部分稱為"展望"，這是我們寫文章的常規做法：談論一下CPU的構架。相信任何一個編輯團隊都能勝任這項工作。第二步叫做"轉折"，我們用正常的文章來做一些不同尋常的事情。在這一部分裡我們著重討論晶片生產工藝的細節以及移動CPU晶片的歷史。相信讀者們都能從這篇文章中有所收益。
三年前，IE是流覽器市場的絕對王者。今日，穀歌Chrome則是當之無愧的領跑者。而移動晶片市場中（SoC)，高通現在無疑是絕對的王者，但是在短短三年內，英特爾將會取而代之！
這一定是一個很大膽的論斷。我們也明白。但是我們的團隊緊隨科技界15年之多，這段經歷作給予我們的便是看待事物的不同視角。我們已經見證了AMD和英特爾的短兵相接，ARM超越MIPS和Super-H,以及PowerVR和BitBoys的捲土重來！
移動系統級晶片（MSoCs)將會成為未來三年的熱點話題。因此你會看到很多很多類似的預測，這其中不乏瘋狂的預測，比如預測英特爾將會收購高通！
然而根據我們的分析論斷，英特爾會最終在移動市場證明自己。

觀點差異 各抒己見
產品技術白皮書和構架分析與現實應用以及實際測試有著很大的差距。大多數的科技作者在討論公司的發展前景的時候，他們都喜歡用抽象的數字和概念。但是有一點需要明白：不是公司創造了技術，而是公司中的人才創造了技術。
就以體育為例。洛杉磯湖人隊在某些年份裡要比其他球隊優秀，但是正是有了像科比布萊恩特這樣的球員和非爾.傑克迅這樣的主教練才是得他們成就了一個冠軍夢之隊。說的再簡單一些，當一個公司被收購，買家其實並不是真正需要公司的所有資產。相反，買家可能是想通過支付高昂收購費來得以使用某些專利而已，當然更重要的是，買家能夠把關鍵性技術人才收之麾下。
因此未來移動系統級晶片（MSoCs)的發展勝出將會依靠如下三點：其一，系統級晶片構架，其二，優秀的生產工藝。其三，超越同輩的圖形晶片技術。
很多人都認為所有的移動系統級晶片都一樣。某家公司把ARM公司授權的晶片設計買來，（比如說是Cortex-A9 或者 Cortex-A15），然後把採用Mali或者是PowerVR 公司的技術圖形處理器組合在一起，再加上記憶體以及I/O介面，然後就可以進行生產了。

很多認為所有採用ARM設計的晶片的功能自然也是一樣。但是略微懂行讀者們則知道ARM僅僅是一種指令集。而有的公司可以從ARM公司購買完整的CPU核心。佈局設計（Intrinsity公司為蘋果以及三星公司設計的產品屬於此列，注：蘋果已經收購Intrinsity公司。）則可以改善性能。而有的公司則是設計全新的晶片，而不採用ARM公司提供的公版設計方案。高通公司生產的Scorpion CPU核心就是採用此種方式。而其最新的"Krait"同樣是高通自己設計的產品解決方案。英偉達的"丹佛計畫"（Project Denver)自然也屬於這一類別。（英偉達通過收購PortalPlayer, Transmeta以及 ULi公司獲得研發產品的關鍵專利以及專業研發團隊。）
但是值得注意的是，CPU核心在整體產品性能表現中的比重並不是很大。還有很多因素需要考慮，例如記憶體的頻寬，匯流排的結構，緩存設計等等。就單拿頻寬來說，頻寬是一個重要指標，但是記憶體的延遲也起著同等重要的角色。這就是為什麼AMD Athlon 64晶片的性能要優於英特爾的奔騰4晶片的原因之一。同理，這也是為什麼蘋果的iPad 2在操控反應速度以及整體系能表現好於同類產品的主要原因。這絕對不是簡單的"拿來就用"的產品設計方案。
為了能夠預測未來三年內哪家公司能夠在移動系統級晶片（SoC)市場領先對手，我們必須要搞清楚兩件事情：哪家公司的研發團隊最擅長實現晶片的最高性能以及哪家公司的研發團隊最有可能在晶片功耗領域領先競爭對手。
CPU的性能
在談論晶片功耗之前，讓我們先說說晶片的系能。毫無疑問，英特爾在實現最快CPU方面有著最優秀的資源，英特爾擁有著最優秀的資源從而能夠使其具備生產最快CPU的能力。ARM公司以及高通將會不可避免的避免x86構架生產商所經歷的成長之痛。
在下一代移動處理器中，高通將會從部分亂序指執行Scorpion構架轉變成完全亂序執行的"Krait"構架。Krait應該能夠實現處理器達到峰值時候的運行效率從而實現效率最優化。

與此同時，高通卻已駛入了自己不能操控的領域，在這個領域高通的工程師缺乏相應的專業知識和背景。ARM公司在研發Cortex-A9（採用了亂序執行設計）晶片過程中積累了部分經驗。但是在其新的Cortex-A15設計方案中，ARM將會為每一個執行單元提供獨立的預留緩存空間(the instruction queue)。英特爾和AMD過去也採用過獨立預留緩存空間的方式，但是現在卻都採用統一預留緩存空間（unified reservation stations ）來改善性能和使用效率。與ARM公司不同，高通想直接採用統一預留緩存空間技術。最初奔騰Pro首先成功的採用了統一預留緩存空間，所以認為高通採用這樣跳躍式發展不能成功的想法是站不住腳的。（至少有機會。）
英特爾的Atom（Medfield)構架並沒有採用公司的任何先進的技術。這還是一款採用循序執行（in-order)的單核處理器，也許這樣技術會讓你想起古老的奔騰處理器來。這真是關鍵所在：儘管採用如此過時的技術，Atom構架的運行速度已經快於ARM構架的產品。隨著產品對處理器性能要求的不斷提升，英特爾自然會把更多的新技術應用到Atom構架產品中去。英特爾在發佈Atom構架之初(2008年）便說要在5年內採用亂序執行（out-of-order)，那麼2013年之英特爾一定會完成。所以，先拋開功耗不說，英特爾自然是能夠生產最快的移動處理器。最新的實際測試也證明，最新的ATOM 單核心SOC秒殺了Cortex-A9雙核！
記憶體頻寬以及延遲方面也很相似。除了蘋果的方案，今天市場上大多數的移動系統級晶片的表現都差強人意。蘋果的系統匯流排設計不同于其他廠商。蘋果匯流排設計得益於收購P.A. Semi公司（創立這家公司的人員是來自DEC Alpha以及Strong ARM處理器的頂級設計工程師。）以及 Intrinsity（由Paul Nixon創立，他曾經負責Exponential Technology X86構架處理器項目，目前Paul Nixon就職於德州儀器MCU部門。 ） 這兩家公司。
目前為止，我們還未看見來自ARM，德州儀器以及高通的系統匯流排設計方案表現出高性能的水準。而來自英偉達的Tegra產品線採用的系統匯流排與其競爭的產品並無太大的區別。（現在發售的Tegra 3的記憶體頻寬仍然低於去年蘋果採用A5處理器。）但是英偉達的研發能力不容小覷，畢竟英偉達在NV2的環形記憶體匯流排（ring memory bus）這個nForce 2平臺的獲得業界的認可，並且在其顯卡使用交叉記憶體控制器（crossbar memory controllers ）方面積累著豐富的經驗。只是目前英偉達並沒有把這些事情提上日程而已。

另一方面，英特爾的平臺表現能力向來不俗。（不妨看看英特爾現在的Sandy Bridge-E平臺。）再一次重申，性能從來不是英特爾的攔路虎，而晶片功耗則是英特爾面臨的最大挑戰！
無線性能

英特爾在3G/LTE無線領域的經驗幾乎為零。但是在基於802.11標準的無線方面卻有著良好的口碑。英特爾的迅馳（Centrino ）平臺更是把英特爾在筆記本電腦市場推上了王者寶座。
但是隨著英特爾完成對英飛淩的收購的完成，英特爾已經獲得了在3G/LTE領域的重要資源的整合。高通，一直是3G/LTE領域的強者。但是高通的802.11無線網路的軟肋則是通過收購Atheros來加強的。在無線領域，高通的3G網路技術是領先的。但是在LTE制式技術方面，高通的優勢並不十分明顯。英特爾和高通還要共同面對的敵人包括：英偉達（擁有Icera， 軟數據機晶片廠商。3G以及LTE技術都很優秀。）三星，NTT DOCOMO，富士通以及NEC共同研發的3G/LTE產品。
系能總結
在未來三年，ARM和高通需要在提高CPU產品性能方面加大投資力度。他們的設計工程師並不精通于此，因此可能要經歷多年以前x86廠商當年所經歷的產品研發瓶頸的陣痛。但從性能方面來說，英特爾、AMD和蘋果（Intrinsity 以及 PA Semi）在高性能移動晶片領域人才濟濟，而在系統匯流排設計記憶體管理方面的人才更可謂出類拔萃。而英偉達則很有可能是一匹黑馬，坐擁豐富的技術組合，儘管還萬未採用其高端的匯流排以及記憶體設計方案，但是需要競爭對手警惕。
我們大談特談性能表現，但是卻不能不對產品功耗掉以輕心，畢竟正是功耗指標才讓移動系統級晶片顯得與眾不同。而移動晶片的功耗控制方面似乎一直是英特爾的死穴。
ARM在移動市場所向披靡的原因是，至今英特爾都不能夠展示低功耗的移動系統級晶片解決方案。在移動世界裡，大肆宣揚讓人印象深刻的性能功耗比數值是遠遠不夠的。實際上智慧手機生產廠家必須要讓自己的產品能夠至少持續一天的通話時間以及更長的待機時間，這樣的標準可以說才算產品能夠正常工作。伴隨著Medfield的發佈，英特爾至少向我們展示了其具備生產能與ARM構架一決高下的移動晶片的技術能力。正如英特爾自己所說的那樣，Medfield至少為公司在移動市場佔據了一席之地。

讀者一定聽說過許多有關ARM和x86構架的各種優缺點的討論。的確，ARM和高通在低功耗方面取得了更多的成功。在Medfield發佈之前，人們根本不確定這些採用ARM構架的產品的功耗優勢有多明顯，現在我們可以說他們領先了英特爾四年之久。因為英特爾在發佈Atom之後正是花費了四年之久才研發了一款能夠與ARM抗衡的產品。
但是，在接下來的三年之內又會發生什麼呢？現在的情況是英特爾的Medfield達到了與目前已經上市ARM移動晶片的水準。所以我們必須要拿下一代產品進行比較。在前面的討論中，我們已經提及ARM和高通在提升CPU核心性能方面所面臨的挑戰正如英特爾在降低晶片功耗方面遭遇的挑戰一樣多。

我們可以很客觀的評價移動晶片廠商在生產工藝方面的優劣。英特爾擁有半導體行業最優秀的工廠，這使得其能夠與採用在K6，K7構架的AMD的競爭中勝出。而當AMD在採用了成功的K8構架核心的時候，先進的生產工藝使得英特爾至少能夠得以維持自己的市場地位。Medfield採用了32納米制程的生產工藝與ARM解決方案相比已經很有競爭力。而英特爾的下一步計畫則是生產工藝提升到22納米的3-D三柵極電晶體。這實質上是代表著生產工藝的兩次進步。英特爾在生產工藝提升方面從未失手過，並且很快英特爾會在Ivy Bridge處理器生產過程中積累豐富的經驗。如果公司按照目前的態勢發展，那麼英特爾的晶片生產工藝領先對手18個月左右的時間。競爭對手出貨28納米生產工藝的晶片時，英特爾則會採用22納米工藝的晶片。而競爭對手全面採用3-D三柵極電晶體的時間則會更長。這些工藝的優勢能夠使得英特爾再降低20-30%的功耗。
High-K/金屬柵極
基於ARM構架的廠商目前正在逐步讓移動晶片的生產工藝採用High-K/金屬柵極。除了英特爾和三星之外，其他的廠商則要依靠如IBM，Globalfoundries和台積電的晶片工廠生產晶片。三星建造了自己的晶片生產工廠同時也為其他廠商代工。
高通與Globalfoundries簽署了合同，讓後者為其生產採用28納米工藝的移動系統級晶片。而Globalfoundries 28納米工藝師採用的"先柵極"（"gate-first" high-k/金屬柵極 技術。）IBM和三星也會如此。除非20納米微影技術出現，否則他們都不會採用"後柵極"（gate-last）。台積電（可能為蘋果A6處理器代工）雖然在不久的將來也會採用"後柵極"方案，但是英特爾已經領先其他競爭對手提前採用了。

先柵極能夠增加晶片管芯密度，能夠大幅提升產品性能。但是產品良品率則不高，在生產過程中成品率較低。而Gate-last則是能很好的保證產品生產的良品率。但是對產品設計的要求會更高。英特爾在2007年就開始出貨採用Hign-K的Penryn處理器。Globalfoundries直到2011年還沒有成功的量產Hign-K的晶片。
英特爾選擇Gate-last是不會錯的。這在其 Penryn, Nehalem和Sandy Bridge構架產品中得以驗證。 高通選擇gate-first則可能是錯誤的。 Globalfoundries有一條採用gate-first為AMD生產APU的生產線。壞消息是，據AMD第三季度的財務報表顯示，產品良品率一直未達到預期效果，從而導致了公司的營收也未達到預期。
重要的是，據公司負責研發的高級副總裁透露台積電決定採用"後柵極"工藝的想法由來已久。導致採用"先柵極"工藝良品產出率不高的部分原因是由於這種技術需要廠商精確的控制台Vt門限電壓，這是因為Nmos管道與Pmos管道使用相同的金屬。而這個問題已經困擾半導體行業20餘年之久。但是採用"後柵極"工藝則不需要複雜的工藝來控制電壓，因為Pmos管道的金屬柵極與N管道的不同。儘管這種技術管芯密度沒有"前刪級"工藝高，但是良品產出率卻很高。很明顯，最容易讓人失去市場的是產品遲遲不能上市。（因此良品產出率很重要。）然而如果想從"前柵極"轉向"後柵極"也不是一蹴而就的事情。這可不像把Globalfoundries的訂單取消然後直接在台積電的訂單上劃勾打叉一樣簡單，因為工藝的轉變則意味著需要重新設計產品結構。

似乎高通也意識到採用Gate-first的良品率根本無法滿足需要。在洛杉磯舉行的2010年國際電子設備大會上，高通宣稱其絕大多數的採用28納米生產工藝的晶片不好採用high-k/金屬柵極技術。這對高通來說，是個十分不利的條件。
性能結論
英特爾32納米hign-K方案（Medfield）與採用40/45納米工藝的基於ARM構架的晶片相比有著競爭優勢。

而在下一次產品升級過程中，英特爾則會採用22納米的3D三柵極電晶體技術，這相當於產品工藝兩次飛躍。高通生產工藝則是由45納米工藝轉向28納米工藝。但是其並不能採用先進的High-K工藝，這樣的結果則是性能提升以及功耗降低方面的不盡如意。蘋果會從45納米工藝轉向28納米的high-k技術。英偉達則是從40納米向28納米工藝轉變(同樣採用Hign-k技術。)所以與高通相比，蘋果和英偉達的28納米工藝系能的提升會由於高通的28納米工藝。
凡事有利有弊，英特爾通過採用先進的生產工藝可以提升性能降低功耗。高通將賭注押在28納米先柵極（gate-first）技術上，如果產品良品產出率讓人滿意的話，晶片的高密度會讓高通佔用優勢。而現在，似乎別無選擇，高通必須支援晶片生產工藝向28納米提升。
但是有的事偏偏利大於弊。要想提高產品競爭力，高通必須要在採取亂序指令以及改善記憶體結構上苦下功夫。而公司的設計工程師則是在Krait中首次設計這樣的方案。他們必須確保指令集萬無一失。而英特爾卻在這款沒有太多技術含量的Atom晶片設計中表現十分優秀。而取得這樣的成績的前提是英特爾根本沒有使用在x86構架產品積累和研發的任何一項新技術!
當然，英特爾的生產工藝的領先形勢會一直持續。當所有競爭對手試圖追趕英特爾的high-k/金屬柵極生產工藝的時候，英特爾已經公開展示Claremont，一款Near-Threshold超低電壓處理器，能夠在低於10毫瓦的電壓下工作。更有意思的是，和Atom一樣，英特爾的這款晶片還是基於原來的奔騰核心構架。
所以英特爾在晶片構架以及生產工藝方面將會勝出。那麼只剩下一個因素形勢還不甚明瞭：圖形處理器！
在2011年，移動晶片市場圖形晶片的主導者是PowerVR和高通的Adreno。而這兩家圖形晶片廠商追根溯源在當年都是研發x86遊戲產品的，可惜都以失敗告終。
PowerVR無疑是最卓越選手。因為英特爾，蘋果甚至德州儀器都在使用它設計的圖形晶片技術。回到90年代，Imagination Technologies （還叫VideoLogic）。PowerVR系列晶片的採用了全稱為Tile Based Deferred Rendering的渲染技術。雖然Videologic不是第一個採用這種渲染方式的公司，但卻是將這種渲染方式成功應用於實際的市場產品上的公司。這種技術只把可見部分圖形進行渲染，而看不見的部分則不需要渲染，這樣無疑很大程度上節省了頻寬。而在那個時代，其他顯卡廠商還是採用採用傳統的無論圖元是否可見，都要全部進行渲染的老路子。

然而PowerVR最大的問題則是它的團隊主要是由極富遠見的數學家和工程師組成。但是缺乏晶片設計和遊戲開發的經驗。最初這款PowerVR PCX晶片缺乏雙線性過濾功能，這意味著什麼呢？客戶花費300美元購買的顯卡，僅僅得到的是像最初PlaySation遊戲機中顯示的紋理圖元化的效果。而同時代Nintendo 64 和 3Dfx 顯卡則提供雙線性過濾功能，能夠為客戶提供更平滑的遊戲畫面。而這個雙線性過濾功能並不是什麼高深莫測的技術，最大的問題在於PowerVR的研發工程師並不願意為產品加入這樣功能。儘管這個問題在接下來的PowerVR PCX2中得以解決，這款顯卡主頻更高，也採用了雙線性過濾技術。不幸的是，這個設計團隊缺乏遊戲開發經驗，並且團隊領導人也沒有把遊戲系能給予足夠重視。後果就是設計團隊認為沒有必要加入 src*dst 溫立交混技術。問題又出在了團隊設計理念上，不是什麼技術難題，關鍵是團隊缺乏那麼一點遠見。

事情本來還是有轉機的。當年的一代名機"世嘉Dreamcast"就是採用了由NEC生產的PowerVR Series 2系列晶片。而這款晶片可以說在當時是最流行的遊戲機圖形晶片。然而不幸的是，VideoLogic在接下來的產品設計上卻一再失誤，白白喪失了這次絕地反擊的大好局面。當初VideoLogic不得不召回產品原型，結果發現產品設計存在致命的故障。而有點問題則是出在了和滑鼠指針有關方面！一次又一次，不是技術難題讓PowerVR無法攻克，而是接連不斷的錯誤加錯誤！而正是在 PowerVR Series 2 系列顯卡的失敗迫使公司做出了推出高性能顯卡的行列，轉而專注於低功耗圖形晶片設計上來。
接下來的PowerVR則是實現顯卡晶片生產商向晶片設計商的轉變。這種行銷策略與ARM公司相差無幾。這一轉變，也許是公司做出的最明智的決定。因為這樣就可以使公司更專注於數學和程式模組的研發，從而不再關注具體的生產工藝的設計。由於在公司90年代有著豐富的圖形設計和應用經驗，PowerVR今日華麗的轉身讓我們對其充滿期待！
而移動顯卡領域的另一卓越選手當屬高通的Adreno圖形晶片。Adreno公司絕非等閒之輩，因為這是高通從AMD購買的公司。AMD又是從ATI購買的，ATI則是通過收購BitBoys獲得Adreno的！

現在年齡較大的玩家可能還記憶猶新，BitBoys這家公司以"跳票"而聲名狼藉。但是採用這家公司技術的產品也確實存在。這個故事說起來有些瘋狂，而實際上，我們也對講瘋狂的故事樂此不疲。
故事要從1991年說起。在90年代初期，芬蘭盛行Demo scene,就是程式師（很多人才上高中）聚集到一起編寫能夠使電腦硬體達到極限的軟體。這個創意包括創造出讓人難以置信的視覺效果或者是讓實現這樣的視覺效果的程式盡可能的小。這些Demo創意把在視頻和音訊領域極富創造力的人才聚集在一起，這些人就是純粹的程式設計天才。這些競爭專案包括僅僅用4KB空間寫成的介紹（包含音訊和視頻）以及64KB的Demo,有興趣的朋友可以在網路上找到相應的視頻看看。

在當時最出名的一個小組是Future Crew，他們在比賽中獲得了第一名。這個小組成員中就有Mika Tuomi（也被成為Trug）他可是一位頂級程式師。正是他和他的弟弟Kaj Tuomi以及一群要好的朋友創立了這家名為BitBoys的公司。起初，他們只是為當地公司開發軟體。在他們征服了 Second Reality demo後，他們開始把興趣轉向3D顯卡。

在經過一些列招兵買馬的準備後，他們研發出來名為 Pyramid3D 的顯示晶片，這是為一家名為TriTech的公司設計的。絕大多數人認為這是BitBoys的第一次"跳票"，但是這款晶片設計設計工作已經完成，並且產品原型也生產了很多，並且在微軟大會上得以展示。產品的研發和生產幾經起伏最終成品生產了。但是由於TriTech同時還生產音訊晶片，並且它生產的音訊晶片侵犯了Cirrus Logic公司的智慧財產權。兩家公司對簿公堂後，前者輸掉了官司，最終導致公司關門大吉，這款採用Pyramid3D晶片的顯卡也最終沒有機會接受消費者檢驗。
當然，這些軟體天才們最不怕的就是挑戰。於是他們重整團隊捲土重來。這一次他瞄準了一些大公司： Real3D （從Lockheed剝離，被英特爾收購。） Rendition （被美光收購）創新實驗室（最終收購了3DLabs），ATI，英偉達，甚至他們還找到了Diamond Multimedia。但是這些公司都不願意和他們合作，最後他們只好決定自己做。

這一次他們的專案是Glaze3D，計畫採用9MB集成DRAM和高性能的填充率。公司募集到了第一輪的風險投資資本並且選取英飛淩作為其硬體生產商，這應該是基於英飛淩在集成記憶體方面的專業技術的考慮。
Kaj Tuomi是Mika的弟弟，他開始編寫一種軟體，能夠讓程式師用C語音完成一個單元設計，然後用工具套件軟體自動轉換成VHDL，這樣就可以類比程式的運行。這種軟體可以讓設計工作通過模擬器來進行。隨著3D顯卡的發展，這種設計理念實用性極高。後來他們把這款Glaze3D更名為Axe，BitBoys許諾的技術規格更高！
BitBoys又演砸了

事情發生在2001年，此事正值互聯網泡沫危機。記憶體價格急跌，英飛淩作為唯一能夠生產Axe晶片的廠商在危機中，不得不關掉集成DRAM部門。這意味著BitBoys的可以正常工作的晶片除了英飛淩外沒有廠家能夠生產。（這和高通選擇"先柵極"High-K工藝代工廠有著驚人的相似。）但是Axe也不能算作"跳票"的產品。在英飛淩DRAM部門關閉之前，生產了數量有限的一些Axe顯卡，這也讓BitBoys才得以可以拿著這些顯卡向風險投資公司展示他們的能力。
想讓程式設計天才屈服？沒門！
接下來整個團隊則是著手研發代號為"Hammer"的顯卡晶片，這是一款高性能的電腦顯卡晶片。要完成這個項目，BitBoys遇到了前所未有的挑戰。在2002年，英偉達開始銷售GeForce 4 產品而ATI開始出售Radeon 9700/9800產品，這幾款產品可都是兩家公司生產有史以來最優秀的顯卡。這時候，諾基亞找到了他們。於是BitBoys開始設計手機圖形晶片。得益於 Kaj設計的類比軟體，他們很快就設計出了晶片，這些C語言編碼可以從EPGA直接輸出。儘管這些設計並不是真正的晶片，但是性能卓越。BitBoys團隊的春天終於來了。
到2006年，BitBoys被ATI收購開始了 imageon產品線。AMD和ATI合併之後，imageon部門在2009年被高通收購。這也意味著部門的50名員工從AMD芬蘭總部轉移到了高通的芬蘭總部。
這正是Adreno的由來，它是基於BitBoys極富傳奇色彩的技術。Adreno 225圖形晶片將會用在Krait晶片中，在高解析度下性能要優於使用了 PowerVR SGX 543MP2 圖形晶片的蘋果A5處理器。而PowerVR SGX 543MP2 和Adreno 225 圖形晶片的性能都比Tegra 3的圖形晶片性能強勁。英偉達則是一再強調，從長遠角度看，公司一直致力通過增加CPU核心的性能創造更多的價值。
所以一方面，英特爾，蘋果以及德州儀器都採用了PowerVR的圖形晶片方案取得的不錯的效果。而高通的圖形處理器則是來自BitBoys的技術，產品性能也十分優秀。
但是問題的實質就在這：BitBoys團隊的主要成員在一年前紛紛離開了高通，成立一家名為 SIRU Innovations Oy的公司。

也許你從來沒有聽說過SIRU Innovations Oy 公司的名字。但是這家剛剛起步的小公司在過去一年內可謂風生水起。。
儘管目前我們尚不清楚SIRU團隊的所以成員。但是BitBoys創始人Mika 和 Kaj Tuomi兄弟是公司的聯合創始人。此外Mikko Alho是公司的總裁，他曾是高通芬蘭總部的圖形晶片硬體專案部的經理。值得注意的是，儘管Mikko Alho現在身處管理層，負責專案計畫，人員配置，設計部署，日常項目協調，專案進展彙報等工作，在90年代的BitBoys團隊裡他是負責程式模組設計工作的，還包括基於C語言以及RTL-model應用等方面的工作。這意味著這個公司的管理層更懂技術。Jarkko Makivaara，前高通芬蘭總部的工程師部經理也加入了SIRU。Jari Komppa，芬蘭高通總部高級工程師，同樣也加入了這家公司。（此人可謂Demo界的傳奇人物。）當然SIRU團隊裡還有很多前BitBoys的成員。
所以2009年加入高通的高級圖形晶片工程師，在移動顯卡設計領域有著10多年的寶貴經驗，在過去的一年內，並不是全心全意的在為高通服務。
還記得我們前面說過的PowerVR正是缺乏不能預判到軟體發展者以及用戶需求的工程師而導致失敗的例子嗎？這對於SIRU來說，卻不是什麼大問題。它的團隊成員全是程式設計高手，還有來自Fathammer的高級程式師。
另外我們深知硬體設計和軟體驅動對於產品性能同樣重要。Adreno 205 晶片再升級了驅動之後，性能就提升了50%！而SIRU團隊裡精通x86構架工程師可全是一些元老級的人物，他們在順序指令（in-order)單核處理器方面的才能無人能及。現在你還認為基於奔騰構架的Atom和Near Threshold概念技術可笑至極嗎？
高通芬蘭總部在流失了如此多的人才之後，移動圖形晶片的研發將會怎樣呢？等一下，這些人也離開了高通：
Marko Laiho，原BitBoys首席軟體構架師，高通芬蘭工程部經理半年前也離開了高通，成立了一家名為Vire Labs的公司。Joonas Torkelli，原BitBoys handheld IP產品部經理，在高通芬蘭擔任圖形軟體部門負責人，Jani Huhtanen，精通顯卡驅動以及2D/3D圖形演算法，前高通高級工程師。Jusso Heikkila以及 Kari Malmber 都加入了這家公司。
隨著大量高級人才的流失，這無疑是對高通的沉重一擊。原來歸高通獨有的專業技術人才現在卻成立了兩家公司，他們都準備把自己的技術以授權的方式賣給盡可能多的客戶使用。

最後的思考
目前，基於英特爾Medfield平臺的智慧手機還未上市。高通第四季度財報顯示營收為41.2億美元。但是在未來三年內，會發生翻天覆地的變化。想想三年前的柯達！
高通面臨著三方面的挑戰：押寶在"先柵極"工藝上，現在卻不得不採用標準的生產工藝，這就需要高通的CPU工程師在亂序指令設計上面臨挑戰。在圖形晶片方面的挑戰則是高級人才的不斷流失。
英特爾呢？在生產工藝遙遙領先，目前已經展示了一款採用32納米制程生產的移動晶片，在不使用亂序指令集技術的前提下就已經很有競爭力。而圖形晶片方面，英特爾可以選擇PowerVR的設計或者SIRU將來研發出來的產品。當然更不能排除英特爾自己的工程師研發出自己的移動圖形晶片。
因此，根據以上分析我大膽預測：英特爾三年之內必將超越高通！

People who looked at this item also looked at…

• ARM總裁：Medfield很好但是沒ARM好
• 聯發科：控局者的游戲(好文,值得一看)
• 聯想發第一款英特爾芯智慧手機LenovoK800
• 英特爾發力，全面推動智慧手機、平板電腦和超極本創新
• 穀歌官方資料：Android 4.0僅占0.6%使用份額

Related items

• 聯想發第一款英特爾芯智慧手機LenovoK800
• 英特爾發力，全面推動智慧手機、平板電腦和超極本創新
• ARM總裁：Medfield很好但是沒ARM好
• 2G手機晶片價格戰愈演愈烈
• 2G晶片進入四家中國芯血拼時代

http://www.programmer.com.cn/9202/

文 / 韓瑩 Linux Kernel峰會（簡稱KS）是Linux最重要的年度大會，受邀的是開源組織各個子系統的維護者和核心開發者。今年的峰會安排在10月23-25日。作為Google內核開發組和Linux開源開發的一員，作者受邀參加了今年的KS大會。文中記錄了一些印象較深的討論。 What’s Next For Control Cgroup Cgroup是內核裡用來把使用者進程分組的機制。 在此基礎上每個子系統（CPU、Memory、Disk和Networking）有相應的機制來監控和限制資源利用。用cgroup和resource controller來實現多個任務的資源分享，同時提供每個任務運行環境的隔離，從而保證任務性能的穩定性。由於與現有的Virtual Machine在系統性能上保有優勢，包括RedHat、openSUSE、Google、IBM、Oracle和Parallel等在內的公司都在一定程度上採用了cgroup。 由於越來越多的用戶需求，今年KS上專門安排了有關cgroup的討論。James Bottomley首先提出了目前cgroup開發社區資源不足的問題，包括開發人員和維護者。現有維護者由於某些原因即將退出，大家一致認為需要馬上找到新的維護者。Andrew Morton指出很多在記憶體管理社區的patch都是和cgroup相關的，現在的問題是沒有專門的cgroup開發人員參與討論和做Code Review，相應的patch進度就會被放慢。當然，同樣的問題在其他子系統裡也會出現。James在會後創建了一個新的郵寄清單（cgroups@vger.kernel.org)，除了針對cgroup的討論外，所有子系統的controller的討論也建議抄送到這個列表上。不管cgroup現有的實現是否理想，但用途已經越來越廣。包括Andrew和Linus都在會上提到cgroup的發展是不可逆轉的，接下來也希望多一些社區開發者加入到其中的討論中。 Memory Controller（memcg） Workshop Memcg建立在cgroup的基礎上，支持memory isolation機制。這次難得的機會，很多核心開發人員包括維護者都來到了布拉格，所以在LinuxCon會議期間我們組織了個專門的Workshop。包括來自Google、RedHat、openSUSE、Fujitsu和OpenVZ的十幾位工程師在一起討論了當前的開發進度和之後的開發計畫。這次的Workshop我們主要針對最近的幾個開發項目進行了討論，這裡簡單介紹一下幾個重點項目。 • Kernel Memory Accounting：目前3.1內核中memcg只支持user page accounting，但由於使用者進程也會申請大量kernel memory，沒有相關的kernel memory accounting會嚴重影響程式運行性能的穩定性。Google和OpenVZ都在參與相應的開發，目前主要的挑戰是怎樣在大規模網路服務器的環境下運行並不引入系統regression。 • Soft_limit Reclaim In Over-committed Environment：Over-commitment是普遍採用的提高系統資源利用率的配置。在今年的LSF上我提出利用memcg已有的Soft_limit介面在page reclaim裡實現over-commit得到了積極的認可。這次討論包括RedHat、Google和openSUSE在內的工程師把現有的實現做了進一步改善，之後會有具體細節發佈在linux－mm的郵寄清單裡面。 • Per-memcg Dirty Limit Accounting：Linux支援設置系統允許的dirty page數目的上界，但沒有支援針對每個Cgroup的支持。如果只是依靠系統的設置，很容易造成Cgroup被Out-Of-Memory Kill。Google的實現方法得到了大家一致的認可，接下來應該很快被引入upstream裡。 這次會後一個很大的感受是越來越多核心記憶體管理的開發者加入了memcg的討論和研發。記得2010年10月我去渥太華參加Linux Symposium（OLS)，當時和IBM的Balbir Singh（memcg的作者和維護者）討論接下來的開發專案和相關細節, 大部分的討論都是我和他在會後進行的。今年在三藩市的Linux Storage and Filesystem Summit上，很大一部分會上時間就開始討論memcg相關的開發細節了。所有這些變化很記Linux Kernel Summit 2011大會報導. 大的一個推動力是不斷增大的用戶需求，Google的雲計算平臺和OpenVZ的虛擬計算平臺都是基於Container的，RedHat和openSUSE近期的distribution都有cgroup的支持。和Mel Gorman會後談到這個問題，統計過去一段時間記憶體管理的patch，大部分都是和memcg相關的。同時我們都希望能有更多的工程師，尤其是核心的記憶體管理和檔案系統的開發者加入其中的討論並給出修改意見。 What to do with Android 今年的話題是怎樣提高Code Review的品質。大部分子系統的維護者都談了自己的想法，問題還是集中在沒有足夠多的資源和時間對每個patch做細緻的Review。 簡單介紹一下Linux社區開發的流程：所有的patch都要發佈在lkml的郵寄清單上。作者的名字需要標注在“Signedoff-by”後，當然一個patch也可能有多個作者，最後一個修改過的“Signed-off-by”出現在最下方。比如所有的記憶體管理patch都要先進入Andrew的mmotm tree，然後Linus會pull mmotm，所以大部分的patch最後兩個“Signed-off-by”是Andrew Morton和Linus Torvalds。一個patch一般都是要經過幾輪的code review，最終才有希望被接受。當然也有些patch一開始就被否定掉了，主要原因是要解決的問題沒有得到一致的認可。如果被多個人Review過，每個Review的人會在Email裡打上“Reviewed-by”（相對仔細看過patch的細節）或是“Acked-by”的標注（大致看過patch的細節）。 之後每個子系統的維護者會根據情況把patch加到各自的tree裡，最後由Linus決定把各個子系統merge到Linux的tree裡。 其中最關鍵的一步是把要解決的問題闡述清楚，不要一開始就關注實現細節。建議如果是大的feature [...]]]> 一位內核開發者的見聞

http://www.programmer.com.cn/9202/

文 / 韓瑩
Linux Kernel峰會（簡稱KS）是Linux最重要的年度大會，受邀的是開源組織各個子系統的維護者和核心開發者。今年的峰會安排在10月23-25日。作為Google內核開發組和Linux開源開發的一員，作者受邀參加了今年的KS大會。文中記錄了一些印象較深的討論。
What’s Next For Control Cgroup
Cgroup是內核裡用來把使用者進程分組的機制。
在此基礎上每個子系統（CPU、Memory、Disk和Networking）有相應的機制來監控和限制資源利用。用cgroup和resource controller來實現多個任務的資源分享，同時提供每個任務運行環境的隔離，從而保證任務性能的穩定性。由於與現有的Virtual Machine在系統性能上保有優勢，包括RedHat、openSUSE、Google、IBM、Oracle和Parallel等在內的公司都在一定程度上採用了cgroup。
由於越來越多的用戶需求，今年KS上專門安排了有關cgroup的討論。James Bottomley首先提出了目前cgroup開發社區資源不足的問題，包括開發人員和維護者。現有維護者由於某些原因即將退出，大家一致認為需要馬上找到新的維護者。Andrew Morton指出很多在記憶體管理社區的patch都是和cgroup相關的，現在的問題是沒有專門的cgroup開發人員參與討論和做Code Review，相應的patch進度就會被放慢。當然，同樣的問題在其他子系統裡也會出現。James在會後創建了一個新的郵寄清單（cgroups@vger.kernel.org)，除了針對cgroup的討論外，所有子系統的controller的討論也建議抄送到這個列表上。不管cgroup現有的實現是否理想，但用途已經越來越廣。包括Andrew和Linus都在會上提到cgroup的發展是不可逆轉的，接下來也希望多一些社區開發者加入到其中的討論中。
Memory Controller（memcg） Workshop
Memcg建立在cgroup的基礎上，支持memory isolation機制。這次難得的機會，很多核心開發人員包括維護者都來到了布拉格，所以在LinuxCon會議期間我們組織了個專門的Workshop。包括來自Google、RedHat、openSUSE、Fujitsu和OpenVZ的十幾位工程師在一起討論了當前的開發進度和之後的開發計畫。這次的Workshop我們主要針對最近的幾個開發項目進行了討論，這裡簡單介紹一下幾個重點項目。
• Kernel Memory Accounting：目前3.1內核中memcg只支持user page accounting，但由於使用者進程也會申請大量kernel memory，沒有相關的kernel memory accounting會嚴重影響程式運行性能的穩定性。Google和OpenVZ都在參與相應的開發，目前主要的挑戰是怎樣在大規模網路服務器的環境下運行並不引入系統regression。
• Soft_limit Reclaim In Over-committed Environment：Over-commitment是普遍採用的提高系統資源利用率的配置。在今年的LSF上我提出利用memcg已有的Soft_limit介面在page reclaim裡實現over-commit得到了積極的認可。這次討論包括RedHat、Google和openSUSE在內的工程師把現有的實現做了進一步改善，之後會有具體細節發佈在linux－mm的郵寄清單裡面。
• Per-memcg Dirty Limit Accounting：Linux支援設置系統允許的dirty page數目的上界，但沒有支援針對每個Cgroup的支持。如果只是依靠系統的設置，很容易造成Cgroup被Out-Of-Memory Kill。Google的實現方法得到了大家一致的認可，接下來應該很快被引入upstream裡。
這次會後一個很大的感受是越來越多核心記憶體管理的開發者加入了memcg的討論和研發。記得2010年10月我去渥太華參加Linux Symposium（OLS)，當時和IBM的Balbir Singh（memcg的作者和維護者）討論接下來的開發專案和相關細節, 大部分的討論都是我和他在會後進行的。今年在三藩市的Linux Storage and Filesystem Summit上，很大一部分會上時間就開始討論memcg相關的開發細節了。所有這些變化很記Linux Kernel Summit 2011大會報導.
大的一個推動力是不斷增大的用戶需求，Google的雲計算平臺和OpenVZ的虛擬計算平臺都是基於Container的，RedHat和openSUSE近期的distribution都有cgroup的支持。和Mel Gorman會後談到這個問題，統計過去一段時間記憶體管理的patch，大部分都是和memcg相關的。同時我們都希望能有更多的工程師，尤其是核心的記憶體管理和檔案系統的開發者加入其中的討論並給出修改意見。
What to do with Android
今年的話題是怎樣提高Code Review的品質。大部分子系統的維護者都談了自己的想法，問題還是集中在沒有足夠多的資源和時間對每個patch做細緻的Review。
簡單介紹一下Linux社區開發的流程：所有的patch都要發佈在lkml的郵寄清單上。作者的名字需要標注在“Signedoff-by”後，當然一個patch也可能有多個作者，最後一個修改過的“Signed-off-by”出現在最下方。比如所有的記憶體管理patch都要先進入Andrew的mmotm tree，然後Linus會pull mmotm，所以大部分的patch最後兩個“Signed-off-by”是Andrew Morton和Linus Torvalds。一個patch一般都是要經過幾輪的code review，最終才有希望被接受。當然也有些patch一開始就被否定掉了，主要原因是要解決的問題沒有得到一致的認可。如果被多個人Review過，每個Review的人會在Email裡打上“Reviewed-by”（相對仔細看過patch的細節）或是“Acked-by”的標注（大致看過patch的細節）。 之後每個子系統的維護者會根據情況把patch加到各自的tree裡，最後由Linus決定把各個子系統merge到Linux的tree裡。
其中最關鍵的一步是把要解決的問題闡述清楚，不要一開始就關注實現細節。建議如果是大的feature proposal，最好先發佈一個RFC然後附有patch的prototype。另一點是要把正確的人抄送進來，一般是包括維護者和最近在相關代碼中改動很多的開發人員。建議多花一些時間做測試，一定量測試結果會大大增加reviewer的信心。最後也是最關鍵的一點，是要得到用戶的認可和支援。每個feature的開發目的都是要解決一個實際問題，就像Linus在會上對Android的評價：“Code that actually is used that is actually worth something。”
最後給工程師一點建議
貢獻patch到開源社區一般需要花幾倍于開發patch本身的時間，但受益是長遠的。有的patch最終沒有被接受，有時只是時間的問題。最難的環節一般在開始，怎樣解釋清楚要解決的問題。如果問題本身被接受了，接下來的實現方法就容易很多了。最後提一下測試程式，這個十分關鍵，我們很多時候花太多時間去描述要解決的問題，但一張測試結果圖通常勝過千言萬語。
本文選自《程式師》雜誌2011年12期

People who looked at this item also looked at…

• 技術控解釋為什麼Android沒有iOS那麼順滑
• 美貌智慧傾倒全公司　Google女神周末完婚 (有聽過她的演講…)
• 轉貼:畢業三年，同學基本都辭職了
• [轉載] 我希望四年前就有人告訴我的事情
• 聯發科：控局者的游戲(好文,值得一看)

Related items

• How about some Android graphics true facts?
• Dianne Hackborn explain the Android MMI performance issues. #2
• 穀歌官方資料：Android 4.0僅占0.6%使用份額
• 手機作業系統之爭：為什麼穀歌快微軟慢
• Android 4.0遭破解 可在HTC G1中運行

http://tech.qq.com/a/20111125/000168.htm

騰訊科技中濤 騰訊科技訊（中濤）北京時間11月25日消息，據美國科技博客網站TechCrunch報導，國外智慧手機論壇XDA-Dev駭客jcarrz1日前上傳的一則視頻內容顯示，穀歌代號為“霜淇淋三明治”（Ice Cream Sandwich）的Android 4.0版手機作業系統已遭到破解，並能夠在宏達電(HTC)製造的首款Android手機G1當中順利運行。 宏達電G1為首款Android手機。儘管為推廣Android平臺立下了汗馬功勞，但畢竟G1屬早期產品，並於去年逐漸淡出市場。TechCrunch認為，此次駭客們將Android 4.0破解後在G1中運行，一方面是展示他們的破解技術，另一方面也是表達出一種懷舊情緒。但無論如何，在G1中成功運行Android 4.0版，其實也體現了Android平臺的靈活性。 TechCrunch指出，如果通過大量工作，駭客們也可以使G1成功運行Ubuntu甚至Windows 95作業系統，但Android 4.0能夠在G1中運行，總是一件令人感到愉快的事情。畢竟G1使用的是528MHz處理器和256MB記憶體，要順利運行針對更強功能的Android 4.0版，確實有不少難度。 jcarrz1在破解過程中，為Android 4.0系統設計了一個可運行的AOSP(Android開放源碼庫)埠，而不是完整本的定制ROM，並將其標記為“Alpha 1”。在G1運行Android 4.0後，由於無線晶片組不相容問題，導致該手機的Wifi和藍牙等功能無法使用。G1的一些硬體功能也無法獲得良好支援，如按鍵和亮度控制等。 儘管如此，G1運行Android 4.0後，流覽器、通話以及發送短信等功能都非常順暢。TechCrunch預計，今後數周內駭客們很可能推出Android 4.0版的定制ROM。

http://info.china.alibaba.com/news/detail/v5000441-d1019430978.html

時間：2011-08-23 15:39來源： 華強電子網 摩根士丹利證券近日指出，晨星2G晶片成長快速，單月出貨已由今（2011）年初的100至200萬顆大幅攀升到目前的500至600萬顆，為聯發科出貨規模的7分之1至8分之1，加上中國廠商互芯（Coolsand）積極低價搶市，影響所及，聯發科接下來將有一波價格戰得打。 據此，摩根士丹利證券半導體分析師呂家預期，聯發科未來60天股價表現將劣於大盤，除了上述潛在價格戰風險外，聯發科近期股價領先大盤上漲，也使得投資價值不再具吸引力。 不過，瑞銀證券亞太區半導體首席分析師程正樺認為，聯發科股價經過今年初以來的重挫，未來再度大跌機率已不高，是他維持“中立”看法的主要原因，但3.75G智慧型手機晶片需求目前看起來並不強，在新產品難有突破的前提下，股價也很難有大漲空間。 根據呂家的瞭解，拜深圳世大運所賜，第3季中國手機晶片市場仍有旺季效應可期，尤其是7月，相關廠商出貨成長動能都不錯，但隨著世大運8月11日開始舉行，白牌手機需求已開始趨緩下來，現在只能期待9月新一波拉貨需求。 從個別手機晶片廠商狀況來看，呂家指出，聯發科與展訊雙雄之間的戰爭看起來沒有太大變化，但值得注意的是，新進廠商已開始嶄露頭角，如晨星單月出貨量已由今年初的100至200萬顆大幅攀升到目前的500至600萬顆。 呂家表示，500至600萬顆的量相當展訊的3分之1、是聯發科的7分之1至8分之1，若加上中國本土廠商互芯的竄起、積極展開價格戰，第4季2G手機晶片市場競爭將非常激烈。 呂家認為，整體來說，2G手機晶片組已越來越難區隔化，走向低價且平均銷售價格（ASP）走跌將是必然趨勢，過去可能只有聯發科與展訊互打，現在又多了新進競爭對手，意味著新一輪價格戰即將開打，未來提供低成本與低價產品的廠商，才能擴大市占率。

http://info.china.alibaba.com/news/detail/v5000441-d1018858523.html

時間：2011-07-27 10:05來源： 華強電子網 就在MTK與展訊在低端GSM市場慘烈廝殺的時候、就在GSM手機市場連接幾個月無比淡痛的時候，另兩家GSM晶片廠商卻已悄悄復活，並在這樣一個大家都認定的淡季雙雙快速衝量了。真是應了那句名言：“這是一個最好的時代，也是一個最壞的時代。” 近日昌旭聽聞互芯的單晶片GSM方案CT1128在七月份預計將跑到KK級了，CT1128目標是MTK的6252和展訊的SC6610市場。接下來，還有一顆集成度更高的CT1130直接打價格更低的MT6252D。“目前已有二、三個專注於低端GSM機的大型集成商用我們的方案，這二、三家在七月的出貨將會超過1KK。我們暫時還不會鋪得太開，僅專注於幾個大的集成商。”互芯的一個負責人向昌旭透露，“我們不會衝量太快的。”他有些詭異地對昌旭強調。 互芯，這個在生死線上掙扎多年的GSM晶片廠商，終於又活了過來，並且是在人們認為最不好的世道活了過來，這不得不歸功於其投資人的一個正確決策。去年，在投資人的運作下，互芯與RDA成為同一個投資人下的兩個獨立的公司，產品線互補。互芯也終於與RDA，這個既具有強勢商業運作能力，又具有技術實力的公司結為兄弟。RDA公司低調、神秘的CEO戴保家從此也為互芯的復活獻策獻力。 目前起量KK級的是CT1128，而一下代CT1130才是最值得期待的，因為它將直接對抗MTK的6252D。據瞭解，互芯CT1130集成RFIC和PMU，內置32M或16M的PSRAM，支持SPIFlash。3Sim卡控制器(支援3卡功能)。採用MIPS架構，主頻156M，支援豐富多媒體應用。設計支援觸控式螢幕(最高HVGA解析度)，全鍵盤，雙T卡，WiFi,藍牙等所有基本功能外。更重要的是，它可在主機板上省掉32K晶體。成本可以說已做到極致。正如一位網友在昌旭的微博中所述：“32K晶體都省掉了，這個省的有點乾脆了。看來能幹掉它的只有MT6251啦!”的確，傳聞MTK下半年會推出終極產品MT6251，目標是將價格做到無敵，不過可能只供幾大手機品牌廠商。 熱鬧的還在後面。在互芯復活快速起量的同時，另一家在去年走過彎路的Mstar也在今年上半年這個大家都喊“痛”的季節回到快速上升的通道上來。“事實上，我們4.5.6月都在增長，7月可能跑到5-6KK水準。”Mstar一個負責人表示。目前Mstar主要起量的是8533C，8533B(33C的降成本版本)。另外，直接瞄準MTK6252和SC6620的8532也已開始出貨。8532的拍攝圖元由8533C的200M改為30M。據悉，聞泰對此次Mstar的起量貢獻較大。“除聞泰外，還有十幾家大型設計公司和品牌也出貨較大。”這個負責人表示。 看似價格戰已走到盡頭的GSM市場，仍有人在不斷進來，下半年的搏殺將變得更加赤裸裸。“一堆人搶爛白菜葉子吃，還比較誰吃得更津津有味。”一個網友在昌旭的微博中評論道。另一個網友更直接：“我一直想不明白，三個人在啃一塊骨頭…再擠進一個頭來，還能啃出神馬味道?口水的味?”網友們對於互芯的進入、Mstar的重回主流，絕大部分人都表現出了擔憂。 其實，這個產業多一些競爭者，不一定是壞處。另外，這些後進入的公司，他們也早已想好了差異化的定位。 互芯與MStar的戰略與戰術 通過與這兩家公司的負責人交流，並且分析其產品，昌旭試著詮釋下他們不同的定位與戰略戰術。 互芯現階段或較長的階段都會定位在最低端，這也是RDA的殺手鐧。“與高端GSM或智慧機玩的是軟體不同，低端GSM玩的仍是硬體遊戲。”RDA負責人表示，“而RDA在硬體成本控制上有絕招。比如我們可以實現非常小的模組化封裝、可以做低成本的二層電路板。玩硬體是我們的強項。”他自豪地稱。當然，這負責人也表示會對智慧機保持密切觀望，如果Android真如微軟所想的開始收費，那對白牌智慧機也許是一個機會，劇情又會重新改寫了。“但是目前來說，我們專注在低端GSM市場。” 與互芯專注於低端，憑自己在硬體成本上的Knowhow來取勝不同，Mstar的策略則是“低成本下實現差異化。”也就是價格上要與MTK和展訊打，同時還要讓用戶能實現少許差異化，多賺一點點利潤。“純粹玩價格戰不是我們後來者的戰略，只有給用戶一些差異化，哪怕是一點小小的改變，才能讓用戶轉向我們的方案。”Mstar負責人表示。他分析，完全以語音為主的極低端GSM市場已飽和，現在的GSM多是二次購機市場，這樣對功能的差異化就提出了要求，“但是價格也是要極具競爭性的。”他也特別強調，“因為我們在玩差異化時，同時還要特別注意是針對大眾市場的，能起量的大眾市場，不能因為玩差異化變成僅滿足小眾市場需求。” 還有一個更熱鬧的消息，今年下半年Mstar除了低端8532將會重點推出外，還將會在今年3Q推出一顆內建藍牙的晶片，而MTK也會推出內建藍牙的6255，6256”。 看來，局外人和局內人看問題真不一樣。當大家都認為MTK與展訊血戰已快無利潤的時候，互芯和Mstar仍一如既往地往裡走，並且從目前來看他們還活得不錯。而MTK呢，前有狼，後有虎。前面3G智慧平臺MT6573不僅在商務上嚴重受高通制約，技術上來說，昌旭也認為其HSUPAMODEM的穩定性還待真實網路與各網路設備相容性的檢驗。低端呢，現在則是被三家追著打。展訊的日子也不會很好過，本來全力應對MTK，現在出來兩個攪局的，且還有一家是在低價上玩了多年的老手。展訊的EDGEAndroid平臺SC6810是被不少人所期待的，但是碰上MTK的6513，這一戰還真難算誰輸誰贏。 經歷了一個漫長的冬天與春天，中國手機市場下半年會很熱鬧，MTK、展訊、Mstar和互芯四家血戰會是一個什麼場景?昌旭微博中一個MTK員工稱之為：“遲到了兩年的血戰!”

http://www.macx.cn/thread-2029071-1-1.html

HotNews 分享

雖然很多Android手機的配置都比iPhone要高，比如大多數Andorid手機的記憶體都有1GB，而iPhone 4S只有512MB記憶體，但用過iPhone的人都知道Android手機在使用的時候總感覺沒有那麼順滑，究竟為什麼會出現這種現象呢？一位軟體工程師和前Google實習生Andrew Munn解釋說是因為Android系統UI的框架設計的問題。 在iOS中UI渲染過程具有絕對的優先等級，當使用者接觸到iPhone的觸控式螢幕後，iOS中所有的進程都將停止，系統會將所有資源用於渲染UI過程。而在Android系統中UI渲染過程的優先順序別卻沒有那麼高，也就是說當你觸摸Android手機螢幕的時候，系統後臺的程式並沒有停止，仍然在繼續運行之中，比如下載和查收短信，這樣系統UI獲得的資源就不夠，這就是Android系統不流暢的原因。

由於這個原因，新發佈的Galaxy Nexus，甚至配備四核處理器的話說EeePad Transformer Prime平板電腦都無法保證順滑的操作體驗，這些設備只能與3年前的iPhone順滑程度相比，那麼Android團隊為什麼不從根本解決這個問題呢？

實際上，Android的開發工作在第一代iPhone發佈之前就已經開始了，原始Android原型體被設計成為使用鍵盤手機的設備，也就是黑莓手機的競爭對手。UI渲染優先順序別在有鍵盤的手機上並沒有那麼重要。但是在iPhone發佈之後，Android小組為了快速推出能與iPhone競爭的產品，迅速將Android改成觸控式螢幕手機系統，但那時重寫UI框架已經不可能了。因為如果這樣Android應用市場中的所有程式將變得不可用，這種關係將一直處於惡性循環之中。難怪約伯斯在傳記中表示Android是偷來的產品，哪怕蘋果傾家蕩產也要將其消滅。

cultofmac

http://www.cnbeta.com/articles/164605.htm

ugmbbc發佈 感謝淺嘗輒止的投遞 新聞來源:個人原創 iOS和Android是兩個最流行的移動應用平臺，當你有了一個絕佳的創意，如何決定先在哪個平臺上實現它？本文給出了自己的觀點。 1.硬體與相容性方面

Apple的硬體未必比Android旗艦們好，但是代碼執行速度真能比的上i字頭的並 不多見。搭載Tegra3的華碩平板在之前的評測中和半年前的iPad2有勝有負，據悉其將在明年二月上市。而大家普遍認為明年四月蘋果將會發佈下一代 iPad。而市面上大部分Android機型配置遠低於旗艦。是的，一旦新一代iOS設備上市，很快就會出現該設備獨佔的軟體（Siri應該是個極好的例 子），而為頂級Android設備開發獨佔軟體則是得不償失的。我擁有一台Galaxy SII，它上市於半年前，幾乎已經是上一代Android旗艦了，但是我依然沒有找到一款能發揮它性能的遊戲。唯一能顯示旗艦性能的是可以用外掛程式在這 些遊戲中開啟16倍抗鋸齒。

更嚴重的問題在於硬體分化。這體現在運算速度、螢幕大小、GPU系列、甚至是感測器上。GPU在Android 上有幾個系列，甚至有一個付費軟體專門用來解決這方面的相容性——將一 個GPU偽裝成另一個。再舉個例子，著名遊戲DoodleJump在iPhone4上的表現很好，在iPhone3G和Galaxy S2上就顯得反應遲鈍。原因是iP4上啟用了陀螺儀，而3G和S2上僅使用加速度感測器。因為大部分Android機型不支持陀螺儀，所以遊戲甚至未對此 進行優化。

綜上所述，對系統要求較高的遊戲適於在iOS上運行，而普通應用則對此表示影響不大。

2.付費、政策

遊戲的賺錢方式主要有三種：付費購買、遊戲內廣告、軟體內付費，以前兩者居多。應用賺錢的方式則更多些，僅有少部分應用是付費購買的。對大部分應用來說，用戶數就是錢。另外很多應用會採取軟體內付費的方式。

Android 混亂的市場對開發者來說簡直是災難。在中國，任何遊戲都可以在各種黑市場中免費下載。 在國外，盜版的情況應該稍好一些，不過依然不是個小數字。而最新的iOS5依然沒有完美越獄，就是說這些設備中的付費軟體都是買的。前一段 AppStore中國區爆出了黑美金問題，蘋果很快就解決了：通過啟用人民幣支付。這對用戶和開發者都是好消息。另一方面，Google的政策使得中國無 緣付費軟體。

Android的應用內廣告也是個悲劇。憤怒鳥這個代表性作品在中國很容易就能找到去廣告版。另外禁用這些遊戲的網路訪問也能阻止他們顯示廣告。

對 Android開發者還是有好消息的：Google僅收取用戶付費的5%分成。前段時間蘋果下架了一個軟體，因為其開發者堅持繞過蘋果的軟體內付費， 嫌蘋果的30%分成太高了。另外Android的軟體審核更為寬鬆；即使是官方市場也只下架那些惡意應用。像Market Enabler這種用來Hack菜市場的軟體都堂而皇之的在菜市場裡付費下載。蘋果有很嚴的審查，並且嚴禁那些和系統自帶功能衝突的應用存 在，Firefox既是為此無法入駐iOS平臺。

所以，任何一次性付費軟體（大部分遊戲是這種收費類型）在AppStore上架更為合適； 普通應用有更多的賺錢方式。對於軟體內收費的來說，（網路遊戲和各種線下服務的移動用戶端）Android平臺反而有一定優勢。而且在Android平臺 開發軟體也比較自由。你甚至可以和水貨商結盟，讓他們刷入帶有你應用的固件。

3.系統層面

iOS對底層許可權的開放很少，Android則非常自由甚至可以獲取Root許可權（隨便哪個牛鬼蛇神做Android軟體都要讀寫存儲卡，建一個自己的目錄，真是無奈）。

iOS特有的沙盤特性使得每個軟體都是獨立的。Android有極為強大的軟體間通訊功能（這是個革命性的功能，只是過於Geek了，Google也不會宣傳）。

iOS禁止後臺進程，Android則完全開放。所以Android可以在桌面擺放小工具，iOS則只能放置圖示。

舉個例子，Android上我可以在下載器裡開始下載一個檔，然後去做別的事。下載完成後下載器彈出通知，點一下通知直接調用播放機打開它。在iOS設備裡就變成了：添加下載任務，看著他一點點下載直到完成，然後運行播放機程式，找到對應的檔，打開。

值 得一提的是，iOS的通知系統極為優秀。他甚至提供了Android做不到的功能。誠然，Android可以通過後臺服務不停地查詢伺服器來類比iOS的 通知系統，但這太耗電了。這裡引用一條微博：“@williamlong: 不知道是不是我的錯覺還是其他什麼原因，剛才我的iphone上忽然彈出一個視窗，說我已經很久沒玩捕魚達人了，然後系統就自動運行我手機上的捕魚達人應 用了。”如果在Android上，要麼運行服務，要麼掛開機啟動，但這兩種方式都太重了，一個普通遊戲幹這種事兒也很容易被認為是流氓行為。 （CutTheRope表示這事兒我幹多了，3進程1服務佔用60M記憶體毫無壓力。）

這樣看來在系統層面Android跑應用是非常自由 的。遊戲則較難從這種自由中獲取足夠好處。（CutTheRope表示衛星定位手機識別碼互聯網連接我全要，雖然作為一個用戶看不到這有什麼好 處）Android軟體唯一要注意的其實是自律，不要濫用這些許可權。編寫iOS應用要求比較高，足夠美觀是一項基本要求（鈦備份是一個昂貴的付費軟體，他 的UI如果讓iOS用戶看到恐怕會笑掉大牙），限制也比較多，不過如果活用通知也會出彩。

http://it.sohu.com/20110901/n318015758.shtml

來源：搜狐IT 【搜狐IT消息】北京時間9月1日消息，據國外媒體報導，穀歌的雲計算服務一直使用“App Engine”品牌，日前穀歌宣佈App Engine服務將在九月份結束預覽期，正式投入商用，穀歌也首次推出了“穀歌雲服務”（Google Cloud Service）的品牌。 在Google雲計算相關網頁上，頂部的服務名稱已經標注為“穀歌雲服務”。谷歌在給開發人員的信件中宣佈，九月份，作為雲計算服務核心內容的App Engine（應用引擎）將結束預覽期，正式對外服務。 　　對於開發人員來說，谷歌也帶來一個“壞消息”，隨著App Engine結束預覽期，各項收費將全面上漲。 　　據收到信件的開發人員稱，根據新的資費標準，可以免費使用的雲計算服務內容將會縮水，各種服務的價格均作了上調。未來，穀歌雲計算服務將採用三種資費模式，即免費、收費以及超值版。每一個網路應用收費9美元，超值版則是每個帳戶收費500美元。 　　穀歌表示，超值版用戶可以獲得“運營支援”服務，獲得發票，可以創建不限數量的線上應用，但仍需繳納API、資料庫等單項使用費。 　　利用谷歌和亞馬遜等提供的雲計算服務，網路應用開發人員可以無須手工建站，直接開發程式之後寄存在穀歌的資料中心，從而免除了硬體維護之憂。這種雲計算服務越來越受到個人開發者和企業用戶的歡迎。（暻瑾）

http://tech.sina.com.cn/t/3g/2011-09-02/01376012502.shtml

新浪科技

新浪科技訊 9月2日消息，展訊全球首款40納米TD-SCDMA/HSPA多模晶片已正式商用，一款三星手機已採用該晶片。 　　三星電子於近日發佈了TD手機三星Galaxy S2，據悉該款高端手機採用了展訊全球首款40納米TD-SCDMA/HSPA多模晶片SC8800G系列，可支援高達2.8M TD-HSDPA及2.2M TD-HSUPA，該款三星手機將在9月初上市銷售。 　　不久之前，展訊通信曾宣佈公司擁有基於先進的40納米平臺的低成本、高性能基帶解決方案，並在在2011年上半年中，在TD領域實現了重大的增長。 　　市場研究公司IHS iSuppli中國研究部門負責人凱文•王(Kevin Wang)稱：“在2011年上半年，展訊通信在中國TD-SCDMA市場上取得了超過50%的份額。” 　　展訊通信預計，2011年下半年中該公司在TD-SCDMA市場上所占份額的增長速度將會加快，從而將整體市場今年的出貨量從去年的3400萬提高至超過5000萬。 　　而伴隨著全球頂級TD手機三星Galaxy S2出爐，展訊TD高端產品解決方案的穩定性與低功耗等特點也得到了充分的驗證，並獲得全球越來越多手機製造商青睞。 　　之前展訊通信總裁兼CEO李力游曾公開表示：“先進的40納米平臺使我們得以提供優質的手機3G體驗。我們TD-SCDMA基帶解決方案的低功耗能提供最多15小時的通話時長和17天的待機時間。”(銀刀)