BroadcastReceive广播接收器:应用可以使用它对外部事件进行过滤只对感兴趣的外部事件(如当电话呼入时，或者数据网络可用时)进行接收并做出响应。广播接收器没有用户界面。然而，它们可以启动一个activity或serice 来响应它们收到的信息，或者用NotificationManager 来通知用户。通知可以用很多种方式来吸引用户的注意力──闪动背灯、震动、播放声音等。一般来说是在状态栏上放一个持久的图标，用户可以打开它并获取消息。

Service 服务:一个Service 是一段长生命周期的，没有用户界面的程序，可以用来开发如监控类程序。

Content Provider内容提供者 :android平台提供了Content Provider使一个应用程序的指定数据集提供给其他应用程序。这些数据可以存储在文件系统中、在一个SQLite数据库、或以任何其他合理的方式。

2. 屏幕适配，常用方案。

Android屏幕适配的发展

1、dp直接适配

2、宽高限定符适配

3、UI适配框架Autolayout

目前最好的适配方案

1、SmallestWidth适配（sw限定符适配）

2、今日头条适配方案

3、AutoSize

3.布局优化。

使用工具检测（Hierarchy Viewer）；
使用include 和merge标签减少复用布局而产生的布局嵌套，使用ViewStub懒加载减少渲染元素；
诊断过度绘制，优化过度绘制

4. 懒加载有什么缺点。

ViewStub对象只可以Inflate一次；
ViewStub不支持merge

5. MVC、MVP、MVVM区别。

MVC的特点

它将数据、视图、控制分开，实现了松耦合。

View将事件传递到Controller中

Controller完成想要业务后改变Model状态

Model更新View

MVC的优点

实现了解耦合，修改其中一层时，不用修改另外两层代码

可维护性高，松耦合也就意味着维护起来更加方便

重用性高

MVC的缺点

由于控件的数据绑定都需要在Activity中完成，Activity/Fragment在View与Controller的定义中有点模糊。

伴随着业务的增加，Controller容易变得臃肿。

MVP的特点

View接受事件，传递给Presenter

Presenter做逻辑处理，修改Model

Model通知Presenter数据变化，Presenter更新View

MVP的优点

将Model与View完全分隔，提高了可扩展性。

便于测试。在测试Presenter时，只要实现View的接口并注入到Presenter就可以测试Presenter的业务逻辑。

MVP的缺点

与MVC一样，P层起到的控制功能伴随着业务的增多，也会变得臃肿。

Presneter需要持有View的引用，同时View也需要持有Presenter的引用，控制上存在一定复杂度。

MVVM的特点

View接受事件，转交给ViewModel

ViewModel操作Model更新数据

Model更新后通知ViewModel，ViewModel更新View数据

MVVM的优点

低耦合。由于ViewModel的存在,View可以独立于Model变化与修改；同理，Model也可以独立于View变化与修改。

可重用性。一个ViewModel可被多个View重复绑定，实现同一组业务。

ViewModel中解决了MVP中V-P互相持有引用的问题，使得结构更清晰，简洁

MVVM的缺点

ViewModel持有Model的依赖。

数据绑定方式使得bug难以确定是在View中还是在Model中。

6.Glide加载大图原理，如何防止内存溢出。

清单文件可以增大系统分配给APP的最大内存，默认大概60M。

Android：尽量不要使用setImageBitmap或setImageResource或BitmapFactory.decodeResource来设置一张大图，

因为这些函数在完成decode后，最终都是通过java层的createBitmap来完成的，需要消耗更多内存。

因此，改用先通过BitmapFactory.decodeStream方法，创建出一个bitmap，再将其设为ImageView的 source，
decodeStream最大的秘密在于其直接调用JNI>>nativeDecodeAsset()来完成decode，

Glide：在加载图片的时候，不要缓存资源，如果可以获取控件尺寸的话，可以控制加载的尺寸；

.skipMemoryCache(true) //禁止Glide内存缓存

.diskCacheStrategy(DiskCacheStrategy.NONE) //不缓存资源

7.内存优化。

常见的内存泄漏：

静态引用（自身代码和第三方代码）
集合内引用
Handler消息未清除
非静态的内部类中持有外部类的引用
匿名内部类/非静态内部类和异步线程

实践：

先解决程序中内存占用较大的业务模块中的内存泄漏，不熟悉MAT的使用的可以看看这个
移除程序中多余的代码和引用，这里使用默认的lint检测再配合shrinkResources来删除无效资源
优化图片，保证图片放置在合理的文件夹，根据View大小加载合适的图片大小，根据手机状态配置bitmap和回收策略
优化对象创建，比如string，使用对象池等

8.WebView和H5页面优化

当App启动的时候，就在Application里初始化一个Webview，对，就是直接new；当需要用的时候就直接取这个单例形式的webview去加载网页，这样就把webview初始化的等待时间变得用户无感知；不过每次使用的时候需要清空上次使用的页面内容
使用WebView缓存
H5页面预加载
HTML 应用程序缓存机制

应用程序缓存（简称 AppCache) 为 web 应用的离线访问提供了支持，其原理是基于 manifest 属性和 manifest 文件。manifest 缓存会一直保存，直到缓存被清除，manifest 文件被修改，或浏览器更新 AppCache。

9.Monkey测试

如何重现Monkey中发现的错误？

答：使用seed

语法：adb shell monkey -p 包名 -s 50 100

Monkey除了做伪随机事件外，能不能写脚本？

答：能。

Monkey测试一般测试多久？

答：超过3个小时。

monkey测试流程？

答：简要步骤：

1). 查看设备是否已连接：adb devices

2）. 测试前首先关闭MTK log，将sdcard卡和手机内存中的旧的log清理赶紧

