一份年薪50万的Android面试宝典，附答案，头条三面技术四面HR

最新推荐文章于 2024-11-08 23:02:35 发布

2024云技术

最新推荐文章于 2024-11-08 23:02:35 发布

阅读量708

点赞数 25

分类专栏： 2024年程序员学习文章标签： android 面试职场和发展

本文链接：https://blog.csdn.net/2401_83621004/article/details/136934685

版权

2024年程序员学习专栏收录该内容

291 篇文章 2 订阅

订阅专栏

handler = null;

new Thread(new Runnable() {

private Looper mLooper;

@Override

public void run() {

//必须调用Looper的prepare方法为当前线程创建一个Looper对象，然后启动循环

//prepare方法中实质是给ThreadLocal对象创建了一个Looper对象

//如果当前线程已经创建过Looper对象了，那么会报错

Looper.prepare();

handler = new Handler();

//获取Looper对象

mLooper = Looper.myLooper();

//启动消息循环

Looper.loop();

//在适当的时候退出Looper的消息循环，防止内存泄漏

mLooper.quit();

}

}).start();

主线程中默认是创建了Looper并且启动了消息的循环的，因此不会报错：
应用程序的入口是ActivityThread的main方法，在这个方法里面会创建Looper，并且执行Looper的loop方法来启动消息的循环，使得应用程序一直运行。

子线程中可以通过Handler发送消息给主线程吗？

可以。有时候出于业务需要，主线程可以向子线程发送消息。子线程的Handler必须按照上述方法创建，并且关联Looper。

7、事件传递机制以及自定义View相关

Android的视图树

Android中View的机制主要是Activity的显示，每个Activity都有一个Window（具体在手机中的实现类是PhoneWindow），Window以下有DecorView，DecorView下面有TitleVie以及ContentView，而ContentView就是我们在Activity中通过setContentView指定的。

[图片上传失败…(image-504911-1585739565438)]

事件传分发机制

[图片上传失败…(image-4880ef-1585739565438)]

ViewGroup有以下三个与事件分发的方法，而View只有dispatchTouchEvent和onTouchEvent。

@Override

public boolean dispatchTouchEvent(MotionEvent ev) {

return super.dispatchTouchEvent(ev);

}

@Override

public boolean onInterceptTouchEvent(MotionEvent ev) {

return super.onInterceptTouchEvent(ev);

}

@Override

public boolean onTouchEvent(MotionEvent event) {

return super.onTouchEvent(event);

}

事件总是从上往下进行分发，即先到达Activity，再到达ViewGroup，再到达子View，如果没有任何视图消耗事件的话，事件会顺着路径往回传递。其中：

dispatchTouchEvent是事件的分发方法，如果事件能够到达该视图的话，就首先一定会调用，一般我们不会去修改这个方法。
onInterceptTouchEvent是事件分发的核心方法，表示ViewGroup是否拦截事件，如果返回true表示拦截，在这之后ViewGroup的onTouchEvent会被调用，事件就不会往下传递。
onTouchEvent是最低级的，在事件分发中最后被调用。
子View可以通过requestDisallowInterceptTouchEvent方法去请求父元素不要拦截。

注意

事件从Activity.dispatchTouchEvent()开始传递，只要没有被停止或拦截，从最上层的View(ViewGroup)开始一直往下(子View)传递。子View 可以通过onTouchEvent()对事件进行处理。
事件由父View(ViewGroup)传递给子View，ViewGroup 可以通过onInterceptTouchEvent()对事件做拦截，停止其往下传递。
如果事件从上往下传递过程中一直没有被停止，且最底层子View 没有消费事件，事件会反向往上传递，这时父View(ViewGroup)可以进行消费，如果还是没有被消费的话，最后会到Activity 的onTouchEvent()函数。
如果View 没有对ACTION_DOWN 进行消费，之后的其他事件不会传递过来。
OnTouchListener 优先于onTouchEvent()对事件进行消费。

自定义View的分类

对现有的View的子类进行扩展，例如复写onDraw方法、扩展新功能等。
自定义组合控件，把常用一些控件组合起来以方便使用。
直接继承View实现View的完全定制，需要完成View的测量以及绘制。
自定义ViewGroup，需要复写onLayout完成子View位置的确定等工作。

