码农弟弟

那我来说说glide4 的缓存机制吧 glide4 缓存主要分为三个 activiteResources(弱引用缓存) MemoryCache(Lru缓存) DiskCache(磁盘缓存) 还有一个http网络缓存, 不多做介绍 首先弱引用缓存代表的是当前正在使用的缓存, 请求图片之后 会分为两个步骤, 1.进入磁盘缓存,2进入弱引用缓存。 在弱引用缓存中使用一个计数器来维护当前资源的是否被使用,如果计数器=0说明当前资源已经不被使用了,则进入Lru缓存,Lru缓存是glide使用linkhashmap来维护的,如果lru满了则删除最长时间未使用的。 如果一个资源加载的时候在弱引用缓存中找不到,就会到lru缓存中查找,如果没找到就去磁盘缓存找,不管在lru中找到 还是在磁盘中找到, 都会把命中的缓存,放在弱引用缓存中. glide设计的三层缓存模型, 其中内存缓存 减轻了磁盘缓存的压力,避免io操作,而弱引用缓存则减轻了 lru缓存的压力,避免lru过满导致频繁gc,并且提高查找效率 另外再说下 glide4 五种缓存策略 data source all no automic data则是缓存住原始图片资源,...

aidl 广播等,跨进程原理是用binder机制,binder机制是一种cs架构的IPC通信方案,细节请大佬补充

每一个线程都有一个 handler loop messagequeue机制 线程A要调用线程B 首先线程A会向 线程b的mq中发送一条消息, 线程b的looper就会不断循环取出里面的消息 然后调用线程a的handler的 handlemessage 从而实现了不同线程间通信

1.把application oncreate 中要执行的方法 分为同步和异步,尽量去延迟执行 或者使用空闲线程 去初始化一些方法 2.配置一个启动背景,避免白屏或者黑屏,然后做一个空的Activity这个Activity只做一件事,就是跳转到真的Activity,因为 启动速度 和application oncreate的耗时和第一个Activity的绘制有关, 上面都是easy的做法 3. 利用 redex 工具 优化 dex , 因为 class字节码 分布在不同的dex中,所以启动的时候必须逐个查找一些文件,他们散列分布在不同的dex中,查找起来耗时又不方便,利用redex 把相关的class 放在同一个dex包下,避免 同一个dex包被多次查找 4.在attachedbaseContext中 新起一个进程 去加载 mutildex 可以加速App启动页的打开(可能在启动页中会等待,但是加速了从launcher到启动页的速度)

你说二级缓存,其实recyclerView缓存细分不止二级. 我来说说我的看法 scrap viewCache recyclerPool scrap 是当前展示的缓存, 在onlayout时候 缓存 viewCache 是屏幕外看不见的缓存, 可以吧viewCache设置大点,空间换时间 避免段距离内快速滑动卡顿 以上两种缓存是不走 createView和 onbind recyclerPool 比较特殊他是会走 onbind的,他可以被多个recyclerView共享内部的item,实际用途是:多个recyclerView之间共享item,应用在 垂直recyclerView 内嵌水平recyclerView,或者viewpager中多个recyclerView 网易新闻首页

1.监听onscrolllistener 把一部分的图片加载和 视频控件出事化到 停止滚动的时候采取加载 2.在feed流中使用viewstub, 把一部分不是每次都要初始化的view 延迟初始化 3.使用 x2c 工具 把原本是xml 构造的界面 转为代码生成 减少 读取xml的 ios操作 4.设置viewCacheSize 使得短距离内快速滑动,复用item,不用走createView和 binderView,避免卡顿 5.设置recyclerPool, 使得 一个Activity中多个相似的recyclerView, 或者水平嵌套垂直的 recyclerView可以复用 6.不在onbindview里面做数据操作 而是获取网络的时候就把model中的复杂数据处理成简单地viewmodel,直接设置进去就能用了 7.使用空闲线程 去预先初始化一部分 view 8.如果可以...

接口隔离原则

能否简便点,不要让业务层写这么多代码

我认为最好不要让用户配置这种数字，而是初始化的时候传入一个枚举，告诉你UI给的设计稿是基于哪个设备 而不是传入数字或者传一个闭包，要简化业务层的代码。

这块改善了吗