技术护航产品出海-阿里云开发者社区

开发者社区> 开发与运维> 正文
登录阅读全文

技术护航产品出海

简介: 2017杭州云栖大会移动技术实践专场上,来自UC国际业务部资深专家何杰带来UC国际业务线工作方面的分享。本文主要介绍了产品出海面临的一些问题和挑战,首先介绍了UC的国际化历程,进而阐述了移动互联网的国家市场分析,重点分享了本土化打法和性能优化和远程用户体验及质量保障手段,最后作了简要总结。
2017杭州云栖大会移动技术实践专场上,来自UC国际业务部资深专家何杰带来UC国际业务线工作方面的分享。本文主要介绍了产品出海面临的一些问题和挑战,首先介绍了UC的国际化历程,进而阐述了移动互联网的国家市场分析,重点分享了本土化打法和性能优化和远程用户体验及质量保障手段,最后作了简要总结。

 

以下是精彩视频内容整理:

 

UC的国际化历程

32215ae7e32be3a711af7d47efa8eada53217e3b

UC国际产品包括内容分发平台、安卓应用分发平台与流量交易和变现平台,UC的出海历程如下:

第一个阶段。2014年以前,我们有一个好的产品,在寻找什么样的市场能够和我们有切合,所以我们决定出海。这个阶段我们叫做“空军打法”,我们认为做国际化有三种打法:空军、海军、陆军。空军是当地没有研发团队,也没有自己的办公室,我们要找到自己的产品切合哪个国家,满足这些国家用户特点,通过兼容性、国际性适配工作让产品迅速扩散。

第二个阶段。2014年开始,中国厂商已经出海了,中国产品可以伴随中国厂商一起出海,就是所谓海军打法。

第三个阶段。我们要设立办公室,要有当地运营人员,甚至要有当地的研发、质量保障人员做一些深度工作,涉及到内容、文化等等。

 

移动互联网的国家市场分析

0adb16b3e0d8e8e89041fa49945b974ef87ceb69

如果我们的产品要出海,在国家市场选择上应该是什么样的?这是一张世界地图,做国际化首先要想到的就是做英文版本,但是实际上做国际化一定不是英文版,世界上有200多个国家,不可能靠一种语言覆盖到所有国家,也不是200多个国家都各出一个版本,整个国际有很多区域,区域可以按照人口、文化、经济发展的程度来分。以美国为代表的发达国家人口非常多,经济基础设施非常好,如果以商业变现为目的的产品可以适合在这种国家落地。而像非洲这样的国家,移动互联网基础设施不完备,过几年再考虑。像韩日国家条件比较好,但是相对封闭,在本身工具、内容并不匮乏的情况下,这里需要一些创新的做法才可以。UC重点布局的国家包含印度、印尼、俄罗斯以及他们所辐射的周边国家,印尼辐射东南亚、俄罗斯影响东欧国家,欧洲有很多小国,单个国家人口不是非常大,互联网是非常讲究边际成本的,一个国家如果只有几百万人口,我们在其中占20%渗透率非常小。

3ae4d9cb620d05423e625f6cd89815a0813da18e

全世界人口从高往低排如图,我们已经囊括大部分国家。美国为什么没有去?移动互联网最发达的两个国家一是中国,一是美国,但是中国人的碎片时间比较多,而美国人都开车,零碎消费时间不是特别多,意味着对于互联网产品需求有很大差异。我们倾向于工具型产品可以向相对经济落后、但有人口优势和成长潜力的地方。

 

产品技术挑战

0f8303193fac9430ccbf23c3ce358d3efb609f35

国内和国际相比,主要的挑战来源于几个方面,包括设备、网络、语言、文化、政策以及当地的技术环境。

  • 设备:1G内存以下占比高达30%,在国际2G成为标配的情况下已经有非常大的差异,这对内存优化和崩溃、使用卡顿率等等影响都是非常大的。ROM空间小于1G占40%,意味着国内APP动辄四五十兆,解压出100多兆,一台手机只能装10个APP,所以ROM空间优化非常大,UC浏览器有20兆大包和2兆小包,这非常影响APP是否到达用户。CPU双核占比高,低端机问题在国内显现不出来,但是后续影响非常大。分辨率480P占比50%,这是中国四五年前的水平。
  • 网络:3D网络占比非常高,以印度为例,印度去年10月份2G网络渗透率高达60%,所以弱网络、低速网络方面有非常多的问题。我们做国际化不光是做一个国家,可能是很多国家,服务器可能部署在国外,同一套部署可能部署在美国、新加坡等有运维辐射能力的地区,所以跨国网络延迟也是需要考虑的。去年印度最大运营商开始推免费4G和资费优惠,4G比例上升非常高,但是网络状况不是特别理想,这需要一个发展的过程,网络状态在国内很自然认为信号有就是在线,没有信号就是不在线,其实有很多假在线的情况,也是需要相应的监测机制。运营商在印度有50多家,在印尼有20多家,如果业务有跨运营商的情况出现,这里网络情况也是非常不理想的。如果想要某个功能去测在每个运营商下面的表现,投入也很大,不一定可以买得到对应的卡。
  • 语言:UC浏览器支持10多种语言,在中国支持中文就可以,而印度虽然英语为官方语言,但是最大的用户群是印度语,反而英语的比例非常低,对应的消费数据不是特别好,因此,我们也需要做一些小语种处理和多语言切换。
  • 文化:我们看到非常多的不一样,比如节日。我们也要了解国外的文化以及做对应的运营活动。不同国家喜欢的颜色也不一样,我们的APP主色调在印度是大红色,在印尼是绿色。
  • 政策:信息不通导致我们对海外市场不是特别了解,比如说俄罗斯要求所有数据必须在国内,印尼要求做任何业务服务器必须在当地,服务器部署出口价格又不一样,以印尼为例,如果服务器在印尼国内,访问站点是国外,出口成本非常高,所以选择服务器在国内还是国外成本也是我们考虑的因素。
  • 生态环境:在发行方面,国内各种各样的应用商店,包括APP自己的更新都不是非常受限制,在国内通常用到的各种动态化、灵活性的方案国外会受到很大的限制,支付、发行基础设施不是非常完善。

