簡(jiǎn)介：Android 轉(zhuǎn) Java 開發(fā)在技術(shù)棧上有哪些差異？思考和解決問題時(shí)又會(huì)有怎樣的轉(zhuǎn)變？本文分享阿里技術(shù)專家從 Android 開發(fā)轉(zhuǎn) Java 應(yīng)用開發(fā)的心得感受，分析兩者差異及在動(dòng)態(tài)性、兼容性、內(nèi)存管理和狀態(tài)問題等方面的一些看法，并總結(jié)了在阿里做一個(gè) Android 開發(fā)和 Java 開發(fā)所需要的技術(shù)棧。

寫在前面

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

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

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

除了 Java 本身，其實(shí)都不一樣

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

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

• 從我個(gè)人學(xué) OC 的經(jīng)驗(yàn)看，我覺得 OC 同學(xué)學(xué) Java 還是要比 Java 同學(xué)學(xué) OC 簡(jiǎn)單多了，Java 更接近自然語言的表達(dá)，并且，好歹大家大學(xué)都還是學(xué)過一點(diǎn)的吧～
• 當(dāng)沒有了 Java 語言本身的優(yōu)勢(shì)，Android 與 Java 應(yīng)用幾乎沒有半毛錢關(guān)系，能直接拿來就用的框架微乎其微，硬要說還有優(yōu)勢(shì)的話，只能說 Android studio 也是基于 Intellij Idea 的，開發(fā)起來還算順手。

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

技術(shù)棧差異

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

Android 開發(fā)：

Java 應(yīng)用開發(fā)：

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

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

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

動(dòng)態(tài)性

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

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

• 使用動(dòng)態(tài)框架，從應(yīng)急修復(fù)到動(dòng)態(tài)發(fā)布，一方面是應(yīng)急，另一方面是加快版本迭代和收斂效率。那么，設(shè)計(jì)的業(yè)務(wù)框架、寫的組件是不是有動(dòng)態(tài)修改、擴(kuò)展的可能性，是否存在編譯、混淆優(yōu)化導(dǎo)致無法熱修復(fù)的風(fēng)險(xiǎn)，是設(shè)計(jì)和開發(fā)過程中要考慮的點(diǎn)。
• 無法挽回的發(fā)布。不僅僅是因?yàn)槊嫦蛴脩?#xff0c;只要發(fā)出去的版本有問題，大概率是沒有時(shí)間和機(jī)會(huì)挽回的，容易出較大的輿情和故障，所以客戶端的測(cè)試工作也會(huì)比較辛苦，全功能的回歸是發(fā)布前必走的流程。

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

兼容性

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

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

內(nèi)存管理

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

狀態(tài)問題

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

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

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

寫在最后

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

原文鏈接：https://developer.aliyun.com/article/766613?

版權(quán)聲明：本文中所有內(nèi)容均屬于阿里云開發(fā)者社區(qū)所有，任何媒體、網(wǎng)站或個(gè)人未經(jīng)阿里云開發(fā)者社區(qū)協(xié)議授權(quán)不得轉(zhuǎn)載、鏈接、轉(zhuǎn)貼或以其他方式復(fù)制發(fā)布/發(fā)表。申請(qǐng)授權(quán)請(qǐng)郵件developerteam@list.alibaba-inc.com，已獲得阿里云開發(fā)者社區(qū)協(xié)議授權(quán)的媒體、網(wǎng)站，在轉(zhuǎn)載使用時(shí)必須注明"稿件來源：阿里云開發(fā)者社區(qū)，原文作者姓名"，違者本社區(qū)將依法追究責(zé)任。 如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，歡迎發(fā)送郵件至：developer2020@service.aliyun.com 進(jìn)行舉報(bào)，并提供相關(guān)證據(jù)，一經(jīng)查實(shí)，本社區(qū)將立刻刪除涉嫌侵權(quán)內(nèi)容。

總結(jié)

以上是生活随笔為你收集整理的从 Android 到 Java：如何从不同视角解决问题？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。