Android開發的過去、現在和將來

標籤：

現如今，擁有著 80% 的市場份額的 Android 是最主流的手機作業系統。它運行在無數的智能手機、平板以及其他各種各樣的裝置上。僅憑這一點，我們是否可以認為  Android 編程是簡單而輕鬆的呢？

幾年前，Miley Cyrus 還在唱著鄉村音樂，Justin Bieber 還梳著他那著名的“Bieber”髮型，Malcolm 還在 AC/DC 樂隊，而同時 Android 開發還相當複雜。Android 開發人員對於Android 系統開發最簡單的應用都有一大堆問題。

為什嗎？嗯，親愛的讀者，問題出在各種地方：

漏洞層出的IDE：你有沒有試過用一把鏟子去修理你的汽車？或者你開著你爺爺的40年前的 Yugo 汽車去把妹？在Android世界中，對於 Android 開發，我們有一個官方 IDE——Eclipse，它有一大堆問題，在10分鐘之內保證讓你抓狂。Eclipse ADT 外掛程式對於更多的複雜工程來說也是充滿漏洞、緩慢而不友好的。我們對此非常噁心，祈禱能發生奇蹟來改善這一切。

系統分裂：Gingerbread (2.3.7)在 Android 系統版本中佔據著相當大的市場份額（至少15-20%）。正如你已知道的，Android 正通過4.0版本（Ice Cream Sandwich）經曆著複雜的翻修過程。系統有了新的使用者介面元素、新的裝置硬體API、新的螢幕密度等等，這就導致了我們必須小心地最佳化和編寫我們的應用來使得在新版本Android和舊版本 Android 都能運行良好。所有的這一切都極大地影響了我們的開發進程和導致了更多的 bug 和 crash，以至於延長了開發時間。

緩慢的模擬器：我們需要在不同的 Android 系統版本和螢幕尺寸測試我們的應用，所以我們必須買至少20種 Android 裝置。聽起來是不是很瘋狂？好吧，我們能使用模擬器來解決。但是你曾有沒有試過用預設的 Android 模擬器？它的緩慢讓人痛不欲生，當你的應用正在被部署到你的模擬器的時候，你會讓你自己去數辦公樓前面停的車的數量來打發時間。

使用者介面(UI)：Android 應用無聊死了。如果你褻瀆看一眼 iOS 應用，你會看到這些應用充滿了生活氣息而且色彩繽紛。所有的事物都是活生生的，動作轉換，從左至右、從右至左……而我們的應用是死的，如果我們想要提高我們的使用者體驗，老舊的Gingerbread 會很快抹殺我們的希望和憧憬。

但是這些都是2013的事了。

一個新開始

所有者一起都在去年發生了改變，改變發生的如此之快，以至於你很容易地失去對它們的追隨腳步，然後問自己“這都是什麼時候發生的？”更重要的是整個 Android 生態系統提高了很多——我們有了新的硬體（智能手錶），新的軟體（Gradle，Android Studio），新的系統（Android 5.0 Lollipop）。

每個人都對此有著貢獻——Google、裝置製造商、開發人員。每個人都有相同的目標。問他們相同的這個問題：“OK。現在我們有穩定的系統，十億計的應用和十億計的使用者——我們怎麼才能進一步簡化和提高 Android？我們怎麼才能使得開發進程更好？”這就是 open access和 open source 原則展現的他們的潛力——每個人都可以做出改變、產生提高、創造新的事物的所在。

很難列出全部的變化，但我做了一個列表來列出其中（在我看來）最重要的變化：

1.ANDROID STUDIO

我們最喜歡的Andorid 開發的 IDE 終於變成了穩定的1.0版本了。我不會談論太多關於 AS 為什麼對於開發進程來說是最好的相關細節，因為我們已經有兩篇登出的部落格覆蓋了這一主題。我會說 Eclipse ADT 外掛程式已經不被官方贊成使用，我也強烈建議你把所有的應用遷移到  Android Studio。向 Google 致敬！

 新Android Studio Logo 2.GRADLE

