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.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://au.ibtimes.com/articles/255199/20111124/usb-stick-sized-dual-core.htm

By Mary Elaine Ramos | FXI Technologies, a Norwegian-based company unveiled a new USB which could function as a pocket-sized computer. The code name for this USB prototype is "Cotton Candy" which derives from the fact that the USB’s weight is equal to the weight of the popular sweet treat, weighing around 21 [...]]]> A USB Stick-Sized Dual-Core Computer?

http://au.ibtimes.com/articles/255199/20111124/usb-stick-sized-dual-core.htm

By Mary Elaine Ramos |
FXI Technologies, a Norwegian-based company unveiled a new USB which could function as a pocket-sized computer.

The code name for this USB prototype is "Cotton Candy" which derives from the fact that the USB’s weight is equal to the weight of the popular sweet treat, weighing around 21 grams. The USB is run through Android and its function is described as "any-screen computing" because it is capable of turning devices like the TV, laptop, phone, tablets, or set-top box into a terminal due to the Android OS. This revolutionary USB has a dual core 1.2GHz Samsung Exynos ARM CPU (similar with Samsung Galaxy S II), 802.11n Wi-Fi, Bluetooth capability, HDMI-out, and microSD card slot for expandable memory. It has a USB 2.0 connecter on one end and the other end contains an HDMI jack.
In terms of connecting to an HDTV, the USB will utilize the HDMI-out port for video and USB for power. The USB also utilizes its Bluetooth function in order to connect to a keyboard, mouse, or tablet in order to control the OS. The USB also has an output of up to 1080p and is capable of having a full HD screen display of the Android 2.3 OS in native resolution. It is also capable of playing local 1080p video or stream HD videos from the Internet. Upon plugging the USB to a Mac or PC, it would recognize it as a normal USB device. Users can then launch the software and run the Android system in a secure window while running the desktop OS outside of the window. Files can also be transferred through dragging them through both windows.
Borgar Ljosland, the CEO of FXI demonstrated how the Cotton Candy works when he plugged it into his Mac. The transition to an Android OS was done in only a matter of seconds. Ljosland also discussed the future of the Cotton Candy as it plans to expand more in terms of being used to other devices such as tablets, smartphones, or even in iPhones and iPads in the near future. The CEO also mentioned that the main purpose of the Cotton Candy is to provide a "unique and complete computing experience" through the use of this gadget.
Presently, the Cotton Candy USB runs on Anrdoid 2.3 but it could also carry Ubuntu Linux and future models could run Windows 8. The company has not yet decided on the selling price for the Cotton Candy but it is estimated to be less than US$200.

People who looked at this item also looked at…

• 一位內核開發者的見聞
• 技術控解釋為什麼Android沒有iOS那麼順滑
• Android 4.0遭破解 可在HTC G1中運行
• 谷歌向開發者發佈Android 4.0 x86版原始程式碼
• Linux Kernel 排程機制介紹

Related items

• 蘋果穀歌再掀專利爭奪戰 InterDigital成新目標
• 『手機數碼』 [業界動態]RT:手機平臺那些事兒~(轉載)
• 渾水公司承認“誤解”展訊財報
• 諾基亞出售手機電郵及IM部門 繼續縮小關注點
• 聯發科將在MWC推出3.5G智能手機解決方案

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://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://tech.163.com/11/0902/10/7CULDF1J00094LRO.html

來源: 網易科技報導 網易科技訊 9月2日消息，百度今日正式宣佈開放其雲計算平臺，這也是繼資料和應用開放平臺後，百度又一個全面開放的大型平臺。 百度CEO李彥宏去年曾給雲計算大潑冷水，稱之為“新瓶裝舊酒”，但他今年3月再談及這一話題時稱，雲計算目前最關鍵的問題是如何發展出殺手級應用，表明這家公司並未放鬆在雲計算領域的佈局。在今天舉行的百度世界大會上，百度雲計算架構技術團隊首次公開亮相，百度執行總監范麗披露了百度雲計算的開放線路圖，智慧資料服務、典型行業應用和公共雲計算平臺將作為百度雲計算開放服務的發展方向。 百度雲計算總工程師林仕鼎稱，搜尋引擎是最典型的雲計算應用之一，百度在雲計算基礎架構和海量資料處理能力已較為成熟。未來還將陸續開放laas、Paas和SaaS等多層面的雲平臺服務，如雲存儲和虛擬機器、應用執行引擎、智慧資料分析和事件通知服務、網盤、地圖、帳號和開放API等。互聯網服務架構和資料智慧將作為擔當百度公共雲“協調調度”作業系統角色的中間平臺層，將在應用和計算、存儲間建立連接。 “百度此前的雲計算主要以“專有雲”的方式服務於內部產品，接下來將逐步開放技術，構建公共雲計算服務平臺”，範麗表示，先期開放的BAE（百度應用引擎）、雲端計算和存儲能力，將能夠説明接入的互聯網企業降低研發和運營成本。（劉偉） (本文來源：網易科技報導 )

