JessYan

AutoSizeConfig.getInstance().stop(this); 停止框架会崩溃吗

可能是 recyclerview 复用之前的 View 导致的，最好在 onBindHodlder 中使用 AutoSize.autoConvertDensityOfGlobal(activity) 设置 Density 后，再手动刷新这个 Item View 的所有 UI 内容

@13297063206 在 fragment 里面使用的时候也可以传他的宿主 activity

@q454216935 AndroidAutoSize 在版本 **v0.9.1** 之后，新增了副单位，区别与传统的今日头条方案，可以使用 **pt、in、mm** 这三种冷门单位在 **layout** 文件中布局，这样不光可以直接填写设计图中的 **px** 尺寸，不需要再将 **px** 转化为 **dp** 外，还可以规避修改 **DisplayMetrics#density** 所造成的对于其他使用 **dp** 布局的系统控件或三方库控件的不良影响

@q454216935 AndroidManifest 直接填 px 尺寸，在布局中也写 px 的尺寸，但是单位用副单位，详情看 [demo-subunits](https://github.com/JessYanCoding/AndroidAutoSize/tree/master/demo-subunits ) ，注释写的很详细

@q454216935 按照 [README](https://github.com/JessYanCoding/AndroidAutoSize/blob/master/README-zh.md#preview) 中的步骤，创建对应单位的模拟设备，布局中用什么单位就创建什么单位的模拟设备，不可能预览不了，所有单位的模拟设备我测试了无数遍，全部将 **Preview** 放大到 **1000%**，测得创建的所有单位的模拟设备预览时与设计图的误差都不超过 **0.5 px**

@kevinStrange 直接用上面留言提到的副单位，直接可以按照设计图的尺寸填写

@yutouxiansheng 和控件没有关系，只要将框架引入项目，所有控件都可以适配

不是，这个只是预览设备显示效果会变小，图片运行到实际设备不一定会小，为了让副单位布局的页面预览效果能够和设计图的显示效果一模一样，所以使用算法求出的预览设备的屏幕尺寸都是被放大了很多倍的，wrap_content 在放大很多倍的屏幕上显示效果变小在所难免，但并不影响实际的运行效果，因为实际设备的屏幕尺寸是正常

@Leu-Z wrap_content 是按图片的实际大小来显示，在小屏显示正常，在大屏显示效果就很小不是很正常吗，因为图片实际大小是没变的，你要想这个图片也能和其他控件一样同比例放大，就给它标注尺寸，使用 wrap_content 框架是不会帮你同比例缩放的