Android面试题汇总-RecyclerView、Fragment、WebView、性能优化等

一、RecyclerView

1、RecyclerView的多级缓存机制,每一级缓存具体作用是什么,分别在什么场景下会用到哪些缓存

RecyclerView的多级缓存机制是为了提高滚动和数据更新的效率而设计的。每一级缓存都有其特定的作用和使用场景。以下是各级缓存的作用和它们的使用场景：

一级缓存：mAttachedScrap 和 mChangedScrap
二级缓存：mCachedViews
三级缓存：ViewCacheExtension
四级缓存：RecycledViewPool

mAttachedScrap:
- 作用：这是一个ArrayList，用于存储暂时分离的子视图（Scrap view）。这些视图可以重复使用而不需要与RecyclerView完全分离。如果视图不需要重新绑定数据，就不会进行修改。
- 使用场景：在布局期间和数据更新时，这个缓存会被使用。
mChangedScrap:
- 作用：类似于mAttachedScrap，但它存放的是发生变化的ViewHolder。如果使用到了这里的缓存的ViewHolder，需要重新走Adapter的绑定方法。
- 使用场景：在数据有局部更新时使用。
mCachedViews:
- 作用：这是一个有容量限制的ArrayList，默认大小为2。它存放的是已经从RecyclerView中移除的视图，但ViewHolder仍然保存着之前的信息，如位置和绑定的数据等。
- 使用场景：在滚动过程中和预取（prefetch）时使用。
RecycledViewPool:
- 作用：这是一个全局的缓存池，可以跨多个RecyclerView共享。它用于存储不再需要的ViewHolder，任何绑定过的痕迹都没有了。当需要新的item时，可以从这个池中获取，并进行重用。
- 使用场景：在Item被移除、有更新或滚动过程中使用。
ViewCacheExtension:
- 作用：这是一个开发者可以自定义的缓存层级。官方没有默认实现，它允许开发者根据自己的需求来缓存ViewHolder。
- 使用场景：取决于开发者如何实现它。

通过有效地管理ViewHolder的缓存和重用，RecyclerView的多级缓存机制极大地提高了处理大量数据集时的性能和效率。

2、RecyclerView的滑动回收复用机制

RecyclerView的滑动回收复用机制是其核心功能之一，它允许应用高效地处理大量的数据集。这个机制确保了用户界面的流畅滚动，即使是在数据集非常大的情况下。

滑动和回收:
- 当用户滑动屏幕时，RecyclerView会检测到哪些项（item views）不再可见，并将这些项的ViewHolder回收到缓存中。这个过程称为回收（Recycling）。
- 回收的ViewHolder会被存放在一个叫做mCachedViews的缓存列表中。这个列表有一个固定的大小，当达到上限时，最早回收的ViewHolder会被移除并放入另一个缓存池，即RecycledViewPool。
复用:
- 当新的项需要显示在屏幕上时，RecyclerView会首先尝试从mCachedViews中复用ViewHolder。如果找到了合适的ViewHolder，就会直接使用它，而不需要重新创建一个新的。
- 如果mCachedViews中没有可用的ViewHolder，RecyclerView会转而从RecycledViewPool中寻找。RecycledViewPool是一个更大的缓存池，可以跨多个RecyclerView实例共享。
绑定数据:
- 一旦找到了一个可复用的ViewHolder，RecyclerView会通过调用Adapter的onBindViewHolder方法来绑定新的数据。这个过程称为绑定（Binding）。
- 绑定数据是必要的步骤，因为虽然ViewHolder可能是复用的，但显示的数据需要是当前项的数据。
LayoutManager的角色:
- LayoutManager负责决定屏幕上项的布局方式。它也参与回收和复用的过程，因为它知道哪些项不再可见，以及何时需要新的项来填充屏幕。
优化:
- RecyclerView还包含了其他优化措施，比如预取（Prefetching），它会在后台线程中提前绑定数据，以减少滚动时的延迟。

通过这种方式，RecyclerView能够快速地回收和复用ViewHolder，从而实现高效的滚动性能。这个机制是Android开发中非常重要的优化手段，它使得即使是数据量巨大的列表也能够流畅地滚动。

3、RecyclerView的刷新回收复用机制

RecyclerView的刷新回收复用机制是其核心特性之一，它允许应用程序高效地处理和显示大量数据。这个机制主要包括以下几个步骤：

刷新（Refresh）:
- 当数据集发生变化时，例如通过notifyDataSetChanged()方法，RecyclerView会被通知需要刷新。
- 刷新操作会导致RecyclerView重新绑定和布局视图，但尽可能地利用已有的ViewHolder进行数据绑定，以避免不必要的视图创建。
回收（Recycle）:
- 当滑动RecyclerView时，屏幕上不再可见的视图会被回收到缓存中。
- 回收的视图不会立即被销毁，而是存放在缓存中，等待复用。
复用（Reuse）:
- 当需要显示新的数据项时，RecyclerView会首先尝试从缓存中查找可复用的ViewHolder。
- 如果缓存中有合适的ViewHolder，就会直接使用它并绑定新的数据，而不是创建一个新的ViewHolder。

RecyclerView的回收复用机制涉及到几个关键的缓存结构：

mCachedViews: 这是一个临时缓存，用于存放最近被回收的ViewHolder。它的默认大小为2，但可以根据需要调整。
RecycledViewPool: 这是一个更大的缓存池，用于存放不同类型的ViewHolder。它允许不同的RecyclerView共享ViewHolder，从而提高复用效率。
ViewCacheExtension: 这是一个可选的缓存扩展点，开发者可以自定义缓存策略，以适应特定的复用需求。

在刷新过程中，RecyclerView会尽量复用已有的ViewHolder，减少创建和销毁视图的开销，从而提高性能和流畅度。这个机制确保了即使在数据频繁更新的情况下，用户界面也能保持流畅的滚动体验。

4、RecyclerView 为什么要预布局

RecyclerView 的预布局用于 Item 动画中，也叫做预测动画。其用于当 Item 项进行变化时执行的一次布局过程（如添加或删除 Item 项），使 ItemAnimator 体验更加友好。

考虑以下 Item 项删除场景，屏幕内的 RecyclerView 列表包含两个 Item 项：item1 和 item2。当删除 item2 时，item3 从底部平滑出现在 item2 的位置：

