Introdução: A App Factory, como o nome sugere, é uma fábrica que pode gerar aplicativos com base em vários materiais e formulários organizacionais. Uma descrição mais profissional é baseada em um relacionamento de dependência com uma biblioteca completa de componentes e esses componentes e combinada em um aplicativo.

No passado, a arquitetura de P&D do aplicativo único, porque cada embalagem e compilação e liberação de versão eram uma quantidade total de coleta de código, portanto, não há necessidade de considerar a relação de dependência e acoplamento entre cada componente. No cenário multi -aplicativo, devido à existência de um conjunto de códigos, o código necessário para gerar diferentes aplicativos sob demanda, a arquitetura original, o relacionamento de dependência de código e os métodos de organização de código de engenharia precisam ser alterados de acordo.

A meta da fábrica de aplicativos é gerar o código necessário para o aplicativo de destino com base em um conjunto de código em uma arquitetura e cenário de negócios específicos. Um conjunto de códigos e a geração de demanda é o núcleo, o que é indispensável. Especialmente sob demanda, significa não transportar nenhum código desnecessário, o que é muito desafiador no processo de implementação. Da perspectiva do iOS, compartilhe a teoria e a prática do 58App na fábrica de aplicativos.

Autor | Peng Fei

App Factory Gere Background

O teste rápido e o erro do negócio dão à luz vários aplicativos

Independentemente de a Internet móvel estar no primeiro semestre ou no segundo tempo, a inovação comercial nunca parou. De Weibo à compra de grupo, de carros compartilhados a bicicletas compartilhadas, de vídeos longos a vídeos curtos, continua a inovação de negócios e modelo. Nos últimos anos, vi as notícias e erros nas manchetes. De informações às transmissões ao vivo, a vídeos curtos, é a onda um após o outro.

Independentemente de ser uma grande empresa de Internet ou uma pequena empresa empreendedora, se você deseja explorar o mundo em um novo campo, você deve continuar tentando errar. O negócio no campo móvel é constantemente tentativa e erro, e é necessário produzir rapidamente um aplicativo inovador correspondente a cada empresa.

A expansão gradual e o refinamento dos negócios de grupo geraram multi -pp

Os rios e lagos da Internet têm sido três ponteiros, os gigantes foram estabelecidos e grandes plataformas da Internet são difíceis de formar. Mas quanto maior a plataforma da Internet, mais preocupada com a ofensiva do negócio de segmento vertical. Para lidar com a ofensa, os negócios do grupo também precisam expandir e refinar gradualmente em algumas áreas, e o aplicativo vertical surgiu.

A lacuna entre o aplicativo vertical e o aplicativo de inovação é que o aplicativo vertical é baseado na segmentação de negócios da plataforma existente e o aplicativo de inovação não está disponível para o negócio da plataforma.

Além disso, para responder à distribuição do mercado de aplicativos e pacotes sensíveis, o pacote rápido quase se tornou um aplicativo obrigatório para as principais empresas nos últimos anos.

A fusão e a fusão dos negócios de grupo geraram multi -App Cross

A aquisição e a fusão de negócios também são comuns para grandes empresas de Internet. Como integrar os negócios após a aquisição, como manter a independência dos negócios, mas também salvar os recursos de P&D do grupo, mas também apoiar um conjunto de negócios cruzados (também conhecidos como negócios verticais). Pergunta. Por exemplo, a integração do negócio de propriedades domésticas e os 58 negócios imobiliários originais do 58º grupo deste ano é um caso típico.

Metas de fábrica de aplicativos, métodos de arquitetura e implementação

Objetivos de implementação da fábrica de aplicativos

1. App Factory tem os seguintes objetivos:

• A saída dos recursos padronizados é a taxa de crescimento da P&D R&D R&D R&D

Os recursos de padronização são a base das fábricas de aplicativos. Os recursos de padronização não têm relação de acoplamento com o código de negócios do aplicativo, como o React Native SDK, a biblioteca de rede, a biblioteca de cache etc.

• Apoie a geração e a iteração do aplicativo de inovação, aplicativo vertical e aplicativo de velocidade

O mesmo conjunto de código, de acordo com a configuração, pode gerar o código necessário para diferentes aplicativos sob demanda. A necessidade de gerar conforme necessário é a chave e o núcleo. O código do aplicativo gerado pela fábrica do aplicativo é transportado por qualquer código inútil para aumentar o tamanho do pacote.

• Apoie a tradução de negócios verticais em um aplicativo independente

A fábrica de aplicativos está anexada ao código da estrutura 58App. Coletes, pacotes de alta velocidade e fábricas de aplicativos (58App) são a relação entre um subconjunto e uma coleção completa. Mas, semelhante ao APP ANJU e 58APP, são dois aplicativos independentes, existem interseções (código inferior público ou determinado código comercial) e a coleta de códigos de negócios é diferente.

Para o código de negócios público do aplicativo independente, ele é definido como negócios verticais. Sob a premissa de serviços subjacentes unificados, a fábrica de aplicativos também suporta a tradução de negócios verticais em aplicativos independentes. Ou seja, um conjunto de código comercial pode ser executado em dois ou mais aplicativos independentes.

Arquitetura de fábrica de aplicativos

Glossário

Vagens

No campo do iOS, os pods se referem especificamente a cocoapods, que é abreviado. Cocoapods é um gerenciamento de dependência de projetos de coco de OC ou Swift. (Cocoapods é um gerente de dependência para projetos Swift e Objective-C Cocoa.)

Middleware

