Android 技術的下半場

wingjay發表於2019-03-25

越來越多的人在提“移動端的下半場”、“Android開發的焦慮”之類的，也有人在喊“技術天天在變，學也學不完”，“昨天Kotlin今天Flutter”。其實我卻認為，如果你技術達到了一定程度，你無需太過在意這些。

移動端真正進入下半場了嗎？於我看來並沒有，最多說“Android技術的探索”進入了下半場，而整個市場還是樂觀的。以前是BAT的天下，而近兩年出來越來越多的獨角獸：頭條、抖音、拼多多、快手、小猿搜題等，這些公司的業務都在移動端上，他們需要招聘更多的移動端人才。如果真要說下半場，只能說很多小型創業公司在退出市場，這確實會導致很多入門工程師失業，但這也說明了這個行業在更加規範。

而且，對於Android工程師而言，這更是個好的時代。網際網路下沉，那麼下沉市場裡的使用者是使用Android多還是iOS多，大家都清楚。

那麼，對於工程師而言需要做什麼才能存活呢？很簡單，要麼轉行，要麼提高。我相信，一個技術不錯的工程師，不但無需焦慮，而且在這個時代，能夠擁有穩定的職業生涯和豐厚的收入。

Android技術的下半場

要說下半場，我更願意說是“Android技術的下半場”，隨著這幾年大量的工程師和公司投入研發，Android技術已經從最早的簡單頁面，到越來越複雜的互動，再到動態化、外掛化等新技術和黑科技，這個領域的深度在不斷加深。

如果想成為優秀、不擔心淘汰的工程師，絕不是一味跟風新技術，今天學Kotlin、明天學Flutter，疲於奔命；而應該持續努力去完善自己的知識體系，保持一定的技術深度。

因此，本專欄希望在大家做UI、介面開發之餘，分享一些Android架構方面的知識和技能。

希望且相信這些技能能夠讓讀者真正擺脫技術焦慮，最終找到自己的方向和競爭力。

業務同學需要了解架構嗎？

有的同學會問，我平常都在寫業務程式碼、寫頁面、呼叫SDK，有必要去了解架構嗎？答案很簡單，業務是表，架構是裡。變化萬千的業務背後都是大同小異的架構。時代更迭，業務變遷，理解架構的技術人員可以處變不驚，而非疲於奔命。

因此，本人建議業務同學在繁重的業務開發之餘，可以多去研究一些底層庫原理，而非停留在花式呼叫SDK的階段，這會讓你具備更強的技術競爭力。

架構孵化於業務，服務於業務

不少公司的架構同學和業務同學都存在一種矛盾：架構與業務互相獨立，導致輸出的技術總是不能很好的滿足業務需求，導致的結果是：架構同學有心無力，業務同學有苦難言。

實際上，真正好的架構是從業務中孵化出來的，而且能服務於更廣闊的業務形態。

舉幾個例子大家就清楚了。

大家都知道阿里主營電商業務，而電商是強運營的，所以對於動態化有非常強的需求，也就是希望App儘可能像網頁一樣，能夠隨時更新頁面內容。於是，阿里內部孵化出了Weex，通過遠端開發部署js程式碼，即可實時更新頁面內容；

另外，手淘App對於整個阿里集團的戰略意義非常大，它不僅是盈利怪獸，而且是整個集團的流量入口（手淘DAU自2015年即達1.1億）。這也就是阿里曾提出的“航母策略”：手淘如一座航母，集團內各種業務形態如飛豬、閒魚、天貓等都可坐落在其上。於是，Atlas誕生了，所有App都可以輕鬆整合到手淘上，享受流量滋養。

類似的例子還有很多，比如大家熟知的微信，需要保證訊息在任何複雜網路下都能有最高的到達率。因此微信自研了一套跨平臺長連線方案，提出智慧心跳方案、多種弱網應對策略如多級超時等，最終推出了Mars，保證了全國各種網路環境下的使用者都能穩定的收發訊息。

有些同學可能瞭解阿里15年提出的“大中臺，小前臺戰略”，搭建集團資料中臺、技術中臺，幫助各種前臺業務快跑前進；這樣的技術架構和組織架構幫助阿里快速孵化出各種新的業務，比如18年初的淘寶特價版，據朋友瞭解整個App從啟動到上線只用了短短一個多月的時間。今年，騰訊組織架構調整，擔任CTO的張志東就提到：“沒有能幫助到公司級的資料中臺建設，我個人也蠻遺憾。”，自此騰訊也正式啟動了“中臺架構”建設。