+-------+                       +-------+
|       | <-----+               |       | <-----+
| item1 |       |               | item1 |       |
|       |       |               |       |       |
+-------+     screen   ---->    +-------+     screen
|       |       |               |       |       |
| item2 |       |               | item3 |       |
|       | <-----+               |       | <-----+
+-------+                       +-------+

上述效果是如何实现的呢？我们知道 RecyclerView 只会布局屏幕内可见的 Item，对于屏幕外的 item3，如何知道其要运行的动画轨迹呢？要形成轨迹，至少需要知道起始点，而 item3 的终点位置是很明确的，也就是被删除的 item2 位置。那起点是如何确定的呢？

对于这种情况，RecyclerView 会进行两次布局：

第一次被称为 pre-layout，也就是预布局。在这一阶段，RecyclerView 将不可见的 item3 也加载进布局内，得到 [item1, item2, item3] 的布局信息。
之后再执行一次 post-layout，得到 [item1, item3] 的布局信息。比对两次 item3 的布局信息，也就确定了 item3 的动画轨迹了。

这个预布局的过程使得 ItemAnimator 能够更好地执行动画，提升用户体验。

5、ListView 与 RecyclerView区别

ListView 和 RecyclerView 都是 Android 中用于展示列表数据的组件，但它们在设计和功能上有一些关键的区别。以下是 ListView 和 RecyclerView 的主要区别：

缓存机制:
- ListView 有一个基本的缓存机制，它通过重用屏幕外的视图来优化性能。
- RecyclerView 引入了一个更复杂的缓存系统，包括四级缓存，使得视图的重用和数据更新更加高效。
布局管理:
- ListView 默认只支持垂直滚动的列表。
- RecyclerView 通过 LayoutManager 支持更多样化的布局，如线性布局、网格布局和瀑布流布局。
ViewHolder 的使用:
- 在 ListView 中，开发者需要自定义 ViewHolder 并使用 setTag() 和 getTag() 方法来优化视图的重用。
- RecyclerView 有一个规范化的 ViewHolder 使用方式，不需要 setTag() 和 getTag() 方法。
数据更新:
- ListView 在数据更新时通常使用 notifyDataSetChanged() 方法，这会导致整个列表刷新。
- RecyclerView 允许局部数据更新，如 notifyItemChanged()，这样可以提高性能和用户体验。
动画和装饰:
- RecyclerView 提供了丰富的动画 API 和装饰功能，可以轻松添加分隔线、动画等。
- ListView 的动画和装饰功能较为有限。
触摸反馈:
- RecyclerView 通过 ItemTouchHelper 支持拖动和滑动操作，这在 ListView 中不是原生支持的。
嵌套滚动:
- RecyclerView 实现了嵌套滚动机制，可以与其他滚动容器（如 ViewPager）更好地协同工作。
- ListView 没有实现嵌套滚动机制。

6、RecyclerView性能优化

当涉及到 Android 中的列表展示时，RecyclerView 是一个常用的组件。它的性能对用户体验至关重要。

数据优化

分页加载和数据缓存：
- 对于远程数据，建议进行分页加载，并对拉取的数据进行缓存。这样可以提高二次加载速度。
- 使用 DiffUtil 来局部刷新新增或删除的数据，而不是全局刷新整个列表。DiffUtil 是 Android Support 库中的一个工具类，用于判断新旧数据的差异，从而进行局部刷新。
分离数据处理和视图绑定：
- 在 RecyclerView.Adapter 的 onBindViewHolder 方法中，应该只是将数据设置到视图中，而不应进行耗时的业务处理。例如，避免在此方法中进行日期比较和格式化操作。

布局优化

减少过度绘制：
- 减少布局层级，可以考虑使用自定义 View 来减少层级，或者更合理地设置布局来减少层级。
- 注意：目前不推荐在 RecyclerView 中使用 ConstraintLayout，因为在某些版本中性能表现不佳。
减少 XML 文件的 Inflate 时间：
- XML 文件包括 layout 和 drawable 的 XML，它们的 Inflate 操作是耗时的 I/O 操作。
- 可以考虑使用代码生成布局，即通过 new View() 的方式来创建布局。
减少 View 对象的创建：
- 复杂的列表项可能包含大量的 View，而 View 的创建会消耗时间。因此，尽量简化 ItemView，设计共用的部分，减少 View 的构造和嵌套。
设置高度固定：
- 如果列表项的高度是固定的，可以使用 RecyclerView.setHasFixedSize(true) 来避免不必要的 requestLayout 操作。
共用 RecycledViewPool：
- 在嵌套的 RecyclerView 中，如果子 RecyclerView 具有相同的适配器，可以设置共用一个 RecycledViewPool。
- 注意：如果使用的是 LinearLayoutManager 或其子类，需要手动开启这个特性。

二、Fragment

1、Fragment的生命周期（结合Activity的生命周期）

在 Android 开发中，理解 Fragment 的生命周期及其与 Activity 生命周期的关系是非常重要的。Fragment 的生命周期与 Activity 紧密相关，但也有其独特的回调方法。以下是 Fragment 生命周期的一个概述，结合了 Activity 的生命周期：

onAttach():
- 当 Fragment 与 Activity 关联时调用。
- 这是 Fragment 生命周期的第一个回调。
onCreate():
- 用于进行 Fragment 的初始创建。
- 在这里可以初始化除了视图以外的组件。
onCreateView():
- 创建并返回与 Fragment 关联的视图层次结构。
- 这是设置 Fragment 布局的地方。
onActivityCreated():
- 当 Activity 完成 onCreate() 方法后调用。
- 可以在这里进行最终的初始化，如检索视图和恢复状态。
onStart():
- 当 Fragment 对用户可见时调用。
- Activity 的 onStart() 也会被调用。
onResume():
- 当 Fragment 开始与用户交互时调用。
- Activity 的 onResume() 也会被调用。
onPause():
- 当 Fragment 不再与用户交互时调用。
- Activity 的 onPause() 也会被调用。
onStop():
- 当 Fragment 不再对用户可见时调用。
- Activity 的 onStop() 也会被调用。
onDestroyView():
- 允许 Fragment 清理与其视图关联的资源。
onDestroy():
- 对 Fragment 的状态进行最终清理。
onDetach():
- 当 Fragment 不再与 Activity 关联时调用。

在整个过程中，Activity 的生命周期回调会影响 Fragment 的状态。例如，当 Activity 进入 onPause() 时，所有的 Fragments 也会进入 onPause() 状态。同样，当 Activity 被销毁时，所有的 Fragments 也会经历 onDestroy() 和 onDetach()。