http://digital.sina.com.hk/news/7/4/1/1089890/1.html

導語：美國科技博客BusinessInsider今天撰文，回顧了十家科技企業在創始人離職後的發展狀況，多數企業都逐漸陷入困境，甚至最終消亡。 　　以下為文章全文： 史蒂夫•喬布斯(Steve Jobs)離職後， Apple 不會有事——至少短期不會。 但一家公司的創始人的確有一些獨特的地方。試想：沒有了馬克•紮克伯格(Mark Zuckerberg)的Facebook和沒有了拉裡•佩奇(Larry Page)的 Google 會是什麼樣子？ 儘管其他員工可能會從一定程度上理解創始人的願景——例如喬布斯對簡潔設計的追求——但恐怕仍然無法擁有製定正確決策的本能。 成功企業的創始人同樣能夠贏得很多尊重，因此在遭遇重大決策問題時能夠最終拍板，並且有助於公司招聘到其他優秀的高管和員工。擁有一名具備遠見卓識的創始人同樣可以幫助企業獲得更多的媒體關注。 失去一名具有遠見卓識的創始人並不是公司的末日，但這些公司通常會伴隨著創始人的離開而轉變命運。 　　以下就是科技行業的十個例子： 比爾•蓋茨 1、比爾•蓋茨(Bill Gates )離職後，微軟增速放緩並在重要趨勢中落後。 自從蓋茨2000年卸任CEO以來，微軟就從一家高成長企業變成了藍籌股。該公司的財報一直非常亮麗(金融危機期間除外)，Windows Phone和Kinect等業務也有上佳表現。 但投資者卻擔心該公司在搜索、智慧手機和雲計算等領域的起步過晚，而Windows長期以來的壟斷地位也在逐步被iPad和其他上網設備破壞。在矽穀，有關微軟將在未來幾年內滅亡的說法並不鮮見。 傑克•多西 2、傑克•多西(Jack Dorsey)離職後，Twitter增速放緩。但隨著他的回歸，該公司又再次加快了發展步伐。 Twitter基本上都是多西的創意，而當該服務在2007年的SXSW大會上一夜成名時，多西也一直是該公司的CEO。但當他2008年卸任CEO後，儘管Twitter的用戶仍然高速增長，但卻缺乏明確的盈利計劃。 當迪克•科斯特羅(Dick Costolo)去年出任Twitter CEO後，他於今年3月邀請多西重新返回Twitter。該公司仍然未能明確創收計劃，但多西已經推出了一系列新功能，並且與 Apple 達成了合作協議，將在下一代iPhone中整合Twitter。 英特爾聯合創始人安迪•格魯夫 3、安迪•格魯夫(Andy Grove)管理的英特爾高速發展，但該公司在他離職後卻出現停滯。 在與英特爾的另外兩名聯合創始人戈登•摩爾(Gordon Moore)和羅伯特•諾依斯(Robert Noyce)一起離開仙童半導體後，格魯夫在1968年成為英特爾的第三名員工。在他1987年至1997年擔任英特爾CEO期間，該公司的市值從40億美元增長到1600多億美元。他的管理風格舉世聞名，包括鼓勵工程師嘗試各種產品並且願意做出巨大調整。他後來還以自己的經典名言“只有偏執狂才能生存”為名寫了一本書。 　　格魯夫2005年卸任英特爾董事長。自那以後，英特爾股價停滯不前甚至略有下滑，並在流動市場面臨ARM的競爭。就連他們2005年剛剛爭取來的合作夥伴 Apple 現在也開始考慮在今後的Mac中轉用ARM架構的處理器。 Palm創始人傑夫•霍金斯 4、Palm在上世紀90年代推出過轟動一時的Pilot，但在傑夫•霍金斯(Jeff Hawkins)及其團隊離職後卻幾無建樹。 霍金斯創建的PamOS成為了Palm Pilot的基礎，而後者則是上世紀90年代最成功的消費電子產品之一。 但Palm隨後捲入了一系列併購，先是被US Robotics收購，後來又被3Com收入囊中。到1998年，霍金斯開始厭倦，並與他的創業夥伴多納•杜賓斯基(Donna Dubinsky)和埃德•克裡甘(Ed Colligan)創辦了另外一家名為Handspring的手持計算設備企業。 與此同時，Palm卻幾經易主，並在本世紀初成功推出了幾款智慧手機。但在iPhone出現後，Palm卻逐漸被邊緣化，並於2009年被惠普斥資12億美元收購。惠普本月早些時候宣佈將關閉Palm硬體業務。 Danger創始人安迪•魯賓 5、安迪•魯賓(Andy Rubin)將他的願景帶到了 Google ，而Danger卻在被微軟收購後消失。 魯賓2000年與他人共同創辦了Danger，目的是將手機打造成為迷你電腦。 Danger早期就憑藉HipTop獲得了成功(T-Mobile美國將其命名為Sidekick)，但由於投資者希望增加高管名額，導致魯賓於2003年離職。 他又創辦了Android，並於2005年被 Google 收購。在他的領導下，Android已經成為全球最受歡迎的智慧手機平臺，並顛覆了整個行業。 與此同時，Danger卻於2008年被微軟以5億美元的價格收購。微軟將該團隊浪費在了一款名為Kin的社交手機上，但這款產品卻很短命。 Dodgeball創始人丹尼斯•克羅利 6、 Google 浪費了Dodgeball，但其創始人鄧尼斯•克羅利(Dennis Crowley)卻離職創辦了一家與之競爭的服務Foursquare，並且獲得了長足發展。 Google 2005年收購了克羅利的首家基於地理位置的社交網絡Dodgeball。克羅利對 Google 的管理不善和資金缺乏非常不滿，並於2007年離職創辦了一家與Dodgeball類似的企業——Foursquare。儘管創收前景仍不明確，但有報導稱，該公司的估值已經超過5億美元，並且擊退了大量的模仿者。而 Google 仍在憑藉Google+部署自己的社交網絡戰略。 Sun聯合創始人斯科特•麥克尼利 7、當斯科特•麥克尼利(Scott McNealy)離職時，Sun就已經陷入困境，但解僱他也沒有起到任何幫助。 在聯合創始人麥克尼利的領導下，Sun經歷了互聯網泡沫時期的繁榮，但同樣也遭遇了泡沫破裂後的困境。 當麥克尼利2006年將帥印交予喬納森•施瓦茨(Jonathan Schwartz)時，Sun已經陷入困境——隨著英特爾架構的服務器性能增強，高端服務器的需求開始降低，而Sun也一直沒有找到利用Java創收的方法——但得益於與微軟達成的反壟斷和解協議，他至少在任期的最後兩年將公司的現金儲備翻番。 不過，施瓦茨一直也沒有找到真正適合Sun的發展路徑，而當2008年金融危機爆發時，訂單開始減少。他最終被迫以74億美元將Sun出售給甲骨文，這一數字還不到Sun 2000年巔峰時期1800億美元市值的二十分之一。 AOL創始人史蒂夫•凱斯 8、史蒂夫•凱斯(Steve Case)將AOL打造成行業巨頭，但時代華納卻未能充分利用該公司的優勢，蒂姆•阿姆斯壯(Tim Armstrong)同樣運氣不佳。 在凱斯的領導下，AOL的實力大增，甚至以價值1000億美元的股票收購了時代華納。在互聯網泡沫破裂後，合併後的公司市值大幅縮水，而凱斯也於2005年離開董事會。 時代華納2009年分拆了AOL，但在新CEO阿姆斯壯的領導下，該公司依舊舉步維艱——其廣告業務的增速仍然不足以抵消撥號業務的下滑。 雅虎創始人楊致遠 9、楊致遠拒絕了微軟的收購要約，但他的繼任者卡羅爾•巴茨(Carol Bartz)也表現不佳。 楊致遠因為做出了科技行業發展史上最糟糕的決策之一而聲名狼藉：2008年初拒絕了微軟400多億美元的收購要約。同年晚些時候，當經濟陷入困境時，雅虎股價開始下跌，憤怒的投資者迫使他卸任CEO。 但他的繼任者巴茨同樣表現不佳。她與微軟達成了搜索合作協議，但並未達到預期效果，而雅虎的顯示廣告業務同樣遭遇困境。她也並沒有製定能夠吸引投資者的明確戰略。內部人士表示，等到她與雅虎的合同2013年到期後，很可能無法續約。 史蒂夫•喬布斯 10、當 Apple 首次失去喬布斯後，公司險些破產。 喬布斯本人的經歷就是非常經典的例子：在約翰•斯卡利(John Sculley)1985年將他驅逐後， Apple 的發展越來越差，直到公司還有幾個月就將破產時，喬布斯於1997年回歸，並創造了歷史。 (鼎宏)

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、資料庫等單項使用費。 　　利用谷歌和亞馬遜等提供的雲計算服務，網路應用開發人員可以無須手工建站，直接開發程式之後寄存在穀歌的資料中心，從而免除了硬體維護之憂。這種雲計算服務越來越受到個人開發者和企業用戶的歡迎。（暻瑾）

