android产品业务逻辑对app稳定影响太大

产品经理们，

看看你们的交互文档，

有n个逻辑分支，

在我们的实现中至少存在2*n个逻辑分支

这样极度造成了app的不稳定性，表现就是

非必须的bug很多。还有就是维护性极差

当然你们会说，你们可以写一些高内聚和少耦合的代码

来减少依赖。

我想说的是，我去，业务逻辑的代码，你搞这么多分支，

对应这么多业务情况，还要加上异常情况，完全没有

使代码高内聚。

客户端比较常用的模式MVC，MVVM，MVP

业务逻辑的复杂直接导致V,VM,P很复杂

甚至最后这3种模式发展成为四不像。

时间： 2024-07-29 21:06:28

android产品业务逻辑对app稳定影响太大的相关文章

[架构设计] 什么是业务逻辑

讨论设计时,专业词汇满天飞,每个人的技术背景.工作经验上的不同都会导致在理解上存在着差异.无论是SEI的定义.OMG UML的定义.还有各路大神的定义,都有从不同视角带来的差异.准备后面关注这些定义的差异,摊开来大家一起来讨论. 关于'业务逻辑', 国内国外争论了很多年了(这篇在07年就说没有清晰的定义),其中几个比较详细的讨论见附录(一定要看评论).我总结主要分为两类: 一类是逻辑处理论,一类是数据操作论. 逻辑处理论 先看前者,这一类观点,核心是强调逻辑.细说业务逻辑中,作者将业务逻辑分别做

android产品研发（十三）-->App轮训操作

转载请标明出处:一片枫叶的专栏 上一篇文章中我们讲解了android app实现长连接的几种方式,各自的优缺点以及具体的实现,一般而言使用第三方的推送服务已经可以满足了基本的业务需求,当然了若是对技术有追求的可以通过NIO或者是MINA实现自身的长连接服务,但是自己实现的长连接服务一来比较复杂耗时比较多,而且可能过程中有许多坑要填,一般而言推荐使用第三方的推送服务,稳定简单,具体管理长连接部分的模块可参考:android产品研发(十二)–>App长连接实现. 而本文将讲解app端的轮训请求服务,

android产品研发（十二）-->App长连接实现

转载请标明出处:一片枫叶的专栏 上一篇文章中我们讲解了android应用内页面跳转协议-scheme协议,通过该协议我们可以跳转至指定的Activity,并在该Activity中解析scheme用于跳转到指定的页面,我们可以利用scheme协议实现应用内页面跳转.H5页面与Native页面相互跳转.通知栏消息跳转相应页面等,具体可参考:android产品研发(十一)–>使用scheme实现页面跳转. 而本文中我们将讲解一下App的长连接实现.一般而言长连接已经是App的标配了,推送功能的实现基础

android产品研发（十四）-->App升级与更新

转载请标明出处:一片枫叶的专栏 上一篇文章中我们讲解了android app中的轮训操作,讲解的内容主要包括:我们在App中使用轮训操作的情景,作用以及实现方式等.一般而言我们使用轮训操作都是通过定时任务的形式请求服务器并更新用户界面,轮训操作都有一定的使用生命周期,即在一定的页面中启动轮操作,然后在特定的情况下关闭轮训操作,这点需要我们尤为注意,我们还介绍了使用Timer和Handler实现轮训操作的实例,更多关于App中轮训操作的信息,可参考我的:android产品研发(十三)–>App轮训

android产品研发（八）-->App数据统计

转载请标明出处:一片枫叶的专栏 上一篇文章中我们介绍了android社区中比较火的热修复功能,并介绍了目前的几个比较流行的热修复框架,以及各自的优缺点,同时也介绍了一下自身项目中对热修复功能的实践.目前主流的热修复原理上其实分为两种,一种是通过利用dex的加载顺序实现热修复功能,一种是通过native层实现指针替换实现热修复功能,两种各有利弊可以根据自身产品的需要选择不同的方案. 而文本将要介绍一下android产品中另一项基础功能-数据统计.App数据统计的意义在于通过统计用户的行为方式有针对

android产品研发（九）-->App网络传输协议

转载请标明出处:一片枫叶的专栏 上一篇文章中我们讲解了App的数据统计,其主要分为两种:使用第三方服务统计和自身实现数据统计.一般而言我们使用第三方统计服务已经可以很好的满足我们的也无需求了,只是部分数据敏感性App,可能自身实现数据统计服务是一个更好的选择. 而本文中将要介绍的是App端的网络传输协议.那么这里首先需要明确一点的是什么是网络传输协议呢?这里首先套用一段百度百科的定义: 网络传输协议或简称为传送协议(Communications Protocol[1] ),是指计算机通信的共同语

android产品研发（二十一）-->UI优化

转载请标明出处:一片枫叶的专栏 上一篇文章中我们讲解了android产品研发过程中的代码Review.通过代码Review能够提高产品质量,增强团队成员之间的沟通,提高开发效率,所以良好的产品开发迭代过程中,代码Review是一个必不可少的步骤.那么如何进行代码Review呢?我们主要讲解了团队成员之间的代码Review,代码lint检查,开发规范等方面的知识点,更多关于代码Review相关的知识可参考我的:android产品研发(二十)–>代码Review 本文我们将讲解一下android U

android产品研发（七）-->Apk热修复

转载请标明出处:一片枫叶的专栏 去年一整年android社区中刮过了一阵热修复的风,各大厂商,逼格大牛纷纷开源了热修复框架,恩,产品过程中怎么可能没有bug呢?重新打包上线?成本太高用户体验也不好,咋办?上热修复呗. 好吧,既然要开始上热修复的功能,那么就得调研一下热修复的原理.下面我将分别讲述一下热修复的原理,各大热修复框架的比较,以及自身产品中热修复功能的实践. 热修复的原理 通过更改dex加载顺序实现热修复 最新github上开源了很多热补丁动态修复框架,大致有: HotFix      

android产品研发（六）-->Apk混淆

前面一篇文章中我们讲解了android里面的多渠道打包,对于大型的app来说,几百个上千个渠道包都是很正常的事,所以效率定制化是一件很重要的事.主要讲解了三种多渠道打包方式,并分析了其各自的利弊,在各自产品多渠道打包的时候,可以根据自身的产品需求选择相应的打包方式. 而本文主要讲解Apk的混淆,这里的混淆分为两种代码混淆和资源文件混淆.实际的产品研发中为了防止自己的劳动成果被别人窃取,混淆代码能有效防止apk文件被反编译,进而查看源代码.说来惭愧,作为互联网创业公司的我们也确实对竞品Apk反编译