以下是 騷年你的螢幕適配方式該升級了! 系列文章，歡迎轉發以及分享:

前言

我在前面兩篇文章中詳細介紹了 今日頭條適配方案 和 SmallestWidth 限定符適配方案 的原理，並驗證了它們的可行性，以及總結了它們各自的優缺點，可以說這兩個方案都是目前比較優秀、比較主流的 Android 螢幕適配方案，而且它們都已經擁有了一定的使用者基數

但是對於一些才接觸這兩個方案的朋友，肯定或多或少還是不知道如何選擇這兩個方案，我雖然在之前的文章中給出了它們各自的優缺點，但是並沒有用統一的標準對它們進行更細緻的對比，所以也就沒辦法更形象的體現它們的優劣，那下面我就用統一的標準對它們進行對比，看看它們的對比情況

方案對比

我始終堅定地認為在這兩個方案中，並不能以單個標準就能評判出誰一定比誰好，因為它們都有各自的優缺點，都不是完美的，從更客觀的角度來看，它們誰都不能成為最好的那個，只有可能明確了它們各自的優缺點，知道在它們的優缺點裡什麼是我能接受的，什麼是我不能接受的，是否能為了某些優點做出某些妥協，從而選擇出一個最適合自己專案的螢幕適配方案

單純的爭論誰是最好的 Android 螢幕適配方案沒有任何意義，每個人的需求不一樣，站的角度不一樣，評判標準也不一樣，你能接受的東西他不一定能接受，你覺得不可接受的東西他卻覺得可以接受，你有你的理由，他有他的理由，想讓一個觀點讓所有人都能接受太難了！所以我在這裡只是列出它們的對比項和對比結果，儘可能的做到客觀，最後的選擇結果請自行決定，如果還有什麼遺漏的對比項，請補充！

可以看到 SmallestWidth 限定符適配方案 和 今日頭條適配方案 的適配效果其實都是差不多的，我在前面的文章中也通過公式計算過它們的精確度，SmallestWidth 限定符適配方案 執行在未覆蓋的機型上雖然也可以適配，但是卻會出現一定的誤差，所以 今日頭條適配方案 的適配精確度確實要比 SmallestWidth 限定符適配方案 略高的，不過只要 SmallestWidth 限定符適配方案 合理的分配資原始檔，適配效果的差距應該也不大

SmallestWidth 限定符適配方案 主打的是穩定性，在執行過程中極少會出現安全隱患，適配範圍也可控，不會產生其他未知的影響，而 今日頭條適配方案 主打的是降低開發成本、提高開發效率，使用上更靈活，也能滿足更多的擴充套件需求，簡單一句話概括就是，這兩兄弟，一個求穩，一個求快，好了，我就介紹這麼多了，自己選擇吧！

AndroidAutoSize

由來

下面就開始介紹我根據 今日頭條螢幕適配方案 優化的螢幕適配框架 AndroidAutoSize，大家千萬不要認為，我推出的螢幕適配框架 AndroidAutoSize 是根據 今日頭條螢幕適配方案 優化的，我本人就一定支援 今日頭條螢幕適配方案 是最好的 Android 螢幕適配方案這個觀點，它確實很優秀，但同樣也有很多不足，我最真實的觀點在上面就已經表述咯，至於我為什麼要根據 今日頭條螢幕適配方案 再封裝一個螢幕適配框架，無外乎就以下幾點原因:

• SmallestWidth 限定符適配方案 已經有多個優秀的開源解決方案了，它們已經能滿足我們日常開發中的所有需求

• 今日頭條 官方技術團隊只公佈了 今日頭條螢幕適配方案 的 文章 以及核心程式碼，但並沒有在 Github 上建立公開的倉庫，一個新的方案必定要有一個成長迭代的過程，在此期間，一定需要一個可以把所有使用者聚集起來的公共社群，可以讓所有使用該方案的使用者在上面交流，大家一起總結、一起填坑，這樣才能讓該方案更成熟穩定，這就是開源的力量

• 今日頭條 官方技術團隊公佈的核心程式碼並不能滿足我的所有需求，已經開源的其他基於 今日頭條螢幕適配方案 的開源專案以及解決方案也不能滿足我的所有需求，而我有更好的實現想法

• MVPArms 需要一個適配效果還不錯並且切換維護成本也比較低的螢幕適配框架，以幫助使用者用較低的成本、工作量將已經停止維護的 AndroidAutoLayout 快速替換掉