by laoyaoba 近日有關蘋果谷歌爭相購買Interdigital專利成為業界熱點，也引發媒體智能手機時代專利爭奪戰的討論。

2011年是智能手機爆發的一年，也是有關智能手機知識產權糾紛爆發的一年，以Apple、微軟、甲骨文為代表的對三星、HTC及Google等行業新貴發起一輪又一輪的進攻，之所以如此在於智能手機時代剛剛到來，舊的行業秩序已經被打破，而新的平衡尚未達成，以HTC、三星為代表Google Android陣營在手機領域的異軍突起對GSM時代形成的架構形成衝擊，Nokia江河日下，微軟在智能手機時代投入多年不見起色，專利則成了這些傳統霸權打壓競爭對手的最佳武器。

而在傳統功能手機領域以中國手機為代表的新勢力也對Nokia等GSM時代的霸主地位形成致命威脅，包括Nokia起訴大陸手機方案提供商上海華勤、深圳Gfive也是維護自身勢力範圍的方式之一。

應當說行業轉型期知識產權糾紛是標誌之一，也是勢力範圍劃分的主要方法和手段，不過這些並不是蘋果、Google從爭奪北電專利到Interdigital根源。

這幾年由於中國華為、中興的興起，通訊行業正在經歷顛覆性變化，傳統的通信巨頭如北電已經日落西山，通過出售專利回收資金本是迫不得已，不過由於Google、Apple等在知識產權的糾紛使得北電專利被以較高議價的45億美元成交，無疑讓傳統知識產權領域的領先者羨慕，首先是Moto股東建議Moto出售自身專利，而Interdigital的董事會更對北電專利被45億美元高價賣出目瞪口呆。

