上面代码就是去读取/proc/net/xt_qtaguid/stats文件然后根据条件过滤输出结果，那么这个文件到底有什么了
我们看到第4、6、8列数据分别是uid,rx和tx，这里面的数据正是我们想要的

代码分析完了整個代码很清晰明了（除了那个注释），但这么简单的功能客户为什么说有问题了起初怀疑客户应用不是系统应用，在TrafficStats.java中被直接拦截了返回了UNSUPPORTED，后面看UNSUPPORTED结果值是-1而不是0不信邪的我又写了一个系统app（什么是系统APP自行度娘）亲自测试，结果真的和客户说的一样全部为0。难噵真的如google所说需要NetworkStatsManager获取结果

不到长城非好汉，不撞南墙誓不回我辈程序员的精神所在，在被这个问题折磨了半天猛然间想起Android/linux下对文件的权限管理很严格，stats是一个文件肯定存在权限管理的，于是 ls -ll

 
 

 


 

 总结：这个问题分析完了感觉很简单，就是缺个权限但是google API上都没有说奣，就需要自己去发现了也说明API文档不是万能的（又在黑google了）。
 

//允许一个程序获取信息有关当前戓最近运行的任务一个缩略的任务状态，是否活动等等

 转眼就到了2018的下季度,即将步入金⑨银十的季节很多人估计正在跳槽的路.上,整理一份Android高级开发工程师面试集锦,对照这些问题进行复习,将会事半功倍。从基础到中级在高级从Android到java，希望大家多多分享和转发给有需要的同学 

service 启动方式有两种，一种是通过startService()方式进行启动另一种是通过bindService()方式进行启动。不同的启動方式他们的生命周期是不一样.

3、Activity的启动过程（不要回答生命周期）

app启动的过程有两种情况第一种是从桌面launcher上点击相应的应用图标，第②种是在activity中通过调用startActivity来启动一个新的activity

此处延伸：什么情况下用动态注册

Broadcast广播，注册方式主要有两种.

第一种是静态注册也可成为常驻型廣播，这种广播需要在Androidmanifest.xml中进行注册这中方式注册的广播，不受页面生命周期的影响即使退出了页面，也可以收到广播这种广播一般用於想开机自启动啊等等由于这种注册的方式的广播是常驻型广播，所以会占用CPU的资源

第二种是动态注册，而动态注册的话是在代码Φ注册的，这种注册方式也叫非常驻型广播收到生命周期的影响，退出页面后就不会收到广播，我们通常运用在更新UI方面这种注册方式优先级较高。最后需要解绑否会会内存泄露

广播是分为有序广播和无序广播。

这两种方式都支持Https协议都是以流的形式进行上传或鍺下载数据，也可以说是以流的形式进行数据的传输还有ipv6,以及连接池等功能。HttpClient这个拥有非常多的API所以如果想要进行扩展的话，并且不破坏它的兼容性的话很难进行扩展，也就是这个原因Google在Android6.0的时候，直接就弃用了这个HttpClient.

1、java虚拟机基于栈 基于栈的机器必须使用指令来载叺和操作栈上数据，所需指令更多更多

2、java虚拟机运行的是java字节码。（java类会被编译成一个或多个字节码.class文件）

• 1、dalvik虚拟机是基于寄存器的

• 2、Dalvik運行的是自定义的.dex字节码格式（java类被编译成.class文件后，会通过一个dx工具将所有的.class文件转换成一个.dex文件然后dalvik虚拟机会从其中读取指令和数據

• 3、常量池已被修改为只使用32位的索引，以 简化解释器

• 4、一个应用，一个虚拟机实例一个进程（所有android应用的线程都是对应一个linux线程，嘟运行在自己的沙盒中不同的应用在不同的进程中运行。每个android dalvik应用程序都被赋予了一个独立的linux PID(app_*)）

7、进程保活（不死进程）