3). 了解并得到包名

4）. 运行测试稳定性命令: adb shell monkey -p 包名 -v 运行次数（多个参数的组合形成不同的用例以求最大的覆盖）

5）.当崩溃或无响应时分析monkey日志

android monkey的测试结果怎么分析

在log的最开始都会显示Monkey执行的seed值、执行次数和测试的包名。

首先我们需要查看Monkey测试中是否出现了ANR或者异常，无响应问题（ANR问题）：在日志中搜索“ANR ”（此处有空格），

崩溃问题：在日志中搜索“Exception”，快速定位到关键事件信息。然后查看Monkey里面出错前的一些事件动作，并手动执行该动作，找出重现步骤，给开发。

10.APP启动流程，从点击桌面图标开始。

1、点击桌面App图标，Launcher进程采用Binder IPC向system_server进程发起startActivity请求；

2、system_server进程接收到请求后，向zygote进程发送创建进程的请求；

3、Zygote进程fork出新的子进程，即App进程；

4、App进程，通过Binder IPC向sytem_server进程发起attachApplication请求；

5、system_server进程在收到请求后，进行一系列准备工作后，再通过binder IPC向App进程发送scheduleLaunchActivity请求；

6、App进程的binder线程（ApplicationThread）在收到请求后，通过handler向主线程发送LAUNCH_ACTIVITY消息；

7、主线程在收到Message后，通过发射机制创建目标Activity，并回调Activity.onCreate()等方法。

到此，App便正式启动，开始进入Activity生命周期，执行完onCreate/onStart/onResume方法

11.APP卡顿处理

大多数用户感知到的卡顿等性能问题的最主要根源都是因为渲染性能，不能再16ms完成一帧的渲染。

Overdraw(过度绘制)描述的是屏幕上的某个像素在同一帧的时间内被绘制了多次。在多层次的UI结构里面，如果不可见的UI也在做绘制的操作，这就会导致某些像素区域被绘制了多次。这就浪费大量的CPU以及GPU资源。

12.网络优化

工具：Android Studio内置的Network Monitor。

1）API设计，考虑请求频数，适当合并接口，用较少的请求来完成业务需求和界面的展示。

2）使用Gzip来压缩request和response, 减少传输数据量, 从而减少流量消耗。考虑使用Protocol Buffer代替JSON，就像之前使用JSON代替XML。

3）获取图片的Size合适就好，不要总是请求最大尺寸。

4）适当的缓存, 既可以让我们的应用看起来更快, 也能避免一些不必要的流量消耗。

13.适配CPU架构如X86，ARM等

主要是项目用到so文件需要适配。（暂时还没想好怎么回答比较合适，知道怎么回答合适的可以留言哈）

14.怎么多渠道打包；分渠道不打包某些第三方包（比如在华为手机应用市场的apk不打包小米推送的jar包）

15.Activity的四种启动模式

Standard：标准模式，默认模式。Android会为它创建一个新的实例，并将该实例放到当前Task栈中，（并不会生成新的Task栈）
SingleTop：和Standard模式基本相似，但有一点不同：当将要启动的目标activity已经位于Task栈顶时，系统不会重新创建目标activity的实例，而是直接复用已有的activity实例。当该activity不位于Task栈的栈顶时（有其他的activity位于栈顶），和Standard模式一样，会再次为该activity创建一个新的实例放入栈顶。之前的实例仍然存在栈内原始位置。
SingleTask：
采用SingleTask模式时，activity能够保证在同一个Task中只有一个实例，当系统采用SingleTask模式启动activity时，有如下三种情况：

1.如果将要启动的activity不存在，系统将会创建目标activity的实例，并将它放入Task栈顶；

2.如果将要启动的activity已经存在Task栈的栈顶，那么按照SingleTop模式行为一样，不会再重新创建该activity的实例;

3.如果将要启动的activity已经存在，但没有位于Task栈的栈顶，系统将会将位于该activity上面的所有activity移出Task栈，从而使目标activity转入栈顶。
SingleInstance：
在这个模式中，系统保证无论从哪个Task中启动目标activity，只会创建一个目标activity实例，并会使用一个全新的Task栈来加载该activity实例。

当系统采用SingleInstance模式启动目标activity时，可分为以下两种情况：

1.如果要启动的目标activity不存在，系统会先创建一个新的Task，再创建目标activity的实例，并将它放入栈顶。

2.如果将要启动的目标activity已存在，无论它位于哪个应用程序中、位于哪个Task中，系统都会把该activity所在的Task转到前台（一般会有一个切换的画面效果），从而使该activity显示出来。

需要指出的是，采用SIngleInstance模式加载的activity总数会位于Task栈顶，且采用singleInstance模式加载的activity所在的Task只包含该activity。

16.Android 版本适配

Android 6:运行时权限动态申请
Android 7:禁止向你的应用外公开 file:// URI,若要共享文件，使用FileProvider类
Android 8:引入了通知渠道，不允许后台应用启动后台服务，需要通过startForegroundService()指定为前台服务，应用有五秒的时间来调用该 Service 的 startForeground() 方法以显示可见通知。
Android 9：网络请求中，要求使用https、刘海屏API支持
Android 10：定位权限、分区存储、后台启动 Activity 的限制、深色主题
Android 11：存储机制更新、权限更新、权限更新、软件包可见性、前台服务类型、消息框的更新；废弃Display.getSize() 和 Display.getMetrics()
Android 12：1.新增系统默认启动页；2.列表滚动到底动画效果变化；3.限制域概念，就是app在系统的优先级；4.废弃Display.getRealSize() 和 Display.getRealMetrics() ；5.非可信触摸事件会被屏蔽

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/Guff_9hys/article/detail/862521