Interdigital有理由如此考慮，作為LTE技術的主要專利擁有者，Interdigital據說已經審批的專利達到8000項，而北電只有6000項，Interdigital自信相比北電專利更有價值，如果InterDigital最終能以50億美元的價格出售，這將相當於該公司過去12個月EBITDA(扣除利息、稅項、折舊和攤銷之前的利潤)的23倍，真的如此，對股東的回報當然比繼續運營公司更好，應當說與北電日暮西山不同，Interdigital在LTE正在興起之時出售專利或公司完全是被高溢價所吸引，與公司運營無關。

據說Interdigital內部在經過評估後首先與Google進行了溝通，對於剛剛在北電專利競價落敗，在Android專利糾紛中又頻繁遭到打壓的Google肯定表示了濃厚的興趣，Interdigital董事會要的就是這種態度，於是Interdigital想出售專利的消息被媒體有意爆出以引起Apple等公司關註，Interdigital希望像北電一樣能在未來的專利競價中獲得最大利益，當然如果Apple、Google對競價興趣不大，Interdigital也完全可以繼續運營下去不受傷害。

在智能手機時代新的平衡尚未達成之前，一股知識產權交易的洪流已經開始，可惜在這個變革中中國的公司基本上只能處於觀望者的身份，即使華為、中興及其他公司有足夠資金，美國政府也不會允許參與知識產權的並購，一旦新的平衡形成，可以想象對中國等新興市場的掠奪也會加劇，中國即使可以生產全球大多數產品，依然難以擺脫“中國加工”的地位，繼續呆在產業的最低端。（老杳）

Google、Apple繼續爭奪手機專利，下一戰鎖定InterDigital

http://www.bnext.com.tw/focus/view/cid/103/id/19538

撰文者：許凱玲編譯 智慧型手機專利戰爭越演越烈，除了在法庭上互控侵權之外，法庭之外的專利收購大戰更是精彩。Google日前欲收購北電（Nortel Networks）6千項專利，敗給蘋果為首的競標團隊，於是Google轉向和IBM買下超過千項的專利，最新表態考慮收購無線技術開發商InterDigital的專利。

相較於北電的專利組合中，僅2～4%和4G無線技術相關，InterDigital則是擁有更多4G無線技術專利，其中許多專利並未對外授權，若是真能標售入袋，可以說是實力大增。現在傳出蘋果也考慮要加入InterDigital的專利收購大戰，不過自從InterDigital相關專利可能出售的消息一傳出，其股價就不斷攀升，最後收購價可能會超過50億美元，將會是十年來無線設備產業規模最大的收購交易。

目前各大手機廠商所出產的智慧型手機中，約有四成會使用到InterDigital的相關專利，根據彭博社報導，InterDigital去年94%營收來自專利授權，可見其專利價值；券商Jefferies Group分析師Peter Misek指出，若是蘋果能夠成功買下InterDigital的專利，每支手機成本將可省下3～10美元，甚至可藉由專利授權費用，拉高Android手機的製造成本，爭取iPhone的市場價格優勢；因此對Google來說，這又將是一場不能輸的專利戰役，這次可不能再用圓周率這類的創意競標數字迎戰蘋果大軍了。

出自New York Times

Apple和Google再度競標InterDigital專利庫

http://richard-rrb.blogspot.com/2011/07/applegoogleinterdigital.html

