JessYan: 意见收集 😘，请进 QQ 群: 455850365

[JessYanCoding]

• 关于常见的 issues 在 这里
• 有什么问题可以直接进 咨询

如果您对 MVPArms 和 JessYan 有什么好的建议, 都可以在下面留言以及讨论

[GitHubAFeng]

谢谢！整合了好多新兴技术，加法做了好多，什么时候做做减法呢？

JessYan 回复: Arms v2.5.0 版本开始, 已经在拆分 Arms 中非必须的库, 并且通过扩展库的方式，保证对旧版本的完美兼容，现在已经拆分了 support-design、AndroidEventBus、Glide、AndroidAutoLayout 等库，这样的好处是使框架使用者可以自由的选择某种类型的三方库，还可以减轻 Arms 的体积，后面还将继续对 Arms 进行拆分，让 Arms 的扩展性更强，体积更轻，新增的功能或库，也将采用 接口 + 扩展库 的方式进行集成

[xiaobailong24]

@JessYanCoding 牛逼的不要不要的。看了那么多RxJava、MVP、Retrofit等等的文章和例子，如今终于可以整合了！感谢无私分享，正在学习，准备使用本框架重构旧项目。

[JessYanCoding]

@xiaobailong24 好的,可以加qq群,有问题一起交流

[xiaobailong24]

@JessYanCoding 好的，周末正好研究一下！

[ReepicheepRed]

@JessYanCoding 建议 BaseApplication extends MultiDexApplication

[JessYanCoding]

@ReepicheepRed BaseApplication 通过 AppDelegate 来做一些框架需要的操作,就是为了让开发者不是必须要继承 BaseApplication, AppDelegate 可以让开发者很方便的自定义一些可以满足自己需求的 Application,并且也不会影响到框架的运行,你的想法是站在 App 开发的角度, 需要框架很方便的实现自己的需求, 我站在框架设计的角度,要满足每个开发者每个 App 的需求是不可能做到的,所以我要做的是提供扩展的方式,让开发者能根据自己的需求自己去扩展,而不是一味的满足每个人的需求,这个是恶性循环,你需要 MultiDexApplication ,其他人可能并不需要,人家为什么要为了方便你的需求,而去被迫继承一个自己并不需要的 Application ,这个对于别人来说是不划算的事

[JessYanCoding]

@ReepicheepRed 为了让开发者更方便的使用 MultiDex ,以及对一些框架的初始化,现提供 attachBaseContext 扩展方式

[bopo]

厉害，很好，终于找到组织了

[JanusKun]

群号是啥？加一下 一起交流

[JessYanCoding]

@JanusKun 老哥,第一楼就有群号

[fightcoder]

真的很棒！思想很厉害，向作者学习，多谢开源

[2286033294]

首先非常感谢大神的无私奉献！我是一个小白，还是有些地方不懂，如果大神有时间能出个视频讲解一下就好了！

[zhou9527]

有木有相对简单的mvp模式demo，这个看着有些蒙蔽，熟悉点的只有rxjava,retrofit..。。看引用了很多的框架，，要一个一个学习再学习你在这个哇

[JessYanCoding]

@zhou9527 不管是 MVP ,还是 RxJava ,以及 Retrofit 和 Dagger , Github 简单的 Demo 真的太多,一搜一大堆,你就自己找吧,就是因为 Github 上大部分的此类型 App 或 Demo ,写的是在太简单了,所以我才写的这个框架属于进阶版,这个框架自动屏蔽没入门的朋友,因为你没入门根本看不懂,更说明你可成长的空间非常大,这时候你应该感到焦虑而更努力的自己主动去学,这些技术已经不算最火的技术了,我 16年 初就把这个框架写出来了,大部分人都会,大部分人都会的东西,而你不会,那无论面试还是工作肯定会有些许劣势,但现在这个时候才去学也不晚,你也有好处,那就是现在这方面的资料真的太多了,坑被踩完了,学习起来非常快,所以别问我了,直接花时间去硬啃

[hxlailfh1314]

AndroidAutoLayout 不维护了，之后会选择移除吗

[JessYanCoding]

@hxlailfh1314 现在框架不是强制使用 AndroidAutoLayout ,不声明 Androidmanifest 中的 meta,就不会使用, AndroidAutoLayout 虽然不维护了,但是并不代表他没有价值,依然有很多项目在使用它,带来了很多便利,作为使用两年的老用户,也并没遇到什么大的 Bug ,在某些使用场景使用起来非常愉快,所以暂时不会移除,以后看情况再做打算,如果你不喜欢用,可以不声明 meta

