ios 初级开发_我作为初级ios开发人员了解软件体系结构的旅程

2023-10-13 05:50

本文主要是介绍ios 初级开发_我作为初级ios开发人员了解软件体系结构的旅程,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

ios 初级开发

A beginner friendly approach to software architecture.

初学者友好的软件体系结构方法。

In this article I describe part of my journey as a junior iOS developer and some of the issues I faced and the solutions I came up with after some research.

在本文中,我描述了作为一名初级iOS开发人员的过程中的一部分旅程,以及我经过研究后遇到的一些问题和解决方案。

背景 (Background)

I began my journey as an iOS developer back in 2015 in a company that developed smart-watches and had a companion application to manage the watch both for Android and iOS. The project I inherited from “senior” iOS developers was built using Objective-C and had at least 200 files, most of them were UIViewController implementations for the multiple screens the app had. Build times were awful and the project had a really hard time scaling, objects had a lot of responsibilities and requests from upper management to add new features took way too much time and often seemed impossible. Looking for help in the iOS dev community I found that what I was facing at the time was very common among junior devs and it had a name, MassiveViewController.

我在2015年作为一家iOS开发人员开始了自己的旅程,当时该公司开发了智能手表,并拥有一个配套应用程序来管理Android和iOS手表。 我从“高级” iOS开发人员继承的项目是使用Objective-C构建的,并且至少具有200个文件,其中大多数是该应用程序具有多个屏幕的UIViewController实现。 构建时间很糟糕,项目很难扩展,对象承担很多责任,高层管理人员添加新功能的请求花费了太多时间,而且通常看起来是不可能的。 在iOS开发人员社区中寻求帮助时,我发现我当时面对的情况在初级开发人员中非常普遍,并且它的名称为MassiveViewController。

Apple encourages developers to use MVC in iOS apps, by its deep integration in UIKit. Following Apple’s MVC, junior developers wrongly put everything in the UIViewController like view layout, view updates, model manipulation, data access, networking, etc.

苹果通过与UIKit的深度集成,鼓励开发人员在iOS应用中使用MVC。 遵循Apple的MVC,初级开发人员错误地将所有内容放入UIViewController中,例如视图布局,视图更新,模型操纵,数据访问,联网等。

Looking for a solution, I became familiar with popular architectural patterns in the presentation layer that vary from MVC such as MVP and MVVM. As many junior devs in the community, I thought that the MV* variations mentioned before would fix my problem. And as other junior developers I made the mistake of trying to fit every object in the project in one of the categories that compose the acronym of the pattern of choice, i.e using MVVM, objects either were a Model, a ViewModel or a View.

在寻找解决方案时,我熟悉了表示层中流行的架构模式,这些模式与MVC(例如MVP和MVVM)不同。 与社区中的许多初级开发人员一样,我认为前面提到的MV *版本可以解决我的问题。 和其他初级开发人员一样,我犯了一个错误,即试图将项目中的每个对象放入组成选择模式首字母缩写的类别之一中,即使用MVVM,对象是模型,视图模型或视图。

Other mistake I made was to give objects too many responsibilities, for instance ViewModels ended up being in charge of networking, data access, model manipulation, etc, just like using a UIViewController with MVC. Later I learnt that not all objects would fit it in one of those categories and that responsibilities should be limited.

我犯的另一个错误是赋予对象太多的责任,例如ViewModels最终负责网络,数据访问,模型操作等,就像将UIViewController与MVC一起使用一样。 后来我了解到,并非所有对象都适合这些类别之一,并且应该限制责任。

So after learning from my mistakes and started using the patterns the right way I realized that even though the patterns helped my code to be more readable and objects in the project had fewer responsibilities than before, they didn't seemed to really fix the core issue, maintainability was still difficult and adding new features a nightmare. This is because the problem wasn’t in how the UI and Presentation were talking to each other, but in how the whole software was structured, in other words the problem I was facing was with the software architecture.