from Richard’s Research Blog 才剛剛競標完Notel的專利，媒體又傳出Apple和Google可能馬上又要開始競爭InterDigital的專利，Nortel是老牌電信廠商，但Interdigital有那麼重要嗎? 找了一下資料，發現不得了，這家公司在4G LTE的基礎專利數位居第二，僅次於Qualcomm。

讓人驚訝的是，中國華為、韓國Samsung、LG都在LTE專利佔有一席之地，而Google、Apple這兩家半路跨行進來的非傳統手機廠，則沒有(或很少) LTE專利，難怪都對InterDigital的專利勢在必得。

LTE Essential Patents

Qualcomm 25% InterDigital 16% Nokia [...]]]> http://laoyaoba.blog.hexun.com.tw/66636160_d.html

by laoyaoba
近日有關蘋果谷歌爭相購買Interdigital專利成為業界熱點，也引發媒體智能手機時代專利爭奪戰的討論。

2011年是智能手機爆發的一年，也是有關智能手機知識產權糾紛爆發的一年，以Apple、微軟、甲骨文為代表的對三星、HTC及Google等行業新貴發起一輪又一輪的進攻，之所以如此在於智能手機時代剛剛到來，舊的行業秩序已經被打破，而新的平衡尚未達成，以HTC、三星為代表Google Android陣營在手機領域的異軍突起對GSM時代形成的架構形成衝擊，Nokia江河日下，微軟在智能手機時代投入多年不見起色，專利則成了這些傳統霸權打壓競爭對手的最佳武器。

而在傳統功能手機領域以中國手機為代表的新勢力也對Nokia等GSM時代的霸主地位形成致命威脅，包括Nokia起訴大陸手機方案提供商上海華勤、深圳Gfive也是維護自身勢力範圍的方式之一。

應當說行業轉型期知識產權糾紛是標誌之一，也是勢力範圍劃分的主要方法和手段，不過這些並不是蘋果、Google從爭奪北電專利到Interdigital根源。

這幾年由於中國華為、中興的興起，通訊行業正在經歷顛覆性變化，傳統的通信巨頭如北電已經日落西山，通過出售專利回收資金本是迫不得已，不過由於Google、Apple等在知識產權的糾紛使得北電專利被以較高議價的45億美元成交，無疑讓傳統知識產權領域的領先者羨慕，首先是Moto股東建議Moto出售自身專利，而Interdigital的董事會更對北電專利被45億美元高價賣出目瞪口呆。

Interdigital有理由如此考慮，作為LTE技術的主要專利擁有者，Interdigital據說已經審批的專利達到8000項，而北電只有6000項，Interdigital自信相比北電專利更有價值，如果InterDigital最終能以50億美元的價格出售，這將相當於該公司過去12個月EBITDA(扣除利息、稅項、折舊和攤銷之前的利潤)的23倍，真的如此，對股東的回報當然比繼續運營公司更好，應當說與北電日暮西山不同，Interdigital在LTE正在興起之時出售專利或公司完全是被高溢價所吸引，與公司運營無關。

據說Interdigital內部在經過評估後首先與Google進行了溝通，對於剛剛在北電專利競價落敗，在Android專利糾紛中又頻繁遭到打壓的Google肯定表示了濃厚的興趣，Interdigital董事會要的就是這種態度，於是Interdigital想出售專利的消息被媒體有意爆出以引起Apple等公司關註，Interdigital希望像北電一樣能在未來的專利競價中獲得最大利益，當然如果Apple、Google對競價興趣不大，Interdigital也完全可以繼續運營下去不受傷害。

在智能手機時代新的平衡尚未達成之前，一股知識產權交易的洪流已經開始，可惜在這個變革中中國的公司基本上只能處於觀望者的身份，即使華為、中興及其他公司有足夠資金，美國政府也不會允許參與知識產權的並購，一旦新的平衡形成，可以想象對中國等新興市場的掠奪也會加劇，中國即使可以生產全球大多數產品，依然難以擺脫“中國加工”的地位，繼續呆在產業的最低端。（老杳）

Google、Apple繼續爭奪手機專利，下一戰鎖定InterDigital

http://www.bnext.com.tw/focus/view/cid/103/id/19538

撰文者：許凱玲編譯
智慧型手機專利戰爭越演越烈，除了在法庭上互控侵權之外，法庭之外的專利收購大戰更是精彩。Google日前欲收購北電（Nortel Networks）6千項專利，敗給蘋果為首的競標團隊，於是Google轉向和IBM買下超過千項的專利，最新表態考慮收購無線技術開發商InterDigital的專利。

相較於北電的專利組合中，僅2～4%和4G無線技術相關，InterDigital則是擁有更多4G無線技術專利，其中許多專利並未對外授權，若是真能標售入袋，可以說是實力大增。現在傳出蘋果也考慮要加入InterDigital的專利收購大戰，不過自從InterDigital相關專利可能出售的消息一傳出，其股價就不斷攀升，最後收購價可能會超過50億美元，將會是十年來無線設備產業規模最大的收購交易。