我建議大家都可以去實際體驗一下 今日頭條螢幕適配方案 和 SmallestWidth 限定符適配方案，感受下它們的異同，我給的建議是，可以在專案中先使用 今日頭條螢幕適配方案，感受下它的使用方式以及適配效果，今日頭條螢幕適配方案 的侵入性非常低，如果在使用過程中遇到什麼不能解決的問題，馬上可以切換為其他的螢幕適配方案，在切換的過程中也花費不了多少工作量，試錯成本非常低

但如果你在專案中先使用 SmallestWidth 限定符適配方案，之後在使用的過程中再遇到什麼不能解決的問題，這時想切換為其他的螢幕適配方案，這工作量可就大了，每個 Layout 檔案都含有大量的 dimens 引用，改起來這工作量得有多大，想想都覺得後怕，這就是侵入性太高導致的最致命的問題

如果想體驗 今日頭條螢幕適配方案，千萬不要錯過 AndroidAutoSize 哦！僅需一步即可接入專案，下面是 AndroidAutoSize 的地址:

與今日頭條螢幕適配方案的關係

AndroidAutoSize 與 今日頭條螢幕適配方案 的關係，相當於汽車和發動機的關係，今日頭條螢幕適配方案 官方公佈的程式碼，只實現了修改系統 density 的相關邏輯，這的確在螢幕適配中起到了最關鍵的作用，但這還遠遠還不夠

要想讓使用者能夠更傻瓜式的使用該方案，並且能夠應對日常開發中的所有複雜需求，那在架構框架時，還需要考慮 API 的易用性以及合理性、框架的擴充套件性以及靈活性、功能的全面性、註釋和文件的易讀性等多個方面的問題

於是我帶著我的這些標準在網上搜尋了很久，發現並沒有任何一個開源框架或解決方案能夠達到我的所有標準，它們大多數還只是停留在將 今日頭條螢幕適配方案 封裝成工具類來引入專案的階段，這樣在功能的擴充套件上有限制，並且對使用者的使用體驗也不好，而我想做的是一個全面性的產品級螢幕適配框架，這離我最初的構想，差距還非常大，於是我只好自己動手，將我的所有思想實現，這才有了 AndroidAutoSize

寫完 AndroidAutoSize 框架後，因為對 今日頭條螢幕適配方案 有了更加深入的理解，所以才寫了 騷年你的螢幕適配方式該升級了!（一）-今日頭條適配方案，以幫助大家更清晰的理解 今日頭條螢幕適配方案

與 AndroidAutoLayout 的關係

AndroidAutoSize 因為名字和 鴻神 的 AndroidAutoLayout 非常相似，並且在填寫設計圖尺寸的方式上也極為相似，再加上我寫的螢幕適配系列的文章也釋出在了 鴻神 的公眾號上，所以很多人以為 AndroidAutoSize 是 鴻神 寫的 AndroidAutoLayout 的升級版，這裡我哭笑不得 ?，我只好在這裡說一句，大家好，我叫 JessYan，的確可以理解為 AndroidAutoSize 是 AndroidAutoLayout 的升級版，但是它是我寫的，關注一波唄

但 AndroidAutoSize 和 AndroidAutoLayout 的原理，卻天差地別，比如 AndroidAutoLayout 只能使用 px 作為佈局單位，而 AndroidAutoSize 恰好相反，在佈局中 dp、sp、pt、in、mm 所有的單位都能支援，唯獨不支援 px，但這也意味著 AndroidAutoSize 和 AndroidAutoLayout 在專案中可以共存，互不影響，所以使用 AndroidAutoLayout 的老專案也可以放心的引入 AndroidAutoSize，慢慢的完成螢幕適配框架的切換

之所以將框架取名為 AndroidAutoSize，第一，是想致敬 AndroidAutoLayout 對 Android 螢幕適配領域的貢獻，第二，也想成為在 Android 螢幕適配領域有重要影響力的框架

結構

我在上面就已經說了很多開源框架以及解決方案，只是把 今日頭條螢幕適配方案 簡單的封裝成一個工具類然後引入專案，這時很多人就會說了 今日頭條螢幕適配方案 官方公佈的全部程式碼都只有 30 行不到，你不把它封裝成工具類，那封裝成什麼？該怎麼封裝？下面就來看看 AndroidAutoSize 的整體結構

