前言
AndroidX出來一段時間了，從09年開始一直在做公司的quickstart和組件化的東西，基礎框架搭建這一塊也算是有一些成績。從原來的功能的抽象的封裝，到現在系統性質研究。
正文
新的項目啓動，有利於做一些前沿技術的思想的學習和吸收。androidx問世以後，從長遠角度出發，確實是android開發者的福音。谷歌終於開始佈局對於開發者友好以一塊的事情了。也許是長期依賴開發者對兼容包詬病很多，不管谷歌出於什麼樣的目的，長遠看來確實是一件好事
然而，實際並沒有那麼簡單
在開始使用androidx的時候也碰到了一些棘手的事情，比如如何將舊項目遷移到androidx上面來，還好google在as IDE上面增加了Migrate功能。雖然這個功能並不能搞定所有的事情，但是最起碼是一個好的開始。修改的工作量稍微降低了一些。可能最費勁的要屬material庫的修改，並不能很好的支持遷移
廢話不多說，今天就從core包的幾個類講起，他們分別是：
- ContextCompat
- IntentCompat
- ActivityCompat
- ActivityOptionsCompat
通過對這幾個類的源碼進行解讀我們不難發現，這個兼容類，是爲了幫我們處理不同Build.VERSION.SDK_INT 所對應的實現相同功能的不同調用方式
注意：⚠️SDK_INT 這個版本運行在硬件設備上的SDK版本，這個值不會被改變，除非硬件廠商提供OTA更新
/**
* The SDK version of the software currently running on this hardware
* device. This value never changes while a device is booted, but it may
* increase when the hardware manufacturer provides an OTA update.
* <p>
* Possible values are defined in {@link Build.VERSION_CODES}.
*/
public static final int SDK_INT = SystemProperties.getInt(
"ro.build.version.sdk", 0);
這裏我們舉例說明一下
ContextCompat
/**
* Return the handle to a system-level service by class.
*
* @param context Context to retrieve service from.
* @param serviceClass The class of the desired service.
* @return The service or null if the class is not a supported system service.
*
* @see Context#getSystemService(Class)
*/
@SuppressWarnings("unchecked")
@Nullable
public static <T> T getSystemService(@NonNull Context context, @NonNull Class<T> serviceClass) {
if (Build.VERSION.SDK_INT >= 23) {
return context.getSystemService(serviceClass);
}
String serviceName = getSystemServiceName(context, serviceClass);
return serviceName != null ? (T) context.getSystemService(serviceName) : null;
}
/**
* Gets the name of the system-level service that is represented by the specified class.
*
* @param context Context to retrieve service name from.
* @param serviceClass The class of the desired service.
* @return The service name or null if the class is not a supported system service.
*
* @see Context#getSystemServiceName(Class)
*/
@Nullable
public static String getSystemServiceName(@NonNull Context context,
@NonNull Class<?> serviceClass) {
if (Build.VERSION.SDK_INT >= 23) {
return context.getSystemServiceName(serviceClass);
}
return LegacyServiceMapHolder.SERVICES.get(serviceClass);
}
上面這端代碼在獲取SystemSerivce的時候會進行SDK_INT的判斷，選擇不同的獲取service的方法。
我們進入context兩種獲取service的方法看看代碼
public abstract @Nullable Object getSystemService(@ServiceName @NonNull String name);
public final @Nullable <T> T getSystemService(@NonNull Class<T> serviceClass) {
// Because subclasses may override getSystemService(String) we cannot
// perform a lookup by class alone. We must first map the class to its
// service name then invoke the string-based method.
String serviceName = getSystemServiceName(serviceClass);
return serviceName != null ? (T)getSystemService(serviceName) : null;
}
咋一開並不是很明白，通過類獲取服務的方式的最終實現還是通過類的名字進行獲取的，這裏我們先不去關心他爲什麼要這樣做，只關注他的實現最終希望達到的效果你就明白了
core包下面的這些Compat類都是爲了方便開發者去調用的東西，幫助開發者屏蔽掉底層實現的差異性，從而簡化應用層代碼的編寫。
所以長遠看，androidx 確實是一個不錯的選擇，也是google android想對這一塊進行整改和優化，如今的android硬件和軟件都已經可以媲美ios了，價格也便宜，甚至在競合關係的大浪潮下取得了驕人成績，甚至超越了蘋果，打破了只能模仿從未超越的局面，成功逆襲。
好聽的說太多，並不好，這裏還是要並着批判的態度看待問題，我剛纔說過從長遠看，androidx是未來的方向和趨勢，現在是個什麼樣子呢？有沒有什麼問題呢？
這裏我僅僅推薦一篇文章供大家參考，後續會增加更多相關的文章進行整理，方便大家查閱和解決手上棘手的bug
總是聽到有人說AndroidX，到底什麼是AndroidX？