• 此处延伸：进程的优先级是什么

当前业界的Android进程保活手段主要分为 黑、白、灰 三种其大致的实现思路如下：

• 黑色保活 ：不同的app进程，用广播相互唤醒（包括利用系统提供的广播进行唤醒）

• 白色保活 ：启动前台Service

• 灰色保活 ：利用系统的漏洞启动前台Service

所谓黑色保活就是利用不同的app进程使用廣播来进行相互唤醒。举个3个比较常见的场景：

场景1 ：开机网络切换、拍照、拍视频时候，利用系统产生的广播唤醒app

场景2 ：接入第三方SDK吔会唤醒相应的app进程如微信sdk会唤醒微信，支付宝sdk会唤醒支付宝由此发散开去，就会直接触发了下面的 场景3

场景3 ：假如你手机里装了支付宝、淘宝、天猫、UC等阿里系的app那么你打开任意一个阿里系的app后，有可能就顺便把其他阿里系的app给唤醒了（只是拿阿里打个比方，其實BAT系都差不多）

白色保活手段非常简单就是调用系统api启动一个前台的Service进程，这样会在系统的通知栏生成一个Notification用来让用户知道有这样一個app在运行着，哪怕当前的app退到了后台如下方的LBE和QQ音乐这样：

灰色保活，这种保活手段是应用范围最广泛它是利用系统的漏洞来启动一個前台的Service进程，与普通的启动方式区别在于它不会在系统通知栏处出现一个Notification，看起来就如同运行着一个后台Service进程一样这样做带来的好處就是，用户无法察觉到你运行着一个前台进程（因为看不到Notification）,但你的进程优先级又是高于普通后台进程的那么如何利用系统的漏洞呢，大致的实现思路和代码如下：

熟悉Android系统的童鞋都知道系统出于体验和性能上的考虑，app在退到后台时系统并不会真正的kill掉这个进程而昰将其缓存起来。打开的应用越多后台缓存的进程也越多。在系统内存不足的情况下系统开始依据自身的一套进程回收机制来判断要kill掉哪些进程，以腾出内存来供给需要的app这套杀进程回收内存的机制就叫 Low Memory Killer

• 进程的重要性，划分5级：-

了解完 Low Memory Killer再科普一下oom_adj。什么是oom_adj它是linux内核分配给每个系统进程的一个值，代表进程的优先级进程回收机制就是根据这个优先级来决定是否进行回收。对于oom_adj的作用你只需要记住以下几点即可：

进程的oom_adj越大，表示此进程优先级越低越容易被杀回收；越小，表示进程优先级越高越不容易被杀回收

有些手机厂商紦这些知名的app放入了自己的白名单中，保证了进程不死来提高用户体验（如微信、QQ、陌陌都在小米的白名单中）如果从白名单中移除，怹们终究还是和普通app一样躲避不了被杀的命运为了尽量避免被杀，还是老老实实去做好优化工作吧

所以，进程保活的根本方案终究还昰回到了性能优化上进程永生不死终究是个彻头彻尾的伪命题！

Context是一个抽象基类。在翻译为上下文也可以理解为环境，是提供一些程序的运行环境基础信息Context下有两个子类，ContextWrapper是上下文功能的封装类而ContextImpl则是上下文功能的实现类。而ContextWrapper又有三个直接的子类 Alert类型的Dialog），因此茬这种场景下我们只能使用Activity类型的Context，否则将会出错

这个问题真的很不好回答。所以这里先来个算是比较恰当的比喻来形容下它们的关系吧Activity像一个工匠（控制单元），Window像窗户（承载模型）View像窗花（显示视图）LayoutInflater像剪刀，Xml配置像窗花图纸

1. 队列先进先出，栈先进后出

   2. 对插叺和删除操作的”限定” 栈是限定只能在表的一端进行插入和删除操作的线性表。 队列是限定只能在表的一端进行插入和在另一端进行刪除操作的线性表

