移动端架构师都需要具备怎样的技术栈和能力

移动端架构师都需要具备怎样的技术栈和能力

主要的能力

技术深度

技术广度

动手能力: 比如说造轮子的能力, UI(高级自定义UI, 通用UI组件库), LibrarySDK(通用基础库, 项目框架/架构)

经验丰富

辅助的能力

领导力

沟通能力

洞察与前瞻

赋能业务

技术栈

T字形技术栈

语言

语言高级特性

多线程与并发

Andorid高级技术

网络

数据持久化

图片

路由与导航

架构技术

构建与打包

性能优化

扩展技术

开发工具

混合架构技术(动态化容器)

运维

三方技术

技术全栈

深度   广度

主要语言: java, Kotlin 辅助语言: javascript, TypeScript, Dart

泛型, 注解, 反射, 高阶函数, 闭包, 扩展, Lambda

线程/线程池, java.util.concurrent, kotlin协程

消息机制, 虚拟机原理, 类加载机制

HttpURLConnection, OkHttp, retrofit, RESTful, 网络调试与抓包

File&I/O, SharedPreferences, SQLite, ORM(Room等)

Bitmap, LruCache/三级缓存, Glide/Fresco

ARouter, Navigation component

Jetpack架构组件: Lifecycle,LiveData,ViewModel... 架构模式:MVC,MVP,MVVM 设计模式:单例模式,建造者模式,适配器模式.... 工程架构:模块化,组件化,插件化,容器化 IOC架构:Dagger2

Gradle:构建优化,插件开发,插件发布, APK打包原理 持续集成: Jenkins, GitLab Cl, Travis Cl, 一体化: 打包上传(私服/蒲公英) 机器人通知(钉钉) 安全与逆向: 混淆/加固, 逆向/反编译

启动速度优化,加载耗时优化,流畅度FPS优化,内存优化, 网络优化,包大小瘦身

Android X适配与升级,大厂多屏幕适配,Android Q黑暗模式,AppBunle,权限治理

主要:Android 辅助:webStorm,VScode,IDE 协作: 开发规约, Git 构建:Gradle,Maven,Jcenter 调试工具:开发支持工具,云真机平台 web Debugging:Charels,Fiddler,Wiresshark 扩展工具:Xmind,Axure,UML

Flutter, RN, 小程序, 快应用

监控(Crash监控):自建, Firebase,Bugly,友盟 日志系统:HiLog 热修复:Tinker,Robuse,Hotpatch

支付,埋点统计,推送,分享,扫码

后端技术:SpringBoot2,MuBatis,MySQL,Redis,Tomcat,Nginx 前端技术:javascript, TypeScript,react.js,less,AntDesign 小程序/快应用技术

如何从0开始架构一个中大型APP

需要考虑的事情

业务理解: 首先是业务理解，架构是服务于业务的，脱离业务谈架构，就是纯粹的耍流氓

赋能业务: 架构要能够赋能业务，比如业务是否有动态性的需求，以及灵活配置的一些需求，这些不能仅靠业务方来想，作为架构师要能够发掘业务潜在的一些诉求，从技术角度帮助业务更好更快的发展。有人会说，技术不能代替业务方。但技术能够帮助业方更好的去向前冲，如果说理解业务会让架构师走的快，那么赋能业务则会让架构师走的更久.

研发效率: 

• 多人多团队协作: 我们需要考虑架构之间的解偶/模块间相互独立/ 单独仓库/jar/arr依赖
• 复杂度控制: 复杂度控制在组件内部, 对外简单可以依赖
• 复用: 为矩阵产品输出轮子, 一个中大型公司, 他的产品不仅仅单单是一个APP,有可能是很多APP的一个矩阵, 那么我们做架构的时候在考虑加工每个组件或者某个框架的时候，我们要能考虑能够横向的为其他的一些矩阵的产品输出这些轮子,而不是只服务于我们当前的这个APP。
• 编译速度提升: 组件单独编译, Maven私服, 构建加速

技术选型:

