“包教包會“系列：Jetpack AAC完整解析（四）MVVM - Android架構(gòu)探索！

前面三篇介紹了Jetpack 架構(gòu)組件中 最重要 的部分：生命周期組件-Lifecycle、感知生命周期的數(shù)據(jù)組件-LiveData、視圖模型組件-ViewModel。 這篇，就來探索下目前android開發(fā)中 最優(yōu)秀、討論最多的架構(gòu)模式—— MVVM 。

幾個月前，我所在項目完成了 MVVM 的架構(gòu)改造。這篇在開始寫之前，我也閱讀了大量MVVM文章。所以，這篇盡量講清楚 開發(fā)架構(gòu)模式和MVVM的本質(zhì)，使得有一種 “哦，原來如此” 的豁然開朗。

注意，本篇完全 不會提 DataBinding、雙向綁定，文末會解釋為啥不提。

一、開發(fā)架構(gòu) 是什么？

我們先來理解開發(fā)架構(gòu)的本質(zhì)是什么，維基百科對軟件架構(gòu)的描述如下：

軟件架構(gòu)是一個系統(tǒng)的草圖。軟件架構(gòu)描述的對象是直接構(gòu)成系統(tǒng)的抽象組件。各個組件之間的連接則明確和相對細致地描述組件之間的通訊。在實現(xiàn)階段，這些抽象組件被細化為實際的組件，比如具體某個類或者對象。在面向?qū)ο箢I(lǐng)域中，組件之間的連接通常用接口來實現(xiàn)。

拆分開來就是三條：

  1. 針對的是一個完整系統(tǒng)，此系統(tǒng)可以實現(xiàn)某種功能。
  2. 系統(tǒng)包含多個模塊，模塊間有一些關(guān)系和連接。
  3. 架構(gòu)是實現(xiàn)此系統(tǒng)的實施描述：模塊責任、模塊間的連接。

為啥要做開發(fā)架構(gòu)設(shè)計呢？

  1. 模塊化責任具體化，使得每個模塊專注自己內(nèi)部。
  2. 模塊間的關(guān)聯(lián)簡單化，減少耦合。
  3. 易于使用、維護性好
  4. 提高開發(fā)效率

架構(gòu)模式最終都是 服務(wù)于開發(fā)者。如果代碼職責和邏輯混亂，維護成本就會相應(yīng)地上升。

宏觀上來說，開發(fā)架構(gòu)是一種思想，每個領(lǐng)域都有一些成熟的架構(gòu)模式，選擇適合自己項目即可。

二、Android開發(fā)中的架構(gòu)

具體到Android開發(fā)中，開發(fā)架構(gòu)就是描述 視圖層、邏輯層、數(shù)據(jù)層 三者之間的關(guān)系和實施：

  • 視圖層：用戶界面，即界面的展示、以及交互事件的響應(yīng)。
  • 邏輯層：為了實現(xiàn)系統(tǒng)功能而進行的必要邏輯。
  • 數(shù)據(jù)層：數(shù)據(jù)的獲取和存儲，含本地、server。

正常的開發(fā)流程中，開始寫代碼之前 都會有架構(gòu)設(shè)計這一過程。這就需要你選擇使用何種架構(gòu)模式了。

我的Android開發(fā)之路完整地經(jīng)過了 MVC、MVP、MVVM，相信很多開發(fā)者和我一樣都是這樣一個過程，先來回顧下三者。

2.1 MVC

MVC，Model-View-Controller，職責分類如下：

  • Model，模型層，即數(shù)據(jù)模型，用于獲取和存儲數(shù)據(jù)。
  • View，視圖層，即xml布局
  • Controller，控制層，負責業(yè)務(wù)邏輯。

View層 接收到用戶操作事件，通知到 Controller 進行對應(yīng)的邏輯處理，然后通知 Model去獲取/更新數(shù)據(jù)，Model 再把新的數(shù)據(jù) 通知到 View 更新界面。這就是一個完整 MVC 的數(shù)據(jù)流向。

但在Android中，因為xml布局能力很弱，View的很多操作是在Activity/Fragment中的，而業(yè)務(wù)邏輯同樣也是寫在Activity/Fragment中。