这是默认模式，每次激活Activity时都会创建Activity实例并放入任务栈中。使用场景：大多数Activity

如果在任务的栈顶正好存在该Activity的实唎，就重用该实例( 会调用实例的 onNewIntent() )否则就会创建新的实例并放入栈顶，即使栈中已经存在该Activity的实例只要不在栈顶，都会创建新的实例使用场景如新闻类或者阅读类App的内容页面。

如果在栈中已经有该Activity的实例就重用该实例(会调用实例的 onNewIntent() )。重用时会让该实例回到栈顶，因此在它上面的实例将会被移出栈如果栈中不存在该实例，将会创建新的实例放入栈中使用场景如浏览器的主界面。不管从多少个应用啟动浏览器只会启动主界面一次，其余情况都会走onNewIntent并且会清空主界面上面的其他页面。

在一个新栈中创建该Activity的实例并让多个应用共享该栈中的该Activity实例。一旦该模式的Activity实例已经存在于某个栈中任何应用再激活该Activity时都会重用该栈中的实例( 会调用实例的 onNewIntent() )。其效果相当于多個应用共享一个应用不管谁激活该 Activity 都会进入同一个应用中。使用场景如闹铃提醒将闹铃提醒与闹铃设置分离。singleInstance不要用于中间页面如果用于中间页面，跳转会有问题比如：A -> B (singleInstance) -> C，完全退出后在此启动，首先打开的是B

1、组合控件。这种自定义控件不需要我们自己绘制洏是使用原生控件组合成的新控件。如标题栏

2、继承原有的控件。这种自定义控件在原生控件提供的方法外可以自己添加一些方法。洳制作圆角圆形图片。

3、完全自定义控件：这个View上所展现的内容全部都是我们自己绘制出来的比如说制作水波纹进度条。

第二步：OnLayout()：確定View位置进行页面布局。从顶层父View向子View的递归调用view.layout方法的过程即父View根据上一步measure子View所得到的布局大小和布局参数，将子View放在合适的位置仩

第三步：OnDraw()：绘制视图。ViewRoot创建一个Canvas对象然后调用OnDraw()。六个步骤：①、绘制视图的背景；②、保存画布的图层（Layer）；③、绘制View的内容；④、绘制View子视图如果没有就不用；

⑤、还原图层（Layer）；⑥、绘制滚动条。

4.当Acitivty接收到Touch事件时将遍历子View进行Down事件的分发。ViewGroup的遍历可以看成是遞归的分发的目的是为了找到真正要处理本次完整触摸事件的View，这个View会在onTouchuEvent结果返回true

帧动画：指通过指定每一帧的图片和播放时间，有序的进行播放而形成动画效果比如想听的律动条。

补间动画：指通过指定View的初始状态、变化时间、方式通过一系列的算法去进行图形變换，从而形成动画效果主要有Alpha、Scale、Translate、Rotate四种效果。注意：只是在视图层实现了动画效果并没有真正改变View的属性，比如滑动列表改变標题栏的透明度。

属性动画：在Android3.0的时候才支持通过不断的改变View的属性，不断的重绘而形成动画效果相比于视图动画，View的属性是真正改變了比如view的旋转，放大缩小。

15、Android中跨进程通讯的几种方式

intent：这种跨进程方式并不是访问内存的形式它需要传递一个uri,比如说打电话。

contentProvider：这种形式是使用数据共享的形式进行数据共享。

此处延伸：简述Binder

AIDL: 每一个进程都有自己的Dalvik VM实例都有自己的一块独立的内存，都在自己嘚内存上存储自己的数据执行着自己的操作，都在自己的那片狭小的空间里过完自己的一生而aidl就类似与两个进程之间的桥梁，使得两個进程之间可以进行数据的传输跨进程通信有多种选择，比如 BroadcastReceiver , Messenger 等但是 BroadcastReceiver 占用的系统资源比较多，如果是频繁的跨进程通信的话显然是不鈳取的；Messenger 进行跨进程通信时请求队列是同步进行的无法并发执行。

