Android移动应用架构设计.docx
- 文档编号:29662945
- 上传时间:2023-07-26
- 格式:DOCX
- 页数:12
- 大小:1,010.14KB
Android移动应用架构设计.docx
《Android移动应用架构设计.docx》由会员分享,可在线阅读,更多相关《Android移动应用架构设计.docx(12页珍藏版)》请在冰豆网上搜索。
Android移动应用架构设计
Android移动应用架构设计
随着新技术的引入,及编写原生Android代码的技能不断提升,我们开始思索如何去解锁移动应用新架构,也就是Growth5.0。
我们尝试使用了Kotlin+ReactNative+Dore+WebView搭建了一个简单的Android移动应用模板。
为了尝试解决Growth3.0+出现的一系列问题:
启动速度慢、架构复杂等等的问题。
作为Architecture练习计划的一部分,我们将采用规范一些的叙述方式来展开。
1.业务架构
2.技术远景
3.方案对比
4.架构设计方案
5.持续集成设计
6.测试策略
7.架构实施
即下图:
技术架构设计之路
业务架构
技术是为了解决业务的问题而产生的。
脱离了业务,技术就没有了存在的前提。
脱离了业务的架构不叫“架构”,而叫刷流氓,又或者是画大饼。
业务由于其本身拥有其特定的技术场景,往往是对技术决策影响最大的部分。
因此,开始之前让我们先了解一些业务,这里以Growth为例。
Growth的价值定位是:
带你成为顶尖开发者。
复杂一点的说明就是:
Growth 提供 编程学习服务 使用 Web开发路线 帮助 新手Web程序员 解决 Web学习路径问题。
让我们来看一下,更复杂一些的说明(电梯演讲):
对于
缺少Web体系经验的程序员
他们有
书籍、在线教程、论坛、技术问答、练习项目
我们的产品
编程学习软件Growth
是一个
移动应用
它可以
涵盖Web开发的流程及技术栈,Web开发的学习路线、成长衡量等各方面。
但他不同于
segmentfault、知乎
它的优势是
拥有完整的Web开发流程(知识图谱)、配套完整的电子书、提供练习及学习工具。
在原有的业务架构下,我们拥有Growth、探索、社区、练习四个核心业务,以及用户中心的功能。
oGrowth(首页),即带有详细介绍的Web应用的生命周期,能帮助开发者理解Web应用的构建流程。
o探索,以辅助开发者了解Web应用方方面面的知识,如常用工具、练手项目、技能测验、读书路线等等。
o练习,通过这些练习项目,来帮助开发者更好的掌握知识。
o社区,一个简易的论坛。
o用户中心,一些用户的收藏数据、应用相关的设置等等。
这就是业务上的主要架构,接下来让我们看看技术上的事务。
技术远景
远景,即想象中未来的远大景象。
技术远景,即想象中未来的技术方面的远大景象。
在上一节中,我们介绍的是项目的业务远景。
而作为一个技术人员,在一个项目里,我们也已经创建自己的技术远景。
一来,我们可以创建出可持续演进的架构;二来,可以满足个人的技能需求。
以Growth为例,我的最基本的技术需求是:
提升自身的能力。
然后才是一个跨平台的技术设施——减少构建时间。
从Growth1.0、Growth2.0采用的Ionic,到Growth3.0采用的ReactNative,它都优先采用新的技术来帮助自己成长,并使用了跨平台的移动应用开发框架。
而这几个不同的版本里,也拥有其对应的不同技术问题
oGrowth1.0主要是Angular1.x的跳崖式升级,使之变成不可维护的系统。
oGrowth2.0则是Angular2.x那庞大的构建体积,带来了启动时间慢的问题。
oGrowth3.0则是,ReactNative生成的 index.android.bundle 文件有3.1M,这个体积相当的大,以至于即使在高通的骁龙835处理器上,也需要4~5秒的打开时间。
而在Growth5.0的设计构架里,考虑到ReactNative本身的不加密,其对于应用来说,存在一些安全的风险。
我决定引入Native的计划,来从架构上说明,这个系统在某种程度上也是可以加密的。
因此,对于我而言,从技术上的期望就是:
o使用新技术带来成长
o让应用长期可维护
o拥有跨平台的基础设施
o插件化方案
方案对比
对于普通的应用来说,其需要从不同的方案中选择一个合适的方案。
其选择的核心,取决于项目所依赖的关键点。
如在Growth有两个关键点:
代码复用程度、应用性能。
这个时候就需要罗列出不同系统的优缺点,并从中选择合适自己的一部分。
如下数据(纯属个人使用体验总结,没有任何的数据基础):
原生
ReactNative
NativeScript
混合应用
开发效率
2
4
3
5
跨平台程度
0
3
3
4
性能
5
4
4
2
成熟度
5
4
3
5
安全性
5
3
4
2
总计
17
18
17
18
PS:
NativeScript在安全性上比ReactNative好一点点的原因是,使用NativeScript的人相对少一点,所以技术成本就高一些。
毕竟,macOS和Android手机上也是有病毒的。
考虑到我打算结合不同的几个框架,所以这里就不需要选择了。
技术方案
在定下了基本的技术方案后,就差不多是时候进行架构设计了。
现今的很多应用里,也是采用多种技术栈结合的架构,如淘宝的Android原生+Weex+WebView,或者支付宝(不确定有没有Weex)。
但是,可以肯定的是几乎每个大型应用,都会在应用里嵌入WebView。
WebView毕竟是可以轻松地进行远程动态更新,也需要原生代码那样的后台更新策略。
在Growth3.0里,我们选择了使用ReactNative+WebView的构建方式,其原因主要是WebView的生态圈比较成熟,有相当多的功能已经用WebView实现了。
而在新版本的设计中,则系统变得稍微复杂一些:
架构图2
从设计上来说,它拥有更好的扩展性,毕竟在安全上也更容易操作。
然而,从技术栈上来说,它变得更加复杂。
Growth技术方案
原生部分
系统在底层将采用原生的代码作为基础框架,而不再是ReactNative作为基础。
再考虑到项目上正在实施的Android插件化方案,我打算在Android的Native部分使用RePlugin来引入一些更灵活的地特性。
因此,从架构上来说,能满足个人的成长需求了。
毕竟原生Android有些架构还是相当有意思的:
原生Android架构
ReactNative
ReactNative从代码上的变化比较大,架构设计上从代码上切分出几个不同的页面。
它可能可以在某种程度上Bundle文件过大,带来的加载速度慢的问题。
因而,在某种程度上,可能带来更快的启动速度。
WebView
总体上来说,WebView变化不会太大。
除了,可能从ReactNative的WebView迁移到原生部分的WebView之外。
持续集成设计
之前我们提到持续集成的时候,多数是指持续集成的实施。
而今天我们谈到持续集成的时候,则是在讨论如何去设计。
代码策略
首先,就是代码策略,即代码管理策略。
代码管理,指的就是决定采用哪种git工作流。
会影响到代码管理的因素有:
o上线功能。
如某次发布要上线哪些功能,肯定会影响到正常的开发流程。
o代码集成。
当我们采用模块化、插件化来设计系统架构时,就需要将几个不同的的项目集成到一起。
o代码合并。
在有的项目里,人们会使用PR来提交代码,有的则是直接在master上提交,也有的采用featurebranch。
o分支策略。
什么时候,决定拉出新的分支?
o修复bug。
当我们拉到一条新的分支时,我们要怎么去应对一个bug的出现呢?
对于Growth而言,则仍然是master分支,采用多个GitHub项目的集成方式。
工具箱
作为一个有经验的程序员,我们应该在设计的初期考虑到我们所需要的工具:
o基础设施,诸如ReactNative需要的Node.js、Android及Java需要的构建工具Gradle
o文档工具,诸如架构决策记录工具ADR,
o开发工具,编写Android应用需要的AndroidStudio、编写ReactNative的IntellijIDEA
o依赖库,这些工具是我们
o持续集成,在持续集成上可以采用TravisCI
o应用发布,APP仍然使用GitHub和来进行测试版发布。
至于后台API,是否从GitHub、Coding上迁出,仍然有待商榷。
这些也仍是我们在设计架构的过程中,需要考虑的一些因素。
测试策略
一般情况下,我们要会采用测试金字塔:
测试金字塔
在这里,引用《全栈应用开发:
精益实践》对于测试金字塔的分析:
从图中我们可以发现:
单元测试应该要是最多的,也是最底层的。
其次才是服务测试,最后才是UI测试。
大量的单元测试可以保证我们的基础函数是正常、正确工作的。
而服务测试则是一门很有学问的测试,不仅仅只在测试我们自己提供的服务,也会测试我们依赖第三方提供的服务。
在测试第三方提供的服务时,这就会变成一件有意思的事了。
除此还有对功能和UI的测试,写这些测试可以减轻测试人员的工作量——毕竟这些工作量转向了开发人员来完成。
而如果是架构混搭的应用来说,其的测试成本相当的大。
因为要测试的部分是3+1,即:
o原生部分,采用原先代码的测试策略,如JUnit
oReactNative部分,继续之前的 react-test-renderer 测试渲染、 jest 和 chai 测试业务逻辑
oWebView部分,采用框架本身推荐的框架
o组合部分,对于这部分来说,UI上的测试会更加可靠,如在Growth3.0中采用的 appium 就是一个不错的选择。
架构实施
最后,让我们来看看我在两个星期前,搭的一个架子,用于作技术验证功能。
一共由三部分组件:
o使用Kotlin编写的原生代码
o使用ReactNative编写的Fragment
o使用Ionic编写的WebView应用
接下来看两个简单的代码示例:
创建ReactNative的Fragement
如下是一个使用ReactNative编写的Fragement示例,它可以直接在原生的Activity上使用:
1.classArcheReactFragment:
ReactFragment(){
2. overridevalmainComponentName:
String
3. get()="RNArche"
4.
5. privatevarmReactRootView:
ReactRootView?
=null
6. privatevarmReactInstanceManager:
ReactInstanceManager?
=null
7.
8. @Nullable
9. overridefunonCreateView(inflater:
LayoutInflater?
group:
ViewGroup?
savedInstanceState:
Bundle?
):
ReactRootView?
{
10. mReactRootView=ReactRootView(activity)
11. mReactInstanceManager=ReactInstanceManager.builder()
12. .setApplication(activity.application)
13. .setBundleAssetName("index.android.bundle")
14. .setJSMainModulePath("index")
15. .addPackage(MainReactPackage())
16. .setUseDeveloperSupport(BuildConfig.DEBUG)
17. .setInitialLifecycleState(LifecycleState.RESUMED)
18. .build()
19. mReactRootView!
!
.startReactApplication(mReactInstanceManager,"RNArche",null)
20. returnmReactRootView
21. }
22.}
除了将ReactNative切分成不同的几个子模块。
对于一个ReactNative应用来说,它可以注册多个Component
1.AppRegistry.registerComponent('RNArche',()=>App);
2.AppRegistry.registerComponent('RNArche2',()=>App2);
这样一来说,可以在一个ReactNative应用里被原生部分多次调用不同的组件。
简单的WebView
对于那些不需要原生组件的组件来说,可以直接由原生应用来对WebView处理。
从逻辑上来说,这样的性能会更好一些:
1.@SuppressLint("SetJavaScriptEnabled")
2.@Nullable
3.overridefunonCreateView(inflater:
LayoutInflater?
container:
ViewGroup?
savedInstanceState:
Bundle?
):
View?
{
4. valview=inflater?
.inflate(R.layout.fragment_webview,container,false)
5. mWebView=view?
.findViewById(R.id.webview)
6.
7. mWebView!
!
.loadUrl("file:
///android_asset/www/index.html")
8.
9. valwebSettings=mWebView!
!
.settings
10. webSettings.javaScriptEnabled=true
11. mWebView!
!
.webViewClient=WebViewClient()
12.
13. returnview
14.}
对,就是这么简单。
结论
请尝试做这样的架构设计:
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Android 移动 应用 架构 设计