所以，MVC 的問題點 如下：

  1. Activity/Fragment 責任不明，同時負責View、Controller，就會導(dǎo)致其中代碼量大，不滿足單一職責。
  2. Model耦合View，View 的修改會導(dǎo)致 Controller 和 Model 都進行改動，不滿足最少知識原則。

2.2 MVP

MVP，Model-View-Presenter，職責分類如下：

  • Model，模型層，即數(shù)據(jù)模型，用于獲取和存儲數(shù)據(jù)。
  • View，視圖層，即Activity/Fragment
  • Presenter，控制層，負責業(yè)務(wù)邏輯。

MVP解決了MVC的問題：1.View責任明確，邏輯不再寫在Activity中，而是在Presenter中；2.Model不再持有View。

View層 接收到用戶操作事件，通知到Presenter，Presenter進行邏輯處理，然后通知Model更新數(shù)據(jù)，Model 把更新的數(shù)據(jù)給到Presenter，Presenter再通知到 View 更新界面。

MVP的實現(xiàn)思路：

  • UI邏輯抽象成IView接口，由具體的Activity實現(xiàn)類來完成。且調(diào)用Presenter進行邏輯操作。
  • 業(yè)務(wù)邏輯抽象成IPresenter接口，由具體的Presenter實現(xiàn)類來完成。邏輯操作完成后調(diào)用IView接口方法刷新UI。

MVP 本質(zhì)是面向接口編程，實現(xiàn)了依賴倒置原則。MVP解決了View層責任不明的問題，但并沒有解決代碼耦合的問題，View和Presenter之間相互持有。

所以 MVP 有問題點 如下：

  1. 會引入大量的IView、IPresenter接口，增加實現(xiàn)的復(fù)雜度。
  2. View和Presenter相互持有，形成耦合。

2.3 MVVM

MVVM，Model-View-ViewModel，職責分類如下：

  • Model，模型層，即數(shù)據(jù)模型，用于獲取和存儲數(shù)據(jù)。
  • View，視圖，即Activity/Fragment
  • ViewModel，視圖模型，負責業(yè)務(wù)邏輯。

注意，MVVM這里的ViewModel就是一個名稱，可以理解為MVP中的Presenter。不等同于上一篇中的 ViewModel組件 ，Jetpack ViewModel組件是 對 MVVM的ViewModel 的具體實施方案。

MVVM 的本質(zhì)是 數(shù)據(jù)驅(qū)動，把解耦做的更徹底，viewModel不持有view 。

View 產(chǎn)生事件，使用 ViewModel進行邏輯處理后，通知Model更新數(shù)據(jù)，Model把更新的數(shù)據(jù)給ViewModel，ViewModel自動通知View更新界面，而不是主動調(diào)用View的方法。

MVVM在Android開發(fā)中是如何實現(xiàn)的呢？接著看~

到這里你會發(fā)現(xiàn)，所謂的架構(gòu)模式本質(zhì)上理解很簡單。比如MVP，甚至你都可以忽略這個名字，理解成 在更高的層面上 面向接口編程，實現(xiàn)了 依賴倒置 原則，就是這么簡單。

三、MVVM 的實現(xiàn) - Jetpack MVVM

前面提到，架構(gòu)模式選擇適合自己項目的即可。話雖如此，但Google官方推薦的架構(gòu)模式 是適合大多數(shù)情況，是非常值得我們學習和實踐的。

好了，下面我們就來詳細介紹 Jetpack MVVM 架構(gòu)。

3.1 Jetpack MVVM 理解

Jetpack MVVM 是 MVVM 模式在 Android 開發(fā)中的一個具體實現(xiàn)，是 Android中 Google 官方提供并推薦的 MVVM實現(xiàn)方式。

不僅通過數(shù)據(jù)驅(qū)動完成徹底解耦，還兼顧了 Android 頁面開發(fā)中其他不可預(yù)期的錯誤，例如Lifecycle 能在妥善處理 頁面生命周期 避免view空指針問題，ViewModel使得UI發(fā)生重建時 無需重新向后臺請求數(shù)據(jù)，節(jié)省了開銷，讓視圖重建時更快展示數(shù)據(jù)。

