什么是App云控?应该怎么做?

申悦
1557 阅读
3


前两天看到唐韧的一篇文章《不粘锅的产品经理,程序员最怕的主儿!》,提到老板发现客户端有个错字,因为是写死在代码里的,必须发版才能修改,就导致不升级的用户一直会看到这个bug。


结果产品总监把这个问题甩锅给技术,说是没做成后台文字可改,这让技术同学很不爽。


针对这个事,先站个队:甩锅是不对的,责任是团队的,文案也可以做成可配的。


但话分两头,这件事如果有后续,我能想到的一个可怕结果是:技术为避免背锅,会要求所有文案都可配!


我之前就见过类似需求,不仅要求所有文字可随时修改,还规定策略参数、界面样式,都后台可配!


可实际结果是,开发花了大力气,还做了个配置后台,但那些文案、参数,从来没人动过……


所以更好的做法是,从未来替换频率的角度提配置需求,如果可预期是常年不更新的文案,从实施成本考虑,开发完全有理由写死。


不过除了专门针对一个功能做配置项,还有没有一些方法,能尽量减少“发版后才能修改”的问题呢?这里就给大家简单聊聊一些我的思路。


方案1:页面前端化


这种做法比较常见,实施成本低,也好理解。就是当要开发一些可能会经常变更样式的页面,为避免频繁发版,就把整个页面用H5方式内嵌到App中。想修改时,调整前端代码后直接发布,页面就会实时更新。


页面前端化缺点也很明显:交互体验不如原生,首次加载有读取时间,存在机型适配问题。


方案2:页面模块化


所谓模块化,是在开始定义产品界面时,就把界面里的元素进行统一化、抽象化、通用化,使得我们能通过对模块的拼接,组合出一个产品页面。


以我在负责的360手机助手为例,因为要引导用户下载应用,背后就要准备几十款不同App展示样式的模块,如下图所示,就分横排、竖排、三图、大图这几种。


1602862488714443.png

当想在一个页面推荐几组应用时,我们只需在后台先建立一个页面,再在页面里创建一批不同样式的模块(样式相同也行,自由选择),每个模块选择一组App数据源即可。我们的后台界面如下:

1602862528132988.png

其中模块的名称,模块中每个元素的图片、数据、位置均可配。


这种方案的优点是灵活性强,只要把这套框架做出来,后面的工作就只是适配新模块,而原模块无论怎么修改都无需发版,还能基于不同样式组合做A/B测试。难点则是架构比较复杂,初期建设成本较高。


方案3:页面插件化


这是一种我来360之后了解到的一种客户端技术实现方案,简单来说就是做到页面级的热插拔更新。


以360手机助手为例,清理页、通知栏、桌面悬浮窗、App详情页、广告页等等,几乎每个页面都可作为一个插件单独更新、单独发版,而无需更新主包


每个插件发布时,还可根据版本号、机型、用户特征等标签灰度放量。


听说手机助手为写这套插件化架构,投入了很大精力,在业界也是小有名气。我觉得如果能开放出来,是对行业的一大贡献。至于具体怎么做到的我就不得而知了。


但方案3也存在缺点,就是首次启动时,需加载大量插件,会很耗流量和时间,所以我们特意做了丰富的启用引导,也是为了预留足够多时间。


上面三套方案,实施难度逐层增加,但对用户体验和需求变更响应速度则是越来越友好的,各位产品经理可以拿这篇文章和你们技术商量,看看是否能减少大家背锅的机会~


 公众号:互联网悦读笔记