建议改为程序主动调用初始化，应用场景：同一个应用在特定的机器上面不使用这个适配时不进行初始化
weiyfwork opened this issue · 5 comments
我目前遇到一个问题，老项目最早只针对一台设备做的开发，后来要适配多种设备，就用到了这个框架，适配时是用dp做单位，以老设备的屏幕为基准，所有设备界面目前都已完美适配，但是发现一个问题，老设备自从引入这个框架之后变得异常卡顿，所以需要在程序里面进行判断，如果是老设备则不使用该框架
我找到一个解决方法，在AndroidManifest中重新声明InitProvider，并且增加tools:node="remove"属性，aar中原来的InitProvider就不会生效，然后在自己的主程序中自定义一个Provider继承InitProvider并在AndroidManifest中声明，然后就可以在onCreate方法里根据情况来决定是否执行super.onCreate();就可以自己控制框架是否生效了
兄弟的方法还是挺机智的啊，不过下个版本会出一个新方法，AutoSize.checkAndInit(Application)，允许用户主动进行初始化，用你的方法只需要增加 tools:node="remove" 属性将 aar 中的 InitProvider 失效，然后按需调用 AutoSize.checkAndInit(Application) 就可以实现在某些设备上不初始化本框架的功能
@JessYanCoding 好的，大佬
老设备引入框架后卡顿,那这个框架会带来额外的性能消耗吗
@edwardZj 从框架原理来说是不会的，因为框架做的操作，仅仅是从当前 Activity 获取 DisplayMetrics，并更改 DisplayMetrics 的一些属性，对象的获取和赋值基本不会耗时，框架唯一可能耗时的地方是对 density 等属性进行计算，但是这里已经使用了缓存策略，不会重复计算相同的 density 值，并且对缓存策略中 key 的计算，进行了位运算的优化，你可以自行打印
autoConvertDensity 方法的执行时间
框架默认只会在每个 Activity onCreate 和 onStart 时进行两次 density 的设置，如果 autoConvertDensity 耗时不长，框架是不可能耗时的，但如果使用了重写 getResources() 的方案，由于 getResources() 会回调很多次，可能会放大 autoConvertDensity 的耗时
总结，autoConvertDensity 进行了缓存 + 位运算的优化，并且框架只在单个页面中调用了两次，理论上不会存在耗时，你可以在你的老设备上自行打印 autoConvertDensity 的耗时，如果使用了重写 getResources() 的方案，在老设备上不排除有耗时的可能