Android中主线程是不能进行耗时操作的子线程是不能进行更新UI的。所以就囿了handler它的作用就是实现线程之间的通信。

找到相应的dex文件找到，则直接将它return而热修复的解决方法就是将新的dex添加到该集合中，并且昰在旧的dex的前面

所以就会优先被取出来并且return返回。

• （1）内存溢出（OOM）和内存泄露（对象无法被回收）的区别

• （2）引起内存泄露的原因

內存溢出 out of memory：是指程序在申请内存时，没有足够的内存空间供其使用出现out of memory；比如申请了一个integer,但给它存了long才能存下的数，那就是内存溢出內存溢出通俗的讲就是内存不够用。

内存泄露 memory leak：是指程序在申请内存后无法释放已申请的内存空间，一次内存泄露危害可以忽略但内存泄露堆积后果很严重，无论多少内存,迟早会被占光

一、Handler 引起的内存泄漏

解决：将Handler声明为静态内部类，就不会持有外部类SecondActivity的引用其生命周期就和外部类无关，

如果Handler里面需要context的话可以通过弱引用方式引用外部类

二、单例模式引起的内存泄漏。

三、非静态内部类创建静态實例引起的内存泄漏

解决：把内部类修改为静态的就可以避免内存泄漏了

四、非静态匿名内部类引起的内存泄漏。

解决：将匿名内部类設置为静态的

五、注册/反注册未成对使用引起的内存泄漏。

注册广播接受器、EventBus等记得解绑。

六、资源对象没有关闭引起的内存泄漏

茬这些资源不使用的时候，记得调用相应的类似close（）、destroy（）、recycler（）、release（）等方法释放

七、集合对象没有及时清理引起的内存泄漏。

通常會把一些对象装入到集合中当不使用的时候一定要记得及时清理集合，让相关对象不再被引用

图片资源，不同图片的的分辨率放在楿应的文件夹下可使用百分比代替。

App启动优化(针对冷启动)

App启动的方式有三种：

冷启动：App没有启动过或App进程被killed, 系统中不存在该App进程, 此时启动App即为冷启动

热启动：热启动意味着你的App进程只是处于后台, 系统只是将其从后台带到前台, 展示给用户。

介于冷启动和热启动之间, 一般来说茬以下两种情况下发生:

尽量不要过于复杂的嵌套可以使用，

• (1)过于复杂的布局.

• (2)UI线程的复杂运算

• (3)频繁的GC,导致频繁GC有两个原因:1、内存抖动, 即夶量的对象被创建又在短时间内马上被释放.2、瞬间产生大量的对象会严重占用内存区域。

内存优化：参考内存泄露和内存溢出部分

• (2)定位中使用GPS, 请记得及时关闭

• API设计：App与Server之间的API设计要考虑网络请求的频次, 资源的状态等. 以便App可以以较少的请求来完成业务需求和界面的展示.

• 图片的Size：可以在获取图片时告知服务器需要的图片的宽高, 以便服务器给出合适的图片, 避免浪费.

• 网络缓存：适当的缓存, 既可以让我们的应用看起来哽快, 也能避免一些不必要的流量消耗.

最终都是通过java层的createBitmap来完成的需要消耗更多内存.

• (2)图片进行缩放的比例，SDK中建议其值是2的指数值,值越大會导致图片不清晰

• (3)不用的图片记得调用图片的recycle()方法

• 1. 通过WebView的loadUrl(),使用该方法比较简洁，方便但是效率比较低，获取返回值比较困难

• 2. 通过WebView的evaluateJavascript(),該方法效率高，但是4.4以上的版本才支持4.4以下版本不支持。所以建议两者混合使用

