主页

iOS工作流整体规划报告

背景 新的一年开始了,随着公司不断的发展壮大,我们的业务线也随之快速横向裂变。之前的三期工程化方案是针对当时公司单一主包、多业务线合并的思路设计而来的,足以满足当时的使用场景。 但是现在的公司已经开始扩展各种海外单包,并且不同的单包之间还出现了业务上的独立发展,并且由于防止因代码雷同而导致的审核风险,我们必须对现有的代码进行混淆处理才能对安心上线。 在这样的背景下,服务端开始尝试通过通用服务平台化的方式来满足业务扩展的需求。而我们客户端也希望通过整体程序架构的改进和工作流的优化,来满足公司未来产品方向的需求。 计划目标 客户端代码 解决客户端代码在多业务、多需求、多单包、单版本要求下,开发流程容易阻塞的问题,同时提高代码复用率,减少重复开发成本,到Service为止全...

阅读更多

iOS工作流设计文档

前言 新的一年开始了,随着公司不断的发展壮大,我们的业务线也随之快速横向裂变。之前的三期工程化方案是针对当时公司单一主包、多业务线合并的思路设计而来的,足以满足当时的使用场景。 但是现在的公司已经开始扩展各种海外单包,并且不同的单包之间还出现了业务上的独立发展,并且由于防止因代码雷同而导致的审核风险,我们必须对现有的代码进行混淆处理才能对安心上线。 诸如此类的业务发展方向的变化,导致了之前的工程化工作已经不能完全满足现有的需求,因此我们组长之间也对此进行了讨论,认为更新现有业务组织迭代方式迫在眉睫。本篇内容将更多的在理论环节对workflow的工作进行阐述,如有建议或者意见,欢迎大家反馈。 解决目标 通过ci流程自动化处理重复的操作,如语法检查、单元测试、代码混淆,co...

阅读更多

iOS端弱业务服务池设计文档

一、 什么是弱业务服务池 根据iOS端目前的工程化设计蓝图,我们将iOS的app结构,从代码的组织形式上分为四层结构。 其中的基础层和核心层的建设已经基本完成,接下来的主要工作是弱业务层的构造。而弱业务服务池就是对弱业务层中各类业务的统一规范和抽象。根据实际情况发现,弱业务的共性主要是需要统一进行生命周期的管理和集中的对账户信息的依赖(uid)。因此弱业务池的核心部分就是对以上两点的实现。 二、 为什么要拆分弱业务,如何拆分 弱业务本质上就是复用性足够高的业务,在移动端中,UI基本很难复用,Controller内的业务逻辑与表现给用户的功能的联系过于紧密,只有数据模型相关的业务与对应的处理逻辑相对通用。因此对于多个业务场景共用的数据和数据流的处理可以进行抽象,根据实际功能范围设计...

阅读更多

iOS远程调试工具设计文档

前言 由于业务迭代速度增快,我们遇到线上问题进行排查时复杂度也在不断增加,对于客户端来说,现有的排查方法无非只有查看crash后台、根据客诉信息尝试复现场景;对于线上问题的修复方式更是只能让服务端做兼容,如果遇到兼容配置无法满足需求的时候只能做发版处理。因此对于客户端来说有一套完整的可在线调试的系统的构建迫在眉睫。 设计目标 Doctor与其说是一个功能模块,不如说是一个工具集。对于一个工具集来说以下几点要素是必须要考虑的: 操作的便利性 支持复杂的调用结构 可以轻松横向扩展功能集,功能之间可以有依赖、也可以相互独立 对多个命令有批处理能力 功能的错误调用抛出的内部异常不会导致主程序崩溃 对于前两点我们通过模仿shell的调用方式,将字符串解析为命令,...

阅读更多

iOS聊天业务程序设计文档

前言 胜者先胜而求战,败者先战而求胜 大部分业务开发人员在开发的时候,经常没有通盘的思考结构设计和方案,或者因为经验不足而思考不全,一句话:先搞,遇到问题再说。这样对于业务简单的需求来说还好,但是对于复杂的业务模块就是灾难了,因为它从一出生就是修修补补出来的,扩展性、可维护性、稳定性都是很大的问题。随着业务的发展和业务场景的多变,会变成一颗随时爆炸的雷。 意义 奠定业务开发人员在模块设计方面的积累 应用到各个业务开发中,促进整个项目的设计规范统一,进一步提高互备的效率和质量 目标 大家对聊天业务模块的熟悉 大家对业务模块的设计有自己的思考和积累 未来要沉淀出公司特色的业务设计结构 发现问题 随着聊天业务的不断扩展,旧的chat相关业务程序设计...

阅读更多

iOS 客户端组件化之路

前言 随着业务的发展,产品的需求不断的增加,功能模块越来越多,开发人员逐渐膨胀。因此明确职责分工,剔除冗余结构,避免重复工作,减少多人合作冲突变成了非常重要的事。而组件化就是完成这些目标的一种方案。 目前市面上对组件化方案对讨论也有了很多,但是大多都只局限在路由这块,本文将阐述我对组件化项目的思考和演进路线的安排,希望大家能多多给出建议和意见,共同完善我们的产品。 范围 组件化在前端已经是一种非常常见的架构方式了,后端也有类似的微服务。但是客户端这边目前还是处于不太成熟的阶段。组件化的本质就是从混成一团麻的项目中,抽离出具有高度复用性的模块。因此在说明组件化方案之前,我们需要先描述组件化的范围。 目前公司的 iOS 端的结构如下: 目前主要存在的问题有以下几点: ...

阅读更多

iOS组件化实践(三):实施

前言 上一篇中我们对组件化的准备工作做了介绍,这篇文章我们以SXNews为例进行组件化,Demo地址在这里,壳工程获取脚本在这里,希望本文能给你带来帮助。 一、修改配置 根据上一篇文章所述,你应该已经有了ModularizationDemo文件夹,此时该文件夹中只有config和OldProject两个子文件夹。这时我们应该针对项目情况,修改config内容。 这里是SXNews的Podfile 根据这个文件,我们可以得知该项目主要使用了RAC等框架开发,因此为了方便起见,我们需要修改一下我们的config: 通过终端进入config文件夹内,后面的路径是你的文件夹路径 cd ~/ModularizationDemo/config 修改conf...

阅读更多

iOS组件化实践(二):准备

前言 上一篇中我们对组件化是什么和常用的组件化中间件方案做了简单的介绍,这篇文章则是用来说明开始进行组件化时需要做哪些准备工作,希望本文能给你带来帮助。 一、概述 在实施组件化之前,我们需要进行一些准备才能保证接下来的工作顺利愉快的进行。首先便是需要对目前的项目结构做分层设计,因为在实施组件化时,层的概念很重要。那什么是层?又如何分层呢? 首先我们来理解层的概念。以常见的MVC架构为例,一般都是Controller持有View和Model,然后Controller根据需求更新Model并将Model转为对应的View可用数据,通过View的数据源及代理方法刷新View。这种关系形如下图: 而项目中的文件结构大概如下: 当项目的功能模块累加到一定程度时,我们会发现MV...

阅读更多