在UC中我们有三个阶段:

1.         空军阶段,需要已有的产品找到在哪些国家有用户痛点,比如UC浏览器过去主要口碑是省流、打开网页快。印度人民访问Facebook,可能一个大页面所有的数据拉下来从用户点击到展现需要10~20秒,我们通过转码和各种各样的流量节省以及路由选择,访问时间能够提升三四秒,而且排版样式更加符合手机适用屏幕排版,在线播放非常少,用户下载数非常强,我们从网页转码和下载处的优化完全切合市场发展,找到了用户以后,通过口碑传播以及渠道打法,这种工具属性产品很容易在用户里产生很好的口碑。

2.         本土化打法。用户喜欢什么需要建立当地的运营团队以及技术团队,要考虑技术对灵活性的支撑。

3.         深度本土化。中国内容生态已经非常复杂了,过去有论坛、BBS等非常多的内容制造者,而在今天网络已经越来越好的情况下,行业内容估计量是不足的,我们产品要考虑怎样催化当地生态变化,让用户有更丰富的内容消费升级。

性能优化

低端机

低端机方面的优化如下:

第一,CPU和磁盘读写都是非常大的瓶颈,主要启动把复杂的任务做原子化,有变形处理框架,让整个东西并发,低端机和高端机分化非常严重,把低端机做优化的同时要考虑对高端机的影响,比如说启动速度过去平均值是2秒钟,现在优化到1秒钟认为很好了,其实细分来看,低端机3秒钟到2秒钟,高端机500毫秒到600毫秒,所以我们优化要做的更细致。

第二,卡顿。很多机器都是四五百块钱,对性能、监控力度要求非常大,我们要知道到底有哪些卡顿的点,通过聚合分析找到里面的问题再解决。我们尝试把500个ANR变成500毫秒的ANR,这样可以更好的发现用户出现的问题并且做优化。

第三,闪存。平均存储40%-50%不到1G,我们常规会做各种各样的图片压缩,还会把第三方SDK做很多精简,把国际上的Facebook核心协议抽取出来。也可以考虑mini开发,我们有大包、中包,也会有更小的包,这里也是可以有分包的策略。

第四,分辨率。分辨率分化非常严重,我们也会考虑用压缩机的方式做支持,在整个方案的基础上可以得到高清效果,也能够极大地节省包体积,一个三四兆左右的产品资源有1兆左右,可以减到300G左右的体积,对启动内存节省非常大。

第五,内存会处理各种稳定性兼容问题,虚拟内存限制还好,但是物理内存不太好做突破。比如剩余内存一共50兆,这个时候虚拟机再高还是会出现崩溃,对此,我们实现一套方案,比如图片创建正常都是JAVA分配,我们有相应的方法在Native空间上做分配,这样让OAM的爆发比例极大缩小,在平常开发环境中,我们会把转化关掉,让问题更好的暴露,及时的做处理。突破MAXHeap限制,Class按需加载。

低速网络

2013年以前,我们不知道只要把重复次数调多、超时时间减少,联网成功率可以提升10几个百分点,因为网络是通的,可能网络波动非常厉害,主要是稳定性不好,这时策略调整非常关键,包括预连接、连接保持、HTTPDNS都需要我们有更好的发现机制,针对性做对应的处理。

本土化打法

本土化打法和国内很多技术非常相像,性能优化我们遇到的环境更加苛刻,我们需要把环境做的更加深入,差异化的打法对于运营灵活性要求特别高,配置的复杂度比国内要大,因为我们面向很多国家、很多语言、很多地区,需要有复杂的精准配置下发方法,有定向灰度和ABtest的能力,有GCM和自身的双通道支持,有推拉结合的模型等等。