Fragment 的每个生命周期阶段都是管理 Fragment 状态的关键点，确保资源被正确管理，并且用户体验是连贯的。了解这些生命周期方法如何与 Activity 的生命周期方法相互作用，对于创建稳定和响应迅速的 Android 应用至关重要。

2、Activity和Fragment的通信方式， Fragment之间如何进行通信

在 Android 中，Activity 和 Fragment 之间的通信可以采用多种方式。

使用 Bundle 和 setArguments：
- 在 Activity 中创建 Fragment 时，可以通过 Bundle 将数据传递给 Fragment。这样，Fragment 可以在其生命周期内访问这些数据。
- 步骤：
  1. 在 Activity 的布局文件中定义 Fragment 占位符（例如 FrameLayout）。
  2. 创建需要添加的 Fragment 实例。
  3. 创建一个 Bundle 对象，将数据放入其中。
  4. 将 Bundle 设置到 Fragment 中。
  5. 动态添加 Fragment 到 Activity 中。
接口回调：
- 在 Fragment 中定义一个接口，包含需要通信的抽象方法。
- 在 Activity 中实现该接口，并具体实现接口中的方法。
- 在 Fragment 中调用接口方法，从而实现通信。
ViewModel：
- 使用 ViewModel 是一种常见的通信方式。
- 在 Activity 或父 Fragment 中创建共享的 ViewModel 实例。
- 在需要通信的 Fragment 中获取 ViewModel 实例，然后观察 LiveData 或调用 ViewModel 中的方法。
Result API：
- 自 Fragment 1.3.0-alpha04 起，FragmentManager 新增了 FragmentResultOwner 接口，用于实现 Fragment 之间的通信。
- 通过 setFragmentResultListener 监听 Fragment 返回的数据，然后在另一个 Fragment 中处理这些数据。

3、为什么使用Fragment.setArguments(Bundle)传递参数

在 Android 中，使用 Fragment.setArguments(Bundle) 来传递参数是一种推荐的做法。虽然直接通过构造方法传递参数也是可行的，但官方更倾向于使用 setArguments 方法。

Activity 重建时的问题：
- 当 Activity 由于配置变化（例如横竖屏切换）而重新创建时，它所管理的 Fragment 也会重新构建。
- 如果你直接在构造方法中传递参数，那么在 Fragment 重新创建时，之前传递的参数将会丢失，因为系统会调用默认的无参构造方法来创建 Fragment。
- 使用 setArguments 方法传递参数可以避免这个问题，因为 Bundle 中的数据会在 Fragment 重建时保留下来。
setArguments 方法的工作原理：
- setArguments 方法将参数存储在 Fragment 的内部 Bundle 中。
- 这个 Bundle 会与 Fragment 关联，即使 Fragment 重新创建，也能保持参数的状态。

示例对比：

假设你有一个自定义的 Fragment 类 MyFragment，需要传递一个参数。

方式一：通过构造方法传递参数

public class MyFragment extends Fragment {
    public MyFragment(String parameter) {
        // 将参数保存起来
    }
}

方式二：使用 setArguments方法传递参数

public class MyFragment extends Fragment {
    public static MyFragment newInstance(String parameter) {
        MyFragment myFragment = new MyFragment();
        Bundle args = new Bundle();
        args.putString("someParameter", parameter);
        myFragment.setArguments(args);
        return myFragment;
    }
}

总之，官方推荐使用 Fragment.setArguments(Bundle) 这种方式来传递参数，以确保参数在 Fragment 重建时不会丢失。

4、FragmentPageAdapter和FragmentStatePageAdapter区别及使用场景

FragmentPagerAdapter 和 FragmentStatePagerAdapter 都是用于在 ViewPager 中管理 Fragment 的适配器，但它们在处理 Fragment 的方式上有所不同。

FragmentPagerAdapter：
- FragmentPagerAdapter 适用于那些相对静态的、数量较少的 Fragment 页面，如使用选项卡界面时。
- 它会将所有的 Fragment 实例保留在内存中，即使它们不是可见的。因此，当用户在页面间切换时，页面状态可以快速恢复。
- 由于所有的 Fragment 都保存在内存中，所以不适合用于大量 Fragment 的情况，因为会增加内存消耗。
FragmentStatePagerAdapter：
- FragmentStatePagerAdapter 适合用于有大量 Fragment 页面的情况，特别是当这些页面需要频繁地进入和退出用户视线时。
- 它只保留当前页面及其相邻页面的状态，在页面不可见时，会销毁 Fragment 的视图并释放资源。
- 当用户返回到之前访问过的页面时，FragmentStatePagerAdapter 会重新创建页面视图。

使用场景：

如果你的 ViewPager 只有少数几个页面，且这些页面不太可能被系统回收，那么 FragmentPagerAdapter 是一个好选择。
如果你的 ViewPager 需要承载大量的页面，或者页面的创建和销毁是一个频繁的过程，那么 FragmentStatePagerAdapter 更加合适。

5、Fragment懒加载

Fragment懒加载是一种优化技术，用于在 Android 应用中延迟加载和初始化 Fragment 的内容，以提高应用性能和用户体验。其核心思想是只有在 Fragment 可见时才加载数据和执行相关操作，而不是在 Fragment 创建或添加到 Activity 时立即加载。

以下是懒加载的一般实现方式和流程：代理+反射模式

创建 Fragment：
- 在创建 Fragment 时，不立即加载数据或执行耗时操作。
- 只进行必要的初始化工作，如获取布局视图等。
生命周期方法：
- 在 Fragment 的生命周期方法中，特别是 onCreateView()、onResume()、onPause() 等方法中实现懒加载逻辑。
可见性判断：
- 在 onResume() 方法中判断 Fragment 是否可见，可以使用 isVisible() 方法、getUserVisibleHint() 方法或自定义标志位进行判断。
加载数据：
- 当 Fragment 可见时，根据需要加载数据和执行相关操作，如从网络获取数据、查询数据库、更新 UI 等。

下面是一个简单的示例代码，展示了如何实现 Fragment 懒加载：

public class LazyLoadFragment extends Fragment {
    private boolean isDataLoaded = false; // 标记数据是否已加载
    private boolean isFragmentVisible = false; // 标记 Fragment 是否可见

    // 其他生命周期方法...

    @Override
    public void onResume() {
        super.onResume();
        if (!isDataLoaded && isFragmentVisible) {
            loadData(); // 加载数据
            isDataLoaded = true;
        }
    }