因此,从错误中吸取教训并以正确的方式开始使用模式后,我意识到,即使这些模式使我的代码更具可读性,并且项目中的对象比以前少了责任,但它们似乎并没有真正解决核心问题,可维护性仍然很困难,并且增加了新功能。 这是因为问题不在于UI和Presentation如何彼此交谈,而在于整个软件的结构方式,换句话说,我所面临的问题是软件体系结构

一些研究 (Some Research)

那么什么是MVC? (So What is MVC?)

Model View Controller (MVC) was introduced back in 1979 by Trygve Reenskaug in the Model View Controller Report. Reenskaug defines MVC in this article as follows.

模型视图控制器(MVC)于1979年由Trygve Reenskaug在“模型视图控制器报告”中引入。 Reenskaug在本文中对MVC的定义如下。

MVC was conceived as a general solution to the problem of users controlling a large and complex data set.

MVC被认为是解决用户控制大型和复杂数据集问题的通用解决方案。

The essential purpose of MVC is to bridge the gap between the human user’s mental model and the digital model that exists in the computer. The ideal MVC solution supports the user illusion of seeing and manipulating the domain information directly. The structure is useful if the user needs to see the same model element simultaneously in different contexts and/or from different viewpoints. The figure below illustrates the idea.

MVC的基本目的是弥合人类用户的心理模型与计算机中存在的数字模型之间的鸿沟。 理想的MVC解决方案支持用户直接查看和操作域信息的错觉。 如果用户需要在不同的上下文中和/或从不同的角度同时看到相同的模型元素,则此结构很有用。 下图说明了这个想法。

Image for post
Fig.1 Trygve Reenskaug’s MVC — Diagram by Trygve Reenskaug
图1 Trygve Reenskaug的MVC — Trygve Reenskaug的图表

If we analyze the diagram above MVC refers to the interaction between the user, an input tool, a process and an output. MVC seems like a very generic concept, it’s so generic that it can apply to almost any architecture that isn’t total spaghetti code. But nowadays applications are not only composed of a view like a text-editor, a model like a text, and a controller to manage the interaction. Applications now hold complex behaviors and processes, need remote data access, analytics and what not.

如果我们分析上面的图,MVC是指用户,输入工具,过程和输出之间的交互。 MVC似乎是一个非常通用的概念,它是如此通用,几乎可以应用于任何不是全部意大利面条式代码的体系结构。 但是如今,应用程序不仅由诸如文本编辑器的视图,诸如文本的模型以及用于管理交互的控制器组成。 应用程序现在具有复杂的行为和流程,需要远程数据访问,分析以及其他功能。

Essentially MVC refers to what today we know as the presentation part of an application. Therefore MVC, MVP and MVVM only solve the way we structure the presentation of an application, each in a different way.

本质上,MVC指的是今天我们所知道的应用程序的表示部分。 因此,MVC,MVP和MVVM仅以不同的方式解决了构建应用程序表示的方式。

更多研究 (More Research)

I knew that there had to be a way to design software that wasn’t so hard to maintain. So I dived into lots of software architecture literature, Clean-Architecture by Uncle Bob, Hexagonal Architecture, Layered Architecture and Microservices. Throughout my readings I can conclude that they are essentially all the same. Bear with me here, each architecture is different from each other and serve different purposes. This is in the surface though, deep down they intend the same goal, which is to separate responsibilities and establish a standard way of communication between its components, improve maintainability and scalability and reduce development time.

我知道必须有一种设计软件的方法,它并不很难维护。 因此,我深入研究了许多软件体系结构文献,包括Bob叔叔的Clean-Architecture,六角体系结构,分层体系结构和微服务。 在阅读过程中,我可以得出结论,它们基本上是相同的。 在这里忍受我,每种体系结构互不相同,并且服务于不同的目的。 尽管从表面上看,他们的内在目的是相同的目标,即分离职责并建立组件之间的标准通信方式,提高可维护性和可伸缩性并减少开发时间。

那么,如何从MassiveViewController转到易于维护的可扩展项目project? (So, how do I go from MassiveViewController to a scalable easy to maintain project 🚀?)