目前各大手機廠商所出產的智慧型手機中，約有四成會使用到InterDigital的相關專利，根據彭博社報導，InterDigital去年94%營收來自專利授權，可見其專利價值；券商Jefferies Group分析師Peter Misek指出，若是蘋果能夠成功買下InterDigital的專利，每支手機成本將可省下3～10美元，甚至可藉由專利授權費用，拉高Android手機的製造成本，爭取iPhone的市場價格優勢；因此對Google來說，這又將是一場不能輸的專利戰役，這次可不能再用圓周率這類的創意競標數字迎戰蘋果大軍了。

出自New York Times

Apple和Google再度競標InterDigital專利庫

http://richard-rrb.blogspot.com/2011/07/applegoogleinterdigital.html

from Richard’s Research Blog
才剛剛競標完Notel的專利，媒體又傳出Apple和Google可能馬上又要開始競爭InterDigital的專利，Nortel是老牌電信廠商，但Interdigital有那麼重要嗎? 找了一下資料，發現不得了，這家公司在4G LTE的基礎專利數位居第二，僅次於Qualcomm。

讓人驚訝的是，中國華為、韓國Samsung、LG都在LTE專利佔有一席之地，而Google、Apple這兩家半路跨行進來的非傳統手機廠，則沒有(或很少) LTE專利，難怪都對InterDigital的專利勢在必得。

LTE Essential Patents

Qualcomm 25%
InterDigital 16%
Nokia 13%
Samsung 9%
Huawei 9%
LG 8%
Ericsson 3%
Nortel 3%
NSN 3%
Panasonic 2%
ETRI 2%
TI 2%
Others 5%

Source: ESTI, Techlpm, (Jefferies)

People who looked at this item also looked at…

• Android到底侵犯了微軟的什麼專利？
• Google曾為Android尋找Java替代技術
• 美貌智慧傾倒全公司　Google女神周末完婚 (有聽過她的演講…)
• 轉貼:畢業三年，同學基本都辭職了
• 技術控解釋為什麼Android沒有iOS那麼順滑

Related items

• Supercharging Android: Google to Acquire Motorola Mobility (125E美金….)
• 蘋果穀歌再掀專利爭奪戰 InterDigital成新目標
• Android 2.2 features: more HTML5, fastest mobile browser
• Apple extending ticketing ambitions to travel?
• 手機行業回顧與展望：網路服務提供商崛起

Since its launch in November 2007, Android has not only dramatically increased consumer choice but also improved the entire mobile experience for users. Today, more than 150 million Android devices have been activated worldwide—with over 550,000 devices now lit up every day—through a network of about 39 manufacturers and 231 carriers in 123 countries. Given [...]]]> http://googleblog.blogspot.com/2011/08/supercharging-android-google-to-acquire.html

Since its launch in November 2007, Android has not only dramatically increased consumer choice but also improved the entire mobile experience for users. Today, more than 150 million Android devices have been activated worldwide—with over 550,000 devices now lit up every day—through a network of about 39 manufacturers and 231 carriers in 123 countries. Given Android’s phenomenal success, we are always looking for new ways to supercharge the Android ecosystem. That is why I am so excited today to announce that we have agreed toacquire Motorola.

Motorola has a history of over 80 years of innovation in communications technology and products, and in the development of intellectual property, which have helped drive the remarkable revolution in mobile computing we are all enjoying today. Its many industry milestones include the introduction of the world’s first portable cell phone nearly 30 years ago, and the StarTAC—the smallest and lightest phone on earth at time of launch. In 2007, Motorola was a founding member of the Open Handset Alliance that worked to make Android the first truly open and comprehensive platform for mobile devices. I have loved my Motorola phones from the StarTAC era up to the current DROIDs.

In 2008, Motorola bet big on Android as the sole operating system across all of its smartphone devices. It was a smart bet and we’re thrilled at the success they’ve achieved so far. We believe that their mobile business is on an upward trajectory and poised for explosive growth.

Motorola is also a market leader in the home devices and video solutions business. With the transition to Internet Protocol, we are excited to work together with Motorola and the industry to support our partners and cooperate with them to accelerate innovation in this space.

Motorola’s total commitment to Android in mobile devices is one of many reasons that there is a natural fit between our two companies. Together, we will create amazing user experiences that supercharge the entire Android ecosystem for the benefit of consumers, partners and developers everywhere.

This acquisition will not change our commitment to run Android as an open platform. Motorola will remain a licensee of Android and Android will remain open. We will run Motorola as a separate business. Many hardware partners have contributed to Android’s success and we look forward to continuing to work with all of them to deliver outstanding user experiences.

