项目及文章公开发布网址:https://github.com/lucifinilsu/SmartAndroidDeveloper
项目简介:****
SmartAndroidDeveloper(下简称SAD)是一个由我个人在过往项目的开发中不断总结经验教训,以及对新技术的研究中开发的全新的Android应用的敏捷开发框架,目的是为应用层程序员提供一个高度集成化且可定制性较强的开发环境,尽可能的令程序员专注于业务逻辑而非技术问题。其遵循以下原则:
u不干涉应用层,以接口或抽象类的形式向上扩展功能。
u基础组件提供simple样例,可供应用层程序员作为编写扩展的参考或者直接继承。
u架构形式采用事件隔离,彻底绝灭不必要的耦合。
u工具类尽可能以静态方法呈现。
u不滥用设计模式。
u谨慎使用注解。
u用RClassManager类下的find方法代替android的find方法
项目解析:****
本项目目前主要使用Eclipse开发,AndroidStudio(AS)为辅助,后期会转为AS项目。本框架分为三个部分:基本框架结构,基础组件部分,工具部分,异步逻辑处理部分,自定义UI部分,功能部分。篇幅原因,本篇文章着重解释几个方面,其他可见demo中展现。
基本框架结构:****
这里只重点讲解两个地方,其他的在demo里详细说明
1,RC-RCH机制****
首先我们要明晰一个原则:各个组件和控件应当各司其职,尽量减少承担不必要的工作,不要过分的去承担和寻求所需资源的来历。例如:Activity和Fragment,我们最主要的是控制它在生命周期内根据业务需求对任务的发起、UI的更新,而不考虑任务的具体过程如何、UI控件从何处取得。
所以这里我们声明一个资源控制层(抽象类):ABaseRESController(下简称RC)和一个资源应用层(接口):IRESControllerHost(下简称RCH),他们的关系和功能是这样的:
例如:在SAD的Activity里,由Activity实现RCH接口,作为宿主,RCH的主要功能是将Activity实例提供给RC,并持有RC的继承类为成员变量,RC在Activity的OnCreate周期实例化,作为寄生者,并调用其init方法。RC的主要职责是初始化Activity所需要的UI资源,并将其暴露给RCH,我们在Activity里可自由的取用RC提供的UI资源,而不关心其是xml静态的还是java动态生成的或者是做过什么处理。
此外RC-RCH机制还可以帮助我们解决例如Activity和Fragment、Service等组件(这里我们将Fragment也视为组件的一种)的资源共享问题。在共享控制的时候,RC变得十分强悍,RC不关心宿主的层级(例如fragment多层嵌套),它只有一个主宿主,若干个副宿主,但并不关心副宿主之间的层级,例如:副宿主1是fragment,副宿主2是1的下级fragment,那么在控制器里1和2是并列的,主宿主可以通过RC直接操控副宿主2的资源,副宿主1也可直接通过控制器操控2的所有资源。RC-RHC的应用场景很多,View级别也可以使用,这里具体的应用参照Demo。
2,事件隔离机制****
MVP架构众所周知,也是很多项目里常用的架构,但MVP依然有一定的局限性,例如:随着项目的变大业务需求变复杂,Presenter层会越来越臃肿,并且要编写非常多的View接口,究其根本,是由于MVP所使用的是接口隔离机制导致。其实这里我们不妨做这样一个设想:当一项业务任务在A处发布并执行以后,并在B处更新其结果到UI上,而又要避免AB相互依赖,这里我们就要用到事件隔离机制了:在SAD里我们首先定义好业务逻辑引擎类(BT)(例如调用接口获取数据、本地读写数据库获取相应结果),BT是纯数据操作,操作结束后将结果通过Eventbus进行发布,接收方可以在不依赖发布方的情况下直接进行UI更新,比如一个典型的例子:我们在service里用BT异步(耗时)获取一个数据,并用Eventbus发布出去,Activity可以在不依赖service和BT情况下直接更新UI。也就是说,发布方不关心发布的是什么,接收方不关心是谁发布的,BT不关心以上两者,三方隔离,避免了很多臃肿代码的产生,简洁明快,并且有利于团队分工开发。
基础组件部分:
由于在实际的工作项目中会遇到各种各样的需求,对于Android四大组件的生命周期的把控要求会越来越复杂,所以SAD注重对生命周期的二次解构和细分。
Activity:在基本框架结构部分我们已经分析了RCH和RC原理,这里就不再赘述,这里我们重点说明对OnCreate周期的细分,SAD将OnCreate过程细化为了以下过程:
/**
* 在执行oncreate之前执行一些操作,比如setTheme等。
* @param savedInstanceState
*/
publicboolean OnPreOnCreate(Bundle savedInstanceState);
/**
* 在执行setContentView之前执行
* @param savedInstanceState
*/
publicboolean OnPreSetContentLayout(Bundle savedInstanceState);
/**
* 获取活动对象的布局
* @return
*/
publicint OnGetContentLayoutRes();
/**
* setContentView之后执行
*/
publicboolean OnSetContentLayoutCompleted();
/**
* 开始执行activity逻辑
*/
publicboolean OnExecuteActivityFunction();
。应用层开发者可按需扩展这些方法,十分便捷。
另外,Google早在I/O 2014就对UI设计规范Material Design做了明确的定义,但对多版本的兼容性不佳,例如Android4.4和5.0在statusbar和Toolbar的配置编写上存在差异,SAD针对其做了兼容性的配置,应用层开发者仅仅需要在RC继承类里扩展其中几个方法就能快速完成MD编写,节约大量时间,具体可见Demo。
Fragment:在实际开发中,我们往往会遇到Fragment反复重载的场景,其OnCreateView方法需要根据需求进行调整,有时会比较繁琐,SAD提供了适配各种场景的载入模式例如懒加载模式、WebView模式等。通过配合RC-RCH机制十分便捷。
Service、BroadcastReceiver等目前没有扩展的必要。只是IntentService有几个网络请求的Simpe可以直接调用。
功能和异步逻辑部分(简述)****
异步逻辑:SAD对AsyncTask进行了重写,目的是令其支持根据当前设备CPU的状态进行任务并发,此外还定义了多种执行器,支持串行、并行等。能够适配多种任务类型。
网络请求:SAD对OkHttp进行了二次封装,支持GET,POST,HEAD,PUT,PATCH,DELETE等Method,并作为数据访问引擎用AsyncTask包装了应用层可直接调用的工具类,并且支持文件的上传下载(支持断点续传),非常便捷。
缓存框架:SAD建立了并管理一个稳固并强有力的三级缓存框架(2级内存,1级磁盘)。在Cahce的设计中,一般会考虑两种对象管理方法,一是按对象大小,比如开一个10M字节的cahce空间。另外一个是按对象的数量,比如1000个对象的cache空间。在SAD里,我们优先考虑对象大小然后考虑对象数量:首先存入一级内存缓存时, 严格审查计算一级缓存是否在存入新缓存对象后大小符合规定,如果超出则删掉旧缓存, 一直删到大小符合规定为止,然后再根据一级缓存的容器特性对数量进行控制,超出则向二级缓存溢出。当然,SAD也提供了较为热门的DiskLruCache管理方法。
权限管理:自Android6.0发布以来,Google收紧了应用权限申请,在开发中,涉及关键权限的操作都要求手动编写代码申请,SAD提供了专用的权限管理类,一行代码搞定权限申请。
其他:SAD提供了丰富的应用层开发所需要的接口,例如在Application监控Activity的周期接口,网络状态接口,设备状态接口,日志接口,AIDL相关接口,防杀保活接口,H5页面配置接口等等。
工具类:SAD有丰富的工具类可以直接使用:文件、图片、视频、设备、应用、算法、加解密等等,目前还在不断添加中。
SAD目前对大型Android应用项目具有良好的兼容性、易用性和稳定性。更多的新功能和优化仍在进行中。