After all my research, I had some knowledge to build my own implementation of a software architecture and solve my problem. I found that a clean-layered- modular oriented architecture was the way to go, so I did that.

经过所有的研究,我掌握了一些知识来构建自己的软件体系结构实现并解决了问题。 我发现必须采用干净的面向分层模块的架构,所以我做到了。

The architecture I came up with focuses on building software by composing multiple independent reusable modules, a practice that many developers use.

我提出的体系结构专注于通过组合多个独立的可重用模块来构建软件,这是许多开发人员使用的一种做法。

好处 (Benefits)

This approach lets developers built software that is easy to test, maintain and scale. On the business side, this architecture helps developers deliver applications in small chunks which increases speed of development since multiple developers can build different parts of the software simultaneously, it even allows for software to be developed with no need to wait for the UI to be designed. Ultimately this means better productivity which translates to our clients using higher quality products, better costumer retention and maybe even increased profitability.

这种方法使开发人员可以构建易于测试,维护和扩展的软件。 在业务方面,此架构可帮助开发人员以小块形式交付应用程序,这可以提高开发速度,因为多个开发人员可以同时构建软件的不同部分,它甚至允许开发软件而无需等待UI的设计。 。 最终,这意味着更高的生产率,这可以转化为使用更高质量产品的客户,更好的客户保留率,甚至可能提高利润率。

潜水之前 (Before diving in)

This is not a silver bullet. Every software behaves differently and is designed to solve a specific need, hence each software must have its architecture designed to fit its purpose. Nonetheless this simple architecture which is based on widely popular architectural patterns, should fit most applications.

这不是灵丹妙药。 每个软件的行为各不相同,旨在满足特定需求,因此,每个软件都必须具有适合其目的的体系结构。 但是,这种基于广泛流行的架构模式的简单架构应该适合大多数应用程序。

结构体 (Structure)

Most applications are composed of multiple features that use a database, some sort of storage and third party services.

大多数应用程序由使用数据库,某种存储和第三方服务的多种功能组成。

特征 (Features)

A Feature refers to a specific set of tasks and use cases of an application, i.e Messages in a social networking app. Every Feature must live in its own module (think of a sandbox) so it can be replaced by other implementations that perform the same required tasks, for instance replace the Messages Feature with a new version with new UI and fancy animations without breaking the whole app.

功能是指应用程序(即社交网络应用程序中的Message)的一组特定任务和用例。 每个功能都必须存在于其自己的模块中(就像沙盒一样),以便可以由执行相同必需任务的其他实现替换它,例如,用具有新UI和精美动画的新版本替换Message s Feature ,而不会破坏整体应用程式。

分解功能 (Breaking down a Feature)

A Feature like Messages is composed of small pieces that do a specific task, these pieces are what users actually interact with.

诸如消息之类的功能由执行特定任务的小部分组成,这些部分是用户实际与之交互的部分。

Taking the previous Messages example into consideration, let's analyze a real world app like iMessage.

考虑到前面的Messages示例,让我们分析一个像iMessage这样的真实应用程序。

Image for post
Fig.2 — iMessage in iOS7 Images by Apple Inc.
图2-Apple Inc.在iOS7图像中的iMessage

If we break it down we will find that the messaging feature of an app is probably composed by some of the next parts:

如果将其分解,我们将发现应用程序的消息传递功能可能由以下几个部分组成:

  • ChatList

    聊天清单
  • NewChat

    新聊
  • Chat

    聊天室

Through this exercise we realize that the Messages Feature is only a concept that encapsulates a lot of parts that execute specific tasks.

通过本练习,我们意识到消息功能只是一个概念,它封装了许多执行特定任务的部分。

Image for post
Fig.3 Messages Feature
图3消息功能

Some Features may also contain Sub-Features. Sub-Features are parts of a Feature that may render too complex to be implemented in a single module.

某些功能可能还包含子功能。 子功能是功能的一部分,可能过于复杂而无法在单个模块中实现。

Since Sub-Features are Features, they also live in their own module. Take the Chat component in iMessage as an example, entering in a Chat we might find the following.