We recently explained how companies including Microsoft and Apple are banding together in anti-competitive patent attacks on Android. The U.S. Department of Justice had to intervene in the results of one recent patent auction to “protect competition and innovation in the open source software community” and it is currently looking into the results of the Nortel auction. Our acquisition of Motorola will increase competition by strengthening Google’s patent portfolio, which will enable us to better protect Android from anti-competitive threats from Microsoft, Apple and other companies.

The combination of Google and Motorola will not only supercharge Android, but will also enhance competition and offer consumers accelerating innovation, greater choice, and wonderful user experiences. I am confident that these great experiences will create huge value for shareholders.

I look forward to welcoming Motorolans to our family of Googlers.

Posted by Larry Page, CEO

Breaking News: Google to Buy Motorola Mobility for $12.5 Billion

http://phandroid.com/2011/08/15/breaking-news-google-to-buy-motorola-for-12-5-billion/

by Quentyn Kennemer
Well slap me silly and call us crazy – we never, ever saw this coming. Google is getting set to buy Motorola Mobility, the company who was a huge part of why Android has quickly become one of the most widely-used operating systems today. The purchase will be made for $12.5 billion. Google cites Motorola’s commitment to Android being the only smartphone operating system they use as one of the reasons why the OEM fits their future plans perfectly.
This doesn’t mean Google has suddenly become an OEM – Motorola will continue to operate independently and Android will still be as open as it is now to every OEM. A large part of this acquisition has to do with Motorola’s stronghold in other telecommunications market.
Another piece to the puzzle? Motorola’s patent portfolio. They get a nice list of patents to go along with the company in order to further help protect themselves from the patent trolls.
I know what all of you are thinking – ZOMG NEXUS 3 BY MOTOROLA! We don’t know that. In fact, we’d bet heavily against that. But we’re glad to see previous rumors of Motorola’s plan to fade away from Android to focus on their own operating system may be curtailed by the fact that they are owned by Google.

People who looked at this item also looked at…

• Android到底侵犯了微軟的什麼專利？
• Google曾為Android尋找Java替代技術
• 蘋果谷歌Interdigital專利爭奪戰由來
• 轉貼:畢業三年，同學基本都辭職了
• 李一男再離職 “天才少年”遭遇管理之困

Related items

• 蘋果谷歌Interdigital專利爭奪戰由來
• Android 2.2 features: more HTML5, fastest mobile browser
• 手機行業回顧與展望：網路服務提供商崛起
• Android 4.0遭破解 可在HTC G1中運行
• 技術控解釋為什麼Android沒有iOS那麼順滑

http://it.sohu.com/20110802/n315163987.shtml

【搜狐IT消息】8月2日消息，Google與甲骨文關於Android侵權的訴訟案7月21日進行聽證，根據聽證會的記錄顯示，Google一名叫Tim Lindholm的員工去年曾寫過一封內部郵件，時間大約為訴訟發生前兩周，當時Google創始人拉裡•佩吉(Larry Page)和塞爾吉•布林(Sergey Brin) 曾要求“調查哪種技術可以成為Android中Java的替代方案”。 　　根據法庭記錄，郵件中寫道：“我們尋找了許多方案都不行，因此得出結論：我們要商討Java授權。” 　　今年四月，佩奇成為Google CEO。 　　美國加州北區州地方法院法官威廉•阿爾薩普(William Alsup)週一表示，Google不能對內部郵件保密，因為它是一份不完全的手稿，不受當事人保密特權保護。 　　Google於2007年推出Android，並迅速成為最流行的智慧手機作業系統。2010年8月甲骨文起訴Google，指控Android侵犯SUN Java專利。SUN已經被甲骨文收購，交易於去年初完成。 　　一位甲骨文聘請的專家表示，Android侵權賠償金額可達數十億美元。不過，威廉•阿爾薩普已經建議用1億美元作為起點估計損失。 　　根據21日聽證，威廉•阿爾薩普說Google內部郵件中提議的獲得SUN授權記錄可以考慮作為審訊的證據。阿爾薩普對Google律師說：“在這份文件上，你們是失利的一方。” 　　而Google代表律師内斯特（Robert Van Nest）反駁說，內部提議獲得授權是在甲骨文訴訟變成一個威脅後才提出的。他說：“如果甲骨文跑來說，好吧，你們準備把所有的錢花在官司上，而我們想獲得數十億美元賠償，而CEO的問題是有沒有其它方法達成一致。” 　　Android是建立在開源模式上的，它使用的是非Google的技術，這引起了眾多的訴訟。Android在高端智慧手機上流行，而Java卻被功能手機廣泛使用。（水星）

http://www.c114.net/news/17/a628221.html

