一个产品，如果你不能衡量它，你就不能了解它，自然而然，你就无法改进它。数据说到底，就是这样个工具——通过数据，我们可以衡量产品，可以了解产品，可以在数据驱动下改进产品。
数据分析和数据处理本身是个非常大的领域，这里主要总结些我个人觉得比较基础且实用的部分，在日常产品工作中可以发挥比较大作用。本期主要讨论些数据分析的三个常用方法：
数据趋势分析
数据对比分析
数据细分分析
1.数据趋势分析
趋势分析般而言，适用于产品核心指标的长期跟踪，比如，点击率，GMV，活跃用户数等。做出简单的数据趋势图，并不算是趋势分析，趋势分析更多的是需要明确数据的变化，以及对变化原因进行分析。
趋势分析，较好的产出是比值。在趋势分析的时候需要明确几个概念：环比，同比，定基比。环比是指，是本期统计数据与上期比较，例如2017年2月份与2017年1月份相比较，环比可以知道较近的变化趋势，但是会有些季节性差异。为了消除季节差异，于是有了同比的概念，例如2017年2月份和2016年2月份进行比较。定基比更好理解，就是和某个基点进行比较，比如2016年1月作为基点，定基比则为2017年2月和2016年1月进行比较。
比如：2017年2月份某APP月活跃用户数我2000万，相比1月份，环比增加2%，相比去年2月份，同比增长20%。
趋势分析另个核心目的则是对趋势做出解释，对于趋势线中明显的拐点，发生了什么事情要给出合理的解释，无论是外部原因还是内部原因。
2.数据对比分析
数据的趋势变化独立的看，其实很多情况下并不能说明问题，比如如果个企业盈利增长10%，我们并无法判断这个企业的好坏，如果这个企业所处行业的其他企业普遍为负增长，则5%很多，如果行业其他企业增长平均为50%，则这是个很差的数据。
对比分析，就是给孤立的数据个合理的参考系，否则孤立的数据毫无意义。
般而言，对比的数据是数据的基本面，比如行业的情况，全站的情况等。有的时候，在产品迭代测试的时候，为了增加说服力，会人为的设置对比的基准。也就是A/Btest。
比较试验较关键的是A/B两组只保持单变量，其他条件保持致。比如测试页改版的效果，就需要保持A/B两组用户质量保持相同，上线时间保持相同，来源渠道相同等。只有这样才能得到比较有说服力的数据。
3.数据细分分析
在得到些初步结论的时候，需要进步地细拆，因为在些综合指标的使用过程中，会抹杀些关键的数据细节，而指标本身的变化，也需要分析变化产生的原因。这里的细分定要进行多维度的细拆。常见的拆分方法包括：
分时：不同时间短数据是否有变化。
分渠道：不同来源的流量或者产品是否有变化。
分用户：新注册用户和老用户相比是否有差异，高等用户和低等用户相比是否有差异。
分地区：不同地区的数据是否有变化。
组成拆分：比如搜索由搜索词组成，可以拆分不同搜索词;店铺流量由不用店铺产生，可以分拆不同的店铺。
细分分析是个非常重要的手段，多问些为什么，才是得到结论的关键，而步步拆分，就是在不断问为什么的过程。
4.小结
趋势，对比，细分，基本包含了数据分析较基础的部分。无论是数据核实，还是数据分析，都需要不断地找趋势，做对比，做细分，才能得到较终有效的结论。
人工智能、大数据、云计算和物联网的未来发展值得重视，均为前沿产业，多智时代专注于人工智能和大数据的入门和科谱，在此为你推荐几篇优质好文：

学习数据分析，需要懂统计吗？
http://www.duozhishidai.com/article-15083-1.html
怎么才能转入大数据领域 ，成为一名合格的大数据分析师
http://www.duozhishidai.com/article-14929-1.html
电商企业如何做好经营数据分析？
http://www.duozhishidai.com/article-13885-1.html
大数据分析现状是什么，主要的分析技术是什么？
http://www.duozhishidai.com/article-13338-1.html
人工智能、机器学习、数据挖掘以及数据分析有什么联系？
http://www.duozhishidai.com/article-13135-1.html


多智时代-人工智能和大数据学习入门网站|人工智能、大数据、物联网、云计算的学习交流网站



　　

前言

2010年左右，还是在上学的时候，学过一门课程叫《数据仓库与数据挖掘》，那还是属于传统数据的时代，我们会讨论什么是数据仓库？什么是数据集市？数据仓库和数据库有什么区别？等等，当我还在苦苦学习这些之时，大数据时代悄然到来，并迅速改变着各行各业。如今，十年风云际会，大数据早已成了行业绕不开的话题，这其中我们或多或少会接触到很多新兴的概念，例如数据湖、数据中台等，通过一些碎片化的学习，也是大概知道这些概念的意思，但要系统的说出这些概念之间的区别，深刻的了解其内涵，对我而言，恐怕还是困难的。所以，最近我系统的学习并总结了这些概念的含义和区别，写成本篇文章，分享给和我一样对此困惑并感兴趣的同学，希望理清这些概念的内涵和异同能对日后的工作有所帮助。

本篇文章将大体按照传统数据到大数据时代发展的时间轴介绍其中所涉及的数据概念，并以数据仓库为核心通过两两对比的方式总结其中的异同。本文属于综述性的概念科普文章，对其中所涉及到的方法论不做过多的阐述，感兴趣的同学可以查阅相关资料学习，后续，若时间允许，将陆续推出相关方法论系列介绍，同时欢迎有兴趣的同事和我一起完成。

 

1 概念介绍

本文主要介绍如下几个数据概念：



数据库

数据库是“按照数据结构来组织、存储和管理数据的仓库”。是一个长期存储在计算机内的、有组织的、有共享的、统一管理的数据集合。

数据库是以一定方式储存在一起、能与多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合，可视为电子化的文件柜——存储电子文件的处所，用户可以对文件中的数据进行新增、查询、更新、删除等操作。——百度百科

数据集市

是企业级数据仓库的一个子集，他主要面向部门级业务，并且只面向某个特定的主题，按照多维的方式进行存储，包括定义维度需要计算的指标维度的层次等，生成面向决策分析需求的数据立方体。——wikipedia

数据仓库

