前些年我在调查某个导航栏bug的时候查阅过systemui的代码,当时意外地发现大量的模块包括statusbar、recents、keyguard等都是di方式引入的。虽然对dagger略有耳闻,但仍看得云里雾里,不得其解。
systemui作为android系统里最核心最复杂的app,称之为大型项目毫不过分。现在就来看看dagger2如何助力这个大型app管理大量的系统组件。
※ 源码版本:android 11
systemui中主要的依赖实例都管理在denpency类中。
public class dependency {
…
@inject @background lazy mbackgroundexecutor;
@inject lazy mclockmanager;
@inject lazy mactivitymanagerwrapper;
@inject lazy mdevicepolicymanagerwrapper;
@inject lazy mpackagemanagerwrapper;
@inject lazy msensorprivacycontroller;
@inject lazy mdockmanager;
@inject lazy minotificationmanager;
@inject lazy msysuistateflagscontainer;
@inject lazy malarmmanager;
@inject lazy mkeyguardsecuritymodel;
@inject lazy mdozeparameters;
@inject lazy mwallpapermanager;
@inject lazy mcommandqueue;
@inject lazy mrecents;
@inject lazy mstatusbar;
@inject lazy mdisplaycontroller;
@inject lazy msystemwindows;
}
后面以statusbar实例的注入为例阐述下systemui里dagger2的注入流程。
随着systemserver发出启动systemuiservice的请求,systemui的application将首先被实例化。在实例化之前,指定的appcomponentfactory实现类将会收到回调。
// androidmanifest.xml
<application
android:name=“.systemuiapplication”
…
tools:replace=“android:appcomponentfactory”
android:appcomponentfactory=“.systemuiappcomponentfactory”>
调用super得到application实例之后向其注册context准备完毕的回调,该回调会执行systemuifactory和di组件的初始化。
public class systemuiappcomponentfactory extends appcomponentfactory {
@inject
public contextcomponenthelper mcomponenthelper;
…
@override
public application instantiateapplicationcompat(
@nonnull classloader cl, @nonnull string classname)
throws instantiationexception, illegalaccessexception, classnotfoundexception {
application app = super.instantiateapplicationcompat(cl, classname);
if (app instanceof contextinitializer) {
发表评论