在修改完一个bug之后，我突然意识到一个问题。这个APP没能上架 APP Store, 那用户如何更新app呢？
答案当然很明显，我需要实现一个自动更新的功能。 但是失去了APP Store这条大腿，自己又没钱买服务器，如何才能实现自动更新呢？ 思来想去，我发现还有另外一条大腿可以抱一抱，那就是所有程序员都知道的 github 。
接下来简单说下我实现自动更新的流程：
下面是效果图
以前在一家公司开发的ios app是通过企业证书打包的，自动更新是通过公司自己的服务器实现。如果你所在的公司比较贫穷 或者 比较节省，也可以考虑用这样一种方式实现自动更新。如果我们要检测app版本的更新，那么我们必须获取当前运行app版本的版本信息和appstore 上发布的最新版本的信息。
当前运行版本信息可以通过infoplist文件中的bundle version中获取;
要获取当前app store上的最新的版本，有两种方法，
一、在某特定的服务器上，发布和存储app最新的版本信息，需要的时候向该服务器请求查询。
二、从app store上查询，可以获取到app的作者，连接，版本等。官方相关文档
>>1、为什么要加缓存？
场景一：等待，在向服务器请求新的数据时。我们让用户看到什么？第一种是漂亮的等待加载页面；第二种是缓存的内容。对于第二种，用户可以对页面进行 *** 作，等待新数据时可以查看旧数据，更具有“可 *** 作性”与“可用性”，从而减轻了从服务器获取数据这一动作的大小和时间长短，增强了用户体验。另一方面，如果内容更新的间隔较长或者用户刷新的间隔较短，在没有缓存的情况下，很多数据我们会多次重复的向服务器获取，增加了成本。
场景二：结果没有联网，或者在地铁上网络太差无法加载数据时，如果留给用户一个空白页面，实在是感觉有点不负责任啊。并且很多功能在没有联网的情况下也有使用的可能性，比如：APP中的通讯录，查看一些聊天记录，通知信息，文章列表等。因为用户打开APP不一定是要看新信息，说不定是回顾老信息（或许老信息里也有用户之前没看的），所以恰当的缓存可以满足更多的用户场景。
场景三：金钱有一天，一个用户发现自己装了某个APP后流量用的特别快，Ta可能永远将这个APP打入冷宫了，而增加缓存正是节省流量的一个方法。虽然节省的不多或者用户也察觉不到，但是作为一个有态度的产品经理，应该多做一些思考。
2、什么是缓存？
缓存可分为如下几类：
（1）app缓存。
（2）固定缓存。
（3）可手动清理的缓存。
（4）不可手动清理的缓存。
（5）临时缓存。
其中，临时缓存常用于一个功能页面内，保存各栏目的缓存。同一个功能里会把子功能分为多个栏目进行划分，每个标签栏目下的内容在本次使用中都可保存为临时缓存，在该功能里切换栏目，不需要重新加载数据，使用缓存显示。
对于用户来说，使用时达到了无缝切换浏览，对于服务器来说，在短时间内数据很少会有更新，所以在一般情况下能满足用户的正常需求，并达到体验优秀。
临时缓存的清理机制是：退出该功能模块就清除之前的缓存。也就是说下次进入该功能模块，需要重新获取一次数据。
很多时候我们都会用到临时缓存，因为那些信息真的不是那么重要，而且不需要经常反复查看，那对于那些我们经常使用而且经常需要反复查看的信息，马海祥建议采取固定缓存，保存在本地，方便下次翻阅时不需要再一次向服务器请求数据了。
对于固定缓存又会细分为可手动清理的缓存和不可手动清理的缓存。
第一种是我们最常见的缓存，几乎所有产品都采用这种缓存方式。平时用户浏览文章、图集加载的数据就以这种形式缓存在本地，下次看回这篇文章、图集时就不需要加载了。用户也可以手动把这些缓存清理了，释放空间。
而对于某些特殊场景，例如一些相对固定的数据，我们不愿意一开始就打包进App里，这样会占太大容量，造成产品包很大，也不愿意每次进入页面都向服务器加载这些信息，那怎么办？建议的解决方法就是我们可以只加载一次就永远存在本地了，这样安装包也不会大，以后也不用加载了。
3、如何清理缓存？
一般App都会在“设置”里提供一个清理缓存的功能，一键把空间释放。除此之外，App最好要设计自动清理机制，可以通过两个维度来设计这个机制。
（1）、时间
通过设定一个固定的时间，或者根据用户使用周期灵活设定时间来清理缓存。每个产品的场景不一，用户使用频率不一，设定这个机制的时候就需要结合实际情况考虑了。
（2）、容量
一般是设定一个容量上限，采用堆栈的设计原理进行缓存清理，溢出堆栈的旧数据将自动清除。
1、页面加载
方案1：单页面整体加载
这种加载比较简单，一般运用在页面内容比较单一的情况下，所以直接一次性加载完所有数据后再显示内容。其单页面加载失败的状态相对来说也比较好处理。
方案2：单页面分块加载
这种方案的特点是，能让用户逐步看到内容，在这个渐进的过程中降低用户的焦虑心理。
其中又可以分为，模块间有关联性的，先加载父内容，再加载子内容。如优酷，先把栏目加载出来，再加载各栏目的内容。
模块间没有绝对关联性的，可独自加载各自模块内容，根据请求的速度不同分别显示。这样处理有一定几率让用户在没完全刷出数据的情况下就能找到自己需要的功能，如大众点评、淘宝客户端等。
框架固定，内容更新的，可先把框架显示出来，再把各模块的数据各自加载显示，如各种iOS自带应用。
这种分模块加载的需要特别注意加载失败的状态，毕竟每个模块都提示加载失败，点击重试是很挫的一件事，可以根据信息的优先级来决定哪些数据失败了采用默认状态，哪些数据采用失败提示。
方案3：跨页面加载
父页面&子页面 or 同一app内，页面间字段可以复用的，在加载子页面时不需要重新加载新数据。
方案4：预加载
这种加载方式的特点是，在加载一个页面内容的同时，预测用户的下一步行为，并为他下一步需要使用的页面加载内容，使得他在下一步的 *** 作中能立刻获取信息而不需要加载等待。
预加载提供给用户无缝的产品使用体验，使得用户在使用产品的过程中更直接流畅，没有被打断的感觉。
具体的例子有：
在浏览图集的时候，当看到第一张的时，就自动后台加载第二第三第四张，用户浏览完第一张切换到第二张时就不会有加载等待的过程。
在浏览新闻列表时，就把每篇新闻的内容在后台进行预加载，用户选择看某篇新闻时，能立刻阅读到内容。
但是这种方案也需要面临很多的问题，马海祥觉得最直接的就是流量问题，因为会自动跑掉很多用户可能根本用不上的数据流量，所以，一般情况下马海祥建议可以设定在wifi环境才采用这种加载模式。又或者设定加载规则，只把主要内容预加载，而部分次要内容可以在用户真的用到的时候才加载，例如预加载新闻正文的情况，可以只加载文本信息，信息等到用户进入内页才加载。这种预加载与分块加载结合的方式也普遍运用在各个场景。
另外，预加载也需要时间的，他只是不在客户端显示给用户，默默在后台运作而已，需要特殊考虑未加载完用户就使用到那些信息的情况，所以在做预加载设计时需要同时考虑另一种适合该情况的普通加载方式。
预加载需要根据具体的场景来进行设计，设定好信息优先级，综合考虑各种类型信息的具体大小流量，整体考虑预加载的方式，这些都是需要经过精心分析思考的。
随着网络环境的发展，预加载将成为以后产品普遍的加载方式，他提供给用户的无缝使用体验地提升了产品的可用性。
2、 *** 作加载
除了页面的信息需要加载，页面内的 *** 作也是需要通过给服务器发送请求记录的。
方案1：加载层
进行一个 *** 作后，d出模态的提示层，告知用户正在加载。采用模态的提示主要是防止用户在该过程中进行其他 *** 作，导致当前加载出错。由于采用模态的提示，并且有可能因为网络原因导致长时间处于加载状态，建议提供一个“关闭”的 *** 作，中止本次加载，恢复App可用状态。加载失败时可在当前浮层变换为失败提示。模态提示层是最稳妥的方式，但他会使用户在使用过程中有打断的感觉。
方案2：控件自身加载状态
这种方式是把 *** 作加载的状态与控件的样式结合起来了，对某个控件进行 *** 作后，控件变换为加载状态，此时控件不能重复 *** 作。由于这种加载方式是控件的自身状态，不影响其他 *** 作，所以用户也可以对页面进行其他 *** 作，可能会导致同时有多个请求的情况，增加了加载失败的风险，这也算是这种方式的弊端，不过这种极端情况很少出现。请求失败后，可配合Toast提示告知用户失败的原因。
方案3：后台加载
用户在 *** 作后，客户端立刻反馈 *** 作成功，然后把请求放到后台与服务器交互，这一过程用户不需要了解，不需要等待，在正常情况验是非常棒的。
但是在极端情况下会出现一些莫名其妙的状况，由于是后台记录请求并与服务器交互，所以实际请求是否成功客户端是不说明的，全部以 *** 作成功来显示，这就会导致用户误以为 *** 作成功了，但实际上下次来看发现没有成功。
所以，这种加载方式是需要根据具体使用场景来权衡使用的，对于一些重要的 *** 作，建议还是使用模态的方式加载，对于一些小 *** 作，如点赞、订阅、关注，可采用后台加载的方式。
3、下一页加载还是当前也加载
用户进入首页，正式迈出体验的第一步，接下来迎接的就是基于用户目标的界面间跳转。完成界面的跳转，会有各种加载策略，但无论形式如何，我们都可以将其归为两大类：“下一页加载”、“当前页加载”。
（1）“下一页加载”满足了用户提前窥视的需求
我们把页面看成“点”，页面流是连接这些点的“线”，我们以“用户想买一条牛仔裤”这一场景作为案例做了简单的眼动研究，从应用启动到商品浏览再到商品确定最后进入下单页，用户所呈现的瞳孔梯次增大，即E>D>C>B>A，为了解释这一现象，通过与被试交流，我们发现相比于各种浏览，用户更期待看到他们想看到的东西。因此此时的”下一页加载“正好，满足了用户提前窥视的需求。
（2） Wait！I Need Think Think
我们以同样的方式又对“使用支付宝对手机充值”这一场景做了研究，从开始支付到二次确认支付，用户所呈现的瞳孔都比较大，即A与B近似相等，通过访谈，我们发现与“递增体验流”不同的是，当用户遇到判断逻辑的界面时，用户并非急于想看下一页面到底包含怎样的内容，而是非0即1的验证心态，即我的 *** 作效成功了吗？因此在判断逻辑界面中，用户的内容窥视需求并不强，当然也没什么内容，要么仅是一个小小的Toast，再大一点就是一个简单的信息反馈界面（意味着“下一页加载”在这里就是个鸡肋），用户反而对非0即1的验证需求较为强烈，其中还伴随着等待结果过程中的紧张感、激动感，因此界面通过 当前页加载 表明系统正在努力地处理用户交代的指令了用户的紧张感、激动感，直到结果显现——“处理成功”，完成了非0即1验证的满足感。
4、先加载还是先展示
当需加载的是功能时，可以先展示再加载，当需加载的是内容时，则反过来。
淘宝
打开APP的第一个页面是功能，所以先展示再加载的：
随便点击一个模块（不要点菜单），下面要展示的将要是内容（商品），所以是先加载再展示的，没有加载完都不展示：
京东
同样的，功能模块先展示后加载：
内容先加载，没加载完不展示：
两种方式各有利弊：
先展示，后加载：
优点：给用户0等待的错觉
缺点：当前数据有可能是错的，而且得等用户 *** 作到最后一步才会发现
先加载，后展示：
优点：保证数据的质量和准确
缺点：网络不好时，造成等待
显然，功能模块对于一个产品来说是既有固定的，在短时间内几乎不会更新，所以这种数据出现错误或与当前状态不同的几率小得多，因此，可以使用先展示后加载的方式。
另一方面，内容（特别是商品数据）是最容易产生变动的，为了保证每一个消费者看到的数据都是最真实，最准确的，所以务必要先加载再展示。
1、空白页面刷新失败有提示
现在的应用都标榜以内容为中心，所以都会极力避免空白页面的出现。对于大部分的应用，最好的方法就是使用缓存，进入页面之后，先显示之前的缓存，然后再进行内容的刷新。其次，消灭空白页面的第二种方法就是提供系统推荐项进行替代。但是对于一些页面，页面内容跟用户的使用状态关系密切，无法避免会出现空白页面，这时候会使用一些引导类的提示，使得页面变得更加丰富，同时可以促进用户产生内容。
但是一些资讯类应用，比如读读日报，打开默认是空白页面，然后再加载内容（我不是很明白这种设定）。其他一些应用，比如：豆瓣一刻和MONO，每天第一次进入应用的时候也会出现空白页面。我猜想第二类应用的展示方式的原因是这样的。他们的内容都是严格以天为单位的，每天固定时段精选内容。他们会希望你每天只看并且看完当天的东西，所以一旦到了第二天，昨天的内容就是累赘了。所以每天第一次进入应用的时候会出现空白页面，象征着每天都是从新开始。此时就会对应一个“空白刷新”逻辑。
空白刷新对应的场景是这样子的：用户想要刷新出内容，并且用户知道这里可以刷出新内容，但是没有刷新成功，这时候需要给用户一个交待。所以需要提示用户。同时，提示完用户之后需要给用户一个解决方法，这就是“点击后重试”。
2、缓存页面刷新失败无提示
常见的应用比如知乎、网易新闻、好奇心日报、微信朋友圈等，这些应用都会采用缓存的形式，打开之后显示的是缓存内容，然后系统会给服务器发送请求，如果有内容更新的话就会自动更新一次内容，更新之后的内容直接覆盖当前的内容。更新失败之后是没有提示的。但是有一些应用，比如有道词典、企鹅FM、网易云音乐等，他们更新失败之后是有提示的。
我觉得这两种应用的区分点在于
应用的使用频率；
内容的时间连续性；
界面之间的关系紧密度。
比如说网易新闻，作为一个打发时间的工具，每天使用频率就会比较高，所以用户进来之后是想看看有没有更新。其次，网易新闻的内容是连续不断更新的，所以用户会知道当前显示的内容是我看看过并且处理过的。最后，新闻列表页面显示的是摘要，用户可以通过摘要快速进行判断是否要进入详情页，摘要有助于帮助用户回忆上一次的使用场景。
所以这就对应着一个这样的场景：用户只是想看看有没有更新，所以他们已经做好了“没有新内容”的心理预期，所以即使是更新不了内容，用户也不会想太多。反倒是，如果进行了错误提示，用户可能会有一种挫败感。因为他知道现在有内容，只是因为网络的原因而没有更新，他要进行的任务受到了外界因素的阻碍，由此产生一种细微的挫败感。
3、缓存页面刷新失败有提示
另一类应用，使用频率没那么高，或者内容不具备时间连续性的，又或者说当前界面无法唤起用户上一次的使用场景。那么就有必要进行率先你失败提示了。
比如说企鹅FM，音频类的应用注定使用不会那么频繁，因为通过视觉接收的信息会比通过听觉接收的信息更快更多，同时音频类对环境的要求较高（比如用耳机时要求环境不那么嘈杂，外放时要求在私人场所）。其次，此类应用都是实时推荐的，不存在时间连续性的问题，用户无法通过时间来判断内容是否被阅读过。再者，标题也无法帮你快速做出判断，你还是要进去听过才知道内容是什么。最后如果不提醒，用户进入到详情页再收到提醒，就会觉得应用浪费了用户的时间。所以，对于此类内容，刷新失败是有必要进行提醒的。Native app维护更新复杂主要是因为以下几个因素：
1 多平台适配问题：Native app需要适配不同的 *** 作系统和硬件平台，例如iOS和Android，这涉及到不同的设计规范、开发语言、API和SDK等，开发团队需要具备多种技能才能完成多平台的适配工作。
2 版本兼容性问题：随着移动设备的不断升级， *** 作系统和硬件平台也在不断更新，因此Native app需要保持与不同版本的 *** 作系统和硬件平台的兼容性。如果不及时更新和修复，可能会导致应用程序的崩溃和功能失效等问题。
3 跨团队协作问题：Native app开发通常需要跨多个团队进行协作，包括设计、前端、后端、测试等，这就需要开发团队高效的协作和沟通，以确保每个人都对应用程序有清晰的理解，并按照一致的标准进行开发和维护。
4 安全性问题：Native app通常会保存用户的敏感信息，如用户名、密码、支付信息等，这就需要开发团队保证应用程序的安全性，以防止黑客攻击和数据泄露等问题，这需要考虑到多个方面，包括加密、防篡改、防病毒等。
因此，Native app的维护更新比较复杂，需要开发团队具备多种技能和经验，并保持高效的协作和沟通。
手机APP经常更新这个原理就跟手机经常需要升级系统，电脑经常更新系统等原理是一模一样的。
经常更新APP是因为APP会经常增加功能，修复bug优化用户体验新功能。
因为对于有些有bug会极大地影响用户体验，比如在bug之外还有很多按钮、布局、交互方式等会影响到用户体验。
有些应用是为了优化自己的产品，有些应用是保住以及增加用户的方法，总之各有所好。
从开发者来看，因为应用软件开发与PC软件开发的特点本身不同，由于更激烈的竞争环境，要求开发者快速完成开发，并有敏锐的嗅觉去不断迎合市场需求。
手机应用不断的更新，从深层次来讲，是一件好事，是应用商为了促使产品更加的人性化，用户体验更加的好，产品功能更加的完善和齐全的目的二区做的更改，不管是对是对商家来说，还是对我们用户自己来说，都是一件非常好的事情。唯一需要强调的就是我们的内存了。
先来说一下我的情况吧，我的手机只有3G运行内存，16G手机，可想而知有多么卡了，我每次是用到什么应用才回去卸载，经常不用的或是偶尔需要用到的，我都是用的时候再卸载，比如办公软件钉钉吧，有时候请假的时候我才会安装，然后请完假就直接的卸载。
平时感觉用的最多的也就是头条和微信这两款应用，因为我是做自媒体的，它们也是更新的比较频繁的应用，为了更好地满足用户的需求，觉得每一次的更新，都会是一个全新的体验吧，并且增加了很多的功能，让用户体验更佳的好。
关于手机内存不足的现实，我们可以装一个存储卡，我的手机已经都用好几年了，是在是划不来了。也只剩下更新换代了。
我们需要做的就是养成生活中清理内存的好习惯，因为很多的应用，尤其是网页类的应用，视频、都会非常占用我们的内存和空间，我们要定期养成清理内存的好习惯，具体方法非常的简单，打开手机——设置——应用管理，可以清理很多的空间。
Android 和 iOS 应用的更新都可以不用做，可以让第三方应用商店来帮你做，你只需更改应用的版本就行了。目前 Android 的通用做法是，在应用内检查版本号，通过跟服务器的版本号来对比，版本号不同就更新，具体的做法是可以在应用内写个下载程序，也可以在d出浏览器来下载。iOS 应用如果要上传到 app store，是不允许在应用内检查更新的，否则不让上架，iOS 的更新更简单，让苹果 app store 来做就行了，你在 build 的时候，改变版本号就行，希望对你有帮助。欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）