---

※ 引述《toshiba978 (頭噓吧jo機掰)》之銘言：
:         這樣一來dirver的撰寫就容易得多, 而且比較不會有寫不好就導致系統不順
:         的狀況發生, 不用去考慮卡在kernel space太久,要快速切換之類的問題
:         這就是為什麼Android 系統需要特別的調教才會變順, 而iOS不需要的原因了
:         而特別的調教這一部分算是各家系統廠的功力所在了
:         所以平平是Android , 有得順, 有得慢
:         就這樣

其實Android的User Space裡面也........

假定今天是一個3D程式,那麼一開始是OpenGL ES java class當作繪製系統,
GLsurfaceview當作繪製的桌布,然後,OpenGL ES會經過JNI介面,跳到底層的
OpenGL ES C++ API.GLsurfaceview則是往下轉換成view->surface,經過JNI
層建立自己的surface,向底層的surfaceflinger請求服務

OpenGL ES API一開始是經過一個空殼,他會幫你載入系統中的libagl(軟體實作)
以及libhgl(硬體實作)兩個版本,然後在執行時期選擇要用硬體執行還是軟體執行.
最後和egl連接起來就可以做render.

但一開始的GLsurfaceview,找surfaceflinger要服務註冊成layer後,surfaceflinger向
libui要求建立Graphicbuffer,這樣每個APP都可以從Activity接下是自己的
Window下,這個Window Manager System含有一個viewroot指向要求到的surface,
每個double buffered的surface,在surfaceflinger內經過軟體或者是硬體(由
OpenGL ES做render to texture)的compositer後.surfaceflinger就計算出


如果是2D的畫面的話,繪製圖形的工具是Graphics class和Canvas對象.
繪製到各種view上,view再把東西複製到surface上.Graphic Class和Canvas
藉由JNI,呼叫Skia Graphic Library的功能,基本上這套library偏向於軟體實作.


找surfaceflinger要服務註冊成layer後,surfaceflinger向

libui要求建立Graphicbuffer,這樣每個APP都可以從Activity接下是自己的
Window下,這個Window Manager System含有一個viewroot指向要求到的surface,
每個double buffered的surface,在surfaceflinger內經過軟體或者是硬體(由
OpenGL ES做render to texture)的compositer後.surfaceflinger就計算出


以上是2.3以前,Android 4.0大概做了一半份量的修改.

我光把流程列出來就要用掉二十分鐘打字.可以想見真的在跑的負擔有多大.
以上還沒列兩個拖慢時間的因素:

1.Dalvik VM本身的overhead

2.Android 越早的版本考慮越多 "無GPU/2D GPU/Blit/SIMD指令加速"的較低階硬體
  所以以上提到的每一層code都有比一般程式碼更多的抽象層...

--
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.114.78.54

--