leobert-lan / blog Goto Github PK

分享在摩托时期，我们如何通过技术改进，让复杂列表页面的代码越来越优雅。

本篇着重从数据结构入手，解释数据模型对业务的支撑

概述

对 数据结构 - 线性表 进行温故，以期获新知

对数据结构-栈进行温故，以期获新知

• 加载过程源码分析
• uml图总结
• 思危，是否存在不当使用的情况
• 思退，是否有激进的使用情况，如果改进，不限于Glide
• 思变，源码中是否提供了灵感，可以优化我们自己的项目

如题

使用DaVinCi 处理背景

1. 分析Glide中对于缓存模块的设计以及编解码的设计
2. 抽象问题为模型，寻找类似的问题
3. 讨论这些设计是否可以用于其他问题的解决
4. 对于这些问题的普遍做法是否存在明显缺陷

理解为什么要有消息机制，挖掘消息机制，避免一些看似神奇的bug

准确描述是布局😜

在Compose中使用Glide？我写了一堆Bug！

斗胆称之为最佳实践。

在前段时间，我发布了一篇组件化场景下，Module依赖管理的实践探索，提出了一种更加符合场景的方案 (#3 or #18 )。

文接上回，再讨论讨论Gradle依赖管理的实践方案。

或许你掌握了measure的细节，layout机制，事件传递机制，canvas各种API，但是，你们想过这个问题吗？

本想狂妄一下叫最佳实践，但是太狂妄容易扯到蛋。

分享一种在组件化项目中，优雅的处理依赖的问题。