完美架构设计编程数据库

Posted 2020-12-18 ibdjb

比如一个还处于很婴儿期的应用，这个时期的应用我们对它只有一个要求，只要它能尽快交付，尽快发布进的版本，开发足够敏捷就够，其他能力对我来说都是浮云。对于这样的应用完全不需要使用容器，就按照传统的App开发流程也挺好的，为什么还需要使用容器呢？但是我们可以提供给它一个完全难以抗拒的诱惑力就在于交付能力。我们可以实现动态部署，你要的交付能力不就是，你早上你诞生了一个想法，上午把它设计出来，下午把它开发好，晚上就能够把它发布到用户手里。这个是大家在做传统Web开发里面都梦寐以求的东西。所以，即使是一个初创阶段的应用，也是非常渴望拥有这样的能力，只要能够使用容器，并不需要把App进行拆分，然后放到一个Bundle里面，动态部署可以把你的Bundle完整的更新替换，有了随时到达用户手中的能力。

当你的应用，开始可能没有容器，但某一天，需要迁移到容重的时候，正因为我在对透明性上做了工作，我们并不需要对代码做实质上的改变，因为它对容器没有任何调用上的依赖。适应性在android上面能够更好的体现，因为三大总线都是基于OS封装，所以他的互操作性能够在最大限度上得到保证。

从巨型App时代的臃肿回归田园App时代的轻盈。

我们在开发时候，很多问题都是因为App越来越臃肿导致的。要回归田园App时代我们必须做到下面几点：

 

开发：像微型App一样便捷的开发调试（不依赖容器），只需要构建自己的Bundle。

这里写图片描述

上图中左侧是生产的包的打包模型，右侧是开发模式上的打包模型。开发模式中可以把其中的一些组件拿出来，包括它的UI, Service, Library打包成一个APK，比如一个商品的详情，开发的时候就可以直接把商品详情这个Bundle安装到手机里面运行它，然后就可以调试手机里面的所有流程，但是这时不可避免的还会涉及到和其他模块的协同，这个时候就需要跨Bundle的调试，但是不可能要把他们全部构建，这样就不能保证很好构建速度。可以在调试的时候使用持续构建环境，事先把别的Bundle打包。比如在详情模块需要调用交易，可以到持续构建环境中下载一个Bundle，它也是一个APK，然后都安装在手机里面。这样就可以互相调用了，调试也不需要编译其他Bundle，只需要编译调试自己的Bundle。但是这里还有一些细节的问题到目前为止还没有解决，比如，共享的一些权限，还有两个Bundle调用服务的时候，其中一个Bundle的服务并没有export，如果是两个App又如何调用呢？这里Android天然提供给我们一个机制—-ShareUserId，它可以使两个Bundle公用一个UserId，使他们可以像同一个应用一样的来工作。有了一个机制，Bundle之间可以共享很多东西，比如权限集合。这样就可以保证在开发环境下，能够尽可能的接近生产环境下的运行模型。

集成：极简的集成模型，AAR的构建产物AWB，这个每个Bundle交付出来的微缩版的APK，集成的时候只要把这个APK放到我们最终的安装包里面，直接运行了。并不需要在集成阶段做整个App的重新编译的工作。集成只是一个简单的合并包的过程，所以它非常快。

测试：之所以我们传统的迭代不能快起来，瓶颈就在于集成测试。如果能够把集成测试成本足够低，我们的迭代周期可以缩小的足够短。如果要两种发一个版本的话，要把集成测试的时间缩短在两周以内。我们是重Bundle测试，Bundle自己的测试要非常完备，才会进入到集成阶段，而在集成阶段只要做非常轻量级的测试。Bundle的测试是对应着Bundle的迭代开发周期的，不会阻塞整个发布的周期。使得发布的迭代周期可以缩短。

部署：借助于Bundle的自动化在线部署机制。实现开发完，测试完就直接到用户手中。