├── external
│   ├── ExternalAdaptInfo.java
│   ├── ExternalAdaptManager.java
│── internal
│   ├── CancelAdapt.java
│   ├── CustomAdapt.java
│── unit
│   ├── Subunits.java
│   ├── UnitsManager.java
│── utils
│   ├── AutoSizeUtils.java
│   ├── LogUtils.java
│   ├── Preconditions.java
│   ├── ScreenUtils.java
├── ActivityLifecycleCallbacksImpl.java
├── AutoAdaptStrategy.java
├── AutoSize.java
├── AutoSizeConfig.java
├── DefaultAutoAdaptStrategy.java
├── DisplayMetricsInfo.java
├── FragmentLifecycleCallbacksImpl.java
├── InitProvider.java

AndroidAutoSize 根據 今日頭條螢幕適配方案 官方公佈的 30 行不到的程式碼，經過不斷的優化和擴充套件，發展成了現在擁有 18 個類檔案，近 2000 行程式碼的全面性螢幕適配框架，在迭代的過程中完善和優化了很多功能，相比 今日頭條螢幕適配方案 官方公佈的原始程式碼，AndroidAutoSize 更加穩定、更加易用、更加強大，歡迎閱讀原始碼，註釋非常詳細哦！

功能介紹

AndroidAutoSize 在使用上非常簡單，只需要填寫設計圖尺寸這一步即可接入專案，但需要注意的是，AndroidAutoSize 有兩種型別的佈局單位可以選擇，一個是 主單位 (dp、sp)，一個是 副單位 (pt、in、mm)，兩種單位面向的應用場景都有不同，也都有各自的優缺點

• 主單位: 使用 dp、sp 為單位進行佈局，侵入性最低，會影響其他三方庫頁面、三方庫控制元件以及系統控制元件的佈局效果，但 AndroidAutoSize 也通過這個特性，使用 ExternalAdaptManager 實現了在不修改三方庫原始碼的情況下適配三方庫的功能

• 副單位: 使用 pt、in、mm 為單位進行佈局，侵入性高，對老專案的支援比較好，不會影響其他三方庫頁面、三方庫控制元件以及系統控制元件的佈局效果，可以徹底的遮蔽修改 density 所造成的所有未知和已知問題，但這樣 AndroidAutoSize 也就無法對三方庫進行適配

大家可以根據自己的應用場景在 主單位 和 副單位 中選擇一個作為佈局單位，建議想引入老專案並且注重穩定性的人群使用 副單位，只是想試試本框架，隨時可能切換為其他螢幕適配方案的人群使用 主單位

其實 AndroidAutoSize 可以同時支援 主單位 和 副單位，但 AndroidAutoSize 可以同時支援 主單位 和 副單位 的目的，只是為了讓使用者可以在 主單位 和 副單位 之間靈活切換，因為切換單位的工作量可能非常巨大，不能立即完成，但領導又要求馬上打包上線，這時就可以起到一個很好的過渡作用

主單位

主單位 的 Demo 在 demo

基本使用

將 AndroidAutoSize 引入專案後，只要在 app 的 AndroidManifest.xml 中填寫上設計圖尺寸，無需其他過多配置 (如果你沒有其他自定義需求的話)，AndroidAutoSize 即可自動執行，像下面這樣?

<manifest>
    <application>            
        <meta-data
            android:name="design_width_in_dp"
            android:value="360"/>
        <meta-data
            android:name="design_height_in_dp"
            android:value="640"/>           
     </application>           
</manifest>

在使用主單位時，design_width_in_dp 和 design_height_in_dp 的單位必須是 dp，如果設計師給你的設計圖，只標註了 px 尺寸 (現在已經有很多 UI 工具可以自動標註 dp 尺寸了)，那請自行根據公式 dp = px / (DPI / 160) 將 px 尺寸轉換為 dp 尺寸，如果你不知道 DPI 是多少？那請以自己測試機的 DPI 為準，如果連怎麼得到裝置的 DPI 都不知道？百度吧好伐，如果你實在找不到裝置的 DPI 那就直接將 px 尺寸除以 3 或者 2 也是可以的

如果你只是想使用 AndroidAutoSize 的基礎功能，AndroidAutoSize 的使用方法在這裡就結束了，只需要上面這一步，即可幫助你以最簡單的方式接入 AndroidAutoSize，但是作為一個全面性的螢幕適配框架，在保證基礎功能的簡易性的同時，也必須保證複雜的需求也能在框架內被解決，從而達到一個小閉環，所以下面介紹的內容全是前人踩坑踩出來的一些必備功能，如果你沒這個需求，或者覺得麻煩，可以按需檢視或者跳過，下面的內容建議和 Demo 配合起來閱讀，效果更佳

