主要工作:
- 添加app productFlavor,同一套代码可以编译出插件和app
- 用Activity承载LauncherFragment
- 解决包依赖问题
- 权限申请(账号权限、cde权限)
- 处理包名变更引起的问题
- 添加app升级功能
- 相关UI、体验设计
使用Activity承载入口Fragment
- 添加入口Activity
- 把LauncherFragment的view设置为Activity的contentView(比add fragment的方式view层级低&避免Fragment的回收重建问题)
- 手动调用LauncherFragment的生命周期函数
- 实现之前宿主Activity的接口,并提供关键实现
解决包依赖问题
插件引用了launcher的一些类和功能,插件不用把那些类编译进dex,只需要编译通过,所以有很多jar都是provided的方式。
作为独立app,需要把那些jar编译到dex里边。
遇到了两个问题:
- jar类冲突
- 改为compile方式之后,遇到了jar类冲突的问题。之前的jar设置不合理,多个jar会含有相同的一些类,如果都compile进去,就冲突了。
- 解决办法:解压jar,把多余的类删掉,重新打包jar(Java Jar包压缩、解压使用指南 https://www.cnblogs.com/javastack/p/8761248.html)。
- 方法数超过64K(已经有混淆和去资源冗余了)
- 之前很多jar并没有编译到dex里边,改为compile方式之后,方法数就超标了
- 处理方法:
- 清理代码(删除老旧不用的功能代码和相关jar)
- 减去对fresco的依赖(插件化的情况下,freso是不编译进dex的。app话fresco会引入大量的代码和so,我们没有大部分功能使用的ImageLoader,可以去掉fresco。fresco还会引入so,作为系统app,必须把so放到system/lib,现在已经有系统应用把so放到system/lib了,如果我们也用fresco,那么必须考虑so的版本问题,代价高,容易出错)。
权限申请(账号权限、cde权限)
之前宿主有申请账号的权限,作为app运行之后,必须自己申请账号等权限,申请加入白名单等
处理包名变更引起的问题
宿主统一修改了插件的包名,在插件里边,所有的标准api获取的包名都是宿主的。改为app之后,这些ap获取的包名就是插件自己的包名了。
包名变动涉及:定向广播、广告sdk对包名的判断、其他子功能对包名的判断
app升级功能
插件的升级是宿主统一管理的,app话之后,需要自己考虑升级功能。升级方式有两种:
- 使用应用商店的静默升级功能
- 自己添加升级逻辑&UI。使用通过升级sdk,能够快速完成升级逻辑。
相关UI、体验设计
- Logo
- 启动图
- 大背景图&loading背景图
- 多桌面插件情况下,左键、上键、右键都有对应的功能,例如切桌面、呼出通知栏。app的情况下,就能重新定义这些按键了。