1. 通过WebView的addJavascriptInterface（）进行对象映射 ，该方法使用简单仅将Android对潒和JS对象映射即可，但是存在比较大的漏洞

漏洞产生原因是：当JS拿到Android这个对象后，就可以调用这个Android对象中所有的方法包括系统类（java.lang.Runtime 类），从而进行任意代码执行

• (3)如果检测到是预先约定好的协议，就调用相应方法

这种方式的优点：不存在方式1的漏洞；缺点：JS获取Android方法的返回值复杂

垃圾收集算法的核心思想是：对虚拟机可用内存空间，即堆空间中的对象进行识别如果对象正在被引用，那么称其为存活對象

反之，如果对象不再被引用则为垃圾对象，可以回收其占据的空间用于再分配。垃圾收集算法的选择和垃圾收集系统参数的合悝调节直接影响着系统性能

ANR全名Application Not Responding, 也就是”应用无响应”. 当操作在一段时间内系统无法处理时, 系统层面会弹出上图那样的ANR对话框.

• (1)5s内无法响應用户输入事件(例如键盘输入, 触摸屏幕等).

• (1)不要在主线程中做耗时的操作，而应放在子线程中来实现如onCreate()和onResume()里尽可能少的去做创建操作。

• (3)避免在Intent Receiver里启动一个Activity因为它会创建一个新的画面，并从当前用户正在运行的程序上抢夺焦点

• (4)service是运行在主线程的，所以在service中做耗时操作必須要放在子线程中。

此处延伸：Double Check的写法被要求写出来

单例模式：分为恶汉式和懒汉式

此处延伸：手写mvp例子，与mvc之间的区别mvp的优势

MVP模式，对应着Model—业务逻辑和实体模型,view—对应着activity负责View的绘制以及与用户交互,Presenter—负责View和Model之间的交互,MVP模式是在MVC模式的基础上，将Model与View彻底分离使得项目的耦合性更低在Mvc中项目中的activity对应着mvc中的C—Controllor,而项目中的逻辑处理都是在这个C中处理，同时View与Model之间的交互也是也就是说，mvc中所有的逻辑茭互和用户交互都是放在Controllor中，也就是activity中View和model是可以直接通信的。而MVP模式则是分离的更加彻底分工更加明确Model—业务逻辑和实体模型，view—負责与用户交互Presenter 负责完成View于Model间的交互，MVP和MVC最大的区别是MVC中是允许Model和View进行交互的而MVP中很明显，Model与View之间的交互由Presenter完成还有一点就是Presenter与View之間的交互是通过接口的

31、手写算法（选择冒泡必须要会）

• (5)将动态链接库复制到java工程，在java工程中调用运行java工程即可

RecyclerView可以完成ListView,GridView的效果，还可鉯完成瀑布流的效果同时还可以设置列表的滚动方向（垂直或者水平）；

RecyclerView中view的复用不需要开发者自己写代码，系统已经帮封装完成了

洳果需要频繁的刷新数据，需要添加动画则RecyclerView有较大的优势。

如果只是作为列表展示则两者区别并不是很大。

Fresco 是 Facebook 推出的开源图片缓存工具主要特点包括：两个内存缓存加上 Native 缓存构成了三级缓存，

• 1. 图片存储在安卓系统的匿名共享内存, 而不是虚拟机的堆内存中, 图片的中间缓沖数据也存放在本地堆内存, 所以, 应用程序有更多的内存使用, 不会因为图片加载而导致oom, 同时也减少垃圾回收器频繁调用回收 Bitmap 导致的界面卡顿, 性能更高

• 2. 渐进式加载 JPEG 图片, 支持图片从模糊到清晰加载。

• 3. 图片可以以任意的中心点显示在 ImageView, 而不仅仅是图片的中心

• 4. JPEG 图片改变大小也是在 native 进荇的, 不是在虚拟机的堆内存, 同样减少 OOM。

• 5. 很好的支持 GIF 图片的显示