注意事項

• 你在 AndroidManifest.xml 中怎麼把設計圖的 px 尺寸轉換為 dp 尺寸，那在佈局時，每個控制元件的大小也需要以同樣的方式將設計圖上標註的 px 尺寸轉換為 dp 尺寸，千萬不要在 AndroidManifest.xml 中填寫的是 dp 尺寸，卻在佈局中繼續填寫設計圖上標註的 px 尺寸

• design_width_in_dp 和 design_height_in_dp 雖然都需要填寫，但是 AndroidAutoSize 只會將高度和寬度其中的一個作為基準進行適配，一方作為基準，另一方就會變為備用，預設以寬度為基準進行適配，可以通過 AutoSizeConfig#setBaseOnWidth(Boolean) 不停的切換，這意味著最後執行到裝置上的佈局效果，在高度和寬度中只有一方可以和設計圖上一模一樣，另外一方會和設計圖出現偏差，為什麼不像 AndroidAutoLayout 一樣，高和寬都以設計圖的效果等比例完美呈現呢？這也很簡單，你無法保證所有裝置的高寬比例都和你設計圖上的高寬比例一致，特別是在現在全面屏全面推出的情況下，如果這裡不這樣做的話，當你的專案執行在與設計圖高寬比例不一致的裝置上時，佈局會出現嚴重的變形，這個機率非常大，詳情請看 這裡

自動執行是如何做到的？

很多人有疑惑，為什麼使用者只需要在 AndroidManifest.xml 中填寫一下 meta-data 標籤，其他什麼都不做，AndroidAutoSize 就能自動執行，並在 App 啟動時自動解析 AndroidManifest.xml 中填寫的設計圖尺寸，這裡很多人不敢相信，問我真的只需要填寫下設計圖尺寸框架就可以正常執行嗎？難道使用了什麼 黑科技?

其實這裡並沒有用到什麼 黑科技，原理反而非常簡單，只需要宣告一個 ContentProvider，在它的 onCreate 方法中啟動框架即可，在 App 啟動時，系統會在 App 的主程序中自動例項化你宣告的這個 ContentProvider，並呼叫它的 onCreate 方法，執行時機比 Application#onCreate 還靠前，可以做一些初始化的工作，get 到了嗎？

這裡需要注意的是，如果你的專案擁有多程序，系統只會在主程序中例項化一個你宣告的 ContentProvider，並不會在其他非主程序中例項化 ContentProvider，如果在當前程序中 ContentProvider 沒有被例項化，那 ContentProvider#onCreate 就不會被呼叫，你的初始化程式碼在當前程序中也就不會執行，這時就需要在 Application#onCreate 中呼叫下 ContentProvider#query 執行一下查詢操作，這時 ContentProvider 就會在當前程序中例項化 (每個程序中只會保證有一個例項)，所以應用到框架中就是，如果你需要在多個程序中都進行螢幕適配，那就需要在 Application#onCreate 中呼叫 AutoSize#initCompatMultiProcess 方法

進階使用

雖然 AndroidAutoSize 不需要其他過多的配置，只需要在 AndroidManifest.xml 中填寫下設計圖尺寸就能正常執行，但 AndroidAutoSize 還是為大家準備了很多可配置選項，盡最大可能滿足大家日常開發中的所有擴充套件需求

所有的全域性配置選項在 Demo 中都有介紹，每個 API 中也都有詳細的註釋，在這裡就不過多介紹了

自定義 Activity

在 AndroidManifest.xml 中填寫的設計圖尺寸，是整個專案的全域性設計圖尺寸，但是如果某些 Activity 頁面由於某些原因，設計師單獨出圖，這個頁面的設計圖尺寸和在 AndroidManifest.xml 中填寫的設計圖尺寸不一樣該怎麼辦呢？不要急，AndroidAutoSize 已經為你考慮好了，讓這個頁面的 Activity 實現 CustomAdapt 介面即可實現你的需求，CustomAdapt 介面的第一個方法可以修改當前頁面的設計圖尺寸，第二個方法可以切換當前頁面的適配基準，下面的註釋都解釋的很清楚

public class CustomAdaptActivity extends AppCompatActivity implements CustomAdapt {

	 /**
     * 是否按照寬度進行等比例適配 (為了保證在高寬比不同的螢幕上也能正常適配, 所以只能在寬度和高度之中選擇一個作為基準進行適配)
     *
     * @return {@code true} 為按照寬度進行適配, {@code false} 為按照高度進行適配
     */
    @Override
    public boolean isBaseOnWidth() {
        return false;
    }

