其他分享
首页 > 其他分享> > Android架构组件-App架构指南,2021我是如何拿到小米、京东、字节的offer

Android架构组件-App架构指南,2021我是如何拿到小米、京东、字节的offer

作者:互联网

这一切的要点在于,您的 app组件 可以单独和无序地启动,并且可以在任何时候由用户或系统销毁。由于 app组件 是短暂的,并且它们的生命周期(创建和销毁时)不在您的控制之下,因此您不应该在app组件中存储任何 app数据或状态,并且 你的 app组件不应相互依赖。

通用架构原则


如果你不使用 app组件存储app数据和状态,那么应该如何构造应用程序呢?

你关注的最重要的事情是如何在你的应用中分离关注点。常见的错误是将所有的代码写入一个Activity或Fragment,任何不处理 UI 或 与操作系统交互的代码都不应该出现在这些类中,你应该尽可能保持 Activity或Fragment 精简,这样可以避免许多生命周期相关的问题。请记住,你不拥有这些类,它们只是建立操作系统和你的应用程序之间契约的胶水类。Android操作系统可能会随时根据用户交互或其他因素(如低内存)来销毁它们。最好尽可能地减少依赖他们,以提供可靠的用户体验。

第二个重要原则是 你应该从一个模型驱动你的UI,最好是一个持久化的模型。之所以说持
久化是理想的模型,原因有两个:如果操作系统销毁你的应用程序以释放资源,那么你的用户就不会丢失数据,即使网络连接不稳定或连接不上,您的应用程序也会继续工作。模型是负责处理应用程序数据的组件。它们独立于应用程序的 Views 和 app组件,因此模型与这些 app组件的生命周期问题是相隔离的。保持简洁的UI代码,以及不受约束的应用程序逻辑,可以使app的管理更加容易,基于具有明确定义的管理数据责任的模型类的应用程序,会更加具有可测试性,并使您的应用程序状态保持前后一致。

推荐的App架构


在本节中,我们将演示如何通过使用用例来构造使用了 架构组件(Architecture Components) 的应用程序。

注意:不可能有一种对每个场景都是最好的编写应用程序的方法。也就是说,对于大多数用例来说,这个推荐的架构可能是一个好的起点。如果你已经有了编写Android应用的好方法,那就不要在更改了。

我们现在可以想象一下,假如我没正在搭建一个用来显示 用户概况的UI。该用户概况将使用 REST API从我们自己的服务器端获取。

搭建用户界面

这个UI 将由 UserProfileFragment.java 及 Fragment 相应的 user_profile_layout.xml 布局文件组成。

为了驱动用户界面,我们的数据模型需要保存两个数据元素。

我们将创建一个基于ViewModel 的 UserProfileViewModel 类来保存这些信息。

一个 ViewModel 提供了一个特定 UI 组件中的数据,如一个 fragment 或 activity, 并且负责与数据处理业务的通信,例如调用其他app组件来加载数据或转发的用户信息的修改。ViewModel不知道View,并且不受配置更改的影响,例如由于屏幕旋转而重新创建 Activity。

现在我们有3个文件。

接下来我们将开始实现(为了简单起见,省略了布局文件):

public class UserProfileViewModel extends ViewModel {

private String userId;
private User user;

public void init(String userId) {
this.userId = userId;
}

public User getUser() {
return user;
}
}

public class UserProfileFragment extends Fragment {
private static final String UID_KEY = “uid”;
private UserProfileViewModel viewModel;

@Override
public void onActivityCreated(@Nullable Bundle savedInstanceState) {
super.onActivityCreated(savedInstanceState);
String userId = getArguments().getString(UID_KEY);
viewModel = ViewModelProviders.of(this).get(UserProfileViewModel.class);
viewModel.init(userId);
}

@Override
public View onCreateView(LayoutInflater inflater,
@Nullable ViewGroup container, @Nullable Bundle savedInstanceState) {
return inflater.inflate(R.layout.user_profile, container, false);
}
}

现在,我们已经有了三个代码块,那么我们如何将它们联系在一起呢?毕竟,当给 ViewModel 的用户字段设值后,我们需要一种方法来通知用户界面,这就是 LiveData 类的作用。

LiveData 是一个可观察的数据持有者。它允许应用程序中的组件观察 LiveData 对象的更改,但不会在它们之间创建明确的和严格的依赖关系路径。 LiveData 还会关联 app组件(activities, fragments, services) 的生命周期状态,并做出合适的事情来防止内存泄漏。