是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合用于支持管理决策。其主要功能是将组织透过资讯系统之联机事务处理（OLTP）经年累月所积累的大量资料，透过数据仓库理论所特有的资料存储架构，作一有系统的分析整理，以利各种分析方法如联机分析处理（OLAP）、数据挖掘（Data Mining）之进行，并进而支持如决策支持系统（DSS）、主管资讯系统（EIS）之创建，帮助决策者能快速有效的自大量资料中，分析出有价值的资讯，以利决策拟定及快速回应外在环境变动，帮助构建商业智能（BI）。——《Building the data warehouse》W.H.Inmon

数据湖

数据湖是以其自然格式存储的数据的系统或存储库，同行是对象blob或文件。数据湖通常是企业所有数据的单一存储，包括源系统数据的原始副本，以及用于报告、可视化、分析和机器学习等任务的转换数据。数据湖可以包括来自关系数据库（行和列）的结构化数据，半结构化数据（CSV，日志，XML，JSON），非结构数据（电子邮件、文档、PDF）和二进制数据（图像、音频、视频）。——wikipedia

数据平台

数据平台是在大数据基础上出现的融合了结构化和非结构化数据的数据基础平台，为业务提供服务的方式主要是直接提供数据集。——网络博客

数据中台

    “以全域大数据建设为中心，技术上覆盖整个大数据从采集、加工、服务、消费的全链路的各个环节，对内对外提供服务。丰富的大数据生态组件，构成了阿里的核心数据能力，通过大数据生态组件，可以迅速的提升数据应用的迭代能力，人人都有可能成为大数据专家。”——《阿里巴巴全域数据建设》，阿里巴巴数据技术及产品部高级技术专家张磊，2017杭州云栖大会-阿里大数据分论坛

“数据中台是聚合和治理跨域数据，将数据抽象封装成服务，提供给前台以业务价值的逻辑概念。”——《数据中台已成下一风口，它会颠覆数据工程师的工作吗？》，ThoughtWorks数据和智能总监史凯

    通俗的来看，以上六个数据概念按顺序整体呈现从小到大（指囊括的数据范围和层次），从后端到前台演变的趋势，这也反映出数据行业价值的转变。从前，IT是业务的后端，而数据是后端的后端，数据要往前走面临着巨大挑战，人们很难看到数据和价值的关系。如今，DT时代，数据通过中台直接面向业务来创造价值，数据的价值可以得到最直接的体现。

2 对比介绍

数据仓库作为数据行业发展时间轴上一以贯之的概念，它的存在见证了数据行业的发展，本文将以数据仓库为核心与其他五个概念的特性进行对比分析：



 

数据仓库VS数据库
一般来说，传统数据库是为存储而生，而数据仓库很明显，是为分析而生。

传统数据库包括增删改查，但数据仓库注重查询。而传统数据库的主要任务是执行联机事务处理（OLTP）。主要负责日常操作。而数据仓库系统在数据分析和决策方面为用户或“知识工人”提供服务，可以以不同的格式组织和提供数据，以便应付不同的需求，这种系统称作联机分析处理（OLAP）。


			
 
			
			

			
数据仓库
			
			

			
数据库
			
		

			
面向对象
			
			

			
面向市场的，用于知识工人的数据分析
			
			

			
面向顾客的，用户操作员，客户和信息技术人员的事务和查询处理
			
		

			
数据内容
			
			

			
管理大量历史数据，提供汇总和聚集机制，而且在不同的粒度层上存储和管理信息
			
			

			
管理当前数据。一般这种数据比较琐碎，很难用于决策
			
		

			
数据设计
			
			

			
系统采用星形或雪花模型和面向主题的数据库设计
			
			

			
采用实体联系数据模型和面向应用的数据库设计
			
		

			
数据视图
			
			

			
经常需要跨越数据库模式的不同版本
			
			

			
关注一个企业或部门内部的当前数据，不涉及历史数据或不同单位的数据
			
		

			
访问模式
			
			

			
大部分是只读操作
			
			

			
主要由短的原子事务组成，一般需要并发控制和恢复机制
			
		
 

相信数据仓库和数据库的区别，大家都已经有所了解，这里就不做过多的解释了。

数据仓库VS数据集市
数据集市不同于数据仓库，一般是服务于某几个部门。数据仓库向各个数据集市提供数据，且一般来讲，数据仓库的表设计符合规范化设计，而数据集市一般使用维度建模。一般有两种类型的数据集市——独立性和从属性。独立性数据集市直接从操作型环境获取数据，从属性数据集市从企业级数据仓库获取数据。

从属性数据集市结构如下图所示：



 

 上图所示的以数据仓库为基础的决策支持环境，要求数据仓库能够满足所有最终用户的需求。然而，最终用户的需求是不断变化的，而且各种类型的用户对信息的需求也不一样，这就要求数据仓库存储的数据具有充分的灵活性，能够适应各类用户的查询和分析。另一方面，最终用户对信息的需求必须易于访问，能够在较高的性能上获得结果。但是，灵活性和性能对数据仓库而言，是一对矛盾体。为了适应灵活性的要求，数据仓库需要存储各种历史数据，以规范化的模式存储（一般是第3范式）。于是，对于特定的用户，TA所需要的信息就需要在许多张很大的表上连接后得到结果，这样就无法满足用户对快速访问的性能需求。为了解决灵活性和性能之间的矛盾，数据仓库体系结构中增加了数据集市，数据集市存储为特定用户需求而预先计算好的数据，从而满足用户对性能的需求。

独立型数据集市的存在会给人造成一种错觉，似乎可以先独立地构建数据集市，当数据集市达到一定的规模可以直接转换为数据仓库，然而这是不正确的，多个独立的数据集市的累积并不能形成一个企业级的数据仓库，这是由数据仓库和数据集市本身的特点决定的。如果脱离集中式的数据仓库，独立的建立多个数据集市，企业只会又增加了一些信息孤岛，仍然不能以整个企业的视图分析数据，数据集市为各个部门或工作组所用，各个集市之间又会存在不一致性。当然，独立型数据集市是一种既成事实，为满足特定用户的需求而建立的一种分析型环境，但是，从长远的观点看，是一种权宜之计，必然会被企业级的数据仓库所取代。