	 /**
     * 這裡使用 iPhone 的設計圖, iPhone 的設計圖尺寸為 750px * 1334px, 高換算成 dp 為 667 (1334px / 2 = 667dp)
     * <p>
     * 返回設計圖上的設計尺寸, 單位 dp
     * {@link #getSizeInDp} 須配合 {@link #isBaseOnWidth()} 使用, 規則如下:
     * 如果 {@link #isBaseOnWidth()} 返回 {@code true}, {@link #getSizeInDp} 則應該返回設計圖的總寬度
     * 如果 {@link #isBaseOnWidth()} 返回 {@code false}, {@link #getSizeInDp} 則應該返回設計圖的總高度
     * 如果您不需要自定義設計圖上的設計尺寸, 想繼續使用在 AndroidManifest 中填寫的設計圖尺寸, {@link #getSizeInDp} 則返回 {@code 0}
     *
     * @return 設計圖上的設計尺寸, 單位 dp
     */
    @Override
    public float getSizeInDp() {
        return 667;
    }
}

如果某個 Activity 想放棄適配，讓這個 Activity 實現 CancelAdapt 介面即可，比如修改 density 影響到了老專案中的某些 Activity 頁面的佈局效果，這時就可以讓這個 Activity 實現 CancelAdapt 介面

public class CancelAdaptActivity extends AppCompatActivity implements CancelAdapt {

}

自定義 Fragment

Fragment 的自定義方式和 Activity 是一樣的，只不過在使用前需要先在 App 初始化時開啟對 Fragment 的支援

AutoSizeConfig.getInstance().setCustomFragment(true);

實現 CustomAdapt

public class CustomAdaptFragment extends Fragment implements CustomAdapt {

    @Override
    public boolean isBaseOnWidth() {
        return false;
    }

    @Override
    public float getSizeInDp() {
        return 667;
    }
}

實現 CancelAdapt

public class CancelAdaptFragment extends Fragment implements CancelAdapt {

}

適配三方庫頁面

在使用主單位時可以使用 ExternalAdaptManager 來實現在不修改三方庫原始碼的情況下，適配三方庫的所有頁面 (Activity、Fragment)

由於 AndroidAutoSize 要求需要自定義適配引數或取消適配的頁面必須實現 CustomAdapt、CancelAdapt，這時問題就來了，三方庫是通過遠端依賴的，我們無法修改它的原始碼，這時我們怎麼讓三方庫的頁面也能實現自定義適配引數或取消適配呢？別急，這個需求 AndroidAutoSize 也已經為你考慮好了，當然不會讓你將三方庫下載到本地然後改原始碼！

• 通過 ExternalAdaptManager#addExternalAdaptInfoOfActivity(Class, ExternalAdaptInfo) 將需要自定義的類和自定義適配引數新增進方法即可替代實現 CustomAdapt 的方式，這裡 展示了使用方式，以及詳細的註釋

• 通過 ExternalAdaptManager#addCancelAdaptOfActivity(Class) 將需要取消適配的類新增進方法即可替代實現 CancelAdapt 的方式，這裡 也展示了使用方式，以及詳細的註釋

需要注意的是 ExternalAdaptManager 的方法雖然可以新增任何類，但是隻能支援 Activity、Fragment，並且 ExternalAdaptManager 是支援鏈式呼叫的，以便於持續新增多個頁面

當然 ExternalAdaptManager 不僅可以對三方庫的頁面使用，也可以讓自己專案中的 Activity、Fragment 不用實現 CustomAdapt、CancelAdapt 即可達到自定義適配引數和取消適配的功能

副單位

前面已經介紹了 副單位 的應用場景，這裡就直接介紹 副單位 如何使用，副單位 的 Demo 在 demo-subunits

基本使用

首先和 主單位 一樣也需要先在 app 的 AndroidManifest.xml 中填寫上設計圖尺寸，但和 主單位 不一樣的是，當在使用 副單位 時 design_width_in_dp 和 design_height_in_dp 的單位不需要一定是 dp，可以直接填寫設計圖的 px 尺寸，在佈局檔案中每個控制元件的大小也可以直接填寫設計圖上標註的 px 尺寸，無需再將 px 轉換為 dp，這是 副單位的 特性之一，可以幫助大家提高開發效率

<manifest>
    <application>            
        <meta-data
            android:name="design_width_in_dp"
            android:value="1080"/>
        <meta-data
            android:name="design_height_in_dp"
            android:value="1920"/>           
     </application>           