A interpretação comum da parte do meio no campo de software é: conectar componentes e aplicativos de software. O middleware aqui reflete conexão e compartilhamento. A camada de negócios e o banco de dados básico estão conectados, que são serviços comuns refletidos na camada de negócios.

As partes do meio são divididas em middleware empresarial e middleware padrão, de acordo com se o negócio é forte.

• Middleware comercial:

  Middleware relacionado ao negócio forte, universal em um determinado aplicativo independente. Devido à dependência excessiva de outras funções do aplicativo atual, ele não é adequado para outros aplicativos independentes.

• Middleware padrão:

  O middleware relacionado aos negócios fracos não é apenas universal em um determinado aplicativo independente, mas também universal em outros aplicativos independentes, relacionados aos negócios fracos no aplicativo. O mais comum é a versão padrão do RNSDK.

Biblioteca base

Bibliotecas independentes que não dependem de outras vagens. Por exemplo, algumas bibliotecas de três partidas de código aberto são bibliotecas base comuns. Além do código aberto de terceiros, o SDK embalado no grupo 58 também pode ser atribuído à biblioteca básica, como Passport SDK, WPUSH SDK, etc.;

Projeto de entrada

É principalmente responsável pela configuração do código necessário para o aplicativo gerado pela fábrica do aplicativo.

PODs de engenharia de entrada: É principalmente responsável pela configuração do código necessário para o aplicativo gerado pela fábrica de aplicativos. As funções incluídas na engenharia de entrada são:

• Informações do aplicativo: Configurações de informações básicas do aplicativo, como nomes de aplicativos, identificador de pacote, número da versão, certificado, etc.;

• Podfile: A dependência do aplicativo atual do código de engenharia necessário, como o pacote de colete de recrutamento que depende do POD de negócios de recrutamento e de outros serviços de serviços básicos e cápsulas de biblioteca de três partidas;

• Regen.sh: Um arquivo executável (P&D e comissionamento local RD), leia a configuração do podfile, copie o código e a configuração do aplicativo e, em seguida, gera o código necessário para o aplicativo;

• Reng_jenkins.sh: Um arquivo executável (embalagem de serviço Jenkins), leia a configuração do podfile, copie o código e a configuração do aplicativo e, em seguida, gera o código necessário para o aplicativo;

Pool da biblioteca de engenharia

O pool de engenharia é uma coleção de código de pod para a fábrica de aplicativos.

O pool de engenharia é a coleta total de código da fábrica de aplicativos. Cada código necessário para gerar aplicativo é obtido nesta coleção de código. Durante o processo de pesquisa e desenvolvimento, a atualização do código será atualizada simultaneamente nesta coleta de código.

• Pods de negócios: cada código de engenharia de negócios independente, a coleta de código é dividida de acordo com os tipos de negócios, como o App Homepage Pod, POD imobiliário, vagem de recrutamento;

• Middleware Pods: O código de serviço intermediário da fábrica de aplicativos é embalado pelo próprio 58. O código público da terceira parte diferente do mundo exterior é chamado de código de middleware. A parte do meio é dividida em dependência se o negócio 58App é forte:

Middleware comercial:

Está fortemente relacionado ao negócio 58APP, mas é um serviço intermediário universal no 58App. Seu cenário de aplicação está dentro do cenário comercial do 58App.

Middleware padrão:

Está relacionado ao negócio fraco do 58App e pode ser introduzido como um middleware padronizado em outros aplicativos independentes.

No middleware padrão, você pode ver que o ícone é adicionado com duas linhas verticais, o que significa que a implementação de certas funções deste aplicativo de acesso dependente de middleware padrão é implementada e o protocolo da interface está aberto apenas.

Pegue o middleware padrão da biblioteca básica do RN como exemplo:

O conteúdo contido na parte do meio é o conteúdo da página da transportadora e a atualização quente da atualização quente. No entanto, para alguns componentes estendidos (como o ponto enterrado), um protocolo aberto exige que a parte do acesso a implemente, e isso A lógica não percebe essa lógica.

• PODs de biblioteca de três partidas: o código da biblioteca de terceira parte do mundo aberto do mundo exterior possui um padrão de referência uniforme no setor;

Análise de arquitetura

A imagem acima é a arquitetura da fábrica de aplicativos. O grande aspecto é dividido em duas camadas das camadas superior e inferior: importar engenharia e pool de fábrica. O POT POD depende do POD no pool de engenharia e configura o código do POD necessário para o aplicativo, onde cada engenharia de entrada está localizada através da configuração do PODFILE.

O POD no pool de engenharia é dividido em camadas de negócios, camadas de middleware e camadas básicas de bibliotecas. Entre eles, a camada de middleware depende se o código depende fortemente do negócio 58App e é dividido em middleware comercial e middleware padrão.

Em termos de design de arquitetura, as dependências de várias camadas de vagens são:

• A camada superior pode depender do nível inferior, mas o nível mais baixo não pode depender do nível superior. Por exemplo, a página inicial no cápsulas de negócios de nível superior (MainPage) pode confiar no ciclo de vida (WblifeCircle) no middleware comercial, mas não pode depender do outro.

• Você pode depender da camada de partição. Por exemplo, o Business POD pode depender da vagem básica da biblioteca;

• Não há dependência entre o POD de negócios. Por exemplo, o POD imobiliário não pode confiar no recrutamento.

• A parte do meio do pod e a vagem da biblioteca de três partidas podem ser unidirecionais. Por exemplo, o POD onde o RN está localizado pode ter uma dependência de um caminho da vagem do serviço de login.

As dependências mencionadas acima são formuladas para configurar o POD necessário sob demanda ao produzir aplicativos ou tradução para negócios verticais.

