如何把网站程序做授权网址访问,怎么制作自己的链接,医疗器械行业前景,广告网站设计当前参与的项目历史也很久远#xff0c;第一行代码据说是写于2014年的某一天#xff0c;那时Android用的ide还是Eclipse、那时Android还没有很好的架构指导#xff08;mvp、mvvm#xff09;、那时Android最新的版本是5.0、那时Android的Material Design还没流行……背景随着…当前参与的项目历史也很久远第一行代码据说是写于2014年的某一天那时Android用的ide还是Eclipse、那时Android还没有很好的架构指导mvp、mvvm、那时Android最新的版本是5.0、那时Android的Material Design还没流行……背景随着业务和产品发展目前参与的项目apk有2~10个Android开发人员注开发人员数回浮动不是因为离职而是是因为当前项目团队在承接多个项目的并行开发在进行迭代和维护。当前技术部移动团队有30开发人员有多个不同的项目在并行开发但是却没有架构组底层码农管不了组织的事只能埋头敲代码没有架构组的最直接的问题是没有一个组织来统一各个项目的技术选型和技术方案。今天带来自己写的一个组件化框架 XModulableXModulable使用1. 添加依赖配置android {defaultConfig {...javaCompileOptions {annotationProcessorOptions {arguments [ XModule : project.getName() ]}}}
}dependencies {// gradle3.0以上建议使用implementation(或者api) com.xpleemoon.xmodulable:XModulable-api:x.x.xcompile com.xpleemoon.xmodulable:XModulable-api:x.x.xannotationProcessor com.xpleemoon.xmodulable:XModulable-compiler:x.x.x...
}复制代码2. 实现组件XModule(name XX组件名)
public class XXModule implements IModule{}复制代码3. 初始化sdkif (isDebug) {XModulable.openDebug();
}
XModulable.init(this);复制代码4. 获取组件组件获取有两种方式依赖注入和手动查询获取。依赖注入public class TestActivity extends BaseActivity {InjectXModule(name xxx)XXModule mXXModule;Overrideprotected void onCreate(Nullable Bundle savedInstanceState) {super.onCreate(savedInstanceState);XModulable.inject(this);}
}复制代码手动获取XModulable.getInstance().getModule(XX组件名)复制代码5. 添加混淆规则-keep class * implements com.xpleemoon.xmodulable.api.template.XModuleLoader
-keep class * implements com.xpleemoon.xmodulable.api.IModule
-keep class **$$XModulableInjector { *; }复制代码原理介绍组件化/模块化组件基于可重用的目的对功能进行封装一个功能就是一个组件例如网络、IO、图片加载等等这些都是组件模块基于业务独立的目的对一系列有内聚性的业务进行整理将其与其他业务进行切割、拆分从主工程或原所在位置抽离为一个相互独立的部分由于模块是独立、解耦、可重用的特性在实施组件化/模块化的过程中我们需要解决三个主要问题1. 模块通信——因为业务模块是相互隔离的它们完全不知道也无法感知其他业务模块是否存在所以需要一种尽最大可能的隔离、耦合度相对最低、代价相对最小的可行方案来实现通信2. 模块独立运行——在后续迭代维护的过程中各个业务线的人员能够职责更加清晰3. 模块灵活组合运行——能够适应产品需求灵活拆分组合打包上线NOTE组件化/模块化这一节将会以XModulable为例进行解释它是如何进行组件化/模块化阐述和理解一个程序问题最直接的方式是写一个小的demo演示和show关键代码。本文可能有些地方讲的不够详细强烈建议拉下XModulable运行看看。XModulable架构图.pngXModulable工程结构.png解决抛出的三个问题之前先过下[XModulable]的工程结构图和架构图上图中的module对应层级app壳层——依赖业务层可灵活组合业务层模块业务层——im、live和main面向common层实现业务层服务接口向common注册和查询业务模块common层——依赖基础组件层承接业务层暴露业务层服务接口同时为业务层提供模块路由服务basic层——basicRes和basicLibbasicRes——包含通用资源和各UI组件basicLib——包含网路组件、图片加载组件、各种工具等功能组件XModulable只是一个小的demo而已而图中展示的是我对于每一层的完整构想所以当去源码的时候发现有些是缺失的common缺失了AOP代码、basciRes缺失了UI组件basicLib缺失了几乎所有的组件。XModulable-annoation、XModulable-api和XModulable -compiler属于XModulable SDK。XModulable SDK主要用于业务模块的注册sdk在执行初始化的时候会自动进行注册和获取依赖注入和手动获取。这里对XModulable Sdk不做具体技术分析对于依赖注入和注解的编译期处理不了解或者感兴趣的可移步我以前写的编译时Compile time处理撸一个简易版的ButterKnife1. 模块通信模块化的通信UI跳转和数据传递需要抓住几个基本点隔离、解耦、代价小易维护、传递复杂数据Fragment、View、File……。实现独立互不依赖模块的通信很容易能够想到以下几种方式Android传统通信比如aidl、广播、自定义url……无法避免高度耦合、以及随着项目扩张导致难以维护的问题还有另外一关键个问题就是只能进行一些非常简单的数据传递像Fragment、View、File……这些数据或者叫对象也行完全无法通信传递但是这些数据在实际的app中恰恰是组成一个app的关键节点。比如说app的主站中有一个MainActivity它是一个ViewPagerTabLayout的结构其中的每一个页面都是来自于不同模块的Fragment这个时候我们的通信就完全无法满足了。第三方通信比如EventBus、RxBus……容易陷入茫茫的event通知和接收中增加调试和维护的成本能够传递一些复杂的数据通过event事件来携带其它数据对象但是代码耦合性相应的会增加第三方路由库比如ARouter、OkDeepLink、DeepLinkDispatch……基本都能够实现隔离、解耦、代价小易维护。至于数据传递的话默认只支持一些简单数据但是我们可以结合面向接口编程公共层暴露接口业务层面向公共层的接口去实现对应的接口方法UI跳转、数据读写……最后当业务层使用的时候只需要通过路由到接口就可以完成复杂数据的通信。以ARouter为例可以在common层暴露业务模块的服务接口IProviderARouter提供的服务接口只要实现了该接口的自定义服务ARouter都能进行路由操作然后交由对应的业务模块去实现common层对应的服务接口最后在业务模块中使用ARouter进行路由其他业务模块暴露的服务接口来实现。从上面的分析来看路由面向接口编程是实现组件化/模块化的不二之选但是这里又有一个问题——假设哪天抽风想要更换路由库或者可能某种特殊需求不同的业务模块使用了不容的路由库那怎么办呢没关系我们这时候需要对路由库做一层封装使业务模块内的路由都相互隔离也就是一个业务模块内部的路由操作对其他业务模块来说是一个黑箱操作。我的封装思路是这样的加一个XModule可以把它想象成一个容器的概念在common层暴露服务接口的同时暴露XModule它的具体实现也是有对应的业务模块决定的每一业务模块都对应一个XModule用于承载common层暴露的服务接口业务模块之间的通信第一步必须先获取XModule然后再通过这个容器去拿到服务。综上所述最终的组件化/模块化采用的是封装路由面向接口编程。以live业务模块为例从源码的角度看下它们是实现这套思路的。在common层把live业务模块想要暴露给其他业务模块的服务LiveService进行了暴露同时在common层暴露了一个LiveModulelive业务模块的服务容器承载了LiveService,llive业务模块面向common层对应的接口进行实现LiveModuleImpl和LiveServiceImpl。这样的话上层业务就可以通过XModulable SDK获取到LiveModule然后通过LiveModule承载的服务进行调用。// common层live暴露的XModuleLiveModule和服务接口LiveService
public abstract class LiveModule extends BaseModule {public abstract LiveService getLiveService();
}
public interface LiveService extends BaseService {Fragment createLiveEntranceFragment();void startLive();
}
// 业务模块层——live针对common层暴露的实现LiveModuleImpl和LiveServiceImpl
XModule(name ModuleName.LIVE)
public class LiveModuleImpl extends LiveModule {AutowiredLiveService liveService;Overridepublic LiveService getLiveService() {return liveService;}
}
Route(path PathConstants.PATH_SERVICE_LIVE)
public class LiveServiceImpl implements LiveService {Overridepublic void init(Context context) {}Overridepublic Fragment createLiveEntranceFragment() {return new LiveEntranceFragment();}Overridepublic void startLive() {ARouter.getInstance().build(PathConstants.PATH_VIEW_LIVE).navigation();}
}复制代码2. 模块独立运行业务模块在Android Studio中其实就是一个module从gradle的角度来说module不是以application plugin方式运行就是以library plugin方式运行所以为了业务模块也能够独立运行就需要控制gradle能够在application plugin和library plugin两种形式下切换同时还要提供单独运行时的源码。首先在项目的build.gradle中创建业务模块配置isStandAlone表示业务模块是否独立运行ext {applicationId com.xpleemoon.sample.modulable// 通过更改isStandalone的值实现业务模块是否独立运行以及app壳工程对组件的灵活依赖modules [main: [isStandalone : false,applicationId: ${applicationId}.main,],im : [isStandalone : false,applicationId: ${applicationId}.im,],live: [isStandalone : true,applicationId: ${applicationId}.live],]
}复制代码然后设置对应业务模块的build.gradledef currentModule rootProject.modules.live
// isStandalone的值决定了当前业务模块是否独立运行
if (currentModule.isStandalone) {apply plugin: com.android.application
} else {apply plugin: com.android.library
}android {
省略...defaultConfig {if (currentModule.isStandalone) {// 当前组件独立运行需要设置applicationIdapplicationId currentModule.applicationId}省略...def moduleName project.getName()// 业务组件资源前缀避免冲突resourcePrefix ${moduleName}_javaCompileOptions {annotationProcessorOptions {arguments [// ARouter处理器所需参数moduleName : moduleName,// XModulable处理器所需参数XModule: moduleName]}}}
省略...sourceSets {main {// 单独运行所需要配置的源码文件if (currentModule.isStandalone) {manifest.srcFile src/standalone/AndroidManifest.xmljava.srcDirs [src/main/java/, src/standalone/java/]res.srcDirs [src/main/res, src/standalone/res]}}}
}
省略...复制代码最后在业务模块中编写build.gradle中sourceSets声明单独运行所需要的额外源码文件比如Application、SplashActivity和Manifest。完成上面的过程后就可以选择对应的业务模块live运行3. 模块灵活组合运行模块的灵活组合其实也非常简单只需要更改业务模块配置在项目build.gradle的isStandalone值然后在app壳的build.gradle中通过业务模块的isStandalone来决定是否依赖就行关键代码如下dependencies {
省略...def modules rootProject.modulesdef isMainStandalone modules.main.isStandalonedef isIMStandalone modules.im.isStandalonedef isLiveStandalone modules.live.isStandalone// 判断业务组件是否独立运行实现业务组件的灵活依赖if (isMainStandalone isIMStandalone isLiveStandalone) {api project(:common)} else {if (!isMainStandalone) {implementation project(:main)}if (!isIMStandalone) {implementation project(:im)}if (!isLiveStandalone) {implementation project(:live)}}
}复制代码产品技术债OK现在已经把组件化/模块化所面临的问题消灭了那就回过头来整理现有产品的技术债代码耦合、臃肿、混乱模块层级不合理业务模块相互依赖耦合业务模块拆分粒度不够某些模块像个大杂烩业务模块无法单独编译运行业务模块之间无法灵活组合成apk基础组件无法快速提取以供给其他工程使用上述问题直接导致新来同事无法快速理清工程结构以及无法快速进入开发。若团队后续扩张的话势必会按照业务功能模块划分独立的业务小组那么会导致人员组织架构和工程组织架构上打架对症下药(一)控制代码质量团队内部人员需要有代码质量意识否则容易出现有一波人在重构优化而另一波人却在写bug、写烂代码这样就完全失去了重构的意义。所以在进入重构之前务必要明确传达控制代码质量。控制公共分支master、develop和版本分支权限将公共分支的权限集中在少数人手里可避免代码冲突、分支不可控非项目负责人只有develop权限——无法merge远端仓库的master、develop和版本分支制定git flow和code review流程提高团队协作效率项目负责人从master或者develop分支视自身的项目管理而定迁出版本分支开发人员从版本分支迁出个人的开发分支开发人员在个人的开发分支上进行开发工作开发人员在个人分支上开发完成后需要push到远端开发人员在远端我们用的是gitlab创建merge requestSource branch个人分支Target branch版本分支同时指派给项目负责人并相关开发人人员执行code reviewreview完成由负责人进行远端的分支合并(二) 合理的模块层级首先来看下模块层级架构图在原有app的层级上重新划分模块层级这是很吃力的一件事情。因为一个项目经常是有多人并行的开发迭代的当你已经切割或者规划出模块层级了但是其它成员却在反其道而行之必然会导致实施过程中进行代码合并时有茫茫多的冲突需要解决和返工所以我们在这里还需要灌输模块层级思想和规划。划分层级从上到依次为app壳层、业务层、common层、basic层它们的职责如下app壳层——直接依赖业务模块业务层——项目中各个独立的业务功能的聚合由多个业务模块构成业务层common层——承上启下承接上层业务提供业务模块路由服务依赖底层basic统一提供给上层使用basic层——basicRes和basicLibbasicRes——包含通用资源和各UI组件basicLib——包含网路组件、图片加载组件、各种工具等功能组件业务模块提取通用代码、组件、公共资源进行下沉通用代码下沉到common可能涉及到BaseAplication、BaseActivity、广播通知事件也可能是EventBus相关事件具体视自身而定ui组件和基础资源下沉到basicRes网路组件、图片加载组件、各种工具等功能组件下沉到basicLib大杂烩模块拆分独立。以主业务模块为例包含了推送、分享、更新、地图、用户中心、二手房、新房、租房……如此臃肿的模块不可能一次性拆分完成所以必须制定一个计划有节奏的进行推进。我们的规划是按照业务关联性由低到高的原则依次拆分分享、更新下沉到basicLib推送、地图下沉到basicLib用户中心独立成业务模块二手房、新房、租房独立成业务模块业务模块独立运行业务模块之间灵活组合成apk(三) 基础组件内网maven依赖基础组件拆分完成后如果直接进行module依赖的话会导致重复编译和无法灵活供给其它app使用的问题。所以我们需要将基础组件上传内网maven然后通过maven进行依赖。basicRes和basicLib作为基础资源组件和基础功能组件上传到内网maven对basicRes和basicLib根据组件细粒度拆分上传内网maven方便其他工程能够根据实际需求灵活依赖设定节奏和目标制定重构节奏和流程如下将规划合理分配到各个版本中去在保证产品迭代的同时能够稳步推进基于组件化/模块化的重构探索实践。节奏目标执行范围第一期控制代码质量1. 控制公共分支master、develop和版本分支权限2. 制定git flow和code review流程第二期合理的模块层级现有层级分割下沉1. 划分层级2. 业务模块提取通用代码、组件、公共资源进行下沉第三期合理的模块层级大杂烩模块拆分独立1分享、更新下沉到basicLib第四期合理的模块层级大杂烩模块拆分独立2推送、地图下沉到basicLib第五期合理的模块层级大杂烩模块拆分独立3用户中心独立成业务模块第六期合理的模块层级大杂烩模块拆分独立4二手房、新房、租房独立成业务模块第七期合理的模块层级业务模块独立运行和灵活组合业务模块独立运行业务模块之间灵活组合成apk第八期基础组件内网maven依赖1. basicRes和basicLib上传到内网maven2. 对basicRes和basicLib根据组件细粒度拆分上传内网maven源码https://github.com/xpleemoon/XModulable作者xpleemoon。平安好房Android高级工程师相关推荐App组件化与业务拆分那些事热修复原理之热修复框架对比和代码修复Android架构之路-三步实现MVP架构上喜欢可关注
