Android开发人员应该知道的一些技术

一、Android MVC、MVP以及MVVM框架模式

MVC开发框架

  • View:对应于布局文件和自定义View,负责将用户的请求通知Controller,并根据model更新界面;
  • Controller:对应于Activity、Fragement,负责处理业务逻辑接收用户请求并更新model;(而事实上我们的Activity同时承担着MVC3种角色,代码动不动就上千行!)
  • Model:数据模型,负责数据处理相关的逻辑,封装应用程序状态,响应状态查询,通知View改变。


    MVC

MVP开发框架

  • View 对应于Activity,负责View的绘制以及与用户交互
  • Model 依然是数据模型,负责数据处理相关的逻辑和实体模型
  • Presenter 负责完成View于Model间的交互,处理业务逻辑


    MVP

MVP框架的优点:
①Model层和View层充分解耦。
②复杂的任务被分成细小的任务,并且很容易解决。越小的东西,bug越少,越容易debug,更好测试。
③在MVP模式下的View层将会变得简单,简单直观。
④后台任务不再和Activity联系在一起,这既不会导致内存泄露(OOM),也不依赖于Activity的重建。
⑤Persnter层负责处理业务逻辑,这样业务逻辑就被剥离了出来,不在担心需求的不停变更,可以使开发者更专注解决问题。
⑥可以直接单元测试Persenter层,以致于无需实现和View层和Model层。
MVP框架的缺点:
需要写很多类,原本一个类可以完成的事,现在需要写6个!

MVVM开发框架

  • MVVM可以算是MVP的升级版,将 Presenter 改名为 ViewModel。关键在于ViewModel和Model的双向绑定,当View有用户输入后,ViewModel通知Model更新数据,同理Model数据更新后,ViewModel通知View更新。
  • MVVM的出现还是为了解决View层和Model层之间的解耦,实现了充分解耦。
  • MVVM相比MVP,很大程度上解决了MVP的缺点
  • Android Google在2015年提出的DataBinding Library技术,使得ViewModel和Model之间的双向绑定更加容易。IOS上如果要实现类似功能,使用KVO也可实现。


    MVVM

MVVM框架的优点
①继承了MVP框架的所有优点
②书写更加方便,不必创建很多个类。使得视图层,业务逻辑层,数据模型层,层次结构更加清晰。
③再Model层和View层充分解耦的同时,还实现了数据和视图的双向绑定,数据变化时,视图自动更新。这个特性很有用,对于一些实时性较高的应用来说无疑是最佳的解决方案。例如炒股的一些APP。
MVVM框架在Android工程上的实现的基本要求
①开发工具目前只支持Android Stduio,很显然eclipse已经被Google淘汰。
②Android Studio需要1.3版本以上
③Gradle版本需要2.2以上版本
④Android plugin for gradle 1.3.0及以上版本

二、Android组件化开发和插件化开发技术

Android组件化开发

1、什么是组件化开发?
所谓组件化开发就单独的业务模块抽取出来。每一个模块是一个module,正常一个App中可以有多个module,但是一般只会有一个module是设置为application的,其他均设置为library,组件化开发就是要每个module都可以运行起来,因此在开发期间每个module均设置为application,发布时再进行合并。
2、为什么要使用组件化开发?
① Android项目中代码量达到一定程度,编译将是一件非常痛苦的事情,短则一两分钟,长则达到五六分钟。组件化开发可以有效降低代码模块的耦合度,使代码架构更加清晰,同时模块化的编译可以有效减少编译时间,当然总的编译时间是不会减少的,只是App模块化之后开发某个模块时,只需要编译特定模块,可以快速编译调试。
②组件化实现了业务的解耦和重用。

组件化开发模式的演变

(1) 单工程开发模式


单工程开发模式

该种开发模型已经有了明确的模块划分,并且通过逻辑上的分层呈现出较好结构,该模型最为我们所熟悉,通常用于早期产品的快速开发,团队规模较小的情况下,随着产品的迭代,业务越来越复杂,随之带来的是项目结构复杂度的极度增加,此时我们面临着几个问题:

  • 实际业务变化非常快但是工程之前的业务模块耦合度太高,牵一发而动全身.
  • 对工程所做的任何修改都必须要编译整个工程
  • 功能测试和系统测试每次都要进行.
  • 团队协同开发存在较多的冲突.不得不花费更多的时间去沟通和协调,并且在开发过程中,任何一位成员没办法专注于自己的功能点,影响开发效率.
  • 不能灵活的对工程进行配置和组装.比如今天产品经理说加上这个功能,明天又说去掉,后天在加上.

