Alimei簡介：Android和Java開發(fā)在技術(shù)堆棧上有何區(qū)別? 思考和解決問題時會發(fā)生什么? 本文分享了從Android開發(fā)到Java應(yīng)用程序開發(fā)的Ali技術(shù)專家的經(jīng)驗，分析了兩者之間的差異以及一些關(guān)于動力學(xué)，兼容性，內(nèi)存管理和狀態(tài)問題的觀點 ，并概述了如何在Ali中實現(xiàn)Android和Java開發(fā)開發(fā)所需的技術(shù)堆棧。 在文章的結(jié)尾，有年中福利!

寫在前面

記得剛畢業(yè)那會兒，還是 BBA 爭霸的年代，無線迎來一個黃金年代，如同當(dāng)下的 “AI” 和更早些年的 “云”，什么事都需要往熱點上靠一靠，基于 PC 的互聯(lián)網(wǎng)公司們無不發(fā)出 all in 無線的戰(zhàn)略口號，無線業(yè)務(wù)遍地開花，甚至一個公司每個產(chǎn)品線都恨不得出一個 App，直到現(xiàn)在再紛紛都向旗艦收攏，不過那都是后話了。

2013 年，就是在那樣的環(huán)境下，發(fā)生了幾件事情：iPhone 5s 發(fā)布、Android 升級到 4.3 版本，以及......我畢業(yè)了，哈哈。作為校招新人，對長遠職業(yè)規(guī)劃、技術(shù)棧發(fā)展?jié)摿Σ]有太多的認識，只是跟大多程序員一樣，都是希望能跟隨甚至推進業(yè)界的潮流，而不是以熟悉 Android 某個版本某個 API 得先設(shè)置個 false 否則會花屏這樣的二手知識為榮，但是很不幸，由于種種選擇和被選擇，最后錨定了百度上海的校招研發(fā)崗位，一下子集齊了我最討厭的兩樣?xùn)|西：Java 和客戶端!

就這樣也踉踉蹌蹌在 Android 客戶端上耕耘了近 6 年之久，經(jīng)歷了 2.3 與 4.0 的兼容地獄，webkit 到 chromium 的升級、dvm 到 art 的轉(zhuǎn)變以及熱修復(fù)、各類動態(tài)部署狂潮，Android studio 也從 0.9 Beta 到如今的 4.0，并完全消滅了上古的 Eclipse + ADT，也算是有點感情了。直到去年，終于有機會擁抱了變化，得益于團隊內(nèi)有多個業(yè)務(wù)方向，避免了轉(zhuǎn)崗入坑，順利轉(zhuǎn)戰(zhàn)了 Java 應(yīng)用戰(zhàn)場，如今也快到 1 年了，突然也有些感想，與大家分享。

除了 Java 本身，其實都不一樣

從 Android 轉(zhuǎn)客戶端會更容易么

陸續(xù)地，團隊也有其他同學(xué)投入到了 Java 應(yīng)用的懷抱，向著 “全?！?開發(fā)發(fā)展，其中還不乏之前做 IOS 客戶端開發(fā)的同學(xué)。閑暇之余，也會交流一些心得，比如 IOS 的同學(xué)會覺得 Android 轉(zhuǎn) Java 開發(fā)占了比較大的優(yōu)勢，從 IOS 轉(zhuǎn)就會顯得額外的困難，畢竟 OC 或 Swift 和 Java 大概長得完全不一樣，但從一個前 Android Dev 的視角來看，我在這方面的感受是：

從我個人學(xué) OC 的經(jīng)驗看，我覺得 OC 同學(xué)學(xué) Java 還是要比 Java 同學(xué)學(xué) OC 簡單多了，Java 更接近自然語言的表達，并且，好歹大家大學(xué)都還是學(xué)過一點的吧～

當(dāng)沒有了 Java 語言本身的優(yōu)勢，Android 與 Java 應(yīng)用幾乎沒有半毛錢關(guān)系，能直接拿來就用的框架微乎其微，硬要說還有優(yōu)勢的話，只能說 Android studio 也是基于 Intellij Idea 的，開發(fā)起來還算順手。

當(dāng)然，不能說的太絕對，不然容易招杠精，畢竟 Java 本身是為那些框架能力提供鋪墊，客戶端也用了 DVM(類 JVM)的 JNI 能力來做熱修復(fù)，用了動態(tài)代理，甚至也有用 cglib、aspectJ 實現(xiàn) AOP 的方案。但在一個生產(chǎn)環(huán)境中，一個語言本身提供的能力是完全不夠的，一個語言是否能被廣泛使用和接受，還有個主要因素就是得看生態(tài)，看社區(qū)，看大家貢獻的庫，這也是 Java 為什么雖然可能不是最好的語言，但仍然是使用最廣泛的語言的原因，從這個角度看，它們之間，除了語言，真的沒有太多相同的地方。