Como alcançar as metas de design com a arquitetura da fábrica de aplicativos

1. Como fornecer habilidade padronizada

A capacidade de padronização assim chamada pode ser entendida como uma estrutura ou SDK independente e independente, correspondendo ao middleware padrão no diagrama de arquitetura acima. Por exemplo, a Biblioteca Basic RN, um conjunto completo de serviços públicos, como páginas de operadora e atualizações quentes, aplicativos independentes fora do 58App podem ter acesso perfeitamente.

Alguns dos middleware padrão exibidos na figura abaixo:

Nome do middleware padrão

pod nome

Descrição da função

RN Basic Library

WBreactnavelibrary

A função básica do RN, incluindo a página da transportadora, atualização térmica, otimização de desempenho e alguns módulos padronizados

Biblioteca Básica Híbrida

Wbhybrid

A função interativa híbrida, a função de distribuição de ação e algumas ações padronizadas

Componente de salto

WbpageTransferdispatcher

Tapped da lógica de salto e distribuição que suporta o protocolo de salto de aplicativo principal

Biblioteca de rede

Wbnetwork

A operação básica do acesso à rede é encapsulada e a operação de rede é mais próxima e conveniente

posição

Wblocation

A aquisição das estratégias básicas e o posicionamento dos dados originais são encapsulados pela embalagem

Biblioteca de cache

Wbcache

A implementação subjacente do cache e algumas operações básicas

... ...

Além disso, existem SDK padronizados fornecidos por outros departamentos centrais de Taiwan no grupo, como PassportsDK, IMSDK, Pay58SDK, etc.

2. Como apoiar a geração de aplicativos inovadores e aplicativos de velocidade

Conforme mostrado na figura acima, no estado da arquitetura de engenharia ideal (ou seja, atinge as dependências da arquitetura), você pode configurar a função exigida pelo aplicativo para gerar um pacote de colete ou um pacote de velocidade.

Obviamente, para lidar com as auditorias da Apple (as diferenças devem ser mantidas entre os aplicativos), algum processamento personalizado também deve ser executado para sacos de colete ou pacotes de velocidade. Este tratamento personalizado é concluído no projeto de mosaico anterior. Para detalhes, consulte o projeto Mosaic.

3. Como apoiar a tradução de negócios verticais

Negócios verticais: O negócio apresentado em vários aplicativos é chamado de negócios verticais.

Tradução de negócios vertical: Não é realmente emocionante, significa que os negócios subjacentes e a dependência dos negócios verticais são um conjunto de código público que pode ser executado em diferentes aplicativos.

A figura acima mostra que os dois negócios verticais de aluguel e moradia de segunda mão precisam chegar a um conjunto de código, enquanto executa no aplicativo 58App e Anju. Isto exige:

• 58App e ANJU App compartilhando o código subjacente que depende do negócio vertical (código do middleware+código básico da biblioteca);

• O código comercial vertical e o código subjacente dependente do código exclusivo no aplicativo 58App ou Anju não terão nenhum acoplamento, para que não carregue algum código não relacionado, que seja propício para controlar o tamanho do pacote;

O código comercial vertical e o código subjacente dependente devem atender aos princípios e dependências em camadas na arquitetura da fábrica de aplicativos, para que a escalabilidade da estrutura seja mais flexível

Como implementar a fábrica de aplicativos no código de ações

Com base na arquitetura técnica da fábrica de aplicativos e nas dependências de várias camadas de POD, o diagrama esquemático ideal da relação dependência de cada camada de pod é mostrado na figura abaixo (pegue as dependências de vagens de negócios de recrutamento como exemplo):

• Da camada de negócios até a camada de middleware à camada básica da biblioteca, da dependência superior para as dependentes, não há dependência de dependência e circulação reversa

• Não há dependência entre as camadas de negócios

• A camada de middleware e o banco de dados básico podem permitir dependências unidistáveis

Com as dependências ideais mencionadas acima, quando o projeto de entrada é configurado para gerar o código necessário para o aplicativo, ele pode ser configurado sob demanda. Aumente o tamanho do pacote.

1. POD de camada de negócios dissociada

A dependência do negócio de recrutamento mostrado acima. As setas pretas representam as dependências de vagem única e as duas dependências de vagens do POD representadas por setas vermelhas.

Observação: A camada de serviço corresponde às peças intermediárias e a camada de armazém de três partidas corresponde à camada básica do banco de dados.

Para a desacoplamento de vagens de negócios, o principal processamento da menor dependência do POD do POD de negócios e a dependência do POD de negócios, como mostrado na figura abaixo:

2. POD de camada de peça intermediária dissociada

Conforme mostrado na linha real da figura acima, a relação de acoplamento entre o Middleware Layer POD que o POD é recrutado.

As duas relações de acoplamento a seguir devem ser resolvidas pelo POD da camada de serviço:

• Acoplamento de dois caminhos entre pod

• Dependências desnecessárias entre pods

A dissociação da vagem da camada de serviço é fundamental e envolve diretamente a dependência do pod da biblioteca de ferramentas. Se as dependências circulares da vagem da camada de serviço não estiverem aliviadas, isso levará a todas as dependências do POD da biblioteca de ferramentas. Ele não poderá configurar o POD dependente da demanda, fazendo com que o tamanho da bolsa fique despreparado.

3. Camada básica da biblioteca empojeira

Como o POD básico do banco de dados é o POD inferior e nenhuma outra vagem dependente, também é a menor dessas três camadas de desacoplamento do POD.

Atualmente, o POD Basic Layer Camada no 58App é colocado em uma vagem. Essa camada de desacoplamento é dividir esse pod de acordo com a função e desmontá -la em uma unidade que pode depender da vagem superior.