由于子功能是功能,因此它们也存在于自己的模块中。 以iMessage中的“聊天”组件为例,输入“聊天”可能会发现以下内容。

Image for post
Fig. 4 — iMessage chat in iOS7 Images by Apple Inc.
图4 – Apple Inc.在iOS7 Images中的iMessage聊天

As we can see it isn’t just a list of messages, it contains tasks to send voice messages, video, images and what not. The Chat component seems large and we may consider it as a Sub-Feature, thus it may also contain components like MessagesList and SearchMessage and other Sub-Features such as Camera which might be used to take pictures and then send them. So the Chat Sub-Feature might render as follows.

我们可以看到,它不仅是消息列表,还包含发送语音消息,视频,图像等的任务。 聊天组件似乎很大,我们可以将其视为子功能,因此它可能还包含MessagesList和SearchMessage等组件以及其他子功能(例如Camera),可用于拍照然后发送。 因此,聊天子功能可能会呈现如下。

Image for post
Fig.5 Chat Sub-Feature
图5聊天子功能

架构 (The architecture)

Software architecture is all about communication & responsibilities.

软件体系结构是关于沟通和责任的。

Now that we understand how a feature is composed we may start thinking of a more generic diagram to represent the architecture. In this section we will see each module in detail with an example.

现在我们了解了功能的组成方式,我们可以开始考虑使用更通用的图来表示体系结构。 在本节中,我们将通过示例详细介绍每个模块。

域:业务逻辑 (Domain: Business Logic)

Business logic such as Use Cases and Models are defined all together in a separate very low level single module named Domain.

诸如用例和模型之类的业务逻辑在一个单独的名为Domain的非常底层的单独模块中一起定义。

Use Cases should contain the business logic actual implementation, here you should manipulate your models, access data or storage all through interfaces defined in the Domain module. The Domain module must only depend on the chosen programming language’s base framework and some interfaces needed to perform its tasks. For example in case we were using Swift, the Domain module should only depend on Foundation, though there’s one exception.

用例应该包含业务逻辑的实际实现,在这里您应该通过域模块中定义的接口来操纵模型,访问数据或存储。 域模块必须仅取决于所选编程语言的基本框架以及执行其任务所需的某些接口。 例如,在我们使用Swift的情况下,尽管有一个例外,但Domain模块应该仅取决于Foundation。

The exception

例外

A Use Case works like a black box, it receives an input and then manipulates models and other objects to perform a specific task. When finished, it returns its outputs to the interested parties. When asynchronously returning outputs callbacks and closures may be easier to use but be careful if you end up using nested closures as they could cause retain-cycles (if you use classes for your Use Cases), retain-cycles affect your app’s performance and may even cause it to crash. Which is why we prefer to use functional reactive programming and the Observer design pattern. Therefore we recommend that ‘execute’ methods should publish results to observers via a subscription. You could use KVO from Cocoa or frameworks such as RxSwift, Combine or whatever framework for FRP you like. So in this case Domain can also depend on Combine or the framework you choose.

用例就像黑盒子一样工作,它接收输入,然后操纵模型和其他对象来执行特定任务。 完成后,它将其输出返回给感兴趣的各方。 当异步返回输出回调和闭包可能更易于使用,但如果最终使用嵌套闭包,则要小心,因为它们可能会导致保留周期(如果您将用例用于类),则保留周期会影响应用程序的性能,甚至可能导致它崩溃。 这就是为什么我们更喜欢使用函数式React式编程和Observer设计模式的原因。 因此,我们建议“执行”方法应通过订阅 结果发布观察者 。 您可以使用来自Cocoa的KVO或RxSwift,Combin等框架或任何您喜欢的FRP框架。 因此,在这种情况下,Domain也可以取决于Combine或您选择的框架。

Image for post
Fig.6 Domain Module
图6域模块

介面 (Interfaces)

Interfaces, or protocols in Swift, serve as blueprints or contracts that specify a behavior for objects to implement. This contracts allow objects to communicate with other objects that expect this interfaces as dependencies without creating tight coupling, this also helps to avoid inheritance when using classes.

