首先我們在一個新的SoC要上Android系統的時候
除了編譯器外，我們要有SoC廠提供的開發套件toolkit
這些toolkit可以幫助我們節省很多開發時間

省下的這些時間是什麼時間？
每家SoC架構不同，指令集不同
我要怎樣讓Android可以在這些SoC上動？
首先我們要有SoC spec，這些spec
不是平常看的那種CPU時脈，GPU時脈這種規格
要的是比如我要控制相機，Android上可能有只有一個API負責
然後你就要去看怎麼利用這個API控制前相機，或後相機
或者是有不只一個以上的API，分別可以控制前相機或後相機
作業洗桶提供了這些API，好了我們來看SoC是否能達到我們的要求
通常常用功能，各家SoC廠商都會針對這些API下去實作
但是有的時候，新版本的作業系統，有了一個很炫的功能
這個新功能必須使用新的API，才有辦法動
但SoC沒有相對應的ABI，這樣的話會造成一些問題
可能這個功能在這個SoC上就沒有辦法用
或者說會造成崩潰等相關問題
解決的辦法，我們可以找另外一個功能相似
或者用另一種程式邏輯的方法去解決
如果SoC本身功能就不強大，可能真的就算上新版作業系統
也無法提供該功能，這個時候就是SoC不足的地方

舉例一下，Nokia Lumia1020它的4100萬畫素
為什麼在Lumia920上看不到
有一部分就是高通沒有相對應的指令集
去處理這麼高的畫素，然後再做oversampling
所以就算windows phone提供這樣的功能
SoC無法處理也沒有用
直到了Lumia1020，高通才為了Nokia出可以用的SoC

然後我們在寫Android程式的時候
程式設計師，除了寫需要性能的程式
需要用到native code外才會考慮硬體優化問題
一般都是像java一樣編譯一次然後到處執行
程式設計師會參照Dalvik提供的API去寫
一個理想的情況，Dalvik所有會用的API/ABI理應SoC都要確實支援
麻煩的地方就在於Linux上API有一個明確的標準規範，例如POSIX
但ABI卻沒有，所以在不同的SoC移植Dalvik VM非常耗費心力
如果Dalvik VM要用的API/ABI沒有，那就要自己移植
你要在現有的SoC上找一個區塊，去替代掉這個功能

舉個簡單的例子，以前80286時代寫的程式
可以完全無痛在80386上執行
原因就是API/ABI固定
不用像Linux上那樣
換個library或者libc, glibc升級
很多軟體就要重新編譯
當然如果你固定API，這種事情就不會發生
但是在Linux上，你很難不會去自己編譯軟體

今天Google的問題就是每次改版
有新的API不說，它還很喜歡去改舊有的API
所以隨著Android升級，或多或少會遇到相容性問題
假使沒有，新手機SoC不一樣，也是多少會有這些方面的問題

問題是一般的廠商不可能Android升級
就馬上出新版，就算SoC廠商也出相對映的tookit
你也是要花時間測試
如果沒有出tookit，那你就要自己測試
自己移植，自己解決API/ABI相容問題
或許直接編譯完的作業系統可以動
但只要Dalvik VM找不到它要的接口
就會馬上死給你看

再舉一個例子
很久以前，當新的ARMv7開始出現的時候
就開始有不少程式無法在AMRv6上執行
因為Dalvik VM用了一些ARMv7獨有的指令集
例如Firefox for Android就針對ARMv6推出
專門的優化版本，給比較老舊的硬體使用
它沒辦法直接用ARMv7的版本
在ARMv6上你甚至搜尋不到ARMv7版本的Firefox for Android
https://blog.mozilla.org/futurerele...-armv6-support/


API/ABI問題不是不能解決
只是等你解決完了，耗費的時間成本
幾乎等於你重新開案做一隻新手機
大部分廠商會覺得那我就做新手機就好了
幹麼花同樣的成本去升級舊版軟體？

但是這種問題對Google或者三星, APPLE, Nokia等廠商
顯然不是什麼大問題，尤其是Google
這整個作業系統都是他自己的東西
API/ABI有什麼，或沒有什麼，只有它自己最清楚
當一個新的SoC出來，Google本來自己就要替協力廠商
張羅更新移植的種種問題，而不是用嘴巴說
協力廠商應該提供至少18個月的升級維護

AOSP對硬體優化相關的代碼根本少得可憐
很多東西，到了協力廠商那邊有兩種處理的方式
一個就是打掉重練，自己寫優化過的替代功能
另一種就是在基礎上加強
所以你買了一隻白牌手機，裡面的程式
長得跟原生AOSP一樣
我趕跟你打包票，這種的十之八九只用編譯器優化
不會有太多的手工優化代碼

再來是AOSP等相關網頁
我們一般要開發或移植到新的SoC上
通常我會看以下的網頁
http://www.arm.com/zh/products/proc...logies/neon.php
http://www.arm.com/zh/products/proc...es/dsp-simd.php
https://wiki.linaro.org/WorkingGroups/ToolChain
http://www.linaro.org/
裡面會告訴你，什麼時候應該做什麼樣的優化
然後你應該怎麼替你的編譯器打上補丁
在不同的SoC編譯的時候又應該下什麼樣的參數
AOSP上這種說明幾乎少得可憐

但如果全部優化都給編譯做
這樣也不太好，因為編譯器永遠不會知道
最佳的優化方式是什麼
雖然大部分的時候，編譯器比不優化編譯出來的binary性能要高
但在怎麼高也不會你自己人工寫SIMD代碼得到更好的性能

例如我自己編譯的Firefox就有人問我為什麼不編譯AVX或者SSE3的版本
堅持只用SSE2指令集優化，原因很簡單
因為手工優化的SIMD代碼已經有了
你還去要做AVX優化
編譯器雞婆的結果
就是性能更差
所以我至始至中只做SSE2優化
而不是AVX優化不好，只是應該用在對的地方


Nexus的裝置
在4.1.x以後，已經全部由Google負責
以後不會有ASUS版，三星版等
就算以前是ASUS版，三星版，你也可以自己刷國際版
差別就是以前的協力廠商版本，沒辦法跟國際版一樣提早升級