Shadow的缺点介绍

看到有网友看到Shadow的开源公告和Github主页的README以后，以为都是报喜不报忧的介绍。咱们也多少赞成这个见解。若是开源一个项目，并不期望其余人能真正使用，也不期待收获网友们回馈的代码贡献，那么报喜不报忧问题不大。可是Shadow开源的目的不是单纯的吹嘘本身的技术多厉害，给你们随便看看代码片断。咱们是真的但愿你们能用起来，将来咱们的业务和你们的业务用的Shadow是同样的，没有任何区别。这样你们能在插件技术上直接得到通过咱们业务大量实践的高质量SDK，咱们也有机会直接得到你们贡献的代码，减轻咱们维护Shadow的负担。所以，咱们好好谈谈Shadow的缺点。

功能实现不完整

Shadow采用了用一个壳子代理转调插件组件的技术手段实现组件生命周期。好比Activity的各类生命周期都须要壳子代理Activity收到系统调用后转调插件的Activity。同时，反过来插件Activity想调用的父类方法，好比getIntent()方法，也须要经过中间件层ShadowActivity转调回壳子Activity。所以理论上，ShadowActivity就应该完整复制系统Activity类的全部方法，大约有200个左右吧。

不像其余插件框架没有插件框架自己动态化的设计，Shadow的插件框架实现代码也是插件包的一部分，是能够动态更新的。好比ShadowActivity这个类处于runtime模块，也属于插件框架自己实现，咱们的业务假设当前没有使用getIntent()方法，则同这个业务当前版本一块儿发布的Shadow实现就不用实现getIntent()方法。当下一个版本的业务须要用这个方法时，插件框架实现也能够补充这个方法的实现，随业务插件的新版本一同发布。

基于上述缘由，Shadow的功能实现很不完整，只知足了咱们自身业务的需求。不过请放心的是，咱们的业务也比较复杂了，大部分经常使用的功能咱们已经实现了，相似的没有实现的方法，大部分也只须要简单转调便可，很是容易实现。咱们之因此没有真的去实现，主要缘由是咱们的业务不须要这些方法，因此咱们实现了也不能保证质量。

目前Shadow开源的代码中全部的功能应该只有ContentProvider是咱们业务中没有用到的。确切的说，只使用了宿主的FileProvider获取照相文件，插件自身没有提供任何ContentProvider。ContentProvider的实现确实是为了让Shadow的功能对齐其余插件框架而实现的。

Fragment代码调试变麻烦了

Fragment的具体实现方案和缘由在这里先不讲，老是咱们因为坚持不使用任何Hack手段实现，包括在编译期也坚持不Hack官方的构建流程，致使咱们最后只能选择将插件中本来的Fragment类名更名为在本来名字后面加一个下划线。好比业务插件里有一个com.xx.GiftFragment类，实际运行时这个类的名字就变成了com.xx.GiftFragment_。这就致使在com.xx.GiftFragment的源码上打断点是断不下来的。必须在程序运行起来以后，用IDE的重命名功能把它更名为com.xx.GiftFragment_，使得源码和运行时类名字一致才能断点。

这个设计能不能改进，咱们是反复考虑了没有更好的办法的。可是若是Hack构建过程，确实能够避免这个问题。

全动态设计使版本控制更复杂了

这其实是优势带来的负面问题，在Shadow的设计中有3个部分：host,manager,plugin，这3个部分是分别发布版本的。而其余没有全动态设计的插件框架只有host和plugin两部分。这些部分之间的版本关系都是多对多的关系，因此版本管理变得更复杂了。这部分版本的管理，在咱们的实现中是一个依赖于腾讯内部后台框架的后台服务，所以没能在此次开源中带出来。Shadow开源的代码目前是没有包括插件下载和版本检查实现的。manager只实现了下载插件以后的安装逻辑，也包括升级功能。

自动化测试用例比较少

咱们的业务开发模式实际上是不要求对SDK进行测试的，咱们有强大的测试团队会对业务功能进行严格测试。这能够保证Shadow就算有Bug也不会出如今咱们现有业务的场景中。可是咱们也知道其实插件框架中的实现不少都是很是相关的，对插件框架中一处小小的改动，确实可能会影响不少看似不相关的功能。因此自动化测试对于插件框架来讲实际上是很重要的，这咱们有意识。因此，即使是咱们见过的其余插件框架都没有配套的自动化测试，咱们仍是坚持作了自动化测试。惋惜的是因为人力有限，用例还很是少。咱们尽可能但愿将来作出的改动都配套实现自动化测试。

没有多插件的Sample

咱们的业务中对Shadow的应用实际上复杂程度远超Sample。咱们的一个业务其实是由多个插件包构成的，这些插件包之间存在依赖关系，不光有类依赖，还有资源依赖。经过一个复杂的manager实现，让业务逻辑能够通知manager在须要的时候才下载一些功能插件，作到插件的懒加载。

这些多插件相关的功能已经在开源的Shadow代码中支持了，可是咱们一直没有精力再写一个复杂的Sample演示这些功能。

插件管理的Manager实如今卸载插件方面欠缺

实际上代码写了卸载插件的功能。可是咱们的业务对卸载插件需求不强烈，因此咱们更重视更新插件，而对旧插件处理很少。还有一个缘由是旧插件有可能在运行中，也不能贸然删除。对于卸载的实现，咱们是有讨论过和设计的，可是一直没能实现和验证。

本身很难发现本身的缺点，但愿你们指正

咱们真的是颇有诚意，但愿你们能知根知底的了解Shadow的缺点。但人本身真的很难发现本身的全部缺点。因此若是你们认为Shadow还有什么缺点，欢迎你们提Issue，咱们共同改进。