端的动态化能力也是需要我们重点构建的,包括语言管理、小语种支持、根据国家文化节日的动态风格调整、用户体验匹配等方面需要有逻辑的配置支撑灵活性。

过去很多国外产品进入中国最后没有拿下来,除了政策因素之外,很重要的在于可能做了部分本土化,但是不够充分,因为没有考虑中国人需要什么。我们认为国际化第三个阶段是帮助当地产生一些不一样的价值,这是深度的本土化。接下来网络升级以后会有更多的图文消费场景,可能需要视频消费场景,我们需要做很多引领生态的事情,比如关于内容创作的部分,我们要想办法告诉、引导他们,通过各种各样的方式怎样写好文章,用户需要什么样的文章,怎样把好的内容和对应的人建立关联,这就是深度运营的考虑。关于模块化,不同国家有很多新的尝试会复用;关于容器化,UC会用阿里集团的Weex方案,也有UC自己的WEB APP方案;关于互动玩法,用户不是简简单单满足看一个网页,怎样做评估、怎样做评论回复提醒、怎样有趣的让用户内容消费。

 

远程用户体验及质量保障手段

4eddcd36f81c0629c6756f9b780ed81c8f4f49f1

这是正常APP应该有的质量保证流程,从需求阶段到最后发布阶段,包括整个闭环部分、持续集成环节。事实上所有国内产品要做的事情我们都要做,我们特别强调灰度环节、发布环节、现象监控环节、实验室的环境,UC在国内有一个内部适用版本,实验室版本会推给平常工作的同学,他们发现问题会把信息上报,但是国外可能做不到,如果我们有海外站点,希望把这一块利用起来。

a96ec6f5540c2dbf1b87c8c9224d948b74913644

第一,基于本地化实验室的服务能力。一是本土硬件资源提供能力,能够有本地的硬件资源支持,可以做本地问题的副线,有特定机型网络诊断;二是能够提供自动化测试支撑能力;三是真机平台远程能力。

第二,精准、灵活、高效的灰度能力。升级是非常重要的环节,过去为了提高升级转化率会做包体机优化,为了提高升级覆盖率会做定量升级等等,在国际上会有什么困难?一是定向发布是有难度的,因为GP只能上传一个包,所以要有定向发布的能力,UC有应用商店,我们可以通过这种方式做;二是控量发布,无论是灰度还是正式发布都有好几个阶段,可能发5000个用户看一下各种数据变化,发2万再看一下,发100万再看一下,包括稳定性监控、启动速度监控、舆情系统监控等等会自动化关联,控量发布是控量+自动化的体系;三是并行灰度,GP审核周期非常长,最长可以到一周多,当你的产品在多个国家,甚至一个国家做不同实验,并行灰度能力也是我们要具备的。

第三,基于用户信息的关键字告警能力。用户到底遇到了什么问题,我们要有自己的自有反馈平台,国际上要针对对应的社媒传播渠道进行全网监控,为了让跟进效率更高会基于一些关键字做一些告警。

第四,结合算法的质量数据分析能力。我们要把很多因素考虑进去,将机型、国家等等20个左右维度做机器学习的训练,也会一层一层做问题分析。我们会把原始数据按照小时做迭代,通过算法拿出变化趋势、周期性,并且从中提取变化因子,我们可以按照当前设备分布特点,一个技术指标波峰、波谷是多少,有一个正常的数据分为,可以算出问题可能性的百分比,再进行下一轮运算,直到最终找到问题,这实际上极大的提高了效率。

 

渠道推广技术及挑战

国际环境主要渠道有三类:一是类似于Facebook、Google,单价非常高、用户质量非常好;二是网盟,质量不一定好,但是单价非常优惠;三是预装单价比较低,但是周期很长。

我们覆盖了20多个渠道,150多个国家,我们从效率和质量两个层面做监控。提升推广效率,需要建机器化运营系统,再找出同样的推广价值,到底谁更划算?投放需要更加基准,A物料和B物料谁更好,会有很多测试工作,让花费更加有效;渠道质量管控包括假的APP、模拟器、人肉刷APP激活、设备牧场等等一系列东西,关于假量和抢量识别非常重要,我们自己建立一个火眼系统,可以针对全网推广做监控,从中做很多级回溯,可以知道是否是恶意推广。

 

总结

我们能够解决当地实际问题,很多做法都是降维做的,此外,发现问题能力也是非常重要的。

感知增强,阿里特别倚重数据仓库和数据仓库之上做的数据实时分析,会让整个数据分析更加简单;Global,要有Globel视野和Local的价值;消费升级,印度4G网络覆盖率非常高,意味着从图文消费升级到视频,甚至多媒体消费场景,对于我们而言需要有更多新的内容、新的玩法、新的声音帮助用户做工作;新开发者,会有新的内容需要更多的人做创造,我们会从几个方面发力:Native APP,通过9Apps帮助大家,Hybrid App通过Weex,Web APP是从UC+平台帮助大家更好的发展。

                                                                                                                                                                                                                 

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章