注意:如果你已经在使用类似 RxJavaAgera 的库 ,则可以继续使用它们而不是LiveData。但是,当你使用它们或其他方式时,请确保正确处理生命周期,以便在相关的LifecycleOwner 停止时暂停数据流,并在销毁 LifecycleOwner 时销毁数据流。你还可以添加 android.arch.lifecycle:reactivestreams 以将 LiveData 与其他的响应流库(例如RxJava2)一起使用。

现在我们用 LiveData 替换 UserProfileViewModel 中的 User字段,以便在数据更新时通知 Fragment。最主要的是,LiveData 是生命周期感知的,并且在不在需要时,它将自动清理引用。

public class UserProfileViewModel extends ViewModel {

private User user;
private LiveData user;

public LiveData getUser() {
return user;
}
}

现在我们修改 UserProfileFragment 以便观察数据并更新 UI。

@Override
public void onActivityCreated(@Nullable Bundle savedInstanceState) {
super.onActivityCreated(savedInstanceState);
viewModel.getUser().observe(this, user -> {
// update UI
});
}

每次更新用户数据时, 都会调用 onChanged 回调,并刷新UI。

如果你熟悉其他 可观察回调的库,你可能已经意识到,我们没有重写 fragment 的 onStop() 方法来停止观察数据。这对于 LiveData 来说是没有必要的,因为它是生命周期感知的,这意味着它不会调用回调,除非Fragment 处于 活动状态(已收到 onStart() 但未收到 onStop())。当 fragment 收到 onDestroy() 时,LiveData也将自动移除观察者 。

对于配置变化(例如,用户旋转屏幕)我们也没有做任何特殊的处理。当配置改变时,ViewModel 会自动恢复,所以一旦新的 Fragment 生效,它将接收到相同的 ViewModel实例,并且 ViewModel 的回调将立即被当前数据调用,这就是 ViewModels 为什么不应该直接引用 Views 的原因。他们可以比 View的生命周期更持久。想了解更多信息的请查看 The lifecycle of a ViewModel

获取数据


现在我们已经将 ViewModel 关联到了 Fragment,但是 ViewModel 如何获取用户数据呢?在这个例子中,我们假设服务器端提供了一个 REST API。我们将使用 Retrofit 库来访问我们的服务器端,虽然你可以自由使用不同的库来达到同样的目的。

下面是retrofit 的 Webservice ,负责与服务器端进行通信:

public interface Webservice {
/**

ViewModel 的一个简单实现是直接调用 Webservice 来获取数据并将其 赋值给 user 对象,虽然这样是可行的,但是你的应用程序以后将很难维护。它赋予了 ViewModel 类太多的职责,违背了我们前面提到的关注点分离原则。此外,ViewModel 的作用域与一个 Activity 或一个 Fragment 生命周期相关联,当他们的生命周期完成时将丢失所有的数据,这是非常糟糕的用户体验。因此,我们将 ViewModel 的这个工作委托给了一个新的模块 Repository

Repository 模块负责数据处理操作。他们为应用的其余部分提供了一个干净的API,他们知道从何处获取数据以及在更新数据时调用哪些API。你可以将它们视为不同数据源 (持久化模型, web服务, 缓存, etc.)之间的中介。

UserRepository 类使用 WebService 来获取用户数据项,如下:

public class UserRepository {

private Webservice webservice;
// …
public LiveData getUser(int userId) {
// This is not an optimal implementation, we’ll fix it below
final MutableLiveData data = new MutableLiveData<>();
webservice.getUser(userId).enqueue(new Callback() {
@Override
public void onResponse(Call call, Response response) {
// error case is left out for brevity
data.setValue(response.body());
}
});
return data;
}
}

虽然 repository 模块看起来没有必要,但是它有一个重要的目的,它从应用程序的其余部分提取数据源。现在我们的 ViewModel 不知道数据是从 Webservice 获取到的,这意味着我们可以根据需要,将它(Webservice)替换为其他的实现。

注意:为了简单起见,我们忽略了网络错误的情况。对于暴露错误和加载状态的另一个实现,请查看 附录:暴露网络状态

管理组件之间的依赖关系:

上面的 UserRepository 类需要一个 Webservice 的实例来工作,UserRepository 可以简单地创建Webservice ,但要做到这一点,它必须需要知道 Webservice 类的依赖关系来构造它,这会使代码显著和成倍的复杂化(例如,每个需要 Webservice实例的类 都需要知道如何用它的依赖来构造它)。另外,UserRepository 可能不是唯一需要 Webservice 的类。如果每个类创建一个新的 WebService,这将是非常沉重的资源。

现在我们有两种模式可以用来解决这个问题:

这些模式允许您扩展代码,因为它们提供了用于管理依赖关系的清晰模式,无需复制代码或增加复杂性。这两个模式也允许交换实现测试, 这是使用它们的主要好处之一。

在这个例子中,我们将使用 依赖注入 来管理依赖关系。

关联ViewModel和repository


现在我们修改 UserProfileViewModel 使用的 repository。

public class UserProfileViewModel extends ViewModel {

private LiveData user;
private UserRepository userRepo;

@Inject // UserRepository parameter is provided by Dagger 2
public UserProfileViewModel(UserRepository userRepo) {
this.userRepo = userRepo;
}

public void init(String userId) {
if (this.user != null) {
// ViewModel is created per Fragment so
// we know the userId won’t change
return;
}
user = userRepo.getUser(userId);
}

public LiveData getUser() {
return this.user;
}
}

缓存数据


上面的 repository 实现 对抽象调用 Web服务是有好处的,但是因为它只依赖于一个数据源,所以它不是很有用。

UserRepository 实现的问题是,在获取数据之后,它不保存在任何地方。如果用户离开 UserProfileFragment 并返回,应用程序将重新获取数据。这是不好的,原因有两个:浪费宝贵的网络带宽并强制用户等待新的查询完成。为了解决这个问题,我们将添加一个新的数据源到 UserRepository ,这个数据源可以将 User 对象 缓存 到内存中。

@Singleton // informs Dagger that this class should be constructed once
public class UserRepository {
private Webservice webservice;
// simple in memory cache, details omitted for brevity
private UserCache userCache;
public LiveData getUser(String userId) {
LiveData cached = userCache.get(userId);
if (cached != null) {
return cached;
}

final MutableLiveData data = new MutableLiveData<>();
userCache.put(userId, data);
// this is still suboptimal but better than before.
// a complete implementation must also handle the error cases.
webservice.getUser(userId).enqueue(new Callback() {
@Override
public void onResponse(Call call, Response response) {
data.setValue(response.body());
}
});
return data;
}
}

持久化数据


在我们当前的实现中,如果用户旋转屏幕或离开并返回到应用,现有UI将立即可见,因为 repository 从内存中检索缓存的数据。但是,如果用户离开应用程序并且数小时后回来,或Android 系统杀死该进程后,会发生什么?

在目前的实现中,我们将需要从网络上重新获取数据。这不仅是一个糟糕的用户体验,而且会浪费,因为它会使用移动数据重新获取相同的数据。你可以简单地通过缓存Web请求来解决这个问题,但是这会产生新的问题。如果相同的用户数据从另一种类型的请求中显示出来(例如,获取朋友列表),会发生什么情况?那么你的应用程序可能会显示不一致的数据,这是一个混乱的用户体验。例如,由于好友列表请求和用户请求可以在不同的时间执行,所以相同用户的数据可能会以不同的方式显示。您的应用需要合并它们以避免显示不一致的数据。

处理这个问题的正确方法是使用 持久化模型。这就是 Room 持久化库可以拯救的地方。

Room 是一个对象映射库,使用最小的样板代码来提供本地数据持久化。在编译时,它会根据模式验证每个查询,因此,有问题的SQL查询会导致编译时出错,而不是运行时失败。Room 抽象了处理原始SQL表和查询的一些底层实现细节。它还允许观察对数据库数据(包括集合和 join 查询)的更改,通过 LiveData对象 公开这些更改 。另外,它明确定义了解决常见问题的线程约束,例如在主线程上的访问存储。


注意:如果你的应用程序已经使用另一个持久化解决方案(如SQLite对象关系映射(ORM)),则不需要使用 Room 替换现有的解决方案。但是,如果您正在编写新的应用程序或重构现有的应用程序,我们建议使用 Room 来保存应用程序的数据。这样,您可以利用库的抽象和查询 验证功能。

要使用 Room,我们需要定义我们的本地模式。首先,使用 @Entity 注解 User 类 以将其标记为数据库中的表。

@Entity
class User {
@PrimaryKey
private int id;
private String name;
private String lastName;
// getters and setters for fields
}

然后,为你的app创建一个数据库类继承于 RoomDatabase

@Database(entities = {User.class}, version = 1)
public abstract class MyDatabase extends RoomDatabase {
}

注意 MyDatabase 是抽象的。Room 自动提供一个 它的实现。有关详细信息,请查看 Room 文档

现在我们需要一种将用户数据插入数据库的方法。为此,我们将创建一个数据访问对象(DAO

@Dao
public interface UserDao {
@Insert(onConflict = REPLACE)
void save(User user);
@Query(“SELECT * FROM user WHERE id = :userId”)
LiveData load(String userId);
}

然后,从我们的数据库类中引用 DAO (Data Access Object)

@Database(entities = {User.class}, version = 1)
public abstract class MyDatabase extends RoomDatabase {
public abstract UserDao userDao();
}

请注意,该 load 方法返回一个 LiveData。Room 知道数据库何时被修改,当数据改变时它会自动通知所有活动的的察者。因为它使用的是 LiveData,所以这将是有效的,因为只有至少有一个活动的观察者才会更新数据。

注意:Room 根据 table 的修改来检查失效,这意味着它可能发送误报的通知。

现在我们可以修改我们的 UserRepository 来包含 Room 数据源。

@Singleton
public class UserRepository {
private final Webservice webservice;
private final UserDao userDao;
private final Executor executor;

@Inject
public UserRepository(Webservice webservice, UserDao userDao, Executor executor) {
this.webservice = webservice;
this.userDao = userDao;
this.executor = executor;
}

public LiveData getUser(String userId) {
refreshUser(userId);
// return a LiveData directly from the database.
return userDao.load(userId);
}

private void refreshUser(final String userId) {
executor.execute(() -> {
// running in a background thread
// check if user was fetched recently
boolean userExists = userDao.hasUser(FRESH_TIMEOUT);
if (!userExists) {
// refresh the data
Response response = webservice.getUser(userId).execute();
// TODO check for error etc.
// Update the database.The LiveData will automatically refresh so
// we don’t need to do anything else here besides updating the database
userDao.save(response.body());
}
});
}
}

请注意,尽管我们改变了 来自于 UserRepository 的数据,我们并不需要改变我们 UserProfileViewModel或 UserProfileFragment。这是抽象提供的灵活性。这对于测试来说有好处的,因为你可以在测试你的UserProfileViewModel 的时候提供一个假的 UserRepository 。

现在我们的代码是完整了。如果用户以后回到相同的用户界面,他们会立即看到用户信息,因为我们持久化了。同时,如果数据过期了,我们的仓库将在后台更新数据。当然,根据您的使用情况,如果数据太旧,您可能不希望显示持久化数据。

在一些使用情况下,如 下拉刷新,UI 显示用户是否正在进行网络操作是非常重要的。将UI 操作与实际数据分开是一个很好的做法,因为它可能因各种原因而导致更新(例如,如果我们获取朋友列表,同一用户可能会再次触发 LiveData 更新)。站在UI 的角度,事实上,当有一个请求执行的时候,另一个数据点,类似于任何其他的数据 (比如 User 对象)。

这个用例有两种常见的解决方案:

单一的真相来源:

不同的 REST API 端点通常返回相同的数据。例如,如果我们的服务器端拥有另一个返回 朋友列表的端点,则同一个用户对象可能来自两个不同的API 端点,也许粒度不同。如果 UserRepository 从 Webservice请求返回原本的响应,我们的UI可能会显示不一致的数据,因为在这些请求过程中数据可能已经在服务器端发生了改变。这就是为什么在 UserRepository 实现中,Web服务回调只是将数据保存到数据库中。然后,对数据库的更改将触发回调给 活动的 LiveData对象

在这个模型中,数据库充当了 单一的真相来源,应用程序的其他部分通过 Repository 访问它。无论你是否使用磁盘缓存,我们都建议将你的 Repository 指定为应用程序其余部分唯一的真相来源。

测试


我们已经提到分离的好处之一就是可测试性,让我们看看如何测试每个代码模块。

标签:UserRepository,架构,Webservice,offer,App,ViewModel,userId,LiveData,public
来源: https://blog.csdn.net/m0_66145060/article/details/122492357