• 开发语言: 反面案例是单JAVA或单kotlin的模式, 正面案例是使用kotlin和java的混合方式进行开发,因为有很多第三方库是使用Java开发的, 所以单独使用kotlin过于时髦
• 架构模式: 架构模式方面的反面案例是MVC, 这对一个单工程小应用来说还是可以的,对于较大的工程应用就需要在架构模式上应用我们的MVP或者mvvm来
• 工程架构: 工程架构方面的反面案例是单一工程, 会显得我们的项目特别的庞大, 难以维护,不利于多人协作, 这个时候我们就需要应用到我们的模块化/组件化/容器化
• 混合架构: 混合架构方面的反面案例是Native+H5, 因为H5的性能跟不上, 所以说我们只用native+H5的方式的话, 显然不是最优的一些方案, 好的方案推荐使用Native+Flutter/RN+H5,既能体现我们flutter rn的一个动态信号, 又能够兼顾native的相关的体验和性能
• 网络: 网络方面的反面案例是直接拿网络库(OkHttp/retrofit)来使用, 正面案例应该封装统一的网络层接口, 我们的业务层不直接依赖网络库, 而是依赖我们统一的网络接口,然后我们底层提供可插拔的一些设计,比如哪一天我们决定不用OKHttp了,我们要切成其他的一些网络库, 这个时候只需要我们网络层做一些相关的适配,我们的业务层不需要做任何的改动
• 数据持久化:数据持久化反面案例是SharedPreferences+SQLite, 正面案例是File+SharedPreferences+SQLite/Room 

数据层设计 

一款APP在动手写业务之前我们先要设计好它的数据层,因为市面上大部分APP无不需要和数据进行打交道,数据层设计的好坏,在整个APP的架构中起决定性的作用,为两个方面

网络层:RESTful风格,提供统一的API接口

本地数据:提供ORM数据操作框架,减少对SQLite的直接操作,提供统一的数据缓存框架

容灾能力

三个方面可以供我们做架构的时候进行参考, 分别是监控与预警, 动态发布,热修复

开发支持工具

开发规约: 代码规范, codeStyle, CodeReview

Debug Tool

自动构建与持续集成, 自动化构建和持续集成是提升延高效率的很重要的一个抓手

架构大图

底层基础库: 组件库, 工具库

业务层设计

工程结构设计

如何做好项目的技术选型

技术选型的方法论

技术判断: 要实现的目标/要解决什么问题—影响因素—识别风险/利弊—整体最优/次优

影响因素: 业务阶段—技术趋势—行业趋势—未来趋势—切换成本

理性决策: 自己想清楚,听多数人的意见和少数人商量,最后自己做决定, 做技术选型通常为公司为团队,做技术选型不能寻求自己爽,更要能够服众, 

仰望星空与脚踏实地

做技术选型, 架构师既要能仰望星空, 也要脚踏实地

仰望星空—技术与产业的发展, 技术成熟度,再看业务方向与技术选型，做到技术与业务的匹配和融合。

脚踏实地—业务与技术的匹配与融合,需要技术选型的落地技术，为业务服务, 我们要分清业务的重点，还有技术的重点。

业务重点与技术重点

技术选型首先要考虑的是业务是什么, 技术如何服务于业务, 赋能业务.

其实自己商业和业务的重点就是我们技术的重点，比如说对于一款视频类APP，那么它的解码推拉流弹幕。滤镜特效等这些不能完全依赖于外部,不然会被卡着脖子

然后是核心技术的一些自建，避免关键技术的一些依赖

跟风与寻找适合自己的

反面案例, 微软在用Xamarin, 我们也要用, 阿里巴巴搞中台,我们也要搞,盲目的跟风会发现在项目推进的过程中，这些项目技术并不适合自己,进而,反复的修改技术选型,造成了效率上的降低和资源的浪费。

为了避免这种情况的出现，正确的做法是将技术和我们的业务进行结合, 根据我们自己团队的一些实际情况来选择适合自己的才是最好的。

科学与大数据

使用科学的手段, 结合大数据进行技术选型

都有哪些科学的手段呢？首先是技术成熟度曲线(The Hype Cycle)

利用时间轴与市面上的可见度，也就是媒体曝光度上来决定要不要采用新技术的一种工具。

其次是Google趋势,通常我们了解和使用一个新技术，我们最先做的是搜索对我们搜索的这些数据都会被全球最大的搜索引擎哈谷歌收集起来，我们可以在谷歌趋势上使用这些数据。来分析和对比一些技术热度随时间的变化，以及其在不同国家和地区的一些热度。它能够精确到每一个城市对应某个技术的一些热度.

另外就是GitHub Start趋势, 一个开源软件的受欢迎程度,可以通过它的start show来很好的体现

技术选型取舍之道

选型的核心在于取舍, 取舍也是体现一个架构师技术视野和综合判断力的关键因素,它分以下几个部分:

投入成本上的取舍, 技术方面需要投入的时间成本和人力成本

技术特性取舍:, 技术选型+定制开发

技术管理的取舍, 在技术选型时,维护团队的稳定性,技术产品的稳定性等因素的重要性要远大于较低的迁移成本的重要性