大家好，我是 ComboLite 的作者。
首先，感谢大家关注 ComboLite 这个项目。作为一个利用业余时间开发的开源项目，ComboLite 能够发布并得到一些开发者的关注，对我来说是莫大的鼓励。项目目前还处于早期阶段，很多地方需要完善，你们的每一个 Star、Issue 和建议都至关重要。
在持续修复 Bug 和优化现有功能的同时，我一直在思考 ComboLite 下一步该走向何方。为了让项目能持续发展，也为了让大家对 ComboLite 的未来有更清晰的预期，我在这里整理了一份接下来的开发计划。
这份计划按优先级排列，希望能解决一些核心痛点，并为框架构建更健壮的基础。
近期开发计划
1. 优化开发体验：无缝源码调试
- 当前痛点 ：目前以 Library 模块作为插件进行开发时，调试流程非常繁琐。开发者需要经历
打包插件apk->部署到宿主->运行宿主并重新安装插件的漫长过程，这极大地拖慢了开发迭代速度。 - 计划方案 ：
- 实现
debug模式下的源码依赖调试。通过debugImplementation将插件模块直接作为源码依赖集成到宿主中。 - 改造
PluginManager，使其能智能识别debug模式。在此模式下，框架将跳过文件安装、资源加载等重量级步骤，转而直接从宿主 App 的主 ClassLoader 中"发现"并加载插件的入口类和服务。 - 最终目标是让调试插件的体验与开发普通 App 模块完全一致，实现真正的"无感知"开发。
- 实现
- 备注：这个功能是我目前的最高优先级。它的实现可能比较复杂，涉及到对框架核心加载逻辑的改造，预计需要投入较多的时间和精力，希望大家能耐心等待。
2. 增强框架安全性：插件权限系统
- 当前问题 ：框架的去中心化设计赋予了所有插件完全相同的能力，任何插件都可以调用
PluginManager的全部 API，这在开放生态中存在潜在的安全风险。 - 计划方案 ：
- 引入基于签名的权限校验机制。对
PluginManager的敏感 API（如installPlugin,uninstallPlugin等）进行分级。 - 只有与宿主 App 具有相同签名的"受信任"插件，才能调用所有 API。
- 来自第三方的、签名不一致的插件，其权限将受到限制，只能在框架划定的安全范围内运行。
- 引入基于签名的权限校验机制。对
3. 拥抱开放生态：灵活的插件校验策略
- 当前局限：目前强制要求插件签名必须与宿主一致，这虽然保证了安全性，但也阻碍了社区插件的分享与流通。
- 计划方案 ：
- 在保证安全的前提下，提供更多样化的校验策略，供宿主 App 自由选择。
- 设想的几种策略 ：
- 严格模式 (Strict)：维持现状，仅允许同签名插件。
- 白名单模式 (Whitelist)：宿主可配置一组可信的公钥指纹，允许加载这些白名单内的第三方插件。
- 用户授权模式 (User-Grant)：加载未知签名插件时，向用户发起授权请求。
- 开发者模式 (Insecure)：完全禁用签名校验，仅用于开发和调试。
- 最终目的 ：我希望未来开发者们可以方便地分享自己为
ComboLite制作的插件，无论是功能模块还是主题皮肤，任何人都可以轻松下载和集成，共同建设一个活跃的社区生态。
寻求社区帮助与贡献
ComboLite 目前主要由我一个人在业-余时间维护和开发，经常需要熬夜到深夜才能挤出一些时间推进。坦白说，个人的精力和视角都是有限的。上面提到的"无缝调试"就是一个不小的挑战，如果能有其他开发者一同参与，整个进度无疑会大大加快。
因此，我在这里真诚地邀请大家：
- 分享你的想法 ：如果你对以上计划有任何建议，或者发现了其他亟待解决的痛点，欢迎随时通过 GitHub Issues 或 Discussions 提出。
- 反馈使用体验 ：如果你在项目中尝试使用了
ComboLite，请告诉我们你的感受。无论是 Bug 反馈，还是使用上的不便之处，都是我们改进的第一手资料。 - 参与代码贡献 ：如果你对某个功能有实现思路，或者愿意修复某个 Bug，非常欢迎你提交 Pull Request。无论是完善文档、修复一个小问题，还是实现一个新功能你的每一次贡献都将让
ComboLite变得更好。