生態碎片化這件事，早在十年多前就已經在Android社區內被廣泛討論。而在這十年來，作為Android生態的掌舵人，谷歌對這一問題的態度，也從漠不關心、無能為力，轉為了正視現實、積極進取。那麼到了2023年，Android生態的碎片化問題得到解決了嗎？非常遺憾的是，至今為止，Android生態可謂是“碎了一地，且很難破鏡重圓”。
日前，谷歌方面通過Android Studio公佈了截止今年3月，Android各版本的具體佔比。其中顯示，當前保有量最大的是佔比為23.5%的Android R（11），位居次席的則是佔比18.5%的Android Q（10），而Android S（12）、Android P（9）和Android T（13）則分列三四五位，但2017年的Android O（8）和2016年的Android N（7）還分別佔據著6.7%和3.3%的比例。
顯而易見，直都2023年，碎片化這一老生常談的問題依然是擺在Android生態面前的一座大山。那麼問題就來了，Android的碎片化為什麼會成為一個問題，谷歌為什麼非要解決它不可呢？
隨便隔壁蘋果的iOS由於閉源生態的緣故，可以通過將老版本驗證關閉來阻止用戶回滾，可為何PC端的Windows就沒有受到如此嚴重的碎片化問題困擾呢？
事實上，Android之所以因為“碎片化”飽受詬病，是因為這一現狀給開發者增加了不少開發上的成本和麻煩。而Windows的環境則更強調“窗口”這個概念，每個程序也都被視為是在獨立的窗口中，因而應用的分辨率不必與屏幕分辨率保持一致。然而Android根植於移動端，“窗口”的概念被極大弱化，除了彈出對話框和通知外，應用基本都是全屏運行的，即Android設備的分辨率和應用的分辨率高度捆綁。
因此在設計應用界面時，開發者和UI設計師需要根據不同的分辨率，來調整界面中各個控件的位置、間距、大小等。儘管Android針對“碎片化”問題為應用的適配提供了不少解決方案，但還是給開發者帶來了不小的工作量。再加上Android系統版本的迭代實質上是不停疊加功能的一個過程，碎片化導致開發者為了照顧存量用戶，往往很難在應用中使用新的技術。
在解決了編譯器、虛擬機等，更影響Android使用的問題後，此前在Android 8時代，谷歌將彌合Android生態作為了頭等大事，並帶來了Project Treble機制。而Project Treble則將“系統層”和“驅動層”拆分，解除了驅動與系統版本的強綁定，並允許芯片廠商推出長期兼容未來新版本的驅動，並且確保它能在後續新的Android版本中無需修改也能正常使用。
然而理想很豐滿、現實很骨感，即便後來問世的Android手機確實都支持Project Treble，可由於整個Android生態的歷史欠賬問題，使得手機廠商對於老機型的改造興趣缺缺。此前一加的工程師更是曾在論壇中直白的指出，廠商對跟進Project Treble沒興趣的難點，是Android 7以及更早的老機型需要修改底層分區才能適配Project Treble機制。
在Android 7之前，谷歌沒有強制要求手機廠商在打造自家ROM時進行分區，這就使得廠商的私有文件和Android系統文件混在了一起。而一臺手機想要支持Project Treble就需要在底層增加一個分區，將system和vendor這兩個分區的相關鏡像分開，便於能方便的更新和升級system，並且不依賴vendor等底層。
如果手機廠商想要讓老機型支持Project Treble，就需要通過OTA的方式對於分區進行重劃。但在這一過程中，手機存儲的數據會被直接抹掉，並且這種對於手機“大腦”進行的手術稍有閃失，就可能會出現“腦死亡”、讓設備直接變磚。而老機型沒有Project Treble，谷歌想要快速部署新版系統的通道也就不復存在了。
Project Treble除了在實際操作層面面臨技術和用戶體驗方面的難題外，這一機制本身則是一整套符合Android開發規範，但會隨著每次新版本系統的推出，而不斷添加新特性的動態體系。可這一“動態”，就讓手機廠商頗為頭疼了。
原來的情況，是谷歌老師畫一幅畫，下面的手機廠商通過臨摹再添加點細節後，自己的ROM就出爐了。現在則是谷歌從.jpg變成了.gif，稍有一點變化就會出現連鎖反應，最後就導致手機廠商的工作量成倍提升。
手機廠商對Project Treble不感興趣，谷歌當然也看在眼裡。為了避免Project Treble成為“上有政策下有對策”的犧牲品，在Android 9推出時，谷歌方面就要求所有預裝Android 9的機型都必須支持Project Treble框架，並且手機廠商需要在至少2年的時間內，為旗下的主要手機和平板電腦產品定期更新系統。同時還邀請了更多的手機廠商參與新版系統的早期測試，讓後者能夠提早熟悉新版系統。
必須要承認的是，谷歌的這一操作是有一定效果的，自Android P以來推出的機型確實也都獲得了更長的維護週期，而且手機廠商加入Android新版系統的前期階段，也確實讓Android的易用性得以大幅提升。
到了Android 10時代，谷歌則引入了Project Mainline、將系統功能模塊化，並把Android的12個核心組件，也就是媒體編解碼器、Conscrypt、權限控制器、模塊元數據等模塊化。事實上，高通驍龍Adreno以及ARM Mali GPU能夠將GPU驅動單獨在Google Play更新，就是得益於這一設計。
後續更具有里程碑意義的變化，則出現在Android 11上，谷歌開始對Android的Linux內核動刀了，並試圖將Android的內核統一至Linux內核主線。而Linux內核對於Android而言無疑是大廈的基石，Linux內核的升級也會獲得BUG和漏洞修復帶來的安全性、新的硬件驅動、新特性，以及效率的提升。然而，運行在Android設備上的內核其實與谷歌選擇的LTS（長期支持）版本Linux內核，有很大的不同。
所以最終的結果，就是Android設備使用的內核相較Linux內核主線，要滯後兩到三年的時間。在Android 11中，谷歌將系統內核進行了模塊化修改，內核被分成了通用內核鏡像（Generic Kernel Image,GKI）和其他GKI模塊，特定硬件的驅動程序（可能是閉源驅動）則作為內核模塊加載，從而提供了一個穩定的寫入接口，使得硬件供應商能夠輕鬆的插入代碼，並最終消除特定的設備內核。
為了確保新版Android系統能無限拉近與主流Linux的距離，在Linux Plumbers大會（LPC2021）上，谷歌軟件工程師、知名Linux內核技術大牛Todd Kjos還宣佈，未來Android內核開發將轉向上游優先（Upstream first）策略，並正在努力讓所有新品的內核都基於Android Generic Kernel Image (通用內核鏡像) ，確保新的代碼首先進入Linux內核Mainline，而不是直接在Android源碼樹中尋找宿主。
那麼問題來了，谷歌做出如此多的努力後，為什麼最終仍改變不了Android的碎片化問題呢？此時的根源，其實就是Android的開放。
從某種意義上來說，wintel聯盟主導的Windows生態和蘋果控制的iOS生態，其實都是強幹弱枝的中央集權模式。Android則是典型強枝弱乾的聯邦模式，而強枝弱乾的頂層設計也是開放手機聯盟得以建立的基礎。
既然都已經是強枝弱幹了，Android的碎片化也就成為了必然，所以在許多業內人士看來，谷歌的努力或許也很難改變此事。
iPhone如果放棄“固態按鍵”，誰會是最受傷的一方
此事如果成真，上游廠商或將會成為最大的受害者。