[hxlailfh1314]

框架上少引用了“com.squareup.retrofit2:converter-scalars:2.3.0”
所以不能支持返回参数是 String 类型。 不知道你这边 是否考虑加上这个。

[JessYanCoding]

@hxlailfh1314 框架已经提供了 Retrofit 和 Okhttp 扩展参数的方式, 你自己引用, 自己使用就好了, 框架只需要让开发者能够按需扩展自己的需求, 而不需要自己去满足所有人的需求, 这就是框架作者和 App 开发者思想上最大的差别

[yeyueduxing]

想问个问题哦，发现MVPArms更新迭代蛮快的，但是好像没有向下兼容，当依赖的新版本的时候，会造成很多兼容性问题。有的时候想更新版本，又怕更新出问题

[JessYanCoding]

@yeyueduxing 集成化框架和其他功能性框架不一样, 功能性框架只是调用某些 API, 所以他可以很好的屏蔽一些风险, 但是集成化框架要复杂的多, 涉及到的方面远不是简单的调用几个 API 这么简单, 发布新版本时我也是尽量做到不影响旧版本, 在一些做了更改会影响到旧版本更新的地方, 我也在 更新日志 给出了详细的批注以及减小升级成本的方式, 我公司一个十几个模块几百个页面的组件化项目是直接远程依赖 Arms 的, 我每次也都是第一时间升级最新版本, 所以我心里是清楚升级最新版本所花费的成本的, 基本上我这个几百个页面的大项目升级的时间都是在半个小时以内, 大多都是几分钟就搞定, 所以更新你大可不必太过担心, 我这个项目十几个模块几百个页面, 如果更新成本太大我这个项目也是受影响最严重的, 我不可能自己坑自己的, 后面的更新也都会很稳定的

[yeyueduxing]

嗯，好的，谢谢啊

[kinzirva]

@JessYanCoding 你好，关于UserActivity等所有的activity和fragment初始化有个建议：dagger2其实有新的方式来规避，（可以让基类实现baseactivity集成HasActivityInjector），这样一劳永逸！setupActivityComponent这个方法都可以不用再多次初始化，甚至都没必要了。后续所有集成基类的activity或者fragment，都已经有对应HasActivityInjector，HasSupportfragmentInjector的方法了。然hou维护一个androidinjection（是为了activity和fragment oncreate的时候吧它们对应的inject进来！）望采纳。

[JessYanCoding]

@kinzirva 谢谢你的建议, 关于 Dagger2 的新特性我也很久没关注了, 一直在忙别的东西, 第二个原因也是因为怕框架使用新的 特性 会影响之前的用户, 我后面会仔细研究下 Dagger2 以及 Dagger.Android 等新功能, 后续会推出

[kinzirva]

@JessYanCoding 有个小建议哈，其实咱后面，也可以来一版kotlin的项目。我个人现在对app团队要求就是新的业务场景使用kotlin来实现。毕竟是个趋势了。（搞个实验室项目，主要收集和拓展新的框架或者语言特性，像微信 Tinker和360 Repugin那样。研发人员参与进来有贡献就ok）

[JessYanCoding]

@kinzirva 你这个建议也是可以的, 但是这个框架, 目前来说基本上是我一个人来维护和迭代升级, 你看我每个月的提交记录也知道我从来就没休息过, 一直在完成自己对这个项目规划的一些目标, 所以在完成现有的一些规划之前, 实在抽不出时间搞其他实验版, 随着项目用户的增长, 我的压力也越来越大, 毕竟没有一个完美的框架可以应对所有用户的需求, 只有不断的用时间去做优化以及对一些东西做取舍框架才能更完美, 但这个推进的速度也许会很慢, 毕竟一个人的力量比不了那些专业团队

[faxinter]

是不是可以考虑来一个 mvvmArms 框架了

[xiaobailong24]

@wfxphoebus https://github.com/xiaobailong24/MVVMArms
可以参考下

[zhizhulp]

网络请求绑定activity生命周期的时候compose(RxUtils.bindToLifecycle(mRootView))是否能够指定特定的周期，目前是绑定当前的生命周期，导致RESUME时绑定，pause时解绑，无法指定在destroy时解绑。