Swift中的接口或协议用作指定要实现的对象行为的蓝图或合同。 该协定允许对象与希望将此接口作为依赖项的其他对象进行通信,而无需创建紧密耦合,这也有助于避免在使用类时进行继承。

In the Domain module we use interfaces to communicate UseCases with objects outside the module (to avoid module dependency). Objects we may want to communicate with include objects responsable for data access and maybe some other objets for different tasks such as analytics and what not.

在域模块中,我们使用接口将UseCases与模块外部的对象进行通信(以避免模块依赖性)。 我们可能要与之通信的对象包括负责数据访问的对象,以及可能用于诸如分析之类的不同任务的其他对象。

(Example)

Following the iMessage example we may have a SendTextMessageUseCase which only job would be to send a message with text. We may write it as follows:

在iMessage示例之后,我们可能会有一个SendTextMessageUseCase,唯一的工作就是发送带有文本的消息。 我们可以这样写:

This is a very simple Use Case example that adds the provided Message to a database through an object that conforms to MessageRepository protocol. In this example we use a Model, a Use Case and a Repository. The idea behind the Use Case is that you should write your business logic inside the execute method and return whatever output it produces to the caller once it finishes. This way we isolate business logic from UIViewControllers or other classes which lets us reuse code in other modules or even other applications.

这是一个非常简单的用例示例,该示例通过符合MessageRepository协议的对象将提供的Message添加到数据库中。 在此示例中,我们使用模型,用例和存储库。 用例背后的想法是,您应该在execute方法内编写业务逻辑,并在完成后将其产生的任何输出返回给调用方。 这样,我们将业务逻辑与UIViewControllers或其他类隔离开来,这使我们可以在其他模块甚至其他应用程序中重用代码。

特征 (Feature)

An app will have multiple Feature modules. As mentioned before a Feature is composed of small pieces in charge of performing a specific set of tasks. The Feature will grab its logic from the Domain module, so all it should contain are UI & Presentation related objects.

一个应用程序将具有多个功能模块。 如前所述,功能由负责执行一组特定任务的小部分组成。 该功能将从域模块中获取其逻辑,因此它应包含的都是与UI和Presentation相关的对象。

In UIKit projects:

在UIKit项目中:

  • UIViewControllers

    UIViewControllers
  • UIViews

    UIViews
  • UINavigationControllers

    UINavigationControllers
  • Xibs

    锡伯斯
  • Delegates

    代表们
  • Routers **

    路由器**
  • ViewModels / Presenters *

    ViewModels / Presenters *

In SwiftUI projects:

在SwiftUI项目中:

  • Views

    观看次数
  • ViewModels

    视图模型
  • Routers **

    路由器**

*This should be present on your Feature module whether you use MVVM or MVP. Though if you prefer to use MVC there’s no need to add this files, you can use ViewControllers to stitch your logic (Domain), networking & database operations (Data) with your UI&Presentation.

*无论使用MVVM还是MVP,此功能都应显示在功能模块上。 尽管如果您更喜欢使用MVC,则无需添加此文件,但是可以使用ViewControllers通过UI&Presentation来缝合逻辑(域),网络和数据库操作(数据)。

** Depends on how you manage your routing logic.

**取决于您如何管理路由逻辑。

Image for post
Fig.7 Feature Module
图7功能模块

This is a very simple module since it only holds UI&Presentation related files. In the example shown we used MVVM, the Model part comes from the Domain which the ViewModel takes from, the View is represented by the ViewController (which receives inputs from its underlaying view and manages its lifecycle, UIKit only) and at last the ViewModel which manipulates Use Cases from Domain on ViewController’s disposal.

这是一个非常简单的模块,因为它仅包含与UI&Presentation相关的文件。 在所示的示例中,我们使用了MVVM,Model部分来自ViewModel所来自的Domain,View由ViewController表示(ViewController从其底层视图接收输入并管理其生命周期,仅UIKit),最后是ViewModel在ViewController的处置下,从Domain操纵用例。

