叨逼叨
此处记录点零散的小idea，为了避免把csdn当微博，开一篇，都记在这里吧。
感觉服务注册机制，貌似也是一种依赖注入。（虽然我还没完全搞懂依赖注入），理由呢：你需要一个模块的功能，该模块作为一个服务注册上，你就能用，没注册，你的服务请求失败，这样不会出现连build都不过的情况，也达到了解耦的目的，而依赖注入貌似也是帮你完成某个对象的装配，我们可以通过控制依赖注入来灵活的配置装配对象，这样功能的变更不会影响到你的模块，依赖注入配置下就好了，同样目的是解耦。
依赖注入的优势，有时构造一个对象时，很可能这个类的初始化依赖很多其他的类对象，这样一个个都初始化好了，然后再初始化我们需要的类，导致关系复杂，其他不太关心的对象都要了解它的构造过程，而依赖注入可以解决这个问题，不关心具体的组装流程。
“大多数面向对象编程语言，在调用一个类的时候，先要实例化这个类，生成一个对象。如果你在写一个类，过程中要调用到很多其它类，甚至这里的其它类，也要“依赖”于更多其它的类，那么可以想象，你要进行多少次实例化。这就是“依赖”的意思。依赖注入，全称是“依赖注入到容器”， 容器（IOC容器）是一个设计模式，它也是个对象，你把某个类（不管有多少依赖关系）放入这个容器中，可以“解析”出这个类的实例。所以依赖注入就是把有依赖关系的类放入容器（IOC容器）中，然后解析出这个类的实例。仅此而已。”
作者：唐思
链接：https://www.zhihu.com/question/32108444/answer/54773302
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。builder参数构建：初始化时有很多参数，都通过构造函数设置，有时发现某些参数不需要，也要传递，导致代码写了很长很多，很多参数只能设置是null，不想写null，又要写很多不同参数构造函数，所以通过builder更灵活。
浅谈天猫tangram框架
天猫开源的tangram框架，十分适合电商平台的商品展示，方便业务的运营，但是它不支持那种卡片内有click button的处理，一般都是一整张卡片一个处理，不适合一些功能性卡片的开发。不过目前没看到有什么好的库和框架，导致recyclerview写的很烦，有个BRVAH(BaseRecyclerViewAdapterHelper)貌似可以简化写recyclerview的烦恼。不够貌似不是很知名，不太敢用。吐槽一下，android app开发都发展的过气了，很多很基础的功能的库竟然还这么不完善，一些逻辑的处理要写的很复杂，层层嵌套的，套用调侃前端的一句话，要感谢这些app（前端）开发人员，在这么混乱的框架下，仍然写出了这么多“优秀”的程序。我们写代码，究竟是在写什么？
什么是代码，什么是技术？其实编程只是一门工程，和科学不太搭边，做科学研究的只是在利用编程手段完成一些计算处理。而大部分靠编程吃饭的人，都更关注工程方面，而工程方面，主要的关注点在于对业务的抽象能力，如果将复杂的业务抽象分类成一个个简单的模型。这个应该是考察一个工程师最重要的能力，而其他领域知识，是”技“的范畴，是一个时间，经历的积累过程。想不通android里面fragment竟然不能处理back pressed事件。
我是个很tmd能挑刺的人，对于android系统有些接口功能的设计，感到十分“恶心”，比如这个fragment不能处理back pressed事件，比如recyclerview竟然没有官方上拉刷新，没有一个好用的播放器控件（最近封装mediaPlayer都要吐了），很多人可能很坦然的接受，对于这个问题，我的观点：如果在前几年这些都能够接受，而现在android开发已经快”穷途末路“了，竟然很多东西都如此不完善，我并不是存粹的拿来主义，什么都别人做好拿来用，而是希望有良好的分工，基础功能分层，不涉及定制化很多，性能要求很高的基础组件尽量完善，让不同的开发人员处理各自领域的事情。而不是很多东西都从玩泥巴开始。另外对于很多开发者认为研究”底层“原理才牛逼，动不动就分析底层源码的行为，面试时更是动不动喜欢问实现机制的行为，十分不赞同，底层软件就真的高深吗，软件是一个把复杂问题抽象成简单问题的过程，代码是写的简单才牛逼，而不是复杂。不论上层业务还是底层基础软件都是考验抽象，分解，归纳的架构能力。本人之前从事”内核“”驱动“开发，经常遇到很多初生牛犊动不动就想写个操作系统什么的？我一直的观点就是：这个世界上不需要那么多操作系统。如果没有革命性的技术变革，你不过就是copy一份linux，缩小版的。站在巨人的肩膀上构建你的代码，当巨人病了的时候，再去研究巨人。我看过太多自己的业务代码写的一团糟，模块分离不清，各种耦合，重复代码，却整天想着研究底层原理的开发者，先写好自己手头的代码，多看看设计模式吧。