Como garantir a qualidade da fábrica de aplicativos

A qualidade da fábrica de aplicativos é muito importante durante a iteração da versão. Se o código não seguir estritamente as dependências da POD da fábrica de aplicativos durante a iteração da versão subsequente, ele trará muita carga de trabalho adicional até que o problema seja descoberto.

1. Detecção de dependências de pod

Esta é a base para todos os testes de qualidade. Algumas das dependências do POD observadas neste artigo são derivadas das ferramentas de análise automática que desenvolvemos. Sem essa ferramenta, em alguns aplicativos médios e grandes, essa dependência é combinada manualmente, será uma ótima carga de trabalho. Vamos falar sobre pensar aqui, e há uma maneira melhor de receber a troca:

• Digitalize todas as pastas de código do pod no diretório de engenharia local e os arquivos da classe dentro, estabelecem uma relação de mapeamento entre os arquivos de classe e a engenharia de pod Filepo Dd TIC.

• Digitalize as dependências do arquivo (peça de importação) em cada arquivo de pod, de acordo com as dependências do arquivo da cabeça e o FilePo acima Dd TIC, a relação de dependência direta do pod pod Dd EPENDICT.

• As dependências diretas de todos os pods em série, formando a dependência do POD em PodfinalDepenGraph and Said. A estrutura de dados correspondente às dependências do POD é um diagrama.

Conforme mostrado na figura acima, é baseada em um diagrama esquemático com base no POD de recrutamento e no pod construído pelo POD (para facilitar a identificação, uma linha que depende diretamente um do outro em linhas pontilhadas). Com base nessa estrutura de dados, a detecção das dependências de fábrica de aplicativos mencionada no artigo anterior pode ser realizada.

2. A cápsula da camada inferior nas dependências reversas da vagem superior

As dependências reversas do POD superior no POD da camada superior são o principal conteúdo proibido das dependências da fábrica do App. Por exemplo, se a vagem de Wubarn na parte do meio depende do POD da página inicial superior, fará com que o código comercial da página inicial transporte a página inicial desnecessária por se basear em Wubarn.

Com base na direção mencionada acima, a detecção reversa é fácil de obter na tecnologia:

• Built -En Pod e Relacionamento de Mapeamento Hierárquico

• Há um diagrama da relação de dependência do pod para detectar se o nível de vagem em que o pod atual depende é menor que seu próprio nível. Se for menor, é revertido

• Emitir a relação de dependência reversa da marca

3. Detecção de dependência do ciclo de pods

Na fábrica de aplicativos, exceto que o código da camada de negócios tem um motivo muito claro, ele não pode ser dependente e o anel. Mesmo se houver um anel entre as outras camadas, existe uma maneira de atingir o objetivo de não carregar o excesso de código para a fábrica de aplicativos. No entanto, além da fábrica de aplicativos, a existência do anel é essencialmente um código público entre os dois pods na maioria dos casos. Portanto, para tornar as dependências da fábrica de aplicativos mais fábrica e mais fácil de executar, é estipulado uniformemente que a dependência cíclica não pode ser gerada.

A detecção é uma estrutura básica de dados com um anel que existe no diagrama, para que não entre em detalhes aqui.

4. Detecção padrão de poluição por peças intermediárias

O middleware padrão é o núcleo da fábrica de aplicativos. Se o middleware padrão estiver contaminado durante o processo iterativo de negócios subsequentes, ou seja, a introdução das dependências que não atendem aos padrões trarão custos adicionais de manutenção e custos de acoplamento. Portanto, se você puder detectá -lo no momento do ramo único e do ramo integrado, a probabilidade de poluição pode ser minimizada no mínimo.

Na fábrica de aplicativos, o middleware padrão apenas permite que o POD confie na camada básica da biblioteca. Portanto, a estratégia de detecção também é muito simples:

• Atravessando todo o middleware padrão

• Elfos, o POD dependente de cada middleware padrão e determina se o pod de que depende é a camada básica da biblioteca. Se não pertencer, marcará essa dependência contaminada.

• Saia todos os middleware padrão poluente e dependências insatisfatórias.

A experiência prática da fábrica de aplicativos

A fábrica de aplicativos possui uma ampla gama de aplicativos no 58App. Atualmente, ele foi aplicado na tradução da geração de aplicativos verticais e verticais em negócios verticais imobiliários e é lançada.

Prática de tradução para negócios vertical imobiliária (projeto Júpiter)

Desde o ano passado, a indústria de negócios imobiliários e residências de 58 cidades foi ajustada. Os negócios de aluguel e de segunda mão foram re -explicados e integrados nos dois aplicativos independentes. Após o ajuste dos negócios, os negócios de aluguel de 58 da cidade e a segunda mão de Anjuke se tornaram negócios verticais, ou seja, operou ao mesmo tempo nos dois aplicativos independentes do aplicativo 58 City e Anju. O ajuste dos negócios trouxe muitos desafios à arquitetura técnica:

• Como dividir a casa de 58 anos e Anjuke em segunda mão do aplicativo original?

• Como processar o código de dependência no processo de divisão para maximizar o código incompleto de transporte?

Pode -se imaginar que, se a fábrica de aplicativos não se basear nos objetivos acima, o que acontecerá?

• Carregando muitos outros aplicativos que não precisam ou código repetidos, fazendo com que o tamanho da bolsa esteja fora de controle.

• Escreva muitos protocolos para serviços específicos e cada aplicativo independente implementa sua própria implementação para o contrato. No entanto, existem muitas associações, especialmente para o custo de transformação para o código de ações.

