柿蒂

不论是代码优化、架构设计、性能调优都逃不开这些基本原理。离开了地基，再高深的设计模式、框架思维，都很容易成为空中楼阁

由繁至简的过程，其实是一种不一样的体验，“笨办法”或许有时候才是真正聪明的做法，真正的经验往往不是“多高明的技巧”，而是什么时候该停下折腾，选择最合适的平衡点。

其实在工程实践里面很少有最优解，更多的是“阶段解”，我们的每个版本都是为了在当前的条件下一步一步的解决问题

面对三端并行开发带来的巨大复杂度，我们并不急于“全栈统一”，而是更关注架构的合理性与团队协作的可持续性。

一个项目需要有能快速上线并且快速看到用户反馈的能力，也就应该有能够快速定位和解决问题的能力。而如果拥有随时可以重构代码的能力，那么其实不应该对“有问题的代码”产生焦虑。

有时候核心需求的「精准命中」远胜技术完美，功能的价值最终由用户的「实际使用」而非「技术指标」来定义。

我们常说 View “绘制不对动”，但真正的问题常常发生在 测量 (onMeasure) 和 布局 (onLayout) 阶段。我通过项目中实际遇到的几个编译后正常，运行时乱七八糟的坑，来分析下

前言: 很多架构在项目初的时候看不出破绽；只有当项目维护和扩展越来越难的时候，才真正意识到——设计模式不是“装饰”，而是“地基” 。

前言： Android拖拽view进行移动是一个很常见并且很“正常”的功能，在合理的逻辑中，可以实现并不复杂的运算，对于用户设备的性能消耗理论上也可以得到一个较好的支持。