经常“无法加载”在今日小部件扩展 [英] Too often "Unable to load" in Today Widget Extension

查看:118
本文介绍了经常“无法加载”在今日小部件扩展的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在为我的应用制作今日小部件。我的小部件包含一个包含10个单元格的UITableView。 (每个单元格的高度为50pt。)功能很简单。如果我触摸单元格上的按钮,从sqlite重新加载DB并在单元格上显示它们。除了iPhone6 +之外,它在模拟器和iPhone 4s,5,5s,6上运行良好。我确实删除了小部件并再次添加了10次,但这对我没有帮助。我确实检查过记忆和僵尸。但是在~10M以下稳定并且没有泄漏。我怎样才能解决我的问题?

I'm making a Today widget for my app. My widget contains a UITableView with 10 cells. (Each cell's height is 50pt.) Function is simple. If I touch up a button on cell, reload DB from sqlite and show them on cells. It works very well on simulator and iPhone 4s, 5, 5s, 6 except only iPhone6+. I did remove widget and add again over 10 times, but It's not helpful for me. I did check memory and zombie. but that is stabilized under ~10M and no leaks. How can I solve my problem?

推荐答案

好的,伙计们,你们不喜欢我之前的回答。我会重试。

Okay, guys, You don't like my previous answer. I will retry.

考虑以下条件:

+-------------------+
| Table View        |
|+-----------------+|
|| Cell            ||
||+---------------+||
||| UILabel       |||
||+---------------+||
|+-----------------+|
+-------------------+

首先,表的逻辑宽度为:

At first the logical width of the table is:


  • iPhone 5上的320pt(人像)

  • 414pt on iPhone 6 +

内容比例因子为:


  • 0.5 for iPhone 5

  • 0.33 for iPhone 6 +

1pt乘以1pt的实际像素为:

Actual pixels for 1pt by 1pt are:


  • for iPhone 5,(1 / 0.5)^ 2 = 4

  • 适用于iPhone 6+(1 / 0.33)^ 2 = 9

那么如果一个 UILabel 适合整个设备宽度,它的高度为44(Apple的HIG最小可插入高度),因此,实际像素为:

So what if a UILabel fit to entire device width and it's height is 44(minimum tappable height by Apple's HIG), therefore, actual pixels are:


  • 320 * 44 * 4 = iPhone 5的设备像素为5620

  • 414 * 44 * 9 = iPhone 6 +的设备像素为163,944

因此,iPhone6 +需要比iPhone5大3倍的缓冲区来绘制UILabel。

As a result, iPhone6+ requires 3 more times larger buffer than to iPhone5 to draw UILabel.

但是,内存错误当小部件的内存使用量超过10MB时(将通过无数次实验估算)将发生。同样的限制适用于两种设备。 Apple没有记录此限制。

However, The memory error will be occurred when memory usage of the widget exceed 10MB(Estimated by countless experiments). This same limitation is applies to both device. This limitation is not documented by Apple.

请记住,在开发iOS8扩展时,你只能使用1%的设备内存,因为它可以防止杀死后台应用程序。这是支持照片编辑扩展的应用程序很少的主要原因。

Please remember, you can use only 1% of device memory when you developing iOS8 extensions due to prevent killing background apps. This is the main reason for that there are few apps that support photo editing extension.

无论如何,因此需要UI的扩展程序在iPhone 6+上很容易崩溃每个UI元素所需的内存量取决于大小和内容比例。

Anyway, As a result, Extensions that requires UI are crash easily on iPhone 6+ since the required amount of the memory for each UI element depend on size and content scale.

自定义绘图会导致同样的问题,因为它需要绘制缓冲区来优化动画和渲染。 iPhone6 +上缓冲区的分辨率和大小要大得多。

Custom drawing causes same problem since it requires buffer to draw to optimize animations and rendering. And the resolution and size of the buffer is much bigger on iPhone6+.

此外,Notification Center本身也存在漏洞(漏洞),即使只是Hello World小部件(来)使用Xcode模板)每个显示和隐藏的内存消耗都在增长。当它最终达到10MB时,它将崩溃并将被重新加载。这就是小部件有时会闪烁的原因。如果某个小部件连续崩溃3次,iOS会永久禁用小部件并显示无法加载。

In addition, there are bugs(leak) for Notification Center itself, even just Hello World widget(comes with Xcode template) keeps growing memory consumption per each showing and hiding. When eventually it reaches 10MB, it will crash and will be reloaded. It is the reason for that widgets are sometimes flashing. What if some widget crashes 3 times continuously, iOS permanently disable the widget and shows "Unable to Load".

那么,在如此苛刻的条件下我们能做些什么呢?像这样,我为这个问题做了一些规则。

So, what can we do about this problem with such harsh conditions like this, I made some rules for this problem.


  1. 不要使用实现的自定义视图[drawRect:] 除非它的尺寸非常小。

  2. 尽可能减少视图(具有自己的内容,特别是标签)。

  3. 请勿使用背景图片。

  1. Do not use custom view that implements [drawRect:] except when it is extremely small size.
  2. Make views(that have own content, especially labels) small as possible as You can.
  3. Don't use background image.



点击空白区域以选择单元格



这是Widget相关内存错误的常见问题,所以我也在写这个:

Tapping empty area to select cell

This is pretty common problem for Widget that is related memory error, So I'm writing about this also:

小部件层次结构中的所有视图都倾向于具有透明背景( UIClearColor ),这意味着使单元格可以进行处理非常困难。因为用户触摸空白区域时不会发生小部件的整个命中测试。 (只有在至少没有透明的一个超级视图时才能应用自定义命中测试)有一些解决方案:

All views in widget hierarchy tend to have transparent background(UIClearColor), it means that making cell tappable is pretty hard. Because entire hit testing for widget will not be occurred when user touch empty area. (custom hit testing only can be applied when there is not transparent one superview at least) There are some solutions for it:


  1. 制作UILabel的宽度适合Cell:DONT,它在iPhone6 +或更宽和高分辨率设备上消耗更多内存。

  2. 实现空 [drawRect:] 在自定义单元格上不,这是轻松实现透明控制的简单解决方案,但它需要绘图缓冲区。请记住,每个设备的缓冲区大小都不同。

  1. Making UILabel's width fit to Cell: DONT, it drains much more memory on iPhone6+ or wider and high resolution device.
  2. Implementing empty [drawRect:] on custom cell. DONT, This is pretty easy solution for tapping transparent control, however it requires drawing buffer. Remember the buffer size will be different for each devices.

唯一能让它无需额外内存消耗的解决方案就是将小部件背景颜色设置为0.01 alpha的黑色。 (它使命中测试工作)

The only solution that I could make it works without additional memory consumption is that the setting widget background color as the black color with 0.01 alpha. (It makes hit-testing works)

+-------------------+
| Table View        |- backgorund-color: (0, 0, 0, 0.01)
|+-----------------+|
|| Cell            ||
||+---------+      ||
||| UILabel +------++- make it small as possible as you can
||+---------+      ||
|+-----------------+|
+-------------------+

请记住,只有背景颜色的容器视图不会占用缓冲区内存。

Remember that the container view with just background color will not occupy buffer memory.

这篇关于经常“无法加载”在今日小部件扩展的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