Como resultado, o departamento de tecnologia sem fio 58 e o Departamento de Tecnologia Imobiliária (Departamento de Tecnologia Imobiliária da Anju House e 58 Departamento de Tecnologia Imobiliária) foram filmados juntos e aplicaram a fábrica de aplicativos à tradução de negócios vertical de imóveis.

1. Marco do projeto

Aqui vamos nos concentrar no marco do projeto para explicar a idéia de acessar a fábrica de aplicativos durante a tradução para negócios verticais multi -App.

Numeração

marco

Nó frontal dependente

1

58App Wireless Technology Side Package e fornece um banco de dados público necessário para negócios verticais

/ / /

2

58APP Acesso à biblioteca pública vertical de negócios mencionados acima

1

3

Aplicativo do Anjuke Acesso ao banco de dados público vertical acima mencionado

1

4

O negócio de aluguel se adapta ao aplicativo duplo e suporta os negócios na tradução de aplicativos duplos

1, 2, 3

5

Segundo -House Housing Business Line se adapta aos aplicativos duplos e suporte a tradução de aplicativos duplos de negócios

1, 2, 3

A partir da tabela e dependências acima, podemos ver que o projeto é dividido principalmente em três etapas:

• Retirar a biblioteca pública dependente do escritório de negócios vertical

• Cada aplicativo está conectado à biblioteca pública extraída

• Negócios verticais fazem alguma adaptação, que pode ser executada no aplicativo duplo ao mesmo tempo

A primeira fase da biblioteca pública foi usada por cerca de 1 mês e meio; a segunda etapa de cada aplicativo independente foi conectada à biblioteca pública com 1-2 versões (média de 3 versões de segunda-feira), que depende principalmente da situação do teste Recursos; a terceira fase dos negócios verticais foi usada em 2-3 versões.

2. Visão geral da implementação do projeto

2.1 bombeamento da biblioteca pública

A biblioteca pública aqui refere -se à biblioteca de código da camada de middleware e à biblioteca de código de camada básica da biblioteca em que o negócio vertical depende. Esta etapa é muito importante. Se não for processado, os negócios de seguir -up continuarão a trabalhar no processo de acesso.

Os negócios verticais específicos da análise de acoplamento do código do middleware e do código básico da biblioteca foram introduzidos em detalhes acima, e a descrição não é repetida aqui. Aqui temos que discutir uma pergunta muito importante na prática: como unificar o problema dos dois aplicativos independentes dos dois aplicativos independentes?

Esse problema é muito complicado. Tomando as partes intermediárias da rede como exemplo, cada aplicativo independente tem sua própria embalagem e a API encapsulada é muito diferente. É difícil suavizar a diferença ajustando o protocolo da API. Nesse caso, o método mais simples e eficiente é baseado em um aplicativo de uma parte como referência. O outro aplicativo Apples compatível com necessidades e abandona seu código original.

Considerando o volume do aplicativo e o impacto nos negócios, a discussão foi baseada no 58App como referência, e Anjuke usou as necessidades do código de negócios da segunda mão para fazer necessidades compatíveis. Depois que o 58App foi retirado, Anjuke re -acesso.

A biblioteca pública final (middleware padrão) que é alienada é mostrada na tabela abaixo:

Middleware

Descrição da função

Biblioteca de rede

A operação básica do acesso à rede é encapsulada

base de dados

As interfaces envolvidas no mesmo aplicativo da cidade incluem listas da cidade, listas de metrô, dados do distrito comercial, registros de navegação histórica e armazenamento e leitura de informações de pegada.

Biblioteca Básica Híbrida

A função interativa híbrida, a função de distribuição de ação e algumas ações padronizadas

Reaja biblioteca básica nativa

A função básica do RN, incluindo a página da transportadora, atualização térmica, otimização de desempenho e alguns módulos padronizados

Biblioteca de posicionamento

A aquisição das estratégias básicas e o posicionamento dos dados originais são encapsulados pela embalagem

Biblioteca de cache

A implementação subjacente do cache e algumas operações básicas

Biblioteca de salto de rota

Tapped da lógica de salto e distribuição que suporta o protocolo de salto de aplicativo principal

Biblioteca de Protocolo

Fornecido à parte do protocolo (protocolo) que suporta negócios cruzados para ligar para a camada inferior, e a implementação específica é implementada por diferentes plataformas

Biblioteca de parâmetros públicos

A geração e a obtenção da API de alguns parâmetros comuns públicos são encapsulados e você pode obter automaticamente o chefe de solicitação, o cookie e outros parâmetros públicos no aplicativo 58 City.

Há dois pontos -chave sobre a descamação da Biblioteca Pública:

• Centrar o banco de dados público dependia do negócio a ser transferido, não seja ganancioso. Com os drivers de negócios, a biblioteca pública é despojada. Com o acesso gradual e o apoio contínuo aos negócios, o número e as capacidades da biblioteca pública aumentaram gradualmente.

• Não é difícil retirar tecnicamente o banco de dados público. É difícil maximizar o impacto em outros negócios e garantir a estabilidade dos negócios de afiliados.

• Conforme descrito na arquitetura anterior, a biblioteca pública possui preços intermediários padrão e middleware comercial. Não há introdução específica ao middleware comercial aqui. Porque a dependência do middleware comercial é mais complicada. Quando dividida específica, você deve analisar o custo dividido em detalhes.

2.2 Cada aplicativo independente está conectado à biblioteca pública

A tabela a seguir lista os esquemas de acesso dos quatro representantes de quatro middleware no processo de implementação.

Middleware

