一、屏幕適配
1.引入了今日頭條+豎屏寬度法的屏幕適配方式
2.今日頭條適配方案原理：
今日頭條適配方案默認(rèn)項(xiàng)目中只能以高或?qū)捴械囊粋€(gè)作為基準(zhǔn)趟据，進(jìn)行適配，為什么不像 AndroidAutoLayout （也是一種適配方案）一樣盅视，高以高為基準(zhǔn)弱恒，寬以寬為基準(zhǔn)，同時(shí)進(jìn)行適配呢烘跺？
這就引出了一個(gè)現(xiàn)在比較棘手的問題湘纵，大部分市面上的 Android 設(shè)備的屏幕高寬比都不一致，特別是現(xiàn)在大量全面屏的問世滤淳，這個(gè)問題更加嚴(yán)重梧喷，不同廠商推出的全面屏手機(jī)的屏幕高寬比都可能不一致。
這時(shí)我們只以高或?qū)捚渲械囊粋€(gè)作為基準(zhǔn)進(jìn)行適配，就會(huì)有效的避免布局在高寬比不一致的屏幕上出現(xiàn)變形的問題铺敌。
明白這個(gè)后汇歹，我再來說說 density，density 在每個(gè)設(shè)備上都是固定的适刀，DPI / 160 = density秤朗，屏幕的總 px 寬度 / density = 屏幕的總 dp 寬度
設(shè)備 1，屏幕寬度為 1080px笔喉，480DPI取视，屏幕總 dp 寬度為 1080 / (480 / 160) = 360dp
設(shè)備 2，屏幕寬度為 1440常挚，560DPI作谭，屏幕總 dp 寬度為 1440 / (560 / 160) = 411dp
可以看到屏幕的總 dp 寬度在不同的設(shè)備上是會(huì)變化的，但是我們?cè)诓季种刑顚懙?dp 值卻是固定不變的
這會(huì)導(dǎo)致什么呢奄毡？假設(shè)我們布局中有一個(gè) View 的寬度為 100dp折欠，在設(shè)備 1 中 該 View 的寬度占整個(gè)屏幕寬度的 27.8% (100 / 360 = 0.278)
但在設(shè)備 2 中該 View 的寬度就只能占整個(gè)屏幕寬度的 24.3% (100 / 411 = 0.243)，可以看到這個(gè) View 在像素越高的屏幕上吼过，dp 值雖然沒變锐秦，但是與屏幕的實(shí)際比例卻發(fā)生了較大的變化，所以肉眼的觀看效果盗忱，會(huì)越來越小酱床，這就導(dǎo)致了傳統(tǒng)的填寫 dp 的屏幕適配方式產(chǎn)生了較大的誤差
這時(shí)我們要想完美適配，那就必須保證這個(gè) View 在任何分辨率的屏幕上趟佃，與屏幕的比例都是相同的
通過修改density（屏幕密度）值扇谣，強(qiáng)行把所有不同尺寸分辨率的手機(jī)的寬度dp值改成一個(gè)統(tǒng)一的值（在清單文件中定義），這樣就解決了所有的適配問題闲昭，如我在藍(lán)湖中看到我們的UI設(shè)計(jì)圖寬度是375dp罐寨，我就可以通過預(yù)先規(guī)定的最小寬度375dp來為不同設(shè)備動(dòng)態(tài)計(jì)算出它的density值，并給它固定死序矩，保持這個(gè)寬度在不同設(shè)備上都是寬度dp比例為一定的拙泽，屏幕自適應(yīng)的核心就是根據(jù)需要在使用之前不斷修改density能耻、scaledDensity遮精、densityDpi達(dá)到適配效果酬土，如下代碼的實(shí)現(xiàn)；
3.核心原理的代碼實(shí)現(xiàn)：

// 所以：dp = px/(dpi/160) = 720/(320/160) = 360dp 結(jié)論：我們鋪滿一個(gè)機(jī)型A需要360dp啃擦。

4.可以直接使用成熟的庫
（1）引入庫
implementation 'com.github.JessYanCoding:AndroidAutoSize:v1.2.1'
（2）在Androidmanifest中配置參數(shù)即可自動(dòng)全局使用此屏幕適配了

（3）個(gè)別的單獨(dú)頁面如果需要取消此適配復(fù)原的話囊蓝，有兩種方式一種是activity或者fragment實(shí)現(xiàn)CancelAdapt接口，或者在super.onCreate()后執(zhí)行AutoSize.cancelAdapt(this);即可令蛉，推薦第二種方式
（4）//今日頭條屏幕屏幕適配庫聚霜，APP字體不隨系統(tǒng)字體大小變更（可設(shè)置）
AutoSizeConfig.getInstance().setExcludeFontScale(true);
5.優(yōu)缺點(diǎn)
優(yōu)點(diǎn)：
侵入性非常低狡恬，該方案和項(xiàng)目完全解耦，使用的還是Android官方單位
接入無性能損耗蝎宇，使用的全是Android官方的API弟劲。
缺點(diǎn)：
項(xiàng)目中的系統(tǒng)控件、三方庫控件姥芥、等非我們項(xiàng)目自身設(shè)計(jì)的控件兔乞，它們的設(shè)計(jì)圖尺寸并不會(huì)和我們項(xiàng)目自身的設(shè)計(jì)圖尺寸一樣，此時(shí)會(huì)產(chǎn)生適配誤差（我使用時(shí)很少用第三方的控件UI）凉唐。解決方案就是取消當(dāng)前 Activity 的適配效果庸追，改用其他的適配方案
系統(tǒng)修改字體大小后，返回應(yīng)用系統(tǒng)字體大小還是未改變台囱，需要設(shè)置registerComponentCallbacks監(jiān)聽淡溯。 Android AutoSize框架已經(jīng)解決了該問題。
在使用過程中需要進(jìn)行registerComponentCallbacks監(jiān)聽內(nèi)容文字的大小改變情況簿训，解決退出應(yīng)用修改文字大小后咱娶，文字大小不改變的情況
6.在項(xiàng)目MVC中目前的使用方式，舊的BaseActivity和BaseFragment均默認(rèn)取消它的適配强品，目前舊的密度我打印了為2.75膘侮，適配后密度是2.88，比原先大了4.73%的榛，不超過1/20可直接適配替換不算很明顯

