前言

越來越多的人在提“移動端的下半場”、“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專題后續補充