[个人]MVC个人优化方案

一、屏幕适配
1.引入了今日头条+竖屏宽度法的屏幕适配方式
2.今日头条适配方案原理：
今日头条适配方案默认项目中只能以高或宽中的一个作为基准，进行适配，为什么不像 AndroidAutoLayout （也是一种适配方案）一样，高以高为基准，宽以宽为基准，同时进行适配呢？
这就引出了一个现在比较棘手的问题，大部分市面上的 Android 设备的屏幕高宽比都不一致，特别是现在大量全面屏的问世，这个问题更加严重，不同厂商推出的全面屏手机的屏幕高宽比都可能不一致。
这时我们只以高或宽其中的一个作为基准进行适配，就会有效的避免布局在高宽比不一致的屏幕上出现变形的问题。
明白这个后，我再来说说 density，density 在每个设备上都是固定的，DPI / 160 = density，屏幕的总 px 宽度 / density = 屏幕的总 dp 宽度
设备 1，屏幕宽度为 1080px，480DPI，屏幕总 dp 宽度为 1080 / (480 / 160) = 360dp
设备 2，屏幕宽度为 1440，560DPI，屏幕总 dp 宽度为 1440 / (560 / 160) = 411dp
可以看到屏幕的总 dp 宽度在不同的设备上是会变化的，但是我们在布局中填写的 dp 值却是固定不变的
这会导致什么呢？假设我们布局中有一个 View 的宽度为 100dp，在设备 1 中 该 View 的宽度占整个屏幕宽度的 27.8% (100 / 360 = 0.278)
但在设备 2 中该 View 的宽度就只能占整个屏幕宽度的 24.3% (100 / 411 = 0.243)，可以看到这个 View 在像素越高的屏幕上，dp 值虽然没变，但是与屏幕的实际比例却发生了较大的变化，所以肉眼的观看效果，会越来越小，这就导致了传统的填写 dp 的屏幕适配方式产生了较大的误差
这时我们要想完美适配，那就必须保证这个 View 在任何分辨率的屏幕上，与屏幕的比例都是相同的
通过修改density（屏幕密度）值，强行把所有不同尺寸分辨率的手机的宽度dp值改成一个统一的值（在清单文件中定义），这样就解决了所有的适配问题，如我在蓝湖中看到我们的UI设计图宽度是375dp，我就可以通过预先规定的最小宽度375dp来为不同设备动态计算出它的density值，并给它固定死，保持这个宽度在不同设备上都是宽度dp比例为一定的，屏幕自适应的核心就是根据需要在使用之前不断修改density、scaledDensity、densityDpi达到适配效果，如下代码的实现；
3.核心原理的代码实现：

// 所以：dp = px/(dpi/160) = 720/(320/160) = 360dp 结论：我们铺满一个机型A需要360dp。

4.可以直接使用成熟的库
（1）引入库
implementation ‘com.github.JessYanCoding:AndroidAutoSize:v1.2.1’
（2）在Androidmanifest中配置参数即可自动全局使用此屏幕适配了

（3）个别的单独页面如果需要取消此适配复原的话，有两种方式一种是activity或者fragment实现CancelAdapt接口，或者在super.onCreate()后执行AutoSize.cancelAdapt(this);即可，推荐第二种方式
（4）//今日头条屏幕屏幕适配库，APP字体不随系统字体大小变更（可设置）
AutoSizeConfig.getInstance().setExcludeFontScale(true);
5.优缺点
优点：
侵入性非常低，该方案和项目完全解耦，使用的还是Android官方单位
接入无性能损耗，使用的全是Android官方的API。
缺点：
项目中的系统控件、三方库控件、等非我们项目自身设计的控件，它们的设计图尺寸并不会和我们项目自身的设计图尺寸一样，此时会产生适配误差（我使用时很少用第三方的控件UI）。解决方案就是取消当前 Activity 的适配效果，改用其他的适配方案
系统修改字体大小后，返回应用系统字体大小还是未改变，需要设置registerComponentCallbacks监听。 Android AutoSize框架已经解决了该问题。
在使用过程中需要进行registerComponentCallbacks监听内容文字的大小改变情况，解决退出应用修改文字大小后，文字大小不改变的情况
6.在项目MVC中目前的使用方式，旧的BaseActivity和BaseFragment均默认取消它的适配，目前旧的密度我打印了为2.75，适配后密度是2.88，比原先大了4.73%，不超过1/20可直接适配替换不算很明显

