我有一个使用的应用程序,auto-layout当我在iOS 7设备上运行它时,一切仍然按预期工作,但是当我在iOS 8设备上运行时,我的一些约束有点古怪.
我实际上在另一个应用程序中遇到了类似的问题,但这不是一个大问题.现在,我开始怀疑它是否是iOS 8 SDK中的一个错误,或者是否有一种新的方法来处理iOS8中我不知道的自动布局.
这是我的设置:我有UIView一个UIImageView嵌入其中.视图和图像视图都有约束将其底部,前导和后沿固定到其超级视图,常量= 0.
该UIView也有其固定到它的父顶部边缘,我必须以编程方式调整它连接到约束一个IBOutlet.它UIImageView具有第四个约束,将其高度固定到设备的高度(在我的情况下为568).
以下是我在iOS 7中期望/实现的行为:我正在尝试缩小容器视图的高度,并导致图像视图的顶部在没有宽高比变化的情况下被切断(看起来像你裁剪的那种图像的顶部关闭)...这就是我固定图像视图和底部边缘的高度的原因.
在iOS8中实际发生的事情:容器视图按预期收缩(它保持固定在侧面和底部,高度收缩).该UIImageView行为就好像它曾与cosntant == 0,而不是切断图像的顶部的顶部空间限制,整个图像逐渐缩小.由于我在AspectFit模式下有图像,因此侧面也会捏合以保持纵横比相同(但是imageView本身仍保持固定在前导,后沿和下边缘).
我该怎么做:我有一个通知,从我的代码的另一部分触发,以调整连接到IBOutlet的顶部空间约束.它调用的方法非常简单:
- (void) setTopSpaceForContainerView:(NSNotification*) notif{
containerView_TopSpace.constant = [[notif.userInfo objectForKey:kTopSpace] intValue];
[self.view setNeedsUpdateConstraints];
[self.view setNeedsLayout];
}
其他人有类似的经历吗？我正在尝试找到一种解决方法,但iOS 8似乎决心缩小我的图像.
万分感谢!
我有一个超过50个目标并且正在增长的项目,将文件添加到所有目标变得很麻烦,因为选择每个目标需要很长时间.
我知道有多种方法可以将文件添加到多个目标,但它们都涉及检查每个目标的框.(对于那些寻找它的人:如何将.plist文件添加到XCode中的所有目标？)
我正在寻找的是一种替代方法或脚本,可用于将文件或文件集添加到项目中的所有目标,而无需逐个选择它们.有人知道一招吗？
我希望社区可以为我澄清一些事情,其他人可以从中受益.
我的理解是,gunicorn工作进程本质上是Heroku web dynos的虚拟复制品.换句话说,Gunicorn的工作流程不应该与Heroku的工作流程混淆(例如Django Celery Tasks).
这是因为Gunicorn工作进程专注于处理Web请求(基本上限制了Heroku Web Dyno的性能),而Heroku Worker Dynos专注于远程API调用等,这些是长时间运行的后台任务.
我有一个简单的Django应用程序,可以很好地使用远程API,我想优化资源平衡.我也在大多数请求中查询PostgreSQL数据库.
我知道这非常简单,但我是否正确地思考问题？
一些相关信息:
https://devcenter.heroku.com/articles/process-model
https://devcenter.heroku.com/articles/background-jobs-queueing
https://devcenter.heroku.com/articles/django#running-a-worker
http://gunicorn.org/configure.html#workers
http://v3.mike.tig.as/blog/2012/02/13/deploying-django-on-heroku/
https://docs.djangoproject.com/en/dev/howto/deployment/wsgi/gunicorn/
研究此主题的其他准相关有用的SO问题:
排除Nginx + Gunicorn + Django堆栈上的站点缓慢
TL / DR：我的主要问题：是否值得花时间尝试将NGinx添加到我的Django / Gunicorn / Cedar / PostgresSql应用程序中，或者Heroku是否为我实现了这种性能改进？
在Cedar文档（https://devcenter.heroku.com/articles/cedar）中，它明确指出cedar不支持反向代理。“ Cedar不包括诸如Varnish之类的反向代理缓存，而是希望使开发人员能够选择最能满足其需求的CDN解决方案。”
同样在“路由”文章（https://devcenter.heroku.com/articles/http-routing#gzipped-responses）中，指定了nginx不会自动完成：“因为对Cedar应用程序的请求是直接向应用程序服务器发出的–不通过像nginx这样的HTTP服务器进行代理–必须在您的应用程序内完成响应的任何压缩。”
但是，在Python常见问题解答中，它表示 相反：https : //devcenter.heroku.com/articles/python-faq#do-python-applications-run-behind-nginx “不。不需要使用反向代理在Heroku上运行，因为Heroku Cloud Platform会处理这些服务器通常为您所做的一切。
您的应用程序仅提供一个Python服务器来响应HTTP请求.Gunicorn，Gevent和Eventlet是绝佳的选择。
由于Web服务器是嵌入在您的应用程序中的，因此您可以在任何环境中轻松测试和调试完全相同的代码。这种开发和生产上的均等性使得在开发周期中解决问题变得很容易。”
在我看来，Heroku可以解决反向代理的某些好处，但不能解决压缩问题。真的吗？