git 使用 rebase 命令來合併分支，盡量不要直接 merge 導致分支**日誌混亂。
開發新功能時，自己在本地建立 feature 分支開發，功能開發完畢之後，參照上面合併流程操作功能的合併，並刪除本地分支，注意不要將本地分支推送到伺服器。
平時開發只在 develop 分支和自己的本地分支操作，不要操作 master 和 release 分支，這兩個分支只有在功能穩定上線的時候才進行合併操作。當線上版本出現緊急 bug 時，直接基於 master 分支拉取 hotfix 分支，解決 bug 之後再合併到其它各個分支。具體流程可以參見 git flow 流程
git 提交日誌盡量將注釋縮減為一句話，不要包含詳細的內容。
編譯配置相關
所有用到的第三方庫檔案統一在專案根目錄下的 dependecies.gradle 檔案中管理，並在 thirddependencies 標籤中新增引用並注釋，需要填寫**庫位址，方便後續檢視使用及更新。
專案中用到的顏色規範根據 ued 給出的規範統一定義於專案的 colors 中，不要直接在 xml 布局檔案中寫死，對於只有一兩個地方用到的顏色也需要抽取出來單獨定義，能夠注釋一下更好。
公共風格的控制項需要抽取相應的 theme 放到 styles 檔案中統一使用。不要直接在頁面布局檔案中寫死控制項顏色值或者字型大小大小，需要用統一的風格 theme，並且加上注釋。
布局中需要用到固定寬高的統一在 dimens 中定義好，之後在**中引用。
命名規範
**中變數的命名遵照駝峰命名法。
布局檔案中的控制項命名盡量使用控制項縮寫做字首，如 textview 簡寫為tv_xx，imageview 簡寫為 iv_xx。（不強求，有統一的風格即可）
layout 檔案命名規範如下：
字串資源命名規範如下：
有乙個規則就是如果字串可能有多處地方需要使用時，盡量用通用的英文單詞含義就可以了（如 ok cancel back 等），對於某些字串資源只有某些特定的範圍使用時準照下面的規則。
**編寫
頁面布局中對於需要填充字串或者檢視控制項效果的，都用 tools 命名空間進行資源的填充，對於需要隱藏的空間也需要用 tools 命名空間把控制項進行顯示，這樣方便調整 ui ，一句話就是，要善於使用 tools 命名空間來編寫布局檔案。
對於布局有間距需求的，統一在 root view 級別做統一的上下左右間隔，盡量不要在子控制項去做整體布局的上下左右間距處理。
**中涉及到字串資源的全部需要提取出來放入 strings.xml 檔案中，不要在**中直接將文字寫死，很難維護。
專案中用到 eventbus 事件的，事件訊息都放到主專案下的 event 包下，不要直接定義字串事件處理，如果需要傳送字串事件處理的，改用傳送本地廣播來處理，通過 localbroadcastmanager 來傳送。
頁面涉及 viewpager 的，可以使用 fzbaseviewpageradapter 來設定介面卡，其中的 fragment 需要繼承 fzbaseviewpagerfragment 來實現懶載入，不要一次把全部頁面的資料都載入出來，切記！！！
recycleview 的 view holder 需要繼承 fzbaseviewholder 來實現，在繫結資料的時候直接呼叫 bindviewdata 即可。
資料模型中，如果沒有需求需要頁面級別傳遞資料的話，不需要實現資料的序列化（parcelable / serializable）。
android專案 開發過程中需要時刻注意的
菜鳥入門級別程式設計師，頭一回做上線專案。經驗不足導致專案在開發完成之後bug 百出，小記一下在以後的開發過程中需要時刻注意的點 1，規範很重要 在後期的 整理的過程中，回頭看才發現，各種亂七八遭的多餘 邏輯混亂的 在專案進行的過程中一定要注意，先理清邏輯再敲 摒棄多餘 該省就省。2，記憶體優化 安...
關於Android開發過程中的weight的問題
weight值是乙個數字，用於指定每個檢視與其他同級檢視在剩餘空間中的佔比。這有點像飲料配方中各種成分的比例 2 份蘇打 1 份糖漿 是指飲料中三分之二是蘇打。例如，如果您將乙個檢視的 weight 值指定為 2，將另乙個檢視的 weight 值指定為 1，總和是 3，那麼第乙個檢視將填滿剩餘空間的...
Android開發過程中遇到的異常集錦
該異常意思是說 這個特定的子控制項 chlidview 已經擁有了乙個父控制項 parentview 你需要首先呼叫父控制項的 removeview 例如 在oncreate 中 rl relativelayout findviewbyid r.id.myrl rl.removeallviews r...