Routing and navigation is up to you, you may choose to use a Router or not, since it belongs to UI & Presentation how we implement it doesn’t really affect the architecture, more on this later.

路由和导航由您决定,您可以选择是否使用路由器,因为它属于UI&Presentation,我们如何实现它并不会真正影响体系结构,稍后将对此进行详细介绍。

Keep in mind that the green box is only a representation, it may contain a lot of Single Component boxes since each of those represent a ‘part’ of the Feature like ChatsList, MessagesList or Camera.

请记住,绿色框只是一种表示形式,它可能包含很多“单个组件”框,因为每个“单个组件”框都代表“功能”的“一部分”,例如ChatsList,MessagesList或Camera。

数据与第三方 (Data & Third Parties)

Data module contains DataModels, DataModels exist in a 1:1 relationship with Models in Domain, Mappers help DataModels be mapped into Models. Repositories must only return Models. Under the Bridge Pattern, Repositories are defined as objects that encapsulate data access.

数据模块包含数据模型,数据模型与域中的模型以1:1关系存在,映射器帮助数据模型映射到模型中。 存储库只能返回模型。 在桥接模式下,存储库定义为封装数据访问的对象。

Interfaces (protocols) describe a contract between objects to communicate. In simpler words protocols specify all the properties and methods a type must implement to be able to communicate with its dependees in any module. In this case as data interfaces will also be used in the Domain module by UseCases, they must be declared in the Domain module to ensure independency between modules.

接口 (协议)描述了对象之间进行通信的契约。 用简单的话来说,协议指定类型必须实现的所有属性和方法,以使其能够与任何模块中的依赖者进行通信。 在这种情况下,UseCases还将在域模块中使用数据接口,因此必须在域模块中声明它们,以确保模块之间的独立性。

For example if Type A implements Interface S and Type B also implements S, this means that Type A and B should behave the same in eyes of the Domain module and this also means that both implementations are interchangeable.

例如,如果类型A实现接口S,类型B也实现S,则这意味着类型A和B在域模块的作用下应该相同,这也意味着这两种实现是可互换的。

Image for post
Fig.8 Data module interacting with other modules
图8数据模块与其他模块的交互

Interfaces in this example:

本示例中的接口:

  • <Repository>: Defines a set of methods a type must implement to execute data related tasks required by a set of Use Cases. We should use one repositories for each model as a rule, having a single repository using generics gets complicated and it’s not recommend since each model may need different operations.

    <存储库>:定义类型必须执行的一组方法,以执行一组用例所需的数据相关任务。 通常,我们应该为每个模型使用一个存储库,使用泛型的单个存储库会很复杂,因此不建议这样做,因为每个模型可能需要不同的操作。
  • <ThirdPartyService>: Defines a set of methods a type must implement to use a third party service. Setting an interface for this means that we can swap the framework or library we use and don’t affect the app at all.

    <ThirdPartyService>:定义类型必须使用一组方法才能使用第三方服务。 为此设置接口意味着我们可以交换我们使用的框架或库,而完全不影响应用程序。

Keep in mind that every module is plug and play. This allows modules to be shared between other modules or even across applications.

请记住,每个模块都是即插即用的。 这允许模块在其他模块之间甚至在应用程序之间共享。

模块提供者 (Module Provider)

The Module Provider switches between a Feature module’s root navigation controller, on UIKit projects and rootView on SwiftUI projects. The switching is done through the activeModule attribute of type Module of the ModuleProvider class. The Module is just an enum with all the available module names. The switch could be done through a singleton or via NotificationCenter, this means that any module can tell the ModuleProvider that it’s time to switch to a new module or to dismiss itself to the root module.

模块提供程序在UIKit项目上的功能模块的根导航控制器和SwiftUI项目上的rootView之间切换。 切换是通过ModuleProvider类的Module类型的activeModule属性完成的。 该模块只是具有所有可用模块名称的枚举。 切换可以通过单例完成,也可以通过NotificationCenter进行,这意味着任何模块都可以告知ModuleProvider,现在该切换到新模块或将自己退出到根模块了。

