谈到Jetpack,你们都觉得是一堆框架,事实上它的内容要大的多。本文以你们熟知的Preference组件为切入点,逐步探究它的前世此生。java
Preference
做为设置画面的标准实现,你们都不陌生。这个组件跟随Android系统一同诞生,以后便不断地变动。先是Support库
中出现了独立版本,接着整合到了AndroidX
中,最后在Android 10的时候彻底废弃了SDK版本。android
Preference
组件的API设计得很是简单、清晰。markdown
类 | 做用 |
---|---|
PreferenceActivity | 提供了Preference布局设置和查找的ListActivity |
PreferenceFragment | 展现Preference布局的专属Fragment |
Preference | 全部Preference组件的基类,预设了Preference处理的基本API |
PreferenceGroup | 扩展自Preference,用以嵌套Preference组件并内置List进行管理 |
PreferenceScreen | 扩展自PreferenceGroup,嵌套Preference组件的根布局,内部将管理列表View和对应的Adapter |
PreferenceCategory | 扩展自PreferenceGroup,展现设置条目分组的小标题,不可点击、不可得到焦点 |
SwitchPreference | 内置了Switch控件的Preference组件,相似的扩展组件还有ListPreference、EditTextPreference等 |
... |
Preference组件是Android 1.0发布就引入的元老级组件,那会RecyclerView
还未推出,天然采用经典的ListView
构建整个设置列表。架构
使用起来很是简单,跟普通视图的写法并没有二致。app
<PreferenceScreen android:title="@string/my_preference_settings">
<PreferenceCategory android:title="@string/my_preference_general" >
<Preference android:fragment="com.android.settings.applications.ManageApplications" android:key="app" android:title="@string/my_preference_general_apps" />
</PreferenceCategory>
...
</PreferenceScreen>
复制代码
public class SettingsActivity extends PreferenceActivity {
public void onCreate(Bundle bundle) {
super.onCreate(bundle);
addPreferencesFromResource(R.xml.my_preference_layout);
}
}
复制代码
原理也不复杂:框架
ListView的性能欠佳,再也不适应复杂的设置画面,尤为是内容众多的系统设置App。ide
Support库
是为新API提供向后兼容性的支持库,包含大量应用组件、视图、Material Design
等功能类。从新改写的Preference
组件也包含其中。工具
依据兼容API版本的不一样,Support库的分支众多且凌乱,使用起来也愈发繁琐和呆板。oop
Preference组件的变动首次出如今Support库的V7包,主要是将SDK版本的Preference组件拷贝过来进行了重写。布局
对外的API只是微调,区别大致集中在内部的实现细节上:
onBindViewHolder()
来向RecyclerView提供条目的视图另外,针对实现变化较大的API,在原有命名上增长Compat字样,好比PreferenceFragment改成PreferenceFragmentCompat
。
使用的话需导入额外依赖:
implementation 'com.android.support:preference-v7:28.0.0'
复制代码
另外要注意的是Fragment里加载布局的API由addPreferencesFromResource()改成setPreferencesFromResource()
。因为API只是微调,其余使用起来几乎没有变化。
public static class PrefsFragment extends PreferenceFragmentCompat {
@Override
public void onCreatePreferences(Bundle savedInstanceState, String rootKey) {
setPreferencesFromResource(R.xml.preferences, rootKey);
}
}
复制代码
第二次变动发生在V14包,区别只是将命名里的Compat
字样去掉了,弱化了和SDK版本的API差别。
好比:
导入只须要细微调整便可:
implementation 'com.android.support:preference-v14:28.0.0'
复制代码
随着Android系统逐渐流行到TV等大屏设备,Google推出了Leanback
导航模式,并引入到了V17中。Preference组件也针对Leanback模式进行了跟进,新增了一系列新组件。
新的类 | 做用 |
---|---|
BaseLeanbackPreferenceFragment | 相似瑞士军刀风格的PreferenceFragment抽象基类,内部集成了VerticalGridView控件 |
LeanbackPreferenceFragment | 外层包裹了标题的BaseLeanbackPreferenceFragment子类 |
LeanbackSettingsFragment | 根布局为LeanbackSettingsRootView的Fragment组件,主要和LeanbackPreferenceFragment配合使用 |
LeanbackPreferenceDialogFragment | 带DialogPreference的Leanback Fragment组件 |
LeanbackListPreferenceDialogFragment | 带ListPreference的LeanbackPreferenceDialogFragment组件 |
好比Support库各分支下Preference组件在AndroidX下的对应关系:
Support库 | AndroidX |
---|---|
com.android.support:preference-v7 | androidx.preference:preference |
com.android.support:preference-v14 | androidx.legacy:legacy-preference-v14 |
com.android.support:preference-leanback-v17 | androidx.leanback:leanback-preference |
使用也很方便,只需指定对应的包名和版本便可:
def preference_version = "1.1.1"
implementation "androidx.preference:preference:$preference_version"
复制代码
AndroidX和原有Support库的API对应关系,能够到官方的映射表里进行查询:
将最核心的Preference类进行对比,能够发现:除了格式、书写风格的差别之外,代码逻辑几乎彻底一致。
再好比AndroidX里提供的PreferenceFragment类,其实现和Support库的版本几乎是同样的。
AndroidX replaces the original support library APIs with packages in the
androidx
namespace. Only the package and Maven artifact names changed; class, method, and field names did not change.
像官方描述的那样,AndroidX是针对Support库的整合和替代,区别仅仅体如今仓库的地址和包名。正由于此,AndroidX拥有清晰统一的版本管理,开发者能便捷和灵活地使用。
以前,Preference组件等新API分散在Support库的各个分支包里,源文件也会集成到AOSP源码,ROM厂商能够修改。
好比V14包的Preference组件在AOSP源码的对应位置以下。
/frameworks/support/v14/preference/src/android/support/v14/preference/
Android 9开始整合到了AndroidX里,但为了过渡,源文件在AOSP源码里仍然保留。也就是咱们仍然能够修改其源码。
/frameworks/support/preference/src/main/java/androidx/preference/
Android 10开始全面转向AndroidX,完全废弃Support库的使用。AOSP源码里也再也不集成源文件,只提供了对应的AAR包,这也使得ROM厂商更改实现变得困难,须要额外留意。
/prebuilts/sdk/current/androidx/m2repository/androidx/preference/
为了简化向后兼容的开发工做,将Support库全面迁移至AndroidX极为必要,设置以下的Gradle 插件标志便可。
android.useAndroidX
:Android 插件会使用对应的 AndroidX 替代Support库android.enableJetifier
:Android 插件会经过重写其二进制文件来自动迁移现有的第三方库,以使用 AndroidX 依赖项固然在AndroidStudio菜单里也能够手动地迁移至AndroidX:Menu
→ Refactor
→ Migrate to AndroidX
。
更详细的迁移细节能够参考以下这篇文章:
依照官方提供的AndroidX构成列表,我归纳并制做了一张AndroidX的构成图。
能够看到,实际上AndroidX在集成了Support库的之外,还涵盖了众多知名的Jetpack框架,这些框架实际上来源于2017年发布的Android Architecture Components(AAC)。
Android App开发有不少痛点,包括Activity/Fragment生命周期的管理较为呆板,线程间数据传递的复杂,SQLite封装的繁琐等等。为了改善这些情况并对App架构进行指导,Google IO 2017上发布了Android Architecture Components
,简称AAC
。
它包含了几个较为经典的框架:
Lifecycle
LiveData
ViewModel
Room
Paging
、Navigation
和WorkManager
同时Google还给Android开发者展现了推荐的应用架构,随着Jetpack家族的日益壮大,先在看来这个架构图略显简单。
AAC库在完善的过程当中,和Support库一块儿,也逐步往AndroidX中迁移,并孕育出一个更大更强的概念Jetpack。
短短一年后,Android Architecture Components就退出了舞台,Google IO 2018上发布了全新的Jetpack开发套件。
核心的Architecture
模块涵盖了熟知的框架,前身就是去年发布的AAC库
以及从Support
库整合过来的包,好比Preference
、Framgent
、AppCompat
等
除此以外,还包括KTX
和Test
工具包等
Android Jetpack is a set of libraries, tools and architectural guidance to help make it quick and easy to build great Android apps. It provides common infrastructure code so you can focus on what makes your app unique.
因此说,将Jetpack理解为一系列框架不够准确。实际上它是包含了框架、KTX、开发工具和开发向导的开发套件,指望在多个层面提高与Android开发的效率。
Jetpack开发套件的源码管理在AndroidX内,包括以前的Support库,还有后来吸取的AAC库等等。简要绘制了一下Jetpack的演变图。(画着画着,竟画成了Android机器人的形象,哈哈)
非要总结下Jetpack和AndroidX关系的话,像fundroid大神描述的那样比较贴切。
AndroidX是对SDK之外API的内部管理包,Jetpack则是对外宣传的开发套件。
“AndroidX”的名字也很酷啊,那为何不直接用它来进行宣传? 我的的一些理解:
Android的分支众多、迭代太快,开发者疲于应对。Google一直在试图改变这种混乱局面,从经典的Support库
,到变革的AAC库
,再到持续火爆的Jetpack套件
。
与此同时,随着Android系统越发完善,SDK也趋于稳定,一年一度的OSV终将是小修小补。但行业的持续发展必将催生层出不穷的新理念、新技术。Google天然不会停下脚步,它将以更高频次、更大范围的动做去变革和应对,而这多将聚焦在SDK之外的领域,好比Jetpack、MAD等。
MAD
,全称Modern Android Development
,是Google针对Android平台的全新开发理念。它站在比Jetpack更高的视野,旨在经过语言、工具、发行格式、框架等多个层面去指导新型的Android开发。
在Jetpack套件之外MAD还囊括了诸多内容,包括:
Android Studio
Kotlin
开发语言Android App Bundle
发行格式Compose
工具包能够说,MAD
是每一个Android开发者都应了解和掌握的重要技术,后续我将解读这个全新的开发理念。
基于Android Architecture Components的应用架构指南