    @Override
    public void setUserVisibleHint(boolean isVisibleToUser) {
        super.setUserVisibleHint(isVisibleToUser);
        isFragmentVisible = isVisibleToUser;
        if (!isDataLoaded && isVisibleToUser) {
            loadData(); // 加载数据
            isDataLoaded = true;
        }
    }

    private void loadData() {
        // 执行数据加载操作，如从网络获取数据、查询数据库等
        // 更新 UI
    }
}

懒加载可以有效地减少不必要的资源消耗，提高应用性能和用户体验。特别是在使用 ViewPager 等容器来管理 Fragment 时，懒加载可以避免预加载的 Fragment 一开始就加载数据，只有当用户真正切换到该 Fragment 时才进行加载，节省了时间和资源。然而，懒加载也可能存在一些问题和注意事项：

数据一致性：懒加载可能导致数据更新不及时，如果在可见性判断之后发生了数据变化，可能需要在重新可见时重新加载数据以确保数据的一致性。
生命周期处理：由于懒加载会涉及到 Fragment 的生命周期方法，需要注意处理好与其他生命周期方法的配合和调用顺序，以避免出现逻辑错误或内存泄漏。
Fragment 嵌套：在使用嵌套 Fragment 时，需要考虑父 Fragment 和子 Fragment 之间的可见性传递和数据加载逻辑，确保懒加载的正确性。

总之，Fragment 懒加载是一种有效的性能优化技术，可以延迟加载和初始化 Fragment 的内容，提升应用性能和用户体验。在实际开发中，需要根据具体的业务需求和场景来合理使用和处理懒加载，以避免出现数据不一致或逻辑错误的情况。

6、ViewPager2与ViewPager区别

当谈到 Android 中的页面滑动组件时，ViewPager2 和 ViewPager 是两个常见的选择。

功能和优势:
- ViewPager2是 ViewPager的进阶版本，具有更多新功能和改进。以下是 ViewPager2的一些优势：
  - 使用 RecyclerView：ViewPager2 使用 RecyclerView 来管理视图，因此它能够高效地处理内存使用，并且支持视图的回收和复用。这是一个重要的特性，因为它有助于减少内存占用。
  - 数据集变更动画：ViewPager2 支持数据集变更动画，例如当使用 DiffUtil 来通知适配器数据集发生变化时，它会自动处理动画效果。
  - 垂直方向支持：与传统的水平滑动相比，ViewPager2 还支持垂直滑动。你可以通过设置 android:orientation="vertical" 来启用垂直滑动。
  - 右到左布局支持：ViewPager2 支持从右到左的布局（RTL）滑动。你可以通过设置 android:layoutDirection="rtl" 来启用 RTL 布局。
  - 可修改的片段集合：ViewPager2 支持通过可修改的片段集合进行分页，当底层集合发生变化时，调用 notifyDatasetChanged() 可以更新 UI。
  - DiffUtil 支持：由于 ViewPager2 是基于 RecyclerView 构建的，因此它可以直接使用 RecyclerView 的 DiffUtil 工具类，从而获得数据集变更动画的好处。
使用方式:
- 如果你的应用程序已经在使用 ViewPager，那么迁移到 ViewPager2 是一个不错的选择，因为 ViewPager2 正在积极开发，而 ViewPager 则不再得到支持。
- 如果你的应用程序尚未使用 ViewPager，而你想要在应用中使用分页功能，那么直接选择 ViewPager2 也是一个不错的选择。

总之，ViewPager2 是一个更先进、更强大的页面滑动组件，具有更多功能和改进，因此在大多数情况下，我建议你使用 ViewPager2。

三、WebView

1、如何提高WebView加载速度

提高 WebView 加载速度是优化 Android 应用性能的重要方面。以下是一些提升 WebView 加载速度的方法：

预加载技巧:
- 在应用启动时提前初始化 WebView 并进行预加载，可以减少 WebView 首次加载页面的时间。例如，可以在应用的启动过程中将 WebView 加入到 IdleHandler 中，等到主线程空闲的时候进行加载。
请求优化:
- 并行请求：在加载 H5 页面时，可以在 H5 加载模板文件的同时，由 Native 端发起请求获取正文数据。一旦数据获取成功，Native 端通过 JavaScript 将数据传递给 H5 页面，从而实现并行请求，减少总耗时。
- 拦截请求：可以通过自定义 WebViewClient 来拦截 WebView 的请求。重写 shouldInterceptRequest 方法，可以拦截所有 WebView 的请求，然后进行相应的处理。
缓存优化:
- WebView 缓存池：预先创建的 WebView 实例存储在内存中，并在需要加载网页时从缓存池中获取可用的 WebView 实例，而不是每次都创建新的 WebView。
- 缓存策略：合理设置 WebView 的缓存策略，根据应用的特点选择适合的缓存类型和策略。
渲染优化:
- 启用硬件加速：通过 setLayerType() 方法启用硬件加速，提高 WebView 的渲染性能。
- 减少 JavaScript、CSS 和 HTML 文件的大小：可以使用 minify 或 uglify 工具。
其他优化:
- 使用 WebP 格式图片：WebP 是一种高效的图片格式，使用 WebP 格式图片可以减少图片大小，提高网页加载速度。
- 避免过度重定向：尽量避免网页过多的重定向，减少不必要的网络请求，从而加快页面加载速度。
- 优化 JavaScript 代码：JavaScript 代码的性能对网页加载速度有重要影响。可以使用 JavaScript 代码压缩工具来减少代码大小，并优化 JavaScript 代码的执行。

2、WebView与 js的交互

WebView 与 JavaScript 的交互是 Android 混合开发中的一个重要功能，它允许原生代码与网页中的 JavaScript 代码相互通信。以下是实现 WebView 与 JavaScript 交互的几种方法：

Android 调用 JavaScript:
- 通过 loadUrl() 方法: 可以通过 WebView 的 loadUrl()方法直接调用 JavaScript 代码。例如：
```
webView.loadUrl("javascript:yourJavaScriptFunction()");
```
- 通过 evaluateJavascript() 方法: 这个方法允许你执行 JavaScript 并且异步获取执行结果。例如：
```
webView.evaluateJavascript("javascript:yourJavaScriptFunction()", null);
```
JavaScript 调用 Android:
- 通过 addJavascriptInterface() 方法: 你可以将一个 Java 对象映射到 JavaScript 中，这样 JavaScript 就可以调用该 Java 对象的方法。例如：
```
webView.addJavascriptInterface(new WebAppInterface(), "Android");
```
  然后在 JavaScript 中，你可以这样调用 Android 方法：