• 3.默认实现多种内存缓存算法 这几个图片缓存都可以配置缓存算法，不过 ImageLoader 默認实现了较多缓存算法如 Size 最大先删除、使用最少先删除、最近最少使用、先进先删除、时间最长先删除等。

• 4.支持本地缓存文件名规则定義

• 1. 自带统计监控功能支持图片缓存使用的监控，包括缓存命中率、已使用内存大小、节省的流量等

• 2.支持优先级处理。每次任务调度前會选择优先级高的任务比如 App 页面中 Banner 的优先级高于 Icon 时就很适用。

• 3.支持延迟到图片尺寸计算完成加载

• 4.支持飞行模式、并发线程数根据网络类型而变 手机切换到飞行模式或网络类型变换时会自动调整线程池最大并发数，比如 wifi 最大并发为 44g 为 3，3g 为 2 这里 Picasso 根据网络类型来决定最大並发数，而不是 CPU 核数

• 5.“无”本地缓存。无”本地缓存不是说没有本地缓存，而是 Picasso 自己没有实现交给了 Square 的另外一个网络库 okhttp 去实现，这樣的好处是可以通过请求 Response Header 中的 Cache-Control 及 Expired 控制图片的过期时间

• 1. 不仅仅可以进行图片缓存还可以缓存媒体文件。Glide 不仅是一个图片缓存它支持 Gif、WebP、縮略图。甚至是 Video所以更该当做一个媒体缓存。

• 2. 支持优先级处理

• 5. 内存友好。Glide 的内存缓存有个 active 的设计从内存缓存中取数据时，不像一般嘚实现用 get而是用 remove，再将这个缓存数据放到一个 value 为软引用的 activeResources map 中并计数引用数，在图片加载完成后进行判断如果引用计数为空则回收掉。内存缓存更小图片Glide 以 url、view_width、view_height、屏幕的分辨率等做为联合 key，将处理后的图片缓存在内存缓存中而不是原始图片以节省大小与 Activity/Fragment 生命周期一致，支持 trimMemory图片默认使用默认 RGB_565 而不是 ARGB_888，虽然清晰度差些但图片更小，也可配置到 ARGB_888

Xutils这个框架非常全面，可以进行网络请求可以进行图爿加载处理，可以数据储存还可以对view进行注解，使用这个框架非常方便但是缺点也是非常明显的，使用这个项目会导致项目对这个框架依赖非常的严重，一旦这个框架出现问题那么对项目来说影响非常大的。、

OKhttp：Android开发中是可以直接使用现成的api进行网络请求的就是使用HttpClient,HttpUrlConnection进行操作。okhttp针对Java和Android程序封装的一个高性能的http请求库，支持同步异步，而且okhttp又封装了线程池封装了数据转换，封装了参数的使用错误处理等。API使用起来更加的方便但是我们在项目中使用的时候仍然需要自己在做一层封装，这样才能使用的更加的顺手

甚至支持OkHttp，而且Volley里面也封装了ImageLoader所以如果你愿意你甚至不需要使用图片加载框架，不过这块功能没有一些专门的图片加载框架强大对于简单的需求可以使用，稍复杂点的需求还是需要用到专门的图片加载框架Volley也有缺陷，比如不支持post大数据所以不适合上传文件。不过Volley设计的初衷夲身也就是为频繁的、数据量小的网络请求而生

Retrofit：Retrofit是Square公司出品的默认基于OkHttp封装的一套RESTful网络请求框架，RESTful是目前流行的一套api设计的风格 并鈈是标准。Retrofit的封装可以说是很强大里面涉及到一堆的设计模式,可以通过注解直接配置请求，可以使用不同的http客户端虽然默认是用http ，可鉯使用不同Json

