• Android 開發的昨天、今天和明天

    1
    Android HTML C/C++ Go 25131 次瀏覽

    收到過位將要畢業的同學的來信,問 Android 開發是否有「前途」。我個人從前端轉到移動相關的工作也有些時日,雖然期間有點心得但回復類似的問題不免會有「誤人子弟」的擔憂。

    剛好在 Android Weekly 上見到了這篇文章,闡述的部分觀點竟然和我不謀而合,因此草譯下權當有相關問題的同學作為參考。同時,國內的 Android 環境可以用「奇葩」來形容,因此文章后面我會加入些自己的個人觀點。

    混沌之初

    很難相信,如此的一個系統竟然會有 80% 的市場占有量!在我個人看來,Android 能夠做到如此成功在早期并不是它足夠的優秀,而是同期的競爭對手做得比它更好。

    為什么?我親愛的讀者,在那個時候到處都是問題好嗎:

    糟糕的開發工具(甚至包括 IDE)

    你嘗試過用鐵鍬修車嗎?或者,開著你爺爺曾經使用過的有著 40 年歷史的 Yugo 載著姑娘去兜風?在那個時代 Android 開發有且只有一個「相對」官方的開發工具:Eclipse 。

    請您相信我,Eclipse 有各種的問題甚至能讓你在十分鐘之內發瘋!Eclipse 的 ADT 插件簡直就是「Bug 與 Crash 齊飛,重啟和關閉共一色」。尤其在相對復雜的項目開發上,那酸爽簡直不敢相信!

    很大的程度上,光就是 Eclipse 這個開發工具就嚇到了很多入門開發者,讓他們投入其他開發陣營的懷抱(對,例如 XCode)。

    碎片化

    Android 的碎片化嚴重得可以用張麻子臉上的痘痘來形容,我們先來說說軟件方面的。Gingerbread (2.3.7) 是相對比較老的系統版本了,對比同期的 iOS 4.x 系列,目前還有百分之 15-20 個點(可能具體地區的占有率稍有不同)。

    您或許已經知道,Android 4.0(Ice Cream Sandwich) 是一個巨大革新的版本,新的 UI、新的 API、新的屏幕分辨率,這一切看起來非常的美好。但,緩慢的用戶遷移過程讓我們不得不面對這些優秀新系統特性的同時,同時還需要兼容那老舊的系統。于是 為了兼容新老的兩套系統,項目開發中多了非常多的兼容代碼,這會使得應用到處是 Bug 和奔潰。

    (這段譯者自己添加,吐槽我最擅長了。)除了軟件方面,硬件的碎片化的問題更加的嚴重。你甚至不了解你的應用會在什么樣的硬件上運行,你需要獲取用 戶的位置信息,對不起設備可能沒有 GPS 甚至沒有基站定位;你需要打開攝像頭掃描二維碼,對不起設備可能沒有攝像頭、即便有攝像頭但運行內存不夠,崩潰!這個時候用戶是嫌棄自己的硬件呢,還是說 您的應用有問題…

    硬件方面最頭疼的還是屏幕分辨率的問題,Android 開發過程中在資源(resource)目錄下有各種的目錄(drawable-xxhdpi、drawable-xhdpi、drawable- mhdpi、etc…),你需要針對不同的分辨率調整自己的資源文件,對相信我這塊有時候會比編碼的時間還長!

    緩慢的模擬器

    當你完成一個應用以后,首先要測試在各個不同 Android 版本以及屏幕分辨率下的運行情況,所以我們購置了不下二十臺 Android 設備用于測試。

    聽起來似乎有點夸張?好吧,感謝上帝我們還有 Android 模擬器!

    然后,你興沖沖的跑去建立 Android 模擬器并嘗試讓它跑起來,你會發現半小時后你會哭!先不說它那緩慢的運行速度,就連調試過程中你甚至會開始思考你的人生。

    從此以后你再也沒有勇氣打開運行過它,它只是成為你機子文件系統中一塊占用地方的文件而已。

    UI

    「設計 Android 應用是多么得無趣!」如果你對比過同期的 iOS 應用,那么 Android 的應用竟然會如此得暗淡無色。對比 iOS 那流暢的動畫、交互以及細節,你會覺得 Android 應用一切都是「靜止」的!

    當你打算給 Android 添加點生氣的時候,你會發現還是那些老舊的系統(例如 Gingerbread)囚禁了你的創意和思想、乃至期望。

    全新

    我們將時間推倒 2013 年,這些糟糕的事情總算有了一些改變。

    那個時候問題已經足夠糟糕到連 Google 自己都看不下去的程度,即便 Android 4.0 發布至今對于上面的問題稍微有些緩解,但還不足夠達到能夠徹底解決問題的程度。

    直到 Android 5.0(Lollipop) 的發布。

    所有人都在思考 - Google、設備提供商、開發者。所有人都會自問這樣的問題,就是「當我們有了個相對穩定的系統、上千萬的應用以及對應的用戶。那么我們應當如何讓 Android 這個巨無霸化繁為簡?如何將開發的過程變得優雅、吸引更多的人加入這個行列?」

    Android 5.0(Lollipop) 有著巨大得改變,那些非常多的特性出于篇幅的考慮我只能列出我個人認為重要的幾個點:

    Android Studio

    Android Studio 在 1.0 版本以后就變得非常的穩定。我無法從只言片語來描述這個應用能夠給我們帶來的巨大的變革。如果您愿意了解詳細信息,可以參看原先我寫的兩篇文章(這里這里)。

    The new Android Studio logo

    這個 IDE 是如此的優秀,以至于 Eclipse ADT 插件已經停止了官方的維護,因此嚴重推薦原先如果開發 Android 的同學遷移到這個 IDE 上。

    人生苦短、及時行樂。

    Gradle

    Gradle 是個全自動化的構建工具,在 Android Studio 已經全面替代了 Apache Ant 作為主要的構建系統。

    這個全新的系統將會給構建 Android 應用帶來全新的體驗(聽著耳熟?)。當您設置好構建配置腳本以后,所有剩下的事情都將不用你操心。

    譯者注:Gradle 在大陸使用建議還是需要掛代理,Sigh…

    Lollipop

    Google 說過 Lollipop 是有史以來變革最大的系統版本(每次它都這樣說),我希望他們是對的。

    同時,也希望目前的主流機型能夠升級到這個版本(譯者:個人覺得原文作者有些樂觀)。

    Lollipop 之外 - Material Design

    理所當然,作為 Lollipop 提出的重點之一,自然會有很多的筆墨來闡述 Material Design 這個新的設計理念。我個人非常同意 Material Design 的其中之一的理念,那就是「所有的東西都是重要的(everything is important)」。

    One animation, please

    例如動畫,長期以來我們的觀點是動畫只是 效果 的一部分,而 Material Design 主張動畫也是有 含義 的,就好比文章分段的間隔符。

    我們重新設計、重新開發符合 Material Design 的應用,最終的目的在于應用并不僅僅是生活的一部分,而是能像水和空氣一樣夠讓它融入到生活中的每處,讓它無處不在。

    這就為了以后即便在不同的平臺下不同的應用看起來風格和體驗也是統一的。

    Lollipop 之內 - ART

    對于 Material Design 提供的外在設計元素,我們開發人員最關注的還是其內在的改變。一個新的運行時(runtime system)稱之為 ART 的就內在其中。

    其實 ART 并不是新鮮事物,首次出現應該在 Android 4.4(Kitkat)中。我們之所以重新介紹它是因為在 Lollipop 中 ART 已經全面替代了 Dalvik 成為系統默認的運行時(runtime system)。

    ART 有很多優秀的特性,處于篇幅考慮我只說明其中兩點:

    • 使用前置編譯 AOT (ahead-of-time) 。這意味著 ART 模式下,代碼被直接編譯為機器指令,程序運行時直接執行機器指令。這能帶來更快的執行速度以及更小的 CPU 損耗以及更長的電池時間,當然另一面就是安裝時間可能會變長。
    • 支持更多的方法數量(multidex support)。Dalvik 的每個 dex 字節文件只支持 65,356 個方法。這使得我們單個應用無法支持超過這個數量的方法數量。雖然這個數量看起來非常的龐大,但如果我們將例如 Google Play、以及其他的庫加入到項目中,那么剩余我們能夠使用的方法數量將會大大的減少,甚至不夠用。ART 中將重新整理字節碼文件分割到不同的 dex 文件中,同時再整合到單個 APK 安裝文件中,從而避免了這個問題。

    譯注,針對這塊下面有評論,可以參考

    Note that ART still has the same 65k method limit. Multidex support applies to Dalvik as well.
    As an addition to the improvements you mentioned, I would add the unit testing support they just released with version 1.1.0 of AS. Hopefully it's a fresh start for better testing of Android apps out of the box. It also works great with Robolectric.

     

    到處都是 Android

    現在我們已經可以開始針對智能手表、電視、甚至汽車編寫應用。想象下我們坐下來煮上一杯熱咖啡,環顧四周將來可能至少有四五個設備運行著 Android 系統:電視、筆記本、平板、相機、乃至廚房電器。

    Android 開始逐漸占領所有具有微處理器的設備,猶如水和空氣一般得存在。

    逐漸高品質的智能手機

    Android 的核心平臺還是其智能手機這塊,但長期以來一直所受的困擾就是運行其系統的智能手機品質差次不齊。老的 Anroid 設備運行起來對比其同時代的 iPhone 設備顯得非常的卡頓 - iOS 卻依然流暢得多。這「得益于」那些國產廠商提供的眾多低端機型。(譯者注:原文 This was especially true for cheaper devices produced by a multitude of Chinese manufacturers. 華強北再次被黑)。

    值得慶幸的是隨著硬件設備的摩爾定律,目前的 Android 智能手機設備提供商正在逐漸的改變這一現狀。很可能在不遠的將來,我們能夠得到一臺性能足夠強大但同時性能不差的 Android 智能手機。

    例如我個人非常喜歡 Motorola 提供的智能手機(雖然它目前已經是 Lenovo 的子公司),他們出品的 Moto X、Moto G、Moto E 等型號的手機都有著不俗的性價比。

    Project Ara parts

    同時有個叫 Ara 的項目能夠提供類似 PC 的模塊化硬件解決和組裝方案,在未來相信 Android 智能手機硬件平臺這塊能夠得到非常樂觀的發展。

    下一步?

    遠離 Java

    當解決完系統和開發工具層面的問題以后,我們繼續將 Android 相關的問題聚集到其他地方。

    恕我直言,我認為針對 Android 最核心的問題將會是 Java,尤其是 Java6 或者 Java7。Java 是門非常的好的語言,但有時候我們可以考慮跳出這個圈子去思考 - 我們或許針對 Android 開發需要門更新的語言。

    作為對比的 Apple ,他們的 Swift 提供了更新以及更現代的特性。這使得它能夠支持 iOS 開發人員更便捷的開發應用。明顯,Java 在這方面比現代的語言臃腫些。

    是時候我們需要更新鮮點的內容了,目前其實已經有了針對 Java 的替代方案,例如我原先關注的 Groovy。它從語法方面和 Java 很接近(實際上它基于 Java),同時我們針對此開發已經有了些原型。 當然,還有別忘記了它是 Gradle 的主要實現語言 - 所以為什么不直接用于 Android 開發呢?

    同時,Scala (使用數增長迅速)以及 Kotlin (這里有篇文章或許能讓你熱血澎湃)也是非常好的考慮對象。

    更好的數據管理

    還有個必須指出的問題,就是數據管理 API(database management API)。如果你有對比,例如 iOS(嚴格上說應該是 Core Data),他們提供了眾多非常好的抽象方法(method)、圖形化的數據管理、對象、數據觀察者(database change listeners)等。對比 Android 提供的 API,這簡直就像是只土鱉 - 我們仍然在寫 SQL 語句并同時期望得到正確的結果。

    調試 SQL 語句是件非常不容易的事情,首先需要面對的問題就是我們沒有個直觀的圖形化界面去跟蹤這些事務。雖然目前已經有些很優秀的 ORM 類庫供我們使用(例如 GreenDAOActiveAndroid、或者 SugarORM),但實際上他們仍然各自有各自的問題。

    我還是期待能夠像 iOS 一樣操作數據庫,例如有個數據觀察者(database change listeners)等類似工具幫忙。目前能夠找到的就類似 DBFlow 等第三方的類庫,至少目前而言他們能減少和減輕我很多工作量。

    中國的情況(譯者加)

    很明顯,國內的 Android 開發環境比國外的冷酷很多。除了上文提到的問題外,還有因為些政策以及特色的原因造成各種本地化的問題。

    缺少 Google 組件包

    或者說完全無法使用 Google 提供的服務。我們單說推送服務,Google 官方是提供了推送服務的,但是由于各種方面的原因國內的開發者基本上不會使用。這使得各家自己實現推送方案,從而惡性循環造成應用的品質下降。

    無厘頭的優化

    國內的 Android 用戶有「清理內存、殺進程」的習慣,因此很多正常運行的 Service 會被莫名得 kill 掉,而開發人員為了避免被 kill 又頻繁的啟動后臺 Service ,惡性循環。

    同時各固件廠商所做得優化有時候不得法,胡亂更改系統底層。例如某固件更改了 TextView 等導致應用顯示「怪異」的情況時有出現。

    設計方面 iOS 化

    這點不用多言,Material Design 即便出來有些時日,但幾乎沒有跟進的跡象。甚至部分廠商提供的 Android 版本的應用無論從交互還是視覺上和 iOS 版本相差無幾。

    我個人很悲觀的認為這種情況將會持續很久。

    低端機型肆虐

    正如原文作者所言,國產尤其是華強北出品的大批低端山寨機進一步打碎了 Android 系統的體驗。想象下 Android 開發者開發的應用還需要面對的幾年前的機型、這在 iOS 平臺是無法想象的;同時這造成的巨大的資源浪費以及應用品質的下降。

    總結

    那么 Android 開發的出路在哪里?這個問題直到本文結束可能都沒有個標準答案。我相信能夠提供良好的 Android 體驗的往往是些小型的開發團隊,相比大公司的團隊而言他們的創新思維、試錯能力、反應能力會比巨無霸們更強更快。

    而 Android 系統本身經過幾個大版本的進化以后路線也逐漸的清晰,相信除去目前的智能手機領域外,在其他的平臺上也會逐漸得發力。

    這點,能看得到。

     

     


    原文  http://www.gracecode.com/posts/the-past-present-and-future-of-android-development.html

    相似問題

    相關經驗

    相關資訊

    相關文檔

  • sesese色