</manifest>

由於 AndroidAutoSize 提供了 pt、in、mm 三種類型的 副單位 供使用者選擇，所以在使用 副單位 時，還需要在 APP 初始化時，通過 UnitsManager#setSupportSubunits(Subunits) 方法選擇一個你喜歡的副單位，然後在佈局檔案中使用這個副單位進行佈局，三種類型的副單位，其實效果都是一樣，大家按喜歡的名字選擇即可

由於使用副單位是為了徹底遮蔽修改 density 所造成的對三方庫頁面、三方庫控制元件以及系統控制元件的佈局效果的影響，所以在使用副單位時建議呼叫 UnitsManager#setSupportDP(false) 和 UnitsManager#setSupportSP(false)，關閉 AndroidAutoSize 對 dp 和 sp 的支援，AndroidAutoSize 為什麼不在使用 副單位 時預設關閉對 dp、sp 的支援？因為允許同時支援 主單位 和 副單位 可以幫助使用者在 主單位 和 副單位 之間切換時更好的過渡，這點在前面就已經提到過

UnitsManager 的詳細使用方法，在 demo-subunits 中都有展示，註釋也十分詳細

自定義 Activity 和 Fragment

在使用 副單位 時自定義 Activity 和 Fragment 的方式是和 主單位 是一樣的，這裡就不再過多介紹了

適配三方庫頁面

如果你的專案在使用 副單位 並且關閉了對 主單位 (dp、sp) 的支援，這時 ExternalAdaptManager 對三方庫的頁面是不起作用的，只對自己專案中的頁面起作用，除非三方庫的頁面也使用了副單位 (pt、in、mm) 進行佈局

其實 副單位 之所以能徹底遮蔽修改 density 所造成的對三方庫頁面、三方庫控制元件以及系統控制元件的佈局效果的影響，就是因為三方庫頁面、三方庫控制元件以及系統控制元件基本上使用的都是 dp、sp 進行佈局，所以只要 AndroidAutoSize 關閉了對 dp、sp 的支援，轉而使用 副單位 進行佈局，就能徹底遮蔽修改 density 所造成的對三方庫頁面、三方庫控制元件以及系統控制元件的佈局效果的影響

但這也同樣意味著使用 副單位 就不能適配三方庫的頁面了，ExternalAdaptManager 也就對三方庫的頁面不起作用了

佈局實時預覽

在開發階段佈局時的實時預覽是一個很重要的環節，很多情況下 Android Studio 提供的預設預覽裝置並不能完全展示我們的設計圖，所以我們就需要自己建立模擬裝置，dp、pt、in、mm 這四種單位的模擬裝置建立方法請看 這裡

總結

AndroidAutoSize 在經歷了 240+ commit、60+ issues、6 個版本 的洗禮後，逐漸的穩定了下來，已經在上個星期釋出了首個正式版，在這裡要感謝將 AndroidAutoSize 接入到自己專案中的上千個使用者，感謝他們的信賴，AndroidAutoSize 建立的初衷就是為了讓所有使用 今日頭條螢幕適配方案 的使用者能有一個可以一起交流、溝通的聚集地，所以後面也會持續的收集並解決 今日頭條螢幕適配方案的常見問題，讓 今日頭條螢幕適配方案 變得更加成熟、穩定

至此本系列的第三篇文章也就完結了，這也預示著這個系列連載的終結，這篇文章建議結合系列的第一篇文章 騷年你的螢幕適配方式該升級了!（一）-今日頭條適配方案 一起看，這樣可以對 今日頭條螢幕適配方案 有一個更深入的理解，如果你能將整個系列的文章都全部認真看完，那你對 Android 螢幕適配領域的相關知識絕對會有一個飛速的提升!

當你的專案需要切換某個框架時，你會怎麼去考察、分析、對比現有的開源方案，並有足夠的理由去選擇或優化一個最適合自己專案的方案呢？其實整個系列文章可以看作是我怎麼去選擇同類型開源方案的過程，你以後當遇到同樣的選擇也可以參照我的思維方式去處理，當然如果以後面試官問到你螢幕適配相關的問題，你能將我如何選擇、分析、對比已有方案的過程以及文章中的核心知識點告訴給面試官，那肯定比你直接說一句我使用的是某某開源庫有價值得多

以下是 騷年你的螢幕適配方式該升級了! 系列文章，歡迎轉發以及分享:

Hello 我叫 JessYan，如果您喜歡我的文章，可以在以下平臺關注我

– The end