swift获取应用包名_Swift软件包如何改变我构建应用程序的方式

swift获取应用包名

介绍 (Introduction)

Even though we’ve had dependency managers for several years now, with Swift Package Manager (SPM), creating packages in your app is almost as easy as adding new folders. Converting parts of your project to packages is not just a way to organize your code nicely; it actually changes the way you work and architect your app.

即使我们已经有依赖管理器几年了，使用Swift Package Manager (SPM)，在您的应用程序中创建包几乎与添加新文件夹一样容易。 将项目的某些部分转换为包不仅是一种很好地组织代码的方法； 它实际上改变了您的工作方式和架构应用程序。

It all started when I had to take an existing big project and port one feature to a dedicated app. Since this feature is based on a low-level code, such as networking, persistent store, analytics, and logging, I thought it would be best to check how to convert those parts to modules.

当我不得不承担一个现有的大项目并将一个功能移植到专用应用程序时，一切就开始了。 由于此功能基于网络，持久性存储，分析和日志记录等底层代码，因此我认为最好检查如何将这些部分转换为模块。

I planned to:

我计划：

• Copy all this code to the new app
  将所有这些代码复制到新应用中
• Organize the code in Swift Packages
  在Swift包中组织代码
• Take the packages and implement them back into the “mother” app
  提取软件包并将其实施回“母亲”应用中
• Put the packages on their own repositories in GitHub and have shared code
  将软件包放在GitHub上自己的存储库中并共享代码

I knew that having code shared between apps is a great way to maintain them over time. What I didn’t realize was that even without putting those packages on GitHub and sharing them, using modules (packages/Pods, whatever you want to call it) brings additional value to your app.

我知道在应用之间共享代码是随着时间的推移维护它们的好方法。 我没有意识到的是，即使不将这些程序包放在GitHub上并共享它们，使用模块(程序包/ Pods，无论您想称呼什么)也能为您的应用带来额外的价值。

乐高玩 (Playing With Lego)

Most standard iOS apps are built from one big codebase and some third-party libraries. Organizing your code into packages changes all that. It makes your app development process feels like playing with Lego bricks. Do you want an app with the same foundation but a different UI? No problem, easy to set up. You want the today widget to take advantage of the excellent logging mechanism you created? Piece of cake. Everything is modular and easy to maintain.

大多数标准的iOS应用程序都是基于一个大型代码库和一些第三方库构建的。 将代码组织到软件包中将改变所有这些。 它使您的应用程序开发过程像玩乐高积木一样。 您是否想要具有相同基础但不同UI的应用程序？ 没问题，易于设置。 您想使用今天创建的窗口小部件来利用您创建的出色的日志记录机制吗？ 小菜一碟。 一切都是模块化的，易于维护。

Take a look at the following diagram:

看下图：

Image source: Author

图片来源：作者

Except for the UI, all the other components are, in fact, packages. The diagram also reflects the dependencies between them. The logger and some help methods bundled to a common library are the low layer of the project. They do not depend on anything, but the other packages need them. So we have a network and persistent store packages that require the common and logger modules to function.

除了UI，其他所有组件实际上都是软件包。 该图还反映了它们之间的依赖性。 记录器和捆绑到公共库中的一些帮助方法是项目的底层。 它们不依赖任何东西，但是其他软件包则需要它们。 因此，我们有一个网络和持久性存储程序包，它们需要common和logger模块才能起作用。

Then we move to the sync, which obviously needs the network and the persistent store, and so on with the other modules.

然后，我们转到同步，这显然需要网络和持久性存储，以及其他模块等等。

If you built one or two apps in your life, this diagram is not new. Most apps are actually built like that but with groups. With modules, it’s more clear and transparent.

如果您一生中构建了一个或两个应用程序，则此图并不新鲜。 实际上，大多数应用都是按照这样的方式构建的，但是具有分组功能。 使用模块，它更加清晰透明。

模块使您的图层界面更清晰 (Modules Make Your Layers Interface Clearer)

Because each part of your app is a module, the process of building modules forces you to really plan and design the interfaces between them. You need to make important design decisions, and you need to decide what functions are public — oh, finally, it has meaning inside your app! — and what the dependencies are. By looking at the diagram above, you can see that you cannot import the analytics package into the persistent store library. I’m not sure it’s even possible, but surely it’s not a best practice.

因为应用程序的每个部分都是一个模块，所以构建模块的过程迫使您真正计划和设计它们之间的接口。 您需要做出重要的设计决策，还需要确定哪些功能是公开的-哦，最后，它在您的应用程序中具有意义！ —以及依赖关系是什么。 通过查看上图，您可以看到您无法将分析程序包导入持久性存储库。 我不确定这是否有可能，但是肯定不是最佳实践。

Actually, without drawing the diagram, it’s hard to define the dependencies, so we’ve also earned … a diagram?

实际上，如果不绘制图表，则很难定义依赖关系，因此我们也获得了……图表？

您现在有几个小问题，而不是一个大问题 (You Now Have Several Small Problems Instead of a Giant One)

This is part of something called dynamic programming. Everybody knows that solving a small problem is easier than solving a big one. Splitting your app to small modules makes it easier for you to solve issues in your code.

这是所谓的动态编程的一部分 。 众所周知，解决小问题比解决大问题容易。 将应用程序拆分为小模块，可以使您更轻松地解决代码中的问题。

In fact, your app can be in a state that it’s not even compiled (!), and you can still work on a specific module, compile it, write tests, and make any modifications you want. It’s also clear what part of your app you need to work on, now that your project is built of SDKs.