我也遇到这个问题

[githeer]

@JessYanCoding改造好了。我之前对框架和dagger的理解还是不够想的太复杂了。最后整理了一下思路，尝试框架内的di一套不去动他，还是交给框架内的AppDelegate去管理。然后我们通过自定义的Application在OnCreate方法里面注入我们项目（demo）需要的一套di（AppComponent+allActivityModules+AllFragmentModules）去做依赖注入就行了。在自己的appComponent里面不用写框架内AppComponent的方法并且可以扩展自己的项目需要的一些临时单例等，感觉可以完美让arms框架用上dagger.android了

@JessYanCoding 改造好了。我之前对框架和dagger的理解还是不够 想的太复杂了。最后整理了一下思路，尝试框架内的di一套不去动他，还是交给框架内的AppDelegate去管理。然后我们通过自定义的Application在OnCreate方法里面注入我们项目（demo）需要的一套di（AppComponent+allActivityModules+AllFragmentModules）去做依赖注入就行了。在自己的appComponent里面不用写框架内AppComponent的方法 并且可以扩展自己的项目需要的一些临时单例等，感觉可以完美让arms框架用上dagger.android了

这样子重复注入依赖会有问题吗

[JessYanCoding]

@ncworm 先实践，再问

[xilost]

有个问题，现在我需要建一个全局的单例对象，找不到合适的地方，只想到自己新建个application来实现。

[JessYanCoding]

@xilost 自定义 Application 持有全局单例是可以的，但是需要多一步创建操作，GlobalConfiguration 和 AppLifecyclesImpl 是现成的，里面大部分方法都能拿到 Context，可以在里面创建静态方法

[zhuxiaole]

@JessYanCoding ,Glide有with(Fragment)的特性，希望ImageLoader中可以增加loadImage(Fragment fragment, T config)方法来保留这个特性。

[JessYanCoding]

@zhuxiaole ImageLoader 是上层，他下层可能是 Glide，或者其他图片加载框架，如果一个上层耦合某一个下层特有的特性，从设计上来说就有很多弊端，而且 Glide 以及其他图片加载框架有很多非常有用的功能，如果一有使用者需要新的功能我就被动的增加方法的话，对我来说是低效的，而且永远满足不了所有人的需求，这就是我为什么要把 ImageConfig 设计成建造者模式，并且推荐让你们自己去实现，因为们你们完全可以自己去创建实现类往里面不断的扩展参数，而 Fragment 不过是里面的参数，我根本就不需要知道你们在图片请求时需要什么参数，需要什么逻辑，但你们照样能满足自己的所有需要，因为这些你们完全可以自定义，这就是我这样设计的本质原因，https://github.com/JessYanCoding/MVPArms/wiki#3.4

[xiejingwlin]

android4.4手机不支持吗，报java.lang.RuntimeException: Unable to instantiate application com.jess.arms.base.BaseApplication: java.lang.IllegalArgumentException: Unable to find ConfigModule implementation
Caused by: java.lang.IllegalArgumentException: Unable to find ConfigModule implementation
at com.jess.arms.integration.ManifestParser.parseModule(ManifestParser.java:68)
at com.jess.arms.integration.ManifestParser.parse(ManifestParser.java:52)
at com.jess.arms.base.delegate.AppDelegate.(AppDelegate.java:76)
at com.jess.arms.base.BaseApplication.attachBaseContext(BaseApplication.java:56)

[JessYanCoding]

@xiejingwlin https://github.com/JessYanCoding/MVPArms/wiki/Issues#3

[xilost]

J神，为啥在GlobalConfiguration里设置了ProgressManager.getInstance().with(okhttpBuilder);，监听下载状态的时候没有效果呢？

[JessYanCoding]

@xilost https://github.com/JessYanCoding/ProgressManager 兄弟跑下官方 Demo，看下 Demo 里的代码是怎么操作的

[xilost]

J神，有个小疑惑，按照项目里config.gradle的配置拉取第三方库都没问题，但是只要改下某一个第三方包的版本号就不行了，比如photoview升级2.3.0，就开始报”Could not resolve“。

[Leu-Z]

现在框架里的AppGlideModule是写死的，里面的配置无法自定义。而且我看了Glide的官方文档，“程序库一定 不要 包含 AppGlideModule 实现。”它建议在程序库里使用LibraryGlideModule，尽管LibraryGlideModule里不允许配置应用特定的设置项，比如缓存实现和缓存大小。