Gradle 是工程自動化工具，它已經替代 Apche Ant 成為 Android 應用主要的構建系統。它在 Android 開發人員中非常流行。因為我們通過它幾乎可以自動化所有事情——從將我們的應用區分成不同風格、正確配置簽名等等

因此，他變成了一系列的“管理”工具，我們用來定義和維持我們的工程設定。Gradle 也是測試自動化庫和自動構建伺服器大量增長的主要原因。測試自動化庫和自動構建伺服器又給  Android 系統帶來了持續整合（CI）開發過程。但是不是一切都是那麼令人樂觀——Gradle也在執行速度上飽受批評。在複雜工程上面 Gradle 也真的很慢，但我們希望這個問題會在接下來的版本和發行中解決。

3.LOLLIPOP

Google 說 Lollipop 是自人類誕生以來 Android 系統最大的提升，Google 說的沒錯。 Android 的每個部分都有相應的修改和提升，但是我們也尚未見到開發人員對這些改變有怎樣的反應。雖然將舊裝置升級到 Lollipop 還有很多問題，但是我們期望這會在接下來的版本中解決。

4.LOLLIPOP 的外在—— MATERIAL DESIGN

對於這個叫作 Material Design 的金光閃閃的新 Android UI 有很多要寫。這是最近幾年Android 系統最重要創新點之一，它完全改變了我們應用的觀感。我最喜歡 Material Design 的是它徹底改變了使用者體驗原則——一切都重要。即使是細小的細節也不能被忽略。我們必須對每個使用者互動、點擊、觸摸等做出響應。因為，這正如 Google 所說的，這些動作都是有意義的。我們必須使用黑體、擁抱新的生動的色彩、每一步使用動畫、大字型，簡單地說，我們要給我們的應用以生命。Material Design 同樣也完全符合 Android 生態系統，適應各種不同的螢幕尺寸。這也就是為什麼我們的應用是相似的，但是在不同的平台有著不一樣的外觀。

 Material Design 動畫 5.LOLLIPOP 的內在—— ART

每個人都在談論設計、UI、UI 元素、動畫、色彩······,但是我們是開發人員，我們感興趣的是外表之下的東西。而且，哇！！！這引擎真是美極了：ART，新的運行系統。為了記錄，ART 並不是什麼新東西—它被介紹為 Kitkat 上次要的運行系統。通過引入 Lollipop，它完全代替了 Dalvik，成為主系統。由於很多原因 ART 是偉大的，但我只提及其中兩點：

一、它使用 AOT（ahead-of-time）編譯，這意味著它把中繼語言（Dalvik位元組碼）編譯成系統二進位碼。這就導致我們應用更短的執行時間、更少的 CPU 佔用、更少的電池消耗。在另一方面，安裝過程也就更長。

二、他提供 multidex 支援。Dalvik dex 檔案有個重大缺陷—它們只能包含65，356種方法。我們必須組織好我們的 Android 應用以使方法不要超過這個限制。儘管這個數字可能看上去很大，但是如果你把 Google Play 服務（幾乎每個應用都需要）算在內，再加上一些外部函數庫，你就能輕易超過這個限制。ART 以一種突破了位元組碼以眾多 dex 檔案打包到一個單獨的 APK 的方式組織你的應用。

6.ANDROID 無處不在

我們開始給智能手錶、電視、汽車開發應用，為什麼要在此打住呢？如果你坐在你的房間，喝著了一杯熱咖啡，花一兩分鐘看看你的周圍。在接下去的這幾年你也許會看到至少五樣運行著 Android 系統的裝置—電視、筆記本、平板、相機、單車、廚房電器、恒溫器、汽車等等。Android 開始作為一種實驗，它被證明能夠運行在任何一個擁有小型微處理器的事物上面。

