从Android到Java：如何从不同视角解决问题？
云棲號資訊：【點擊查看更多行業資訊】
在這里您可以找到不同行業的第一手的上云資訊，還在等什么，快來！
?
阿里妹導讀：Android 轉 Java 開發在技術棧上有哪些差異？思考和解決問題時又會有怎樣的轉變？本文分享阿里技術專家從 Android 開發轉 Java 應用開發的心得感受，分析兩者差異及在動態性、兼容性、內存管理和狀態問題等方面的一些看法，并總結了在阿里做一個 Android 開發和 Java 開發所需要的技術棧。
寫在前面
記得剛畢業那會兒，還是 BBA 爭霸的年代，無線迎來一個黃金年代，如同當下的 “AI” 和更早些年的 “云”，什么事都需要往熱點上靠一靠，基于 PC 的互聯網公司們無不發出 all in 無線的戰略口號，無線業務遍地開花，甚至一個公司每個產品線都恨不得出一個 App，直到現在再紛紛都向旗艦收攏，不過那都是后話了。
2013 年，就是在那樣的環境下，發生了幾件事情：iPhone 5s 發布、Android 升級到 4.3 版本，以及......我畢業了，哈哈。作為校招新人，對長遠職業規劃、技術棧發展潛力并沒有太多的認識，只是跟大多程序員一樣，都是希望能跟隨甚至推進業界的潮流，而不是以熟悉 Android 某個版本某個 API 得先設置個 false 否則會花屏這樣的二手知識為榮，但是很不幸，由于種種選擇和被選擇，最后錨定了百度上海的校招研發崗位，一下子集齊了我最討厭的兩樣東西：Java 和客戶端！
就這樣也踉踉蹌蹌在 Android 客戶端上耕耘了近 6 年之久，經歷了 2.3 與 4.0 的兼容地獄，webkit 到 chromium 的升級、dvm 到 art 的轉變以及熱修復、各類動態部署狂潮，Android studio 也從 0.9 Beta 到如今的 4.0，并完全消滅了上古的 Eclipse + ADT，也算是有點感情了。直到去年，終于有機會擁抱了變化，得益于團隊內有多個業務方向，避免了轉崗入坑，順利轉戰了 Java 應用戰場，如今也快到 1 年了，突然也有些感想，與大家分享。
除了 Java 本身，其實都不一樣
從 Android 轉客戶端會更容易么
陸續地，團隊也有其他同學投入到了 Java 應用的懷抱，向著 “全棧” 開發發展，其中還不乏之前做 IOS 客戶端開發的同學。閑暇之余，也會交流一些心得，比如 IOS 的同學會覺得 Android 轉 Java 開發占了比較大的優勢，從 IOS 轉就會顯得額外的困難，畢竟 OC 或 Swift 和 Java 大概長得完全不一樣，但從一個前 Android Dev 的視角來看，我在這方面的感受是：
- 從我個人學 OC 的經驗看，我覺得 OC 同學學 Java 還是要比 Java 同學學 OC 簡單多了，Java 更接近自然語言的表達，并且，好歹大家大學都還是學過一點的吧～
- 當沒有了 Java 語言本身的優勢，Android 與 Java 應用幾乎沒有半毛錢關系，能直接拿來就用的框架微乎其微，硬要說還有優勢的話，只能說 Android studio 也是基于 Intellij Idea 的，開發起來還算順手。
當然，不能說的太絕對，不然容易招杠精，畢竟 Java 本身是為那些框架能力提供鋪墊，客戶端也用了 DVM（類 JVM）的 JNI 能力來做熱修復，用了動態代理，甚至也有用 cglib、aspectJ 實現 AOP 的方案。但在一個生產環境中，一個語言本身提供的能力是完全不夠的，一個語言是否能被廣泛使用和接受，還有個主要因素就是得看生態，看社區，看大家貢獻的庫，這也是 Java 為什么雖然可能不是最好的語言，但仍然是使用最廣泛的語言的原因，從這個角度看，它們之間，除了語言，真的沒有太多相同的地方。
技術棧差異
以在阿里的生產環境為例，要做一個 Android 開發或者 Java 開發 “攻城獅”，你大概需要的知識圖譜如下（圖是根據自己的認知整理的，有不詳盡甚至錯誤的地方望指出）：
Android 開發：
?
?
Android 技術棧知識圖譜
Java 應用開發：
?
?
Java 技術棧知識圖譜
可以看到，從大類看其實都是通的，無非是基礎的框架、擴展的庫或中間件、以及一些列的發布、監控等支撐平臺，套路上無論做什么技術估計都是這樣吧，但偏向性卻有本質的區別。面向客戶端的 Android Framework 核心解決的問題是事件交互、生命周期、視圖繪制問題、處理人機交互的邏輯，而 Java 服務端常用的 Spring 框架核心更關心服務之間的耦合、依賴、面向大規模集群擴展的能力。基礎框架不同，必然類庫、中間件也會有本質的區別，幾乎就沒有共性了，這些由設計思路帶來的不同勢必也要求開發的同學需要在轉換開發角色時轉換思考方向。
思考問題的角度轉變
翻看以前的代碼，記得剛從 C/C++ 學 Java 的時候，還在學生的時代，總會喜歡一個 main 函數帶著一群 static 方法來實現主流程，又到后來學 Python 用于一些數據分析和腳本處理，也總是焦慮沒有地方聲明變量類型，對于 a = {} 這樣的 map 聲明方式也很不習慣，所以，不光是 do as Romas，Think as Romas 才是轉變中最重要的東西，不僅僅只是換了一些庫和工具。
動態性
動態性曾經是客戶端最為看中的能力，從熱修復到動態 dex loader，到 RN、Weex、Dinamic 一系列動態能力的建設，可以說是面試必考題。無論是 Android 菜鳥還是 Android 專家，都要讓你聊一聊你知道的動態技術方案以及他們之間的區別，幾個大廠之間的熱修復方案對比更是每個 Android Dev 都需要準備的分享 PPT，Android 如此，IOS 也不例外，直到 IOS 禁止了動態加載的能力。
對于客戶端來講，發布周期與服務端有著較大的區別，按照之前我們在手淘的集成經驗，Android 端覆蓋 80% 的用戶大概需要 3-5 天的時間。早些年更慢，因為還沒有 App 商店的統一靜默升級，還需要在各個應用市場更新或者推送更新，簡直五花八門，用戶也不勝其煩。IOS 會稍微好一些，古早就有了應用市場，但一個更新周期畢竟還是遠遠大于后端的周期，應用發布都是以分鐘最多是小時級別記。這樣的區別導致客戶端的開發過程必須要考慮：
- 使用動態框架，從應急修復到動態發布，一方面是應急，另一方面是加快版本迭代和收斂效率。那么，設計的業務框架、寫的組件是不是有動態修改、擴展的可能性，是否存在編譯、混淆優化導致無法熱修復的風險，是設計和開發過程中要考慮的點。
- 無法挽回的發布。不僅僅是因為面向用戶，只要發出去的版本有問題，大概率是沒有時間和機會挽回的，容易出較大的輿情和故障，所以客戶端的測試工作也會比較辛苦，全功能的回歸是發布前必走的流程。
但這些問題在 Java 應用上很不顯著，雖然也有熱部署的框架，但僅僅也是為了部署效率，并不會作為核心的能力提供。
兼容性
同樣是因為迭代周期長，并且無法做到真正全量更新，客戶端還會面臨一個較大的問題就是版本兼容。目前 Android 已經更新到 11 了，但市場上也不排除有 4.x 的版本，同樣，App 發展到 X 版本了，市場上同樣遍布這 1-N 的各個版本。版本覆蓋后的數據兼容，特別是 sqlite 升級，會讓 Android 的開發者們苦惱萬分，也經常容易出現問題而導致啟動閃退，被迫讓用戶重新安裝。同樣的問題在服務端還是比較少出現的，唯一可能的就是協議的變更，但往往也可以在短時間內進行共存和遷移。
除了端上數據的兼容性，另一個兼容性就是 API 及設備的兼容性，特別在 2.x 到 4.x 的年代。同樣的視圖實現在不同的 Android 機器上、在不同的 API Level 上都可能出現不同的表現，修改方案也往往顧此失彼，往往一次修改完就得所有主流機型回歸一遍，對于在 Android 中重 UI 的開發同學，簡直有摔手機的沖動。當然現在 API 日漸完善，compat 包也解決了很多兼容問題，開發體驗已有質的飛躍。從這方面說，Java 應用面臨的問題又要簡單不少，部署環境有問題？用 Docker 虛擬化！簡直樂無邊！
內存管理
但服務端應用并不意味著更簡單。老實說，去年差點沒被線上 FullGC 弄死。一大波流量進來，持續的 FullGC 導致集群假死，大量的服務超時引來客戶投訴，重啟擴容都無法解決，還得靠找到問題的根源后才能解決。FullGC 是 Java 應用常見的問題，但在客戶端是完全不需要關注的。客戶端分配給 App 的內存通常只會有 128M～256M，與服務端動輒幾個 G 的內存管理不能同日而語，并不過分關心 GC，除非是在極致的性能優化場景，更別說是用 G1 還是 CMS 了（當然 Android 也沒有）。通常只關心泄露和 OOM，畢竟 OOM 才是客戶端唯一的內存殺手，所以才有了大波的圖片加載庫，來解決對象的內存管理問題，畢竟一個 App 在你的手機里存活不太可能以天計，在前臺的時間更是少之又少，不太必要考慮長時間運行下的累積問題。
狀態問題
客戶端的狀態一般都是保存在頁面本身的。頁面、視圖作為一個對象，獲取數據，渲染，展現給用戶，并負責與用戶交互，反饋修改頁面狀態等一系列動作，幾乎把一個頁面內的所有行為狀態都封閉了起來，形成交互對象內的強耦合。但 Java Beans 可能并不是這么想，所有的 Beans 原則上都是無狀態的，數據由專門的 db 或中心存儲，這也是分布式系統的基本要求，這點上是設計思維的最大轉變。
客戶端有并發問題么，其實也有。Android 支持 AsyncTask，支持HandlerThread，甚至更底層的 Thread，Looper，但客戶端的線程數通常是個位數或者幾十個。異步線程的模型也相對簡單，一般都只是處理一些數據，畢竟 UI 刷新還得在主線程完成（SurfaceView，TextureView 除外），主要的邏輯都在主線程的交互事件處理，幾乎不存比較難解的同步問題。
但 Java 應用在這里面要考慮的東西就太多了，多線程同步、一致性、原子性、鎖，展開講可能一本書都講不完，或許這也是 Java 應用迷人的地方。
寫在最后
說了這么多，不善言辭，也是隨性發揮，想到啥說些啥，更多是對自己開發歷程的一些感受。要細說差別，還有太多沒有提及的方向，知識圖譜中的每個點拿出來都還可以細品。但想表達的無非還是在開發的過程中，每一行代碼，每一種設計模式的使用，思考的重點和角度都會有所不同。我們常常聽到 “全棧” 兩個字，但要我說，會多少語言，熟悉多少框架并不是全棧的含義，能嘗試不同的技術棧，從不同的視角來思考并解決問題，融會貫通，才是全棧賦予我們最大的價值，這也是我個人追求的技術之 “道”。
【云棲號在線課堂】每天都有產品技術專家分享！
課程地址：https://yqh.aliyun.com/live
立即加入社群，與專家面對面，及時了解課程最新動態！
【云棲號在線課堂 社群】https://c.tb.cn/F3.Z8gvnK
原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。
總結
以上是生活随笔為你收集整理的从Android到Java：如何从不同视角解决问题？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 基于MaxCompute Informa
- 下一篇： MaxCompute管家详解--管家助力