記得去年寫年終總結(jié)的時候到旦，我還在去看老友的火車上，那時對新一年充滿了無數(shù)期許巨缘，雖已是爭分奪秒添忘，但是當宣布 game over 的那一刻，這一年的收獲若锁、成長搁骑、遺憾、失落已經(jīng)定格又固。
內(nèi)容提要
- MVP 架構(gòu) App
- 浮窗組件開源
- NodeJs 全棧開發(fā)
- App web 化發(fā)展趨勢
- 年度博客總結(jié)
MVP 架構(gòu) App
針對項目中結(jié)構(gòu)混亂仲器，分層不清晰，提出 MVP 架構(gòu)的想法仰冠，經(jīng)過內(nèi)部分享乏冀，試點實踐，最終于五六月份在 MVP 的基礎(chǔ)加上 EventBus 全面重構(gòu)沪停。 架構(gòu)的收益是持續(xù)的煤辨，去掉了耦合在各個層面上回調(diào)函數(shù)裳涛，從架構(gòu)層面上規(guī)避了最常見的內(nèi)存泄漏問題，同時由于層之間的高度解耦众辨，使得我們可以針對不同層次使用不同的單元測試框架端三，大大降低了寫單元測試的成本。
盡管 MVP 和 EventBus不算什么新技術(shù)鹃彻，但對我們的項目來說是第一次郊闯，作為一個團隊的一員，要引入新的技術(shù)或新的想法不是一件容易的事蛛株。你得說服你的老大還有你的同事团赁，你不能干巴巴的說這個技術(shù)好然后你的同事就能信服你，特別是技術(shù)水平和視野上的差異谨履，沒有認知上的共鳴欢摄，你很難推動實施。作為團隊的新面孔笋粟，我也是費了很多波折怀挠，開始在小組內(nèi)做 MVP 的分享，再后來是在新接手的業(yè)務(wù)帶頭實踐 MVP 害捕，真正讓大家全面認可是下面的經(jīng)歷:
大約是4绿淋、5月的時候，隨著功能的增加尝盼，各處隱藏的內(nèi)存泄漏問題終于累積到了一個爆發(fā)點吞滞，大量引發(fā) OOM 問題。經(jīng)過內(nèi)存工具排查盾沫、反復測試裁赠、觀察內(nèi)存走向，游走大部分歷史代碼終于解決了問題疮跑。我把解決過程詳細的寫成了兩篇內(nèi)部分享文章组贺，鞭尸了 n 多個黑代碼(很多人為了怕影響同事關(guān)系，寧愿容忍渣代碼祖娘，也不愿指出錯誤失尖，我很不贊同這種價值觀，對于技術(shù)氛圍的形成十分有害渐苏，渣代碼就是要鞭尸,我覺得應(yīng)該提倡 review ,彼此鞭尸渣代碼掀潮。)，內(nèi)存溢出并不是在某個功能點琼富，而是散布在各個地方的 Handler 仪吧，這些 Handler 讓各個層次藕斷絲連。為了規(guī)避這些問題鞠眉，才有了后來的 MVP + EventBus薯鼠，它才開始真正被接納择诈。
關(guān)于在團隊中引入新技術(shù)，除了溝通能力之外出皇，你應(yīng)該還要做到兩點：1 明白項目的問題在哪里羞芍，2 用你要引入的技術(shù)解決當下的問題，3 對于新的技術(shù)郊艘，團隊成員成本多大荷科，例如當時想本要使用 RxJava ，考慮到當時團隊成員的學習成本就使用較為容易上手的 EventBus 了纱注。
浮窗組件開源
為了方便玩家游戲過程不用切換游戲也能方便地體驗我們的 App 的服務(wù)畏浆，我們需要"伸出一雙手"到游戲中，在合適的位置狞贱、合適的時間出現(xiàn)刻获。等于將 App 的功能閹割到浮窗中，所以邏輯還是比較復雜斥滤，經(jīng)過幾個版本下來遇到了很多坑将鸵，特別是在版本兼容問題上，在解決這些問題之后我覺得應(yīng)該把浮窗組件沉淀一下佑颇，開源出來：https://github.com/liuguangli/FloatUtil。
插件化研究
在進行浮窗功能設(shè)計的時候草娜，一開始打算做成插件的形式挑胸，花了大量的時間進行插件化的研究，看了幾大開源框架宰闰，對于設(shè)計模式茬贵、Android 框架、App 加載和執(zhí)行等都是一次進階性的提升移袍，最后形成了插件化研究的系列文章：
- 《Android應(yīng)用程序插件化研究之DexClassLoader》
- 《Android應(yīng)用程序插件化研究之AssetManager》
- 《插件化研究代ACTIVITY注冊》
- 《插件化研究之資源沖突》
NodeJs 全棧開發(fā)
App 客戶端的需求越來越少解藻，剛好后端要做業(yè)務(wù)重構(gòu)，進行前后端分離葡盗，主動申請參與前端的開發(fā)螟左，從無到有參與前端 NodeJs 項目架構(gòu)并支撐第一個新業(yè)務(wù)的上線。前后端分離觅够，在組織架構(gòu)上也算是一種解耦胶背， 為了讓后端從"代碼套頁面"的噩夢中解放出來、更加專注于數(shù)據(jù)業(yè)務(wù)的開發(fā)喘先，后端面向細粒度 API 開發(fā)钳吟，只關(guān)注服務(wù)和接口；NodeJs 作為服務(wù)到用戶的中間層窘拯，面向用戶側(cè)的開發(fā)红且，關(guān)注交互和界面坝茎，提供多端特性的適配。
App web 化發(fā)展趨勢
3 月份大家還在大談插件化暇番、這個時候插件化已是百花齊放景东，React Native （簡稱 RN）已經(jīng)在各大技術(shù)沙龍分享實戰(zhàn)經(jīng)驗，2015 年 9 月 RN 發(fā)布開源奔誓，這是一次 App 跨平臺開發(fā)思路上的突破：Web 方式編程斤吐，原生化的體驗。
2016 年 6 月厨喂，阿里開源 Weex 和措； 2016 年 9 月，微信小程序開放內(nèi)測蜕煌；RN派阱、Weex 和小程序 在思路上是一致的：采用某一種 Web 編程技術(shù)編寫頁面，生成的 js 部署到服務(wù)器斜纪，然后下發(fā)到客戶端贫母，客戶端 App 上搭載一個 JS 解釋器，最終轉(zhuǎn)換成 Native 組件盒刚。 三者實現(xiàn)手段上略有差異腺劣，RN 采用 React 的語法編寫程序邏輯，客戶端采用 JavascriptCore 作為 js 解釋器因块；Weex 采用 Vue 語法編程橘原，客戶端使用 V8 內(nèi)核作為 Js 運行環(huán)境；微信小程序可能和前兩種差稍有不同涡上，稍微進化得慢一些趾断，小程序提供的編程方式和 Weex 很相似，不過最終下發(fā)到客戶端執(zhí)行的還是 html 和 js 文件吩愧，最后由 X5 內(nèi)核來執(zhí)行 html 和 js芋酌。
RN、Weex 和微信小程序讓我看到的是一種編程方式的變化雁佳，App 原生開發(fā)和 Web 開發(fā)正在統(tǒng)一脐帝。微信小程序的出現(xiàn)一度引起很多討論，其中就有關(guān)于小程序是否會吞并 App 的討論甘穿，我倒是對此不以為然腮恩，不過我思考的是：微信小程序能做到、Weex 能做到温兼、RN 能做到秸滴，那么 OS 來做不也是輕而易舉的事么？這樣的 OS 一定會到來吧募判？（這時荡含，我不由得把視角轉(zhuǎn)向了 Google 咒唆，據(jù)說 Google 內(nèi)部正在融合Chrome OS 和 Android，將推出 Andromeda 操作系統(tǒng)释液。）那個時候才是真正的大一統(tǒng)全释。技術(shù)發(fā)展一直遵循著摩爾定律，性能误债、帶寬逐年提升浸船，Web 和 原生的體驗差距在慢慢變小App web 化開發(fā)一定是一種趨勢。
年度博客總結(jié)
1 插件化系列文章寝蹈，總結(jié)了插件化開發(fā)的基本思想概論李命。
- 《Android應(yīng)用程序插件化研究之DexClassLoader》
- 《Android應(yīng)用程序插件化研究之AssetManager》
- 《插件化研究代ACTIVITY注冊》
- 《插件化研究之資源沖突》
2 浮窗系列文章，總結(jié)了Android 窗口體系的相關(guān)知識點箫老。
3 物聯(lián)網(wǎng)入門系列文章封字，總結(jié)了 NodeJs 在硬件領(lǐng)域的使用，使用 Ruff 來 DIY 自己的家電耍鬓。
- 《DIY物聯(lián)網(wǎng)應(yīng)用 1-學習計劃》
- 《DIY物聯(lián)網(wǎng)應(yīng)用 2－RUFF 介紹》
- 《DIY物聯(lián)網(wǎng)應(yīng)用 3－控制繼電器》
- 《DIY物聯(lián)網(wǎng)應(yīng)用 4－遙控器控制風扇》
- 《DIY物聯(lián)網(wǎng) 5 – 手機控制風扇》
4 經(jīng)驗阔籽、思維、方法論
