※ 本文為 layzer 轉寄自 ptt.cc 更新時間: 2012-09-17 07:13:10
看板 Gossiping
作者 標題 Re: [問卦] 有沒有android無法體會iPhone滑順的八卦
時間 Sun Sep 16 18:11:56 2012
※ 引述《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就計算出
最後混合得到的畫面,然後把畫面建立在FramebufferNativeWindow,依照
硬體配備放在graphic memory或者是pmem上.由HAL得知的kernel driver
就可以因此驅動硬體.
硬體配備放在graphic memory或者是pmem上.由HAL得知的kernel driver
就可以因此驅動硬體.
如果是2D的畫面的話,繪製圖形的工具是Graphics class和Canvas對象.
繪製到各種view上,view再把東西複製到surface上.Graphic Class和Canvas
藉由JNI,呼叫Skia Graphic Library的功能,基本上這套library偏向於軟體實作.
比較可能利用SIMD加速,但比較不容易採用GPU加速.
view畫好變成surface一樣.........(以下用複製的)
view畫好變成surface一樣.........(以下用複製的)
找surfaceflinger要服務註冊成layer後,surfaceflinger向
libui要求建立Graphicbuffer,這樣每個APP都可以從Activity接下是自己的
Window下,這個Window Manager System含有一個viewroot指向要求到的surface,
每個double buffered的surface,在surfaceflinger內經過軟體或者是硬體(由
OpenGL ES做render to texture)的compositer後.surfaceflinger就計算出
最後混合得到的畫面,然後把畫面建立在FramebufferNativeWindow,依照
硬體配備放在graphic memory或者是pmem上.由HAL得知的kernel driver
就可以因此驅動硬體.
硬體配備放在graphic memory或者是pmem上.由HAL得知的kernel driver
就可以因此驅動硬體.
以上是2.3以前,Android 4.0大概做了一半份量的修改.
我光把流程列出來就要用掉二十分鐘打字.可以想見真的在跑的負擔有多大.
以上還沒列兩個拖慢時間的因素:
1.Dalvik VM本身的overhead
2.Android 越早的版本考慮越多 "無GPU/2D GPU/Blit/SIMD指令加速"的較低階硬體
所以以上提到的每一層code都有比一般程式碼更多的抽象層...
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 140.114.78.54
推 :專業1F 09/16 18:12
推 :恩恩 沒錯2F 09/16 18:13
推 :嗯阿3F 09/16 18:13
推 :確實如此4F 09/16 18:13
→ :原來是jk大大,可惜此文內容對小弟太深了 囧rz5F 09/16 18:14
→ :等等會有人要你翻譯6F 09/16 18:14
→ :可以翻成中文嗎7F 09/16 18:14
→ :原來如此 看不懂8F 09/16 18:14
推 :嗯嗯 大致上都提到了 嗯嗯9F 09/16 18:15
→ :太專業了 看不懂10F 09/16 18:15
推 :結論: 舊機慢 新機快?11F 09/16 18:15
推 :this is a book.12F 09/16 18:15
→ :為了向下相容反而更慢?13F 09/16 18:16
推 :恩對 跟我想得差不多14F 09/16 18:18
推 :恩 還不錯 只有中文看得懂~15F 09/16 18:19
推 :其實算是模組化的另一個副作用, 因為android裡用了很多16F 09/16 18:20
→ :external project, 因為要便於抽換,所以弄得很複雜
→ :external project, 因為要便於抽換,所以弄得很複雜
推 :恩還不錯 我也是這樣認為的18F 09/16 18:22
噓 :太專業 我眼紅 噓一下 ~19F 09/16 18:23
推 :真的太專業了,完全看不懂...20F 09/16 18:47
推 :你可以不要這麼專業嗎? QAQ21F 09/16 18:49
→ :你確定廠商在自製UI不會直接使用 JNI OpenGLES ?22F 09/16 19:01
→ :JVM overhead 是第一次執行程式時會慢的主因,但我們在討論
→ :為什麼有人說畫面刷得不順,通常都是在講桌面管理程式吧
→ :JVM overhead 是第一次執行程式時會慢的主因,但我們在討論
→ :為什麼有人說畫面刷得不順,通常都是在講桌面管理程式吧
→ andy199113 …
推 :恩恩 跟我想的一樣 恩恩 果然如此26F 09/16 20:03
→ :你糟了 有人會噓你"洛一堆英文 是不會用中文逆??????"27F 09/16 20:07
推 :內容完全看不懂,不過結論算是有看種,謝謝分享28F 09/16 20:15
推 :這篇專業!!29F 09/16 20:29
→ :字可以不要全部連在一起嗎? 看得很痛苦30F 09/16 22:06
--
※ 同主題文章:
09-16 17:11 ■ Re: [問卦] 有沒有android無法體會iPhone滑順的八卦
● 09-16 18:11 ■ Re: [問卦] 有沒有android無法體會iPhone滑順的八卦
09-16 19:14 ■ Re: [問卦] 有沒有android無法體會iPhone滑順的八卦
※ 看板: layzer 文章推薦值: 0 目前人氣: 0 累積人氣: 454
※ 文章分類: i(don't care)Phone
作者 jk21234 的最新發文:
- 我970 1070 2080都有搶初期 首批沒有後的等待大約是3.5個月 2.5個月 ...2080印象不到2個月 3080自發表到發售前的熱度 體感上較為接近gtx980/970 的時候...所以有 …31F 21推
- 為什麼cache預料之外的hit會導致data外流.... 其實表面來說 資料沒有被讀出來 但是是被窮舉的方式猜出來的 基本原理 0. int64 a = rdtsc() RDTSC = Read t …72F 40推
- 消費級的就先不用嚇自己 因為 1. user mode的計算不會變慢 壓檔跟跑分是沒有因為這樣分數洗牌的 2. I/O syscall要多花時間所以變慢 但你自己的應用會是重度I/O嗎 而且原本dis …131F 56推
- OK 你看不出來 是因為你剛好錯開不一樣的年代 故事是這樣的 首先 除了Quicktime跟RM,當時大部分的壓縮的影像是來自於 JPEG/MPEG系列以及衍伸的技術 所以使用的壓縮方法都還蠻接近的. …84F 49推
- 今天拿來裝顯示卡 圖中是1070FE 約是10.5吋 如果裝了8吋以上的卡 會少兩個3.5擴充可用 上方5.25的只有上面兩個可以裝 光碟機 否則會撞到主機板 下面5.25頂多拿來轉接3.5吋 所以最 …90F 40推
點此顯示更多發文記錄
回列表(←)
分享