几个小的改进的建议，希望能采纳 。
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 25/100
- Issue 类型
- 功能
- 描述清晰度
- 需要澄清
- 活跃度
- 停滞
- 领域
- mobile, performance
调研方向
首先跟踪 SkinAttrSupport.getSkinViews(Activity) 以及 issue 中描述的 skin 应用流程，包括 activity 注册和 onResume 处理。将当前的完整 activity 扫描和刷新时机与提议的延迟方案进行比较。完成的标准是实现一项已达成共识的性能改进，并验证其在多个 activity 中的行为。
由索引模型根据 Issue 内容生成。
描述
1 actionbar如何换肤
我看其中的代码,是从activity里面content中开始遍历，而不是rootview开始
public static List<SkinView> getSkinViews(Activity activity)
{
List<SkinView> skinViews = new ArrayList<SkinView>();
ViewGroup content = (ViewGroup) activity.findViewById(android.R.id.content);
addSkinViews(content, skinViews);
return skinViews;
}
2 每次换肤都开始扫描整体所有activity，如果打开的activity过多，或者activity中有较多的元素需要更换，这里能不能自身去维护skinViews,因为后续还有便利和字符串裁剪工作要做，这里能不能换成先将处于resume的activity优先换掉。然后发消息给剩下的activity的，让其在onresume中再换掉，这里的性能会不会好点？
List<SkinView> skinViews = SkinAttrSupport.getSkinViews(activity);
3 如果我没理解错，原理是通过加载宿主的资源文件，然后通过regster的方式里面调用apply去刷新regster的activity的布局，如果打开的activity过多，或者activity中有较多的元素，这个操作是不是会让activity较慢显示在用户的视野，能不能将regster的时机推迟到onResume中？
- 主要语言
- Java
- 星标
- 1.7k
- 派生
- 364
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
我们还没有检查这个项目的环境配置文件。先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
hongyangAndroid/AndroidChangeSkin 的其他 Issue
-
难度 3/5 1-2 天 新手友好度 20/100
-
难度 5/5 一周以上 新手友好度 20/100
-
动态设置颜色和图片时，换肤失效！未关闭
难度 4/5 3-5 天 新手友好度 35/100
-
难度 3/5 1-2 天 新手友好度 25/100
hongyangAndroid/AndroidChangeSkin#46 · 3 条评论 ·
-
自定义View无法换肤未关闭
难度 5/5 一周以上 新手友好度 15/100
查看 hongyangAndroid/AndroidChangeSkin 的全部 Issue
相似的 Issue
-
难度 1/5 1 小时以内 新手友好度 92/100
-
难度 2/5 1-3 小时 新手友好度 68/100
-
难度 2/5 1-3 小时 新手友好度 72/100
oracle/javavscode#652 ·
-
难度 2/5 1-3 小时 新手友好度 78/100
OpenAPITools/openapi-generator#25014 ·
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 92/100
AloisSeckar/demos-java#380 ·