CSDN首頁今天有篇關於Android UI和iOS UI作對比的文章：《技術控解釋爲什麼Android沒有iOS那麼順滑》：http://mobile.csdn.net/a/20111207/308708.html
很有趣，可以讀讀，作者是一個曾經在谷歌呆過Google的軟件工程師，他的觀點認爲由於Android的UI渲染線程優先級過低，造成了Android沒有iOS那麼順滑，即使在四核處理器下，事實上，熟悉了不少GUI框架，包括Windows的，Java Swing的，大部分渲染線程是單線程，無法利用多線程處理器的優勢，不知道Android的UI框架是不是個例外。
事實上，調整線程優先級是很輕鬆的一件事，Java Swing的GUI線程就是比普通的線程多一個優先級，我不認爲Android的工程師調整這個線程優先級有多複雜。
用過iPhone的用戶發現它的UI界面反應，特別是一些動畫效果特別流暢，而Android UI不流暢的問題，可能有幾個原因：
- 過多的計算在UI渲染線程，而沒有進行很好的優化。比如說處理一個UI動畫效果，例如兩個界面動態的切換，可能需要生成兩個圖片，並對這兩個圖片進行處理，然後渲染，圖片的生成就會耗費大量的時間，有的效果可能必須要生成圖片對象，而生成這些圖片有可能必須放在渲染線程執行，對生成圖片對象的優化就變成了很重要的問題，必須耗費更少的時間達到更好的效果，有些圖片最好做一些緩存。
- 不應該放在UI渲染線程的任務放在了渲染線程，事實上，上述文章提出的一些問題，比如下載和查收短信，類似這樣的任務應該放在其他線程，而針對多線程的處理器，這些線程的任務不會影響UI渲染線程的反應。
- 主動繪製和被動繪製的問題沒有處理好，大部分GUI框架是被動繪製，就是通過系統觸發界面區域變髒的事件進行被動繪製，而視頻遊戲，動畫效果基本上是主動繪製，通過一個線程循環對界面所有元素進行繪製；類似iPhone的界面效果可能是主動繪製和被動繪製相結合的效果，或者針對動畫部分例程，進行了特別的處理，就是針對動畫效果不能用被動繪製；針對GUI界面，主動繪製也沒必要，JavaFX就是一個GUI主動繪製的例子，GUI的控件就是scene中的一個Node,動畫效果很好，但GUI表現又太差；完全使用主動繪製要考慮CPU佔用的問題。
事實上，在多核時代，GUI框架應該進行一些改變，UI渲染線程應該繪製一些內部狀態準備好的控件對象，而把和界面無關的其他計算放在其他線程，而UI上邊的動畫效果則需要特別的處理來保證流暢，而UI反應過慢這些問題很容易通過一些性能分析工具查出來，個人使用NetBeans自帶的分析工具也分析出來GUI程序的不少問題，比如以前的博客提到的類似一些方法非常慢的問題（GraphicsDevice.getDisplayModes()，GraphicsEnvironment。getAllFonts()，PrinterJob.getPrinterJob()和PrinterJob.defaultPage()方法等）。
相關的關於性能問題的幾篇文章：