今日頭條螢幕適配方案終極版正式釋出!
原文地址:ofollow,noindex">https://www.jianshu.com/p/4aa23d69d481
以下是騷年你的螢幕適配方式該升級了! 系列文章，歡迎轉發以及分享:
前言
我在前面兩篇文章中詳細介紹了今日頭條適配方案 和SmallestWidth 限定符適配方案 的原理，並驗證了它們的可行性，以及總結了它們各自的優缺點，可以說這兩個方案都是目前比較優秀、比較主流的Android 螢幕適配方案，而且它們都已經擁有了一定的使用者基數
但是對於一些才接觸這兩個方案的朋友，肯定或多或少還是不知道如何選擇這兩個方案，我雖然在之前的文章中給出了它們各自的優缺點，但是並沒有用統一的標準對它們進行更細緻的對比，所以也就沒辦法更形象的體現它們的優劣，那下面我就用統一的標準對它們進行對比，看看它們的對比情況
方案對比
我始終堅定地認為在這兩個方案中，並不能以單個標準就能評判出誰一定比誰好，因為它們都有各自的優缺點，都不是完美的，從更客觀的角度來看，它們誰都不能成為最好的那個，只有可能明確了它們各自的優缺點，知道在它們的優缺點裡什麼是我能接受的，什麼是我不能接受的，是否能為了某些優點做出某些妥協，從而選擇出一個最適合自己專案的螢幕適配方案
單純的爭論誰是最好的Android 螢幕適配方案沒有任何意義，每個人的需求不一樣，站的角度不一樣，評判標準也不一樣，你能接受的東西他不一定能接受，你覺得不可接受的東西他卻覺得可以接受，你有你的理由，他有他的理由，想讓一個觀點讓所有人都能接受太難了！所以我在這裡只是列出它們的對比項和對比結果，儘可能的做到客觀，最後的選擇結果請自行決定，如果還有什麼遺漏的對比項，請補充！
| 對比專案 | 對比物件 A | 對比結果 | 對比物件 B |
|---|---|---|---|
| 適配效果(越高越好) | 今日頭條適配方案 | ≈ | SW 限定符適配方案(再未覆蓋的機型上會存在一定的誤差) |
| 穩定性(越高越好) | 今日頭條適配方案 | < | SW 限定符適配方案 |
| 靈活性(越高越好) | 今日頭條適配方案 | > | SW 限定符適配方案 |
| 擴充套件性(越高越好) | 今日頭條適配方案 | > | SW 限定符適配方案 |
| 侵入性(越低越好) | 今日頭條適配方案 | < | SW 限定符適配方案 |
| 使用成本(越低越好) | 今日頭條適配方案 | < | SW 限定符適配方案 |
| 維護成本(越低越好) | 今日頭條適配方案 | < | SW 限定符適配方案 |
| 效能損耗 | 今日頭條適配方案沒有效能損耗 | = | SW 限定符適配方案沒有效能損耗 |
| 副作用 | 今日頭條適配方案會影響一些三方庫和系統控制元件 | ≈ | SW 限定符適配方案會影響 App 的體積 |
可以看到SmallestWidth 限定符適配方案 和今日頭條適配方案 的適配效果其實都是差不多的，我在前面的文章中也通過公式計算過它們的精確度，SmallestWidth 限定符適配方案 執行在未覆蓋的機型上雖然也可以適配，但是卻會出現一定的誤差，所以今日頭條適配方案 的適配精確度確實要比SmallestWidth 限定符適配方案 略高的，不過只要SmallestWidth 限定符適配方案 合理的分配資原始檔，適配效果的差距應該也不大
SmallestWidth 限定符適配方案主打的是穩定性，在執行過程中極少會出現安全隱患，適配範圍也可控，不會產生其他未知的影響，而今日頭條適配方案 主打的是降低開發成本、提高開發效率，使用上更靈活，也能滿足更多的擴充套件需求，簡單一句話概括就是，這兩兄弟，一個求穩，一個求快，好了，我就介紹這麼多了，自己選擇吧！
AndroidAutoSize
由來
下面就開始介紹我根據今日頭條螢幕適配方案 優化的螢幕適配框架 AndroidAutoSize ，大家千萬不要認為，我推出的螢幕適配框架 AndroidAutoSize 是根據今日頭條螢幕適配方案 優化的，我本人就一定支援今日頭條螢幕適配方案 是最好的Android 螢幕適配方案這個觀點，它確實很優秀，但同樣也有很多不足，我最真實的觀點在上面就已經表述咯，至於我為什麼要根據今日頭條螢幕適配方案 再封裝一個螢幕適配框架，無外乎就以下幾點原因:
-
SmallestWidth 限定符適配方案已經有多個優秀的開源解決方案了，它們已經能滿足我們日常開發中的所有需求
-
今日頭條官方技術團隊只公佈了今日頭條螢幕適配方案 的文章 以及核心程式碼，但並沒有在Github 上建立公開的倉庫，一個新的方案必定要有一個成長迭代的過程，在此期間，一定需要一個可以把所有使用者聚集起來的公共社群，可以讓所有使用該方案的使用者在上面交流，大家一起總結、一起填坑，這樣才能讓該方案更成熟穩定，這就是開源的力量
-
今日頭條官方技術團隊公佈的核心程式碼並不能滿足我的所有需求，已經開源的其他基於今日頭條螢幕適配方案 的開源專案以及解決方案也不能滿足我的所有需求，而我有更好的實現想法
-
MVPArms 需要一個適配效果還不錯並且切換維護成本也比較低的螢幕適配框架，以幫助使用者用較低的成本、工作量將已經停止維護的AndroidAutoLayout 快速替換掉
我建議大家都可以去實際體驗一下今日頭條螢幕適配方案 和SmallestWidth 限定符適配方案 ，感受下它們的異同，我給的建議是，可以在專案中先使用今日頭條螢幕適配方案 ，感受下它的使用方式以及適配效果，今日頭條螢幕適配方案 的侵入性非常低，如果在使用過程中遇到什麼不能解決的問題，馬上可以切換為其他的螢幕適配方案，在切換的過程中也花費不了多少工作量，試錯成本非常低
但如果你在專案中先使用SmallestWidth 限定符適配方案 ，之後在使用的過程中再遇到什麼不能解決的問題，這時想切換為其他的螢幕適配方案，這工作量可就大了，每個Layout 檔案都含有大量的dimens 引用，改起來這工作量得有多大，想想都覺得後怕，這就是侵入性太高導致的最致命的問題
如果想體驗今日頭條螢幕適配方案 ，千萬不要錯過AndroidAutoSize 哦！僅需一步即可接入專案，下面是AndroidAutoSize 的地址:
Github :您的 Star 是我堅持的動力 :fist:
與今日頭條螢幕適配方案的關係
AndroidAutoSize與今日頭條螢幕適配方案 的關係，相當於汽車和發動機的關係，今日頭條螢幕適配方案 官方公佈的程式碼，只實現了修改系統density 的相關邏輯，這的確在螢幕適配中起到了最關鍵的作用，但這還遠遠還不夠
要想讓使用者能夠更傻瓜式的使用該方案，並且能夠應對日常開發中的所有複雜需求，那在架構框架時，還需要考慮API 的易用性以及合理性、框架的擴充套件性以及靈活性、功能的全面性、註釋和文件的易讀性等多個方面的問題
於是我帶著我的這些標準在網上搜尋了很久，發現並沒有任何一個開源框架或解決方案能夠達到我的所有標準，它們大多數還只是停留在將今日頭條螢幕適配方案 封裝成工具類來引入專案的階段，這樣在功能的擴充套件上有限制，並且對使用者的使用體驗也不好，而我想做的是一個全面性的產品級螢幕適配框架，這離我最初的構想，差距還非常大，於是我只好自己動手，將我的所有思想實現，這才有了AndroidAutoSize
寫完AndroidAutoSize 框架後，因為對今日頭條螢幕適配方案 有了更加深入的理解，所以才寫了騷年你的螢幕適配方式該升級了!（一）-今日頭條適配方案 ，以幫助大家更清晰的理解今日頭條螢幕適配方案
與 AndroidAutoLayout 的關係
AndroidAutoSize因為名字和鴻神 的AndroidAutoLayout 非常相似，並且在填寫設計圖尺寸的方式上也極為相似，再加上我寫的螢幕適配系列的文章也釋出在了鴻神 的公眾號上，所以很多人以為AndroidAutoSize 是鴻神 寫的AndroidAutoLayout 的升級版，這裡我哭笑不得 :joy:，我只好在這裡說一句，大家好，我叫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 即可自動執行，像下面這樣:point_down:
<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
也是可以的
注意事項
- 你在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，如果您喜歡我的文章，可以在以下平臺關注我
- 個人主頁:http://jessyan.me
- GitHub:https://github.com/JessYanCoding
- 掘金:https://gold.xitu.io/user/57a9dbd9165abd0061714613
- 簡書:http://www.jianshu.com/u/1d0c0bc634db
- 微博:http://weibo.com/u/1786262517
-- The end