1. 規劃Android專案結構

平時我們自己開發一個Android專案時，我們更多是在一個工程裡新建一個Android專案，然後在專案中劃分不同的板塊，例如activities、adapter、entity、net等等，一個專案就將工程的所有功能都實現了，那是因為我們的頁面比較少，但是在公司裡，公司的專案都是很大的，如果有200個頁面的工程，就有200個Activity，再加上邏輯處理、實體、自定義控制元件、資料請求等等，整個工程下來，如果一個專案就將工程中所有功能都實現了，你會發現整個專案非常大以及後期程式碼不易於管理和修改

專案結構：

首先，我們新建了一個Android工程之後，預設有個主專案，然後我們在工程中新建個module，命名為AndroidLib，我們讓AndroidLib成為這個工程中最基礎的類庫，主工程專案保持對AndroidLib庫的依賴，具體

那什麼是與業務無關？

例如：目前公司有個工程是開發一款學車App，學車App其中的業務要分報名駕校、預約學車、筆試刷題、車友圈交流等等不同的業務，但是所有的業務中Activity幾乎都有四個必須要處理的環節，第一初始化控制元件；第二獲取上個頁面傳遞過來資訊，做一些邏輯處理；第三根據當前頁面已有的資訊傳送資料請求等操作，然後根據獲取到的資訊初始化介面；第四頁面關閉，銷燬一些資料，防止出現記憶體洩漏(常見Android記憶體洩漏彙總)，而這四個環節不會因為業務的不存在而不存在，所以這就需要將這些共同的屬性提取到AndroidLib中去編寫一個基類，可以名為：BaseActivity

我們在主專案中，再寫一個基礎的封裝類Activity，可以名為AppBaseActivity，讓它繼承AndroidLib中的BaseActivity，AppBaseActivity主要提取業務的公共邏輯！

與業務無關的程式碼我們肯定也要分板塊，至少有五個基礎部分

1. activity 頁面的與業務無關的邏輯
2. net 網路底層封裝
3. cache 快取資料和圖片的相關處理
4. ui 自定義控制元件
5. utils 存放業務無關的公用方法

主專案中的分層如下：

1. activity 在其中可以按照業務模組繼續劃分到不同的包下
2. adapter 其中也可以根據不同的業務模組劃分，但是通常adapter大部分邏輯都是一樣的，也可以不劃分，當這個包有10個以上的adapter類建議可以根據業務模組劃分
3. entity 所有的實體類
4. db SQLLite相關邏輯的封裝
5. engine 與業務相關的類
6. ui 自定義的控制元件
7. utils 所有公用的方法
8. interfaces 介面
9. listener Listener的介面

這樣劃分的目的：
1. 每個檔案都有一個單獨的類，不使用巢狀類
2. Activity按照模組拆分，可以迅速定位具體的一個頁面

2.BaseActivity的寫法

public abstract class BaseActivity extends Activity {
    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        //初始化介面控制元件
        initViews(savedInstanceState);
        //處理上個頁面傳遞過來的資料
        initVariables();
        //根據已有的資訊執行資料請求或者從本地快取中獲取資料，初始化介面上的控制元件，顯示得到的資訊
        loadData();
    }

    protected abstract void loadData();

    protected abstract void initVariables();

    protected abstract void initViews(Bundle savedInstanceState);

    @Override
    protected void onDestroy() {
        super.onDestroy();
        //關閉有些需要釋放的資源
        close();
    }

    protected abstract void close();
}

3.型別安全轉換函式

為什麼要寫這個函式？

打個比方，公司裡面的前端寫了個配置網站，你們的App會從後臺去獲取這些配置資訊，然後在App端具體顯示這些資訊，但是App端與web前後臺交流不到位，前端配置網站不可能每個配置輸入框都要輸入資訊，但是後臺又沒有通過寫入一些預設資訊寫入資料庫，所以這時出現一個問題，如果有個整型資料的配置資訊，但是客戶並沒有具體配置，App端認為獲取的資料是整型資料，但是使用者沒有配置，該資訊在資料庫中是空，App端直接獲取到後臺的資料後就準備顯示到介面上，你準備將其轉換成int型資料，你發現你的App直接崩潰，出現型別轉換出錯異常…………

這就證明了型別安全轉換函式的必要性！
整型安全轉換函式(其他的型別如果有必要的話，也可以寫個型別安全轉換函式)：

public final static int convertToInt(Object value, int defaultValue) {
    //當資料為空時，返回預設值
    if (value == null || "".equals(value.toString().trim())) {
        return defaultValue;
    }
    try {
        //返回轉換的資料，如果出現異常，說明其不是整型資料
        return Integer.valueOf(value.toString());
    } catch (Exception e) {
        try {
            return Double.valueOf(value.toString()).intValue();
        } catch (Exception e1) {
            return defaultValue;
        }
    }
}

還有什麼不足的地方，望請通過評論的方式指出，謝謝，虛心學習，共同進步！