数据仓库和数据集市的区别总结如下：


			
 
			
			

			
数据仓库
			
			

			
数据集市
			
		

			
数据来源
			
			

			
遗留系统、OLTP系统、外部数据
			
			

			
数据仓库
			
		

			
范围
			
			

			
企业级
			
			

			
部门级或工作组级
			
		

			
主题
			
			

			
企业主题
			
			

			
部门或特殊的分析主题
			
		

			
数据粒度
			
			

			
最细的粒度
			
			

			
较粗的粒度
			
		

			
数据结构
			
			

			
规范化结构（第3范式）
			
			

			
星型模式、雪片模式或混合模式
			
		

			
历史数据
			
			

			
大量的历史数据
			
			

			
适度的历史数据
			
		

			
优化
			
			

			
处理海量数据  数据探索
			
			

			
便于访问和分析  快速查询
			
		

			
索引
			
			

			
高度索引
			
			

			
高度索
			
		
    上文中提到诸多数据建模方法，如规范化建模、维度建模（星型模式、雪片模式、混合模式等）属于具体方法论范畴，感兴趣的同学可以查阅相关资料，便于对以上概念进行更深刻的理解。

数据仓库VS数据湖
相较而言，数据湖是较新的技术，拥有不断演变的架构。数据湖存储任何形式（包括结构化和非结构化）和任何格式（包括文本、音频、视频和图像）的原始数据。根据定义，数据湖不会接受数据治理，但专家们都认为良好的数据管理对预防数据湖转变为数据沼泽不可或缺。数据湖在数据读取期间创建模式。与数据仓库相比，数据湖缺乏结构性，而且更灵活；它们还提供了更高的敏捷性。值得一提的是，数据湖非常适合使用机器学习和深度学习来执行各种任务，比如数据挖掘和数据分析，以及提取非结构化数据等。


			
 
			
			

			
数据仓库
			
			

			
数据湖
			
		

			
类型
			
			

			
结构化数据，而且这些数据必须与数据仓库事先定义的模型吻合
			
			

			
所有类型数据，如结构化数据、半结构化、非结构化数据等，数据的类型依赖于数据源系统的原始数据格式
			
		

			
目的
			
			

			
处理结构化数据，将他们或者转换为多维数据，或者转换为报表，以满足后续的高级报表及数据分析需求
			
			

			
非常适合深度分析，包括高级数据分析、机器学习、深度学习等
			
		

			
特点
			
			

			
高性能、可重复性、持续使用
			
			

			
便于探索、创新、灵活性高
			
		
数据湖和数据仓库的差别很明显，然而在企业中两者的作用是互补的，不应认为数据湖的出现是为了取代数据仓库。

数据仓库VS数据平台
因数据仓库具有历史性，其中存储的数据大多是结构化数据，数据平台的出现解决了数据仓库不能处理非结构化数据和报表开发周期长的问题。


			
 
			
			

			
数据仓库
			
			

			
数据平台
			
		

			
数据类型
			
			

			
结构化数据
			
			

			
所有类型数据，如结构化数据、半结构化、非结构化数据等
			
		

			
服务方式
			
			

			
为业务提供服务的方式主要是分析报表
			
			

			
为业务提供的方式主要是直接提供数据集
			
		
在以上的解读中，数据平台和数据湖好像存在诸多相似性，这二者的区别个人认为应该从数据加工的角度理解，数据湖更着重对原始数据的存储，数据平台则同数据仓库一样，需对原始数据进行清洗、转换等数据处理后进行统一规范存储。

大数据时代，数据平台一般被称之为大数据平台。狭义上的大数据平台和传统数据平台的功能一致，只是技术架构和数据容量方面的不同，但广义的大数据平台通常被赋予更多的使命，它不仅存储多样化的数据类型，还具有报表分析等数据仓库的功能，以及其他数据分析挖掘方面的高级功能。

数据仓库VS数据中台
先说说数据中台，从数据中台的众多定义中我们可以总结出如下一些特点或目标：

采集并致力跨域数据
采集并加工“企业内外割裂的数据”，“治理跨域数据”，消除数据孤岛。

形成数据资产层
经过加工的数据，“实现数据资产化”形成“企业数据资产管理中枢”。各类人员可以直接从数据中台选用需要的数据。

增强“数据应用”迭代能力
提供组件化的加工能力，能够快速形成业务需要的数据产品，“可以迅速的提升数据应用的迭代能力”。

形成API化的数据服务
形成数据资产并封装成API服务后，应用和中台之间无缝衔接，形成高度自动化的数据应用流程。业务人员即使不了解大数据技术，也能实施数据驱动型的工作，“人人都有可能成为大数据专家。”

业务为驱动的数据服务
数据中台的目的是为前台业务提供服务，因此对数据的计算、加工都是以满足业务需求为目标。脱离场景的数据中台是不合理的。

数据仓库也好，传统的数据平台也好，其出发点应该说更是一个支撑性的技术系统，即一定要去考虑我有什么数据，然后我才能干什么，因此特别强调数据质量和元数据管理，而数据中台的第一出发点可不是数据，而是业务，一开始不用看你系统里面有什么数据，而是去解决你的业务问题需要什么样的数据服务。

在具体的技术处理环节，二者也有明显不同，数据的预处理流程正在从传统的ETL结构向ELT转变。传统的数据仓库集成处理架构是ETL结构，这是构建数据仓库的重要一环，即用户从数据源抽取出所需的数据，经过数据清洗，将数据加载到数据仓库中去。而大数据背景下的架构体系是ELT结构，其根据上层的应用需求，随时从数据中台中抽取想要的原始数据进行建模分析。

概括地说，二者的关键区别有以下几方面：


			
 
			
			

			
数据仓库/数据平台
			
			

			
数据中台
			
		

			
建设思想
			
			

			
以数据为驱动，自下向上
			
			

			
以业务为驱动，自上向下
			
		

			
服务方式
			
			

			
提供相关数据集或分析报表
			
			

			
API化（或其他共享方式）的数据服务
			
		

			
业务距离
			
			

			
距离业务远，用于支持管理决策分析，业务价值无法直接体现
			
			

			
距离业务近，加速企业从数据到业务价值的过程
			
		

			
使用场景
			
			

			
主要用于分析型场景
			
			

			
不仅适用于分析型，也适用于交易型等场景
			
		

			
处理结构
			
			

			
ETL结构
			
			

			
ELT结构
			
		
身处大数据行业，最后想简单的说说大数据平台和数据中台。上文中提到，广义的大数据平台是一个企业级的超融合概念，无论是数据采集、存储、处理、分析等环节在技术架构上和数据中台并无明显区别，个人认为当大数据平台满足以业务为驱动的建设模式和数据服务化的条件，大数据平台一般也可看做是数据中台。但需认识到，不少大数据平台还是属于以数据为驱动进行建设的传统数据仓库平台，以数据集中化为目标，很少考虑它的业务价值和具体业务的数据服务内容和形式，这也是直接导致不少大数据平台利用率较低或者价值较低的一个非常重要的原因。