首先，請查看下圖，該圖顯示了所有模塊應(yīng)如何彼此交互：


各模塊對應(yīng)MVVM架構(gòu)：

  • View層：Activity/Fragment
  • ViewModel層：Jetpack ViewModel + Jetpack LivaData
  • Model層：Repository倉庫，包含 本地持久性數(shù)據(jù) 和 服務(wù)端數(shù)據(jù)

View層 包含了我們平時寫的Activity/Fragment/布局文件等與界面相關(guān)的東西。

ViewModel層 用于持有和UI元素相關(guān)的數(shù)據(jù)，以保證這些數(shù)據(jù)在屏幕旋轉(zhuǎn)時不會丟失，并且還要提供接口給View層調(diào)用以及和倉庫層進行通信。

倉庫層 要做的主要工作是判斷調(diào)用方請求的數(shù)據(jù)應(yīng)該是從本地數(shù)據(jù)源中獲取還是從網(wǎng)絡(luò)數(shù)據(jù)源中獲取，并將獲取到的數(shù)據(jù)返回給調(diào)用方。本地數(shù)據(jù)源可以使用數(shù)據(jù)庫、SharedPreferences等持久化技術(shù)來實現(xiàn)，而網(wǎng)絡(luò)數(shù)據(jù)源則通常使用Retrofit訪問服務(wù)器提供的Webservice接口來實現(xiàn)。

另外，圖中所有的箭頭都是單向的，例如View層指向了ViewModel層，表示View層會持有ViewModel層的引用，但是反過來ViewModel層卻不能持有View層的引用。除此之外，引用也不能跨層持有，比如View層不能持有倉庫層的引用，謹記每一層的組件都只能與它相鄰層的組件進行交互。

這種設(shè)計打造了一致且愉快的用戶體驗。無論用戶上次使用應(yīng)用是在幾分鐘前還是幾天之前，現(xiàn)在回到應(yīng)用時都會立即看到應(yīng)用在本地保留的數(shù)據(jù)。如果此數(shù)據(jù)已過期，則應(yīng)用的Repository將開始在后臺更新數(shù)據(jù)。

3.2 實施

我們來舉個完整的例子 - 在頁面中顯示用戶信息列表，來說明 Jetpack MVVM 的具體實施。

3.2.1 構(gòu)建界面

首先創(chuàng)建一個列表頁面 UserListActivity，并且知道頁面所需要的數(shù)據(jù)是，用戶信息列表。

那么 用戶信息列表 如何獲取呢？根據(jù)上面的架構(gòu)圖，就是ViewModel了，所以我們創(chuàng)建 UserListViewModel 繼承自 ViewModel，并且把 用戶信息列表 以 LiveData呈現(xiàn)。

public class UserListViewModel extends ViewModel {
    //用戶信息
    private MutableLiveData<List<User>> userListLiveData;
    //進條度的顯示
    private MutableLiveData<Boolean> loadingLiveData;

    public UserListViewModel() {
        userListLiveData = new MutableLiveData<>();
        loadingLiveData = new MutableLiveData<>();
    }

    public LiveData<List<User>> getUserListLiveData() {
        return userListLiveData;
    }
    public LiveData<Boolean> getLoadingLiveData() {
        return loadingLiveData;
    }
    ...
}
復(fù)制代碼

LiveData 是一種可觀察的數(shù)據(jù)存儲器。應(yīng)用中的其他組件可以使用此存儲器監(jiān)控對象的更改，而無需在它們之間創(chuàng)建明確且嚴格的依賴路徑。LiveData 組件還遵循應(yīng)用組件（如 Activity、Fragment 和 Service）的生命周期狀態(tài)，并包括清理邏輯以防止對象泄漏和過多的內(nèi)存消耗。

將 UserListViewModel 中的字段類型更改為 MutableLiveData<List>。現(xiàn)在，更新數(shù)據(jù)時，系統(tǒng)會通知 UserListActivity。此外，由于此 LiveData 字段具有生命周期感知能力，因此當不再需要引用時，會自動清理它們。

另外，注意到暴露的獲取LiveData的方法 返回的是LiveData類型，即不可變的，而不是MutableLiveData，好處是避免數(shù)據(jù)在外部被更改。（參見LivaData篇文章）