(2)主工程多组件开发模型
在"单工程"模型的基础上,将业务层中的各业务抽取出来,封装成相应的业务组件,将基础库中各部分抽取出来,封装成基础组件,而主工程是一个可运行的app,作为各组件的入口(主工程也被称之为壳程序).这些组件或以jar的形式呈现,或以aar的形式呈现.主工程通过依赖的方式使用组件所提供的功能.


主工程多组件开发模型

优点:
①每个成员可以专注自己所负责的业务,并不影响其他业务,同时借助稳定的基础组件,可以极大减少代码缺陷,因而整个团队可以以并行开发的方式高效的推进开发进度.
②原有的业务不需要再次进行功能测试,可以专注于发生变化的业务的测试,以及最终的集成测试即可.
缺点:
到现在为止,我们已经有效解决了"单工程开发模型"中一些问题,对于大部分团队来说这种已经可以了,但是该模型仍然存在一些可以改进的点:每次修改依赖包,就需要重新编译生成lib或者aar.比如说小颜同学接手了一个项目有40多个组件,在最后集成所有组件的时候,小颜同学发现其中某组件存在问题,为了定位和修改该组件中的问题,小颜同学不断这调试该组件.由于在该模型下,组件不能脱离主工程,那么意味着,每次修改后,小颜同学都要在漫长的编译过程中等待.更糟糕的是,现在离上线只有5小时了,每次编译10分钟,为改这个bug,编译了20次,恩....什么也不用干了,可以提交离职报告了

(3)主工程多子工程开发模型
不难发现,该种开发模型在结构上和"主工程多组件"并无不同,唯一的区别在于:所有业务组件不再是mouble而是作为一个子工程,基础组件可以使moudle,也可以是子工程,该子工程和主工程不同:Debug模式下下作为app,可以单独的开发,运行,调试;Release模式下作为Library,被主工程所依赖,向主工程提供服务.

主工程多子工程开发模型

优点:
①在该种模型下,当小颜同学发现某个业务组件存在缺陷,会如何做呢?比如是基础组件2出现问题,由于在Debug模式下,基础组件2作为app可以独立运行的,因此可以很容易地对该模块进行单独修改,调试.最后修改完后只需要重新编译一次整个项目即可。
②不难发现该种开发模型有效的减少了全编译的次数,减少编译耗时的同时,方便开发者进行开发调试。
③对测试同学来说,功能测试可以提前,并且能够及时的参与到开发环节中,将风险降到最低。

Android插件化开发

插件化和组件化开发略有不用,插件化开发时将整个app拆分成很多模块,这些模块包括一个宿主和多个插件,每个模块都是一个apk或者Dex包(组件化的每个模块是个lib,尽管调试时是一个应用,打包时还是作为lib处理),最终打包的时候将宿主apk和插件apk分开或者联合打包。

Android插件化和组件化

1、为什么会产生插件化开发模式?
我们知道一个APK包只有一个classes.dex文件,但dex文件最大的方法数为65535。
如果一个应用的业务逻辑十分庞大,例如淘宝、京东。很显然如果只有一个APK文件是远远不够的。那么有什么解决方法,有如下几个:

  • 用 H5、React Native、Flutter 代替部分逻辑
  • 删无用代码
  • 买付费版的 Proguard
  • 另外还有一个就是插件化模式。

2、插件化的优点

  • 模块解耦
  • 应用可以实现动态升级(热更新,差异包更新)
  • 可以动态修复线上应用Bug,而无需重新构建版本,再次升级。
  • 高效并行开发
  • 按需加载相应模块,内存占用率更低
  • 节省流量升级

3、Android插件化基础知识

  • Android进程间通信(IPC)binder机制
  • APP打包流程
  • APP安装流程
  • APP启动流程
  • 资源加载机制
  • Gradle脚本

4、Android插件化实现目前的技术流派

  • 动态替换
  • 静态代理
  • Dex合并(Dex合并就是Android热修复的思想)

5、目前比较流行的第三方插件化框架

  • 360的插件化框架:https://github.com/Qihoo360/DroidPlugin
  • 阿里的插件化框架:https://github.com/alibaba/atlas
  • 百度任玉刚:https://github.com/singwhatiwanna/dynamic-load-apk
  • Google亲儿子:Android App Bundles

你可能感兴趣的:(Android开发人员应该知道的一些技术)