3 总结

以上的概念是随着数据行业的发展不断涌现的新兴概念，但新兴概念的出现不是为了取代旧的概念，他们之间更多的应该是相互补充，相互融合的关系。我们不应一味的迎合潮流，强行向流行靠拢，也不应因循守旧而错失与时俱进的最佳时机。

为了更好的理解上述概念，基于个人理解将上述概念分为两个类别：一个是偏技术性数据概念，包括数据库、数据集市、数据仓库、数据湖等，另一个是偏业务性数据概念，包括大数据平台、数据中台等。以上分类可以帮助我们更好的理清他们之间的联系，偏业务性数据概念的实现或多或少会用到或融合偏技术性的数据概念或是基于技术性数据概念的架构，从这个角度出发，或许可以更好理解它们之间相互补充、相互融合的关系。例如，第三方IT研究与顾问咨询公司Gartner联袂某国内厂商发布的基于数据湖架构的大数据平台，据悉是国内首个企业级的私有云数据湖，是新一代的数据汇聚、共享、交换、开放平台。

    当我们正在感叹从数据仓库到数据湖、从数据平台到数据中台的演化如此迅速之时，其它新兴的数据概念也已悄然到来。例如数据网络（Data mesh）概念的提出，改变了数据湖或者数据仓库的集中式范式，将企业数据平台从单体式架构演进成具有微服务特性的分布式数据平台，而这种架构应该更能满足数据中台关于灵活的数据服务化的要求。数据时代发展日新月异，新兴概念层出不穷，我们唯有保持足够的学习热情并积极的思考其内在的演进逻辑才能紧跟时代前沿，创造性的解决一些难题。

以上相关概念当放在两两对比的角度总是容易从狭义且严格的定义中来找不同，实际上，在工作中，广义的理解可能更有利于工作的开展，比如数据仓库和数据集市的区别，狭义上是属于数据层次的不同，广义上当我们谈到企业级数据仓库时，个人认为把他理解为包含了众多从属性数据集市的数据仓库也是可以的。弱化一下较小且细的概念在跨专业或者工作组的沟通上，可能会更加高效和容易一些。但这一切的前提需建立在对相关概念的深刻理解之上，只有这样能才举重若轻、收放自如。

所以，以上对概念的理解应作为对日后相关工作框架性的指导，而非严格的约束，在生产过程中我们应结合企业自身特点兼顾效率，这样才能达到较好的效果，毕竟适合自己的才是最好的。

以上内容来自于网络博客和个人的观点，但均属一家之言，对于总结或者分析不对的地方，欢迎指正。

 

参考资料

1.超越数据平台！阿里推崇的数据中台到底是什么样的

https://baijiahao.baidu.com/s?id=1645427586926296393&wfr=spider&for=pc

2.辨析BI、数据仓库、数据湖和数据中台内涵及差异点(建议收藏)

https://blog.csdn.net/zhaodedong/article/details/101139388

3.数据仓库和数据集市的概念、区别与联系

https://blog.csdn.net/weixin_42575593/article/details/84763340

4.《数据资产管理实践白皮书4.0版》

5.从数据仓库到大数据，数据平台这25年是怎样进化的？

https://blog.csdn.net/weixin_30826095/article/details/96178130

6.什么是数据湖？有什么用？终于有人讲明白了……

https://blog.csdn.net/zw0Pi8G5C1x/article/details/87910161

7.Data Lake与数据仓库

https://blog.csdn.net/Tybyqi/article/details/86647607

8.数据仓库与数据湖之间有何区别？

https://my.oschina.net/hblt147/blog/3024677

9.分布式数据平台Data Mesh

https://zhuanlan.zhihu.com/p/83134986

10.基于数据湖架构的大数据平台：品高云与Gartner联合报告

https://blog.csdn.net/chuanzhongdu1/article/details/84848380

 

        经过两年的时间，终于完成对Android系统的研究了。Android是一个博大精深的系统，老罗不敢说自己精通了（事实上最讨厌的就是说自己精通神马神马的了，或者说企业说要招聘精通神马神马的人才），但是至少可以说打通了整个Android系统，从最上面的应用层，一直到最下面的Linux内核，炼就的是一种内功修养。这篇文章和大家一起分享这两年研究Android系统的历程，以此感谢大家一直以来的支持和鼓励。
