個人積分：1620分
文章編號：83314621
不要太高興 這些價格都是稅前, 稅後要加美金40元左右
個人積分：2343分
文章編號：83316978
個人積分：1620分
文章編號：83317511
個人積分：88分
文章編號：83318279
游戏脑力 wrote:
intelbridge转译后的windows 11 android下的gb5跑分
和windows 10下的差距很小,考虑到windows 11 下的amd处理器跑分本来就低
看来 windows11 跑android 透过intelbridge 转译后,可以做到接近无损运行
https://blogs.windows.com/windows-insider/2021/10/20/introducing-android-apps-on-windows-11-to-windows-insiders/
腦兄自稱英文能力超過99%台灣人，麻煩解幫我開釋下GB5在windows 11 android下為什麼會用到超厲害的intelbridge的轉譯呢?
没看.只是知道windows11跑原生android都要透过intel bridge
個人積分：1620分
文章編號：83318502
個人積分：2159分
文章編號：83318834
個人積分：88分
文章編號：83318839
個人積分：2159分
文章編號：83322668
個人積分：1620分
文章編號：83323750
個人積分：88分
文章編號：83323908
恍似 wrote:
您附的圖片是AMD Ryzen...(恕刪)
從geekbench官網的資料，可以清楚看到windows 11下的android是以x86的架構的運行
android最原始的想法本來就是可以在不同的架構集(arm/x86/mips/riscv/andes)上運作，為了達到這個目的才會使用類似於java vm，也就是把bytecode轉成相對於架構集的機器碼後執行，這一個步驟是必然要發生的，差別在於要不要在安裝app時就把byte code先編成機器碼再安裝(dalvik vm->ART)減少轉譯帶來的效能損失。如果以android SDK來開發的app都是使用這種執行方式，這也是java/android為什麼都號稱write once run every where的最大原因。
而與硬體相關的部份就是由各hardware vendor提供HAL介面的c/c++ library與android framework對接。也就是說，在windows 11上的android subsys實際上就是x86 linux kernel+x86 hal + android framework所組成。
理想上android的app都HAL是無感的，因為有framework這一層來隱藏硬體實作，但是事實總是很骨感，為了要充份發揮硬體潛力，android app會使用android NDK來開發，也就是app會直接與HAL對接，這就會導致app與cpu綁定失去android app跨平台的特性，但這也不是沒有解決方法，就以geekbench 5為例
我們可以看到在lib目錄裡有arm64-v8/arm-v7/x86/x64對應的library，也就是在不同cpu上執行會使用不同架構集的library來達到最好的執行效能。
在intel想用atom打進手機市場(2014)時，當時使用x86 NDK使用率不高，導致有些arm only的app無法在x86平台執行，intel的解法就是使用bridge technology在執行階段把arm code轉成x86 code，這就是腦兄一直掛在嘴邊的
我们和intel合作透过英特尔桥接技术使那些只能支持arm架构的apps能够在amd和intel设备上运行.使得客户们能够在最广泛的设备上获得最广泛的apps运用
以上講的都是關於cpu轉譯的部份，其實intelbridge裡是宣稱是支援xPU(CPU/GPU/...)的，這部份就誇張了，手機SoC上有大量DSP/co-processor，不要說要跨到x86，光是要從高通跨到MTK都要花大量時間開發，好在這種app都是高度綁定於手機，不會在app store上出現。
所以總結一下，在windows 11 android subsys裡執行的GB5實際上是以原生x86方式執行，不存在arm code轉x86 code的效能損失，但實際上由於過了一層hyper-v，理論上還是會比windows x86版的GB5來得差一點，而我自己腦補90%以上的app都符合這個狀況。
最後的最後，麻煩大家不要相信只看廣告而沒有根據的腦補了，當成娛樂還行，要是被誤導的話不免會鬧笑話，拜託拜託
