一、APP研發錄總結
1、重構的憂傷
如果版本發行後很短的時間內，就需要對其進行重構，除了小部分其他原因外，最重要的只能說是程式碼寫的爛，架構設計不夠靈活，導致耦合度很高。
要是非得要做重構，必須充分考慮現有資源，在非極端情況下，可與產品經理商量減功能，來彌補。在開發過程中，要本著以需求為第一要務，然後考慮抽出人手進行重構。
那麼既然做重構，計劃必須事先給出，且不要超過兩週的時間。重構時，在釋出版的上，新建一個分支，避免不必要的麻煩。

2、開工
在軟體開發過程中，主要包括市場調研、正式立項、需求分析、專案策劃、概要設計、詳細設計、編碼、測試、試執行、產品釋出、使用者培訓、產品複製、銷售、實施、系統維護、版本升級。
在軟體定義階段就需要搭建一套簡單實用的應用框架AndroidLib，它將封裝業務無關的邏輯，實行模組化拆分和外掛化程式設計。
AndroidLib包括哪些業務無關邏輯（結構劃分）：
（1）activity 包中存放的是與業務無關的 Activity 基類，Activity 基類要分兩層， AndroidLib 下的基類 BaseActivity 封裝的是業務無關的公用邏輯，主專案中的AppBaseActivity 基類封裝的是業務相關的公用邏輯；
（2）net 包裡面存放的是網路底層封裝；
（3）cache 包裡面存放的是快取資料和圖片的相關處理；
（4）ui包中存放的是自定義控制元件；
（5）utils 包中存放的是各種與業務無關的公用方法。
主專案的結構劃分：
（1）activity：我們按照模組繼續拆分，將不同模組的 Activity 劃分到不同的包下（儘量少使用內部類）；
（2）adapter：所有介面卡都放在一起；
（3）entity：將所有的實體都放在一起；
（4）db：SQLLite 相關邏輯的封裝；
（5）engine：將業務相關的類都放在一起；
（6）ui（widget）：將自定義控制元件都放在這個包中；
（7）utils：將所有的公用方法都放在這裡；
（8）interfaces：真正意義上的介面，命名以 I 作為開頭；
（9）listener：基於 Listener 的介面，命名以 On 作為開頭。

  在AndroidLib的BaseActivity中，重寫onCreate方法，並定義abstract方法（初始化變數，初始化控制元件，資料載入），然後主專案繼承BaseActivity，實現abstract方法。

  在點選事件這件事情上，可以選擇onClick方法，也可以直接在控制元件初始化下面使用setOnClick方法，但兩者都應該將其事件抽出作為私有方法。

3、業務邏輯到底怎樣理解
大家都清楚經典三層架構：表示層、業務邏輯層、資料訪問層
而在軟體產品中其實是這樣的，介面與互動為表示層，業務邏輯包含業務邏輯層和資料訪問層，在通常清楚下，我們將業務邏輯層與資料訪問層看作是並列關係，其實資料訪問層算是業務邏輯層的衍生物：（介面和互動–>表示層）（業務邏輯 –>業務邏輯層 –>資料訪問層）

  業務邏輯的組成部分：

領域實體
業務規則（不同於需求，要求無二義性）
完整性約束
業務流程及工作流

  業務邏輯的職責（業務指功能？與需求緊密聯絡）：

4、不要使用JSONObject或JSONArray來承載資料
因為它們不能被序列化，而序列化的好處就是方便儲存與傳輸。我們使用fastJson或GSON這樣的優秀庫。要是使用了JSONObject，那麼只能將物件封裝到全域性變數中，而在手機記憶體不夠，很可能導致記憶體洩漏問題。在頁面的跳轉中，也需要使用實體。

5、adapter
在使用adapter時，可以寫一個BaseAdapter，此外Adapter中使用ViewHolder效果更佳。

6、關於判空的問題必須嚴肅
可以使用TextUtils進行判斷，關於資料的分級，對於普通資料，沒有資料就不顯示，但是涉及到金額這類的，就必須給使用者一個友好的提示，並停止接下來的操作。

公眾號：