《Android系统源代码情景分析》一书正在进击的程序员网（http://0xcc0xcd.com）中连载，点击进入！
        以下是本文的提纲：
        1. 理念
        2. 里程碑
        3. 看过的书
        4. 研究过的内容
        5. 将来要做的事情
        它们涵盖了老罗这两年一直想要和大家分享的内容。好了，不说废话了，直入主题。
        一. 理念
        这里说的理念是说应该带什么样的心态去研究一个系统。古人说书中自的颜如玉，书中自有黄金屋，我想说代码里也有颜如玉和黄金屋，所以老罗希望大家都能“Read The Fucking Source Code”。再者，对于优秀的开源项目来说，不去读一下它的源代码，简直就是暴殄天物啊。那么，读代码有什么好处呢？太多了，除了可以学到别人的优秀代码、架构之外，最重要的是，我们能从中找到答案，从而可以解决自己项目上的燃眉之急。
        我们在项目中碰到问题的时候，通常第一反应都是到网上去搜索答案。但是有时候有些问题，网络并不能给出满意的答案。这时候就千万不要忘了你所拥有的一个大招——从代码中找答案！当然，从代码中找答案说起来是轻松，但是等到直正去找时，可能就会发现云里雾里，根本不知道那些代码在说什么东东，甚至连自己想要看的源代码文件都不知道在哪里。这就要求平时就要养成读代码的习惯，不要临时抱佛脚。有时候临时抱佛脚是能解决问题，但是千万不能抱着这种侥幸心里，掌握一门技术还是需要踏踏实实地一步一步走。
        胡克其实在牛顿之前，就发现了万有引力定律，并且推导出了正确的公式。但由于数学不好，他只能勉强解释行星绕日的圆周运动，而没有认识到支配天体运行的力量是“万有”的。后来数学狂人牛顿用微积分圆满地解决了胡克的问题，并且把他提出的力学三条基本定律推广到了星系空间，改变了自从亚里士多德以来公认的天地不一的旧观点，被科学界奉为伟大的发现。胡克大怒，指责牛顿剽窃了他的成果。牛顿尖酸刻薄的回敬：是啊，我他妈还真是站在巨人的肩膀上呢！
        我们有理由相信像牛顿、乔布斯之类的狂人，不用站在巨人的肩膀上也能取得瞩目的成就。但是，我们不是牛顿，也不是乔布斯，所以在看代码之前，还是找一些前人总结的资料来看看吧。拿Android系统来说，你在至少得懂点Linux内核基础吧！所以在看Android源代码之前，先找些Linux内核的经典书籍来看看吧，骚年！后面老罗会推荐一些书籍给大家。
        另外，我们知道，现在的互联网产品，讲究的是快速迭代。Android系统自第一个版本发布以来，到现在已经经历了很多版本呢？那么我们应该如何去选择版本来阅读呢？一般来说，就是选择最新的版本来阅读了。不过随着又有新版本的源代码的发布，我们所看的源代码就会变成旧版本。这时候心里就会比较纠结：是应该继续看旧的代码，还是去追新版本的代码呢？就当是看连续剧，一下子跳到前面去，可能就不知道讲什么了。其实版本就算更新得再快，基础的东西也是不会轻易变化的。我们看代码时，要抱着的一个目的就是弄懂它的骨架和脉络。毕竟对于一个系统来说，它是有很多细节的，我们无法在短时间把它们都完全吃透。但是主要我们掌握了它的骨架和脉络，以后无论是要了解它的什么细节，都可以很轻轻地找到相关的源文件，并且可以很容易进入主题。
        坦白说，对于Android系统，很多细节我也不了解。所以有时候你们可以看到，在博客文章后面的评论上，有些同学问的一些比较具体的问题，我是没有回复的。一来是我不懂，二来是我也没有时间去帮这些同学去扒代码来看。这也是在文章一开头，我就说自己没有精通Android系统的原因。但是请相信，主要你熟悉Android系统的代码，并且有出现问题的现场，顺藤摸瓜跟着代码走下去，并且多一点耐心和细心，是可以解决问题的！
        关于Android版本的问题，相信大家都知道我现在的文章都是基于2.3来写的。很多同学都说我out了，现在都4.2了，甚至4.3或者5.0都要出来了，还在看2.3。我想说的是，主要你掌握了它的骨架和脉络，无论版本上怎么变化，原理都是一样的，这就是以不变应万变之道。因此，我就一直坚持研究2.3，这样可以使得前前后后研究的东西更连贯一致，避免分散了自己的精力。如果还有疑问的话，后面我讲到Android的UI架构时，就会简单对比一下4.2和2.3的不同，其实就会发现，基本原理还是一样的！
        说到Android系统的骨架和脉络，也有同学抱怨我的文章里面太多代码细节了，他们希望我可以抽象一下，用高度概括的语言或者图像来勾勒出每一个模块的轮廓。我想说的是，如果你不看代码，不了解细节，即使我能够用概括的语言或者图像来勾勒出这样的轮廓出来，也许这个轮廓只有我才能看得懂。
        我在真正开始看Android系统的源代码之前，也是有这样的想法，希望能有一张图来清楚地告诉我Android系统的轮廓，例如，HAL为什么要将驱动划分成用户空间和内核空间两部分，为什么说Binder是所有IPC机制效率最高的。我确实是从网上得到抽象的资料来解释这两个问题，但是这些资料对我来说，还是太抽象了，以至于我有似懂非懂的感觉，实际上就是不懂！就是因为这样，激发了我要从代码中找答案的念头！现在当我回过头来这些所谓抽象的轮廓时，我就清楚地知道它讲的是什么了。
        所以古人云“天将降大任于斯人也，必先苦其心志，劳其筋骨，饿其体肤”是有道理的，因为只有亲身经历过一些磨难后得到的东西才是真实的！
        好了，关于理念的问题，就完了，这里再做一下总结：
        1. 从代码中找答案——Read The Fucking Source Code。
        2. 以不变应万变——坚持看一个版本的代码直至理清它的骨架和脉络。
        二. 里程碑
        研究Android 2.3期间，主要是经历了以下五个时间点，如图1所示：

图1 研究Android 2.3的里程碑
         从2011年06月21日第一篇博客文章开始，到2013年06月03日结束对Android 2.3的研究，一共是差不多两年的时间，一个从无到有的过程。其中，最痛苦的莫过于是2011年12月下旬到2012年06月12日这6个多月的时间里面，整理了2011年12月下旬前的所有博客文章，形成了《Android系统源代码情景分析》一书，并且最终在2012年10月下旬正式上市。
        总的来说，就是在两年的时间里面，获得了以下的两个产出： 
        1. 《老罗的Android之旅》博客专栏93篇文章，1857224次访问，4156条评论，13440积分，排名154。
        2. 《Android系统源代码情景分析》一书3大篇16章，830页，1570000字。
        以上产出除了能帮助到广大的网友之外，也让自己理清了Android系统的骨架和脉络。这些骨架和脉络接下来再总结。2013年06月03日之后，将何去何从？接下来老罗也会简单说明。
        三. 看过的书 
        在2011年06月21日开始写博客之前，其实已经看过不少的书。在2011年06月21日之后，也一边写博客一边看过不少的书。这个书单很长，下面我主要分类列出一些主要的和经典的。
        语言：
        《深度探索C++对象模型》，对应的英文版是《Inside C+++ Object Model》
        程序编译、链接、加载：
        《链接器和加载器》，对应的英文版是《Linker and Loader》
        《程序员的自我修养：链接、装载和库》
        操作系统：
        《Linux内核设计与实现》，对应的英文版是《Linux Kernel Development》
        《深入理解Linux内核》，对应的英文版是《Understanding the Linux Kernel》
        《深入Linux内核架构》，对应的英文版是《Professional Linux Kernel Architecture》
        《Linux内核源代码情景分析》
         网络：
        《Linux网络体系结构：Linux内核中网络协议的设计与实现》，对应的英文版是《The Linux Networking Architecture: Design and Implementation of Network Protocols in the Linux Kernel》
        《深入理解LINUX网络技术内幕》，对应的英文版是《 Understanding Linux Network Internals》
        设备驱动：
        《Linux设备驱动程序》，对应的英文版是《Linux Device Drivers》
        《精通Linux设备驱动程序开发》，对应的英文版是《Essential Linux Device Drivers》
        虚拟机：
        《Java SE 7虚拟机规范》
        《深入Java虚拟机》，对应的英文版是《Inside the Java Virtual Machine》
        《Oracle JRockit: The Definitive Guide》
        嵌入式：
        《嵌入式Linux开发》，对应的英文版是《Embedded Linux Primer》
        《构建嵌入式Linux系统》，对应的英文版是《Building Embedded Linux Systems》
        ARM体系架构：
        《ARM嵌入式系统开发：软件设计与优化》，对应的英文版是《ARM System Developer's Guide: Designing and Optimizing System Software》
        综合：
       《深入理解计算机系统》，对应的英文版是《Computer Systems: A Programmer's Perspective》
        上面介绍的这些书，都是属于进阶级别的，所以要求要有一定的语言基础以及操作系统基础。此外，对于看书，老罗有一些观点，供大家参考：
        1. 书不是要用的时候才去看的，要养成经常看书、终身学习的习惯。
        2. 不要只看与目前自己工作相关的书，IT技术日新月异，三五年河东，三五年河西。
        3. 书看得多了，就会越看越快，学习新的东西时也越容易进入状态。
        对于Android应用开发，力推官方文档：
        http://developer.android.com/training/index.html
        http://developer.android.com/guide/components/index.html
        http://developer.android.com/tools/index.html
        四. 研究过的内容
        整个博客的内容看似松散，实际上都是有组织有计划的，目标是打通整个Android系统，从最上面的应用层，到最下面的Linux内核层。简单来说，博客的所有文章可以划分为“三横三纵”，如图2所示：

