热更新

本文来自于 腾讯Bugly 公众号（ weixinBugly ），未经作者同意，请勿转载，原文地址： http://mp.weixin.qq.com/s/rNGD6SotKoO8frmxIU8-xw 本期 T 沙龙探讨了移动端热更新相关的话题。由于沙龙时间的限制，本期我们选取了美团的 Hybrid 化建设、去哪儿的跨平台 ListView 性能优化、微博 Android 端热更新踩过的坑话题。还期待热更新、热修复哪些话题？欢迎留言给我们。也欢迎报名参加 T 沙龙分享自己开发中的心得。 Hybrid 是移动端热更新最常用的手段，限于 App Store 上架审核时间较长，美团大众点评也采取了该方案，欢迎来自美团大众点旅游业务 iOS 负责人 吴卓 分享**《美团大众点评 酒旅方面 Hybrid 化建设》**。 大家好！我是吴卓，很高兴能来到 T 沙龙做这个分享，今天我将从 iOS 的角度跟大家一起探讨一下美团点评整体在 Hybrid 建设中做一些事情。 首先自我介绍一下： 我进入比较早，在 2011 年的 7 月份最早在美团实习。后来又继续出国读研，同时做一名兼职的开发者，在 2013 年的时候，做过 iOS 的独立开发，有很多人把它作为自己的一项事业去做。 后来在 2014 年 12 月份重新加入美团，现在是旅游 iOS 的负责人。 我负责的主要是住宿，度假，大交通

开篇之前,先讲一个自己开发中的一个小插曲: 今天周日,iOS版 App 周一提交,周三审核通过上架,很给力.不过,中午11:30的时候,运营就反应某个页面有一个很明显的问题,页面没法拉到底部,部分信息显示不全;那个页面是基于react-native写的,项目中本身已经有了热更新的相关机制;原因很简单,13:00左右,解决问题,发了一个补丁,测试环境自测完毕;补丁发给Leader,他可以提交到线上;出去吃饭,13:00 回来午休;14:00,Leader回到工位,补丁提交到线上;确认补丁生效,问题解决. 不要吐槽说,流程可以更优化,解决的问题更快,这涉及到另一个话题,改日有心情再聊. 如果按照没有热更新能力的解决流程,大致会是: 11:30 发现问题,13:00 解决,确认测试环境生效;生成测试包,上传 提交;人品好的话,可以走紧急审核;3~5天后,问题修复.3~5天的审核期,有人认为很长,有人早已习以为常. 小插曲而已,看看就好.我只是想让大家明白,react-native本身,可能对你的业务,确实是一个很有意义的工具,仅此而已.许多人,也是认同 react-native 的价值的,但是可能并没有在自己的项目中应用,而没有应用的原因,相对一部分原因,是很难驾驭.从我目前的实践来看,没有一个能够同时自由驾驭Native和react栈的技术人员存在,一个技术组是很难有可能把react

必要的序 以后在写系列文章,准备把基本的规划和动机等,单独作为一个小的序言部分给独立出来.序言部分,可以较为完整地交待系列文章的写作动机,所展示的编码技术可能的应用场景等.个人,我还是比较看重文章或者书籍等的序言部分的.真有相对确定确实有价值的东西,才会进一步去阅读.所以,我觉得,序,总是必要的. 关于我写博客的节奏 我会尽可能地使每一个系列的文章,能相对完整.但是,就像你看到的这样,前一个系列还在讲Spark,这篇文章就开始讲 iOS 开发的一些问题.到底要闹哪样? 还能怎么样?开心就好!干嘛要让那些不存在的东西,束缚自己呢!我觉得,理想的生活节奏就是,做自己喜欢的事,然后分享给有需要的人看.这就够了. 所以说,未来不管你在博客中看到什么诡异的系列主题,都不用感到惊讶!如果刚好自己也感兴趣,一起来玩喽~ 当然,有人说,天天BUG,还解不完呢,哪有闲心写BUG呢!这是问题,或许也是答案!你用来解决某个BUG的精湛技巧,或许在QA或者PM眼里,不过是理所当然地而已;就算他们给你一个赞,你也明白,其实他们可能根本就不懂你解决的这个问题的真正意义. 但是编码的众多有趣属性中的一种就是: 别人的不认同,并没有办法真正否定你天马行空般编码技术的价值和意义.写出来,哪怕只有一个人,能真心看懂,发自肺腑地给个赞--足矣! 为什么要实现iOS图片等资源文件的热更新化? 首先说一下,这个系列要做什么

简介 以前写过一个补丁更新的文章,此处会做一个更精简的最小化实现,以便于集成.为了使逻辑具有通用性,将剥离对AFNetworking和ReativeCocoa的依赖.原来的文章,可以先看这里: http://www.ios122.com/2015/12/jspatconline/ 这么做的意义 先交代动机和意义,或许应该成为自己博客的一个标准框架内容之一,不然以后自己需要看着,也不过是一堆干瘪的代码.基本的逻辑图,如上!此处,我就从简! 从简的原因有3: 补丁更新,状态可以设计的很复杂,就像开头那篇文章提到的那样,但是我感觉没多大必要,至少在我们的App中; 我想演示一个相对完整的逻辑,但是又不想耗费太多的时间构建场景; 从简后的方案,简单但够用了,至少目前针对我们的项目来说; 所以说:这篇文章的意义,其实是在于简化已有的热更新代码,越简单越好维护. 基本思路 App启动时,判断特定的服务器接口所返回的图片url是否为最新,判断方式就是比对返回值中的md5字段与本地保存的资源的url是否一致; 如果图片资源有更新,则下载解压到指定的缓存目录,初步打算以资源文件的md5来划分文件夹,来避免冲突; 读取图片时,优先从缓存目录读取,缓存目录不存在再从ipa资源包中读取; 下面就一步一步来实现了. App启动时,判断有无最新图片资源 此处主要涉及到的可能的技术点: 1.