```
Android.yourJavaMethod();
```
- 通过 shouldOverrideUrlLoading() 方法: JavaScript 可以通过加载一个特殊的 URL 来请求 Android 做一些操作，然后在 WebViewClient 的 shouldOverrideUrlLoading() 方法中拦截这个 URL。
- 通过 onJsAlert(), onJsConfirm(), onJsPrompt() 方法: 这些方法允许你拦截 JavaScript 的弹窗，并在 Android 中处理。
注意事项:
- 使用 addJavascriptInterface() 方法时需要特别注意安全问题，因为 JavaScript 可以访问注入对象的所有公共方法。在 Android 4.2 以上版本，需要在公共方法上添加 @JavascriptInterface 注解来暴露给 JavaScript。

这些方法为 Android 应用与网页内容之间提供了强大的交互能力。你可以根据你的具体需求选择合适的方法来实现交互。

3、WebView的漏洞

WebView 是 Android 中用于显示网页的组件，但在使用过程中可能存在一些安全漏洞。

远程代码执行漏洞:
- 在 Android API level 17 之前的系统版本中，存在一个远程代码执行漏洞。攻击者可以利用 Java 反射 API 通过 addJavascriptInterface() 接口执行任意 Java 对象的方法。这可能导致手机被安装木马程序、发送扣费短信、通讯录和短信被窃取等安全问题。
文件协议跨域访问漏洞:
- 如果 setAllowFileAccessFromFileURLs 或 setAllowUniversalAccessFromFileURLs 被设置为 true，允许 file 域访问 HTTP 域，但未对 file 域的路径进行严格限制，可能会导致应用克隆攻击。
SSL证书校验漏洞:
- 如果 WebView 组件在加载网页时发生证书认证错误，而 onReceivedSslError 方法实现调用了 handler.proceed() 来忽略该证书错误，则可能受到中间人攻击的威胁，导致隐私泄露。
明文存储漏洞:
- WebView 默认开启密码保存功能，如果用户选择保存在 WebView 中输入的用户名和密码，则会被明文保存到应用数据目录的 databases/webview.db 中。如果手机被 root，则可以获取明文保存的密码，造成用户的个人敏感数据泄露。

为了防范这些漏洞，建议开发者采取以下措施：

对于远程代码执行漏洞，确保不在 WebView 中暴露任何敏感的 Java 方法。
对于文件协议跨域访问漏洞，不要允许 file 域访问 HTTP 域，或者对 file 域的路径进行严格限制。
对于 SSL 证书校验漏洞，不要忽略证书错误，而是采取适当的错误处理措施。
对于明文存储漏洞，不要在 WebView 中保存用户的用户名和密码，或者使用加密方式存储。

4、JSBridge原理

JSBridge，顾名思义，是一座用于连接 JavaScript 和原生应用的桥梁。它允许开发者在 Web 页面中调用原生应用的 API，从而实现与原生应用的无缝交互。通过 JSBridge，Web 页面可以调用原生应用的功能，如摄像头、定位、文件系统等，弥补了 Web 技术在移动开发中的不足。

JSBridge 工作原理

JSBridge 的工作原理主要基于消息传递机制。它允许双向通信，即 Web 页面可以向原生应用发送消息，原生应用也可以向 Web 页面发送消息。

具体实现方式如下：

Native 向 Web 发送消息:
- 在 Android 中，可以通过 loadUrl("javascript:yourJavaScriptFunction()") 或 evaluateJavascript("javascript:yourJavaScriptFunction()", null) 来执行 JavaScript 代码。
- 在 iOS 中，可以通过 stringByEvaluatingJavaScript(from: "yourJavaScriptFunction()") 或 evaluateJavaScript("yourJavaScriptFunction()", completionHandler: nil) 来执行 JavaScript 代码。
Web 向 Native 发送消息:
- 通常有两种实现方式：
  - 拦截式：Native 拦截 Web 发出的 URL 请求，约定一个 JSBridge 请求格式，如果请求是 JSBridge，则进行相应处理。
  - 注入式：在 Web 页面中注入一个全局的 JavaScript 对象，供 Web 页面调用，然后 Native 端监听该对象的方法调用。
实践案例:
- 例如，Web 页面需要调用原生相册功能，可以通过 JSBridge 向原生应用发送消息，触发相册功能并获取结果。

总之，JSBridge 是连接 JavaScript 和原生应用的关键桥梁，使得 Web 和原生应用之间可以实现双向通信。

四、MVP、MVC、MVVM

1、 MVC及其优缺点

在Android开发中，MVC（Model-View-Controller）是一种常见的架构模式，用于将应用程序的数据处理（Model）、用户界面（View）和业务逻辑（Controller）分离，以实现更好的代码组织和可维护性。

MVC的优点:

分工明确：各个组件有明确的职责，有助于代码的组织和管理。
降低耦合性：视图层和业务逻辑层分离，使得视图代码可以独立于模型代码变化。
便于测试：由于分离，可以独立测试模型和控制器逻辑。
重用性高：模型代码可以在不同的视图中重用。

MVC的缺点:

视图与控制器耦合：虽然视图和模型分离，但视图与控制器之间通常还是存在较强的耦合。
Activity职责过重：在Android中，Activity既承担视图的角色也承担控制器的角色，导致Activity代码臃肿。
更新界面复杂：当模型数据变化时，更新界面可能需要复杂的逻辑和多次的视图状态检查。
可维护性问题：随着应用逻辑的增加，控制器的代码量可能会迅速增长，使得维护变得困难。

在实际开发中，MVC模式可能会根据具体项目的需求进行调整和优化。例如，可以通过引入ViewModel来减少Activity的负担，或者使用DataBinding来简化视图和模型之间的数据同步。

2、MVP及其优缺点

MVP（Model-View-Presenter）是Android开发中常用的一种架构模式，它是对MVC模式的改进。在MVP中，Presenter成为了核心，它从View中分离出业务逻辑，而View只负责展示数据。这里是MVP的一些优缺点：

MVP的优点:

逻辑清晰：Presenter处理所有的业务逻辑，减少了Activity的负担，使得代码更加清晰。
解耦合：Model层与View层完全分离，修改View不会影响Model，降低了耦合性。
重用性：可以将一个Presenter用于多个视图，而不需要改变Presenter的逻辑。
便于测试：Presenter与View的交互是通过接口进行的，便于单元测试。

