了解移动应用程序变慢的这三个主要原因可以帮助您解决等待建立UI（用户界面）的问题；另一方面是与UX（UserExperience）相关，包括界面按钮无法按预期响应，或者用户发现各种默认的手势、动作、动画无法生效等。显然，这两者都会影响用户体验。在本文中，我将深入探讨导致应用程序运行缓慢的主要原因以及如何使用跨平台应用程序框架解决这些问题。跨平台vs.原生在日常的开发过程中，人们往往对跨平台技术存在偏见。他们认为，因为不是原生的，而是基于网络的，所以整体效率会比较慢，当然也难免出错。然而，他们不知道：如今，原生架构能够实现的功能，跨平台应用框架基本上都可以实现，而它们之间的运行效率通常取决于用户如何实现他的程序代码。在实际项目中，我们经常看到一些团队使用Swift/Java开发的原生应用速度慢，经常崩溃；而其他团队则可以使用Titanium等跨平台技术开发流畅的产品。此外，跨平台框架本身可以在不使用混合跨平台工具的情况下生成真正的原生UI。所以，作为一个原生应用的开发者，你过去遇到的内存泄漏等问题，在今天的大多数跨平台框架中已经得到了充分的解决，它们可以帮助开发者完成大部分重量级的Load任务。由此可见，只有了解你所使用的框架的局限性，才是避免出现应用缓慢的情况的关键。下面，我就试着和大家一起分析为什么跨平台应用在移动设备上运行缓慢甚至无响应，并帮助大家找到各种提速的方法。作为代码示例，我选择了Titanium作为框架。当然，这些改进技术也适用于其他类型的框架。原因一：设计通常，在开发跨平台应用时，开发团队倾向于将两个平台的版本合二为一。而这种设计理念，恰恰是导致应用运行久了变慢的根源之一。首先，你需要了解的是，不同平台对应的默认UI和UX（更重要的是）是有很大差异的。例如，iOS为每个窗口“堆栈”配置打开/关闭动画和滑动手势。虽然这些看似微不足道，但动画的触发却能给用户带来互动体验。这种“让用户通过在手机屏幕上滑动手指，就可以在应用中的不同页面之间和窗口堆栈中的应用之间切换”的思路缓冲了跳转的时间。用户不会直观地体验到点击后退按钮可能会体验到的缓慢。因此，开发者在为一个表单设计不同的外观时，应该考虑是否使用原生显示效果。如果要自定义，那么开发者需要使用一个事件监听器来捕捉用户是否在屏幕上滑动手指，然后关闭相应的窗体。否则，动画手势的突然消失会让用户感受到整个UX的下降，进而产生应用变慢的感觉。除了以上动画效果和UI的区别，开发者还需要注意跨平台框架的垃圾回收，防止自定义UI运行过程中出现内存泄露。同时，随着用户的广泛使用和移动设备硬件性能的提升，他们会设置更多的自定义手势和快捷方式，您的移动应用需要捕捉、跟踪和计算更多的手指轨迹。所以，你会发现数据的加载和计算的阻塞会相互影响，形成恶性循环。结果，一些应用程序在推出一年后就失去了可维护性和可用性，开发团队不得不重新编写和重构程序。解决方案首先，在应用程序的设计阶段，我们应该充分理解并接受平台之间的差异。通过两个系统的产品设计，我们可以发现不同平台用户对界面和效果的期望。在公司内部，可以邀请长期使用安卓手机和iPhone的两类人，对各种使用效果进行实测。其次，利用内置的UX/UI特性，尝试从原生平台的角度，在应用界面上实现各种功能。例如：在大多数iOS应用中，按钮一般放置在标题的左右两侧；而Android版本通常将按钮放在右侧，或者直接将它们隐藏在菜单图标内。此外，Android应用程序将内置后退按钮，而iOS应用程序将具有后退手势。通过支持基于不同移动平台的这些功能，用户可以直观地了解您的应用程序并产生一定的认同感。类别2原因：加载太多应用程序速度变慢的另一个主要原因是：一次加载UI中的元素太多。毕竟移动设备的性能不如用户的电脑，很难同时处理多个任务。此外，并不是每个人都能使用最新的iPhone和高端Android设备。仍在使用Android4.4的用户不在少数。因此，要在各种应用商店中脱颖而出，您的移动产品应该能够在低端配置和旧版本设备上仍然表现出色。例如，在iOS应用商店中，如果您点击并选择“今日”选项卡，它会快速加载五个应用选项卡。接下来，向下滑动时，请注意滚动条的位置和大小。你会发现很简单：滚动条会以原来的大小滑到屏幕底部，当接近屏幕底部的20%时，它会迅速收缩，甚至弹回到上面的某个位置.而“第二页”的数据开始显示在屏幕上。可以看出，应用商店并没有一次性加载所有的数据。因此，在实际应用的设计和构建中，我们应该扪心自问：当我们让用户看到推送的内容时，是否将后续的内容一起加载？你延迟加载图像吗？在预加载的数据中，ListVIEW中应该显示多少？100件还是200件？应用启动时需要调用多少个API？快速调用50个API”，以及“如何在ListVIEW中高效加载10,000条信息”的消息。在这里，我的回答是：“不要那样做！”没有人可以一次查看那么多条信息。使用lazy-加载和分页如果你希望用户能够滚动列表，即使数据存储在设备本地。此外，如果你希望用户搜索？那么请在本地之后推送到用户的设备搜索是在服务端完成的解决方案从上面苹果应用商店的例子，我们可以了解到，直到应用被***打开后，数据内容才被加载。例如在默认的TabGroup中：...也，我为hometab的form添加了一个postlayout事件监听器，这个函数的作用是调用form的initializer，获取tab的相关数据后加载，通过等待postlayout事件，可以确保用户看到的不是加载页面，而是正常的应用程序内容。这是一个simple函数--handlePostlayout用于稍后初始化内容：实际请求的内容，以及相关的依赖，并没有立即初始化或加载，这无疑加快了应用程序的整体性能。同时，对于其他的tab，我们可以监听屏幕窗体的“focus”事件，只有当窗体获得焦点时才加载。同样，也可以使用该事件在当前窗体再次获得焦点时及时刷新数据；并将其应用于FirebaseAnalytics（Android集成埋点分析）。请记住：与使用分页或延迟加载重新初始化整个页面相比，仅下载数据的方法将在数量级上“更轻”，速度更快，CPU效率更高。理由#3：桥梁这里的“桥梁”是一个源自跨平台框架（如Titanium和ReactNative）的概念。它说：JavaScript代码和本机代码之间的每次交互都会产生开销。举个例子：当你在服务端调用API时，很显然，与花费100次调用API每次只取回1条数据相比，我们更愿意只调用一次API一次取回100条数据数据。那么什么是“过桥”呢？其实我们在添加UI元素，更新UI元素，触发动画的时候都会产生调用。例如：Titanium中的Ti.App.fireEvent流程需要用到bridge的概念。这类事件通常用于触发应用程序中的某些操作，进而实现初始化。此外，此类事件还会触发UI更新操作。因此，一个事件可能会触发两次过桥。那么当所有事情同时发生时，尤其是循环触发的状态下，过桥的过程就会变得“拥挤”。但是如果网桥的带宽容量比较“窄”，你的应用就会出现大面积的延迟，甚至会出现中断，直接影响用户体验。解决这类问题其实很简单。您只需要将UI的批处理组合在一起。因此，当ListTimes整张表需要修改时，我们可以使用ListTeal.RePateTimeSt轻松一次性重新插入整个数据集。当您需要更改UI元素的一组属性时，您可以使用applyProperties而无需更改每个属性的特定顺序。同时，您可以使用BackboneEvents来触发整个应用程序的各种事件，而无需过桥。而且，我们可以很方便地将当前各种Ti.App事件迁移到BackboneEvents。如下所示，我们首先将BackboneEvents包含到alloy.js中。Alloy.Globals.events=_.clone(Backbone.Events);然后，将应用程序中使用Ti.App.fireEvent()的任何地方替换为以下函数：Alloy.Globals.events.trigger();然后，以同样的方式，您可以继续将Ti.App.addEventListener()替换为：Alloy.Globals.events.on()您甚至可以在您自己的项目上进行全局搜索和替换，以立即提高性能。结论综上所述，移动应用程序变慢的原因有很多，其中大部分都与低效的代码实现有关。因此，我们应该尽量使用原生的UI组件，尽量少加载数据，减少桥的数量。***，我再重申一遍：跨平台框架注定不会比原生应用慢。事实上，在各种应用商店中，你会发现95%到99%的应用（不包括游戏应用）都是使用Titanium等框架构建的。原标题：移动应用运行缓慢的3个原因，作者：RenePot