图2 Android系统研究之“三横三纵”
        接下来，老罗就分别描述这三条横线和纵线，并且给出对应的博客文章链接。
        1. 准备 -- Preparation -- 横线
        主要就是：
       （1）通过阅读相关的书籍来了解Linux内核和Android应用基础知识
         Android学习启动篇
       （2）搭建好Android源代码环境
         在Ubuntu上下载、编译和安装Android最新源代码
         在Ubuntu上下载、编译和安装Android最新内核源代码（Linux Kernel）
         如何单独编译Android源代码中的模块
         制作可独立分发的Android模拟器
       （3）Android系统有很多C++代码，这些C++代码用到了很多智能指针，因此有必要了解一下Android系统在C/C++ Runtime Framework中提供的智能指针
         Android系统的智能指针（轻量级指针、强指针和弱指针）的实现原理分析
         2. 专用驱动 -- Proprietary Drivers -- 横线
         这些专用驱动就是指Logger、Binder和Ashmem，它们整个Android系统的基石：
        （1）Logger
          浅谈Android系统开发中LOG的使用
         Android日志系统驱动程序Logger源代码分析
         Android应用程序框架层和系统运行库层日志系统源代码分析
         Android日志系统Logcat源代码简要分析
        （2）Binder
          Android进程间通信（IPC）机制Binder简要介绍和学习计划
         浅谈Service Manager成为Android进程间通信（IPC）机制Binder守护进程之路
         浅谈Android系统进程间通信（IPC）机制Binder中的Server和Client获得Service Manager接口之路
         Android系统进程间通信（IPC）机制Binder中的Server启动过程源代码分析
         Android系统进程间通信（IPC）机制Binder中的Client获得Server远程接口过程源代码分析
         Android系统进程间通信Binder机制在应用程序框架层的Java接口源代码分析
        （3）Ashmem
          Android系统匿名共享内存Ashmem（Anonymous Shared Memory）简要介绍和学习计划
          Android系统匿名共享内存Ashmem（Anonymous Shared Memory）驱动程序源代码分析
          Android系统匿名共享内存Ashmem（Anonymous Shared Memory）在进程间共享的原理分析
          Android系统匿名共享内存（Anonymous Shared Memory）C++调用接口分析
        3. 硬件抽象层 -- HAL -- 纵线
        硬件抽层象最适合用作Android系统的学习入口，它从下到上涉及到了Android系统的各个层次：
         Android硬件抽象层（HAL）概要介绍和学习计划
         在Ubuntu上为Android系统编写Linux内核驱动程序
         在Ubuntu上为Android系统内置C可执行程序测试Linux内核驱动程序
         在Ubuntu上为Android增加硬件抽象层（HAL）模块访问Linux内核驱动程序
         在Ubuntu为Android硬件抽象层（HAL）模块编写JNI方法提供Java访问硬件服务接口
         在Ubuntu上为Android系统的Application Frameworks层增加硬件访问服务
         在Ubuntu上为Android系统内置Java应用程序测试Application Frameworks层的硬件服务
        4. 应用程序组件 -- Application Component -- 纵线
        应用程序组件是Android系统的核心，为开发者提供了贴心的服务。应用程序组件有四种，分别是Activity、Service、Broadcast Receiver和Content Provider。围绕应用程序组件，又有应用程序进程、消息循环和安装三个相关模块。
       （1）Activity
         Android应用程序的Activity启动过程简要介绍和学习计划
         Android应用程序启动过程源代码分析
         Android应用程序内部启动Activity过程（startActivity）的源代码分析
         Android应用程序在新的进程中启动新的Activity的方法和过程分析
         解开Android应用程序组件Activity的"singleTask"之谜
       （2）Service
         Android系统在新进程中启动自定义服务过程（startService）的原理分析
         Android应用程序绑定服务（bindService）的过程源代码分析
       （3）Broadcast Receiver
         Android系统中的广播（Broadcast）机制简要介绍和学习计划
         Android应用程序注册广播接收器（registerReceiver）的过程分析
         Android应用程序发送广播（sendBroadcast）的过程分析
       （4）Content Provider
         Android应用程序组件Content Provider简要介绍和学习计划
         Android应用程序组件Content Provider应用实例
         Android应用程序组件Content Provider的启动过程源代码分析
         Android应用程序组件Content Provider在应用程序之间共享数据的原理分析
         Android应用程序组件Content Provider的共享数据更新通知机制分析
       （5）进程
         Android系统进程Zygote启动过程的源代码分析
         Android应用程序进程启动过程的源代码分析
       （6）消息循环
         Android应用程序消息处理机制（Looper、Handler）分析
         Android应用程序键盘（Keyboard）消息处理机制分析
         Android应用程序线程消息循环模型分析
       （7）安装
         Android应用程序安装过程源代码分析
         Android系统默认Home应用程序（Launcher）的启动过程源代码分析
        5. 用户界面架构 -- UI -- 纵线
        大家对老罗现在还在写Android 2.3的UI架构意见最大，认为已经过时了。老罗认为持有这种观点的人，都是没有经过认真思考的。老罗承认，从Android 4.0开始，UI部分发生了比较大的变化。但是请注意，这些变化都是在Android  2.3的UI架构基础之上进行的，也就是说，Android  2.3的UI架构并没有过时。你不能说Android 4.0在Android  2.3之上增加了一些feature，就说Android  2.3过时了。
        下面这张是从Android官网拿过来的最新UI渲染流程图，也就是4.2的UI渲染流程图：

