1. DNS劫持是什么；解决办法。
又称域名劫持，是指在特定网络下，拦截所有域名解析请求，返回假的或不可用的网址。
解决办法：
1. 手动修改路由DNS地址和密码；
2. 使用 HTTPDNS解决：
区别：
a. DNS协议建立在UDP之上，53端口；HTTPDNS协议建立在http之上，80端口.
b. 速度快(多次转发、绕路)，域名解析失败率底,绕过运营商的 Local DNS ，避免域名劫持。
c. 访问过程如下图：
解决方法：
a. 使用阿里云、腾讯云、新浪等提供的HTTPDNS服务；
b. 使用可以定制DNS逻辑的网路库，如okhttp.
private static class MyDns implements Dns { @Override public List<InetAddress> lookup(String hostname) throws UnknownHostException { List<String> strIps = HttpDns.getInstance().getIpByHost(hostname); // !!! 注意 List<InetAddress> ipList; if (strIps != null && strIps.size() > 0) { ipList = new ArrayList<>(); for (String ip : strIps) { ipList.add(InetAddress.getByName(ip)); } } else { ipList = Dns.SYSTEM.lookup(hostname); } return ipList; } } private OkHttp3Utils() { okhttp3.OkHttpClient.Builder builder = new okhttp3.OkHttpClient.Builder(); builder.dns(new MyDns()); mOkHttpClient = builder.build(); }
4. 推荐文章
基础知识： http://www.cnblogs.com/softidea/p/5325162.html
okhttp: http://blog.csdn.net/sbsujjbcy/article/details/51612832
2. Android 兼容性(屏幕适配)
1. 支持各种屏幕尺寸
使用wrap_content、match_parent、weight
android:layout_weight的真实含义是:如果View设置了该属性并且有效，那么该 View的宽度等于原有宽度(android:layout_width)加上剩余空间的占比。
2. 使用相对布局，禁用绝对布局
3. 使用限定符
a. 使用尺寸限定符
例如： 双面板布局 /res/layout/main.xml /res/layout-large/main.xml
b. 使用最小宽度限定符
例如： /res/layout/main.xml /res/layout-sw600dp/main.xml
c. 使用别名布局
res/values-large/layout.xml:
res/values-sw600dp/layout.xml:
4. 使用屏幕方向限定符
-
小屏幕，纵向：单面板，带徽标
-
小屏幕，横向：单面板，带徽标
-
7 英寸平板电脑，纵向：单面板，带操作栏
-
7 英寸平板电脑，横向：双面板，宽，带操作栏
-
10 英寸平板电脑，纵向：双面板，窄，带操作栏
-
10 英寸平板电脑，横向：双面板，宽，带操作栏
-
电视，横向：双面板，宽，带操作栏
5. 使用自动拉伸位图
.9的制作，实际上就是在原图片上添加1px的边界，然后按照我们的需求，把对应的位置设置成黑色线，系统就会根据我们的实际需求进行拉伸。
6. 支持各种屏幕密度
a. 使用密度无关像素 dp、sp(配合权重)
当然，我们尽量使用match_parent和wrap_content，尽可能少的用dp来指定控件的具体长宽，再结合上权重，大部分的情况我们都是可以做到适配的。
b. 提供多种位图
-
xhdpi：2.0
-
hdpi：1.5
-
mdpi：1.0（最低要求）
-
ldpi：0.75
7. 实施自适应用户界面流程
根据当前布局，选择适当界面流程
a. 确定当前布局
b. 根据当前布局做出响应
c. 重复使用其他活动中的片段
最佳实践
关于高清设计图尺寸
Google官方给出的高清设计图尺寸有两种方案，一种是以mdpi设计，然后对应放大得到更高分辨率的图片，另外一种则是以高分辨率作为设计大小，然后按照倍数对应缩小到小分辨率的图片。
根据经验，我更推荐第二种方法，因为小分辨率在生成高分辨率图片的时候，会出现像素丢失，我不知道是不是有方法可以阻止这种情况发生。
而分辨率可以以1280*720或者是1960*1080作为主要分辨率进行设计。
ImageView的ScaleType属性
设置不同的ScaleType会得到不同的显示效果，一般情况下，设置为centerCrop能获得较好的适配效果。
动态设置
有一些情况下，我们需要动态的设置控件大小或者是位置，比如说popwindow的显示位置和偏移量等，这个时候我们可以动态的获取当前的屏幕属性，然后设置合适的数值
|
1
2
3
4
5
6
7
8
9
10
11
|
public class ScreenSizeUtil { public static int getScreenWidth(Activity activity) { return activity.getWindowManager().getDefaultDisplay().getWidth(); } public static int getScreenHeight(Activity activity) { return activity.getWindowManager().getDefaultDisplay().getHeight(); }} |
推荐文章：
http://www.cocoachina.com/android/20151030/13971.html
http://www.cnblogs.com/qishuai/p/7605549.html
3. OOP设计原则(核心基础原则或架构或设计模式铺垫)
a. 面向对象7大设计原则
OOP的方法论（高内聚、低耦合、易复用）
1. 开闭原则(Open-Closed Principle,OCP).
软件实体应当扩展开放、修改封闭。
这是面向对象设计（OOD）的基石，也是最重要的原则。
实现：合理划分构件，一种可变性不应当散落在代码的很多角落里，而应当封装到一个对象里；一种可变现不应当与另一种可变性混合在一起。
2. 依赖倒置原则(Dependency Inversion Principle,DIP)
摆脱面向过程编程思想中高层模块依赖于底层实现，抽象依赖于具体细节。OOP要做到的是，高层模块不依赖于底层模块，两者都依赖于抽象；抽象不依赖具体实现细节，细节依赖抽象。
实现：应该通过抽象解耦的方式，是具体类最多可能的仅与抽象类(接口)发生耦合；程序在需要引用一个对象时，应当尽可能的使用抽象类型作为变量的静态类型，这是针对接口编程的含义。
3. 里氏替换原则(Liskov Substitution Principle, LSP)
继承思想的基石.“只有当衍生类可以替换掉基类，软件功能不会受影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。”
4. 接口隔离原则(Interface Insolation Principle,ISP)
接口功能单一，避免污染.
实现： 一个类对另外一个类的依赖性应当建立在最小的接口上的。使用多个专门的接口比使用单一的总接口更好。
5. 单一职责原则(Single Resposibility Principle,SRP)
就一个类而言，应该仅有一个引起他变化的原因，如果一个类的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能抑制这个类完成其他职责的能力。
6. 合成/聚合复用原则(Composite/Aggregate Reuse Principle,CARP)
设计模式告诉我们对象委托优于类继承，从UML的角度讲，就是关联优于继承关系，尽量使用合成/聚合、尽量不使用继承.
实现：在一个新的对象里面使用一些已有的对象，是之成为新对象的一部分，以整合其功能。
7. 迪米特原则或最少知识原则(Low Of Demeter or Priniciple of Least Kenwledge)
就是说一个对象应当对其他对象尽可能少的了解。即只直接与朋友通信，或者通过朋友和陌生人通信。
朋友的定义（或关系）：
（1）当前对象本身。
（2）以参量的形式传入到当前对象方法中的对象。
（3）当前对象的实例变量直接引用的对象。
（4）当前对象的实例变量如果是一个聚集，那么聚集中的元素也都是朋友。
（5）当前对象所创建的对象。
实现：
（1）在类的划分上，应当创建有弱耦合的类。类之间的耦合越弱，就越有利于复用。
（2）在类的结构设计上，每一个类都应当尽量降低成员的访问权限。一个类不应当public自己的属性，而应当提供取值和赋值的方法让外界间接访问自己的属性。
（3）在类的设计上，只要有可能，一个类应当设计成不变类。
（4）在对其它对象的引用上，一个类对其它对象的引用应该降到最低。
（5）尽量限制局部变量的有效范围.
4. Android 架构初探(1)
a. 基本架构方向、满足特性
方向： 分层->模块化->组件化->插件化.
目标： 方便自动化测试、低耦合(方便维护和扩展)、易复用。
b. 框架简介
1. ORM框架 (解决：数据库-对象映射)
主流： hibernate、mybates/ibates、springjdbc
解决问题： 通过对象-关系映射系统，实现程序对象到关系型数据库的映射，减少大量数据库操作开发量。
劣势： hibernaet 太重性能不好、复杂多表关联查询吃力。
ibates 半自动化，可以自己写sql. 文档、调试、复杂查询不方便。
2. MVC, MVP, MMVM用来解决业务逻辑和视图之间的耦合
MVC: M是指业务模型，V是指用户界面，C则是控制器.
a. 主动MVC
MVC的理论思想对应的是主动MVC, 这里的主动的意思是, Model会主动通知View更新。而我们使用MVC框架, Struts, asp.net mvc等都不是主动MVC(视图的更新都是通过Controller完成的)
Model
用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法。
模型中数据的变化一般会通过一种刷新机制被公布。为了实现这种机制，那些用于监视此模型的视图必须事先在此模型上注册，从而，视图可以了解在数据模型上发生的改变。
View
视图层负责数据的展示。
在视图中一般没有程序上的逻辑。为了实现视图上的刷新功能，视图需要访问它监视的数据模型（Model），因此应该事先在被它监视的数据那里订阅Model的事件。
Controller
控制器是M和V之间的连接器，用于控制应用程序的流程。它处理事件并作出响应。“事件”包括用户的行为和数据模型上的改变。
b. 被动MVC
被动MVC 中，与主动MVC的区别在于：
1、模型对视图和控制器一无所知，它仅仅是被它们使用
2、控制器使用视图，并通知它更新数据显示
3、视图仅仅是在控制器通知它去模型取数据的时候它才这么做(视图并不会订阅或监视模型的更新)
Web中的MVC框架都是被动MVC模式，因为web应用中, 由于http是基于请求和响应方式协同工作的,因此当服务器端的model(数据)发生变化时,它不会立即更新客户端的view,只有客户端重新请求或刷新页面时才更新.
下图是典型的MVC框架中的MVC一个请求流程。
c. MVC 缺陷
MVC的缺点
完美的MVC应用场景应该是这样的:
有个Student Model, 关联StudentListView, StudentEditView.
对于StudentListView, Student Model提供Student的集合数据来显示StudentListView
对于StudentEditView, Student Model提供单个Student数据来展示StudentEditView并且响应StudentEditView的保存操作。
但是这只是完美的情况，实际应用中，在ListView上，不单单显示Student的信息，可能还需要这个Student的历史成绩，家庭情况, 老师信息。而这些是Student Model不能提供的。
也许我们可以扩展Student Model, 将Student Model能够提供的信息扩展，包含成绩信息等，这本身也可以。但是，如果Student显示的View，这个需要只是需要额外的成绩信息，另一个View只是需要额外的家庭信息，Student Model是不是有些疲于奔命，你能知道还会有多少个差异化的View的需求? 而且让逻辑端代码这样不断的修改来适应View端，好吗?
由于MVC的设计思想是从Model出发，而没有考虑到View端的复杂性，这样导致的问题是Model难以符合复杂多变的View端变化。
相对这点，MVP和MVVM就要好得多。它们都独立出了Presenter 和ViewModel来对应每个View。
5. Android Mac无法识别手机或USB调试
a. 排查USB是否识别，确保硬件USB接口和USB数据线正常。
方法：
1. Mac->关于本机->系统报告->USB 如图：
2. 执行 adb devices，查看有无设备
一般情况下都是线或手机USB接口的问题。