kotlin 跨平台开发_使用Kotlin进行多平台开发

kotlin 跨平台开发

I wanted to experience Kotlin MultiPlatform development to understand the complexities involved in adopting this for Android and iOS projects. For this, I wanted to target a small use case and solve that by using Kotlin Multiplatform. In this article, I’ll share my observations with you as you take this journey with me.

我想体验Kotlin MultiPlatform开发，以了解在Android和iOS项目中采用它的复杂性。 为此，我想针对一个小用例，并通过使用Kotlin Multiplatform解决该问题。 在本文中，当您与我同行时，我将与您分享我的看法。

先决条件 (Prerequisites)

• I assume you have familiarity with Android & iOS development.
  我假设您熟悉Android和iOS开发。
• I assume you have sufficient exposure to Kotlin & Swift to understand DSL.
  我认为您对Kotlin＆Swift有足够的了解，可以理解DSL。

First, We’ll go through the problem, followed by one of the possible solutions to the problem and how we’ll use the MultiPlatform approach to solve the problem for Android and iOS, finally conclude by showing how we can use what we built in both platforms.

首先，我们将解决该问题，然后是该问题的可能解决方案之一，以及如何使用MultiPlatform方法来解决Android和iOS的问题，最后通过展示如何使用我们内置的内容来总结两个平台。

1.概述 (1. Overview)

During a fast-paced App Development cycle, we’ll encounter some problems. We’ll go through them briefly and define a goal we wanted to achieve.

在快速的App开发周期中，我们会遇到一些问题。 我们将简要介绍它们，并定义我们要实现的目标。

1.1问题 (1.1 Problem)

In this section, we’ll walk through four scenarios which can create bottlenecks.

在本节中，我们将介绍四种可能造成瓶颈的方案。

1.1.1 EnvironmentTo help understand the environment issue, the figure below shows the non-working environment in red and working environments in Green. An environment can be DEV, SIT, UAT or PROD. Given our App was pointing to red, we wanted to have the flexibility of switching the environments without performing a rebuild to triage if this issue is related to the environment as opposed to a code path within the App.

1.1.1环境为了帮助理解环境问题，下图显示了红色的非工作环境和绿色的工作环境。 环境可以是DEV，SIT，UAT或PROD。 鉴于我们的应用程序指向红色，因此，如果此问题与环境(而不是应用程序中的代码路径)有关，我们希望具有切换环境的灵活性，而无需执行重新构建以进行分类。

[1.1.1] Environment

[1.1.1]环境

1.1.2 FeatureTo understand the issue related to a non-working feature, the figure below shows our App as being composed of Feature blocks and the working features in Green. In contrast, the non-working feature in Red. Given we wanted to identify the problematic feature in Red, we wanted to have the flexibility to turn features on or off without performing a rebuild to triage the problem.

1.1.2功能要了解与无法使用的功能有关的问题，下图显示了我们的App由功能块和绿色的可用功能组成。 相反，红色中的无效功能。 鉴于我们要确定Red中有问题的功能，我们希望能够灵活地打开或关闭功能，而无需执行重建来对问题进行分类。

[1.1.2] Feature

[1.1.2]功能

1.1.3 Tuning ThresholdsConsider we wanted to adjust timing intervals in our App to make them perform better or appear suitable. The figure below shows an App contacting the API and receiving a response. If our timeout interval is too short, our App stops listening soon on the other hand if it is long our App waits for a long time and when this wait is on a critical path of the App, we’ll see a notable lag in our App’s performance. To predict the correct values, we wanted to have a flexibility of adjusting the timeout values to identify what works for our App better, without having to rebuild our App each time.

1.1.3调整阈值考虑我们想在App中调整时间间隔，以使其表现更好或看起来更合适。 下图显示了一个与API联系并收到响应的应用。 如果我们的超时间隔太短，则如果我们的应用很长一段时间，那么我们的应用就会立即停止监听，而如果等待时间很长，并且当此等待处于应用的关键路径上时，我们会发现我们的响应明显滞后应用程序的性能。 为了预测正确的值，我们希望能够灵活地调整超时值，从而确定对我们的App更有效的方法，而不必每次都重新构建App。

[1.1.3] Tuning Thresholds

[1.1.3]调整阈值

1.1.4 Dynamic ValueConsider we wanted to edit a configuration value to test a change quickly without having to rebuild our App. To illustrate this scenario, the figure below shows our App pointing to a non-existing domain example.com while we wanted to perform a quick check to ensure the new domain global.example.com works as expected.

1.1.4动态值考虑到我们想编辑配置值以快速测试更改，而无需重建我们的应用程序。 为了说明这种情况，下图显示了我们的应用程序指向一个不存在的域example.com，而我们想执行一次快速检查以确保新域global.example.com可以正常工作。

[1.1.4] Dynamic Value

[1.1.4]动态值

1.2目标 (1.2 Goal)

Having gone through the concerns mentioned above, let us define our goal, as shown below:

克服了上述问题后，让我们定义目标，如下所示：

“Given that the App has the necessary code. we wanted to change how the App behaves once deployed on the device with minimal effort.”

“鉴于该应用具有必要的代码。 我们希望更改应用程序在设备上部署后的行为方式。”

2.解决方案 (2. Solution)

Considering our goal, we wanted the flexibility to edit the configuration of our App once deployed. For this, we’ll place a Configuration Entry Point(CEP) in the launcher of our App, that allows us to update the configuration before the Main App is loaded. To illustrate this with an example, the diagram below shows launcher having two entry points to our App, the one shown in Green is the Main Entry Point(MEP) to our App. In contrast, the one shown in yellow allows us to customise the settings before launching the MEP.

考虑到我们的目标，我们希望在部署后能够灵活地编辑应用程序的配置。 为此，我们将在应用程序的启动器中放置一个配置入口点 (CEP)，这使我们能够在加载主应用程序之前更新配置。 为了举例说明，下图显示了具有两个应用程序入口点的启动器，绿色显示的是应用程序的主要入口点 (MEP)。 相比之下，黄色显示的内容使我们可以在启动MEP之前自定义设置。