图2 Android 4.2的UI渲染流程
        从这张图可以看出关于Android的UI架构的三条主线：
      （1）每一个Window的Surface都怎样渲染的？不管怎么样，最后渲染出来的都是一个Buffer，交给SurfaceFlinger合成到Display上。
      （2）SurfaceFlinger是怎样合成每一个Window的Surface的？
      （3）WindowManamgerService是怎么样管理Window的？ 
        第（1）和第（2）两个点在2.3和4.2之间有变化，主要是因为增加了GPU的支持，具体就表现为Window的Surface在渲染的时候使用了GPU，而SurfaceFlinger在合成每一个Window的Surface的时候，也使用了GPU或者Overlay和Blitter这些硬件加速，但是主体流程都没有变，也就是说，Window的Surface渲染好之后，最终依然是交给SurfaceFlinger来合成。此外，虽然我还没有开始看4.2的代码，但是可以看得出，4.2里面的HWComposer，只不过是封装和抽象了2.3就有的Overlay和Blitter，而SurfaceTexture的作用与2.3的SurfaceComposerClient、SurfaceControl也是类似的。第（3）点基本上就没有什么变化，除非以后要支持多窗口。
        通过上述对比，只想强调一点：Android 2.3的UI架构并没有过时，是值得去研究的，并且在2.3的基础上去研究4.2的UI架构，会更有帮助。
        仁者见仁，智者见智，Android 2.3的UI架构的说明就到此为止，接下来它的分析路线，都是围绕上述三个点来进行的。
        首先是以开机动画为切入点，了解Linux内核里面的驱动：
        Android系统的开机画面显示过程分析
        FB驱动抽象了显卡，上面的用户空间程序就是通过它来显示UI的。
        HAL层的Gralloc模块对FB驱动进行了封装，以方便SurfaceFlinger对它进行访问：
        Android帧缓冲区（Frame Buffer）硬件抽象层（HAL）模块Gralloc的实现原理分析
        SurfaceFlinger负责合成各个应用程序窗口的UI，也就是将各个窗口的UI合成，并且通过FB显示在屏幕上。在对SurfaceFlinger进行分析之前，我们首先了解应用程序是如何使用的它的：
        Android应用程序与SurfaceFlinger服务的关系概述和学习计划
        Android应用程序与SurfaceFlinger服务的连接过程分析
        Android应用程序与SurfaceFlinger服务之间的共享UI元数据（SharedClient）的创建过程分析
        Android应用程序请求SurfaceFlinger服务创建Surface的过程分析
        Android应用程序请求SurfaceFlinger服务渲染Surface的过程分析
        万事俱备，可以开始分析SurfaceFlinger了：
        Android系统Surface机制的SurfaceFlinger服务简要介绍和学习计划
        Android系统Surface机制的SurfaceFlinger服务的启动过程分析
        Android系统Surface机制的SurfaceFlinger服务对帧缓冲区（Frame Buffer）的管理分析
        Android系统Surface机制的SurfaceFlinger服务的线程模型分析
        Android系统Surface机制的SurfaceFlinger服务渲染应用程序UI的过程分析
        SurfaceFlinger操作的对象是应用程序窗口，因此，我们要掌握应用程序窗口的组成：
        Android应用程序窗口（Activity）实现框架简要介绍和学习计划
        Android应用程序窗口（Activity）的运行上下文环境（Context）的创建过程分析
        Android应用程序窗口（Activity）的窗口对象（Window）的创建过程分析
        Android应用程序窗口（Activity）的视图对象（View）的创建过程分析
        Android应用程序窗口（Activity）与WindowManagerService服务的连接过程分析
        Android应用程序窗口（Activity）的绘图表面（Surface）的创建过程分析
        Android应用程序窗口（Activity）的测量（Measure）、布局（Layout）和绘制（Draw）过程分析
        应用程序窗口是由WindowManagerService进行管理的，并且也是WindowManagerService负责提供窗口信息给SurfaceFlinger的，因此，我们最后分析WindowManagerService：
        Android窗口管理服务WindowManagerService的简要介绍和学习计划
        Android窗口管理服务WindowManagerService计算Activity窗口大小的过程分析
        Android窗口管理服务WindowManagerService对窗口的组织方式分析
        Android窗口管理服务WindowManagerService对输入法窗口（Input Method Window）的管理分析
        Android窗口管理服务WindowManagerService对壁纸窗口（Wallpaper Window）的管理分析
        Android窗口管理服务WindowManagerService计算窗口Z轴位置的过程分析
        Android窗口管理服务WindowManagerService显示Activity组件的启动窗口（Starting Window）的过程分析
        Android窗口管理服务WindowManagerService切换Activity窗口（App Transition）的过程分析
        Android窗口管理服务WindowManagerService显示窗口动画的原理分析
        上述内容都研究清楚之后，Android系统的UI架构的骨架就清晰了。但是前面所研究的应用程序窗口还是太抽象了，我们有必要研究一下那些组成应用程序窗口内容的UI控件是怎么实现的，以TextView和SurfaceView为代表：
        Android控件TextView的实现原理分析
        Android视图SurfaceView的实现原理分析
        最后，分析Android系统的UI架构，怎能不提它的资源管理框架？它有效地分离了代码和UI：
        Android资源管理框架（Asset Manager）简要介绍和学习计划
        Android应用程序资源的编译和打包过程分析
        Android应用程序资源管理器（Asset Manager）的创建过程分析
        Android应用程序资源的查找过程分析
        分析这里，Android系统的UI架构就分析完成了，看出什么门道来没有？是的，我们以开机动画为切入点，从Linux内核空间的FB驱动，一直分析到用户空间中HAL层模块Gralloc、C/C++ Runtime Framework层的SurfaceFlinger、Java Runtime Framework层的WindowMangerService、Window、Widget，以及资源管理框架，从下到上，披荆斩棘。
        6. Dalvik虚拟机 -- 横线
        Android系统的应用程序及部分应用程序框架是使用Java语言开发的，它们运行在Dalvik虚拟机之上，还有另外一部分应用唾弃框架在使用C/C++语言开发的。使用Java语言开发的应用程序框架老罗称之为Java Runtime Framework，而使用C/C++语言开发的应用程序框架老罗称之为C/C++ Runtime Framework，它们被Dalvik虚拟机一分为二。通过前面的学习，其实我们都已经了解Android系统的Java Runtime Framework和C/C++ Runtime Framework，因此，我们最后将注意力集中在Dalvik虚拟机上：
        Dalvik虚拟机简要介绍和学习计划
        Dalvik虚拟机的启动过程分析
        Dalvik虚拟机的运行过程分析
        Dalvik虚拟机JNI方法的注册过程分析
        Dalvik虚拟机进程和线程的创建过程分析
        学习完成“三横三纵”这六条主线之后，我们就可以自豪地说，从上到下地把Android系统打通，并且将它的骨架和脉络也理清了！
        对于“准备”、“专用驱动”、“HAL”、“应用程序组件”这四条主线，老罗极力推荐大家看《Android系统源代码情况分析》一书，内容比博客文章要系统、详细很多，不说其它的，就单单是讲Binder进程间通信机制的那一章，就物超所值。在《Android系统源代码情景分析》一书中，老罗最引以为豪的就是讲Binder进程间通信机制的第5章，网上或者其它书上绝对是找不到这么详尽的分析资料。
        五. 将来要做的事情
        接下来要做的主要是三件事情：
        1. 继续研究Android系统
        本来以为前段时间的Google I/O会发布Android 4.3或者5.0，然后老罗就以最新发布的版本为蓝本来进行研究。既然没有发布新版本，那么就只有以现在的最新发布版本4.2为蓝本进行研究了。如前所述，4.2与2.3相比，最大的不同之处是默认增加了GPU支持，因此，老罗在接下来的一段时间里，将着重研究4.2的GPU支持。
        2. 停止博客更新
        这两年投入在博客上的精力太多了，博客上的文章基本上熬夜熬出来的。大多数时候，一个话题要花一个星期左右的时间来看代码，然后再花四个星期左右的时间将文章写出来。本来是这样计划的，依靠《Android系统源代码情景分析》一书的销量，可以在经济上得到一定的回报，然后可以继续在博客上投入，直至把4.x版本的GPU支持写完，最后再整理出一本关于Android系统UI架构的书。但是最近询问了一下书的销量，差强人意，达不到预期目标。由于没有形成良性循环，因此没有办法，只好停止博客更新。老罗需要把精力投入在其它事情上，希望大家谅解！
        3. 仍然会持续地进行一些小分享
        主要是一些随笔分享，这些分享主要会发布在微博或者QQ群上面，那里也方便一些和大家进行讨论。此外，老罗也乐意和大家进行一些线下分享，主要针对企业或者单位组织的沙龙、活动和会议等，同时也可以单独地针对企业内部进行分享。不过前提当然是举办方对《老罗的Android之旅》专栏或者《Android系统源代码情景分析》一书的内容感兴趣，并且邀请老罗去参加。
        如果需要邀请老罗去参加分享，可以通过微博或者邮箱和老罗联系，非常感谢大家两年以来的支持！
        邮箱：shyluo@gmail.com
        微博：http://weibo.com/shengyangluo
        

