企业官网建设流程全解析

目录

1. 图片缓存框架设计简单介绍

2. 阅读时长统计

3. 复杂页面架构

4. 客户端整体架构设计

图片缓存框架

1. 如何设计一个图片缓存框架

首先我们要有一个管理者，用于管理内存和磁盘上图片的存储，然后还可以通过网络请求图片

同时我们还需要一个解码的管理者，用于图片解码和图片解压缩

1. 图片如何进行读写，过程是怎样的

我们可以使用图片URL的单向哈希值作为KEY

流程如上，依次通过内存，磁盘，网络进行获取

1. 内存上的设计需要注意哪些问题

• 内存存储的空间大小

我们可以通过图片使用的频次和图片的大小来设计对应的size

我们可以使用队列这个数据结构来组织图片的存储

• 淘汰策略

这里可以使用多种方案，这里介绍两种

1. 队列先进先出的方式进行淘汰 2. LRU算法淘汰（如在30分钟内是否使用过）

检查策略可以使用上述几种。其中定时检查不建议使用，这里只是作为一种方法介绍，在使用一个方法的时候我们一定要注意开销

1. 磁盘设计要注意什么问题

磁盘的特点就是磁盘空间大，读取效率低

• 存储方式

• 大小限制

• 淘汰策略

1. 网络设计注意问题

• 图片请求最大并发量（同一时间请求的最大并发数量需要加以限制）

• 请求超时的策略（如果发生超时，一般我们选择再进行尝试，如果再失败则放弃，对于上层使用一张默认图片作为请求失败的默认显示）

• 请求优先级（判断我们当下请求的图片是否是经常使用的，来判断当前优先级）

1. 图片编解码

• 对于不同格式的图片，图片解码我们使用什么来做

我们可以使用策略模式对不同图片格式进行编解码

• 在哪个阶段我们进行图片解码处理

这里认为可以在磁盘读取后 和 网络请求返回后

1. 整体图片缓存框架的图片存储

这里仅介绍一下我认为的处理方式

如果内存中存在，直接返回结果即可

如果内存中不存在，在磁盘中查找，查找成功返回结果并存储到内存

如果磁盘中查找不到，进行网络请求，网络请求返回后先存储到磁盘，然后再从磁盘中解码拿到内存

阅读时长统计问题

1. 如何设计一个时长统计框架

面向上层业务页面，适配 APP 内全部阅读交互场景，对外提供统一调用入口：

页面式： 适配分页阅读场景（小说章节翻页、资讯分页），以单页为计时单元，触发时机：页面可见 / 页面消失、翻页切换；自动计算单页停留有效时长。

流式： 适配无分页长文本（信息流、无限下拉小说），分段滑动计时，页面滑动暂停、切后台、退出时截断当前阅读时长片段。

自定义式： 开放给业务自定义场景：弹窗阅读、局部浮窗、活动专题模块等非常规阅读场景，由业务主动调用接口传入起止时间、业务标识。

处理中心作为埋点数据统一调度中心，负责内存缓冲、本地持久化、网络上报，隔离业务层与 IO / 网络操作：

• 记录缓存（内存队列）

短时缓冲埋点，避免频繁磁盘 IO；

聚合合并同一章节多条短时记录，减少上报条数；

节流策略：攒满 N 条 / 间隔 X 秒，再批量落盘。

• 磁盘存储

本地持久化（SQLite / 二进制文件），解决断网、APP 杀进程、崩溃丢失数据问题；

自动清理策略：删除 7 天以上过期记录、超出容量阈值时先进先出删除旧数据；

• 上传器

管控网络上报策略：区分 WiFi / 移动网络动态开关上报；

批量打包上传，失败指数退避重试；

服务端回执上传成功后，删除本地对应磁盘记录；断网时暂停，恢复网络自动补发。

复杂页面架构设计

整体架构

我们以微博的架构来作为案例进行讲解

这套架构严格遵循分层单向依赖原则，自底向上分为三层：数据层（Engine+Model）→ 业务逻辑层（ViewModel）→ 视图层（ViewController+View）

• 视图层（view & viewController）

view只接收上层传入的UI 专用渲染数据（imageObj、label 富文本对象、按钮状态标记），内部不做数据格式化、时间转换、富文本拼接；用户点击、滑动、输入等交互事件不自行处理，通过闭包 / 代理回调抛给上层 ViewController，不直接持有 ViewModel。

viewController是视图层和业务层的桥梁

数据订阅：监听 ViewModel 对外暴露的 UI 数据信号（Combine/RxSwift 响应式信号），收到新数据后刷新 TableView/CollectionView；

事件转发：接收 View 抛上来的用户操作（点赞、下拉刷新、点击头像、转发微博），将指令转发给 ViewModel，自身不实现业务；

• 业务逻辑层（viewModel）

viewModel是业务逻辑唯一收敛层，隔离视图层与底层数据层，承担「数据转换」+「业务处理」两大核心工作，全程不依赖任何 UI 控件，可脱离页面单独单元测试。

• 数据层（Engine & Model）

数据层是架构最底层，负责原始数据的获取、解析、持久化，向上仅输出标准化业务 Model，屏蔽网络、数据库底层细节。拆分为 Engine 数据引擎、业务Model 领域实体两部分。

数据流

网络数据一般情况下由server通过json（key - Value）传递，业务层使用id + type对数据进行区分，ViewModel接收业务 Model，将其转换为UI 专用渲染数据，UI 数据交给ViewController，最终绑定渲染到View页面。

同时沿着这条链路可以进行反向更新，用户在 View 上产生交互，事件先回调到 ViewController，VC 将交互指令转发给 ViewModel，然后ViewModel 执行对应逻辑：包括本地修改和网络操作

总结

1. MVVM框架介绍

model作为纯粹的数据载体，数据变更通过绑定通知 ViewModel

viewModel收敛全部业务逻辑，监听 Model 的原始数据，预处理为适配页面渲染的 UI 专用数据

view层接收上层传入的 UI 渲染数据，完成页面绘制，同时捕获用户点击、滑动、输入等交互事件，通过回调抛给 ViewController，再由viewController转发进行业务处理

1. RN数据流思想

客户端总体架构设计

独立于App的通用层：比如时长统计的框架，网络的第三方库等

通用业务层：比如自定义的一个UI，自定义的一个组件

中间层：协调和解耦的作用

1. 业务之间的解耦方式

• openURL

用字符串路由地址做中间隔离层，统一路由中心分发请求。

• 依赖注入

通过中间层使用某一方法获取遵循某一协议的实例