您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
   
 
     
   
 订阅
  捐助
Atlas插件框架集成总结
 
作者昵称:草貌路飞
94 次浏览     评价:  
2020-11-16
 
编辑推荐:
本文主要介绍的是作者记录集成Atlas的过程和遇到的问题与总结,希望能对您有所帮助。
本文来自于简书,由火龙果软件Alice编辑、推荐。

简单记录当需要手动分配bunlde的packageID时的方法

参考插件源码

原来以为插件的packageID是根据插件的引入顺序决定的,所以为了不出现些奇怪的问题,一再叮嘱不要改变插件引入的顺序,新的插件也只能放在后面(主要是没找到手动分配id的方式,文档里有写但是并不清楚)。但是看源码后比较清晰了。其实并没有严格按手动还是自动分配来区分,因为如果你只给某个插件分配id也是可以的。没有手动分配的插件就会自动给一个,当然不会重复就是了。而且自动分配的时候会根据插件的唯一标识(groupid+artifactId)做一个排序,所以和插件引用的顺序也无关。总的来说自定义id有三种方式,一种是在插件的module里加一个customPackageID.txt文件,里面直接放数字id.第二种是在host项目的gradle中的altas配置部分加packageIdFile,对应值是一个文件路径,内容为groupid:artifactId=number的格式,可配多个插件。第三种是直接在host项目里加一个packageIdFile.properties文件,内容格式和第二种方式一样。三种方式优先级是递增的。最后没有配置的插件会从minPackageId(配置35)开始找一个没被用到的。呃呃呃。。以上都是从代码上看的结论.第一种没试,第三种无效,应该是理解的不对,可能不是通过properties文件方式。第二种方式是可行的。

1.原先没有找到以坐标方式(awb)引用插件正确打开姿势(主要是因为插件中有单独的包依赖问题,本以为插件单独依赖的包会把资源和代码打包到awb中,最后发现是打到了apk里的插件生成文件so中),现改正。 首先如果某个包只是在一个插件中引用到,并不需要在host中预先引用这个包,只是在上传awb到仓库时pom中的依赖需要配置正确。其次,引用插件时可以用compile或者bundleCompile都可以(个人感觉用bundleCompile好点,能清楚知道它就是个插件),并且不能直接用类似bundleCompile('com.test:secondbundle:1.0.0@awb')方式,这样不会依赖到它自己的依赖,要么直接用 bundleCompile('com.test:secondbundle:1.0.0') ,要么手动配递归依赖bundleCompile('com.test:secondbundle:1.0.0@awb'){

transitive =true

}

和demo里配依赖atlas-core时一样

直接写成compile('com.taobao.android:atlas_core:5.0.6-rc29')也是可以的

2.修改了插件通过maven publish上传至仓库时pom中没有依赖信息的问题.

Git:github.com/alibaba/atlas

1.gradle配置

Atlas的gradle配置应该是最重要也是许多人一直困惑的部分,开始我也不是很明白,现在可能也没完全弄懂,但是集成应该是没问题了。官网和git上都有集成文档,这里只是简单列一下,并对一些之前不太理解的配置做解释。

引入Atlas的插件

这里不需要在引入android插件,里面应该包含了当前能适配的版本。还需要注意的是atlas插件一直在更新,毕竟才放出来问题挺多,所以尽量用最新的。

app(host/main bundle)中gradle配置。分几个部分:

1.基本配置

a.这里仅仅是引入application和atlas,并且对一些环境做配置。

b.如果项目里面分出来的module多建议各种配置写到一个单独的地方管理,可以避免后期修改的时候麻烦一堆。

2.依赖配置

awb:atlas自己定义的一种格式,可以直接理解为普通的aar

host的dependency

a.一些atlas基本依赖,仅仅是host需要依赖,插件module不需要

b.引入一些公共的module,根据自己需要,如果是有两个以上插件用到的就可以放到host里面,如果仅是一个插件中用到的模块可以单独放到插件中引用。

c.所引用的插件bundle.建议还是把bundle也打包发布到仓库中通过坐标(group:artifactid:version)的方式引用。这里不要在后面加@awb,否则插件不会依赖到自己pom中的dependencies(看顶部2017/04/13 更新中的1).

3.host打包发布配置

因为做动态更新时是需要历史版本做对比的,所以host打包后需要发布到本地maven中管理(以awb方式引用插件时也需要把插件的awb发布管理)

maven发布配置

a.发布时的group和version配置,artifactid写死的AP-debug,可以改

b.引入maven插件,并配置发布时的仓库位置和要发布的东西(*.ap文件,用来后面打包patch时做基准包)。仓库位置可以是公司自己的maven库,也可以是本地库。

