1、熱更新/熱替換
場景：
在實際開發(fā)中，我們會遇到app上線了，沒幾天出現(xiàn)了crash的bug，這種情形下，我們不可能重新發(fā)app，除非是非常非常嚴重的，這種場景下，hotfix技術(shù)就非常有用了！
參考技術(shù)：
https://github.com/singwhatiwanna/dynamic-load-apk
https://github.com/alibaba/AndFix
https://github.com/CtripMobile/DynamicAPK
https://github.com/bunnyblue/DroidFix
https://github.com/jasonross/Nuwa
2、快速批量打包--done
場景：
發(fā)更新包，突然有個地方要改，改完需要重新打包，如果再等待一個小時，肯定令人發(fā)指
3、JS協(xié)助的H5開發(fā)
場景：
有些需求非常緊急或者變化非常頻繁，就需要H5支持
參考技術(shù)：
https://github.com/facebook/react-native
4、apk的瘦身--doing
場景：
隨著業(yè)務(wù)的深入，代碼量急速增加，且有很多未使用的代碼未移除，還有一些不適用的圖片，導致apk不斷變大
參考技術(shù)：
http://zhuanlan.zhihu.com/zmywly8866/20006066– 內(nèi)含一些推薦文章
5、代碼分層
場景：
隨著業(yè)務(wù)的增加，代碼量急速增加，原先的類中代碼不斷增長，邏輯開始變負責，導致維護性變差
參考技術(shù)：
java服務(wù)端的分層
android的mvp
android的mvvm
6、app質(zhì)量監(jiān)控--doing
場景：
業(yè)務(wù)初期，我們都忙著開發(fā)新需求，忽視了app的質(zhì)量問題。更多的時候，我們只關(guān)注能用就行。現(xiàn)在人員配備
逐步完善，我們要開始逐步重視質(zhì)量
措施：
加強代碼檢測，團隊內(nèi)開始推廣使用android studio的lint功能
加強線上crash的統(tǒng)計與修復(fù)
加強線上exception的統(tǒng)計與匯總
加強開發(fā)時的自測
團隊內(nèi)，逐步開始code review
7、kotlin語言--android世界的Swift
場景：
原生java語言開發(fā)被人詬病許久，groovy和clojure在android上的進展緩慢，kotlin的出現(xiàn)，社區(qū)比較火，而且
有jetbrains公司的支持，IDE上支持很方便，后續(xù)可以期待
8、RxJava函數(shù)響應(yīng)式編程
場景：
現(xiàn)有異步代碼編寫和維護的時候，發(fā)現(xiàn)異步代碼理解起來不如同步代碼好理解，因為同步代碼代碼都在一起的，異步代碼
不在一起，不好找。RxJava的使用，就能解決這個問題
參考文獻：
http://blog.csdn.net/lzyzsd/article/details/41833541– 大頭鬼的RxJava介紹
http://gank.io/post/560e15be2dca930e00da1083--拋物線的RxJava介紹
9、增量更新
場景：
每次用戶更新都是下載一個完整的apk，費流量
參考文獻：
http://blog.csdn.net/hmg25/article/details/8100896
10、sdk工作--doing
場景：
現(xiàn)在我們有兩個app項目，發(fā)現(xiàn)兩個項目代碼有冗余，主要是非業(yè)務(wù)代碼的重復(fù)。這個時候，我們需要提取sdk，給兩個項目用，
同時為后續(xù)新開項目做準備，當然，也為公司做一些技術(shù)積累