技術(shù)棧差異

以在阿里的生產(chǎn)環(huán)境為例，要做一個 Android 開發(fā)或者 Java 開發(fā) “攻城獅”，你大概需要的知識圖譜如下(圖是根據(jù)自己的認知整理的，有不詳盡甚至錯誤的地方望指出)：

可以看到，從大類看其實都是通的，無非是基礎(chǔ)的框架、擴展的庫或中間件、以及一些列的發(fā)布、監(jiān)控等支撐平臺，套路上無論做什么技術(shù)估計都是這樣吧，但偏向性卻有本質(zhì)的區(qū)別。面向客戶端的 Android Framework 核心解決的問題是事件交互、生命周期、視圖繪制問題、處理人機交互的邏輯，而 Java 服務(wù)端常用的 Spring 框架核心更關(guān)心服務(wù)之間的耦合、依賴、面向大規(guī)模集群擴展的能力。基礎(chǔ)框架不同，必然類庫、中間件也會有本質(zhì)的區(qū)別，幾乎就沒有共性了，這些由設(shè)計思路帶來的不同勢必也要求開發(fā)的同學(xué)需要在轉(zhuǎn)換開發(fā)角色時轉(zhuǎn)換思考方向。

思考問題的角度轉(zhuǎn)變

翻看以前的代碼，記得剛從 C/C++ 學(xué) Java 的時候，還在學(xué)生的時代，總會喜歡一個 main 函數(shù)帶著一群 static 方法來實現(xiàn)主流程，又到后來學(xué) Python 用于一些數(shù)據(jù)分析和腳本處理，也總是焦慮沒有地方聲明變量類型，對于 a = {} 這樣的 map 聲明方式也很不習(xí)慣，所以，不光是 do as Romas，Think as Romas 才是轉(zhuǎn)變中最重要的東西，不僅僅只是換了一些庫和工具。

動態(tài)性

動態(tài)性曾經(jīng)是客戶端最為看中的能力，從熱修復(fù)到動態(tài) dex loader，到 RN、Weex、Dinamic 一系列動態(tài)能力的建設(shè)，可以說是面試必考題。無論是 Android 菜鳥還是 Android 專家，都要讓你聊一聊你知道的動態(tài)技術(shù)方案以及他們之間的區(qū)別，幾個大廠之間的熱修復(fù)方案對比更是每個 Android Dev 都需要準(zhǔn)備的分享 PPT，Android 如此，IOS 也不例外，直到 IOS 禁止了動態(tài)加載的能力。

對于客戶端來講，發(fā)布周期與服務(wù)端有著較大的區(qū)別，按照之前我們在手淘的集成經(jīng)驗，Android 端覆蓋 80% 的用戶大概需要 3-5 天的時間。早些年更慢，因為還沒有 App 商店的統(tǒng)一靜默升級，還需要在各個應(yīng)用市場更新或者推送更新，簡直五花八門，用戶也不勝其煩。IOS 會稍微好一些，古早就有了應(yīng)用市場，但一個更新周期畢竟還是遠遠大于后端的周期，應(yīng)用發(fā)布都是以分鐘最多是小時級別記。這樣的區(qū)別導(dǎo)致客戶端的開發(fā)過程必須要考慮：

使用動態(tài)框架，從應(yīng)急修復(fù)到動態(tài)發(fā)布，一方面是應(yīng)急，另一方面是加快版本迭代和收斂效率。那么，設(shè)計的業(yè)務(wù)框架、寫的組件是不是有動態(tài)修改、擴展的可能性，是否存在編譯、混淆優(yōu)化導(dǎo)致無法熱修復(fù)的風(fēng)險，是設(shè)計和開發(fā)過程中要考慮的點。

無法挽回的發(fā)布。不僅僅是因為面向用戶，只要發(fā)出去的版本有問題，大概率是沒有時間和機會挽回的，容易出較大的輿情和故障，所以客戶端的測試工作也會比較辛苦，全功能的回歸是發(fā)布前必走的流程。

但這些問題在 Java 應(yīng)用上很不顯著，雖然也有熱部署的框架，但僅僅也是為了部署效率，并不會作為核心的能力提供。

兼容性

同樣是因為迭代周期長，并且無法做到真正全量更新，客戶端還會面臨一個較大的問題就是版本兼容。目前 Android 已經(jīng)更新到 11 了，但市場上也不排除有 4.x 的版本，同樣，App 發(fā)展到 X 版本了，市場上同樣遍布這 1-N 的各個版本。版本覆蓋后的數(shù)據(jù)兼容，特別是 sqlite 升級，會讓 Android 的開發(fā)者們苦惱萬分，也經(jīng)常容易出現(xiàn)問題而導(dǎo)致啟動閃退，被迫讓用戶重新安裝。同樣的問題在服務(wù)端還是比較少出現(xiàn)的，唯一可能的就是協(xié)議的變更，但往往也可以在短時間內(nèi)進行共存和遷移。