c.其中apVersion后面解释打包patch配置时用的

4.atlas插件配置

a. autoStartBundles我理解的是在app启动时就加载的插件bunlde,如果你引用了几个插件并没有配为自启动,那根据文档只能通过触发插件中Component的加载而启动插件,比如start一个bundle中的activity或者service。或者是通过手动调用代码加载一个插件(http://atlas.taobao.org/docs/guide-for-use/guide_for_bundle.html).

b.outOfApkBunldes是配置一些不需要打包到apk的插件,就像demo中的remoteBundle。下图

打包host后的输出结构

这种插件中在打包生成apk后不会直接保存到apk中,而是放入单独的文件夹,然后根据自己的需求push或者down到手机上的指定目录。 可以参考官方demo中的DemoApplication,下图

通过设置component查找失败的回调来根据自己的需求获取远程插件。另:getBundleForComponet中componet应该为component - -.

c.patch的配置。之前有见过apVersion,这个默认是空的,代表的是打包patch时的基准线apk.在打包patch时根据命令参数传入.只有apVersion不为空时createTPatch=true才能生效。

这几个地方联系起来才能看懂。还有就是apk的版本也是用这里的version,默认1.0.0可修改。

插件bundle的gradle配置

插件的配置比较简单,一般的android配置跳过了

1.atlas插件配置

根据官方文档配就可以,其中version是发布到仓库中时用的。还有就是打patch时也会用到,demo中没有这个version所以打patch时就是unspecified。baseApFile配成apk打包输出的位置就行,猜测也是打patch时用的。

打patch后的update.json

2.依赖配置

这里有三种依赖方式,一般的compile,如果要引用的包只是这个插件使用可以用这种方式(多个插件用到的包需要放到host里面引用).另一种providedCompile,如果不使用altas的插件的话也只可以使用这种引入方式,但是只支持jar包,aar和project不可以(atlas进行了扩展应该)。这种方式引用的包不会打到插件的包中。最后一种bundleCompile也是atlas插件里面的,表示这个插件引用了其它的插件。

3.插件发布配置

如果想要以awb方式引用插件时需要把插件发布到仓库,这里以maven为例,用maven插件中的publish将awb发布到本地库。这种方式暂时没有找到授权相关的配置(求解求指教),所以只能发布到本地或者是不需要授权的maven服务。尝试过用另一种uploadArchive的方式但是不成功(求解求指教)

..2017/04/13更新

上面的配置打包上传后pom中没有依赖信息,需要在publications里手动添加

判断某个依赖是否在providedCompile的依赖集中

如图,需要通过pom.withXml配置依赖,并且configurations.compile的依赖集里会包含所有compile或者providedCompile的依赖,需要过滤掉,当前只找到从providedCompile依赖集中遍历的方式,如有更好方式求普及。 ?通过上面加的配置就可以在插件的仓库pom中添加dependencies结点,并且只有compile引用方式依赖的包。

问题

1.集成项目时原有工程中有productFlavors配置,现在当做插件引用后报错。暂时改为其它方式实现。

2.当集成多个插件(其实是多个app工程,想尝试放到一个里面)后,sync gradle时总是报依赖重复的问题,通过dependencies查看依赖后发现两个插件的一级依赖都有multidex的引用,但是两个插件的gradle配置没有明显的依赖multidex,而且即使有间接依赖multidex的包也是provided的方式依赖。最后看另外一个atlas的demo中有过滤掉support相关的配置,加入之后没有问题。

3.因为插件默认是放到armeabi里面的,所以如果引用的其它三方包中含有其它abi的只能过滤掉了或者选择其它so的输出目录(暂时没看到相关配置).

4.动态更新时遇到部分由于window系统导致的问题(ali开发用的mac), 新版基本已解决,更新很快很给力。

5.【已解决,看2014/04/13更新】以awb方式引用插件时,awb里面如果引用了其它host里面没引用的包,需要把这些包都在host里面引用,因为打包awb后里面并没有所引用包的代码或者资源,所以编译时引用awb时会出现找不到资源的问题。(这点不知道是本来就不支持还是方法没弄对)

6.因为项目中没有和demo一样的动态更新入口,所以用了atlas update中的广播(AwoPatchReceiver)做动态更新测试,打包patch步骤都一样,只是上传的目录有点不同。具体看命令

update.json?push到手机上时需要改为patch-*@*.json

还有AwoPatchReceiver缺少一行代码,改了重新发布后可行

经验

1.需要注意的是虽然host里面已经有一个application但是在插件中也是可以指定自己义的application的,只在第一次加载插件时初始化调用。所以如果插件中有需要初始化的操作可以和以前一样放到application,但是要小心在代码中getApplication得到的并不是插件中定义的。

2.有时插件可能需要访问host里面的资源或者代码(如appname,launcher),可以单独建一个library存放公共资源和代码,并且一些公共的三方库引用也可以放到里面,这样所有插件都只需要以provided的方式引这个library就可以,不用在每个插件里面都引用相同的库。

3.为了开发插件时方便,插件在开发过程中应该是可以直接运行的application而不是library,而且打包插件和开发时gralde配置是有区别的。这时可以分开创建两个单独的gradle(build_app.gradle,build_lib_gradle),在build.gradle中根据开发还是打包选择引用对应的文件。

4.有上面一点基础上,我们还可以根据是打包app还是打包插件,在gradle中引用不同的代码目录,或者是不同的manifest文件。这样就可以把平时当作app的项目中很多代码和资源区分开来,manifest也可以简化许多,这样还可以配不同的application。(老项目还是eclipse结构。。studio结构也是可以的)

5.开始时是使用项目依赖的方式引用插件,速度慢而且经常出现编译时插件中R类和资源不正常导致n多个dex文件的65535问题。改为awb后好很多。

6.还要注意插件间的资源是独立的,所以可以存在相同的资源名。使用时也要稍加注意。

7.开发时若出现莫名奇妙的问题(可能执行过动态更新),在clean之后也无用时,把手机上已安装的app卸载试试。

8.看dingding群里问的很多的问题build中某个文件被占用,经常出现(window),所以host中每次执行task前把java杀一下。其实也就2秒的时间而已,不用太吹毛求疵

9.使用awb的方式引用插件时格式为bundleCompile或者compile都可以,bundleCompile更直观。

10.许多人对gradle命令不熟悉(我也不是很熟,偶尔发现的),提几个经常遇到人问的点 :

?a.terminal中默认在项目根目录。所以如果在根目录直接执行task(如clean)时会执行所有的module的clean任务。有时这样做并不是必需的而且部分任务并不是所有module都支持的,这时就会出错。

b.如果只想对某个module执行task

方法一:可以cd到这个module的目录在执行gradlew操作。根据module的目录层级加..\ ? 。mac系统换成/

..\gradlew clean

..\..\gradlew clean

方法二: 一直在根目录,不用切换目录,不用管目录的层级多深。自己用这种方式

gradlew ?:moduleName:taskname(如clean)

c.多个task一条命令

gradlew? :moduleB:clean ?:moduleA:clean? :moduleA:asR(可以缩写,代表assembleRelease) ? :moduleA:publish?

11.使用坐标方式引用插件时,每个插件都要配置maven publish上传的配置,如果在每个插件的gradle中都配置一次的话会导致很多重复并且修改时也不方便。这时我们可以新建一个单独的publish.gradle文件存放上传相关配置,至于每个插件的group,artifactId和version相关信息在插件的module中新增一个gradle.properties里单独配置就ok.这样在插件的gradle中apply一下就行,修改也只用改一份.

插件gradle中引用

publish.gradle中存publish相关配置,并且groupid,version等用配置而不是定死

gradle.properties中配置

最后

总的来说Atlas的集成算比较简单的,修改的地方也比较少,大多是gradle的配置,插件中没有引入任何atlas相关的包,可以说完全无感知。简单了解实现原理更加觉得nubility.不管是从class的加载还是资源的加载方式都感觉很聪明,这两块一直是插件化的大问题所在。而且所说不久的将来就会放出动态添加activity和service的功能,这是很多插件框架做不到的。

 
   
94 次浏览     评价: 订阅 捐助
相关文章

深度解析:清理烂代码
如何编写出拥抱变化的代码
重构-使代码更简洁优美
团队项目开发"编码规范"系列文章
相关文档

重构-改善既有代码的设计
软件重构v2
代码整洁之道
高质量编程规范
相关课程

基于HTML5客户端、Web端的应用开发
HTML 5+CSS 开发
嵌入式C高质量编程
C++高级编程
最新课程计划
 
最新文章
Flutter-你还在滥用StatefulWidget吗
移动APP安全测试要点
深入浅出 Kotlin 协程
iOS 组件化 —— 路由设计思路分析
移动端跨平台开发的深度解析
最新课程
Android高级移动应用程序开发
Android应用开发
Android系统开发
Android应用高级开发
移动互联网应用开发(iOS,Android,HTML5)
更多...   
成功案例
北京 iOS开发技术深入研究
某企业 Android高级移动应用程序开发
中体彩 Android产品级测试
移动通信 移动互联网应用开发原理
某电力行 android开发平台最佳
更多...