MVP的缺点:

代码量增加：每个功能点都需要一个Presenter类，以及大量的接口和回调，导致代码量增加。
维护成本：页面逻辑复杂时，相应的接口也会变多，增加维护成本。
内存泄漏风险：Presenter中持有View的引用，可能导致内存泄漏。
UI更新耦合：对视图的渲染放在了Presenter中，视图需要改变时，Presenter也需要跟着改变。

在实际开发中，选择合适的架构模式需要根据项目的具体需求和团队的熟悉程度来决定。MVP模式提供了良好的业务逻辑与界面显示的分离，但也带来了一定的复杂性。

3、MVVM及其优缺点

MVVM（Model-View-ViewModel）是Android开发中的一种架构模式，它通过ViewModel来实现数据和业务逻辑与视图的分离。以下是MVVM的优缺点：

MVVM的优点:

双向绑定：ViewModel与View之间的数据绑定可以自动同步，减少了手动更新UI的代码。
低耦合：Model与View的分离使得代码更易于维护和扩展。
可测试性：由于业务逻辑被封装在ViewModel中，它更容易进行单元测试。
提高开发效率：开发者可以专注于业务逻辑，而不是UI代码的编写。

MVVM的缺点:

复杂性增加：引入ViewModel增加了架构的复杂性，对于小型项目可能显得过于繁琐。
内存消耗：长期持有大型Model可能导致内存消耗增加。
调试困难：数据绑定可能导致调试时难以追踪问题的源头。
重用性降低：由于绑定了特定的Model，重用View可能会受到限制。

MVVM通过其数据绑定和组件分离的特性，为Android应用提供了一个强大的架构模式，尤其适合于复杂的应用程序开发。然而，它也带来了一定的学习曲线和性能考虑。

4、MVC与MVP区别

MVC（Model-View-Controller）和MVP（Model-View-Presenter）都是软件架构模式，用于分离应用程序的不同方面，以提高可维护性和可扩展性。它们在Android开发中被用来组织代码结构，但有一些关键的区别：

MVC的特点:

Model：负责数据和业务逻辑。
View：负责显示数据（用户界面）。
Controller：作为Model和View之间的中介，处理用户输入和系统输出。

在Android中，Activity或Fragment通常承担了Controller的角色，同时也包含了View的逻辑，这导致了一些问题，如Activity变得过于臃肿，以及View和Model之间的耦合性增加。

MVP的特点:

Model：同MVC，负责数据和业务逻辑。
View：同MVC，负责显示数据。
Presenter：取代了MVC中的Controller，直接与Model交互，并更新View。

MVP的主要区别在于Presenter的引入。在MVP中，Presenter完全从View中分离出业务逻辑，而View只负责显示数据。这样做减少了View（如Activity或Fragment）的职责，使其更加轻量化，并且Presenter可以通过接口与View交互，这提高了代码的测试性和重用性。

总的来说，MVP相比于MVC，更加强调了View和Model的分离，使得View层更加简洁，而Presenter层则承担了更多的逻辑处理工作。这种分离使得代码更易于测试和维护，但也可能导致Presenter层变得复杂。

5、MVP如何管理Presenter的生命周期，何时取消网络请求

在MVP（Model-View-Presenter）架构中，管理Presenter的生命周期以及何时取消网络请求是非常重要的，以避免内存泄漏和其他潜在问题。以下是一些常见的做法：

绑定生命周期：可以使用Android的Lifecycle组件来绑定Presenter的生命周期到Activity或Fragment的生命周期。这样，当Activity或Fragment被销毁时，可以在Presenter中的对应生命周期方法中取消网络请求和其他相关操作。
使用接口回调：Presenter可以通过定义接口回调与View层通信。当View层即将被销毁时，例如在onDestroy()方法中，可以通知Presenter停止当前的操作。
弱引用：Presenter持有View的引用时，可以使用弱引用（WeakReference）来避免内存泄漏。当View被销毁时，弱引用不会阻止垃圾回收器回收View对象。
取消网络请求：在Presenter的销毁方法中（如onDestroy()），应该取消所有未完成的网络请求。如果使用Retrofit等网络库，可以通过调用请求的cancel()方法来实现。
合理使用Presenter生命周期：并不是所有的Activity生命周期方法都需要通知Presenter。例如，如果某些操作只与Activity的可见性相关，那么只需要在onResume()和onPause()中处理即可。

通过以上方法，可以有效地管理Presenter的生命周期，并在适当的时机取消网络请求，以保持应用的健壮性和性能。

五、内存泄漏、内存溢出

1、什么是内存溢出、内存泄漏以及原因

内存泄漏（Memory Leak）：

定义：内存泄漏发生在已分配的堆内存无法被垃圾回收器（GC）回收，因为应用程序中的某些部分仍然持有这些对象的引用，即使它们已经不再需要或使用。

原因：

内部类引用：非静态内部类隐式持有对其外部类的引用，例如，一个非静态的Handler类可能会持有对其包含Activity的引用。
监听器注册：事件监听器或广播接收器如果没有被适当地注销，可能会导致内存泄漏，例如在EventBus中注册的事件。
上下文泄漏：错误地使用Activity的Context而不是ApplicationContext可能会导致泄漏。
单例模式：单例对象中的静态成员如果持有Activity的引用，可能会导致内存泄漏。
资源未关闭：未关闭的资源对象，如Cursor或File，可能会导致内存泄漏。
全局集合：全局集合类，特别是静态修饰的集合，如果没有适当地清理，可能会导致内存泄漏。

内存溢出（Out of Memory, OOM）：

定义：内存溢出是指程序尝试分配的内存超过了可用内存限制，导致分配失败。

原因：

堆内存溢出

：通常指的是堆内存溢出，可能由以下原因造成：
- 应用内存上限：应用进程达到内存上限。
- 系统内存不足：设备的可用内存不足，不一定是由于应用消耗过多内存。
应用内存上限

：应用内存达到上限可能由以下原因造成：
- 内存分配速度：内存分配的速度超过了垃圾回收器释放内存的速度，可能是由于加载过大的文件或图片，或者创建大量对象。
- 内存泄漏：内存泄漏导致垃圾回收器无法回收泄漏的内存，使得可用内存逐渐减少。

2、Thread是如何造成内存泄露的，如何解决？

在Android中，Thread可能会导致内存泄露，主要是因为以下几个原因：

