插件项目app化说明

Posted 2020-11-02 bwlcool

主要工作：

• 添加app productFlavor，同一套代码可以编译出插件和app
• 用Activity承载LauncherFragment
• 解决包依赖问题
• 权限申请（账号权限、cde权限）
• 处理包名变更引起的问题
• 添加app升级功能
• 相关UI、体验设计

使用Activity承载入口Fragment

• 添加入口Activity
• 实现之前宿主Activity的接口，并提供关键实现
• 使用content view作为fragment的container，减少不必要的层级

解决包依赖问题

插件引用了launcher的一些类和功能，插件不用把那些类编译进dex，只需要编译通过，所以有很多jar都是provided的方式。

作为独立app，需要把那些jar编译到dex里边。

遇到了两个问题：

1. jar类冲突
   1. 改为compile方式之后，遇到了jar类冲突的问题。之前的jar设置不合理，多个jar会含有相同的一些类，如果都compile进去，就冲突了。
   2. 解决办法：解压jar，把多余的类删掉，重新打包jar(Java Jar包压缩、解压使用指南 https://www.cnblogs.com/javastack/p/8761248.html)。
2. 方法数超过64K（已经有混淆和去资源冗余了）
   1. 之前很多jar并没有编译到dex里边，改为compile方式之后，方法数就超标了
   2. 处理方法：
      1. 清理代码（删除老旧不用的功能代码和相关jar）
      2. 减去对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话之后，需要自己考虑升级功能。升级方式有两种：

1. 使用应用商店的静默升级功能
2. 自己添加升级逻辑&UI。使用通过升级sdk，能够快速完成升级逻辑。

相关UI、体验设计

1. Logo
2. 启动图
3. 大背景图&loading背景图
4. 多桌面插件情况下，左键、上键、右键都有对应的功能，例如切桌面、呼出通知栏。app的情况下，就能重新定义这些按键了。