实际上，您的应用程序甚至可能处于未编译状态(！)，并且您仍可以在特定模块上工作，对其进行编译，编写测试以及进行所需的任何修改。 既然您的项目是由SDK构建的，那么也很清楚您需要处理应用程序的哪一部分。

编译是如此的可笑，现在是如此之快 (Compiling Is So Fast Now That It’s Ridiculous)

You know when you do a small change, and then you wait 30–40 seconds for your project to compile? Well, those days are (almost) over.

您知道什么时候进行小的更改，然后等待30–40秒才能编译项目？ 好吧，那些日子(几乎)结束了。

As I just mentioned, you can compile a specific module, and oh man, it is so fast, you do it again just to make sure something actually happened. Compiling a particular module is easy: Just select it from the scheme pop-up menu:

正如我刚才提到的，您可以编译一个特定的模块，噢，伙计，它是如此之快，您再次执行此操作只是为了确保确实发生了某些事情。 编译特定模块很容易：只需从方案弹出菜单中选择它：

I don’t think I need to explain why compile-time has a significant impact on your daily life as a developer. There’s no way to go back.

我认为不需要解释为什么编译时会对您作为开发人员的日常生活产生重大影响。 没有回头路了。

立即测试所有内容，甚至包括Apple Watch Extension (It’s Straightforward to Test Everything Now, Even Your Apple Watch Extension)

And this is a continuation of the previous point: The benefit of separation is not only compiled time but also testing.

这是先前观点的延续：分离的好处不仅是编译时间而且是测试。

Every module has its own tests:

每个模块都有自己的测试：

The fact that the tests are located just below the execution code, plus the fast compilation, encourages you to add a lot of tests to your app (module). Heck, sometimes it’s the only way to check that your module works since, in many cases, you do it when your app doesn’t even compile.

测试位于执行代码的下方，加上快速编译的事实，鼓励您向应用程序(模块)添加很多测试。 哎呀，有时这是检查模块是否正常的唯一方法，因为在许多情况下，您甚至在应用程序甚至没有编译时就执行此操作。

Also, it’s the only way to test an Apple Watch, through its modules.

而且，这是通过其模块测试Apple Watch的唯一方法。

What about the actual app tests? Now that you have independent modules, which are being tested internally, you can start doing something called integration tests, i.e., test how your modules work together.

实际的应用测试如何？ 现在，您已经拥有正在内部进行测试的独立模块，您可以开始执行称为集成测试的工作 ，即， 测试模块如何协同工作。

Remember, when you share your package with another app, its tests go with it. So it’s another something you save, some of the tests for the new app.

请记住，当您与另一个应用程序共享软件包时，它的测试也会随之进行。 因此，这是您要保存的另一项内容，其中包括新应用程序的一些测试。

是的，毫不费力地共享代码 (Yes, It’s Effortless to Share Code)

After all, the main reason for a Swift package is to share code between projects. Look at the dependencies from the manifest file:

毕竟，Swift软件包的主要原因是在项目之间共享代码。 查看清单文件中的依赖项：

You see? You can define a dependency as a local package, or download it from Git. You can just upload your package to GitHub, change the manifest, and you’re done!

你看？ 您可以将依赖项定义为本地包，或从Git下载。 您只需将包上传到GitHub，更改清单，就可以完成！

SPM(Swift软件包管理器)有其缺点 (SPM (Swift Package Manager) Has Its Drawbacks)

SPM still has its drawbacks:

SPM仍然有其缺点：

• You cannot add any resource files to your package, not even a Xib file. It means that building UI has to be done from code and building a persistent store library based on core data might be an issue since core data needs to make use of the model file (although you can bypass it somehow). Swift 5.3 is planned to solve this.
  您不能将任何资源文件添加到包中，甚至不能添加Xib文件。 这意味着必须通过代码来构建UI，并且基于核心数据来构建持久性存储库可能是一个问题，因为核心数据需要利用模型文件(尽管您可以以某种方式绕过它)。 Swift 5.3已计划解决此问题。
• A Swift Package can be depended on another Swift Package, not Pods or your app code. The problem is that not all the essential frameworks have support for SPM, so you need to solve this somehow using delegates or closures.
  一个Swift软件包可以依赖于另一个Swift软件包，而不是Pods或您的应用程序代码。 问题在于，并非所有基本框架都支持SPM，因此您需要以某种方式使用委托或闭包来解决此问题。

If those are big issues for you, there are other ways of creating Swift packages.

如果这些对您来说是大问题，那么还有其他创建Swift软件包的方法。

摘要 (Summary)

Swift Package Manager has a way to go to be as usable and functional as CocoaPods or Carthage. But Xcode 11 makes it so easy that it makes no sense not to use it. Some of the things I wrote are also true for CocoaPods and Carthage; after all, the principles stay the same. No matter what you use, structuring your app with modules is always recommended

Swift Package Manager可以像CocoaPods或Carthage一样变得可用和功能强大 。 但是Xcode 11如此简单，以至于不使用它是没有意义的。 我写的一些东西对于CocoaPods和Carthage也是正确的。 毕竟，原则保持不变。 无论您使用什么，始终建议使用模块来构建应用程序

Thanks for reading!

谢谢阅读！

翻译自: https://medium.com/better-programming/how-swift-packages-changed-the-way-i-build-appsintroduction-fb4ade0f1cec

swift获取应用包名