Anjuke Segunda House

58App Alugar uma casa

Biblioteca de rede

Migrar o código da segunda mão de Anjuke para 58App, use 58 bibliotecas de rede, suporte HTTPBody, Anjuke Business Code para fazer alterações apropriadas.

O código de aluguel de 58App para Anjuke, Anjuke, é uma camada de API adequada e o código comercial 58APP imobiliário não precisa ser alterado.

base de dados

A migração do código de habitação de segunda mão para Anjuke para 58App não está envolvido no negócio e não precisa considerar o problema do banco de dados.

O código de aluguel do 58APP é realocado para Anjuke e apenas o banco de dados e a tabela de dados em 58 são transportados. O código comercial não precisa ser alterado.

Híbrido

O código da segunda mão de Anjuke foi migrado para o 58App, e o código comercial foi compatível com a compatibilidade.

O código de aluguel do 58APP é realocado para Anjuke, carregando o SDK simplificado de 58 a lado, os recursos de expansão da ação são implementados independentemente na residência e o código comercial não precisa ser alterado.

Jump Center

Mova o código da segunda mão do Anjuke para 58App para modificar o código comercial para se adaptar ao protocolo de salto 58;

O código de aluguel do 58APP é realocado para Anjuke, não há necessidade de modificar o código comercial.

Nativo

Nativo

Nativo

Por se basear nas peças intermediárias 58APP, o código de aluguel 58APP não é basicamente alterado durante o processo de tradução. No entanto, o código comercial da ANJU precisa ser alterado de acordo, o que não pode ser salvo. A julgar pelo atual código de função de Anjuke Second -House, esta parte foi alterada com sucesso.

2.3 Tradução de negócios vertical

O banco de dados público dependente de negócios verticais acima mencionado não significa que o negócio vertical possa ser movido após cada acesso independente do aplicativo. Um dos principais objetivos da fábrica de aplicativos não é transportar código não relacionado. Além da dependência da biblioteca pública, os negócios verticais também dependem de outro código do módulo em seu próprio aplicativo. Somente maximizando a dependência desses código de dados não públicos, ou seja, dividindo -se no middleware comercial, podemos realmente cumprir os objetivos da fábrica de aplicativos.

Não há descrição específica de como resolver o middleware dos negócios. A principal introdução de vários critérios no processo de operação é introduzida principalmente. Desde que você compreenda esse critério, basicamente não há grande problema:

• Analise se o código de dependência pode ser transformado em um middleware comercial. O middleware comercial deve atender ao princípio de dependência de uma via da narrativa anterior, caso contrário, não será possível analisar durante o processo de transporte do código.

• Se o código de dependência for apenas alguns arquivos, não será suficiente dividir o middleware comercial. Algum código duplicado pode ser permitido na premissa de que o tamanho do pacote não afeta.

• Durante o processo de divisão de middleware comercial, é necessário garantir que isso não afete outras linhas de negócios. Por exemplo, imóveis e recrutamento dependem de um código de middleware comercial. No processo de atender à tradução de negócios imobiliários, você deve encontrar uma maneira não afetar o código de recrutamento.

• Preste atenção à seleção de soluções comuns. Por exemplo, quais cenários devem ser notificados, quais cenários devem ser usados para o tempo de execução e quais cenários devem ser propocolo.

3. Resultados do projeto

Este projeto foi concluído juntos pelas três partes. Aqui eu só disse que alguns dos lados do iOS sem fio:

Incidente

Explicação

1 conjunto Aplicativo Fator

Arquitetura de layout e dependências de cada camada são usadas como critério básico para desacoplamento de pods

2 Suporte de geração de aplicativos

APORT APPION DE INOVAÇÃO, APP Independent App Vertical Business Generation

3 Ferramentas de garantia de qualidade de automação

Detecção padrão de poluição por peças intermediárias, peças intermediárias Ocupe a detecção do tamanho do pacote, compilação automática e sincronização da biblioteca estática do preço médio

4 Categoria de questões centrais Esquema de compatibilidade

Salto unificado, tradução para negócios verticais híbridos, biscoitos e unidade de cabeçalho, compatibilidade de negócios personalizados

14 middleware padrão

Por exemplo

430 categorias, 3309 métodos

O preço médio de 14 padrões envolve 430 aulas e 3309 métodos

App 58 App 58 App 58 App 58 App 58 A tradução de negócios vertical com a tribo (está em andamento). A dissociação do middleware comercial está relacionada aos negócios específicos e não há penteado detalhado aqui.

No plano do Júpiter, a receita do pacote e a estabilidade após o acesso no programa Júpiter são mostradas na tabela da seguinte forma:

índice

58App Acesso Aplicativo fábrica

Anjuke Aplicativo Acesso Aplicativo fábrica

os dados mostram

Tamanho da bolsa

Dar 58 Rental House se move para Anjuke Aplicativo Salve 73 Mb cerca de

Peças intermediárias de aluguel (41,2 MB)+biblioteca de três partes (43,8 MB) dependendo de peças intermediárias padrão de acesso ao aluguel-som-anjuke (11,4MB) = 73 .6MB

Dê a segunda casa de mão de Anju, vá para a segunda casa 58App Salve 28 MB

Dependências da segunda mão (1 3.0 8 MB)+a trilogia (14,88 MB) = 28 MB que a segunda casa depende de depende

O tamanho do pacote salvo é calculado de acordo com o código que precisa ser transportado antes e depois do acesso à fábrica do aplicativo.

Colapso

Edição 8.22 antes do acesso, 1.1) de um milésimo da taxa de colapso e 1 milésimos de versões de 8,23 após o acesso