package rmd_pms_web;

import java.util.ArrayList;
import java.util.Arrays;
import java.util.HashSet;
import java.util.List;

/**
 * @Description: 两个list对比，查出增加，删除的数据然后去重
 * @date 2017年8月17日
 */
public class Test {
	 
    public static void main(String[] args) {
    	List<Integer> arr = new ArrayList<Integer>();
    	
        List<Integer> a = Arrays.asList(1, 2, 3, 4,6);
        List<Integer> b = Arrays.asList(4, 3, 2, 1,9);
        
        //增加的元素组成的列表
        List<Integer> aList= getAddaListThanbList(a, b);
        for (Integer integer : aList) {
        	 System.out.println("增加的元素："+integer);
		}
        
        //减少的元素组成的列表
        List<Integer> bList= getReduceaListThanbList(a, b);
        for (Integer integer : bList) {
        	 System.out.println("减少的元素："+integer);
		}
        
        //封装
        arr.addAll(a);
        arr.addAll(b);
        arr.addAll(aList);
        arr.addAll(bList);
        
        
        //去重
        cleanDisRepet(arr);
        
        for (Integer integer : arr) {
        	 System.out.println("全部元素："+integer);
		}
    }
    
    /**
     * @Description: 计算列表aList相对于bList的增加的情况，兼容任何类型元素的列表数据结构
     * @param aList 本列表
     * @param bList 对照列表
     * @return 返回增加的元素组成的列表
     */
    public static <E> List<E> getAddaListThanbList(List<E> aList, List<E> bList){
        List<E> addList = new ArrayList<E>();
        for (int i = 0; i < aList.size(); i++){
            if(!myListContains(bList, aList.get(i))){
                addList.add(aList.get(i));
            }
        }
        return addList;
    }
    
    /**
     * @Description: 计算列表aList相对于bList的减少的情况，兼容任何类型元素的列表数据结构
     * @param aList 本列表
     * @param bList 对照列表
     * @return 返回减少的元素组成的列表
     */
    public static <E> List<E> getReduceaListThanbList(List<E> aList, List<E> bList){
        List<E> reduceaList = new ArrayList<E>();
        for (int i = 0; i < bList.size(); i++){
            if(!myListContains(aList, bList.get(i))){
                reduceaList.add(bList.get(i));
            }
        }
        return reduceaList;
    }
    
    
    /**
     * @Description: 判断元素element是否是sourceList列表中的一个子元素
     * @param sourceList 源列表
     * @param element 待判断的包含元素
     * @return 包含返回 true，不包含返回 false
     */
    private static <E> boolean myListContains(List<E> sourceList, E element) {
        if (sourceList == null || element == null){
            return false;
        }
        if (sourceList.isEmpty()){
            return false;
        }
        for (E tip : sourceList){
            if(element.equals(tip)){
                return true;
            }
        }
        return false;
    }
    
    /**
     * @Description: 去除list重复数据
     * @param list
     * @return list
     */
    public static <E> List<E> cleanDisRepet(List<E> list){
    	 HashSet h = new HashSet(list);   
    	 list.clear();   
    	 list.addAll(h); 
		return list;
    }
  
}