參考就好
目前應該仍有少數相容性問題
主要來自於Android NDK的APP
這挺麻煩的, 相容性即代表效能上的犧牲...
=== 分隔線 (引用來自於連結) ===============================================
Java程式沒問題
大家最好奇的一件事情，應該就是過去在ARM環境的應用程式，如何能夠在x86架構新平台上執行？如果是使用Android SDK開發程式，那麼Intel已經和Google進行合作，除了從Android 1.5剛發展就加入到Google API之外，後來在Android 2.3.3還加入了Intel x86 Atom System Image，能夠模擬出Atom裝置，檢查程式有沒有問題。
因為利用Eclipse＋Android SDK的開發環境，絕大多數皆以Java語言寫成，再丟入Android系統中，1個稱為Dalvik的虛擬機器裡執行，只要Intel和Google把Dalvik虛擬機器搞好，基本上跨處理器平台是沒有問題的。可惜虛擬機器是1把雙面刃，提高平台相容性的同時，也會因為多了轉譯的功夫，導致執行效能下降。
Binary Translation
需要為特定的CPU架構做轉換，因此轉換給ARM處理器執行的機器碼，一定與轉換給Intel Atom處理器的不同；加上ARM處理器是Android市場的主流，部分程式早已為ARM架構撰寫，無法在x86上執行。
根據Intel本身的調查，在Atom z2460去年推出時，Google Play裡大約有25％的應用程式是屬於這種類型，但如果跟消費者說：「很抱歉！Google Play裡的程式你們只能用75％喔。」絕大多數的消費者大概就是直接掉頭就走，看都不看Atom一眼。因此Intel在系統中放入Binary Translation，在程式執行時，直接將給ARM執行的機器碼轉換為x86能夠處理的機器碼，當然多了轉換執行效率會低落，但換來的是相容性提升。
Intel推算大約有90％專為ARM撰寫的程式能夠正常在Atom上執行，也就是說整個Google Play裡只剩下少部分的程式不能使用，且因為Intel已經和Google合作，未來撰寫的程式能夠編譯為Intel x86所能執行的機器碼，因此不能使用的程式比例會逐漸下滑，未來有一天Binary Translation可能會直接消失，就像現在很少人使用Windows 3.1、95、98的程式一樣。
softwind1314 wrote:
關於相容性? 那是 RD 的問題 不是 平台 or HW 的問題
你如果質疑 X86 相容性? 那麼不外乎就是 質疑 Google porting Android的功力 or Linux的可移植性
Linux要ARM可以用 但X86不可以用? 不太可能 普通手機/平板 其HW都是固定的 如果該device有問題 也是 這支手機 的支援廠商 有問題 <-- 這個Asus的 RD 應該要負責解
如果是 Google Android平台 不夠 一般化, maybe 在升級過程中 有可能解掉 相容性問題 <-- 但這就尷尬了 因為只有 Goolge可以解 何時會解 就不一定了
就算是 顯示卡好了 AMD and NV 不都有記錄 升級軟體後 把遊戲搞爛 or 把顯卡燒掉
遑論 升版速度更慢的手機了...(恕刪)
你跟本沒看那個文章吧, 裡面講的很清楚了
現在或許是相容性的問題解決了, 但代價是執行效能
只要那個 app有使用 NDK, 執行效能就會下降, 文中的測試, 下降達 2/3
這個不是跑分軟體可以測的出來的
真正問題在於轉換過程所失去的效能，Android一向被IOS認為其架構鬆散，
硬體規格混亂，連帶APP使用者體驗很差，而現在ATOM加入混戰，雖然增加了消費者的選擇，
但也必須面對目前ATOM執行APP轉換帶來的效能損失，這是表面看不到的問題點，
就像以前電腦追求遊戲畫質與效能，每個人都說自己電腦順，但順不順每個人感覺不同，
有人30FPS就覺得順，有人要45甚至60才OK(理論上30對人眼來說應該是足夠流暢了)，
看到有人拿RR3影片來做例子，除了影片中那位仁兄不知道有沒有關背景清記憶體就跑RR3以外，
影片本身似乎也並不流暢(自動光圈、對焦導致的停頓?)但就實際面來說，RR3在ZENFONE上跑，
的確FPS並不高，而且也不是所有特效都有顯示出來(陽光、材質反光)，
當然這對一般人來說根本不是問題，一般遊戲是覺得流暢的，但對硬體或遊戲狂人來說，
那樣應該是不流暢的，但就C/P方面來說，價錢多少就擺在那，要求表現有破萬機種是有點過份了，
但效能損失也是ATOM更該去加速改善的問題才是強化產品競爭的關鍵。
intel在binary transition的部份真的下足了功夫了
libhoudini這東西dynamic binary transition本來就比較吃效能了，而且你們要求non native code的執行效能有多好?
有查資料的人就知道，libhoudini剛開發的時候效能下降率的確很高，但是後期的版本對大部份的程式支援度上升很多了，尤其是kitkat有kernelspace binary transition assist之後，效能損失應該已經少很多了
手上一隻ZF5 2GB RAM版本，arch linux chroot背景跑爽爽，android userspace照樣pps+line+skype順順用
根本感覺不到效能下降
內文搜尋
從 APP 打開
X