A taxa de colapso da versão 12.14 antes do acesso e 1,3 versões de 12.16 após o acesso

A versão 12.16 colapso da fábrica de aplicativos da fábrica de aplicativos não tem nada a ver com a fábrica do aplicativo, principalmente do colapso de outras empresas.

Pode ser visto na tabela acima que o tamanho do pacote tem um grande benefício, seja 58App ou App ANJU. A taxa de colapso não mudou significativamente antes e depois do acesso, e o código no código foi bem executado. Especialmente para a taxa de colapso e a estabilidade funcional, envolve uma mudança de escala tão grande e não é fácil alcançar acidentes on -line.

58 Tongcheng Recruitment App (App Innovation App) Prática de geração

Aplicativos inovadores e aplicativos de edição de velocidade são o mesmo tipo de aplicativos. A maioria das funções básicas pode usar os recursos básicos da fábrica de aplicativos. Devido às restrições da Apple às regras do pacote de colete, a semelhança da função terá um grande risco de revisão. Portanto, seja um aplicativo inovador ou uma versão de alta velocidade do aplicativo, com base nas restrições da revisão da Apple, o código necessário para a porcentagem não deve ser gerado. Algum código precisa ser desenvolvido um desenvolvimento adicional. Quanto ao quanto o código se desenvolveu, não há certeza para a resposta. Ele pode explicar à Apple explicar as diferenças nos modelos de negócios. É rei através da Apple Review.

Ao contrário do projeto Júpiter, diferentemente da fábrica de aplicativos, a geração de código de aplicativo inovador será descrito como um ângulo, concentrando -se no penteado e dissociação das dependências do POD.

1. Acoplamento penteado de dependências de pod

O objetivo do combate ao acoplamento das dependências do POD é recrutar o POD dependendo de qual vagem é direta ou indiretamente dependente. Qual dessas dependências não atende às dependências das fábricas do aplicativo, como interromper algumas dependências para alcançar as dependências de fábrica de aplicativos?

Existem duas linhas pontilhadas cinza no diagrama de dependência acima. Toda a imagem é cortada em três partes. De cima para baixo, a camada de negócios, a camada de middleware e a camada básica da biblioteca na arquitetura da fábrica de aplicativos. Entre eles, a flecha do garfo indica que não atende às dependências da fábrica de aplicativos:

• A vagem de negócios é horizontal. Por exemplo, o recrutamento e o POD do centro de usuário pertencem à camada de negócios, mas o POD de recrutamento depende da POD do centro do usuário, que pertence às dependências horizontais na mesma camada. Essa dependência precisa ser cortada.

• A vagem inferior depende da vagem superior. Por exemplo, a vagem do Jump Center depende da vagem da página inicial, a vagem do Salting Center pertence ao Middleware POD, e o PAGE HOME PAGE pertence à camada de negócios. para ser cortado.

Pode -se observar que, se as dependências mencionadas acima que não atendem à dependência das dependências da fábrica de aplicativos, o pod de recrutamento não depende do cento do centro pessoal e da página da página inicial. Quando o código do aplicativo é gerado, ele não será transportado Código desnecessário (individual o código do centro e o cápsulas da página inicial e um monte de código de que depende).

2. Medidas de libertação de acoplamento de pods

Finalmente, o elevador de acoplamento de pod deve ser desbloqueado para o relacionamento de chamada entre o código com o pod. Encontre a fusão de acoplamento do arquivo de código a ser levantada de acordo com a situação.

Nossa remoção de acoplamento de código comum significa:

• Mover o arquivo de código. Esse é o menor custo, e o efeito do teste é relativamente mínimo, que é a primeira solução recomendada. Depois de mover arquivos de código para um podfit adequado, a relação de acoplamento dos dois pods originais é levantada automaticamente. Um princípio de escolher esse podfit apropriado é que o pod original dependia originalmente desse podFit. O aumento dos novos arquivos de código não trará uma nova dependência. Mas, às vezes, não existe vagem existente. Nesse momento, é necessário avaliar a criação de um novo pod para resolver essa situação.

• Método de movimento ou atributos públicos. Esse é um meio de alto custo. Após a posição do método ou dos atributos públicos alterações, é necessário resolver a lógica de negócios de vários usos, principalmente preste atenção à chamada dinâmica do método de tempo de execução.

• O acoplamento é desbloqueado durante a compilação. Existem muitas chamadas entre o código. De fato, não é necessário. Por exemplo, o POD de recrutamento tem uma lógica que envia currículos e meu currículo de acoplamento de negócios. Depois que o usuário enviar um currículo no módulo de recrutamento, o centro pessoal precisa ter uma exibição de função correspondente. O módulo de recrutamento precisa passar uma mensagem para o módulo do centro pessoal. A transmissão desta mensagem pode ser implementada pela notificação, ou a API fornecida pelo centro pessoal pode ser chamada diretamente. Mas não importa que tipo de implementação, essa transmissão de mensagens não afete a independência dos negócios do módulo de recrutamento. Mesmo que o centro funcional não tenha função, o módulo de recrutamento pode ser executado. Nesse caso, a dissociação, desde que seja garantida que a compilação do tempo não esteja errada, use notificações para usar algumas chamadas diretas da API ou o método de chamada de tempo de execução.

• O código público afunda. Existem muitas chamadas de código necessárias no tempo de execução. Para esses códigos, você não pode usar os meios de acoplar para ser desbloqueado durante a compilação. Você precisa afundar essa parte do código para a próxima camada, como a camada de middleware. Os meios de afundar o código público e os meios de mover o arquivo de código mencionados anteriormente estão se cruzando, mas existem diferenças. O arquivo de código enfatiza o movimento do arquivo de código. Ele não precisa ser movido para o POD inferior; o código público afundou pode estar afundando no arquivo de código ou em um determinado método afundando.