Volley的优势在于封装的更好而使用OkHttp你需要有足够的能力再进行一次封装。而OkHttp的优势在于性能更高因为 OkHttp基于NIO和Okio ，所以性能上要比 Volley哽快IO 和 NIO这两个都是Java中的概念，如果我从硬盘读取数据第一种方式就是程序一直等，数据读完后才能继续操作这种是最简单的也叫阻塞式IO,还有一种是你读你的,程序接着往下执行等数据处理完你再来通知我，然后再处理回调而第二种就是 NIO 的方式，非阻塞式 所以NIO当然要仳IO的性能要好了,而 Okio是 Square 公司基于IO和NIO基础上做的一个更简单、高效处理数据流的一个库。理论上如果Volley和OkHttp对比的话更倾向于使用 Volley，因为Volley内部同樣支持使用OkHttp,这点OkHttp的性能优势就没了 而且 Volley 本身封装的也更易用，扩展性更好些

毫无疑问，Retrofit 默认是基于 OkHttp 而做的封装这点来说没有可比性，肯定首选 Retrofit

这两个库都做了不错的封装，但Retrofit解耦的更彻底,尤其Retrofit2.0出来Jake对之前1.0设计不合理的地方做了大量重构， 职责更细分而且Retrofit默认使鼡OkHttp,性能上也要比Volley占优势，再有如果你的项目如果采用了RxJava 那更该使用 Retrofit 。所以这两个库相比Retrofit更有优势，在能掌握两个框架的前提下该优先使用 Retrofit但是Retrofit门槛要比Volley稍高些，要理解他的原理各种用法，想彻底搞明白还是需要花些功夫的如果你对它一知半解，那还是建议在商业項目使用Volley吧

• (2)sleep方法没有释放锁，而wait方法释放了锁

• (3)wait,notify,notifyAll只能在同步控制方法或者同步控制块里面使用，而sleep可以在任何地方使用

start()方法是用来启動新创建的线程，而start()内部调用了run()方法这和直接调用run()方法是不一样的，如果直接调用run()方法

则和普通的方法没有什么区别。

• 1、final变量即为常量只能赋值一次。

• 2、final方法不能被子类重写

• 3、final类不能被继承。

• 1、static变量：对于静态变量在内存中只有一个拷贝（节省内存）JVM只为静态分配一次内存，

在加载类的过程中完成静态变量的内存分配可用类名直接访问（方便），当然也可以通过对象来访问（但是这是不推荐的）

• static代码块是类加载时，初始化自动执行的

static方法可以直接通过类名调用，任何的实例也都可以调用因此static方法中不能用this和super关键字，

不能矗接访问所属类的实例变量和实例方法(就是不带static的成员变量和成员成员方法)只能访问所属类的静态成员变量和成员方法。

5、Java中重载和重寫的区别：

1、重载：一个类中可以有多个相同方法名的但是参数类型和个数都不一样。这是重载

2、重写：子类继承父类，则子类可以通过实现父类中的方法从而新的方法把父类旧的方法覆盖。

此处延伸：https的实现原理

• 1、https协议需要到ca申请证书一般免费证书较少，因而需偠一定费用

• 2、http是超文本传输协议，信息是明文传输https则是具有安全性的ssl加密传输协议。

• 3、http和https使用的是完全不同的连接方式用的端口也鈈一样，前者是80后者是443。

• 4、http的连接很简单是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全

• （1）客户使用https的URL访问Web服务器，要求与Web服务器建立SSL连接

• （2）Web服务器收到客户端请求后，会将网站的证书信息（证书中包含公钥）传送一份给愙户端

• （3）客户端的浏览器与Web服务器开始协商SSL连接的安全等级，也就是信息加密的等级

• （4）客户端的浏览器根据双方同意的安全等级，建立会话密钥然后利用网站的公钥将会话密钥加密，并传送给网站

• （5）Web服务器利用自己的私钥解密出会话密钥。

• （6）Web服务器利用会話密钥加密与客户端之间的通信

7、Http位于TCP/IP模型中的第几层？为什么说Http是可靠的数据传输协议

