搞架构
文章平均质量分 80
为啥强制昵称
这个作者很懒,什么都没留下…
展开
-
大模型时代,还需要跨端framework吗?
在我近十年的大前端从业经验中,有一半是在和flutter/rn打交道。虽然,flutter和rn官方和社区已经在非常努力的优化、填坑了,但是这两者的坑还是远远高于原生开发。但是,在锁表的大周期下,华为带着鸿蒙来了,给水深火热的客户端开发带来了新的降温神器:乍一看,鸿蒙是带来了更多的开发需求。但时间拉长,在成本的驱使下,大量中小厂的客户端要不然更快的被完整放弃,要不然科技以套壳为本,客户端最终会落到更加边缘的窘境。当然,跨端很可能会是救客户端于水火的最后稻草,或者跨端真的还需要吗?原创 2024-07-13 17:06:53 · 813 阅读 · 0 评论 -
nextjs上的DDD架构
nextjs的同仓开发能带来非常好的领域/限界上下文代码共享能力。再利用好factory和typedef,可以以领域为维度组织起一整套不论是DDD还是ts视角都很合理的架构。原创 2024-03-09 22:47:49 · 1229 阅读 · 0 评论 -
面向LLM的App架构——技术维度
LLM对于开发来说,当前情况下最大的贡献点在于非代码部分和最细节的代码部分。为了适配LLM的能力水平,流程需要识别出适合LLM的点,并且规范化输入输出,尽可能交给LLM;代码需要极限的拆解,让每一块代码都更聚焦;人需要增强cr能力和表达能力,充分利用好工具;IDE需要更好的集成和基于prompt的协作支持。原创 2023-12-23 11:37:44 · 1745 阅读 · 0 评论 -
sonar与指标解读
ios/android/flutter sonar配置填坑原创 2022-11-16 10:20:11 · 1574 阅读 · 0 评论 -
怎么保证一个传承几十年的项目可维护
面试有人问这个问题,并没有很系统化的回答了,越来越发现是个有意思的问题,来整理一下。原创 2021-12-31 12:45:21 · 300 阅读 · 0 评论 -
跨语言通信——luascriptcore
luascriptcoreluascriptcore是一个用来绑定lua、java、oc的跨语言通信开源框架。被引入到了公司的项目中。方法定义和绑定lua call java注册使用的是带方法名的回调,即LuaContext#registerMethod(String, Callable)。LuaContext持有了Java侧的Callable通过LuaNativeUtil向LuaContext.cpp注册了该方法名和LuaJavaEnv#luaMethodHandler通过LuaSess原创 2021-08-14 12:10:28 · 214 阅读 · 0 评论 -
跨语言通信——起点
现代app一定会涉及到大量的跨语言通信。常见的包括JNI、js bridge等,不常见的有flutter channel、lua binding、python binding等。框架要素更泛化一些看,网络请求也是一种跨语言通信,gRPC可以作为一个中立的跨语言通信模板来拆解要素。通信主要是方法调用,方法调用可以分解成方法定义/绑定(gRPC部分)和参数传递(pb部分),做的好的体系会有签名校验,可能是运行时、编译时甚至生成(gRPC)。方法定义需要在两个语言定义出相同的方法签名,并且告知框架将二者绑原创 2021-08-14 10:55:50 · 223 阅读 · 0 评论 -
技术栈评价体系
现在越来越多的新技术栈出现,时不时要做调研,做评价,慢慢摸到了一些思路。维度常见的评价维度其实都集中在技术上,然而作为业务承载的根基,技术栈的评价维度完全不应该只有技术向评价,而且技术向评价根本不是重点。目前看,应该有三个方向:产品向、技术向和开发向。产品向产品同学通常对技术栈本身其实没有特别的要求,但是落到他们的利益上,技术栈需要满足快速迭代这个核心需求。快速迭代主要是,写得快、发版快。所以评价要关注:动态化,最高需求其实是动态化。就是发板快,细微的改动不需要跟随发板。这个对于强数据驱动公司原创 2020-07-29 16:16:47 · 380 阅读 · 0 评论 -
AOP Observable
在公司重构的过程中,希望用KVO的方式传递数据变化的事件。然而,在传统Android的写法中,Bean是没有setter的,就没有时机来notifyObservers了。 值得庆幸的是AspectJ能够切入Field access事件,用AOP就是一个非常好的解决方法了。项目](https://github.com/pouloghost/AOPObservable),使用方法见README.md,原创 2017-11-10 15:03:21 · 230 阅读 · 0 评论 -
[java-design-patterns]Enum和Factory模式的替换
设计模式合集git笔记系列。abstract factory模式的介绍中创建了KingdomFactory的接口分别实现了ElfKingdomFactory和OrcKingdomFactory为每个KingdomFactory声明了相应的enum声明了KingdomFactory的Factory,根据enum返回对应的KingdomFactory这个流程,诞生自Java还是弱原创 2018-01-10 11:01:43 · 447 阅读 · 0 评论 -
[源码]从CoordinatorLayout到集合中通信
CoordinatorLayout是个挺古老的东西了,然而我才听说,愧为程序员。看一下源码,缓解一下。 一个ViewGroup,也没啥设计思路可说的,无非是:使用Mediator模式解决了集合中子元素的随意通信问题(DependOn),用Decor模式解决了无谓继承的问题(代理给出了不少View的onXXX方法)。这种高层次的思路了。合理设计做依赖,一定都形成DAG,有一个Dire...原创 2018-02-24 19:11:06 · 202 阅读 · 0 评论 -
[造轮子]一个关于IOC初始化的失败脑洞
问题所有IOC系统,都不可避免的要进行实现的注册,包括很多初始化相关的事情。在Android上,随便一个多module的App,多多少少都有相同的问题。 Android冷启动App,IOC系统启动时,基本都要反射来突破Module间依赖的限制(如果这个能解决,也就不需要IOC了)。此时,性能一定会有一些问题,而且理解上不太容易描述清楚。解决方法提高性能的方法有不少种:每个M...原创 2018-02-13 18:28:38 · 300 阅读 · 0 评论 -
[脑洞]复杂页面构建方法
问题每个App都不可避免有一两个复杂的页面,首页啦、主要功能的detail页啦都跑不掉又臭又长。而当海外成为理所应当拓展的市场时,解耦复杂页面、在页面中按需加入功能就是一个刚需了。 具体来说,解耦有几个方面:接口/功能的解耦、View层面(特别是id)的解耦、生命周期传递。通用解决对于接口和功能,使用IOC或者Event方式。每个业务有自己的api module(声明接口和Ev...原创 2018-03-02 18:05:47 · 278 阅读 · 0 评论 -
我用过的代码生成方式综述
这段时间,做了很多开发效率相关的事情,涉及到了不少代码生成的方法和思路,总结如下。生成代码分两部分:代码分析生成工具和代码模板工具按编写难度排序live template这个是intellij的一个简单工具,看起来就是对freemarker或者正则替换做了一些封装。代表方案当然就是内置的那些了。 创建很简单:https://www.jetbrains.org/intellij...原创 2018-03-22 14:57:07 · 708 阅读 · 0 评论 -
[脑洞]使用annotation生成反射常量池
问题反射是每个Java开发都躲不开的工具,很多时候可以用反射把代码写的非常整洁,但会付出两个代价:性能问题反射用字面量和对应的类需要维护,容易出现bug前者是不可避免的,而后者可以通过apt来维护。以前都是用apt/javassist减少反射,后面做首个dex减肥发现,有的反射是必须的。突然发现,apt不仅能干掉反射,也能让反射更好维护。 因为所有需要被反射调用的类都不能被...原创 2018-05-07 16:13:14 · 441 阅读 · 0 评论 -
App 分层思考
为什么要分层主要是为了维持分工体系,提高生产效率。为什么分层能提高生产效率需要理解的范围从实现转向接口(面向接口编程),减少思考复杂性减少依赖,加速打包快速合理的下沉通用代码,减少重复开发建立起合理的边界,权责分明,减少撕逼常见层次业务层:通常是最上层,面向用户、面向产品开发的代码。如直播SDK 层:有一定的专职业务,向业务层提供能力封装。如 push工具库:非常通用的逻...原创 2019-01-30 14:07:57 · 485 阅读 · 0 评论 -
怎样初始化才好
问题每个 App 都会在启动时初始化一坨东西,这个点有两个问题:代码的依赖关系应该是有向无环图,但是初始化是线性的,所以相当于手动进行了一次拓扑排序,而且这个排序是写死的。这里把耦合以一种文档的形式写到了一起,一方面引发了维护文档的问题;另一方面导致所有人需要同时修改一个文件某些初始化本身是一个耗时的操作,启动初始化会严重拖慢 App 启动想法解决这些问题的核心点就是懒加载。让所有功...原创 2019-07-17 15:20:42 · 212 阅读 · 0 评论 -
跨Activity KVO问题思考
大部分展示类App都是Summary->Detail结构的,Detail中常常包含了对Model的修改。如何同步Model和View的状态是一个常见的问题。Android architecturegoogle官方的方案是ViewModel、LiveDataViewModel ViewModel是整个页面数据和逻辑的集合,比较像MVC中的C+M的绑定部分。数据同步靠两点:1.每次resume(或者其原创 2017-10-30 17:22:49 · 698 阅读 · 0 评论 -
[架构]复杂App MVC重构小结
在公司做MVP重构,公司蛮大的,App也蛮复杂(显示逻辑上,业务转移上基本是用户操作驱动,而非业务逻辑驱动),所以是个大MVP,三端都非常臃肿。自然会用拆分来解决问题,同时参照了谷歌官方的架构模型。ModelModel是数据层,该层是面向业务数据进行拆分的。安照SOLID思路,将Model拆成两层:业务Model,这些Model承载着部分数据,以及面向这些数据的原子逻辑。但是,当涉及到持久化(服务原创 2017-11-02 11:34:21 · 381 阅读 · 0 评论 -
GUI架构方法
某个大神写的UI设计模式的综述类文章,笔记如下:MVC分为两层Domain层和Presentation层,前者负责通用数据的CRUD和逻辑,后者负责展示。对象分为两类:域(Domain)数据对象和显示数据对象。域对象与显示完全无关。Model是内存的Bean不是SQL中的行。数据绑定时,没有全局控制器协调多个View,而是使用Observer模式,View直接在Model中监听变化,进而更新原创 2015-09-10 17:25:55 · 1283 阅读 · 0 评论 -
我理解的AOP
偶然看到这个名词,高大上的感觉,然后然后看了一下,感觉上没什么。目的很简单,有一些在整个系统流程中都需要使用的功能,而且这些功能跟业务逻辑没什么联系时,应该抽象出来。形成一个叫Aspect的独立功能模块,实现并在全过程中使用。看一个人的解释,看起来其实跟Obj-c里面KVO原理是一样的。就是动态生成当前类的子类,在子类中相应位置调用Aspect的函数。这样来讲,如果有个框架支持这个东西原创 2013-11-17 21:02:59 · 664 阅读 · 0 评论 -
GOF设计模式 读书总结
读完此书,寥寥几字总结一下各个模式。设计模式是高于算法、低于软件工程的抽象层次,主要是把常见的软件架构设计问题抽象统一出一些模式,保证最基本的软件设计要求:解耦、可扩展、可维护等。书中分为创建型、结构型和行为型。类和对象的使用范围无感。如图所示:0.创建型Factory类,将创建对象的工作从Client处统一到factory中,Abstract Factory是将不同系列但是相原创 2013-12-29 19:44:30 · 816 阅读 · 0 评论 -
解释器模式的一个应用
需求做产品的时候,有一个需求:对于一个字符串要在提交之前做校验,但是校验标准需要可配置。最合理的方案就是使用正则表达式+表达式组合。基础数据结构配置的数据结构如下package com.example.ayizty.myapplication.reg;import java.util.HashMap;public class Configure { public HashMap<String原创 2015-11-04 20:47:39 · 2257 阅读 · 0 评论 -
使用LocalBroadcast实现跨Activity的MVVM
问题工作中遇到了一个问题: 封装了一个Activity组,这组Activity执行了相类似的业务A,但是少部分文案、图片是有差别的,而且要求在这组Activity执行的过程中,后台运行的其他业务可以随时(或在业务A回调时)修改这些显示内容。 不优雅的方案有: - 回调中传递Activity的引用。这样限制了修改时机 - 在某单例中注册当前Activity,同时在Activity上暴露相应的修原创 2016-05-06 20:53:04 · 1574 阅读 · 0 评论 -
(自认为)账户业务最佳结构
源于最近各种改版,与PD一直撕逼,感觉对账户业务开悟了,梳理一下。基础思路抽象来说,账户业务就两个方面:账户详情:用户相关的所有信息。在客户端系统中,相当于维护了一个分布式(客户端、服务端)的数据存储,核心在同步策略权限管理:这个就复杂了,内容包括:权限存储:其实是用户详情的一部分,仍然是存储和同步为重点的功能,客户端要求有足够高的性能权限获取:这个其实是小系统上的主要业务,是与用户交互,验证原创 2016-11-29 17:46:09 · 334 阅读 · 0 评论 -
那些年我看到过的牛逼设计
React:重分抽象了展示的过程,展示就是把数据放到View上的过程,View变化一定是某个数据变化。所以这种变化可以以状态机的形式存在,所有影响View显示的数据作为一个状态。通过对于状态的kvo,可以实现更为高层次的数据绑定,并不是一个View对应一个String这么简单。其实data-binding都是一样的,但是抽象成状态机会非常容易理解。原创 2016-08-26 16:41:24 · 520 阅读 · 0 评论 -
Framework Design Guidelines笔记
Framework Design Guidelines是微软对于好api设计的一个指导,当然针对的是.NET,其中对于Android/Java有裨益的记录一下。命名大小写首字母大写:class、interface。对于IO这种缩写,所有字母都大写,例如IOStream驼峰:其他所有。对于缩写,保持大小写一致,例如ioStream,fileIOStreamxml中下划线:Android的xml里原创 2017-03-02 20:51:23 · 656 阅读 · 0 评论 -
[造轮子]一个脑洞大开的DataBinding Demo
之前看了一下RoboBinding的源码,还YY了一下不用Annotation的做法。自己蛋疼的做了一个极简的demo,顿觉纸上得来终觉浅,绝知此事要躬行。总起抽象来说,DataBinding和ButterKnife、ORMLite都是通过生成代码来减少垃圾代码量,让整体代码更加整洁。Java实现这个主要在两个阶段实现: - 运行时:Annotation+调用反射的代码(印象中ButterKnif原创 2017-03-29 10:21:06 · 410 阅读 · 0 评论 -
[造轮子]Android动态加载框架总结
用了一周多,做了一个Android动态加载的小玩具DCommand。支持下载APK,获取其中的资源、执行代码、启动Activity(这个是抄的,非常粗糙)。 最开始只是觉得动态加载逻辑代码很有用,如果MVP模式使用合理的话,对于大部分的逻辑更新、线上bug修复直接使用动态下发APK,更新P端的逻辑即可。后来越来越复杂,最后基本所有方面都可以动态使用,如果再深入开发的话,做个MVP框架也是可以的(当原创 2016-02-25 20:27:57 · 978 阅读 · 0 评论 -
[源码]RoboBinding及思考
RoboBinding是个有年头的MVVM框架,想看他源码好像也有段时间了,终于下定决心看一下了。看个大概主要是想了解一下作者的实现思路,鉴于代码实在是太松耦合、类实在太多,也没动力看细节了。思路表示,整个框架解耦太厉害了,出现了无数单实现的interface,也就是说,整个框架都是靠着interface联系在一起的。可能这类猿才会做出MVVM+自动化测试的框架吧。 编译时把Presentatio原创 2017-03-23 16:36:55 · 441 阅读 · 0 评论 -
[源码]ARouter
ARouter是大阿里开源的Android App“架构”类框架。最主要的就是解除依赖的,包括了页面的依赖、功能的依赖;还有hook、降级、绑定用的语法糖等。结构合理设计不想使用运行时反射,就在编译时,用Annotation把信息都生成到一个Config文件中。这其实类似于js的eval,是个很好的办法——RouterProcessor技巧原创 2017-03-16 17:44:46 · 508 阅读 · 0 评论 -
[源码]Android-Architecture及对MVP的理解
Android-Architecture是Google给出的MVP架构及其变种示例todo-mvp:原生态的MVP,其实就是说明了一下,在使用Fragment时MVP和Android组件是怎么对应的。 Model:纯Bean,既是View Model,又是Biz Model。Model不负责存取和转换逻辑View:对应着Fragment和Android View,主要负责事件到Presente原创 2017-02-06 15:46:21 · 296 阅读 · 0 评论 -
[源码]OKHttp及Http协议笔记
合理设计使用Builder把成员变量的setter从复杂的逻辑对象里剥离出来,让结构清晰一些,也做到了对象的immutable——OkHttpClient.Builder 但是,可能有个FieldWrapper更加方便:Buildee中需要Builder配置的所有Field都放到FieldWrapper中。Builder在构造函数中new一个FieldWrapper,在build时,把Field原创 2016-06-21 19:37:36 · 2625 阅读 · 0 评论 -
[源码]Gson
尽量泛化,记录一下Gson大大小小合理的设计和编码方式。合理设计原创 2016-04-21 20:41:01 · 796 阅读 · 0 评论 -
基于JS的AB测试方案
客户端的AB测试一直蛮恶心的,基本都是要预置代码、if-else入侵原有逻辑、发版前把所有测试方案都想好,新增只能发版。 当然,像RN这种究极方案解决一切由客户端逻辑不能修改带来的问题,还有一个更加简单的方法:基于JS引擎+JS下发的AB测试。要在APP中内置一个JS引擎,J2V8蛮不错的,还有一些其他。目前来看,都比较容易集成。定义一个interface作为为AB测试预留的坑。这个inter原创 2017-08-07 18:45:45 · 1347 阅读 · 0 评论 -
Bridge、Visitor、State和Strategy的理解
四个被称为很相似的设计模式,我觉得没必要很深究名字和定义直接的区别,理解内涵更必要。不过这四个被分为四个不同的设计模式,倒是让我不解了很久。特别是Visitor和Strategy。个人有一些理解:首先,Strategy是四个里面最为抽象和概括的,其他三个都可以视为Strategy在不同情况下的具体应用。Strategy主要目标是把算法(时序)作为一个对象(空间)存储下来。方便在不同情况下相互替原创 2013-12-26 21:19:52 · 1279 阅读 · 1 评论