长生命周期的对象持有线程的引用：如果一个拥有比Activity生命周期更长的对象持有Thread的引用，那么即使Activity已经结束，Thread依然不会被垃圾回收器回收，因为它仍然被长生命周期的对象所引用。
匿名内部类和非静态内部类：如果你在Activity中创建了一个匿名内部类或非静态内部类的Thread，那么这个Thread会隐式地持有外部类Activity的引用。如果Activity需要被销毁，而Thread还在运行，那么Activity就不会被回收，从而导致内存泄露。
静态变量：如果你将Thread声明为静态变量，那么它的生命周期将和应用程序的生命周期一样长。如果Thread持有Activity的引用，那么这个Activity在整个应用程序的生命周期内都不会被回收。

为了解决这些问题，你可以采取以下措施：

使用弱引用（WeakReference）：使用WeakReference来引用Activity，这样即使Thread的生命周期比Activity长，Activity也可以被垃圾回收器正常回收。
在Activity销毁时停止线程：在Activity的onDestroy()方法中停止正在运行的线程。
使用静态内部类：使用静态内部类来创建Thread，并通过弱引用来引用Activity，这样可以避免隐式地持有Activity的强引用。
使用HandlerThread或IntentService：对于需要在后台长时间运行的任务，可以考虑使用HandlerThread或IntentService，这些组件会在任务完成后自动停止，从而避免内存泄露。

3、Handler导致的内存泄露的原因以及如何解决

在Android中，Handler可能导致内存泄露，主要是因为以下几个原因：

非静态内部类：如果Handler是作为非静态内部类实现的，它会隐式持有外部类（通常是Activity或Fragment）的强引用。如果Activity或Fragment需要被销毁，而Handler还在执行，那么这些组件就不会被垃圾回收器回收，从而导致内存泄露。
延迟消息或运行：Handler发送的延迟消息或Runnable任务在执行前，如果Activity或Fragment已经被销毁，那么这些消息或任务仍然保持对它们的引用，这也会导致内存泄露。

为了解决这些问题，你可以采取以下措施：

使用静态内部类：将Handler作为静态内部类实现，并通过弱引用（WeakReference）来引用Activity或Fragment。这样可以避免隐式地持有外部类的强引用。
及时移除消息和回调：在Activity的onDestroy()方法中，确保移除所有的消息和回调，例如使用Handler.removeCallbacksAndMessages(null)。
使用View.post()：如果你只是想在View可见时执行一些操作，可以考虑使用View.post()方法，因为View会在不可见时自动移除所有的回调和消息。
使用ViewModel和LiveData：对于与生命周期相关的操作，可以使用ViewModel和LiveData，它们设计时就考虑了生命周期，可以帮助你更安全地管理数据和任务。

4、如何加载Bitmap防止内存溢出

在Android开发中，加载Bitmap时防止内存溢出是一个重要的考虑。以下是一些防止内存溢出的方法：

使用合适的图片格式：选择合适的图片格式可以减少内存占用。例如，webp格式提供了有损和无损压缩，通常比png和jpeg更小。
质量压缩：通过改变图片的位深和透明度来减小图片占用的磁盘空间大小，但这不会改变图片在内存中的大小。
采样率压缩：通过设置BitmapFactory.Options.inSampleSize，可以减小图片的分辨率，进而减小图片所占用的磁盘空间和内存大小。
缩放图片：减少图片的像素可以降低图片的磁盘空间大小和内存大小，适用于缓存缩略图。
使用inJustDecodeBounds：在解码图片之前，先设置BitmapFactory.Options.inJustDecodeBounds为true，这样可以获取图片的尺寸而不将其加载到内存中。
计算inSampleSize：根据目标View的大小和图片的尺寸计算出合适的inSampleSize值，以此来加载一个缩小版本的图片。
使用RGB_565：默认情况下，Bitmap使用ARGB_8888格式，每个像素占用4字节。改变配置为RGB_565，每个像素只占用2字节，适用于不需要透明度的图片。
及时回收：当不再需要某个Bitmap时，调用bitmap.recycle()来回收其占用的内存，尤其是在Activity销毁时。
使用Bitmap池：复用Bitmap对象可以减少内存分配和回收的频率，BitmapFactory.Options.inBitmap可以用来指定一个可复用的Bitmap。

5、MVP中如何处理Presenter层以防止内存泄漏的

在MVP（Model-View-Presenter）架构中，防止Presenter层导致的内存泄漏主要可以通过以下几种方式来处理：

弱引用（WeakReference）：Presenter层持有View层的引用时，可以使用弱引用来引用View。这样，即使Presenter生命周期较长，当View被销毁时，由于只是弱引用，垃圾回收器仍然可以回收View，从而避免内存泄漏。
生命周期管理：在View的onDestroy()方法中，通过Presenter来间接取消Model中的耗时任务，并将Presenter和Model的引用置空。这样可以确保当View被销毁时，相关的资源也会被释放。
避免非静态内部类：避免在Presenter中使用非静态内部类或匿名类，因为这些类会隐式持有外部类的引用，如果外部类是一个Activity或Fragment，那么可能会导致内存泄漏。
资源释放：在Presenter中提供一个资源释放的方法，比如destroy()或detachView()，并在View的生命周期结束时调用它，以确保释放Presenter持有的资源。
使用MVP框架：一些现成的MVP框架已经考虑了内存泄漏的问题，并提供了相应的解决方案。使用这些框架可以减少手动管理内存的负担。

首先 MVP 会出现内存泄漏是因为 Presenter 层持有 View 对象，一般我们会把 Activity 做为 View 传递到 Presenter，Presenter 持有 View对象，Activity 退出了但是没有回收出现内存泄漏。

解决办法：

Activity onDestroy() 方法中调用 Presenter 中的方法，把 View 置为 null
使用 Lifecycle

六、性能优化

1、Android内存优化

内存泄漏

常见内存泄漏场景：
- Handler 内存泄漏：在 Activity 中使用非静态内部类初始化 Handler 时，Handler 持有当前 Activity 的引用，导致 Activity 页面关闭后仍存在引用关系。
- 单例造成的内存泄漏：单例持有 Context 对象，如果在 Activity 中传入 this 时，单例会持有该 Activity 的引用，导致 Activity 退出后无法回收。
- 资源性对象未关闭，注册对象未注销：例如 Bitmap 等资源未关闭，BroadcastReceiver、EventBus 未注销，都可能导致内存泄漏。
- MVP 中的内存泄漏：Presenter 层持有 View 对象，如果在 Activity 退出时 Presenter 正在进行耗时操作，可能导致 Activity 无法回收。
- ViewPager + Fragment 内存泄漏：在 PagerAdapter 的 getItem() 方法中返回新的 Fragment 对象，避免持有 Fragment 的引用。
工具查找内存泄漏位置：
- LeakCanary：实时监测 Activity 或 Fragment 是否被回收，用于检测内存泄漏。
- Profiler：使用 Android Profiler 观察内存变化，查看实例和引用对象。