It’s up to you to choose how to provide AppDelegate or SceneDelegate with the appropriate rootViewController or rootView respectively through the ModuleProvider, to avoid toying with Combine, DI and Singletons (more on that in a following post) the following implementation does the job.

由您自己决定如何通过ModuleProvider为AppDelegate或SceneDelegate分别提供适当的rootViewController或rootView,以避免通过使用Combine,DI和Singletons(在下一篇文章中有更多介绍)来完成以下实现。

Fig.9 Module Provider example
图9模块提供者示例

With that implementation you can send the notification to change a module from any ViewModel, Presenter or ViewController you need.

通过该实现,您可以发送通知以从所需的任何ViewModel,Presenter或ViewController更改模块。

整个图片 (The whole picture)

Image for post
Fig.10 Dependency diagram of a the whole architecture
图10整个架构的依赖图

翻译自: https://medium.com/swlh/my-journey-to-understanding-software-architecture-as-a-junior-ios-dev-5a819cc6716f

ios 初级开发


http://www.taodudu.cc/news/show-7941831.html

相关文章:

  • CIAM (用户身份管理)选型指南
  • Fairseq学习日记:注定麻烦的旅程
  • linux 学习旅程01
  • Delta Lake - 数据写入的旅程
  • cc的21天C语言入门
  • 用户体验的要素pdf_2018年优秀用户体验的7大要素
  • 前5个SOA陷阱以及如何避免它们
  • 识别消费陷阱,反消费主义书单推荐
  • 繁体字代码
  • java web生僻字传值_关于C#(生僻字、繁体字)和Java的URL转码GBK后结果不一样的问题解决...
  • MySQL数据库集群——MySQL的异步复制(基于position的主从复制和基于gtid的主从复制),半同步复制,组复制
  • centos 7 (应用知识) 安装后首要做的事
  • centos7 安全配置
  • 运维必看|CentOS 7 安装完毕后必做的七件事
  • resnet50 网络结构图
  • 使用 resnet50 网络训练多分类模型完整代码
  • Resnet_50网络全解
  • 50个网站
  • Excel 单元格利用后续空白单元格中显示完整内容
  • ObjectArx 自定义实体 dwgInFields 数组写法
  • TX_SDK开发的配置
  • 同时安装SolidWorks与altium,导致altium无法正确打开工程
  • AD16使用过程中发现应注意的问题
  • Robotframework ride界面底部日记没有显示,不能查看log和report之解决办法
  • Tensorflow-报错解决方案
  • 大数据实验使用 hdfs dfsadmin -report命令,查看HDFS使用情况为0,解决方法
  • finereport 实现点击多个按钮换色
  • tensorboard可视化学习中出现的一些问题
  • fastreport中的RegisterData方法
  • MATLAB与STK互联38:利用root.ExecuteCommand(),生成报告(Report)
  • 这篇关于ios 初级开发_我作为初级ios开发人员了解软件体系结构的旅程的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



    http://www.chinasem.cn/article/201190

    相关文章

    这15个Vue指令,让你的项目开发爽到爆

    1. V-Hotkey 仓库地址: github.com/Dafrok/v-ho… Demo: 戳这里 https://dafrok.github.io/v-hotkey 安装: npm install --save v-hotkey 这个指令可以给组件绑定一个或多个快捷键。你想要通过按下 Escape 键后隐藏某个组件,按住 Control 和回车键再显示它吗?小菜一碟: <template

    关于数据埋点,你需要了解这些基本知识

    产品汪每天都在和数据打交道,你知道数据来自哪里吗? 移动app端内的用户行为数据大多来自埋点,了解一些埋点知识,能和数据分析师、技术侃大山,参与到前期的数据采集,更重要是让最终的埋点数据能为我所用,否则可怜巴巴等上几个月是常有的事。   埋点类型 根据埋点方式,可以区分为: 手动埋点半自动埋点全自动埋点 秉承“任何事物都有两面性”的道理:自动程度高的,能解决通用统计,便于统一化管理,但个性化定

    Hadoop企业开发案例调优场景

    需求 (1)需求:从1G数据中,统计每个单词出现次数。服务器3台,每台配置4G内存,4核CPU,4线程。 (2)需求分析: 1G / 128m = 8个MapTask;1个ReduceTask;1个mrAppMaster 平均每个节点运行10个 / 3台 ≈ 3个任务(4    3    3) HDFS参数调优 (1)修改:hadoop-env.sh export HDFS_NAMENOD

    嵌入式QT开发:构建高效智能的嵌入式系统

    摘要: 本文深入探讨了嵌入式 QT 相关的各个方面。从 QT 框架的基础架构和核心概念出发,详细阐述了其在嵌入式环境中的优势与特点。文中分析了嵌入式 QT 的开发环境搭建过程,包括交叉编译工具链的配置等关键步骤。进一步探讨了嵌入式 QT 的界面设计与开发,涵盖了从基本控件的使用到复杂界面布局的构建。同时也深入研究了信号与槽机制在嵌入式系统中的应用,以及嵌入式 QT 与硬件设备的交互,包括输入输出设

    OpenHarmony鸿蒙开发( Beta5.0)无感配网详解

    1、简介 无感配网是指在设备联网过程中无需输入热点相关账号信息,即可快速实现设备配网,是一种兼顾高效性、可靠性和安全性的配网方式。 2、配网原理 2.1 通信原理 手机和智能设备之间的信息传递,利用特有的NAN协议实现。利用手机和智能设备之间的WiFi 感知订阅、发布能力,实现了数字管家应用和设备之间的发现。在完成设备间的认证和响应后,即可发送相关配网数据。同时还支持与常规Sof

    活用c4d官方开发文档查询代码

    当你问AI助手比如豆包,如何用python禁止掉xpresso标签时候,它会提示到 这时候要用到两个东西。https://developers.maxon.net/论坛搜索和开发文档 比如这里我就在官方找到正确的id描述 然后我就把参数标签换过来

    安卓链接正常显示,ios#符被转义%23导致链接访问404

    原因分析: url中含有特殊字符 中文未编码 都有可能导致URL转换失败,所以需要对url编码处理  如下: guard let allowUrl = webUrl.addingPercentEncoding(withAllowedCharacters: .urlQueryAllowed) else {return} 后面发现当url中有#号时,会被误伤转义为%23,导致链接无法访问

    【生成模型系列(初级)】嵌入(Embedding)方程——自然语言处理的数学灵魂【通俗理解】

    【通俗理解】嵌入(Embedding)方程——自然语言处理的数学灵魂 关键词提炼 #嵌入方程 #自然语言处理 #词向量 #机器学习 #神经网络 #向量空间模型 #Siri #Google翻译 #AlexNet 第一节:嵌入方程的类比与核心概念【尽可能通俗】 嵌入方程可以被看作是自然语言处理中的“翻译机”,它将文本中的单词或短语转换成计算机能够理解的数学形式,即向量。 正如翻译机将一种语言

    Linux_kernel驱动开发11

    一、改回nfs方式挂载根文件系统         在产品将要上线之前,需要制作不同类型格式的根文件系统         在产品研发阶段,我们还是需要使用nfs的方式挂载根文件系统         优点:可以直接在上位机中修改文件系统内容,延长EMMC的寿命         【1】重启上位机nfs服务         sudo service nfs-kernel-server resta

    【区块链 + 人才服务】区块链集成开发平台 | FISCO BCOS应用案例

    随着区块链技术的快速发展,越来越多的企业开始将其应用于实际业务中。然而,区块链技术的专业性使得其集成开发成为一项挑战。针对此,广东中创智慧科技有限公司基于国产开源联盟链 FISCO BCOS 推出了区块链集成开发平台。该平台基于区块链技术,提供一套全面的区块链开发工具和开发环境,支持开发者快速开发和部署区块链应用。此外,该平台还可以提供一套全面的区块链开发教程和文档,帮助开发者快速上手区块链开发。