View的测量-onMeasure

View的测量最终是在onMeasure方法中通过setMeasuredDimension把代表宽高两个MeasureSpec设置给View，因此需要掌握MeasureSpec。MeasureSpec包括大小信息以及模式信息。

MeasureSpec的三种模式：

EXACTLY模式：精确模式，对应于用户指定为match_parent或者具体大小的时候（实际上指定为match_parent实质上是指定大小为父容器的大小）
AT_MOST模式：对应于用户指定为wrap_content，此时控件尺寸只要不超过父控件允许的最大尺寸即可。
UNSPECIFIED模式：不指定大小的测量模式，这种模式比较少用

下面给出模板代码：

public class MeasureUtils {

/**

用于View的测量
@param measureSpec
@param defaultSize
@return

public static int measureView(int measureSpec, int defaultSize) {

int measureSize;

//获取用户指定的大小以及模式

int mode = View.MeasureSpec.getMode(measureSpec);

int size = View.MeasureSpec.getSize(measureSpec);

//根据模式去返回大小

if (mode == View.MeasureSpec.EXACTLY) {

//精确模式（指定大小以及match_parent）直接返回指定的大小

measureSize = size;

} else {

//UNSPECIFIED模式、AT_MOST模式（wrap_content）的话需要提供默认的大小

measureSize = defaultSize;

if (mode == View.MeasureSpec.AT_MOST) {

//AT_MOST（wrap_content）模式下，需要取测量值与默认值的最小值

measureSize = Math.min(measureSize, defaultSize);

}

return measureSize;

}

最后，复写onMeasure方法，把super方法去掉：

@Override

protected void onMeasure(int widthMeasureSpec, int heightMeasureSpec) {

setMeasuredDimension(MeasureUtils.measureView(widthMeasureSpec, 200),

MeasureUtils.measureView(heightMeasureSpec, 200)

);

}

View的绘制-onDraw

View绘制，需要掌握Android中View的坐标体系：

[图片上传失败…(image-985d4e-1585739565437)]

View的坐标体系是以左上角为坐标原点，向右为X轴正方向，向下为Y轴正方向。

View绘制，主要是通过Android的2D绘图机制来完成，时机是onDraw方法中，其中包括画布Canvas，画笔Paint。下面给出示例代码。相关API不是介绍的重点，重点是Canvas的save和restore方法，通过save以后可以对画布进行一些放大缩小旋转倾斜等操作，这两个方法一般配套使用，其中save的调用次数可以多于restore。

@Override

protected void onDraw(Canvas canvas) {

super.onDraw(canvas);

Bitmap bitmap = ImageUtils.drawable2Bitmap(mDrawable);

canvas.drawBitmap(bitmap, getLeft(), getTop(), mPaint);

canvas.save();

//注意，这里的旋转是指画布的旋转

canvas.rotate(90);

mPaint.setColor(Color.parseColor(“#FF4081”));

mPaint.setTextSize(30);

canvas.drawText(“测试”, 100, -100, mPaint);

canvas.restore();

}

View的位置-onLayout

与布局位置相关的是onLayout方法的复写，一般我们自定义View的时候，只需要完成测量，绘制即可。如果是自定义ViewGroup的话，需要做的就是在onLayout中测量自身以及控制子控件的布局位置，onLayout是自定义ViewGroup必须实现的方法。

8、性能优化

布局优化

使用include标签，通过layout属性复用相同的布局。

<include

android:id=“@+id/v_test”

layout=“@layout/include_view” /

使用merge标签，去除同类的视图
使用ViewStub来进行布局的延迟加载一些不是马上就用到的布局。例如列表页中，列表在没有拿到数据之前不加载，这样做可以使UI变得流畅。

<ViewStub

android:id=“@+id/v_stub”

android:layout_width=“match_parent”

android:layout_height=“wrap_content”

android:layout=“@layout/view_stub” />

//需要手动调用inflate方法，布局才会显示出来。

stub.inflate();

//其中setVisibility在底层也是会调用inflate方法

//stub.setVisibility(View.VISIBLE);

//之后，如果要使用ViewStub标签里面的View，只需要按照平常来即可。

TextView tv_1 = (TextView) findViewById(R.id.tv_1);

尽量多使用RelativeLayout，因为这样可以大大减少视图的层级。

内存优化

APP设计以及代码编写阶段都应该考虑内存优化：

珍惜Service，尽量使得Service在使用的时候才处于运行状态。尽量使用IntentService

IntentService在内部其实是通过线程以及Handler实现的，当有新的Intent到来的时候，会创建线程并且处理这个Intent，处理完毕以后就自动销毁自身。因此使用IntentService能够节省系统资源。

内存紧张的时候释放资源（例如UI隐藏的时候释放资源等）。复写Activity的回调方法。

@Override

public void onLowMemory() {

super.onLowMemory();

}

@Override

public void onTrimMemory(int level) {

super.onTrimMemory(level);

switch (level) {

case TRIM_MEMORY_COMPLETE:

//…

break;

case 其他:

}

通过Manifest中对Application配置更大的内存，但是一般不推荐

android:largeHeap=“true”

避免Bitmap的浪费，应该尽量去适配屏幕设备。尽量使用成熟的图片加载框架，Picasso，Fresco，Glide等。
使用优化的容器，SparseArray等
其他建议：尽量少用枚举变量，尽量少用抽象，尽量少增加类，避免使用依赖注入框架，谨慎使用library，使用代码混淆，时当场合考虑使用多进程等。
避免内存泄漏（本来应该被回收的对象没有被回收）。一旦APP的内存短时间内快速增长或者GC非常频繁的时候，就应该考虑是否是内存泄漏导致的。

分析方法

1. 使用Android Studio提供的Android Monitors中Memory工具查看内存的使用以及没使用的情况。

2. 使用DDMS提供的Heap工具查看内存使用情况，也可以手动触发GC。

3. 使用性能分析的依赖库，例如Square的LeakCanary，这个库会在内存泄漏的前后通过Notification通知你。

什么情况会导致内存泄漏

资源释放问题：程序代码的问题，长期保持某些资源，如Context、Cursor、IO 流的引用，资源得不到释放造成内存泄露。
对象内存过大问题：保存了多个耗用内存过大的对象（如Bitmap、XML 文件），造成内存超出限制。
static 关键字的使用问题：static 是Java 中的一个关键字，当用它来修饰成员变量时，那么该变量就属于该类，而不是该类的实例。所以用static 修饰的变量，它的生命周期是很长的，如果用它来引用一些资源耗费过多的实例（Context 的情况最多），这时就要谨慎对待了。

解决方案
1. 应该尽量避免static 成员变量引用资源耗费过多的实例，比如Context。
2. Context 尽量使用ApplicationContext，因为Application 的Context 的生命周期比较长，引用它不会出现内存泄露的问题。
3. 使用WeakReference 代替强引用。比如可以使用WeakReference mContextRef

线程导致内存溢出：线程产生内存泄露的主要原因在于线程生命周期的不可控。例如Activity中的Thread在run了，但是Activity由于某种原因重新创建了，但是Thread仍然会运行，因为run方法不结束的话Thread是不会销毁的。

解决方案

1. 将线程的内部类，改为静态内部类（因为非静态内部类拥有外部类对象的强引用，而静态类则不拥有）。

2. 在线程内部采用弱引用保存Context 引用。

查看内存泄漏的方法、工具

android官方提供的工具：Memory Monitor（当APP占用的内存在短时间内快速增长或者GC变得频繁的时候）、DDMS提供的Heap工具（手动触发GC）
Square提供的内存泄漏检测工具，LeakCanary（能够自动完成内存追踪、检测、输出结果），进行演示，并且适当的解说。

性能优化

防止过度绘制，通过打开手机的“显示过度绘制区域”即可查看过度绘制的情况。
最小化渲染时间，使用视图树查看节点，对节点进行性能分析。
通过TraceView进行数据的采集以及分析。在有大概定位的时候，使用Android官方提供的Debug类进行采集。最后通过DDMS即可打开这个.trace文件，分析函数的调用情况（包括在指定情况下执行时间，调用次数）

//开启数据采集

Debug.startMethodTracing(“test.trace”);

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级安卓工程师，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Android移动开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。