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

寫在前面

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

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

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

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

從 Android 轉客戶端會更容易么

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

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

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

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

技術棧差異

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

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

思考問題的角度轉變

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

動態(tài)性

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

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

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

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

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

兼容性

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

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

內存管理

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

狀態(tài)問題

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

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

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

寫在最后

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

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