最近關於微軟通過從Android設備上收取專利授權費用而大賺特賺的消息鋪天蓋地，這是一件看起來非常諷刺的事情，因為明明是Google基於Linux開發的手機作業系統，怎麼會輪到毫不相干的大對頭微軟來搶錢？Android設備到底侵犯了微軟的哪些專利？ 到目前為止和微軟在Android設備上達成專利協定的已經有幾家公司，最大的自然是HTC，根據雙方去年達成的協議，HTC每售出一台Android設備就需要支付微軟5美元的專利費，前不久微軟又和緯創達等4家公司達成類似的協議。 除了已經達成授權協定的那些公司之外，微軟也向三星要求為其每一部Android手機支付15美元的授權費用，同時還向摩托羅拉和B&N(旗下有基於Android OS的Nook)提出了訴訟，目前尚在糾結當中。按照這種趨勢，各大Android設備製造商最終都極有可能和微軟達成價格不等的專利授權協定，也就是說，不久之後可能我們每買一部Android手機，都會給微軟貢獻了幾美元。 關於已經達成的協議，微軟並沒有公佈相關專利的具體內容，可能是為了留一手方便以後發動突然襲擊。但是好在還有想摩托羅拉和B&N這樣的反抗軍，讓微軟不得不向法院呈上一些具體的專利內容。下面的內容有些涉及到一些普遍應用在智能手機作業系統甚至是桌面作業系統上的常識性功能，讓人看了不免有些啼笑皆非。 微軟針對摩托羅拉的訴訟中提到的專利 專利號5,579,517，長檔名支持。第5版之前的MS-DOS僅支援11個字元的檔案名（包括副檔名在內），所以微軟發明了一種同時支持長檔名和短檔案名的方法。使用過DOS作業系統的朋友應該知道，超過11個字元的檔案名DOS會自動縮短，並用～符號替代一部分，這個專利就是關於這個實現的。我很疑惑，Android系統有用到這個專利嗎？ 專利號6,621,746，快閃記憶體擦除。監視快閃記憶體的使用狀況，在適當的時候進行有針對性的擦除操作。這個涉及到快閃記憶體檔案系統的管理，具體的描述比較複雜，所以也無從判斷到底和Android有無關聯。 專利號6,909,910，連絡人的創建和更新。具體為從通話記錄中更新某個連絡人或創建新連絡人的系統和方法。如下圖，這個估計很多智慧手機都逃不過： 專利號7,644,376，系統狀態監視和通知系統。主要是關於允許移動應用獲取手機狀態變化的API，管理全域系統狀態通知。 專利號5,664,133，彈出式上下文功能表系統。具體專利描述為對使用者選擇的物件獲取並展示一系列命令在一個彈出功能表中。這專利估計是微軟的屠龍刀，神擋殺神，佛擋殺佛。當初蘋果引入右鍵菜單的時候，微軟沒有起訴是因為Patent Cross-Licensing Agreement嗎？ 專利號6,578,054，增量同步。用來同步伺服器和用戶端裡多個資料副本的系統和方法，通過此方法某一個資料副本的增量變化將會被識別，傳輸，整合到其他所有資料副本上。按照這個專利描述，Android的資料同步功能可以說全軍覆沒。 專利號6,370,566，從移動設備發起計畫會議請求。專利裡描述的實現方式和Google Calendar並不相同，所以不太明白這個和Android哪裡衝突了。 對B&N的訴訟內容大多和電子文檔的操作有關，沒多大意思，所以這裡略過不談。 微軟在Linux系統上的專利 也許更加諷刺的是，微軟在Android出生之前就開始從Linux系統上獲取專利授權費用，所以如果從源頭上看，最近發生的這些事情也只是必然結果。 2007年微軟就宣稱Linux侵犯了自己的235項專利，然而這些專利的具體內容微軟也從未公佈過。微軟的一貫策略是直接和那些應用Linux技術的公司談判，簽署專利授權協定。包括Amazon、Novell、Linspire、TurboLinux在內的多家大公司都已經和微軟簽有專利授權協議，以保護公司和用戶的利益。也有一些在自己設備中利用到Linux內核的廠商，在受到微軟的威逼之後直接選擇從設備種移除相關功能，比如TomTom。 從上面微軟狀告摩托羅拉所提出的清單，我們可以大致想像出這235項專利的輪廓，絕大多數應該涉及到一些已經普遍應用在現代作業系統，已經成為呼吸般存在的基礎功能。如果要避開微軟的專利，那就意味著重新製造輪子，這對整個電腦行業都是一件非常悲哀的事情。 結語 專利本來是為保護智慧財產權、刺激創新而創建的一套系統，但也經常性會適得其反，如何平衡是一個永恆的話題。從微軟對Android相關廠商提出的這些專利來看，個人覺得恐怕更多的是拖了技術後腿，對於產權保護和技術創新已經沒有絲毫意義。即便是基於商業戰略考量，這個做法也畢竟不會長遠，微軟還是在現有智慧手機的基礎上好好加強創新吧，畢竟坐吃山空不是長久之計。