数据库与屏幕适配

1、SQLite
安卓数据库SQLite
Android中的数据库——SqLite
2、GreenDao
GreenDao的总结
 在AndroidStudio4.1.1上使用GreenDao
DaoMaster 负责数据库的初始化和版本管理。
DaoSession 提供了一个会话层，通过它可以访问到所有的 DAO。
XXXDao 是针对特定实体的操作接口，提供了丰富的数据操作方法。
在使用 GreenDAO 开发应用时，通常的流程是首先创建或获取一个 DaoMaster 实例，然后通过 DaoMaster 创建 DaoSession，最后通过 DaoSession 获取所需的 DAO 对象来进行数据操作。
3、ROOM
Room数据库的使用与升级
升级room
提供自定义的Migration：

@Database(entities = [Book::class], version = 1)
abstract class AppRoomDataBase : RoomDatabase() {
       //创建DAO的抽象类
       abstract fun bookDao(): BookDao

       val MIGRATION_2_3 = object : Migration(2, 3) {
           override fun migrate(database: SupportSQLiteDatabase) {
               //对Book表增加一个score字段
               database.execSQL("ALTER TABLE Book ADD COLUMN score TEXT NOT NULL   DEFAULT ''")
           }
       }
   companion object {
           private val DATABASE_NAME = "simple_app.db"
           @Volatile
           private var databaseInstance: AppRoomDataBase? = null
           @Synchronized
           open fun getInstance(): RoomDaoManager {
                   if (databaseInstance == null) {
                           databaseInstance = Room.databaseBuilder(BaseApplication.get(), RoomDaoManager::class.java,DATABASE_NAME)
                                   .allowMainThreadQueries()//允许在主线程操作数据库，一般不推荐；设置这个后主线程调用增删改查不会报错，否则会报错
                                   .addMigrations(MIGRATION_2_3)  
                                   .build()
                   }
                   return databaseInstance!!
           }
        }
}

GreenDAO的缺点：
是一个开源项目，基本没有更新。
需要通过代码生成器生成实体类和DAO类。
没有编译时SQL检查，SQL语句错误只能在运行时发现。
需要手动编写迁移代码，稍显复杂。
性能非常出色，特别是在大量数据操作的场景下。适合对性能要求较高的应用。

Room的优点：
由Google官方开发和维护，作为Android Jetpack的一部分。
使用方便，提供了编译时检查和安全的数据库访问。
易于使用和理解，提供了注解处理器自动生成的SQL语句。
支持Kotlin协程，与LiveData、ViewModel等架构组件无缝集成，支持响应式编程。
提供了简洁的数据库迁移机制，通过Migration类来定义迁移策略。
支持常见的注解如@Entity、@Dao、@Insert、@Update、@Delete、@Query等。
提供编译时SQL语句检查，能够在编译阶段捕获SQL语法错误。
性能较好，但由于编译时检查和类型安全性，可能在某些场景下性能略微逊色于GreenDAO。适合大多数常见应用场景。

屏幕适配
Android 今日头条适配详解
 Android 目前稳定高效的UI适配方案
 Android屏幕适配方案
0、宽高限定符适配
简单的意思来说，就是穷举市面上所有的Android手机的宽高像素值。
比如480*320的分辨率为基准
宽度为320，将任何分辨率的宽度分为320份，取值为x1-x320
高度为480，将任何分辨率的高度分为480份，取值为y1-y480
<dimen name="x2">3.0px</dimen>
但这种方式存在两个问题：
（1）有一个致命的缺陷，那就是需要精准命中才能适配，比如1920x1080的手机就一定要找到1920x1080的限定符，否则就只能用统一的默认的dimens文件了。而使用默认的尺寸的话，UI就很可能变形，简单说，就是容错机制很差。
（2）网上现在基本都是使用屏幕分辨率限定符进行适配，即每种屏幕分辨率的设备需要定义一套 dimens.xml 文件。由于不同分辨率的设备太多了，再加上平板那些你会发现 dimens.xml 文件所占的体积已经超过 2M 了！这绝对不是我们想要的。
1、SmallestWidth适配（sw限定符适配）
SmallestWidth适配，或者称之为sw限定符适配。指的是Android会识别屏幕可用高度和宽度的最小尺寸的dp值（其实就是手机的宽度dp值），然后根据识别到的结果去资源文件中寻找对应限定符的文件夹下的资源文件。
这种机制和宽高限定符适配原理上是一样的，都是系统通过特定的规则来选择对应的文件。举个栗子，小米5的dpi是480，横向像素是1080px，根据px=dp(dpi/160)，可求出横向宽度的dp值为360dp，系统就会去寻找是否存在value-sw360dp的文件夹以及对应的资源文件。
SmallestWidth限定符适配和宽高限定符适配最大的区别在于，前者有很好的容错机制，如果没有value-sw360dp文件夹，系统会向下寻找，比如离360dp最近的只有value-sw350dp，那么Android就会选择value-sw350dp文件夹下面的资源文件。这个特性就完美的解决了上文提到的宽高限定符的容错问题。
而这种dimens引用，在不同的values-sw<N>dp文件夹下的数值是不同的，比如values-sw360dp和values-sw400dp:
dimen name="qb px 10">9.60dp</dimen>
2、今日头条适配方案
它是通过修改density值，强行把所有不同尺寸分辨率的手机的宽度dp值改成一个统一的值，这样就解决了所有的适配问题。
比如，设计稿宽度是720px，那么开发这边就会把目标dp值设为720dp，在不同的设备中，动态修改density值，从而保证(手机像素宽度)px/density这个值始终是720dp,这样的话，就能保证UI在不同的设备上表现一致了。
优点：这个方案侵入性很低，而且也没有涉及私有A，修改一次项目所有地方都会适配，无性能损耗。
缺点：
1.只需要修改一次 density，项目中的所有地方都会自动适配，这个看似解放了双手，减少了很多操作，但是实际上反应了一个缺点，那就是只能一刀切的将整个项目进行适配，但适配范围是不可控的。
2.这个方案依赖于设计图尺寸，但是项目中的系统控件、三方库控件、它们的设计图尺寸并不会和我们项目自身的保持一致。
3、AndroidAutoSize
AndroidAutoSize 是一个轻量级的屏幕适配解决方案，基于今日头条的屏幕适配方案封装而成，提供了自动化和自定义扩展的屏幕适配功能。它简化了在不同分辨率设备上保持布局一致性的复杂过程，同时允许开发者灵活地调整适配策略。