比如我现在我遇到一个问题，希望Glide使用单独配置的OkHttpClient，但是现在框架里在AppGlideModule中写死的使用和调用普通接口同一个OkHttpClient，根本无法更改。对于一个特定的应用，只能存在一个 AppGlideModule 实现（超过一个会在编译时报错）。

我觉得可以把AppGlideModule开放出来，让用户自己去实现，这样自由度更高。

[JessYanCoding]

@Leu-Z

1. 想更改 OkHttpClient 哪怕不使用 AppGlideModule，使用 LibraryGlideModule 就可以更改，因为用来修改 OkHttpClient 的 registerComponents() 方法本身就是 LibraryGlideModule 的方法，AppGlideModule 只不过是继承了 LibraryGlideModule。

   

2. Glide 的确只允许在项目中只能存在一个 AppGlideModule，所以它在文档中建议三方库只能使用 LibraryGlideModule，但是为什么一定跟随它的思维呢？我在 Arms 中虽然占用了这唯一的 AppGlideModule，但是我可以将 AppGlideModule 的权利分发出去啊，只要外部使用者实现了某个接口，Arms 就赋予这个接口实现类与 AppGlideModule 同样的，可以配置 Glide 的权利，这不就可以了吗。

   

   让 ImageLoaderStrategy 实现 GlideAppliesOptions 接口即可。

[Leu-Z]

@JessYanCoding 我经过多次尝试后，发现通过在应用程序中单独实现LibraryGlideModule来修改 OkHttpClient的方法，并不会起作用，类名一直是灰的，Glide不会去使用它。
只有再添加一个AppGlideModule 实现，前面的LibraryGlideModule才会被调用，但是这个时候就存在了两个AppGlideModule，会起冲突。

[JessYanCoding]

@Leu-Z 如果不行的话，如果你执意不想使用同一个 Okhttp，建议先代码拉下来改，这里的代码是很久之前的，当时是测试通过了的，也不知道后来 Glide 升级后，是否改了一些东西，后面有空了再验证下，如果确实不行，我在按上面的方式把 registerComponents() 继续分发给其他接口，实现起来也比较简单

如果只是因为想实现 Okhttp 对不同请求进行不同的 Header 和 Token 等的处理，完全没必要用两个 Okhttp，使用拦截器就可以完成，这个在其他 issues 中我给了解决方案。

[kkroid]

请教一个问题，BaseFragment中有setData方法，这里为什么不用Fragment自己的方法setArguments方法来实现呢？

[JessYanCoding]

@kkroid setArguments 是在 Fragment 创建时，给 Fragment 传递数据的，Fragment 需要自己去 getArguments 获取数据，而 setData 是在 Fragment 创建后，传递数据并通知的目的，setArguments 并没有通知的目的，无法通过调用 setArguments 让 Fragment 响应某项操作，两个方法不是一个东西

[kkroid]

@kkroid setArguments 是在 Fragment 创建时，给 Fragment 传递数据的，Fragment 需要自己去 getArguments 获取数据，而 setData 是在 Fragment 创建后，传递数据并通知的目的，setArguments 并没有通知的目的，无法通过调用 setArguments 让 Fragment 响应某项操作，两个方法不是一个东西

对，setArguments方法的确无法让fragment响应某个操作，只是感觉这两个方法有重叠的功能，所以提问了，感谢回答。

[JessYanCoding]

@kkroid 不冲突，一个是用来传参的，一个用来通信的，setData 可以传参，也是为了通信，因为通信的时候进行数据的传递是必备的需求

[jyy195822328]

大神。 看demo中 UserAtivity UserPresenter 中 几乎没有new来的对象。 都是UserModule中注入。 这些比较简单的,需要增加代码 再一个module 去提供实例吗。 是不是意味着 每一个页面都要有一个独立的module? 现在有种疑惑 有没有必要去Inject

[JessYanCoding]

@jyy195822328 Demo 只是为了展示会把很多东西都放上去，由于有些对象在 Activity presenter 都会用到，所有我直接就在 Module 中去提供，在开发中也是一样的，某个对象需要在多个地方被使用，就可以用 Module 去提供，如果只有一处使用那就没必要，灵活使用就可以了。

[zhuyongdi]

集成了之后app启动速度变得很慢 你们有这样的问题吗