所以說，不同的業務形態，能孵化出特有的架構。

架構是根，扎得越深，業務才越能開枝散葉。

專欄技術圖譜

閒話說了不少，下面正式談一談本專欄會覆蓋的一些技術點吧。這些技術點會基於本人日常的工作積累，同時結合各大廠開源的技術體系，（當然對於阿里閉源的會盡量規避掉，線下可以做一些技術探討）。

下面，我把後面專欄會覆蓋到的技術點列出來，當然在寫作的過程中還會逐步調整。

動態化專題由於App獲客成本不斷提高，動態化是近年來越來越重要的技術架構，例如React Native、小程式、快應用等都在試圖讓App具備實時更新、隨手可得。本專題會對各廠提出的動態化方案進行分析，如JsBridge；包括小程式方案的一些實現思路，比如多程式的H5容器架構；另外，還會分析一些適用於移動平臺的動態化程式語言如Lua，Javascript等。
圖片專題對於億級App而言，圖片的任何優化都對於流量、體驗等具有重要意義。比如Google+ App採用 WebP 圖片格式後，每天節省了 50TB資料儲存空間。因此，本專題會談一下各大廠如騰訊、FB、Google等在圖片優化方面提出過哪些方案，比如WebP vs SharpP；另外也會分析一些大家用的比較多的Glide、Fresco是如何做圖片快取、如何基於Dalvik/Art不同的記憶體結構來優化。
省流專題上面談到了圖片的壓縮，其實節省流量是一個永恆的話題，它不僅能改善使用者體驗，也能幫助減少使用者流量開銷，節省公司成本。因此，本專題會談一談如何監控Android流量；有哪些常用的Diff及壓縮演算法，比如Tinker裡自研的Diff演算法 vs Google提出的google-diff vs BsDiff等；如何選用資料通訊格式如json、ProtoBuf；FastJson、Jackson各自的優勢等等。
網路專題大多數業務同學對網路的認識就是OkHttp+Json解析，實際上，網路這一塊還存在非常多值得研究的技術點。一個優質的App，除了在網路良好的環境下執行，更重要的是，必須在弱網、網路劫持、網路慢等複雜環境下也要良好執行，而且還得快，這也就涉及到DNS加速、網路結果快取等。之前大廠都在提“頁面秒開”的概念，頁面開啟速度很大程度取決於當下的網路環境，也對於使用者體驗和留存有非常大的影響。這個專題我們談談網路相關的技術點。
監控與日誌專題對於監控和日誌，多數人的印象是整合一個第三方SDK，如Fabric、Bugly等。業務同學或許對日誌瞭解不是特別多，但實際上日誌是至關重要的，尤其是在排查複雜問題時。本專題我們談一下如何做到日誌不丟失，如何後臺上報且不影響App執行，最有意思的一點：如何利用長連線等技術，實時拉取任意使用者的本地詳細日誌。
安全專題安全專題就離多數比較遠了，這裡我們講解一些常見的和業務相關的安全話題，具體後續補充。
高可用專題後續補充
GC專題後續補充

專題計劃技術點列表

動態化專題
- 如何讓JavaScript與App互動
- 如何實現“即點即用”之小程式、快應用
- H5容器之多程式架構
- 動態化程式設計之Lua
- ...等
圖片專題
- 圖片壓縮之WebP與騰訊SharpP的實現機制
- 圖片記憶體優化之Glide和Fresco原理篇
- png jpg等常用圖片格式的記憶體、解壓速度分析
- ...等
省流專題
- Android流量監控
- 檔案壓縮 zip 7z gzip等
- 增量更新之diff演算法，案例：Tinker自研diff/patch演算法
- 圖片快取技術
- WebView快取優化
- 資料傳輸協議對比之ProfoBuf、FastJson、Jackson
- ...等
網路專題
- 可靠長連線的意義
- HTTPDNS DNS劫持
- 網路嗅探
- Http2/Https/QUIC協議對比
- CDN 削峰填谷
- 如何做全域性網路限流，保證業務流量高優先順序
- ...等
監控與日誌專題
- mmap日誌落地方式，開源專案Logan，xlog等分析
- 通過長連線動態拉取日誌
- 如果長連線斷開、通過短連線兜底拉取日誌
- 日誌上報，本地分片儲存及後臺上報策略
- ...等
安全專題
- 移動端的加密演算法之對稱與非對稱，防篡改
- 常規編碼方式一覽 md5 base64
- ...等