移动互联网软件工程

Android

开源

IOS

闭源

HarmonyOS

Open Harmony

Harmony

鸿蒙提供了Stage,其中WindowStage类似Activity,AbilityStage类似Service

还提供了分布式软总线,相当于将不同的终端连接起来

系统采用分布式数据管理

一次开发多端部署,方舟编译器

Stage模型

UI ability 生命周期

UIAbility启动模式

  • 单实例模式
  • 标准实例模式
  • 指定实例模式

Want类型

  • 显示Want
  • 隐式Want

Stage

多应用组件在运行时共享同一个虚拟机引擎

多HAP机制

拆分成不同的HAP,供不同型号的设备下载

静态共享包 HAR 动态共享包 HSP

语言渊源

Js 由Mozilla创造

前端框架: React Vue

Ts 由微软创造

ArkTs 由华为创造,增加了

  • 基本UI描述
  • 状态管理
  • 动态构建UI元素
  • 渲染控制
  • 使用限制与扩展

测试用例改造

stateDiagram
    用例编写 --> 用例评审
    用例评审 --> 用例执行
    用例执行 --> 用例编写
    用例执行 --> 人工测试
    用例执行 --> 自动化测试

鸿蒙开发:案例讲解TO-DO List

状态管理

  • ViewUI: UI渲染,一般指自定义组件的build方法和@Builder装饰的方法

需求

  • 理想汽车:贴近场景的设计
  • Apple:一致性体验
  • 符合战略的需求

涉众分析

常见的问题

  1. 没有选定用户
  2. 选中所有用户

优先级评估

power

interest

如果已经有人在领域做了,那就找垂直领域,找小的切入点

在领域内还可以细分市场

ArkTs运行时

RN

  • 前端javascrip
  • Android bridge/ios bridge
  • 抛弃浏览器渲染,通过自己的DSL生成中间格式

Flutter

自渲染,前面的都是对原生组件做映射

现代UI框架

  • widgets
  • Render tree
  • Layer tree
  • Bitmap

云原生

循环依赖

循环依赖引发的核心问题在于一旦依赖环中的一个包对外宣告进行了修改,依赖它的包也得修改,这种修改通知会在依赖环上持续的传递

从单体到微服务

  1. 通过服务组件化

    组件是一个独立可替换和独立升级的软件单元

  2. You build it, you run it

  3. 去中心化治理

  4. 去中心化数据管理

    每个服务可以基于自己的数据库

  5. 基础构建管道

  6. 为失效设计

    应用程序要被设计为能够容忍服务失效

DevOps

设计模式讲解

经典组合、实现与集成

classDiagram
shop o-- taxCaculator
pizzaShop --|> shop
burgerShop --|> shop
sameTax ..|> taxCaculator
increaseTax ..|> taxCaculator

优点

  • 动态配置Caculator
  • 实现不同的shop

缺点

  • 需要能抽象出taxCaculator
  • caculator可能需要获得复杂的数据才能实现功能

抽象工厂

核心思想:希望将对象的创建委托给工厂

优点:

  • 客户端不需要了解工厂,他只需要持有一个抽象工厂的引用,在启动时正确的初始化抽象工厂为具体的工厂,然后把创建都交给工厂就行了,而不是不停地去指定不同的工厂

  • 如果想要新增一套产品,只需要增加一个新的具体工厂和一组新的具体产品

缺点:

  • 如果想要增加产品,需要修改包括抽象工厂的所有工厂,非常痛苦

桥接模式

可以将这个类和那个类的功能通过桥接联系起来,灵活实现

架构

应用架构

  • 稳定性原则
    • 一切以稳定为中心
    • 架构尽可能简单清晰
    • 不过度设计
  • 解耦/拆分
    • 稳定部分与易变部分分离
    • 核心业务与非核心业务分离
    • 主流层与辅流程分离
    • 应用与数据分离
    • 服务与实现细节分离
  • 抽象化
    • 应用只依赖服务的抽象
    • 数据库抽象化
    • 服务器抽象化
  • 松耦合
    • 跨域调用异步化
    • 非核心业务异步化
    • 必须同步调用时,需要设置超时时间和任务队列长度
  • 容错设计
    • 服务自治
    • 集群分布
    • 机房灾配

服务设计

  • 无状态
  • 可复用
  • 松耦合
  • 可治理

远程访问服务

RPC远程方法调用

最初是希望就像调用本地方法一样调用远程服务器上的方法

进程间通信
  • 管道
  • 消息队列
  • socket
三个基本问题
  • 如何表示数据
  • 如何传递数据
  • 如何表示方法

数据架构

  • 统一数据视图
  • 数据、应用分离:应用不直接访问数据库,而是通过服务访问
  • 数据异构
  • 读写分离
  • 合理使用缓存

系统运行时原则

  • 可监控
  • 应用可回滚,功能可降级

系统部署原则

  • N+1:为确保故障多搭建一套系统
  • D-I-D:设计20倍容量,实现3倍容量,部署1.5倍的容量
  • 支持灰度发布
  • 虚拟化部署
  • 业务子网

大型网站架构演化历程

  1. 一个服务器
  2. 服务器分离
  3. 使用缓存改善网站性能
  4. CDN和反向代理