二喻喳、引入了ViewBinding
1.目前項(xiàng)目中存在很多findViewById的操作，而且當(dāng)我們點(diǎn)擊R.id的時(shí)候困曙，比如R.id.ll_main可能會(huì)出現(xiàn)很多xml布局文件都使用了相同id的情況，如下圖谦去，可能會(huì)造成難查找和刪去后不報(bào)錯(cuò)但編譯異常的情況慷丽，對(duì)于這個(gè)情況

2.引入viewBinding后的改變
http://www.reibang.com/p/1282ac817df1
缺點(diǎn)：點(diǎn)擊事件還需要set

點(diǎn)擊事件的變動(dòng)，不再使用switch case：

三鳄哭、狀態(tài)欄和頭布局邏輯的變更
1.方式的變更
一開始的想法是狀態(tài)欄由第三方庫immersionbar來實(shí)現(xiàn)要糊，當(dāng)時(shí)的想法方式是它可以實(shí)現(xiàn)透明狀態(tài)欄和自動(dòng)將布局放置在狀態(tài)欄下方的操作，但是后來發(fā)現(xiàn)這種方式每次都需要給狀態(tài)欄設(shè)置和布局同樣的頂部顏色妆丘，所以放棄锄俄，準(zhǔn)備改用沉浸狀態(tài)欄的形式也就是之前項(xiàng)目里的設(shè)計(jì)思想，大部分頁面必須使用高度可變動(dòng)的statusView這個(gè)view勺拣，雖然也可以用第三方庫immersionbar給它動(dòng)態(tài)設(shè)置高度奶赠，但是以前的成果也比較完善了，就不再引用新庫了
2.理解之前項(xiàng)目中得使用方式药有，將一些可動(dòng)態(tài)配置的參數(shù)進(jìn)行頁面抽取毅戈，如下圖苹丸。同時(shí)還考慮了沒有statusView時(shí)的情況，也就是純沉浸式苇经，改善了之前布局再嵌套一層的邏輯赘理，優(yōu)化了些許性能

四、綜合到Base類的變動(dòng)
0.將一些冗余重復(fù)的操作優(yōu)化扇单，最終挪動(dòng)到BaseActivity中去商模，先看一下實(shí)例改編頁面的最終效果

1.BaseViewBar->BaseMvcViewBar
（1）修改想法是將View的初始化從R.layout的形式修改為viewBinding的形式
（2）將之前在每個(gè)Activity中addView的和viewBar的界面初始化操作全部挪到BaseActivity中使用反射的形式

（3）只需要binding傳參的方式即可自動(dòng)界面初始化，修改后的結(jié)果

2.BaseController->BaseMvcController
（1）將之前在Controller中實(shí)例化viewBar的方式給剝離開蜘澜，覺得之前先Controller再拿出viewBar的view最后addView的形式不太好施流，改為由BaseActivity將布局設(shè)置好后再綁定Controller并返給它viewBar的形式
之前：

修改后：

3.BaseActivty->BaseMvcActivity->AppBaseMvcActivity
（1）將之前Activity中onCreate的Controller和ViewBar綁定均用泛型傳參的形式綁定到BaseActivity中

使用反射的形式將view和controller均在BaseActivity中實(shí)例化綁定

最后我們看看AppBaseMvcActivity，它將一些需要特殊配置的Activity綜合配置了兼都，如果你事先知道它是否是特殊需要配置的頁面就可以添加個(gè)性化的配置了嫂沉，其他的BaseMvcActivity保持默認(rèn)

4.最后我們來看修改后的變化LoginActivity和AchievementDetailActivity相關(guān)的使用后的變化
五、recycleView適配器使用成熟的第三方brvah
全稱baseRecyclerViewAdapterHelper扮碧，顧名思義就是recycleView的適配器幫助者
https://blog.csdn.net/weixin_39069034/article/details/100827789
1.優(yōu)點(diǎn)：省略代碼實(shí)例趟章，同時(shí)省略自定義的點(diǎn)擊事件回調(diào)，它會(huì)自定定義點(diǎn)擊事件

2.缺點(diǎn)：對(duì)viewBinding的支持不好慎王，后續(xù)可能需要我們自己在它基礎(chǔ)上再提取一個(gè)Adapter基類

六蚓土、使用性能更優(yōu)的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
http://www.reibang.com/p/cb2016566504

2.使用MySpUtils工具類