美文网首页如何做一个崩溃率少于千分之三噶应用appAndroid知识Android开发
[Android]如何做一个崩溃率少于千分之三噶应用app(13

[Android]如何做一个崩溃率少于千分之三噶应用app(13

作者: CangWang | 来源:发表于2016-12-29 09:59 被阅读1794次

    以下是我这个系列的相关文章,有兴趣可以参考一下,可以给个喜欢或者关注我的文章。

    [Android]如何做一个崩溃率少于千分之三噶应用app--章节列表

    近来业务忙得不亦乐乎,因为年底要研发发红包了,哈哈。

    相信有关注我的文章的人,已经等了很久了,我也在这一章发我最大的福利。(酝酿了这么久终于要发大招啦)

    看完我上一节关于Activity的module间跳转跳转后,是否对大家有一定的启发呢?

    **************

    如果Android研发已经开发有三五年经验,很多人经历过4.0 Fragment的出现后,就会有人编写到一些关于Fragment的架构,例如单Activity+多Fragment,多Activity+多Fragment的架构。再后来MVP架构的盛行,MVVM架构的提出,然后通过到工具的变迁从Eclipse到Android studio,产生组件化架构开发。

    架构的变更,系统代码框架的变化,研发的工具换代,新的架构思想的普及,项目一年一次的大版本的变化。

    这些都会让你觉得你重新思考是否需要重构现在的代码,重构代码并不是易事。你需要重新绘制你代码的线路图,和新架构思想的线路图。框架是要规范各种开发,基础在于设计模式,各种设计模式利用的场景。

    Android的源码是很好例子,其每年都会有新的变更,更高效更高质量的代码思想,很多时候起源都是对源码的熟读和利用。以前你觉得越来越多程序猿去研究源码,费事费力,做app为何会需要研究这些东西?你觉得设计模式都是从哪里来的,为何需要设计模式,业务只要用好if else已经足够自己饮醉了。

    当你经历了这些,你需要用一个全新的思维方式看待那些你认为熟悉的代码。从功能到架构,看到起源点。

    组件化模块化架构的,最终还是离不开Activity与Fragment,View之间的关系。Module并不存在与代码层,它应该是一个结构层的概念。架构的魅力在于分而治之,抽象分离。

    这期的主题系Activity分发功能Module

    我们为何要分发功能module?

    如果我们一个Activity的组成非常复杂,非常多内容,例如一个直播间里面,有视频,礼物栏,有发言,有氛围灯非常多得功能模块,那么我们希望将功能分开,而且每一个都有他们独有的层级。那么将这些功能封装到一个Module里面是一个很好的选择。

    我们分发功能能module的时候需要一些什么?

    (1)传递activity的对象

    (2)Activity模块对应的ViewGroup

    (3)Activity模块保存全部View数据的Bundle saveInstance

    Activity组件化架构图

    我们使用一个ELModuleContext来保存这些数据

    当然一个Module里面,可以占用多个ViewGroup,所以使用了SpraseArrayCompat这兼容类。

    我们如果管理这些Module?它与Activity间如何关联?

    当然我们这些module拥有着和Activity一样的生命周期,但是我们不一定全部的生命周期都会用到,那么我就设定一些必要的声明周期调用ModuleManager

    modules保存一些Module类名字和它持有Activity的ViewGroup

    allModules保存的是Module类名字和其Module类实体

    全部的Module类实体需要继承于ELAbsModule抽象类,里面都是需要实现它这些生命周期方法。

    这里也提供一个Base的类,用于懒人,我们已经重写过了

    然后扩展一个initModule的方法来,保存saveInstance,Activity和modules信息实例

    嵌入到一个抽象base的基类,用于回调setContentView和moduleConfig的信息(具体基类的实现也可以用接口的方式组合实现)

    那么到只要再继承于这基类的Activity,那么module就可以拥有Activity共享的生命周期了。

    抽象的框架,肯定需要更多的范例支持。

    在这里ModuleBus将会拥有例子的代码给各位读到这里的同学们参考。

    这里使用一个ModuleMainActivity来提供初始的设置,

    其里面包含两个Module,page_name和page_body,给page_name分发page_name的RelativeLayout,给page_body分发page_bodyT和page_bodyB两个layout

    当然我们需要activity的module需要依赖于这两个次module

    这里是使用动态创建的方法来创建出我们想要的module实例

    而两个次module的样式如下

    以page_name的为例,其继承于ELBasicModule,通过moduleContext来获取activity和layout

    然后可以通过layoutInflater来加载module本身的布局page_name_layout

    其布局只有一个简单的textview的title

    最终page_name和page_body的显示

    然后之前有说过提供了一个跨module的通信框架ModuleBus用于module间通信

    只要点击change_Name的按钮,立刻可以跨module转变title的文本。

    详细可以查看ModuleBus的例子,希望大家觉得有用的话,欢迎给个github的星。

    ModuleBus地址

    我也会将这个框架封装到ModuleBus里面,让更多的同学感受到它的魅力。

    如果有疑问可以在留言区提问。

    我也建立了一个关于Android架构学习的群,里面可以进一步进行组件化学习的交流。

    群号是316556016,也可以扫码进群。我在这里期待你们的加入!!!

    这一节就到这里,

    下一节是关于Fragment分发功能组件化的内容,将会更精彩!!!

    相关文章

      网友评论

      • 93e190379222:大神,本身按照功能划分的module,再加上单界面拆分成一个个module会不会太多了,到后面的话各种功能交叉会不会造成依赖混乱啊
        93e190379222:@CangWang 哦哦,没做到过单页面很复杂的东西,长姿势了
        CangWang:@luying6 还有QQ聊天室,各种复杂的模块堆在同一个页面的是时候
        CangWang:@luying6 如果你看直播间里面,高度密集的模块量,你就发现这样的划分是有效的。
      • 前行的乌龟:另外我觉得何必写这么复杂呢,这在业务分层上不应该是划分为公共控件吗,自己把相关功能抽象成第三方控件不更好吗,调用起来不是更方便?
        前行的乌龟: @CangWang 大神可以写一篇,关于自己打ar包,解决依赖冲突的吗?
        CangWang:@前行的乌龟 本来每个lib module最终生成aar,然后再放到application module里面编译,和第三方库并没有什么太大差异。就算你扔一个功能模块的aar出去,给其他工程调用,也是需要依赖于base等库的。如果你想想你每次调base版本(可能不止一个基础模块)和功能模块版本,编译构建等时间消耗。如果出现base版本差异性等问题,调整查询,所消耗得人力,想想也累,我也是做插件化的时候这样折腾过来:joy:
        CangWang:@前行的乌龟如何封装成公共控件的形式,也有利弊。正如那是业务模块,那么就很多需要模块间通信,你如果封装起来其通信就失去灵活性,其需要依赖于同一个base模块才能通信,而第三方库的方式是无法做到的。而你的想法是比较适合于插件化开发的。而这个架构重构到插件化的时候,插件化基础依赖同一个base模块都放在了主模块中了。
      • 前行的乌龟:恩,说一下自己的观点,大神你的项目看了下,我觉得你这抽象方向是不是反了。既然是把复复杂的页面功能剥离成打个的功能 moudle,那么应该是这些功能 moudle 提供自己的 view给需要这个功能的页面。大神你的项目中是把需求者的 view 容器传递给独立的功能 moudle 来实现 view 加载,那么我有一个新的需求者页要显示这个功能 moudle 呢,那么我们还要去改这个功能moudle 吗?比如有的功能 moudle 用到多个需求者的 view 容器了,那么我要是传一个呢,功能moudle 知道是哪个view容器吗,这不就是代码耦合了吗,应该是 moudle 提供自己的 view,别人谁需要爱怎么用怎么用 moudle 不关心啊,所以我认为抽象方向反了!
        CangWang:@前行的乌龟 这个架构是可以做成依赖导致的,我再深入拓展这个架构的时候,会给大家介绍,谢谢你宝贵的建议。
      • kass:页面拆 module?这工程有点儿大了啊
        CangWang:@kass 要看你业务量,功能模块复杂度,适合直播和电商规模的大型单页面多功能业务。
      • sing_song:有点意思,👍

      本文标题:[Android]如何做一个崩溃率少于千分之三噶应用app(13

      本文链接:https://www.haomeiwen.com/subject/jagtvttx.html