除了端上數(shù)據(jù)的兼容性，另一個兼容性就是 API 及設(shè)備的兼容性，特別在 2.x 到 4.x 的年代。同樣的視圖實現(xiàn)在不同的 Android 機器上、在不同的 API Level 上都可能出現(xiàn)不同的表現(xiàn)，修改方案也往往顧此失彼，往往一次修改完就得所有主流機型回歸一遍，對于在 Android 中重 UI 的開發(fā)同學(xué)，簡直有摔手機的沖動。當(dāng)然現(xiàn)在 API 日漸完善，compat 包也解決了很多兼容問題，開發(fā)體驗已有質(zhì)的飛躍。從這方面說，Java 應(yīng)用面臨的問題又要簡單不少，部署環(huán)境有問題?用 Docker 虛擬化!簡直樂無邊!

內(nèi)存管理

但服務(wù)端應(yīng)用并不意味著更簡單。老實說，去年差點沒被線上 FullGC 弄死。一大波流量進來，持續(xù)的 FullGC 導(dǎo)致集群假死，大量的服務(wù)超時引來客戶投訴，重啟擴容都無法解決，還得靠找到問題的根源后才能解決。FullGC 是 Java 應(yīng)用常見的問題，但在客戶端是完全不需要關(guān)注的。客戶端分配給 App 的內(nèi)存通常只會有 128M～256M，與服務(wù)端動輒幾個 G 的內(nèi)存管理不能同日而語，并不過分關(guān)心 GC，除非是在極致的性能優(yōu)化場景，更別說是用 G1 還是 CMS 了(當(dāng)然 Android 也沒有)。通常只關(guān)心泄露和 OOM，畢竟 OOM 才是客戶端唯一的內(nèi)存殺手，所以才有了大波的圖片加載庫，來解決對象的內(nèi)存管理問題，畢竟一個 App 在你的手機里存活不太可能以天計，在前臺的時間更是少之又少，不太必要考慮長時間運行下的累積問題。

狀態(tài)問題

客戶端的狀態(tài)一般都是保存在頁面本身的。頁面、視圖作為一個對象，獲取數(shù)據(jù)，渲染，展現(xiàn)給用戶，并負責(zé)與用戶交互，反饋修改頁面狀態(tài)等一系列動作，幾乎把一個頁面內(nèi)的所有行為狀態(tài)都封閉了起來，形成交互對象內(nèi)的強耦合。但 Java Beans 可能并不是這么想，所有的 Beans 原則上都是無狀態(tài)的，數(shù)據(jù)由專門的 db 或中心存儲，這也是分布式系統(tǒng)的基本要求，這點上是設(shè)計思維的最大轉(zhuǎn)變。

客戶端有并發(fā)問題么，其實也有。Android 支持 AsyncTask，支持HandlerThread，甚至更底層的 Thread，Looper，但客戶端的線程數(shù)通常是個位數(shù)或者幾十個。異步線程的模型也相對簡單，一般都只是處理一些數(shù)據(jù)，畢竟 UI 刷新還得在主線程完成(SurfaceView，TextureView 除外)，主要的邏輯都在主線程的交互事件處理，幾乎不存比較難解的同步問題。

但 Java 應(yīng)用在這里面要考慮的東西就太多了，多線程同步、一致性、原子性、鎖，展開講可能一本書都講不完，或許這也是 Java 應(yīng)用迷人的地方。

寫在最后

說了這么多，不善言辭，也是隨性發(fā)揮，想到啥說些啥，更多是對自己開發(fā)歷程的一些感受。要細說差別，還有太多沒有提及的方向，知識圖譜中的每個點拿出來都還可以細品。但想表達的無非還是在開發(fā)的過程中，每一行代碼，每一種設(shè)計模式的使用，思考的重點和角度都會有所不同。我們常常聽到 “全?！? 兩個字，但要我說，會多少語言，熟悉多少框架并不是全棧的含義，能嘗試不同的技術(shù)棧，從不同的視角來思考并解決問題，融會貫通，才是全棧賦予我們最大的價值，這也是我個人追求的技術(shù)之 “道”。

80+ 阿里技術(shù)電子書覆蓋 Java、物聯(lián)網(wǎng)、云原生、前端、大數(shù)據(jù)、開源、AI 等技術(shù)領(lǐng)域，深度分享阿里工程師實踐精華，頂級技術(shù)內(nèi)容一手掌握。上半年大會資料合集含 2020 阿里云峰會、Flink Forward 全球在線會議等。