二、引入了ViewBinding
1.目前项目中存在很多findViewById的操作，而且当我们点击R.id的时候，比如R.id.ll_main可能会出现很多xml布局文件都使用了相同id的情况，如下图，可能会造成难查找和删去后不报错但编译异常的情况，对于这个情况

2.引入viewBinding后的改变
https://www.jianshu.com/p/1282ac817df1
缺点：点击事件还需要set

点击事件的变动，不再使用switch case：

三、状态栏和头布局逻辑的变更
1.方式的变更
一开始的想法是状态栏由第三方库immersionbar来实现，当时的想法方式是它可以实现透明状态栏和自动将布局放置在状态栏下方的操作，但是后来发现这种方式每次都需要给状态栏设置和布局同样的顶部颜色，所以放弃，准备改用沉浸状态栏的形式也就是之前项目里的设计思想，大部分页面必须使用高度可变动的statusView这个view，虽然也可以用第三方库immersionbar给它动态设置高度，但是以前的成果也比较完善了，就不再引用新库了
2.理解之前项目中得使用方式，将一些可动态配置的参数进行页面抽取，如下图。同时还考虑了没有statusView时的情况，也就是纯沉浸式，改善了之前布局再嵌套一层的逻辑，优化了些许性能

四、综合到Base类的变动
0.将一些冗余重复的操作优化，最终挪动到BaseActivity中去，先看一下实例改编页面的最终效果

1.BaseViewBar->BaseMvcViewBar
（1）修改想法是将View的初始化从R.layout的形式修改为viewBinding的形式
（2）将之前在每个Activity中addView的和viewBar的界面初始化操作全部挪到BaseActivity中使用反射的形式

（3）只需要binding传参的方式即可自动界面初始化，修改后的结果

2.BaseController->BaseMvcController
（1）将之前在Controller中实例化viewBar的方式给剥离开，觉得之前先Controller再拿出viewBar的view最后addView的形式不太好，改为由BaseActivity将布局设置好后再绑定Controller并返给它viewBar的形式
之前：

修改后：

3.BaseActivty->BaseMvcActivity->AppBaseMvcActivity
（1）将之前Activity中onCreate的Controller和ViewBar绑定均用泛型传参的形式绑定到BaseActivity中

使用反射的形式将view和controller均在BaseActivity中实例化绑定

最后我们看看AppBaseMvcActivity，它将一些需要特殊配置的Activity综合配置了，如果你事先知道它是否是特殊需要配置的页面就可以添加个性化的配置了，其他的BaseMvcActivity保持默认

4.最后我们来看修改后的变化LoginActivity和AchievementDetailActivity相关的使用后的变化
五、recycleView适配器使用成熟的第三方brvah
全称baseRecyclerViewAdapterHelper，顾名思义就是recycleView的适配器帮助者
https://blog.csdn.net/weixin_39069034/article/details/100827789
1.优点：省略代码实例，同时省略自定义的点击事件回调，它会自定定义点击事件

2.缺点：对viewBinding的支持不好，后续可能需要我们自己在它基础上再提取一个Adapter基类

六、使用性能更优的MMKV替换掉SharedPreferences或者使用Sp工具类
1.mmkv是腾讯基于mmap的缓存框架
https://blog.csdn.net/qq_36961698/article/details/121459848?spm=1001.2101.3001.6650.1&utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7ERate-1.pc_relevant_antiscanv2&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7ERate-1.pc_relevant_antiscanv2&utm_relevant_index=2
https://www.jianshu.com/p/cb2016566504

2.使用MySpUtils工具类