shifujun

你前面的堆栈显示这里试图在Activity的attachBaseContext方法调用super.attachBaseContext之前就getResource。 我起初看到`androidx.appcompat.app.SkinAppCompatDelegateImpl`的包名，以为这是官方的代码呢。搜了一下看起来不是。 我现在也写不出正常情况下在调用super.attachBaseContext之前就getResource能正常跑的例子。

原来RepluginClassLoader中可以做的Hook也都可以在PMFClassLoader中做。因为PathClassLoader总是尊重parent的ClassLoader的。

> 求问这个问题现在怎么解决的？ > > 这个issue原本的问题看起来也不是很清楚。你如果有类似的问题就fork一下，如果能在sample中修改复现，就新提一个issue吧。注意在sample或者test中搜一下，可能有lifecycle的用例。

之前没看明白，这个问题跟SubName的设计压根没关系。就是getDatabasePath是支持绝对路径传入原样传回来的。 > 对于 SubDirContextThemeWrapperTest 的测试用例，弄半天这个测试项目都运行不起来，实在不知道如何跑用例😂 @Heart-Beats 运行测试用例可以看下https://github.com/Tencent/Shadow/pull/1311/commits/f31081a40bd2f20c40acc5f0b19f7bdadb0ceedb

> instructionSet获取到都是 “arm”。所以is64BitInstructionSet方法返回到都是false，这样得到的都是32位。是我这边的问题吗？我换了麒麟970、麒麟990、通骁龙8 Gen1处理器的手机都是这样。 在64位CPU的手机上得到当前宿主app在使用32为so，只能说明宿主在使用32位so，处于一种兼容模型。这不是问题。 除非说宿主确实在使用64位so，但是instructionSet获取到的是“arm”，那才是Bug。 如果有问题再打开吧。

This is definitely a bug. Just by looking at it, you can guess that it should most likely be changed like this: ```java if (typeName == null) kind = new...

既然确实不同手机有快有慢，这个优化肯定要针对不同手机来做了。所以分析这个问题并不容易。可能影响比较大的还是磁盘I/O。如果你定位到具体某个方法确实慢，咱们可以一起考虑下怎么优化，比如之前有优化过加载宿主类的白名单的匹配。 按已有的经验，最有效的手段是预加载。在用户触发任何插件的功能前，提前主动执行完插件的application onCreate。尽可能让插件处于就差显示界面这一步了。如果插件还有什么方法可以提前执行，也要提前做。

没有代码，就先有一个问题：什么叫被hook呀？ 你fork一下项目，然后在sample里写个用例演示一下就清楚了。

那确实是宿主中的container activity注意注册成不透明的才行。 因为我们当时只考虑了插件activity有的透明有的不透明，所以壳子注册成透明的，方便插件调整背景颜色。并没有用到onStop，所以忽略了这一点。

> AP31.240426.023.B4 https://developer.android.com/about/versions/15/release-notes 你至少先装个最新的Beta 3再测吧？其实你改标题就能看出来你根本不在意是什么版本。 这些Beta版本系统没什么测试意义，bug会非常多。 你这个堆栈可能也没仔细看，那不就是new一个WebView就挂了么？如果你仔细看了应该在issue中指出来这一点，并且给出你测试new Webview的结果。