以下是我这个系列的相关文章,有兴趣可以参考一下,可以给个喜欢或者关注我的文章。
[Android]如何做一个崩溃率少于千分之三噶应用app--章节列表、
这个系列的有关架构的概念,适合有大概三年以上Android经验的同学理解。如果你大概一年半以上经验,入门进阶了,我近段时间会开展分析MVP的相关架构章节。到时有兴趣的同学,可以查看一番。
在我创建的QQ群中,收到很多热心好学的同学询问一些问题,然后我们讨论进一步思考这些问题,也多谢他们给的建议,让我也受益匪浅。
这节要讨论的Application组件化的相关问题。
问题来了,每个module中都可以有Application吗,一个工程中能全部装载这些Application吗?
为了验证这个问题,我就尝试在我的主工程创建一个Application,两个次级的功能module里各自声明一个Application,然后编译,然后你会意外发现出错了。
会提示工程里面存在着多个Application,需要使用“tools:replace="andriod:name”声明去复写AndroidMainifest.xml的文件
好吧,改就改吧,修改完功能的Application,然后继续编译。。。
发现,继续宿主的Application会出现问题了,还是之前一样的问题,那只好继续修改了。
然后是可以编译成功了,问题来了,那Application最后会成为囧样的呢?
从编译的build的mainfest的文件夹里面AndroidMainfest.xml,看到最终还是以ModuleApplication作为最终的module的。
那么那么我们可以猜想到,编译应该是功能module的完成,再继续编译主module生产Application,但是可惜Android studio的编译并不允许这些Application作为合并,只会将最后的Application放到工程里面编译。
既然编译只能作为替换Application,有些引用的库是需要Application的onCreate里面初始化,或者这个时间触发的。这将会让我们的工程资源是否能必须引用更多的库,会影响整个工程的体积。
那么我们可以怎么解决各个module初始化的问题呢???
相信有看过我之间这个系列文章的同学应该有一定的体会。
这里我提出了接口的思想去解决问题。
(1)我先创建一个ModuleImpl的接口,里面有一个onLoad(Application app)的方法
(2)我们让需要做某些初始化的Module继承这个ModuleImpl的接口
然后添加覆写方法
(3)我们在主module的PageConfig里面可以建立一个引用的列表
(4)然后我们建立一个ModuleApplicaiton到主module,然后使用反射方法的思想来运行。
这样就可以完成直接反射调用了,可以运行每个的module的onLoad初始化。
Application的onCreate并木有参数,所以我的onLoad里面只传入Application本身进去。
那么这样就已经是最好的处理了?
(1)其实这里反射可以再简化运用接口调用
这里对比了一下反射速度,其实并没相差多少。但是直接运行接口方法,肯定是要反射调用快的。关于反射方法优化,请自行百度。
(2)这里简单的试了一下,就只是打印一些东西启动的时候反射调用了两个文件打印10个log时间8。
反射的是分两方面的
1.Class.forName创建类
Class.forName是通过类名,找到类再创建,我们这里每个module初始化的时候都需要调用一个类创建。
2.invoke调用
这里invoke调用是通过搜索类中方法的列表来调用的,那么对比类中方法也是需要时间的,刚刚初始化的对象是module里方法多了反射将会非常变慢。
这里我们初始化的时候,因为减少查询的方法表的速度,只封装一个类,加载一个方法来调用,再次编译PageConfig的数组和ModuleApplication里面遍历,再试试调用方法,你会发现调用的时间会变为3。只是小小的优化。
具体的可以查看ModuleBus开源源码(github.com/cangwang/Mo…)
(想要壁纸,那就下源码吧)
还有更优化的Application初始化方法吗?
1.个人觉得只能类似EventBus3.0的编译时注解才能真正提升编译了。
2.也可以使用AOP相关思想来做。
不知道是否有同学想到如何优化,可以留言给更多的建议,谢谢!!!
我建立了一个关于Android架构学习的群,里面可以进一步进行组件化学习和架构思想的的交流。
群号是316556016,也可以扫码进群。我在这里期待你们的加入!!!