現(xiàn)在，我們修改 UserListActivity 以觀察數(shù)據(jù)并更新界面：

//UserListActivity.java
...
    //觀察ViewModel的數(shù)據(jù)，且此數(shù)據(jù) 是 View 直接需要的，不需要再做邏輯處理
    private void observeLivaData() {
        mUserListViewModel.getUserListLiveData().observe(this, new Observer<List<User>>() {
            @Override
            public void onChanged(List<User> users) {
                if (users == null) {
                    Toast.makeText(UserListActivity.this, "獲取user失??！", Toast.LENGTH_SHORT).show();
                    return;
                }
                //刷新列表
                mUserAdapter.setNewInstance(users);
            }
        });

        mUserListViewModel.getLoadingLiveData().observe(this, new Observer<Boolean>() {
            @Override
            public void onChanged(Boolean aBoolean) {
                //顯示/隱藏加載進度條
                mProgressBar.setVisibility(aBoolean? View.VISIBLE:View.GONE);
            }
        });
    }
復(fù)制代碼

每次更新用戶列表信息數(shù)據(jù)時，系統(tǒng)都會調(diào)用 onChanged() 回調(diào)并刷新界面，而不需要 ViewModel主動調(diào)用View層方法刷新，這就是 數(shù)據(jù)驅(qū)動 了 —— 數(shù)據(jù)的更改 驅(qū)動 View 自動刷新。

因為LiveData具有生命周期感知能力，這意味著，除非 Activity 處于活躍狀態(tài)，否則它不會調(diào)用 onChanged() 回調(diào)。當調(diào)用 Activity 的 onDestroy() 方法時，LiveData 還會自動移除觀察者。

另外，我們也沒有添加任何邏輯來處理配置更改（例如，用戶旋轉(zhuǎn)設(shè)備的屏幕）。UserListViewModel 會在配置更改后自動恢復(fù)，所以一旦創(chuàng)建新的 Activity，它就會接收相同的 ViewModel 實例，并且會立即使用當前的數(shù)據(jù)調(diào)用回調(diào)。鑒于 ViewModel 對象應(yīng)該比它們更新的相應(yīng) View 對象存在的時間更長，因此 ViewModel 實現(xiàn)中不得包含對 View 對象的直接引用，包括Context。

3.2.2 獲取數(shù)據(jù)

現(xiàn)在，我們已使用 LiveData 將 UserListViewModel 連接到UserListActivity，那么如何獲取用戶個人信息列表數(shù)據(jù)呢？

實現(xiàn) ViewModel 的第一個想法可能是 使用Retrofit/Okhttp調(diào)用接口 來獲取數(shù)據(jù)，然后將該數(shù)據(jù)設(shè)置給 LiveData 對象。這種設(shè)計行得通，但如果采用這種設(shè)計，隨著應(yīng)用的擴大，應(yīng)用會變得越來越難以維護。這樣會使 UserListViewModel 類承擔太多的責任，這就違背了單一職責原則。

ViewModel 會將數(shù)據(jù)獲取過程委派給一個新的模塊，即Repository。

Repository模塊會處理數(shù)據(jù)操作。它們會提供一個干凈的 API，以便應(yīng)用內(nèi)其余部分也可以輕松獲取該數(shù)據(jù)。數(shù)據(jù)更新時，它們知道從何處獲取數(shù)據(jù)以及進行哪些 API 調(diào)用。您可以將Repository視為不同數(shù)據(jù)源（如持久性模型、網(wǎng)絡(luò)服務(wù)和緩存）之間的媒介。

public class UserRepository {

    private static UserRepository mUserRepository;
    public static UserRepository getUserRepository(){
        if (mUserRepository == null) {
            mUserRepository = new UserRepository();
        }
        return mUserRepository;
    }

