解读代码系统-具有定制列表项的用户界面

两个知乎话题：

1. 我用假简历去面试去面试android的结果为什么是这样？

1）找工作这种事情就跟找对象一样，只要双方看对眼就成了，别的都是借口。

2）对于小公司而言，重要的是你能留下来，而不是你有多优秀！你再优秀，留不下来也是白搭！你这么叼，就算哄着留下来了，没事抄了老板鱿鱼咋办？这就是为什么好多特别厉害的人反而被小公司刷了，因为公司知道留不住。

3）我觉得这个问题是在钓鱼，钓上来一群酸汤鱼。

4）HR招人首先会考虑能不能留住，离职原因说没有可以学习的，会被认为不稳定，技术会考虑人能不能干活。

2. 培训出来的程序员是不是就真的一无是处？

1）如果你不能通过自学达到可以工作的水平，那你还是放弃这个行业！编程说到底，不是流水线，不是学术，不是工人，是“手工业”，手工业是一个有玄机的行业，师傅和师傅之间差距很大，全看一手功夫，有时候就相差毫厘，却全盘失之，有时候看似漫不经心，却能琢的鬼斧神工，所以....本质上决定一个程序员能走多远的，就是学习能力和方法经验….无它，唯手熟尔 。

2）其实很多人通过培训出来扪心自问是真的热爱编程吗？还是只是被高额薪水吸引？其实是不是培训出来并不重要，重要的是有没有一个踏实的愿意钻研的心。

3）说实话，自学能力不是无师自通的能力，是在没有考试和作业的逼迫下完成学习任务的能力，互联网上很多学习资料和课程视频，坐在家里花点电费网费，各种CS课程随你上，你根本不需要无师自通的天赋，只要有毅力坚持就够了。

4）谈过恋爱的，你就该知道，遇到真爱你只会不由自主的想去靠近，喜欢的行业也是如此。犹豫是因为没有喜欢，是因为内心里还在算计着得失，别想太多，安心的敲代码，一辈子做一个奋斗在一线的码农吧，因为编程工作带来的成就感已经成为我生活中不可或缺的一部分了。

5）所有又臭又硬，抱残守缺还得害别人跟着擦屁股的人，我都觉得是垃圾。

项目名称：具有定制列表项的用户界面

分析代码:

一：模型层对象集合类

设计步骤如下：

1）其本身被设计为单例模式

2）在其私有构造函数中，定义一个容器类对象和N个模型层对象，循环创建并依次存入ArrayList中，初始化了一个泛型的Context对象

3）向外提供ArrayList类型的数据集合接口，方便获取其中的数据，这才是集合类本质

设计的合理性：

1）为什么采用单例模式：

其使用场景是：确保这个集合类有且只有一个对象，整个应用维护一份数据，因此整个应用只需要拥有一个全局对象，这有利于协调系统整体的行为，另外在其自行实例化过程中，也就是其构造函数中，创建了很多对象，消耗的资源是很多的，开销大。

Public class CrimeLab
{
Privatestatic CrimeLab sCrimeLab = null;
PrivateCrimeLab(){}
Public static CrimeLab getInstance()
{
If(null== sCrimeLab)
{
Synchronized(CrimeLab.class)
{
If(null == sCrimeLab) {
sCrimeLab= new CrimeLab();
}
}
}
}

}

2）为什么会创建Context：

Context c. getApplicationContext(),需要通过getApplicationContext()方法过滤一遍而不直接使用从客户端（调用方）中传递过来的context参数是因为调用的一方可能是activity也可能是service，其context的生命中国周期是绑定在当前的组件上的，销毁后在用到context会报错。而Application Context 是应用级别的，这样可以保证在应用的整个生命周期里，当我们需要用到context
时，它是一定存在的。

在对外提供的接口中进行了转化

CrimeLab.get(getActivity())

Public class CrimeLab
{
Privatestatic CrimeLab sCrimeLab = null;
PrivateCrimeLab(){}
Public static CrimeLab getInstance()
{
If(null== sCrimeLab)
{
Synchronized(CrimeLab.class)
{
If(null == sCrimeLab) {
sCrimeLab= new CrimeLab();
}
}
}
}

}

官方文档中的描述：returnthe context of the single, global Application object of the currentprocess.this generally should only be used if you need a context whose

Lifecycle isseparate from the current context,that is tied to the lifetime of the processrather than the current component .

其函数原型：

Final ActivityThreadmMainThread;
Final LoadedApkmPackageInfo;
Public ContextgetApplicationContext() {
Return (mPackageInfo ! = null ) ?mPackageInfo.getApplication() : mMainThread.getApplication();
}

Context的作用

例如：AlertDialog.Builder builder = new AlertDialog.Builder(this);传入的this就是一个context，this== Activity.this ，是这个activity的上下文，因为AlertDialog对象是依赖于一个View的，而View是和一个Activity对应的，也就是说AlertDialog应该是属于一个Activity的，在Activity销毁的时候它也就销毁了，不复存在。Activity.this作为参数传递过来，标注你要在当前的activity里创建对话框，不同的activity有其各种的上下文，不过application的上下文却只有一个。

更加参考文档：

/article/11512158.html

/article/1390930.html

3）Application 其本身也是一个符合单例模式的类，我们在设计application类时，就是这样的，比如我们来看看几个原生应用中的设计：

Public class MmsApp extendsApplication {
Private static MmsApp sMmsApp= null ;
Public void onCreate(){
Super.onCreate();
sMnsApp = this;
}
Synchronized public static MmsAppgetApplication(){
ReturnsMmsApp ;
}
}

代码如下：【插入一个文件】