图片优化

Bitmap 内存占用计算：
- 对图片进行内存压缩：包括图片质量压缩、RGB_565 法、采样率压缩、Matrix 比例压缩。
- 高分辨率图片放入对应文件夹：不同 dpi 占用内存不同。
图片优化策略：
- 使用缓存：LruCache 和 DiskLruCache。
- 及时回收：释放不再使用的图片资源。
- 使用 ARTHook 检测加载的图片是否过大。

内存抖动

内存抖动会导致 OOM，解决方法包括减少不合理的对象创建、复用对象、避免在循环中不断创建局部变量。

实时监控工具

LeakCanary：用于测试环境，检测 Activity 和 Fragment 是否被回收，判断是否存在泄漏。
Matrix-ResourceCanary：基于 LeakCanary，裁剪 hprof 文件，增加误报优化，适用于生产环境。

2、启动优化

1. 统计启动时间的方式

使用以下命令来测量 Activity 的启动时间：
```
adb shell am start -S -R 10 -W com.ctg.and.mob.cuservice/com.ctg.and.mob.cuservice.mvp.ui.activity.MainActivity
```
- TotalTime 代表当前 Activity 的启动时间，多次测量并求平均可得到准确的启动时间。

2. 解决白屏问题

设置一个启动闪屏主题，使用与启动页相同的图片作为 android:windowBackground 属性，实现视觉上的无缝过渡。

3. 异步改造和线程池

使用线程池来处理初始化任务，避免无限制新建线程和资源竞争。
根据 CPU 核心数设置线程池的核心线程数，例如使用 Executors.newFixedThreadPool(CORE_POOL_SIZE)。

4. 启动器

将代码进行任务化，根据任务依赖关系生成有向无环图，多线程按优先级执行任务。
延迟启动器利用 IdleHandler 在主线程空闲时执行任务，不影响用户操作。

5. 首页优化

合并首页部分接口，减少网络请求次数。
优化首页布局。

3、布局优化

当涉及到 Android 布局优化时，这是一个关键的领域，它直接影响应用的性能、流畅度和用户体验。让我详细介绍一下 Android 中的布局优化策略：

1. 减少布局层级

使用 ConstraintLayout 作为根布局：ConstraintLayout 是一个强大的布局容器，可以减少布局嵌套层级，同时设置合理的约束条件。
使用 TextView 的 layout_weight 属性：通过权重设置，使文本视图根据内容自动调整大小。

2. 使用 ButterKnife 等库简化视图查找和事件绑定操作

ButterKnife 是一个方便的库，可以简化视图查找和事件绑定的代码。它使用注解来自动生成视图绑定的代码，减少了手动查找视图的工作量。

3. 避免过度绘制

使用工具进行布局分析：
- Layout Inspector：用于查看当前布局层级。
- systrace：查看每一帧的时间和方法调用。
- Choreographer：接收垂直同步信号，可以用来计算帧率。

4. 使用 LayoutInflaterCompat.setFactory2

通过 LayoutInflaterCompat.setFactory2 方法，可以获取单个控件的加载耗时。这是一种兼容的 API，需要在 super.onCreate 之前调用。

总之，布局优化是一个综合性的工作，需要从布局层级、IO 操作、反射等多个方面入手，不断优化和改进。

4、卡顿优化

在Android开发中，卡顿优化是提升用户体验的关键部分。以下是一些主要的卡顿原因及其优化方案：

卡顿原因:

UI线程阻塞：耗时操作如计算、IO操作和网络请求应避免在UI线程执行。
内存泄漏：未及时释放对象和资源，如数据库连接和Bitmap对象，会导致内存泄漏。
图片加载不当：大图加载和频繁的图片加载未经优化会占用大量内存。
数据处理不当：使用不合适的数据结构和算法，或在主线程中处理大量数据。
网络请求不合理：长时间的网络请求会阻塞UI线程。

优化方案:

UI线程阻塞:
- 将耗时操作放在子线程中执行，使用Handler或AsyncTask更新UI。
- 使用Handler的postDelayed()方法延迟UI操作，减少刷新频率。
内存泄漏:
- 使用弱引用（WeakReference）避免持有Context的对象导致的内存泄漏。
- 及时释放资源，如关闭数据库连接和回收Bitmap对象。
图片加载不当:
- 使用图片加载库（如Glide、Picasso）进行图片压缩和内存缓存。
- 对大图使用BitmapFactory.Options进行压缩。
数据处理不当:
- 选择合适的数据结构和算法处理数据。
- 将数据处理操作放在子线程中执行。
网络请求不合理:
- 使用异步请求方式，如OkHttp的异步请求，避免阻塞UI线程。
- 设置合理的超时机制，减少网络请求对UI的影响。

5、网络优化

在Android开发中，网络优化是提高应用性能和用户体验的重要方面。以下是一些关键的网络优化策略：

减少网络请求:
- 使用缓存策略，避免不必要的网络请求。
- 合并多个网络请求，减少服务器连接次数。
优化数据传输:
- 对发送和接收的数据进行压缩，如使用Gzip压缩。
- 使用更高效的数据格式，如Protocol Buffer代替JSON。
改善网络连接:
- 使用IP直连代替DNS解析，减少解析时间。
- 优化TCP/IP参数，如窗口大小和重传超时时间。
异步处理:
- 使用异步机制处理网络请求，避免阻塞UI线程。
- 使用Android的Volley或Retrofit等网络库来管理异步请求。
网络监控和分析:
- 使用Android Studio的Network Monitor工具监控网络请求和性能。
- 使用网络代理工具如Charles或Wireshark分析网络请求和响应。
网络策略优化:
- 根据用户的网络状况（如WiFi或移动数据）调整网络请求策略。
- 在用户设备上预加载常用数据，减少实时网络请求。
图片和资源加载:
- 对图片资源进行适当的压缩和尺寸调整。
- 使用CDN服务缓存静态资源，加快加载速度。
服务器端优化:
- 服务器多地部署，减少用户访问延迟。
- 服务器端进行数据压缩和缓存处理。