一、第一轮我是在前程无忧投的简历，然后hr打电话给我，进行首轮电话面试
- 首先是他介绍公司的情况，和了解我一些的基本情况，比如，之前的实习情况，做过哪些项目，自己负责哪部分，以及那些项目发布了没。其实，就是简单大概的了解我的基本情况和技术。
- 第一轮电话面试通过了，约我去公司进行二轮笔试加面试
二、第二轮，我很信心满满带着简历，身份证、学历学位证的复印件（我面试的是国企，要求带上这些）就去公司面试了
- 首先就是填表，就是面试表（入职表，去面试每个公司都要你填的）
- 填完表格，前台的小姐姐开开心心的拿笔试题给我做了，我看了一下，两道单选，三道多选，六道大题，一道附加题，满分一百分，总共一个小时的时间
- 记得不是很清楚了
- （1）HashMap的原理，关键字key不能重复
- （2）以下哪些情况会出现ANR错误：activity 按键或触摸事件在5s无响应，broadcastreceiver 10s内无法做出回应，service20s内无法处理完成；都会导致应用无响应。（在主线程做耗时操作都会导致ANR）
- （3）handle的消息机制：messege,messegequeue,looper,handle
- （4）wait和sleep的区别：sleep来自Thread类，wait来自Object类，调用sleep()方法的过程中，线程不会释放对象锁。而 调用 wait 方法线程会释放对象锁，sleep睡眠后不出让系统资源，wait让出系统资源其他线程可以占用CPU，sleep(milliseconds)需要指定一个睡眠时间，时间一到会自动唤醒
- （5）Activity的四种启动模式和应用场景：
-
（6）写出MVC、MVP、MVVP的意思，以及他们的优缺点：Activity四种启动模式： 1、standard：标准化启动模式 每启动一个Activity，都会重新创建Activity的新的实例，将其放在栈的顶部。不需要考虑这个实例是否已经存在。 每一次启动，它的onCreate()、onStart()、onResume()方法都会被依次调用。 2、singleTop：栈顶复用模式 当前栈中已经有该Activity实例，并且该实例位于栈顶时，会去调用onNewIntent()方法。 当前栈中已有该Activity的实例但是该实例不在栈顶时，依然会去创建Activity。 当前栈中不存在该Activity实例时，会去新创建一个该Activity。 应用场景：IM对话框、新闻客户端推送。 3、singleTask：栈内复用模式 它主要检测【寻找，通过taskAffinity】整个栈中是否已经存在当前想要启动的Activity，存在的话直接将该Activity置于栈顶，之前位于该Activity上面的Activity将被销毁，同时调用onNewIntent()方法，而不存在的话进行创建。 应用场景：应用主界面。 4、singleInstance： 一个人独享一个任务栈。当该Activity启动时，系统会创建一个新的任务栈，同时将Activity放到这个新的任务栈当中，有别的应用来启动该Activity时，由于栈内复用的特性，不会再去创建相应Activity任务栈，而是这两个应用独享一个Activity实例。 例如：应用A中现有两个Activity E、Activity F，为standard启动模式，应用B中有一个Activity G，但其启动模式是singleInstance。应用A想用应用B任务栈当中的Activity G，尽管在不同的应用下，但是应用A仍然会直接复用Activity G。 特性： 1、以SingleInstance模式启动的Activity具有全局唯一性【全局唯一性即指在整个系统当中只会存在一个这样的实例】； 2、如果在启动这样一个Activity时，【整个系统都是单例的】，已经存在了一个实例； 3、以SingleInstance模式启动的Activity具有独占性。 应用场景：呼叫来电。 -
MVC模式： M:model——>数据处理（网络请求，数据存储（SQL,MySQL）） V:view——>layout，view控件（视图界面显示） C：controller——>Activity、Fragment(业务等逻辑处理) 优点：一定程度上实现了Model与View的分离，降低了代码的耦合性 缺点：Controller与View难以实现完全解耦，并且随着项目复杂度的提升，Controller将越来越臃肿 使用MVC实现需求： 1.将数据的获取与界面的展示分离（即从Activity中分离到model） 2.解决各层之间通信的问题（Activity通知Model获取数据，Model通知Activity更新界面） 3.Activity其实包括View和Model MVP模式： M：model——>负责提供数据方面的功能 V：View（Activity）——>负责提供View层面的功能（采用实现接口的方式） P：presenter——>业务逻辑处理 优点：解决了MVC中Controller与View过度耦合的缺点，职责划分明显，更加易于维护 缺点：接口数量多，项目复杂度升高，随着项目复杂度的提升，Presenter层将越来越臃肿 MVVM模式：这个我用的比较少，你可以百度一下，mvvm主要与dataBinding,LiveData一起使用的，进行单向或是双向绑定，语法跟前端的vue框架有点熟悉（7）你用过哪些设计模式：
- 观察者模式
-
1.观察者模式（Observer Pattern） 释义：观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象，这个主题对象在状态上发生变化时，会通知所有观察者对象，使他们能够自动更新自己。 故事理解：观察者想知道公司所有MM的情况，只要加入公司的MM情报邮件组就行了，tom负责搜集情报，当发现新情报时，不用一个一个通知我们，直接发布给邮件组，我们作为订阅者（观察者）就可以及时收到情报啦。 常见实例：1.BaseAdapter.registerDataSetObserver和BaseAdapter.unregisterDataSetObserver两方法来向BaseAdater注册、注销一个DataSetObserver ; 2.使用ContentObserver去监听数据库变化。 适用场景：1.当对一个对象的改变需要同时改变其他对象，而不知道具体有多少对象有待改变；2.当一个对象必须通知其它对象，而它又不能假定其它对象是谁.适配器模式
-
释义：把一个类的接口变换成客户端所期待的另一种接口，从而使原本因接口原因不匹配而无法一起工作的两个类能够一起工作。适配类可以根据参数返还一个合适的实例给客户端。 故事理解：在朋友聚会上碰到了一个美女Sarah，从香港来的，可我不会说粤语，她不会说普通话，只好求助于我的朋友kent了，他作为我和Sarah之间的Adapter，让我和Sarah可以相互交谈了(也不知道他会不会耍我)。 常见实例：ListView用于显示列表数据，但是作为列表数据集合有很多形式，有Array，有Cursor，我们需要对应的适配器作为桥梁，处理相应的数据（并能形成ListView所需要的视图）。 适用场景：1.业务的接口与工作的类不兼容，（比如：类中缺少实现接口的某些方法）但又需要两者一起工作；2. 在现有接口和类的基础上为新的业务需求提供接口。 适配器模式分为类适配器模式和对象适配器模式。关于类适配模式，因为java的单继承，所以在已继承一个类时，另外的只能是接口，需要手动实现相应的方法，这样在客户端就可以创建任一种符合需求的子类，来实现具体功能。而另外一种对象适配器，它不是使用继承再实现的方式，而是使用直接关联，或者称为委托的方式，具体可见该博客详细介绍适配器模式（Adapter）：类适配器、对象适配器代理模式
-
释义： 通过引入一个新的对象来实现对真实对象的操作或将新的对象作为真实对象的一个替身,这样的实现机制是代理模式(为其他对象提供一种代理以控制对这个对象的访问). 故事理解：校园代理是为他对应的上司作代理，而这个校园代理的工作就是访问校园中的学生，例如对学生进行问卷之类的事。学生就是官方说法中的其他对象，校园代理的上司就通过控制这个校园代理来控制对学生的访问。 常见实例：ActivityManagerProxy类就是一个代理，它是ActivityManagerNative的代理，也就是说ActivityManagerProxy是所说的Proxy类，而ActivityManagerNative就相当于“上司角色“类，它们都有一个共有的接口IActivityManager。ActivityManager，它相当于代理模式的client。在这个类中，可以看到大量的getxxx函数，这些函数，都会调用到ActivityManagerNative类的getDefault()方法，而该方法会获得一个共用的单例的IActivityManager引用，然后通过多态来调用代理中的实现 适用场景：代理模式的应用场合分几种:远程代理，虚拟代理，安全代理等，具体可见为别人做嫁衣—-代理模式工厂模式
-
工厂模式分为简单工厂模式，工厂方法模式以及抽象工厂模式 简单工厂模式：一般情况下，提供一个方法，方法的参数是一个标志位，根据标志位来创建不同的对象，这样调用的时候只需要提供一个标志位就可以创建一个实现了接口的类。 工厂方法模式：将简单工厂模式的那个方法分开，不再是在工厂方法中根据标志位创建对象了。而是定义一个工厂接口，然后想创建几个不同类型的对象（即实现了同一接口的不同java类），就创建了几个不同类型的工厂。也就是创建的对象和创建对象的工厂是一一对应的。然后客户端调用的时候直接去实例化一个具体的对象工厂，创建相对应的对象。 抽象工厂模式:其实这个名起的有点不知所云没有表达出这个模式的特点。其实这个模式就是工厂方法模式的稍微扩展一下而已。工厂方法模式里面，一般一个工厂接口只有一个方法，比如createMouse()。然后用实现了这个接口的具体工厂类只能生产鼠标。而抽象工厂模式就是一个工厂接口有多个方法，比如createMouse() , createKeyboard() 。 这样实现了这个工厂接口的具体工厂类就可以既生产鼠标又生产键盘。单例模式
-
释义：单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例单例模式。单例模式只应在有真正的“单一实例”的需求时才可使用。 故事理解：俺有6个漂亮的老婆，她们的老公都是我，我就是我们家里的老公Sigleton，她们只要说道“老公”，都是指的同一个人，那就是我 常见实例：数据库创建时使用单例模式，Servlet环境下共享同一个资源或者对象 适用场景：对于定义的一个类，在整个应用程序执行期间只有唯一的一个实例对象。如Android中常见的Application对象。 单例模式可分为饿汉式，懒汉式等：命令模式
-
释义：把一个请求或者操作封装到一个对象中。命令模式把发出命令的责任和执行命令的责任分割开，委派给不同的对象。命令模式允许请求的一方和发送的一方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收，以及操作是否执行，何时被执行以及是怎么被执行的。 故事理解：俺有一个MM家里管得特别严，没法见面，只好借助于她弟弟在我们俩之间传送信息，她对我有什么指示，就写一张纸条让她弟弟带给我。这不，她弟弟又传送过来一个COMMAND，为了感谢他，我请他吃了碗杂酱面，哪知道他说：“我同时给我姐姐三个男朋友送COMMAND，就数你最小气，才请我吃面。 常见实例：常用的Runnable(在java.lang包下)，其实就是用了命令模式，具体的体现过程，可见该博客 Runnable下的命令设计模式 适用场景：1. 命令的发送者和命令执行者有不同的生命周期。命令发送了并不是立即执行。2. 命令需要进行各种管理逻辑。3. 需要支持撤消\重做操作（这种状况的代码大家可以上网搜索下，有很多，这里不进行详细解读）。 其实经典的命令模式包括4个角色： Command：定义命令的统一接口 ConcreteCommand：Command接口的实现者，用来执行具体的命令，某些情况下可以直接用来充当Receiver。 Receiver：命令的实际执行者 Invoker：命令的请求者，是命令模式中最重要的角色。这个角色用来对各个命令进行控制。（8）Kotlin和Java的区别
-
（9）附加题：算法题
-
有12个完全相同的球,其中有一个的重量异常（不知是轻还是重）,给你一个无刻度天平,称3次找出它，请写出你的想法。 百度有很多优秀的答案和java代码实现，这里就不写其余题忘了~~~~~~~~~
三、第三轮，技术面
问的问题很多，记得聊了一个多小时，总结一下，大概是一下问题：
- 自我介绍
- Activity的生命周期，以及各阶段的使用场景
- 使用过哪些设计模式
- 线程，多线程，线程池
- handle机制，有没有了解它的底层机制
- MCV.MVP.MVVM的框架的了解和优缺点
- 有没有使用过第三方SDK的接入
- okhttp3,socket的工作原理
- 了不了解一个App从开发到发布经历过哪些环节
- 只记得这么多了
备注：本文参考一下文章：
扫一扫
2048
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