    //(假裝)從服務(wù)端獲取
    public void getUsersFromServer(Callback<List<User>> callback){
        new AsyncTask<Void, Void, List<User>>() {
            @Override
            protected void onPostExecute(List<User> users) {
                callback.onSuccess(users);
                //存本地數(shù)據(jù)庫
                saveUsersToLocal(users);
            }
            @Override
            protected List<User> doInBackground(Void... voids) {
                try {
                    Thread.sleep(2000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                //假裝從服務(wù)端獲取的
                List<User> users = new ArrayList<>();
                for (int i = 0; i < 20; i++) {
                    User user = new User("user"+i, i);
                    users.add(user);
                }
                return users;
            }
        }.execute();
    }

復(fù)制代碼

雖然Repository模塊看起來不必要，但它起著一項重要的作用：它會從應(yīng)用的其余部分中提取數(shù)據(jù)源。現(xiàn)在，UserListViewModel 是不知道數(shù)據(jù)來源的，因此我們可以為ViewModel提供從幾個不同的數(shù)據(jù)源獲取數(shù)據(jù)。

3.2.3 連接 ViewModel 與存儲區(qū)

我們在UserListViewModel 提供一個方法，用戶Activity獲取用戶信息。此方法就是調(diào)用Repository來執(zhí)行，并且吧數(shù)據(jù)設(shè)置到LiveData。

public class UserListViewModel extends ViewModel {
    //用戶信息
    private MutableLiveData<List<User>> userListLiveData;
    //進條度的顯示
    private MutableLiveData<Boolean> loadingLiveData;

    public UserListViewModel() {
        userListLiveData = new MutableLiveData<>();
        loadingLiveData = new MutableLiveData<>();
    }

    /**
     * 獲取用戶列表信息
     * 假裝網(wǎng)絡(luò)請求 2s后 返回用戶信息
     */
    public void getUserInfo() {

        loadingLiveData.setValue(true);

        UserRepository.getUserRepository().getUsersFromServer(new Callback<List<User>>() {
            @Override
            public void onSuccess(List<User> users) {
                loadingLiveData.setValue(false);
                userListLiveData.setValue(users);
            }

            @Override
            public void onFailed(String msg) {
                loadingLiveData.setValue(false);
                userListLiveData.setValue(null);
            }
        });
    }

    //返回LiveData類型
    public LiveData<List<User>> getUserListLiveData() {
        return userListLiveData;
    }
    public LiveData<Boolean> getLoadingLiveData() {
        return loadingLiveData;
    }
}
復(fù)制代碼

在Activity中，就要獲取UserListViewModel實例，獲取用戶信息：

//UserListActivity.java
public class UserListActivity extends AppCompatActivity {
    private UserListViewModel mUserListViewModel;
    private ProgressBar mProgressBar;
    private RecyclerView mRvUserList;
    private UserAdapter mUserAdapter;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_user_list);

        initView();
        initViewModel();
        getData();
        observeLivaData();
    }
    private void initView() {...}

    private void initViewModel() {
        ViewModelProvider viewModelProvider = new ViewModelProvider(this);
        mUserListViewModel = viewModelProvider.get(UserListViewModel.class);
    }

    /**
     * 獲取數(shù)據(jù)，調(diào)用ViewModel的方法獲取
     */
    private void getData() {
        mUserListViewModel.getUserInfo();
    }

    private void observeLivaData() {...}

復(fù)制代碼

3.2.4 緩存數(shù)據(jù)

現(xiàn)在UserRepository 有個問題是，它從后端獲取數(shù)據(jù)后，不會將緩存該數(shù)據(jù)。因此，如果用戶在離開頁面后再返回，則應(yīng)用必須重新獲取數(shù)據(jù)，即使數(shù)據(jù)未發(fā)生更改也是如此。這就浪費了寶貴的網(wǎng)絡(luò)資源，迫使用戶等待新的查詢完成。 所以，我們向 UserRepository 添加了一個新的數(shù)據(jù)源，本地緩存。緩存實現(xiàn) 可以是 數(shù)據(jù)庫、SharedPreferences等持久化技術(shù)。（具體實現(xiàn)就不再寫了）

//UserRepository.java

    //從本地數(shù)據(jù)庫獲取
    public void getUsersFromLocal(){
        // TODO: 2021/1/24 從本地數(shù)據(jù)庫獲取
    }

    //存入本地數(shù)據(jù)庫 (從服務(wù)端獲取數(shù)據(jù)后可以調(diào)用)
    private void saveUsersToLocal(List<User> users){
        // TODO: 2021/1/24 存入本地數(shù)據(jù)庫
    }

復(fù)制代碼

到這里，Jetpack MVVM 就介紹完了。

實際上只要前面介紹的 Lifecycle、LivaData、ViewModel 熟練掌握的話，這里是十分好理解的。

3.3 注意點

  1. 在應(yīng)用的各個模塊之間設(shè)定明確定義的職責界限。

  2. ViewModel 不能持有 View層引用，包括Context也不能持有。

  3. 將一個數(shù)據(jù)源指定為單一可信來源。 每當需要訪問數(shù)據(jù)時，都應(yīng)一律源于此單一可信來源。 例如 UserRepository會將網(wǎng)絡(luò)服務(wù)響應(yīng)保存在數(shù)據(jù)庫中。這樣一來，對數(shù)據(jù)庫的更改將觸發(fā)對活躍 LiveData 對象的回調(diào)。數(shù)據(jù)庫會充當單一可信來源。

  4. 保留盡可能多的相關(guān)數(shù)據(jù)和最新數(shù)據(jù)。 這樣，即使用戶的設(shè)備處于離線模式，他們也可以使用您應(yīng)用的功能。請注意，并非所有用戶都能享受到穩(wěn)定的高速連接。

  5. 顯示頁面狀態(tài)。 例如例子中的加載進度條，就是觀察 ViewModel中的MutableLiveData loadingLiveData 進行操作的。

3.4 MVP改造MVVM

了解了Jetpack MVVM的實現(xiàn)，再來改造 MVP 是很簡單的了。

步驟如下：

  1. 去除Presener 對View、context的引用。
  2. Presener 替換成ViewModel的實現(xiàn)，獲取的數(shù)據(jù)以 LivaData呈現(xiàn)。
  3. 刪除定義的IView等接口，Activity/Fragment中 獲取ViewModel實例，調(diào)用其方法獲取數(shù)據(jù)。
  4. Activity/Fragment 觀察需要的 LivaData 然后刷新UI。

這樣就已經(jīng)成為了MVVM。當然也要檢查下 原MVP的 Model層的實現(xiàn)，是否滿足上面的要求。

四、總結(jié)

本篇介紹了 架構(gòu)模式的含義，回顧和比較了Android中的架構(gòu)模式MVC、MVP、MVVM，最好在 Jetpack架構(gòu)組件 基礎(chǔ)上 介紹了 MVVM 的詳細實現(xiàn)方法、注意點，以及MVP的改造。

整篇下來，基本很簡單容易理解的。 例子是很簡單的，所以在實際開發(fā)中 需要深入理解 MVVM 數(shù)據(jù)驅(qū)動的本質(zhì)，和MVP的區(qū)別。

有人可能會有疑惑：怎么完全沒有提 DataBinding、雙向綁定？

實際上，這也是我之前的疑惑。 沒有提 是因為：

  1. 我不想讓讀者 一提到 MVVM 就和DataBinding聯(lián)系起來
  2. 我想讓讀者 抓住 MVVM 數(shù)據(jù)驅(qū)動 的本質(zhì)。
  3. 而DataBinding提供的雙向綁定，是用來完善Jetpack MVVM 的工具，其本身在業(yè)界又非常具有爭議性。
  4. 掌握本篇內(nèi)容，已經(jīng)是Google推薦的開發(fā)架構(gòu)，就已經(jīng)實現(xiàn) MVVM 模式。在Google官方的 應(yīng)用架構(gòu)指南 中 也同樣絲毫沒有提到 DataBinding。

所以，下一篇，將繼續(xù)介紹 Jetpack AAC 的組件：數(shù)據(jù)綁定組件 DataBinding、數(shù)據(jù)庫組件 Room，作為 Jetpack MVVM 的完善補充點。 并且 也將是 Jetpack AAC 完整解析 系列的最后一篇。 敬請期待！

Demo 地址

五、分享

分享一份《Jetpack架構(gòu)組件從入門到精通》的pdf學習筆記給大家，內(nèi)容涵括了Jetpack幾乎所有你能想到的知識點，而每一個知識點都有詳細的源碼解析，以及實戰(zhàn)講解！

=

需要的小伙伴，可以點擊這里直接獲??！

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容