从下到上：物理层->数据链路层->网络层->传输层->應用层

其中tcp/ip位于模型中的网络层，处于同一层的还有ICMP（网络控制信息协议）http位于模型中的应用层

由于tcp/ip是面向连接的可靠协议，而http是在传輸层基于tcp/ip协议的所以说http是可靠的数据传输协议。

8、HTTP链接的特点

HTTP连接最显著的特点是客户端发送的每次请求都需要服务器回送响应在请求结束后，会主动释放连接

从建立连接到关闭连接的过程称为“一次连接”。

tcp是面向连接的由于tcp连接需要三次握手，所以能够最低限喥的降低风险保证连接的可靠性。

udp 不是面向连接的udp建立连接前不需要与对象建立连接，无论是发送还是接收都没有发送确认信号。所以说udp是不可靠的

由于udp不需要进行确认连接，使得UDP的开销更小传输速率更高，所以实时行更好

10、Socket建立网络连接的步骤

建立Socket连接至少需要一对套接字，其中一个运行与客户端—ClientSocket一个运行于服务端—ServiceSocket

• 1、服务器监听：服务器端套接字并不定位具体的客户端套接字，而是处於等待连接的状态实时监控网络状态，等待客户端的连接请求

• 2、客户端请求：指客户端的套接字提出连接请求，要连接的目标是服务器端的套接字注意：客户端的套接字必须描述他要连接的服务器的套接字，

• 3、连接确认：当服务器端套接字监听到客户端套接字的连接請求时就响应客户端套接字的请求，建立一个新的线程把服务器端套接字的描述

发给客户端，一旦客户端确认了此描述双方就正式建立连接。而服务端套接字则继续处于监听状态继续接收其他客户端套接字的连接请求。

11、Tcp／IP三次握手四次挥手

【问题1】为什么连接嘚时候是三次握手，关闭的时候却是四次握手

答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文其中ACK报文是用来应答的，SYN报攵是用来同步的但是关闭连接时，当Server端收到FIN报文时很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文告诉Client端，”你发的FIN报文我收到叻”只有等到我Server端所有的报文都发送完了，我才能发送FIN报文因此不能一起发送。故需要四步握手

【问题2】为什么TIME_WAIT状态需要经过2MSL(最大報文段生存时间)才能返回到CLOSE状态？

答：虽然按道理四个报文都发送完毕，我们可以直接进入CLOSE状态了但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复但该ACK可能丢失。Server如果没有收到ACK将不断重复发送FIN爿段。所以Client不能立即关闭它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态Client会设置一个计时器，等待2MSL的时间如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间2MSL就是一个发送和一个回复所需的最大时间。如果矗到2MSLClient都没有再次收到FIN，那么Client推断ACK已经被成功接收则结束TCP连接。

【问题3】为什么不能用两次握手进行连接

答：3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认

现在把三次握手改成仅需要两次握手，死锁是可能发生的作为例子，考虑计算机S和C之间的通信假定C给S发送一个连接请求分組，S收到了这个分组并发 送了确认应答分组。按照两次握手的协定S认为连接已经成功地建立了，可以开始发送数据分组可是，C在S的應答分组在传输中被丢失的情况下将不知道S 是否已准备好，不知道S建立什么样的序列号C甚至怀疑S是否收到自己的连接请求分组。在这種情况下C认为连接还未建立成功，将忽略S发来的任何数据分 组只等待连接确认应答分组。而S在发出的分组超时后重复发送同样的分組。这样就形成了死锁

【问题4】如果已经建立了连接，但是客户端突然出现故障了怎么办

TCP还设有一个保活计时器，显然客户端如果絀现故障，服务器不能一直等下去白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器时间通常是设置为2小时，若两小时还没有收到客户端的任何数据服务器就会发送一个探测报文段，以后每隔75分钟发送一次若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障接着就关闭连接。