• Isolamento de código baseado em acordo. Há também uma situação comum que precisa ser proposta que muitas empresas são diferentes em aplicativos diferentes e é difícil resolver com um conjunto de códigos. Em resposta a essa situação, uma camada de protocolo precisa ser retirada e o contrato é chamado no código público. A implementação diferente é concluída com base no protocolo no aplicativo de acesso.

Desaparelamento do pod, especialmente envolvendo o declínio no código da camada de negócios e no código da camada de middleware, é difícil medir qual acoplamento de pod está certo ou errado no início. Porque no início do nível do produto, muitas empresas não consideraram que esse negócio é um negócio vertical, que será movido no Multi -App. No entanto, uma vez que uma empresa está determinada a apoiar o Multi -App, o relacionamento de dependência do POD envolvido nesse negócio deve atender às dependências da fábrica de aplicativos. Este ponto deve receber atenção especial à iteração contínua dos negócios subsequentes.

controle de risco

Toda a reconstrução de código da fábrica de aplicativos envolve uma ampla gama. O 58App mudou o código na fábrica de aplicativos este ano. Os negócios e a arquitetura de cada empresa são diferentes, e a complexidade do Código e a dificuldade da reconstrução também são diferentes; portanto, os riscos on -line que enfrentam também serão diferentes. Além do processo de reestruturação, além de ter uma rigorosa revisão técnica de solução, revisão de código e teste de caso abrangente, especialmente dois pontos que são fáceis de serem ignorados, mas fáceis de causar problemas:

• Versão iteração de fusão e omissões riscos

No 58App, com o aprofundamento contínuo da fábrica de aplicativos e o acesso gradual aos negócios, a divisão da camada de middleware e a camada básica de serviço se tornaram cada vez mais finas. Atualmente, os dados do POD têm mais de 50. Ao mesmo tempo em que o projeto de fábrica de aplicativos é realizado, há uma versão diária dos projetos de demanda em desenvolvimento paralelo. No processo, o mesmo código pode ser alterado na fábrica de aplicativos, mas também se desenvolve com as novas necessidades correspondentes.

O projeto de fábrica do App é relativamente longo. Por exemplo, um determinado preço do meio é desenvolvido com base na versão 8.0. No processo, devemos mesclar constantemente o novo código da versão para a filial de fábrica de aplicativos atual. E você deve lidar com algum código de conflito. O teste de mudança do código da camada de middleware e o código da camada de serviço básico sempre foram um ponto de dor, e é difícil cobrir todos os cenários de negócios. Portanto, é necessário lidar cuidadosamente com conflitos e alterações para evitar problemas on -line.

• Risco de acoplamento de dados

O acoplamento de dados refere -se a algumas operações e dependência do código comercial de determinados dados públicos. No entanto, as dependências de dados não podem ser encontradas durante a compilação e a maior parte da operação, o que traz grande dificuldade para encontrar problemas. Por exemplo, os dados do distrito comercial, dados enterrados e usuários nos aplicativos Telefone Registros de discagem, registros de coleta de postagem etc. estão todos na categoria de acoplamento de dados.

Assim como a versão acima da fusão e omissões, o princípio do processamento de riscos de acoplamento de dados também é resolver e decolar em detalhes os negócios que afetam os dados. É necessário lidar com isso de forma abrangente de vários nós -chave, como desenvolvimento, teste e Verificação de dados em escala de cinza.

Resumir

Qualquer arquitetura é inseparável do negócio. É para resolver pontos de negócios e problemas de negócios, e a fábrica de aplicativos não é exceção. Como a arquitetura de aplicativos de cada empresa é diferente, os formulários de negócios são diferentes e as formas de cooperação departamental também são diferentes, não deve haver critérios de teoria e implementação de fábricas de aplicativos para o mundo.

Durante a implementação do 58App, a capacidade de melhorar gradualmente a fábrica de aplicativos através do acesso contínuo dos negócios. A parte perfeita da capacidade tem a capacidade de padronizar e possui recursos não padronizados. E a padronização e a não padronização podem ser transformadas com a iteração de negócios subsequentes. No futuro, o 58App continuará a acessar mais negócios para continuar a resolver problemas de negócios e melhorar a pesquisa e o desenvolvimento de negócios.

A fábrica de aplicativos é o resultado do trabalho em equipe. Obrigado por participar dos alunos. A fábrica de aplicativos, desde a idéia de implementar e o acesso comercial, é um pequeno movimento nos últimos anos. Sem a concepção, planejamento, orientação, orientação e a implementação coordenada de estudantes em todos os níveis do valor do usuário, não há chefes e colegas de classe do Departamento de Tecnologia Imobiliária (Departamento de Tecnologia Imobiliária da Anju House, 58 Ganji Real Estate Technology Department ), os departamentos de tecnologia de recrutamento e outros departamentos de colaboração de precisão e prática comercial são um projeto tão grande que não pode ser iniciado e concluído.

autor:

PENG FEI, 58 Departamento de Tecnologia-Básica da Cidade Arquiteto de Tecnologia, Chefe do Departamento de Tecnologia da IOS.

Zeng Qinglong, 58 Departamento de Tecnologia-Básica da Cidade Arquiteto de Departamento de Tecnologia

Wang Xiaohui, 58 Departamento de Tecnologia da Cidade-Basic-Iios Departamento de Tecnologia Engenheiro de Pesquisa & D