21.数据的存储方式
- File 存储
- SharedPreference 存储
- ContentProvider 存储
- SQLiteDataBase 存储
- 网络存储
22.数据的加密方式
1.MD5(这种方法不推荐使用了,网上都能直接找到相应的明文)
MD5英文全称“Message-Digest Algorithm 5”，翻译过来是“消息摘要算法5”，由MD2、MD3、MD4演变过来的，是一种单向加密算法，是不可逆的一种的加密方式。
具体可参考:Android数据加密之MD5加密
2.Android数据加密之Base64编码算法
平时开发中遇见的各种数据加密方式，最终都会对加密后的二进制数据进行Base64编码，起到一种二次加密的效果，其实呢Base64从严格意义上来说的话不是一种加密算法，而是一种编码算法，为何要使用Base64编码呢？
Base64是网络上最常见的用于传输8Bit字节代码的编码方式之一，Base64并不是安全领域的加密算法，其实Base64只能算是一个编码算法，对数据内容进行编码来适合传输。标准Base64编码解码无需额外信息即完全可逆，即使你自己自定义字符集设计一种类Base64的编码方式用于数据加密，在多数场景下也较容易破解。Base64编码本质上是一种将二进制数据转成文本数据的方案。对于非二进制数据，是先将其转换成二进制形式，然后每连续6比特（2的6次方=64）计算其十进制值，根据该值在A–Z,a–z,0–9,+,/ 这64个字符中找到对应的字符，最终得到一个文本字符串。基本规则如下几点：
标准Base64只有64个字符（英文大小写、数字和+、/）以及用作后缀等号；
Base64是把3个字节变成4个可打印字符，所以Base64编码后的字符串一定能被4整除（不算用作后缀的等号）；
等号一定用作后缀，且数目一定是0个、1个或2个。这是因为如果原文长度不能被3整除，Base64要在后面添加\0凑齐3n位。为了正确还原，添加了几个\0就加上几个等号。显然添加等号的数目只能是0、1或2；
严格来说Base64不能算是一种加密，只能说是编码转换。
具体可参考:Android数据加密之Base64编码算法
3.异或加密
异或运算中，如果某个字符（或数值）x 与 一个数值m 进行异或运算得到y，则再用y 与 m 进行异或运算就可以还原为 x ，因此应用这个原理可以实现数据的加密解密功能。
具体可参考:Android数据加密之异或加密算法
4.DES
DES是一种对称加密算法，所谓对称加密算法即：加密和解密使用相同密钥的算法。DES加密算法出自IBM的研究，
后来被美国政府正式采用，之后开始广泛流传，但是近些年使用越来越少，因为DES使用56位密钥，以现代计算能力，
24小时内即可被破解。
具体可参考:Android数据加密之Des加密
5.AES
高级加密标准（英语：Advanced Encryption Standard，缩写：AES），在密码学中又称Rijndael加密法，是美国联邦政府采用的一种区块加密标准。这个标准用来替代原先的DES，已经被多方分析且广为全世界所使用。
具体可参考:Android数据加密之Aes加密
6.RSA
RSA算法是最流行的公钥密码算法，使用长度可以变化的密钥。RSA是第一个既能用于数据加密也能用于数字签名的算法。
RSA算法原理如下：
1.随机选择两个大质数p和q，p不等于q，计算N=pq；
2.选择一个大于1小于N的自然数e，e必须与(p-1)(q-1)互素。
3.用公式计算出d：d×e = 1 (mod (p-1)(q-1)) 。
4.销毁p和q。
最终得到的N和e就是“公钥”，d就是“私钥”，发送方使用N去加密数据，接收方只有使用d才能解开数据内容。
RSA的安全性依赖于大数分解，小于1024位的N已经被证明是不安全的，而且由于RSA算法进行的都是大数计算，使得RSA最快的情况也比DES慢上倍，这是RSA最大的缺陷，因此通常只能用于加密少量数据或者加密密钥，但RSA仍然不失为一种高强度的算法。
具体可参考:Android数据加密之Des加密
7.so文件加密
将一些重要信息代码放到native层，主要因为native层的逆向分析的难度更大，而且代码执行效率高，对性能影响小。
23.Xml和Json
XML
XML的优点
A.格式统一，符合标准；
B.容易与其他系统进行远程交互，数据共享比较方便。
XML的缺点
A.XML文件庞大，文件格式复杂，传输占带宽；
B.服务器端和客户端都需要花费大量代码来解析XML，导致服务器端和客户端代码变得异常复杂且不易维护；
C.客户端不同浏览器之间解析XML的方式不一致，需要重复编写很多代码；
D.服务器端和客户端解析XML花费较多的资源和时间。
解析方式:
A.DOM解析器
B.SAX解析器
C.PULL解析器
PULL解析器小巧轻便，解析速度快，简单易用，非常适合在Android移动设备中使用，Android系统内部在解析各种XML时也是用PULL解析器。主要使用XmlPullParser这个类.
Json
JSON的优点：
A.数据格式比较简单，易于读写，格式都是压缩的，占用带宽小；
B.易于解析，客户端JavaScript可以简单的通过eval()进行JSON数据的读取；
C.支持多种语言，包括ActionScript, C, C#, ColdFusion, Java, JavaScript, Perl, PHP, Python, Ruby等服务器端语言，便于服务器端的解析；
D.在PHP世界，已经有PHP-JSON和JSON-PHP出现了，偏于PHP序列化后的程序直接调用，PHP服务器端的对象、数组等能直接生成JSON格式，便于客户端的访问提取；
E.因为JSON格式能直接为服务器端代码使用，大大简化了服务器端和客户端的代码开发量，且完成任务不变，并且易于维护。
JSON的缺点
A.没有XML格式这么推广的深入人心和喜用广泛，没有XML那么通用性；
B.JSON格式目前在Web Service中推广还属于初级阶段。
解析方式:
A.传统的使用JSONObject进行解析
B.Gson
C.FastJson
XML和JSON的优缺点对比
(1).可读性方面。
JSON和XML的数据可读性基本相同，JSON和XML的可读性可谓不相上下，一边是建议的语法，一边是规范的标签形式，XML可读性较好些。
(2).可扩展性方面。
XML天生有很好的扩展性，JSON当然也有，没有什么是XML能扩展，JSON不能的。
(3).编码难度方面。
XML有丰富的编码工具，比如Dom4j、JDom等，JSON也有json.org提供的工具，但是JSON的编码明显比XML容易许多，即使不借助工具也能写出JSON的代码，可是要写好XML就不太容易了。
(4).解码难度方面。
XML的解析得考虑子节点父节点，让人头昏眼花，而JSON的解析难度几乎为0。这一点XML输的真是没话说。
(5).流行度方面。
XML已经被业界广泛的使用，而JSON才刚刚开始，但是在Ajax这个特定的领域，未来的发展一定是XML让位于JSON。到时Ajax应该变成Ajaj(Asynchronous Javascript and JSON)了。
(6).解析手段方面。
JSON和XML同样拥有丰富的解析手段。
(7).数据体积方面。
JSON相对于XML来讲，数据的体积小，传递的速度更快些。
(8).数据交互方面。
JSON与JavaScript的交互更加方便，更容易解析处理，更好的数据交互。
(9).数据描述方面。
JSON对数据的描述性比XML较差。
(10).传输速度方面。
JSON的速度要远远快于XML。
24.网络请求
25.MVC、MVP
26.Android屏幕适配方案
27.界面卡顿的原因
Android系统每隔16ms会发出信号重绘我们的界面(Activity).
为什么是16ms, 因为Android设定的刷新率是60FPS(Frame Per Second), 也就是每秒60帧的刷新率, 约合16ms刷新一次.
例如, 假设我们更新屏幕的背景图片, 需要24ms来做这次运算. 当系统在第一个16ms时刷新界面, 然而我们的运算还没有结束, 无法绘出图片. 当系统隔16ms再发一次VSYNC信息重绘界面时, 用户才会看到更新后的图片. 也就是说用户是32ms后看到了这次刷新(注意, 并不是24ms). 这就是传说中的丢帧(dropped frame),丢帧给用户的感觉就是卡顿, 而且如果运算过于复杂, 丢帧会更多, 导致界面常常处于停滞状态, 卡到爆.
原因:
1.过于复杂的布局(UI布局层次太深,即布局嵌套太多了, 或是自定义控件的onDraw中有复杂运算)
2.过度绘制(Overdraw)
绘制了多重背景.
绘制了不可见的UI元素.
3.UI线程的复杂运算
4.频繁的GC
执行GC操作的时候，任何线程的任何操作都会需要暂停，等待GC操作完成之后，其他操作才能够继续运行, 故而如果程序频繁GC, 自然会导致界面卡顿.
具体参考:Android App优化之消除卡顿
28.JVM的内存分布及垃圾回收机制
29.哪些情况会导致OOM？
30.ANR发生的情况及如何避免
ANR全名Application Not Responding, 也就是”应用无响应”. 当操作在一段时间内系统无法处理时, 系统层面会弹出ANR对话框.
原因:
1.5s内无法响应用户输入事件(例如键盘输入, 触摸屏幕等).
2.BroadcastReceiver在10s内无法结束.
造成以上两种情况的首要原因就是在主线程(UI线程)里面做了太多的阻塞耗时操作, 例如文件读写, 数据库读写, 网络查询等等.所以解决方法就是不要在主线程(UI线程)里面做繁重的操作.
具体可参考:Android App优化之ANR详解
31.内存泄漏
32.第三方框架
1.Volley
2.Glide的源码
3.Okhttp的源码
4.Retrofit的源码
5.Rxjava的源码
33.热更新
1.AndFix
Github上提交不活跃了,不过阿里百川HotFix提供了更为简便方案,具体请点以下网站:
2.Tinker
3.Robust
新一代热更新系统Robust，对Android版本无差别兼容。无需发版就可以做到随时修改线上bug，快速对重大线上问题作出反应，补丁修补成功率高达99.9%。
优势
支持Android2.3-7.X版本
高兼容性、高稳定性，修复成功率高达三个九
补丁下发立即生效，不需要重新启动
支持方法级别的修复，包括静态方法
支持增加方法和类
支持ProGuard的混淆、内联、优化等操作
4.Amigo
5.Aceso
关于热更新的对比可参考以下文章:
Android 热修复专题：支付宝、淘宝、微信、QQ空间、饿了么、美丽说蘑菇街、美团大众点评方案集合
34.Http、Https相关知识
35.谈谈对Socket的理解
两类传输协议：TCP、UDP
TCP是Tranfer Control Protocol的 简称，是一种面向连接的保证可靠传输的协议。通过TCP协议传输，得到的是一个顺序的无差错的数据流。发送方和接收方的成对的两个socket之间必须建 立连接，以便在TCP协议的基础上进行通信，当一个socket（通常都是server socket）等待建立连接时，另一个socket可以要求进行连接，一旦这两个socket连接起来，它们就可以进行双向数据传输，双方都可以进行发送 或接收操作。
UDP是User Datagram Protocol的简称，是一种无连接的协议，每个数据报都是一个独立的信息，包括完整的源地址或目的地址，它在网络上以任何可能的路径传往目的地，因此能否到达目的地，到达目的地的时间以及内容的正确性都是不能被保证的。
比较：
UDP：
1.每个数据报中都给出了完整的地址信息，因此无需要建立发送方和接收方的连接。
2.UDP传输数据时是有大小限制的，每个被传输的数据报必须限定在64KB之内。
3.UDP是一个不可靠的协议，发送方所发送的数据报并不一定以相同的次序到达接收方
TCP：
1.面向连接的协议，在socket之间进行数据传输之前必然要建立连接，所以在TCP中需要连接时间。
2.TCP传输数据大小限制，一旦连接建立起来，双方的socket就可以按统一的格式传输大的数据。
3.TCP是一个可靠的协议，它确保接收方完全正确地获取发送方所发送的全部数据。
应用：
1.TCP在网络通信上有极强的生命力，例如远程连接（Telnet）和文件传输（FTP）都需要不定长度的数据被可靠地传输。但是可靠的传输是要付出代价的，对数据内容正确性的检验必然占用计算机的处理时间和网络的带宽，因此TCP传输的效率不如UDP高。
2.UDP操作简单，而且仅需要较少的监护，因此通常用于局域网高可靠性的分散系统中client/server应用程序。例如视频会议系统，并不要求音频视频数据绝对的正确，只要保证连贯性就可以了，这种情况下显然使用UDP会更合理一些。
什么是Socket
网络上的两个程序通过一个双向的通讯连接实现数据的交换，这个双向链路的一端称为一个Socket。Socket通常用来实现客户方和服务方的连接。Socket是TCP/IP协议的一个十分流行的编程界面，一个Socket由一个IP地址和一个端口号唯一确定。
但是，Socket所支持的协议种类也不光TCP/IP一种，因此两者之间是没有必然联系的。在Java环境下，Socket编程主要是指基于TCP/IP协议的网络编程。
Socket通讯的过程
Server端Listen(监听)某个端口是否有连接请求，Client端向Server 端发出Connect(连接)请求，Server端向Client端发回Accept（接受）消息。一个连接就建立起来了。Server端和Client 端都可以通过Send，Write等方法与对方通信。
对于一个功能齐全的Socket，都要包含以下基本结构，其工作过程包含以下四个基本的步骤：
1） 创建Socket；
2） 打开连接到Socket的输入/出流；
3） 按照一定的协议对Socket进行读/写操作；
4） 关闭Socket.（在实际应用中，并未使用到显示的close，虽然很多文章都推荐如此，不过在我的程序中，可能因为程序本身比较简单，要求不高，所以并未造成什么影响。）
具体使用可参考:
读懂Java中的Socket编程
36.设计模式
1.单例模式
2.工厂模式
3.观察者模式
37.版本控制SVN、Git
本文还未整理完成,会继续整理
