Android-Flutter面经

第一高：前台进程前台进程是Android系统中最重要的进程，是与用户正在交互的进程。第二高：可见进程可见进程指部分程序界面能够被用户看见，却不在前台与用户交互。第三高：服务进程一个包含已启动服务的进程就是服务进程，服务没有用户界面，不与用户直接交互，但能够在后台长期运行，提供用户所关心的重要功能。第四高：后台进程如果一个进程不包含任何已经启动的服务，而且没有用户可见的Activity，则这个进程就是后台进程。第五高：空进程空进程是不包含任何活跃组件的进程。在系统资源紧张时会被首先清楚。startService和bindService的区别，生命周期以及使用场景startService 和bindService 区别startService： onCreate -> onStartCommand -> onDestory ，在多次调用startService的时候，onCreate不重复执行，但是onStartCommand会执行。startService调用了这后，会一直存在，直到其调用了stopService。bindService : onCreate -> onBind -> onUnbind -> onDestory，多次调用bindService，onCreate及onBind都只执行一次。它生命周期跟随其调用者，调用者释放的时候，必须对该Service解绑，当所有绑定全部取消后，系统即会销毁该服务。 bindService 的方式通过onServiceConnected方法，获取到Service对象，通过该对象可以直接操作到Service内部的方法，从而实现的Service 与调用者之间的交互。使用场景如果想要启动一个后台服务长期进行某项任务，那么使用startService如果只是短暂的使用，那么使用bindService。如果想启动一个后台服务长期进行任务，且这个过程中需要与调用者进行交互，那么可以两者同时使用，或者使用startService + BoardCast/ EventBus 等方法。对于既使用startService，又使用bindService的情况，结束服务时需要注意的事项：Service的终止，需要unbindService和stopService都调用才行；顺便提一下IntentService，与Service的区别在于它内部封装了一个工作线程，也就是说，在其内部onHandleIntent的代码都是在子线程里面工作的。Android中IntentService有何优点IntentService是一个通过Context.startService(Intent)启动可以处理异步请求的Service,使用时你只需要继承IntentService和重写其中的onHandleIntent(Intent)方法接收一个Intent对象,在适当的时候会停止自己(一般在工作完成的时候). 所有的请求的处理都在一个工作线程中完成,它们会交替执行(但不会阻塞主线程的执行),一次只能执行一个请求。这是一个基于消息的服务,每次启动该服务并不是马上处理你的工作,而是首先会创建对应的Looper,Handler并且在MessageQueue中添加的附带客户Intent的Message对象,当Looper发现有Message的时候接着得到Intent对象通过在onHandleIntent((Intent)msg.obj)中调用你的处理程序.处理完后即会停止自己的服务.意思是Intent的生命周期跟你的处理的任务是一致的.所以这个类用下载任务中非常好,下载任务结束后服务自身就会结束退出.进程间通信的方式有哪几种AIDL 、广播、文件、socket、管道广播静态注册和动态注册的区别动态注册广播不是常驻型广播，也就是说广播跟随 Activity 的生命周期。注意在 Activity 结束前，移除广播接收器。 静态注册是常驻型，也就是说当应用程序关闭后，如果有信息广播来，程序也会被系统调用自动运行。当广播为有序广播时：优先级高的先接收（不分静态和动态）。同优先级的广播接收器，动态优先于静态同优先级的同类广播接收器，静态：先扫描的优先于后扫描的，动态：先注册的优先于后注册的。当广播为默认广播时：无视优先级，动态广播接收器优先于静态广播接收器。同优先级的同类广播接收器，静态：先扫描的优先于后扫描的，动态：先注册的优先于后册的。Android 性能优化工具使用（这个问题建议配合Android中的性能优化）Android 中常用的性能优化工具包括这些：Android Studio 自带的 Android Profiler、LeakCanary、BlockCanaryAndroid 自带的 Android Profiler 其实就很好用，Android Profiler 可以检测三个方面的性能问题：CPU、MEMORY、NETWORK。LeakCanary 是一个第三方的检测内存泄漏的库，我们的项目集成之后 LeakCanary 会自动检测应用运行期间的内存泄漏，并将之输出给我们。BlockCanary 也是一个第三方检测UI卡顿的库，项目集成后Block也会自动检测应用运行期间的UI卡顿，并将之输出给我们。Android中的类加载器PathClassLoader，只能加载系统中已经安装过的 apkDexClassLoader，可以加载 jar/apk/dex，可以从 SD卡中加载未安装的 apkAndroid中的动画有哪几类，它们的特点和区别是什么Android中动画大致分为3类：帧动画、补间动画（Tween Animation）、属性动画（Property Animation）。帧动画：通过xml配置一组图片，动态播放。很少会使用。补间动画（Tween Animation）：大致分为旋转、透明、缩放、位移四类操作。很少会使用。属性动画（Property Animation）：属性动画是现在使用的最多的一种动画，它比补间动画更加强大。属性动画大致分为两种使用类型，分别是 ViewPropertyAnimator 和 ObjectAnimator。前者适合一些通用的动画，比如旋转、位移、缩放和透明，使用方式也很简单通过 View.animate() 即可得到 ViewPropertyAnimator，之后进行相应的动画操作即可。后者适合用于为我们的自定义控件添加动画，当然首先我们应该在自定义 View 中添加相应的 getXXX() 和 setXXX() 相应属性的 getter 和 setter 方法，这里需要注意的是在 setter 方法内改变了自定义 View 中的属性后要调用 invalidate() 来刷新View的绘制。之后调用 ObjectAnimator.of 属性类型()返回一个 ObjectAnimator，调用 start() 方法启动动画即可。补间动画与属性动画的区别：补间动画是父容器不断的绘制 view，看起来像移动了效果,其实 view 没有变化，还在原地。是通过不断改变 view 内部的属性值，真正的改变 view。TimeInterpolator（时间插值器）作用：根据时间流逝的百分比计算出当前属性值改变的百分比系统已有的插值器：LinearInterpolator（线性插值器）：匀速动画。AccelerateDecelerateInterpolator（加速减速插值器）：动画两头慢，中间快。DecelerateInterpolator（减速插值器）：动画越来越慢。TypeEvaluator（类型估值算法，即估值器）：作用：根据当前属性改变的百分比来计算改变后的属性值。系统已有的估值器：IntEvaluator：针对整型属性FloatEvaluator：针对浮点型属性ArgbEvaluator：针对Color属性 Handler 机制说到 Handler，就不得不提与之密切相关的这几个类：Message、MessageQueue，Looper。Message。Message 中有两个成员变量值得关注：target 和 callback。target 其实就是发送消息的 Handler 对象callback 是当调用 handler.post(runnable) 时传入的 Runnable 类型的任务。post 事件的本质也是创建了一个 Message，将我们传入的这个 runnable 赋值给创建的Message的 callback 这个成员变量。MessageQueue。 消息队列很明显是存放消息的队列，值得关注的是 MessageQueue 中的 next() 方法，它会返回下一个待处理的消息。Looper。Looper 消息轮询器其实是连接 Handler 和消息队列的核心。首先我们都知道，如果想要在一个线程中创建一个 Handler，首先要通过Looper.prepare()创建 Looper，之后还得调用Looper.loop()开启轮询。我们着重看一下这两个方法。prepare()。 这个方法做了两件事：首先通过ThreadLocal.get()获取当前线程中的Looper,如果不为空，则会抛出一个RunTimeException，意思是一个线程不能创建2个Looper。如果为null则执行下一步。第二步是创建了一个Looper，并通过 ThreadLocal.set(looper)。将我们创建的Looper与当前线程绑定。这里需要提一下的是消息队列的创建其实就发生在Looper的构造方法中。loop()。 这个方法开启了整个事件机制的轮询。它的本质是开启了一个死循环，不断的通过 MessageQueue的next()方法获取消息。拿到消息后会调用 msg.target.dispatchMessage()来做处理。其实我们在说到 Message 的时候提到过，msg.target 其实就是发送这个消息的 handler。这句代码的本质就是调用 handler的dispatchMessage()。Handler。上面做了这么多铺垫，终于到了最重要的部分。Handler 的分析着重在两个部分：发送消息和处理消息。*发送消息。其实发送消息除了 sendMessage 之外还有 sendMessageDelayed 和 post 以及 postDelayed 等等不同的方式。但它们的本质都是调用了 sendMessageAtTime。在 sendMessageAtTime 这个方法中调用了 enqueueMessage。在 enqueueMessage 这个方法中做了两件事：通过msg.target = this实现了消息与当前 handler 的绑定。然后通过queue.enqueueMessage实现了消息入队。处理消息。 消息处理的核心其实就是dispatchMessage()这个方法。这个方法里面的逻辑很简单，先判断 msg.callback 是否为 null，如果不为空则执行这个 runnable。如果为空则会执行我们的handleMessage方法。Handler面试知识点www.yuque.com/docs/share/…子线程更新ui会怎么样，为什么不让子线程更新ui,在oncreate里用子 线程更新ui为什么不会报错ActivityThread.handleResumeActivity（） 中初始化了ViewRootImpl 然后执行 requestLayout()进行线程校验if (r.window == null && !a.mFinished && willBeVisible) {
r.window = r.activity.getWindow();
View decor = r.window.getDecorView();
decor.setVisibility(View.INVISIBLE);
ViewManager wm = a.getWindowManager();
WindowManager.LayoutParams l = r.window.getAttributes();
a.mDecor = decor;
l.type = WindowManager.LayoutParams.TYPE_BASE_APPLICATION;
l.softInputMode |= forwardBit;
if (r.mPreserveWindow) {
a.mWindowAdded = true;
r.mPreserveWindow = false;
// Normally the ViewRoot sets up callbacks with the Activity
// in addView->ViewRootImpl#setView. If we are instead reusing
// the decor view we have to notify the view root that the
// callbacks may have changed.
ViewRootImpl impl = decor.getViewRootImpl();
if (impl != null) {
impl.notifyChildRebuilt();
}
}
if (a.mVisibleFromClient) {
if (!a.mWindowAdded) {
a.mWindowAdded = true;
wm.addView(decor, l);
} else {复制代码Android 性能优化Android 中的性能优化在我看来分为以下几个方面：内存优化、布局优化、网络优化、安装包优化。内存优化： 下一个问题就是。布局优化：布局优化的本质就是减少 View 的层级。常见的布局优化方案如下在 LinearLayout 和 RelativeLayout 都可以完成布局的情况下优先选择 RelativeLayout，可以减少 View 的层级将常用的布局组件抽取出来使用 < include >标签通过 < ViewStub >标签来加载不常用的布局使用 < Merge >标签来减少布局的嵌套层次网络优化：常见的网络优化方案如下尽量减少网络请求，能够合并的就尽量合并避免 DNS 解析，根据域名查询可能会耗费上百毫秒的时间，也可能存在DNS劫持的风险。可以根据业务需求采用增加动态更新 IP 的方式，或者在 IP 方式访问失败时切换到域名访问方式。大量数据的加载采用分页的方式网络数据传输采用 GZIP 压缩加入网络数据的缓存，避免频繁请求网络上传图片时，在必要的时候压缩图片安装包优化：安装包优化的核心就是减少 apk 的体积，常见的方案如下使用混淆，可以在一定程度上减少 apk 体积，但实际效果微乎其微减少应用中不必要的资源文件，比如图片，在不影响 APP 效果的情况下尽量压缩图片，有一定的效果在使用了 SO 库的时候优先保留 v7 版本的 SO 库，删掉其他版本的SO库。原因是在 2018 年，v7 版本的 SO 库可以满足市面上绝大多数的要求，可能八九年前的手机满足不了，但我们也没必要去适配老掉牙的手机。实际开发中减少 apk 体积的效果是十分显著的，如果你使用了很多 SO 库，比方说一个版本的SO库一共 10M，那么只保留 v7 版本，删掉 armeabi 和 v8 版本的 SO 库，一共可以减少 20M 的体积。Android 内存优化Android的内存优化在我看来分为两点：避免内存泄漏、扩大内存，其实就是开源节流。其实内存泄漏的本质就是较长生命周期的对象引用了较短生命周期的对象。常见的内存泄漏单例模式导致的内存泄漏。 最常见的例子就是创建这个单例对象需要传入一个 Context，这时候传入了一个 Activity 类型的 Context，由于单例对象的静态属性，导致它的生命周期是从单例类加载到应用程序结束为止，所以即使已经 finish 掉了传入的 Activity，由于我们的单例对象依然持有 Activity 的引用，所以导致了内存泄漏。解决办法也很简单，不要使用 Activity 类型的 Context，使用 Application 类型的 Context 可以避免内存泄漏。静态变量导致的内存泄漏。 静态变量是放在方法区中的，它的生命周期是从类加载到程序结束，可以看到静态变量生命周期是非常久的。最常见的因静态变量导致内存泄漏的例子是我们在 Activity 中创建了一个静态变量，而这个静态变量的创建需要传入 Activity 的引用 this。在这种情况下即使 Activity 调用了 finish 也会导致内存泄漏。原因就是因为这个静态变量的生命周期几乎和整个应用程序的生命周期一致，它一直持有 Activity 的引用，从而导致了内存泄漏。**非静态内部类导致的内存泄漏。**非静态内部类导致内存泄漏的原因是非静态内部类持有外部类的引用，最常见的例子就是在 Activity 中使用 Handler 和 Thread 了。使用非静态内部类创建的 Handler 和 Thread 在执行延时操作的时候会一直持有当前Activity的引用，如果在执行延时操作的时候就结束 Activity，这样就会导致内存泄漏。解决办法有两种：第一种是使用静态内部类，在静态内部类中使用弱引用调用Activity。第二种方法是在 Activity 的 onDestroy 中调用 handler.removeCallbacksAndMessages 来取消延时事件。使用资源未及时关闭导致的内存泄漏。常见的例子有：操作各种数据流未及时关闭，操作 Bitmap 未及时 recycle 等等。使用第三方库未能及时解绑。有的三方库提供了注册和解绑的功能，最常见的就 EventBus 了，我们都知道使用 EventBus 要在 onCreate 中注册，在 onDestroy 中解绑。如果没有解绑的话，EventBus 其实是一个单例模式，他会一直持有 Activity 的引用，导致内存泄漏。同样常见的还有 RxJava，在使用 Timer 操作符做了一些延时操作后也要注意在 onDestroy 方法中调用 disposable.dispose()来取消操作。属性动画导致的内存泄漏。常见的例子就是在属性动画执行的过程中退出了 Activity，这时 View 对象依然持有 Activity 的引用从而导致了内存泄漏。解决办法就是在 onDestroy 中调用动画的 cancel 方法取消属性动画。WebView 导致的内存泄漏。WebView 比较特殊，即使是调用了它的 destroy 方法，依然会导致内存泄漏。其实避免WebView导致内存泄漏的最好方法就是让WebView所在的Activity处于另一个进程中，当这个 Activity 结束时杀死当前 WebView 所处的进程即可，我记得阿里钉钉的 WebView 就是另外开启的一个进程，应该也是采用这种方法避免内存泄漏。扩大内存为什么要扩大我们的内存呢？有时候我们实际开发中不可避免的要使用很多第三方商业的 SDK，这些 SDK 其实有好有坏，大厂的 SDK 可能内存泄漏会少一些，但一些小厂的 SDK 质量也就不太靠谱一些。那应对这种我们无法改变的情况，最好的办法就是扩大内存。扩大内存通常有两种方法：一个是在清单文件中的 Application 下添加largeHeap="true"这个属性，另一个就是同一个应用开启多个进程来扩大一个应用的总内存空间。第二种方法其实就很常见了，比方说我使用过个推的 S DK，个推的 Service 其实就是处在另外一个单独的进程中。Android 中的内存优化总的来说就是开源和节流，开源就是扩大内存，节流就是避免内存泄漏。Binder 机制在Linux中，为了避免一个进程对其他进程的干扰，进程之间是相互独立的。在一个进程中其实还分为用户空间和内核空间。这里的隔离分为两个部分，进程间的隔离和进程内的隔离。既然进程间存在隔离，那其实也是存在着交互。进程间通信就是 IPC，用户空间和内核空间的通信就是系统调用。Linux 为了保证独立性和安全性，进程之间不能直接相互访问，Android 是基于 Linux 的，所以也是需要解决进程间通信的问题。其实 Linux 进程间通信有很多方式，比如管道、socket 等等。为什么 Android 进程间通信采用了Binder而不是 Linux已有的方式，主要是有这么两点考虑：性能和安全性能。 在移动设备上对性能要求是比较严苛的。Linux传统的进程间通信比如管道、socket等等进程间通信是需要复制两次数据，而Binder则只需要一次。所以Binder在性能上是优于传统进程通信的。安全。 传统的 Linux 进程通信是不包含通信双方的身份验证的，这样会导致一些安全性问题。而Binder机制自带身份验证，从而有效的提高了安全性。Binder 是基于 CS 架构的，有四个主要组成部分。Client。 客户端进程。Server。 服务端进程。ServiceManager。 提供注册、查询和返回代理服务对象的功能。Binder 驱动。 主要负责建立进程间的 Binder 连接，进程间的数据交互等等底层操作。Binder 机制主要的流程是这样的：服务端通过Binder驱动在 ServiceManager 中注册我们的服务。客户端通过Binder驱动查询在 ServiceManager 中注册的服务。ServiceManager 通过 inder 驱动返回服务端的代理对象。客户端拿到服务端的代理对象后即可进行进程间通信。LruCache的原理LruCache 的核心原理就是对 LinkedHashMap 的有效利用，它的内部存在一个 LinkedHashMap 成员变量。值得我们关注的有四个方法：构造方法、get、put、trimToSize。构造方法： 在 LruCache 的构造方法中做了两件事，设置了 maxSize、创建了一个 LinkedHashMap。这里值得注意的是 LruCache 将 LinkedHashMap的accessOrder 设置为了 true，accessOrder 就是遍历这个LinkedHashMap 的输出顺序。true 代表按照访问顺序输出，false代表按添加顺序输出，因为通常都是按照添加顺序输出，所以 accessOrder 这个属性默认是 false，但我们的 LruCache 需要按访问顺序输出，所以显式的将 accessOrder 设置为 true。get方法： 本质上是调用 LinkedHashMap 的 get 方法，由于我们将 accessOrder 设置为了 true，所以每调用一次get方法，就会将我们访问的当前元素放置到这个LinkedHashMap的尾部。put方法： 本质上也是调用了 LinkedHashMap 的 put 方法，由于 LinkedHashMap 的特性，每调用一次 put 方法，也会将新加入的元素放置到 LinkedHashMap 的尾部。添加之后会调用 trimToSize 方法来保证添加后的内存不超过 maxSize。trimToSize方法： trimToSize 方法的内部其实是开启了一个 while(true)的死循环，不断的从 LinkedHashMap 的首部删除元素，直到删除之后的内存小于 maxSize 之后使用 break 跳出循环。其实到这里我们可以总结一下，为什么这个算法叫 最近最少使用 算法呢？原理很简单，我们的每次 put 或者get都可以看做一次访问，由于 LinkedHashMap 的特性，会将每次访问到的元素放置到尾部。当我们的内存达到阈值后，会触发 trimToSize 方法来删除 LinkedHashMap 首部的元素，直到当前内存小于 maxSize。为什么删除首部的元素，原因很明显：我们最近经常访问的元素都会放置到尾部，那首部的元素肯定就是 最近最少使用 的元素了，因此当内存不足时应当优先删除这些元素。DiskLruCache原理设计一个图片的异步加载框架设计一个图片加载框架，肯定要用到图片加载的三级缓存的思想。三级缓存分为内存缓存、本地缓存和网络缓存。内存缓存：将Bitmap缓存到内存中，运行速度快，但是内存容量小。 本地缓存：将图片缓存到文件中，速度较慢，但容量较大。 网络缓存：从网络获取图片，速度受网络影响。如果我们设计一个图片加载框架，流程一定是这样的：拿到图片url后首先从内存中查找BItmap，如果找到直接加载。内存中没有找到，会从本地缓存中查找，如果本地缓存可以找到，则直接加载。内存和本地都没有找到，这时会从网络下载图片，下载到后会加载图片，并且将下载到的图片放到内存缓存和本地缓存中。上面是一些基本的概念，如果是具体的代码实现的话，大概需要这么几个方面的文件：首先需要确定我们的内存缓存，这里一般用的都是 LruCache。确定本地缓存，通常用的是 DiskLruCache，这里需要注意的是图片缓存的文件名一般是 url 被 MD5 加密后的字符串，为了避免文件名直接暴露图片的 url。内存缓存和本地缓存确定之后，需要我们创建一个新的类 MemeryAndDiskCache，当然，名字随便起，这个类包含了之前提到的 LruCache 和 DiskLruCache。在 MemeryAndDiskCache 这个类中我们定义两个方法，一个是 getBitmap，另一个是 putBitmap，对应着图片的获取和缓存，内部的逻辑也很简单。getBitmap中按内存、本地的优先级去取 BItmap，putBitmap 中先缓存内存，之后缓存到本地。在缓存策略类确定好之后，我们创建一个 ImageLoader 类，这个类必须包含两个方法，一个是展示图片 displayImage(url,imageView)，另一个是从网络获取图片downloadImage(url,imageView)。在展示图片方法中首先要通过 ImageView.setTag(url)，将 url 和 imageView 进行绑定，这是为了避免在列表中加载网络图片时会由于ImageView的复用导致的图片错位的 bug。之后会从 MemeryAndDiskCache 中获取缓存，如果存在，直接加载；如果不存在，则调用从网络获取图片这个方法。从网络获取图片方法很多，这里我一般都会使用 OkHttp+Retrofit。当从网络中获取到图片之后，首先判断一下imageView.getTag()与图片的 url 是否一致，如果一致则加载图片，如果不一致则不加载图片，通过这样的方式避免了列表中异步加载图片的错位。同时在获取到图片之后会通过 MemeryAndDiskCache 来缓存图片。Android中的事件分发机制