7.智能手機品質的提高

智能手機還是Android 系統的核心裝置。長期以來，智能手機的整體品質有問題。老舊的Android 裝置比老舊的 iPhone 更醜更慢——iOS 通常感覺更流暢。對於那些被眾多中國製造商們生產的廉價裝置來說，這種感受尤其如此。

幸運地是，Android 智能手機的品質和速度穩步提升，所以今天我們有過多適合每個人的預算和需要的新裝置。如果你想擁有一台手機，它有著很高的相機解析度、優秀的設計、強大的處理器和電量，這不是個問題——我們都有。

我個人最喜歡的品牌是摩托羅拉，它的手機—Moto X、Moto G和Moto E 都有著優美的線條，同時也的確有著很好的性價比。而在同時，Google 的一個團隊正力於模組化手機的開發。Project Ara 目標在於徹底動搖 Android 世界，如果一切進行順利，它有可能會來到人們面前。

Project Ara 部分下一步何去何從？ 遠離JAVA

我們已經解決了 IDE 和系統版本的大多數問題，我們就可以關注 Android 其他方面的問題。

恕我直言，在 Android 開發最核心的問題中最重要的問題是 Java。對不起，Java Harmony，基於 Java 7 或 Java6，但它不是 Java。不要讓我放錯——我堅信Java是一門好的程式設計語言，但是我也認為我們是時候打破常規了。我們需要開始尋找另外一門程式設計語言來代替 Java 成為 Android 開發的基礎語言。

看看我們最重要的競爭者—Apple。他們已經介紹了一門全新的語言，叫做 Swift，它結合了數個其他語言（如 Python、Ruby 或 C#）的最優特徵。我們已經比 iOS 開發人員開發同一應用需要更多的時間，而這會使我們更慢。

這就是為什麼我們需要新事物的加入了。我們已經有了關於哪個語言能夠代替Java的一些想法。我認為是 Groovy。它的文法與 Java 非常相似（實際上，它是基於 Java 的），我們也有一些工作原型了。同時，也不要忘了它是 Gradle 的主語言——所以，為什麼不把它用於Android 開發呢？或者也許是 Scala（它可以很快獲得新使用者），又或者是 Kotlin（Jake Wharton 最近寫了一篇很好的關於用於 Android 的 Kotlin 的概論）？

資料庫管理變得更好

我要支出另一個問題—資料庫管理 API。如果你再一次褻瀆 Andoird，看一眼我們的競爭者—iOS（核心資料，將更加精確）—你會看到他們確實有著優秀的方法和建立資料庫物件的GUI 和 CRUD 方法，資料庫變化監聽器。但是如果你回頭看下預設的 Android API ——我們還沒有遠離寫那些極大地影響我們開發進程的 SQL 命令。

調試 SQL 錯誤不是一件容易的事—它非常消耗時間，我們也沒有查看資料庫資料的GUI。儘管也有一些不錯的 ORM 庫（如 GreenDAO、ActiveAndroid 或 SugarORM），但是它們都有自己的問題。我從沒有對它們完全滿意—他們要不是使用很複雜，要不就是丟失一些東西（如資料庫改變監聽器）。我注意到了 Realm for Android 和 DBFlow，我希望他們會解決我所有的問題並且減少執行時間。

結論

Android 在過去的幾年發生了巨大的改變。它已經從一個簡單的智能手機系統進化為一個支援各種裝置的強大系統。時間會告訴我們 Android 將會變成怎樣。誰知道哪天我們會不會甚至可以用它來給核聚變反應堆編程，或者給”終結者“編程。PS. 顯然終結者更有趣。

 

這是本人課餘時間的翻譯，錯誤很多，還請耐心指出，謝謝！

原文連結：https://www.infinum.co/the-capsized-eight/articles/the-past-present-and-future-of-android-development

Android開發的過去、現在和將來