├── HD ├── 101_hd_keynote.srt ├── 102_hd_platforms_state_of_the_union.srt ├── 103_hd_apple_design_awards.srt ├── 104_hd_whats_new_in_xcode.srt ├── 105_hd_introducing_watchkit_for_watchos_2.srt ├── 106_hd_whats_new_in_swift.srt ├── 107_hd_whats_new_in_cocoa_touch.srt ├── 108_hd_building_watch_apps.srt ├── 201_hd_ios_accessibility.srt ├── 202_hd_whats_new_in_cocoa.srt ├── 203_hd_whats_new_in_healthkit.srt ├── 204_hd_apple_watch_accessibility.srt ├── 205_hd_getting_started_with_multitasking_on_ipad_in_ios_9.srt ├── 206_hd_whats_new_in_mapkit.srt ├── 207_hd_watchkit_indepth_part_1.srt ├── 208_hd_watchkit_indepth_part_2.srt ├── 209_hd_creating_complications_with_clockkit.srt ├── 210_hd_whats_new_in_homekit.srt ├── 211_hd_multitasking_essentials_for_mediabased_apps_on_ipad_in_ios_9.srt ├── 212_hd_optimizing_your_app_for_multitasking_on_ipad_in_ios_9.srt ├── 213_hd_building_apps_with_researchkit.srt ├── 214_hd_introducing_on_demand_resources.srt ├── 215_hd_whats_new_in_storyboards.srt ├── 216_hd_layout_and_animation_techniques_for_watchkit.srt ├── 217_hd_adopting_new_trackpad_features.srt ├── 218_hd_mysteries_of_auto_layout_part_1.srt ├── 219_hd_mysteries_of_auto_layout_part_2.srt ├── 220_hd_whats_new_in_core_data.srt ├── 221_hd_improving_the_full_screen_window_experience.srt ├── 222_hd_new_uikit_support_for_international_user_interfaces.srt ├── 223_hd_introducing_the_contacts_framework_for_ios_and_os_x.srt ├── 224_hd_app_extension_best_practices.srt ├── 225_hd_whats_new_in_nscollectionview.srt ├── 226_hd_advanced_nsoperations.srt ├── 227_hd_whats_new_in_internationalization.srt ├── 228_hd_watchkit_tips_and_tricks.srt ├── 229_hd_whats_new_in_uikit_dynamics_and_visual_effects.srt ├── 230_hd_performance_on_ios_and_watchos.srt ├── 231_hd_cocoa_touch_best_practices.srt ├── 232_hd_best_practices_for_progress_reporting.srt ├── 233_hd_advanced_touch_input_on_ios.srt ├── 234_hd_building_document_based_apps.srt ├── 301_hd_whats_new_in_managing_apple_devices.srt ├── 302_hd_whats_new_in_itunes_connect.srt ├── 303_hd_getting_the_most_out_of_app_analytics.srt ├── 304_hd_itunes_connect_development_to_distribution.srt ├── 306_hd_supporting_the_enterprise_with_os_x_automation.srt ├── 401_hd_swift_and_objectivec_interoperability.srt ├── 402_hd_whats_new_in_lldb.srt ├── 403_hd_improving_your_existing_apps_with_swift.srt ├── 404_hd_app_thinning_in_xcode.srt ├── 405_hd_authoring_rich_playgrounds.srt ├── 406_hd_ui_testing_in_xcode.srt ├── 407_hd_implementing_ui_designs_in_interface_builder.srt ├── 408_hd_protocoloriented_programming_in_swift.srt ├── 409_hd_optimizing_swift_performance.srt ├── 410_hd_continuous_integration_and_code_coverage_in_xcode.srt ├── 411_hd_swift_in_practice.srt ├── 412_hd_profiling_in_depth.srt ├── 413_hd_advanced_debugging_and_the_address_sanitizer.srt ├── 414_hd_building_better_apps_with_value_types_in_swift.srt ├── 501_hd_whats_new_in_web_development_in_webkit_and_safari.srt ├── 502_hd_content_protection_for_http_live_streaming.srt ├── 503_hd_monetize_and_promote_your_app_with_iad.srt ├── 504_hd_introducing_safari_view_controller.srt ├── 505_hd_using_safari_to_deliver_and_debug_a_responsive_web_design.srt ├── 506_hd_editing_movies_in_av_foundation.srt ├── 507_hd_whats_new_in_core_audio.srt ├── 508_hd_audio_unit_extensions.srt ├── 509_hd_seamless_linking_to_your_app.srt ├── 510_hd_whats_new_in_core_image.srt ├── 511_hd_safari_extensibility_content_blocking_and_shared_links.srt ├── 602_hd_managing_3d_assets_with_model_io.srt ├── 603_hd_whats_new_in_metal_part_1.srt ├── 604_hd_whats_new_in_spritekit.srt ├── 605_hd_going_social_with_replaykit_and_game_center.srt ├── 606_hd_enhancements_to_scenekit.srt ├── 607_hd_whats_new_in_metal_part_2.srt ├── 608_hd_introducing_gameplaykit.srt ├── 609_hd_deeper_into_gameplaykit_with_demobots.srt ├── 610_hd_metal_performance_optimization_techniques.srt ├── 701_hd_wallet__the_home_for_apple_pay_and_more.srt ├── 702_hd_apple_pay_within_apps.srt ├── 703_hd_privacy_and_your_app.srt ├── 704_hd_whats_new_in_cloudkit.srt ├── 705_hd_whats_new_in_core_motion.srt ├── 706_hd_security_and_your_apps.srt ├── 707_hd_achieving_allday_battery_life.srt ├── 708_hd_debugging_energy_issues.srt ├── 709_hd_introducing_search_apis.srt ├── 710_hd_cloudkit_js_and_web_services.srt ├── 711_hd_networking_with_nsurlsession.srt ├── 712_hd_low_energy_high_performance_compression_and_accelerate.srt ├── 713_hd_introducing_watch_connectivity.srt ├── 714_hd_whats_new_in_core_location.srt ├── 715_hd_cloudkit_tips_and_tricks.srt ├── 717_hd_whats_new_in_network_extension_and_vpn.srt ├── 718_hd_building_responsive_and_efficient_apps_with_gcd.srt ├── 719_hd_your_app_and_next_generation_networks.srt ├── 720_hd_whats_new_in_notifications.srt ├── 801_hd_designing_for_future_hardware.srt ├── 802_hd_designing_for_apple_watch.srt ├── 803_hd_designing_with_animation.srt ├── 804_hd_introducing_the_new_system_fonts.srt └── 805_hd_apple_watch_design_tips_and_tricks.srt ├── README.md └── SD ├── 101_sd_keynote.srt ├── 102_sd_platforms_state_of_the_union.srt ├── 103_sd_apple_design_awards.srt ├── 104_sd_whats_new_in_xcode.srt ├── 105_sd_introducing_watchkit_for_watchos_2.srt ├── 106_sd_whats_new_in_swift.srt ├── 107_sd_whats_new_in_cocoa_touch.srt ├── 108_sd_building_watch_apps.srt ├── 201_sd_ios_accessibility.srt ├── 202_sd_whats_new_in_cocoa.srt ├── 203_sd_whats_new_in_healthkit.srt ├── 204_sd_apple_watch_accessibility.srt ├── 205_sd_getting_started_with_multitasking_on_ipad_in_ios_9.srt ├── 206_sd_whats_new_in_mapkit.srt ├── 207_sd_watchkit_indepth_part_1.srt ├── 208_sd_watchkit_indepth_part_2.srt ├── 209_sd_creating_complications_with_clockkit.srt ├── 210_sd_whats_new_in_homekit.srt ├── 211_sd_multitasking_essentials_for_mediabased_apps_on_ipad_in_ios_9.srt ├── 212_sd_optimizing_your_app_for_multitasking_on_ipad_in_ios_9.srt ├── 213_sd_building_apps_with_researchkit.srt ├── 214_sd_introducing_on_demand_resources.srt ├── 215_sd_whats_new_in_storyboards.srt ├── 216_sd_layout_and_animation_techniques_for_watchkit.srt ├── 217_sd_adopting_new_trackpad_features.srt ├── 218_sd_mysteries_of_auto_layout_part_1.srt ├── 219_sd_mysteries_of_auto_layout_part_2.srt ├── 220_sd_whats_new_in_core_data.srt ├── 221_sd_improving_the_full_screen_window_experience.srt ├── 222_sd_new_uikit_support_for_international_user_interfaces.srt ├── 223_sd_introducing_the_contacts_framework_for_ios_and_os_x.srt ├── 224_sd_app_extension_best_practices.srt ├── 225_sd_whats_new_in_nscollectionview.srt ├── 226_sd_advanced_nsoperations.srt ├── 227_sd_whats_new_in_internationalization.srt ├── 228_sd_watchkit_tips_and_tricks.srt ├── 229_sd_whats_new_in_uikit_dynamics_and_visual_effects.srt ├── 230_sd_performance_on_ios_and_watchos.srt ├── 231_sd_cocoa_touch_best_practices.srt ├── 232_sd_best_practices_for_progress_reporting.srt ├── 233_sd_advanced_touch_input_on_ios.srt ├── 234_sd_building_document_based_apps.srt ├── 301_sd_whats_new_in_managing_apple_devices.srt ├── 302_sd_whats_new_in_itunes_connect.srt ├── 303_sd_getting_the_most_out_of_app_analytics.srt ├── 304_sd_itunes_connect_development_to_distribution.srt ├── 306_sd_supporting_the_enterprise_with_os_x_automation.srt ├── 401_sd_swift_and_objectivec_interoperability.srt ├── 402_sd_whats_new_in_lldb.srt ├── 403_sd_improving_your_existing_apps_with_swift.srt ├── 404_sd_app_thinning_in_xcode.srt ├── 405_sd_authoring_rich_playgrounds.srt ├── 406_sd_ui_testing_in_xcode.srt ├── 407_sd_implementing_ui_designs_in_interface_builder.srt ├── 408_sd_protocoloriented_programming_in_swift.srt ├── 409_sd_optimizing_swift_performance.srt ├── 410_sd_continuous_integration_and_code_coverage_in_xcode.srt ├── 411_sd_swift_in_practice.srt ├── 412_sd_profiling_in_depth.srt ├── 413_sd_advanced_debugging_and_the_address_sanitizer.srt ├── 414_sd_building_better_apps_with_value_types_in_swift.srt ├── 501_sd_whats_new_in_web_development_in_webkit_and_safari.srt ├── 502_sd_content_protection_for_http_live_streaming.srt ├── 503_sd_monetize_and_promote_your_app_with_iad.srt ├── 504_sd_introducing_safari_view_controller.srt ├── 505_sd_using_safari_to_deliver_and_debug_a_responsive_web_design.srt ├── 506_sd_editing_movies_in_av_foundation.srt ├── 507_sd_whats_new_in_core_audio.srt ├── 508_sd_audio_unit_extensions.srt ├── 509_sd_seamless_linking_to_your_app.srt ├── 510_sd_whats_new_in_core_image.srt ├── 511_sd_safari_extensibility_content_blocking_and_shared_links.srt ├── 602_sd_managing_3d_assets_with_model_io.srt ├── 603_sd_whats_new_in_metal_part_1.srt ├── 604_sd_whats_new_in_spritekit.srt ├── 605_sd_going_social_with_replaykit_and_game_center.srt ├── 606_sd_enhancements_to_scenekit.srt ├── 607_sd_whats_new_in_metal_part_2.srt ├── 608_sd_introducing_gameplaykit.srt ├── 609_sd_deeper_into_gameplaykit_with_demobots.srt ├── 610_sd_metal_performance_optimization_techniques.srt ├── 701_sd_wallet__the_home_for_apple_pay_and_more.srt ├── 702_sd_apple_pay_within_apps.srt ├── 703_sd_privacy_and_your_app.srt ├── 704_sd_whats_new_in_cloudkit.srt ├── 705_sd_whats_new_in_core_motion.srt ├── 706_sd_security_and_your_apps.srt ├── 707_sd_achieving_allday_battery_life.srt ├── 708_sd_debugging_energy_issues.srt ├── 709_sd_introducing_search_apis.srt ├── 710_sd_cloudkit_js_and_web_services.srt ├── 711_sd_networking_with_nsurlsession.srt ├── 712_sd_low_energy_high_performance_compression_and_accelerate.srt ├── 713_sd_introducing_watch_connectivity.srt ├── 714_sd_whats_new_in_core_location.srt ├── 715_sd_cloudkit_tips_and_tricks.srt ├── 717_sd_whats_new_in_network_extension_and_vpn.srt ├── 718_sd_building_responsive_and_efficient_apps_with_gcd.srt ├── 719_sd_your_app_and_next_generation_networks.srt ├── 720_sd_whats_new_in_notifications.srt ├── 801_sd_designing_for_future_hardware.srt ├── 802_sd_designing_for_apple_watch.srt ├── 803_sd_designing_with_animation.srt ├── 804_sd_introducing_the_new_system_fonts.srt └── 805_sd_apple_watch_design_tips_and_tricks.srt /HD/502_hd_content_protection_for_http_live_streaming.srt: -------------------------------------------------------------------------------- 1 | 1 2 | 00:00:20,020 --> 00:00:21,555 3 | HTTP实时流媒体播放的扩展 4 | 5 | 6 | 2 7 | 00:00:25,425 --> 00:00:26,326 8 | 大家早上好！ 9 | 10 | 11 | 3 12 | 00:00:27,427 --> 00:00:31,098 13 | 欢迎参加今年的全球开发者大会 14 | 15 | 16 | 4 17 | 00:00:31,532 --> 00:00:33,901 18 | 这是您参加的 19 | 第一个真正的讲座环节 20 | 21 | 22 | 5 23 | 00:00:34,601 --> 00:00:35,836 24 | 因此欢迎您！ 25 | 26 | 27 | 6 28 | 00:00:37,137 --> 00:00:39,106 29 | 今天... 30 | 谢谢你 31 | 32 | 33 | 7 34 | 00:00:39,773 --> 00:00:44,411 35 | 今天我们将讨论 36 | HTTP实时流媒体播放的 37 | 38 | 39 | 8 40 | 00:00:44,678 --> 00:00:46,380 41 | 一个非常激动人心的扩展 42 | 43 | 44 | 9 45 | 00:00:47,681 --> 00:00:53,453 46 | 你知道我们一直在关注 47 | 究竟是什么阻止了你们 48 | 49 | 50 | 10 51 | 00:00:53,520 --> 00:00:57,591 52 | 以自己喜欢的方式 53 | 使用HLS来部署内容 54 | 55 | 56 | 11 57 | 00:00:58,292 --> 00:01:00,027 58 | 而内容保护 59 | 60 | 61 | 12 62 | 00:01:00,260 --> 00:01:05,699 63 | 是指让您的用户观看或收听您的内容 64 | 65 | 66 | 13 67 | 00:01:06,400 --> 00:01:08,635 68 | 却不授权使用它 69 | 70 | 71 | 14 72 | 00:01:09,203 --> 00:01:14,308 73 | 一直是一个真正有难度的问题 74 | 你们中的很多人曾经不得不设法应对 75 | 76 | 77 | 15 78 | 00:01:15,075 --> 00:01:18,745 79 | 而且随着比特率的升高 80 | 以及分辨率的上升 81 | 82 | 83 | 16 84 | 00:01:18,912 --> 00:01:20,614 85 | 那些需求将只会增大 86 | 87 | 88 | 17 89 | 00:01:21,481 --> 00:01:27,588 90 | 那也是我为何 91 | 终于能够高兴地宣布 92 | 93 | 94 | 18 95 | 00:01:28,589 --> 00:01:30,390 96 | FairPlay流媒体的诞生 97 | 98 | 99 | 19 100 | 00:01:31,692 --> 00:01:32,626 101 | 那么它是什么？ 102 | 103 | 104 | 20 105 | 00:01:34,394 --> 00:01:40,901 106 | 首先 107 | 它是我们最出色的内容保护技术 108 | 109 | 110 | 21 111 | 00:01:41,101 --> 00:01:46,139 112 | 它的封装方式允许您将其用于 113 | 保护您的HLS内容 114 | 115 | 116 | 22 117 | 00:01:47,140 --> 00:01:48,175 118 | 现在 它已不是新事物了 119 | 120 | 121 | 23 122 | 00:01:48,809 --> 00:01:52,279 123 | 我们在过去三年一直在 124 | 125 | 126 | 24 127 | 00:01:52,880 --> 00:01:55,082 128 | 与一些主要内容合作伙伴进行合作 129 | 130 | 131 | 25 132 | 00:01:55,849 --> 00:01:59,553 133 | 帮助它们在app 134 | 或Apple TV上部署FPS 135 | 136 | 137 | 26 138 | 00:02:00,187 --> 00:02:05,158 139 | 现在它已被用来保护大量的内容 140 | 141 | 142 | 27 143 | 00:02:05,425 --> 00:02:10,597 144 | 包括一些世界上最热门的 145 | 电影和电视节目 146 | 147 | 148 | 28 149 | 00:02:15,836 --> 00:02:21,642 150 | 现在您可以将它用于iOS 151 | 及Apple TV和OS X上 152 | 153 | 154 | 29 155 | 00:02:22,910 --> 00:02:26,513 156 | 当然 157 | 在我们的移动设备上 电池寿命是王道 158 | 159 | 160 | 30 161 | 00:02:27,080 --> 00:02:30,217 162 | 所以当我们设计 163 | FairPlay流媒体的时候 164 | 165 | 166 | 31 167 | 00:02:31,185 --> 00:02:35,656 168 | 我们所做的每个决定都是建立在 169 | 为您实现良好的电池寿命的基础上的 170 | 171 | 172 | 32 173 | 00:02:35,756 --> 00:02:38,759 174 | 我们选择的编解码器 175 | 我们选择的加密技术 176 | 177 | 178 | 33 179 | 00:02:39,092 --> 00:02:41,929 180 | 我们的实施方式 181 | 甚至我们利用的硬件 182 | 183 | 184 | 34 185 | 00:02:42,329 --> 00:02:45,632 186 | 所以您会有极大的安全性 187 | 也会有很好的电池寿命 188 | 189 | 190 | 35 191 | 00:02:47,000 --> 00:02:52,806 192 | 而且它也与AirPlay无缝集成 193 | 因此它会伴随全面的保护 194 | 195 | 196 | 36 197 | 00:02:54,141 --> 00:02:57,945 198 | 不过您可能会说： 199 | “好吧 那听上去很不错 200 | 201 | 202 | 37 203 | 00:02:58,412 --> 00:02:59,546 204 | 但是我有很多内容 205 | 206 | 207 | 38 208 | 00:02:59,680 --> 00:03:04,251 209 | 我的意思是Apple 210 | 将如何让我为这个FPS付费？ 211 | 212 | 213 | 39 214 | 00:03:04,318 --> 00:03:07,454 215 | 它将是按照影片收费？ 216 | 按每次播放还是统一价格？” 217 | 218 | 219 | 40 220 | 00:03:08,722 --> 00:03:12,326 221 | 我们反复尝试 222 | 最后我们确定采用统一价格 223 | 224 | 225 | 41 226 | 00:03:13,794 --> 00:03:14,628 227 | 零 228 | 229 | 230 | 42 231 | 00:03:15,996 --> 00:03:19,800 232 | 如果大家每年向我们 233 | 支付99美元的开发者费用 234 | 235 | 236 | 43 237 | 00:03:20,100 --> 00:03:24,838 238 | 您将不必再向苹果公司支付一分钱 239 | 就能尽情使用FPS 240 | 241 | 242 | 44 243 | 00:03:26,240 --> 00:03:31,645 244 | 那么现在 观众中间任何从事 245 | 市场营销的朋友可能会说这样的话： 246 | 247 | 248 | 45 249 | 00:03:31,712 --> 00:03:33,146 250 | “哦 那听上去棒极了！” 251 | 252 | 253 | 46 254 | 00:03:33,480 --> 00:03:36,483 255 | 而坐你旁边的工程师可能会说： 256 | “不 不 真的吗？ 它是什么？” 257 | 258 | 259 | 47 260 | 00:03:36,850 --> 00:03:37,784 261 | 好了 那么 262 | 263 | 264 | 48 265 | 00:03:38,352 --> 00:03:41,121 266 | 它实际上是非常简单的 267 | 268 | 269 | 49 270 | 00:03:41,922 --> 00:03:46,326 271 | 我们所做的就是着手解决了DRM系统 272 | 273 | 274 | 50 275 | 00:03:46,393 --> 00:03:48,962 276 | 最重要的组成部分 即密钥保护 277 | 278 | 279 | 51 280 | 00:03:49,963 --> 00:03:55,335 281 | 那么FPS在本质上及实际上是一个 282 | 安全的密钥传送系统 283 | 284 | 285 | 52 286 | 00:03:55,669 --> 00:03:59,006 287 | 它是一种将密钥 288 | 从您在互联网上的服务器 289 | 290 | 291 | 53 292 | 00:03:59,473 --> 00:04:01,775 293 | 转移到设备上的方式 294 | 295 | 296 | 54 297 | 00:04:02,543 --> 00:04:07,648 298 | 让您在该设备上使用密钥 299 | 同时不让攻击者获取它并解密您的内容 300 | 301 | 302 | 55 303 | 00:04:08,849 --> 00:04:12,920 304 | 在设计方面 305 | 我们让它容易使用和采用 306 | 307 | 308 | 56 309 | 00:04:13,487 --> 00:04:15,822 310 | 我们认识到你们中的很多人 311 | 312 | 313 | 57 314 | 00:04:15,889 --> 00:04:20,360 315 | 尤其是当您以流媒体提供 316 | 高级内容或订阅内容时 317 | 318 | 319 | 58 320 | 00:04:20,427 --> 00:04:22,963 321 | 您已经在与某种安全后端对话了 322 | 323 | 324 | 59 325 | 00:04:23,664 --> 00:04:26,233 326 | 因此我们设计了FPS 327 | 328 | 329 | 60 330 | 00:04:26,300 --> 00:04:30,003 331 | 让传送这部分工作成为不可知 332 | 让您使用的协议成为隐蔽 333 | 334 | 335 | 61 336 | 00:04:30,070 --> 00:04:34,842 337 | 如果您拥有安全连接 338 | 您可以极其容易地采用FPS 339 | 340 | 341 | 62 342 | 00:04:35,342 --> 00:04:37,878 343 | 如果没有 你也可以使用HTTPS 344 | 它是一个很不错的选择 345 | 346 | 347 | 63 348 | 00:04:39,346 --> 00:04:42,683 349 | 最后 过去很多朋友 350 | 问我关于HDCP方面的事情 351 | 352 | 353 | 64 354 | 00:04:43,250 --> 00:04:45,586 355 | FPS就是这个问题的答案 356 | 357 | 358 | 65 359 | 00:04:46,987 --> 00:04:51,992 360 | 如果您的设备连接了电视 361 | 或其他外部输入 362 | 363 | 364 | 66 365 | 00:04:52,593 --> 00:04:54,094 366 | 它一定是HDMI 367 | 368 | 369 | 67 370 | 00:04:54,661 --> 00:04:56,763 371 | 而HDCP一定是活跃的 372 | 373 | 374 | 68 375 | 00:04:57,164 --> 00:05:00,400 376 | 否则任何FPS内容播放都会失败 377 | 378 | 379 | 69 380 | 00:05:01,235 --> 00:05:02,135 381 | 没有例外 382 | 383 | 384 | 70 385 | 00:05:04,204 --> 00:05:07,207 386 | 当我们设计它的时候 387 | 388 | 389 | 71 390 | 00:05:07,708 --> 00:05:13,013 391 | 我们知道有很多商业规则或逻辑的区别 392 | 而每个人都有自己的口味 393 | 394 | 395 | 72 396 | 00:05:13,080 --> 00:05:15,382 397 | 而我们不希望 398 | 建立一个庞大而复杂的东西 399 | 400 | 401 | 73 402 | 00:05:15,749 --> 00:05:17,284 403 | 并迫使你们进入我们的盒子 404 | 405 | 406 | 74 407 | 00:05:17,784 --> 00:05:21,255 408 | 所以我们建立了 409 | 这个密钥传送机制 410 | 411 | 412 | 75 413 | 00:05:21,722 --> 00:05:25,259 414 | 我们并不是创建了一种 415 | 权利表达语言评估工具 416 | 417 | 418 | 76 419 | 00:05:25,325 --> 00:05:28,695 420 | 或者是一长串您需要遵守的策略 421 | 422 | 423 | 77 424 | 00:05:29,363 --> 00:05:33,667 425 | 而那意味着 426 | 如果您的商业逻辑要求那些东西 427 | 428 | 429 | 78 430 | 00:05:33,734 --> 00:05:35,936 431 | 您是可以掌控的 432 | 您依然是守门员 433 | 434 | 435 | 79 436 | 00:05:36,470 --> 00:05:39,273 437 | 因此 一旦您为媒体堆栈 438 | 赋予了一个FPS密钥 439 | 440 | 441 | 80 442 | 00:05:39,339 --> 00:05:40,774 443 | 毫无问题 444 | 我们将播放它 445 | 446 | 447 | 81 448 | 00:05:40,841 --> 00:05:42,376 449 | 我们将保护密钥 450 | 我们将去播放它 451 | 452 | 453 | 82 454 | 00:05:43,076 --> 00:05:46,146 455 | 如果您需要实施某种策略实施 456 | 457 | 458 | 83 459 | 00:05:46,246 --> 00:05:50,751 460 | 或进行用户认证 461 | 或对每个设备插槽进行管理 462 | 463 | 464 | 84 465 | 00:05:51,151 --> 00:05:53,987 466 | 那么您就可以在FPS上那么做 467 | 468 | 469 | 85 470 | 00:05:54,421 --> 00:05:57,224 471 | 而且它将是非常容易整合的 472 | 473 | 474 | 86 475 | 00:05:58,458 --> 00:06:00,694 476 | 那么现在让我们讨论一些具体步骤 477 | 478 | 479 | 87 480 | 00:06:01,161 --> 00:06:03,096 481 | 那就是FPS为您提供的基本功能 482 | 483 | 484 | 88 485 | 00:06:03,430 --> 00:06:06,200 486 | 让我们讨论一下 487 | 您采用它需要采取的步骤 488 | 489 | 490 | 89 491 | 00:06:07,467 --> 00:06:09,002 492 | 主要有三步 493 | 494 | 495 | 90 496 | 00:06:09,603 --> 00:06:12,039 497 | 第一步 498 | 也极可能是最重要的一步是 499 | 500 | 501 | 91 502 | 00:06:12,372 --> 00:06:15,709 503 | 由于FPS是一个在线密钥传送协议 504 | 505 | 506 | 92 507 | 00:06:16,343 --> 00:06:20,447 508 | 您必须在线获取您的密钥 509 | 而一旦播放停止密钥即消失 510 | 511 | 512 | 93 513 | 00:06:21,248 --> 00:06:26,386 514 | 您需要把我们所谓的“密钥安全模块” 515 | 集成到您的密钥服务器中 516 | 517 | 518 | 94 519 | 00:06:27,421 --> 00:06:31,024 520 | 因此那是最重大的一步 521 | 稍后我们将详细讨论那个话题 522 | 523 | 524 | 95 525 | 00:06:31,692 --> 00:06:35,462 526 | 但是第二件事情是 527 | 您需向您的应用添加一些代码 528 | 529 | 530 | 96 531 | 00:06:36,029 --> 00:06:39,166 532 | 称为AV Asset Resource Loader Delegate 533 | 534 | 535 | 97 536 | 00:06:39,766 --> 00:06:45,372 537 | 那段代码负责将来自 538 | AV Foundation的密钥请求传送到后端 539 | 540 | 541 | 98 542 | 00:06:45,706 --> 00:06:49,610 543 | 然后将您后端发出的响应 544 | 并返回给AV Foundation 545 | 546 | 547 | 99 548 | 00:06:50,310 --> 00:06:52,513 549 | 最后您需要做的是准备您的内容 550 | 551 | 552 | 100 553 | 00:06:52,579 --> 00:06:57,784 554 | 而那意味着您需要 555 | 使用AES示例加密法将其加密 556 | 557 | 558 | 101 559 | 00:06:58,085 --> 00:07:03,290 560 | 巧的是 这是我们三年前引入的 561 | 562 | 563 | 102 564 | 00:07:04,558 --> 00:07:10,864 565 | 因此与最初HLS使用的传统 566 | 整段代码加密不同的是 567 | 568 | 569 | 103 570 | 00:07:11,098 --> 00:07:14,168 571 | 这种加密法仅加密 572 | 每段示例代码中小的片段 573 | 574 | 575 | 104 576 | 00:07:14,434 --> 00:07:19,106 577 | 这确保了我们能够 578 | 在系统基本水平上进行解密工作 579 | 580 | 581 | 105 582 | 00:07:20,140 --> 00:07:22,476 583 | 因此您需要选择一个内容密钥 584 | 585 | 586 | 106 587 | 00:07:22,543 --> 00:07:24,111 588 | 将其存放在您的后端数据库内 589 | 590 | 591 | 107 592 | 00:07:24,411 --> 00:07:25,479 593 | 对您的内容进行加密 594 | 595 | 596 | 108 597 | 00:07:25,746 --> 00:07:28,649 598 | 然后将对那个密钥的引用加入播放列表 599 | 600 | 601 | 109 602 | 00:07:28,882 --> 00:07:31,652 603 | 以便当您的那小段代码 604 | 接到对密钥的请求时 605 | 606 | 607 | 110 608 | 00:07:31,718 --> 00:07:33,854 609 | 能够知道向后端请求哪个密钥 610 | 611 | 612 | 111 613 | 00:07:35,155 --> 00:07:40,928 614 | 那么我接下来将要做的 615 | 是进一步详述这三个步骤 616 | 617 | 618 | 112 619 | 00:07:41,328 --> 00:07:45,465 620 | 在那之前 我想介绍我的一位同事 621 | 622 | 623 | 113 624 | 00:07:45,799 --> 00:07:47,434 625 | 他是FairPlay团队成员之一 626 | 627 | 628 | 114 629 | 00:07:47,734 --> 00:07:48,936 630 | 詹保罗 法索里 631 | 632 | 633 | 115 634 | 00:07:50,070 --> 00:07:50,904 635 | 欢迎！ 636 | 637 | 638 | 116 639 | 00:07:56,143 --> 00:07:57,044 640 | 谢谢你 罗哲斯！ 641 | 642 | 643 | 117 644 | 00:07:58,145 --> 00:08:00,214 645 | 大家早上好！ 646 | 我叫詹保罗 法索里 647 | 648 | 649 | 118 650 | 00:08:00,280 --> 00:08:02,783 651 | 是Apple的FPS工程师 652 | 653 | 654 | 119 655 | 00:08:03,684 --> 00:08:06,753 656 | 继罗哲斯所做的概述 657 | 我想跟大家谈一下 658 | 659 | 660 | 120 661 | 00:08:06,820 --> 00:08:09,256 662 | 设计一个FPS系统需要些什么 663 | 664 | 665 | 121 666 | 00:08:09,323 --> 00:08:10,791 667 | 我想讲的第一件事 668 | 669 | 670 | 122 671 | 00:08:11,291 --> 00:08:17,631 672 | 是我们所谓的FairPlay流媒体 673 | 证书的目的和重要性 674 | 675 | 676 | 123 677 | 00:08:18,365 --> 00:08:23,270 678 | 接下来 679 | 我将识别系统和数据流中的活动要素 680 | 681 | 682 | 124 683 | 00:08:24,638 --> 00:08:27,975 684 | 然后我将讨论苹果公司将在您 685 | 构建的东西中会提供哪些东西 686 | 687 | 688 | 125 689 | 00:08:28,041 --> 00:08:31,144 690 | 而在您将构建的东西中 691 | 我们将先从服务器端讲起 692 | 693 | 694 | 126 695 | 00:08:31,211 --> 00:08:36,683 696 | 以及如何将Roger刚才所讲的 697 | 密钥安全模块集成到您的密钥服务器中 698 | 699 | 700 | 127 701 | 00:08:37,217 --> 00:08:39,586 702 | 我们将讨论如何测试集成 703 | 704 | 705 | 128 706 | 00:08:40,254 --> 00:08:45,492 707 | 接下来我们将讨论客户端 708 | 以及如何将FPS集成到您的应用中 709 | 710 | 711 | 129 712 | 00:08:45,559 --> 00:08:52,232 713 | 然后我们将讨论 714 | 您将对内容制作工作流的更新 715 | 716 | 717 | 130 718 | 00:08:52,966 --> 00:08:57,337 719 | 以便将内容加密 并确认 720 | 您将对工作流的更改 721 | 722 | 723 | 131 724 | 00:08:59,239 --> 00:09:02,910 725 | 那么当我们讨论FPS证书的时候 726 | 727 | 728 | 132 729 | 00:09:03,010 --> 00:09:05,946 730 | 我们有那些证书是为了 731 | 732 | 733 | 133 734 | 00:09:06,013 --> 00:09:12,519 735 | 能够将您的FPS部署 736 | 和那里已经存在的部署区分开来 737 | 738 | 739 | 134 740 | 00:09:13,053 --> 00:09:16,290 741 | 之所以需要它们是因为有了它们 742 | 743 | 744 | 135 745 | 00:09:16,356 --> 00:09:20,494 746 | 您的客户才可以在他们的设备上 747 | 实际播放他们的内容 748 | 749 | 750 | 136 751 | 00:09:21,929 --> 00:09:27,968 752 | 出于这些原因 753 | 保护FPS证书资产资源就十分重要了 754 | 755 | 756 | 137 757 | 00:09:28,202 --> 00:09:30,204 758 | 不管是当它们被部署在服务器上 759 | 760 | 761 | 138 762 | 00:09:30,270 --> 00:09:31,505 763 | 还是在您的服务器上被使用 764 | 765 | 766 | 139 767 | 00:09:32,306 --> 00:09:33,674 768 | 要确保它们得到保护 769 | 770 | 771 | 140 772 | 00:09:34,641 --> 00:09:40,380 773 | 那么现在继续往下看图表 774 | 左边我们已经有了服务器组件 775 | 776 | 777 | 141 778 | 00:09:40,681 --> 00:09:42,216 779 | 也就是您的密钥服务器 780 | 781 | 782 | 142 783 | 00:09:42,316 --> 00:09:46,119 784 | 它内部已经集成了FPS密钥安全模块 785 | 786 | 787 | 143 788 | 00:09:46,854 --> 00:09:51,458 789 | 密钥数据库里面含有 790 | 用来为您的流媒体加密内容密钥值 791 | 792 | 793 | 144 794 | 00:09:51,725 --> 00:09:56,029 795 | 而在右边我们有客户端活动要素 796 | 即是您的应用 797 | 798 | 799 | 145 800 | 00:09:56,396 --> 00:09:59,600 801 | 罗哲斯刚才讲的 802 | AVFoundation Delegate和AVFoundation 803 | 804 | 805 | 146 806 | 00:09:59,666 --> 00:10:03,470 807 | 已经为我们提供了部分操作系统 808 | 即我们的iOS或Mac OS X 809 | 810 | 811 | 147 812 | 00:10:04,938 --> 00:10:09,176 813 | 那么让我们讨论一下 当用户在您的 814 | 应用中点击播放的时候会发生什么 815 | 816 | 817 | 148 818 | 00:10:09,243 --> 00:10:10,544 819 | 第一件会发生的事情是 820 | 821 | 822 | 149 823 | 00:10:11,011 --> 00:10:13,514 824 | 您的应用将调用AVFoundation 825 | 826 | 827 | 150 828 | 00:10:13,580 --> 00:10:16,683 829 | 并为其提供即将赋予 830 | 加密内容的m3u8 URL 831 | 832 | 833 | 151 834 | 00:10:17,184 --> 00:10:21,288 835 | AVFoundation将从互联网 836 | 抽取那个播放列表并对其进行解析 837 | 838 | 839 | 152 840 | 00:10:21,655 --> 00:10:23,790 841 | 当它注意到内容被加密的时候 842 | 843 | 844 | 153 845 | 00:10:23,857 --> 00:10:28,028 846 | 它将回调您的Delegate 847 | 告诉它需要一个密钥以便播放内容 848 | 849 | 850 | 154 851 | 00:10:29,196 --> 00:10:32,299 852 | Delegate将进行处理 853 | 它将调入AVFoundation 854 | 855 | 856 | 155 857 | 00:10:32,366 --> 00:10:37,070 858 | 并请求后者创建 859 | 所谓的服务器上下文播放 860 | 861 | 862 | 156 863 | 00:10:37,971 --> 00:10:40,841 864 | 在FPS术语中 865 | 我们将其简称为SPC 866 | 867 | 868 | 157 869 | 00:10:40,908 --> 00:10:41,942 870 | 而那是什么？ 871 | 872 | 873 | 158 874 | 00:10:42,209 --> 00:10:47,414 875 | 它是一个Delegate的密钥请求 876 | 它将用post方法提交给密钥服务器 877 | 878 | 879 | 159 880 | 00:10:48,248 --> 00:10:51,818 881 | 以便完成其工作并传递内容密钥 882 | 883 | 884 | 160 885 | 00:10:52,186 --> 00:10:53,921 886 | 这里需要注意的重要一点是 887 | 888 | 889 | 161 890 | 00:10:54,321 --> 00:11:01,061 891 | SPC是在客户端上的 892 | FPS传递上下文中创建的 893 | 894 | 895 | 162 896 | 00:11:01,495 --> 00:11:03,964 897 | 而那是一个特定会话上下文 898 | 899 | 900 | 163 901 | 00:11:05,098 --> 00:11:07,734 902 | 只有那台设备能够创建它 903 | 904 | 905 | 164 906 | 00:11:07,801 --> 00:11:11,905 907 | 也只有那台设备能够为其处理 908 | 来自于服务器的响应 909 | 910 | 911 | 165 912 | 00:11:11,972 --> 00:11:13,807 913 | 它是和设备以及会话绑定的 914 | 915 | 916 | 166 917 | 00:11:14,675 --> 00:11:18,212 918 | 因此当您的服务器准备利用KSM 919 | 920 | 921 | 167 922 | 00:11:18,645 --> 00:11:24,351 923 | 来破解SPC队列请求 924 | 对其格式和加密方法进行验证 925 | 926 | 927 | 168 928 | 00:11:24,718 --> 00:11:27,888 929 | 并在密钥服务器数据库中 930 | 查找对应的内容密钥时 931 | 932 | 933 | 169 934 | 00:11:28,589 --> 00:11:34,828 935 | 它将把那个内容密钥值 936 | 打包为我们所称的内容密钥上下文 937 | 938 | 939 | 170 940 | 00:11:35,162 --> 00:11:36,530 941 | 或简称为CKC 942 | 943 | 944 | 171 945 | 00:11:37,164 --> 00:11:40,634 946 | 而您的app delegate 947 | 将要执行的最后一步是 948 | 949 | 950 | 172 951 | 00:11:40,701 --> 00:11:43,504 952 | 将那个CKC 953 | 返回给AVFoundation 954 | 955 | 956 | 173 957 | 00:11:44,471 --> 00:11:48,942 958 | 那么此刻设备已经有了 959 | 它对内容的解密和播放所需要的一切 960 | 961 | 962 | 174 963 | 00:11:49,643 --> 00:11:53,947 964 | 那么现在我们已经谈及了FP系统中的 965 | 活动要素和数据流 966 | 967 | 968 | 175 969 | 00:11:54,014 --> 00:11:55,816 970 | 让我们谈一下Apple将供哪些东西 971 | 972 | 973 | 176 974 | 00:11:56,984 --> 00:11:58,785 975 | 当然我们提供AVFoundation 976 | 977 | 978 | 177 979 | 00:11:58,852 --> 00:12:03,023 980 | 在iOS和Mac OS中 981 | AVFoundation的一部分是 982 | 983 | 984 | 178 985 | 00:12:03,090 --> 00:12:05,726 986 | 您将用于执行delegate的API 987 | 988 | 989 | 179 990 | 00:12:06,527 --> 00:12:09,730 991 | 我们提供的另一个工具是 992 | developer.apple.com上的 993 | 994 | 995 | 180 996 | 00:12:09,863 --> 00:12:11,865 997 | FairPlay Streaming SDK 998 | 999 | 1000 | 181 1001 | 00:12:11,932 --> 00:12:13,834 1002 | 那个SDK包含一些特定的内容 1003 | 1004 | 1005 | 182 1006 | 00:12:13,901 --> 00:12:17,504 1007 | 首先它包含一个协议规范 1008 | 1009 | 1010 | 183 1011 | 00:12:18,005 --> 00:12:22,709 1012 | 里面有关于SPC和CKC消息 1013 | 编写格式的全部详细信息 1014 | 1015 | 1016 | 184 1017 | 00:12:23,110 --> 00:12:29,783 1018 | 和您将使用哪些加密原函数 1019 | 来处理密钥请求 及生成密钥响应 1020 | 1021 | 1022 | 185 1023 | 00:12:30,651 --> 00:12:36,757 1024 | 它包含一个在网络控制中心的 1025 | 对密钥安全模块服务器的引用实施 1026 | 1027 | 1028 | 186 1029 | 00:12:37,824 --> 00:12:43,664 1030 | 它包含一整套能够用于服务器部署的 1031 | 服务器测试矢量和验证工具 1032 | 1033 | 1034 | 187 1035 | 00:12:44,398 --> 00:12:47,334 1036 | 它包含一些客户端示例内容 1037 | 1038 | 1039 | 188 1040 | 00:12:48,902 --> 00:12:54,842 1041 | 而它包含的最后一点内容是 1042 | 一套客户端示例代码 1043 | 1044 | 1045 | 189 1046 | 00:12:56,376 --> 00:13:01,982 1047 | 因此如罗哲斯指出的 1048 | 密钥服务器的首要职责是加密 1049 | 1050 | 1051 | 190 1052 | 00:13:02,149 --> 00:13:05,018 1053 | 以及对SPC密钥请求的验证 1054 | 1055 | 1056 | 191 1057 | 00:13:05,619 --> 00:13:10,457 1058 | 然后它将根据资源识别符 1059 | 查找客户希望播放的内容 1060 | 1061 | 1062 | 192 1063 | 00:13:10,824 --> 00:13:13,193 1064 | 然后它将生成CKC响应 1065 | 1066 | 1067 | 193 1068 | 00:13:13,260 --> 00:13:15,262 1069 | 它是您的密钥安全模块中 1070 | 1071 | 1072 | 194 1073 | 00:13:15,329 --> 00:13:17,197 1074 | 将发生的第一个和第三个操作 1075 | 1076 | 1077 | 195 1078 | 00:13:18,165 --> 00:13:21,335 1079 | 您有两种执行该操作的方式 1080 | 1081 | 1082 | 196 1083 | 00:13:21,401 --> 00:13:23,837 1084 | 您可以使用FPS SDK中 1085 | 提供的协议规范 1086 | 1087 | 1088 | 197 1089 | 00:13:23,904 --> 00:13:27,841 1090 | 从零开始执行这个逻辑系统 1091 | 1092 | 1093 | 198 1094 | 00:13:28,542 --> 00:13:33,447 1095 | 或者您也可以直接采用C参考实施 1096 | 1097 | 1098 | 199 1099 | 00:13:33,514 --> 00:13:36,950 1100 | 并通过您自己选择的语言 1101 | 1102 | 1103 | 200 1104 | 00:13:37,017 --> 00:13:40,654 1105 | 或直接将其集成到现有密钥服务器中 1106 | 而对其进行定制化处理 1107 | 1108 | 1109 | 201 1110 | 00:13:42,356 --> 00:13:45,726 1111 | 那么在执行完集成之后 1112 | 让我们谈一谈您将如何测试KSM 1113 | 1114 | 1115 | 202 1116 | 00:13:46,894 --> 00:13:48,695 1117 | 我们建议您做的第一件事当然是 1118 | 1119 | 1120 | 203 1121 | 00:13:48,762 --> 00:13:51,498 1122 | 使用我们提供 1123 | 作为SDK一部分的测试矢量 1124 | 1125 | 1126 | 204 1127 | 00:13:51,965 --> 00:13:55,202 1128 | 来验证KSM将生成的响应的正确性 1129 | 1130 | 1131 | 205 1132 | 00:13:55,269 --> 00:14:01,074 1133 | 而您执行此步骤的方式 1134 | 是使用我们提供的SPC测试矢量 1135 | 1136 | 1137 | 206 1138 | 00:14:01,508 --> 00:14:04,144 1139 | 将它们提供给KSM执行 1140 | 1141 | 1142 | 207 1143 | 00:14:04,545 --> 00:14:08,048 1144 | 然后运行由KSM通过验证工具 1145 | 产生并输出的CKC 1146 | 1147 | 1148 | 208 1149 | 00:14:08,415 --> 00:14:14,488 1150 | 以确保它们不管从加密的角度 1151 | 或格式的角度都是正确的 1152 | 1153 | 1154 | 209 1155 | 00:14:15,522 --> 00:14:16,390 1156 | 需要注意的是 1157 | 1158 | 1159 | 210 1160 | 00:14:16,456 --> 00:14:20,694 1161 | 我们在SDK中提供的测试矢量 1162 | 是基于开发专用凭证的 1163 | 1164 | 1165 | 211 1166 | 00:14:20,761 --> 00:14:24,264 1167 | 它们是专为您的开发工作而存在的 1168 | 1169 | 1170 | 212 1171 | 00:14:24,331 --> 00:14:28,569 1172 | 它们不可被用于向活跃的客户设备 1173 | 部署解决方案 1174 | 1175 | 1176 | 213 1177 | 00:14:28,635 --> 00:14:32,639 1178 | 为了向活跃的客户设备部署解决方案 1179 | 您将需要专用于生产目的的FPS凭证 1180 | 1181 | 1182 | 214 1183 | 00:14:33,373 --> 00:14:36,577 1184 | 那么既然我们已经谈了服务器端 1185 | 让我们谈谈客户端 1186 | 1187 | 1188 | 215 1189 | 00:14:36,643 --> 00:14:39,346 1190 | 将FPS集成到您的应用中 1191 | 需要些什么呢？ 1192 | 1193 | 1194 | 216 1195 | 00:14:39,413 --> 00:14:40,347 1196 | 您应做的第一件事是 1197 | 1198 | 1199 | 217 1200 | 00:14:40,414 --> 00:14:44,518 1201 | 用AVAsset注册一个 1202 | AVasset Resource Loader delegate 1203 | 1204 | 1205 | 218 1206 | 00:14:44,685 --> 00:14:48,388 1207 | 而那个delegate的职责 1208 | 有三个方面 1209 | 1210 | 1211 | 219 1212 | 00:14:48,455 --> 00:14:50,991 1213 | 首先它要做的是生成SPC 1214 | 1215 | 1216 | 220 1217 | 00:14:51,291 --> 00:14:53,660 1218 | 这需要通过以下两步完成 1219 | 1220 | 1221 | 221 1222 | 00:14:53,727 --> 00:14:54,828 1223 | 首先您将为密钥请求处理 1224 | 1225 | 1226 | 222 1227 | 00:14:55,162 --> 00:14:56,330 1228 | “should Wait For 1229 | Loading 1230 | 1231 | 1232 | 223 1233 | 00:14:56,396 --> 00:14:59,032 1234 | Of Requested 1235 | Resource”命令 1236 | 1237 | 1238 | 224 1239 | 00:14:59,099 --> 00:15:00,267 1240 | 然后您将做的第二步是调用 1241 | 1242 | 1243 | 225 1244 | 00:15:00,334 --> 00:15:02,836 1245 | “VAsset Resource 1246 | Loading Request 1247 | 1248 | 1249 | 226 1250 | 00:15:02,903 --> 00:15:04,972 1251 | Streaming Content 1252 | Key Request Data 1253 | 1254 | 1255 | 227 1256 | 00:15:05,038 --> 00:15:06,240 1257 | For App” 1258 | 1259 | 1260 | 228 1261 | 00:15:06,306 --> 00:15:07,875 1262 | 以便生成SPC 1263 | 1264 | 1265 | 229 1266 | 00:15:08,842 --> 00:15:11,912 1267 | 一旦您获得了那个 SPC 1268 | 您将把它传送给您的密钥服务器 1269 | 1270 | 1271 | 230 1272 | 00:15:12,379 --> 00:15:14,248 1273 | 而当您的密钥服务器做出响应时 1274 | 1275 | 1276 | 231 1277 | 00:15:14,314 --> 00:15:15,582 1278 | 您将把CKC响应提供给 1279 | 1280 | 1281 | 232 1282 | 00:15:15,649 --> 00:15:17,551 1283 | “AVAsset Resource 1284 | Loading Request” 1285 | 1286 | 1287 | 233 1288 | 00:15:18,452 --> 00:15:21,588 1289 | 那么我们就完成了服务器端的执行 1290 | 也完成了客户端的执行 1291 | 1292 | 1293 | 234 1294 | 00:15:21,655 --> 00:15:25,025 1295 | 让我们谈一谈工作流更新中内容制作 1296 | 1297 | 1298 | 235 1299 | 00:15:25,692 --> 00:15:28,128 1300 | 为了将内容解密您将必须做些什么？ 1301 | 1302 | 1303 | 236 1304 | 00:15:28,195 --> 00:15:29,363 1305 | 您应做的第一件事是 1306 | 1307 | 1308 | 237 1309 | 00:15:29,429 --> 00:15:33,367 1310 | 去从developer.apple.com 1311 | 获取HLS加密规范 1312 | 1313 | 1314 | 238 1315 | 00:15:33,700 --> 00:15:35,636 1316 | 不管比特流是音频还是视频 1317 | 1318 | 1319 | 239 1320 | 00:15:35,702 --> 00:15:39,706 1321 | 它将为您提供您需要了解的 1322 | 对比特流本身加密的所有细节 1323 | 1324 | 1325 | 240 1326 | 00:15:41,275 --> 00:15:45,612 1327 | 一旦您对比特流加密后 1328 | 您将必须更新m3u8播放列表 1329 | 1330 | 1331 | 241 1332 | 00:15:45,679 --> 00:15:47,981 1333 | 首先您采用的是何种加密方式 1334 | 1335 | 1336 | 242 1337 | 00:15:48,048 --> 00:15:50,484 1338 | 这是通过 1339 | 将m3u8列表中的Method标签 1340 | 1341 | 1342 | 243 1343 | 00:15:50,951 --> 00:15:53,420 1344 | 设为Sample-AES而实现的 1345 | 1346 | 1347 | 244 1348 | 00:15:54,655 --> 00:15:57,491 1349 | 您应向客户端发送的另一个信号是 1350 | 1351 | 1352 | 245 1353 | 00:15:57,558 --> 00:15:59,993 1354 | 您希望用FPS来传递密钥的事实 1355 | 1356 | 1357 | 246 1358 | 00:16:00,060 --> 00:16:05,465 1359 | 实现的方式则是对m3u8播放列表中 1360 | 的另一个标签即密钥格式标签进行更新 1361 | 1362 | 1363 | 247 1364 | 00:16:05,532 --> 00:16:07,835 1365 | 应把它设为 1366 | com.apple.streamingkeydelivery 1367 | 1368 | 1369 | 248 1370 | 00:16:10,270 --> 00:16:12,539 1371 | 事实上我们三年多前就开始部署了 1372 | 1373 | 1374 | 249 1375 | 00:16:12,606 --> 00:16:16,844 1376 | 这意味着目前在解码器方面 1377 | 有相当多的第三方支持 1378 | 1379 | 1380 | 250 1381 | 00:16:16,910 --> 00:16:22,349 1382 | 您可以选择搭配其中之一作为替代 1383 | 而不是您亲自更新工作流 1384 | 1385 | 1386 | 251 1387 | 00:16:23,417 --> 00:16:25,085 1388 | 一旦您更新了您的工作流 1389 | 1390 | 1391 | 252 1392 | 00:16:25,319 --> 00:16:29,389 1393 | 这里是您如何检查 1394 | 加密工作流的正确性的方法 1395 | 1396 | 1397 | 253 1398 | 00:16:30,490 --> 00:16:33,894 1399 | 您大体上可以做两个比较 1400 | 1401 | 1402 | 254 1403 | 00:16:35,062 --> 00:16:36,563 1404 | 但它们都是以同样的方式开始的 1405 | 1406 | 1407 | 255 1408 | 00:16:36,630 --> 00:16:39,633 1409 | 开始时先从 1410 | 示例SDK选取一段明文内容 1411 | 1412 | 1413 | 256 1414 | 00:16:40,000 --> 00:16:43,971 1415 | 并使其运行通过您的新工作流 1416 | 1417 | 1418 | 257 1419 | 00:16:44,771 --> 00:16:50,911 1420 | 然后将其与SDK中相同加密资源对比 1421 | 1422 | 1423 | 258 1424 | 00:16:51,578 --> 00:16:57,351 1425 | 也可将其与在HLS媒体文件切割 1426 | 工具上通过的该资源加密版本进行比较 1427 | 1428 | 1429 | 259 1430 | 00:16:57,651 --> 00:17:00,921 1431 | 之所以第二点比较有意思有吸引力 1432 | 是因为您也可以使用自己的内容 1433 | 1434 | 1435 | 260 1436 | 00:17:00,988 --> 00:17:02,489 1437 | 而不是示例内容完成检查工作 1438 | 1439 | 1440 | 261 1441 | 00:17:03,857 --> 00:17:05,425 1442 | 那么现在我们已经讨论了 1443 | 1444 | 1445 | 262 1446 | 00:17:05,492 --> 00:17:09,630 1447 | 客户端开发和服务器端开发所需的工作 1448 | 以及对您的工作流的更新 1449 | 1450 | 1451 | 263 1452 | 00:17:10,564 --> 00:17:12,566 1453 | 接下来我们讨论功能性本地回放 1454 | 1455 | 1456 | 264 1457 | 00:17:12,633 --> 00:17:15,636 1458 | 现在我想很大家谈谈 1459 | AirPlay中对FPS的支持 1460 | 1461 | 1462 | 265 1463 | 00:17:17,069 --> 00:17:23,443 1464 | 我们对FPS和AirPlay的支持 1465 | 是通过AirPlay视频路径实现的 1466 | 1467 | 1468 | 266 1469 | 00:17:23,810 --> 00:17:29,816 1470 | 就是说当您从应用中的 1471 | 本地回放过渡到Apple TV时 1472 | 1473 | 1474 | 267 1475 | 00:17:30,384 --> 00:17:34,421 1476 | 实际上是Apple TV 1477 | 从互联网上读取内容 是吗？ 1478 | 1479 | 1480 | 268 1481 | 00:17:34,488 --> 00:17:36,757 1482 | 它不再是发送方的设备了 1483 | 1484 | 1485 | 269 1486 | 00:17:37,925 --> 00:17:39,426 1487 | 这里的好消息是 1488 | 1489 | 1490 | 270 1491 | 00:17:39,493 --> 00:17:43,430 1492 | 在您的应用中或服务器端 1493 | 都不需要写任何额外代码了 1494 | 1495 | 1496 | 271 1497 | 00:17:43,564 --> 00:17:48,702 1498 | KSM支持来自于Apple TV 1499 | 1500 | 1501 | 272 1502 | 00:17:49,069 --> 00:17:53,173 1503 | 或来自于iOS设备传入的密钥请求 1504 | 1505 | 1506 | 273 1507 | 00:17:55,042 --> 00:17:58,612 1508 | 需要明确的是 1509 | SPC仍是Apple TV上生成的 1510 | 1511 | 1512 | 274 1513 | 00:17:59,146 --> 00:18:03,884 1514 | 而您的密钥服务器上生成的CKC响应 1515 | 也将在AppleTV上进行处理 1516 | 1517 | 1518 | 275 1519 | 00:18:05,152 --> 00:18:10,657 1520 | 然而app仍然负责Apple TV 1521 | 和密钥服务器之间的消息 1522 | 1523 | 1524 | 276 1525 | 00:18:10,724 --> 00:18:12,659 1526 | 因此必须有发送设备的参与 1527 | 1528 | 1529 | 277 1530 | 00:18:14,261 --> 00:18:17,364 1531 | 这给了我们与本地回放同水平的安全性 1532 | 1533 | 1534 | 278 1535 | 00:18:17,431 --> 00:18:21,502 1536 | 因为SPC和CKC消息 1537 | 都来自于并终止于 1538 | 1539 | 1540 | 279 1541 | 00:18:21,668 --> 00:18:23,904 1542 | 实际播放内容的那个设备 1543 | 1544 | 1545 | 280 1546 | 00:18:24,004 --> 00:18:26,406 1547 | 在这种情况下是Apple TV 1548 | 也即AirPlay 1549 | 1550 | 1551 | 281 1552 | 00:18:27,975 --> 00:18:29,743 1553 | 需要注意的一点是 1554 | 1555 | 1556 | 282 1557 | 00:18:29,810 --> 00:18:33,847 1558 | 实际上FPS内容将不会 1559 | 以AirPlay镜像模式执行 1560 | 1561 | 1562 | 283 1563 | 00:18:34,281 --> 00:18:36,984 1564 | 那也适用于在您的本地设备上 1565 | 1566 | 1567 | 284 1568 | 00:18:37,317 --> 00:18:39,987 1569 | 播放的FPS内容所做的 1570 | 屏幕截图和音视频录制 1571 | 1572 | 1573 | 285 1574 | 00:18:41,355 --> 00:18:44,157 1575 | 在我们谈了关于如何 1576 | 在您的app上或AirPlay上 1577 | 1578 | 1579 | 286 1580 | 00:18:44,858 --> 00:18:47,661 1581 | 在本地消费内容之后 1582 | 1583 | 1584 | 287 1585 | 00:18:48,128 --> 00:18:50,264 1586 | 我骄傲地宣布： 1587 | 1588 | 1589 | 288 1590 | 00:18:50,330 --> 00:18:53,066 1591 | 今年我们将增加 1592 | 对El Capitan的FPS支持 1593 | 1594 | 1595 | 289 1596 | 00:18:54,668 --> 00:18:59,873 1597 | 这种大家支持 1598 | 且集成到网站的方式 1599 | 1600 | 1601 | 290 1602 | 00:19:00,240 --> 00:19:04,444 1603 | 是通过加密的媒体扩展 1604 | 1605 | 1606 | 291 1607 | 00:19:04,912 --> 00:19:07,080 1608 | 它们是HTML5的一部分 1609 | 是一个W3C规范 1610 | 1611 | 1612 | 292 1613 | 00:19:07,147 --> 00:19:08,715 1614 | 您可以从它们的网站下载它 1615 | 1616 | 1617 | 293 1618 | 00:19:09,383 --> 00:19:13,187 1619 | 您与EME集成的方式是 1620 | 1621 | 1622 | 294 1623 | 00:19:13,253 --> 00:19:16,623 1624 | 将您的JavaScript格式 1625 | 密钥传递代码写到您的网站上 1626 | 1627 | 1628 | 295 1629 | 00:19:17,124 --> 00:19:21,161 1630 | 我们在SDK中 1631 | 提供了一个这种实施的例子 1632 | 1633 | 1634 | 296 1635 | 00:19:21,261 --> 00:19:22,663 1636 | 它更多地是一个小片段 1637 | 1638 | 1639 | 297 1640 | 00:19:24,097 --> 00:19:30,437 1641 | 这里的好消息是 1642 | 不管是在KSM端或AirPlay端 1643 | 1644 | 1645 | 298 1646 | 00:19:30,504 --> 00:19:32,673 1647 | 都不需要任何新的代码 1648 | 1649 | 1650 | 299 1651 | 00:19:33,106 --> 00:19:34,474 1652 | 它是开箱即用型的 1653 | 1654 | 1655 | 300 1656 | 00:19:34,908 --> 00:19:38,145 1657 | 且写好了JavaScript代码后 1658 | 它将对一切都是完全支持的 1659 | 1660 | 1661 | 301 1662 | 00:19:38,212 --> 00:19:39,179 1663 | 现在让我们谈一下 1664 | 1665 | 1666 | 302 1667 | 00:19:39,246 --> 00:19:43,450 1668 | 您为了在网页上支持FPS 1669 | 而将要写的JavaScript代码 1670 | 1671 | 1672 | 303 1673 | 00:19:43,650 --> 00:19:46,753 1674 | 您要做的第一件事是 1675 | 将m3u8 URL设为 1676 | 1677 | 1678 | 304 1679 | 00:19:47,054 --> 00:19:51,091 1680 | HTML5视频标签的来源属性 1681 | 1682 | 1683 | 305 1684 | 00:19:51,825 --> 00:19:53,427 1685 | 正像您为一个非加密内容所做的那样 1686 | 1687 | 1688 | 306 1689 | 00:19:54,394 --> 00:20:00,634 1690 | 然后为WebKitNeedKey调用 1691 | 添加视频元素Event Listener 1692 | 1693 | 1694 | 307 1695 | 00:20:01,535 --> 00:20:02,402 1696 | 当被触发的时候 1697 | 1698 | 1699 | 308 1700 | 00:20:02,569 --> 00:20:07,641 1701 | 那个Event Listener 1702 | 将把EME内容加密模块设置到FPS 1703 | 1704 | 1705 | 309 1706 | 00:20:08,509 --> 00:20:11,378 1707 | 它还将在video/MP4上 1708 | 创建一个keySession 1709 | 1710 | 1711 | 310 1712 | 00:20:11,445 --> 00:20:14,381 1713 | 以便在密钥系统 1714 | 和您的密钥服务器之间传递消息 1715 | 1716 | 1717 | 311 1718 | 00:20:15,115 --> 00:20:16,717 1719 | 您将 1720 | web kit key message 1721 | 1722 | 1723 | 312 1724 | 00:20:16,783 --> 00:20:19,286 1725 | 向那个keySession 1726 | 添加Event Handler 1727 | 1728 | 1729 | 313 1730 | 00:20:19,786 --> 00:20:25,058 1731 | 那个Event Handler负责 1732 | 把SPC密钥请求传送到您的服务器上 1733 | 1734 | 1735 | 314 1736 | 00:20:25,425 --> 00:20:30,030 1737 | 然后通过更新密钥会话 1738 | 处理CKC响应 1739 | 1740 | 1741 | 315 1742 | 00:20:31,131 --> 00:20:34,701 1743 | 在数据流方面 1744 | 我们在左侧有非常类似的活动要素 1745 | 1746 | 1747 | 316 1748 | 00:20:34,768 --> 00:20:36,703 1749 | 我们在右侧有同样的活动要素 1750 | 1751 | 1752 | 317 1753 | 00:20:36,770 --> 00:20:41,241 1754 | 我们现在有Apple提供的 1755 | Safari以及EME堆栈 1756 | 1757 | 1758 | 318 1759 | 00:20:41,708 --> 00:20:43,377 1760 | 在Safari内我们有您的网站 1761 | 1762 | 1763 | 319 1764 | 00:20:43,911 --> 00:20:50,684 1765 | 及您将在网站上支持FPS内容播放和 1766 | 新写的JavaScript代码片段 1767 | 1768 | 1769 | 320 1770 | 00:20:52,786 --> 00:20:56,123 1771 | 让我们讨论下当用户在Safari中 1772 | 点击Play会发生什么 1773 | 1774 | 1775 | 321 1776 | 00:20:56,256 --> 00:20:59,493 1777 | 那么当用户点击play时 1778 | 将要发生的第一件事是 1779 | 1780 | 1781 | 322 1782 | 00:20:59,927 --> 00:21:03,530 1783 | m3u8将在操作系统中 1784 | 点击EME和AVFoundation 1785 | 1786 | 1787 | 323 1788 | 00:21:03,597 --> 00:21:07,401 1789 | 而EME将会注意到内容已被加密 1790 | 1791 | 1792 | 324 1793 | 00:21:07,467 --> 00:21:12,706 1794 | 这将使它触发 1795 | Web kit need key message 1796 | 1797 | 1798 | 325 1799 | 00:21:12,773 --> 00:21:14,374 1800 | 您的事件监听器将收到这条消息 1801 | 1802 | 1803 | 326 1804 | 00:21:16,410 --> 00:21:18,478 1805 | 然后您的事件监听器将创建密钥会话 1806 | 1807 | 1808 | 327 1809 | 00:21:18,545 --> 00:21:21,081 1810 | 并将等待Web kit key message 1811 | 1812 | 1813 | 328 1814 | 00:21:21,181 --> 00:21:23,183 1815 | 后者又将触发 1816 | Event Handler 1817 | 1818 | 1819 | 329 1820 | 00:21:23,817 --> 00:21:26,286 1821 | 而Event Handler 1822 | 将接收到SPC 1823 | 1824 | 1825 | 330 1826 | 00:21:26,620 --> 00:21:30,123 1827 | 并将其传给您的密钥服务器 1828 | 密钥服务器将对其照常处理 1829 | 1830 | 1831 | 331 1832 | 00:21:30,190 --> 00:21:32,693 1833 | 包括提取内容密钥和创建内容密钥响应 1834 | 1835 | 1836 | 332 1837 | 00:21:33,026 --> 00:21:36,396 1838 | 然后将那个CKC传回 1839 | 给JavaScript代码 1840 | 1841 | 1842 | 333 1843 | 00:21:36,463 --> 00:21:39,900 1844 | 后者再将CKC 1845 | 向下传递返回给EME层以便播放 1846 | 1847 | 1848 | 334 1849 | 00:21:42,202 --> 00:21:43,504 1850 | 正如罗哲斯刚才所说 1851 | 1852 | 1853 | 335 1854 | 00:21:43,570 --> 00:21:48,442 1855 | 我们从最初部署该解决方案 1856 | 到现在已超过三年 1857 | 1858 | 1859 | 336 1860 | 00:21:48,909 --> 00:21:55,716 1861 | 这几年间我们学会了一些 1862 | 如何解决FPS集成问题的秘诀和窍门 1863 | 1864 | 1865 | 337 1866 | 00:21:56,250 --> 00:21:58,886 1867 | 而您可能面对的典型问题 1868 | 1869 | 1870 | 338 1871 | 00:21:59,586 --> 00:22:03,657 1872 | 如果您的集成工作不幸出错的话 1873 | 是内容不播放 1874 | 1875 | 1876 | 339 1877 | 00:22:04,358 --> 00:22:08,095 1878 | 那么您要怎样对那种情况进行调试呢？ 1879 | 1880 | 1881 | 340 1882 | 00:22:08,262 --> 00:22:11,231 1883 | 我们建议您做的一件事是... 1884 | 1885 | 1886 | 341 1887 | 00:22:11,298 --> 00:22:14,935 1888 | 而且这仅限于调试目的 1889 | 我们不建议您在生产环境中这么做 1890 | 1891 | 1892 | 342 1893 | 00:22:15,269 --> 00:22:19,206 1894 | 那就是将您在m3u8播放列表中的 1895 | 密钥格式设为identity 1896 | 1897 | 1898 | 343 1899 | 00:22:19,806 --> 00:22:22,442 1900 | 而不是 1901 | com.apple.streamingkeydelivery 1902 | 1903 | 1904 | 344 1905 | 00:22:22,509 --> 00:22:23,877 1906 | 这有什么作用呢？ 1907 | 1908 | 1909 | 345 1910 | 00:22:23,944 --> 00:22:26,713 1911 | 它将同样的内容传送到客户端 1912 | 1913 | 1914 | 346 1915 | 00:22:27,214 --> 00:22:31,718 1916 | 但并不是用FPS将内容解密 1917 | 而是用明文AES密钥解密 1918 | 1919 | 1920 | 347 1921 | 00:22:32,586 --> 00:22:35,956 1922 | 而我们最终会是两种情况之一 1923 | 1924 | 1925 | 348 1926 | 00:22:36,023 --> 00:22:37,457 1927 | 第一种是您的内容仍不播放 1928 | 1929 | 1930 | 349 1931 | 00:22:37,758 --> 00:22:42,196 1932 | 这种情况下很有可能是内容制作问题 1933 | 1934 | 1935 | 350 1936 | 00:22:42,529 --> 00:22:45,165 1937 | 而那些问题通常分为四类 1938 | 1939 | 1940 | 351 1941 | 00:22:45,566 --> 00:22:48,969 1942 | 或者是您的加密样本存在问题 1943 | 1944 | 1945 | 352 1946 | 00:22:49,036 --> 00:22:53,240 1947 | 如果是那种情况 1948 | 我建议您参考HLS示例加密规范 1949 | 1950 | 1951 | 353 1952 | 00:22:53,540 --> 00:22:55,876 1953 | 它可能是PAT/PMT音频设置问题 1954 | 1955 | 1956 | 354 1957 | 00:22:56,410 --> 00:23:02,182 1958 | 那些是您需要对采用FPS编码 1959 | 和加密的音频流采取的步骤 1960 | 1961 | 1962 | 355 1963 | 00:23:02,249 --> 00:23:04,718 1964 | 需要对一些元数据进行更新 1965 | 1966 | 1967 | 356 1968 | 00:23:05,786 --> 00:23:08,188 1969 | 可能是这样的情况 1970 | 您使用的编解码器不被支持 1971 | 1972 | 1973 | 357 1974 | 00:23:08,388 --> 00:23:09,690 1975 | 而且如罗哲斯稍早提到的 1976 | 1977 | 1978 | 358 1979 | 00:23:09,756 --> 00:23:14,962 1980 | 目前我们在FPS中支持的是 1981 | H.264 AAC 以及加密的AC3 1982 | 1983 | 1984 | 359 1985 | 00:23:15,729 --> 00:23:21,869 1986 | 最后 有可能您将在非HLS片段上 1987 | 重置您的内容密钥 1988 | 1989 | 1990 | 360 1991 | 00:23:22,302 --> 00:23:27,474 1992 | 那么我们建议您将密钥 1993 | 在最细粒度的HLS片段上重置 1994 | 1995 | 1996 | 361 1997 | 00:23:27,841 --> 00:23:32,379 1998 | 或者您也可以转换比特率时 1999 | 更改内容密钥值 2000 | 2001 | 2002 | 362 2003 | 00:23:33,914 --> 00:23:37,985 2004 | 如果在您将密钥格式标签 2005 | 更新为identity之后 2006 | 2007 | 2008 | 363 2009 | 00:23:38,051 --> 00:23:40,187 2010 | 您的内容已经可以播放 2011 | 但可能面临密钥传递问题 2012 | 2013 | 2014 | 364 2015 | 00:23:40,721 --> 00:23:45,292 2016 | 如果那样的话 2017 | 您要做的就是跟踪我们刚才所考查的 2018 | 2019 | 2020 | 365 2021 | 00:23:45,893 --> 00:23:50,464 2022 | 图表中的数据流 2023 | 并确保SPC由客户端正确生成 2024 | 2025 | 2026 | 366 2027 | 00:23:50,531 --> 00:23:55,235 2028 | 它被传送到服务器 2029 | 您的服务器能正确无误处理该密钥请求 2030 | 2031 | 2032 | 367 2033 | 00:23:55,502 --> 00:23:57,771 2034 | 您的服务器在数据库中查找正确的密钥 2035 | 2036 | 2037 | 368 2038 | 00:23:58,172 --> 00:24:02,142 2039 | 而且服务器能够将内容密钥 2040 | 封装为内容密钥响应 2041 | 2042 | 2043 | 369 2044 | 00:24:02,209 --> 00:24:06,880 2045 | 而且客户端能够正确无误地 2046 | 处理那一响应 2047 | 2048 | 2049 | 370 2050 | 00:24:08,015 --> 00:24:12,152 2051 | 既然我们已经考查了 2052 | 在Apple生态系统内 2053 | 2054 | 2055 | 371 2056 | 00:24:12,219 --> 00:24:15,055 2057 | 消费FPS内容的各种方式 2058 | 2059 | 2060 | 372 2061 | 00:24:15,122 --> 00:24:17,524 2062 | 我想把舞台还给罗哲斯 2063 | 让他为这节讲座做一个总结 2064 | 2065 | 2066 | 373 2067 | 00:24:17,624 --> 00:24:18,926 2068 | 非常感谢大家为此付出的时间 2069 | 2070 | 2071 | 374 2072 | 00:24:25,966 --> 00:24:27,067 2073 | 非常感谢谢詹保罗 法索里 2074 | 2075 | 2076 | 375 2077 | 00:24:27,501 --> 00:24:29,236 2078 | 那么让我们在这里快速地总结一下 2079 | 2080 | 2081 | 376 2082 | 00:24:30,137 --> 00:24:33,874 2083 | 面向HLS的FPS 2084 | 2085 | 2086 | 377 2087 | 00:24:34,107 --> 00:24:40,848 2088 | 为您提供业内颇具优势的 2089 | HLS内容保护工具 2090 | 2091 | 2092 | 378 2093 | 00:24:42,082 --> 00:24:48,355 2094 | 您在iOS上 Apple TV上 2095 | 以及在OS X上都能使用它 2096 | 2097 | 2098 | 379 2099 | 00:24:48,689 --> 00:24:53,627 2100 | 自从iOS 6就开始提供了 2101 | 因此已有相当程度的兼容性 2102 | 2103 | 2104 | 380 2105 | 00:24:54,061 --> 00:24:56,797 2106 | 在Apple TV上也是如此 2107 | 2108 | 2109 | 381 2110 | 00:24:57,231 --> 00:24:58,866 2111 | OS X仍较新 2112 | 2113 | 2114 | 382 2115 | 00:24:58,932 --> 00:25:00,868 2116 | 您可以在之后的实验室活动中 2117 | 跟我们聊聊 2118 | 2119 | 2120 | 383 2121 | 00:25:00,934 --> 00:25:03,804 2122 | 我们将向您和盘托出 2123 | 您可以把它用在什么地方 2124 | 2125 | 2126 | 384 2127 | 00:25:05,239 --> 00:25:07,341 2128 | 它已被深度集成到OS内部 2129 | 2130 | 2131 | 385 2132 | 00:25:07,441 --> 00:25:10,677 2133 | 意味着它能够向下兼容到极低的版本 2134 | 2135 | 2136 | 386 2137 | 00:25:10,744 --> 00:25:12,246 2138 | 而且我们也尽可能确保其安全性 2139 | 2140 | 2141 | 387 2142 | 00:25:12,446 --> 00:25:14,882 2143 | 它的电源效率也达到了 2144 | 我们能够达到的极致 2145 | 2146 | 2147 | 388 2148 | 00:25:15,215 --> 00:25:18,085 2149 | 而且它有极佳的电池寿命 2150 | 以及高度的安全性 2151 | 2152 | 2153 | 389 2154 | 00:25:19,052 --> 00:25:22,990 2155 | 而且它支持我们所有生态系统特性 2156 | 2157 | 2158 | 390 2159 | 00:25:23,357 --> 00:25:28,061 2160 | 比如AirPlay 2161 | HDCP HTML5 2162 | 2163 | 2164 | 391 2165 | 00:25:28,128 --> 00:25:32,566 2166 | 而且随着不断推出新特性 2167 | 我们将持续改进它 2168 | 2169 | 2170 | 392 2171 | 00:25:36,069 --> 00:25:37,204 2172 | 那么下一步是什么呢？ 2173 | 2174 | 2175 | 393 2176 | 00:25:38,338 --> 00:25:39,773 2177 | 第一站是在 2178 | 2179 | 2180 | 394 2181 | 00:25:40,174 --> 00:25:43,977 2182 | developer.apple.com 2183 | 上最新的FPS门户 2184 | 2185 | 2186 | 395 2187 | 00:25:44,044 --> 00:25:48,415 2188 | 它现在就在运转中 2189 | 所以您可以去那里看看 2190 | 2191 | 2192 | 396 2193 | 00:25:48,482 --> 00:25:53,921 2194 | 而且您还可以从门户下载SDK 2195 | 您可以查看概述文件 2196 | 2197 | 2198 | 397 2199 | 00:25:53,987 --> 00:25:58,759 2200 | 它会让您对FPS的细节 2201 | 有一点更深入的见解 2202 | 2203 | 2204 | 398 2205 | 00:25:59,259 --> 00:26:04,631 2206 | 而且通过那个站点 2207 | 您也可以申请生产目的的开发者证书 2208 | 2209 | 2210 | 399 2211 | 00:26:04,698 --> 00:26:08,769 2212 | 它们对实现iOS设备或Safari 2213 | 2214 | 2215 | 400 2216 | 00:26:09,036 --> 00:26:12,539 2217 | 上的来回播放是必要的 2218 | 2219 | 2220 | 401 2221 | 00:26:15,742 --> 00:26:22,149 2222 | 我应该提到的下一件事情 2223 | 在那个站点 在登录页上 2224 | 2225 | 2226 | 402 2227 | 00:26:22,516 --> 00:26:27,788 2228 | 你们中间的某些人 2229 | 可能并没有一个现成的后端 2230 | 2231 | 2232 | 403 2233 | 00:26:28,155 --> 00:26:34,261 2234 | 或者一想到将FPS集成到后端 2235 | 就被这个想法吓到了 2236 | 2237 | 2238 | 404 2239 | 00:26:34,661 --> 00:26:38,565 2240 | 那么在那个登录页面上 2241 | 我们有一个小小的清单 2242 | 2243 | 2244 | 405 2245 | 00:26:38,866 --> 00:26:44,004 2246 | 列出了我们的集成合作伙伴 2247 | 像Irdeto 像Adobe 2248 | 2249 | 2250 | 406 2251 | 00:26:44,571 --> 00:26:49,109 2252 | 它们已经为希望使用FPS 2253 | 2254 | 2255 | 407 2256 | 00:26:49,176 --> 00:26:54,081 2257 | 保护HLS内容的朋友 2258 | 建立了一些支持 2259 | 2260 | 2261 | 408 2262 | 00:26:55,282 --> 00:26:58,051 2263 | 我建议您也查看一下那些合作伙伴 2264 | 2265 | 2266 | 409 2267 | 00:26:58,118 --> 00:27:02,789 2268 | 如果您觉得在FPS设置 2269 | 及如何使其为您工作方面 2270 | 2271 | 2272 | 410 2273 | 00:27:03,290 --> 00:27:04,124 2274 | 一点帮助的话 2275 | 2276 | 2277 | 411 2278 | 00:27:04,525 --> 00:27:06,426 2279 | 我觉得这是很容易做的 2280 | 2281 | 2282 | 412 2283 | 00:27:06,493 --> 00:27:09,029 2284 | 但并不是每个人都是业内人士 2285 | 2286 | 2287 | 413 2288 | 00:27:09,463 --> 00:27:11,265 2289 | 因此如果您需要的话 2290 | 我们会为您提供帮助 2291 | 2292 | 2293 | 414 2294 | 00:27:12,099 --> 00:27:18,272 2295 | 此外 2296 | 如果您想让HLS和FPS开始工作 2297 | 2298 | 2299 | 415 2300 | 00:27:18,605 --> 00:27:23,410 2301 | 但是感觉仍然存在问题 2302 | 或者您已经尝试过且遇到了一些问题 2303 | 2304 | 2305 | 416 2306 | 00:27:23,777 --> 00:27:25,679 2307 | 如果您不是在WWDC上 2308 | 2309 | 2310 | 417 2311 | 00:27:25,979 --> 00:27:29,950 2312 | 那么对您来说最佳的第一站 2313 | 就是我们的开发者论坛 2314 | 2315 | 2316 | 418 2317 | 00:27:30,117 --> 00:27:33,453 2318 | 而且我们实际上 2319 | 已经建立了目前处于测试阶段 2320 | 2321 | 2322 | 419 2323 | 00:27:33,754 --> 00:27:37,824 2324 | 但是我们已建立了一个新的论坛 2325 | 它是专门面向FPS的 2326 | 2327 | 2328 | 420 2329 | 00:27:38,225 --> 00:27:41,228 2330 | 因此请查看一下这个论坛 2331 | 2332 | 2333 | 421 2334 | 00:27:41,361 --> 00:27:44,131 2335 | 如果您遇到了困难 2336 | 或者是有什么问题 2337 | 2338 | 2339 | 422 2340 | 00:27:44,398 --> 00:27:48,836 2341 | 很可能其他人也有 2342 | 同样的问题 同样的困难 2343 | 2344 | 2345 | 423 2346 | 00:27:49,102 --> 00:27:51,438 2347 | 而你可能通过查看论坛 2348 | 就能找到答案 2349 | 2350 | 2351 | 424 2352 | 00:27:52,840 --> 00:27:54,374 2353 | 如果那样做失败的话 2354 | 2355 | 2356 | 425 2357 | 00:27:54,441 --> 00:27:57,411 2358 | 还有您的非常友好的社区 2359 | 以及开发者技术支持代表 2360 | 2361 | 2362 | 426 2363 | 00:27:57,477 --> 00:27:59,780 2364 | 将乐于为您提供帮助且收费低廉 2365 | 2366 | 2367 | 427 2368 | 00:28:01,615 --> 00:28:02,616 2369 | 我想就是这样了 2370 | 2371 | 2372 | 428 2373 | 00:28:03,884 --> 00:28:05,052 2374 | 再次感谢您的光临！ 2375 | 2376 | 2377 | 429 2378 | 00:28:05,352 --> 00:28:06,820 2379 | 希望您在大会期间开心！ 2380 | 2381 | -------------------------------------------------------------------------------- /HD/503_hd_monetize_and_promote_your_app_with_iad.srt: -------------------------------------------------------------------------------- 1 | 1 2 | 00:00:19,219 --> 00:00:24,691 3 | 如何在iAd中推广你的App并营利 4 | 从设计到发布 5 | 6 | 7 | 2 8 | 00:00:25,025 --> 00:00:26,760 9 | 大家好！ 10 | 欢迎大家！ 11 | 12 | 13 | 3 14 | 00:00:28,195 --> 00:00:34,968 15 | 你们开发者中有很多人 16 | 把时间精力血汗以及泪水 17 | 18 | 19 | 4 20 | 00:00:35,235 --> 00:00:40,607 21 | 投入到构建一些最令人惊叹的 22 | 引人入胜的以及美妙的app中 23 | 24 | 25 | 5 26 | 00:00:41,975 --> 00:00:44,344 27 | 然而最成功的开发者 28 | 29 | 30 | 6 31 | 00:00:45,312 --> 00:00:47,814 32 | 并不只是关注打造优秀的app 33 | 34 | 35 | 7 36 | 00:00:48,749 --> 00:00:50,984 37 | 他们也认识到了围绕他们的app 38 | 39 | 40 | 8 41 | 00:00:51,451 --> 00:00:54,688 42 | 建立良好的业务的重要性 43 | 44 | 45 | 9 46 | 00:00:56,023 --> 00:00:58,225 47 | 而那正是我们今天在这里 48 | 跟您要讨论的话题 49 | 50 | 51 | 10 52 | 00:00:59,560 --> 00:01:00,961 53 | 我叫卡洛·鄧/邓 54 | 55 | 56 | 11 57 | 00:01:01,328 --> 00:01:04,298 58 | 我的同事莎尚克·珐德克 59 | 将和我一起完成讲座 60 | 61 | 62 | 12 63 | 00:01:04,397 --> 00:01:06,233 64 | 我们都来自于iAd团队 65 | 66 | 67 | 13 68 | 00:01:08,368 --> 00:01:10,304 69 | 今天我们在这里将向您介绍iAd 70 | 71 | 72 | 14 73 | 00:01:10,838 --> 00:01:13,106 74 | Apple的数字广告平台 75 | 76 | 77 | 15 78 | 00:01:14,341 --> 00:01:18,212 79 | 不管您是大型开发机构 80 | 或是小型独立开发者 81 | 82 | 83 | 16 84 | 00:01:18,812 --> 00:01:23,550 85 | iAd都为您提供广泛的解决方案 86 | 帮助您扩大业务 87 | 88 | 89 | 17 90 | 00:01:25,452 --> 00:01:28,655 91 | 而所有业务面临的一些共同挑战 92 | 93 | 94 | 18 95 | 00:01:29,289 --> 00:01:33,894 96 | 如何创造收入以及如何吸引和留住客户 97 | 98 | 99 | 19 100 | 00:01:34,995 --> 00:01:36,964 101 | iAd有针对这两个问题的解决方案 102 | 103 | 104 | 20 105 | 00:01:38,365 --> 00:01:39,800 106 | 为了帮助创造收入 107 | 108 | 109 | 21 110 | 00:01:40,868 --> 00:01:43,170 111 | 将iAd集成到您的app中 112 | 是简单易行的 113 | 114 | 115 | 22 116 | 00:01:44,171 --> 00:01:46,206 117 | 而且以极少的代码就能够实现 118 | 119 | 120 | 23 121 | 00:01:47,007 --> 00:01:49,376 122 | 稍后在讲座中我们会为您展示 123 | 124 | 125 | 24 126 | 00:01:52,045 --> 00:01:54,147 127 | 一方面 对于app开发者来说 128 | 129 | 130 | 25 131 | 00:01:54,414 --> 00:01:57,017 132 | 获取客户可能尤其是 133 | 一件让人望而生畏的事情 134 | 135 | 136 | 26 137 | 00:01:58,085 --> 00:01:59,353 138 | 昨天您也听说了 139 | 140 | 141 | 27 142 | 00:01:59,753 --> 00:02:03,223 143 | 在App Store 144 | 有超过150万个app 145 | 146 | 147 | 28 148 | 00:02:03,757 --> 00:02:07,361 149 | 而平均每件用户设备上 150 | 就有119个app 151 | 152 | 153 | 29 154 | 00:02:08,195 --> 00:02:11,765 155 | 有大量的争夺用户注意力的竞争 156 | 157 | 158 | 30 159 | 00:02:12,299 --> 00:02:15,269 160 | 那么您怎样让您的app被注意到？ 161 | 162 | 163 | 31 164 | 00:02:17,671 --> 00:02:20,274 165 | 对此问题 166 | iAd的解决方案可以帮您 167 | 168 | 169 | 32 170 | 00:02:20,340 --> 00:02:23,577 171 | 在iOS生态系统中高效地推广app 172 | 173 | 174 | 33 175 | 00:02:23,977 --> 00:02:27,514 176 | 以便为您的app创造知名度 177 | 并获取客户 178 | 179 | 180 | 34 181 | 00:02:30,450 --> 00:02:33,921 182 | 为您的app进行推广 183 | 涉及到三个主要概念 184 | 185 | 186 | 35 187 | 00:02:34,922 --> 00:02:38,192 188 | 首先 确认并划分您的用户 189 | 190 | 191 | 36 192 | 00:02:38,692 --> 00:02:42,362 193 | 以便了解您试图影响的不同受众 194 | 195 | 196 | 37 197 | 00:02:43,897 --> 00:02:45,199 198 | 在您的app推广活动中 199 | 200 | 201 | 38 202 | 00:02:45,399 --> 00:02:49,603 203 | 用具有相关性和针对性的消息 204 | 与那些用户建立联系 205 | 206 | 207 | 39 208 | 00:02:50,737 --> 00:02:57,211 209 | 然后衡量那些活动的有效性 210 | 以便能够持续优化和改善活动效果 211 | 212 | 213 | 40 214 | 00:03:00,447 --> 00:03:03,417 215 | 我们将向您演示 216 | 如何利用工具和最佳实践 217 | 218 | 219 | 41 220 | 00:03:03,717 --> 00:03:05,285 221 | 让您做到这两点： 222 | 223 | 224 | 42 225 | 00:03:05,652 --> 00:03:09,957 226 | 在您app开发的整个生命周期内 227 | 对其进行货币转化和推广 228 | 229 | 230 | 43 231 | 00:03:10,891 --> 00:03:11,892 232 | 让我们开始吧 233 | 234 | 235 | 44 236 | 00:03:15,295 --> 00:03:16,997 237 | 设想我是一个app开发者 238 | 239 | 240 | 45 241 | 00:03:17,998 --> 00:03:19,733 242 | 我在App Store里 243 | 有几个app 244 | 245 | 246 | 46 247 | 00:03:20,234 --> 00:03:24,004 248 | 而且我正打算发布我的下一个 249 | 伟大的app名为LiteRight 250 | 251 | 252 | 47 253 | 00:03:25,339 --> 00:03:27,374 254 | LiteRight 255 | 是一个最新的照相app 256 | 257 | 258 | 48 259 | 00:03:27,441 --> 00:03:31,478 260 | 它有一些极为特殊的滤镜 261 | 在其他任何地方都没有 262 | 263 | 264 | 49 265 | 00:03:32,880 --> 00:03:34,314 266 | 它将是一款免费app 267 | 268 | 269 | 50 270 | 00:03:34,581 --> 00:03:37,618 271 | 让用户能够使用那样的一些滤镜 272 | 273 | 274 | 51 275 | 00:03:37,951 --> 00:03:43,190 276 | 而app内置的购买功能 277 | 让用户能够接触到更棒的滤镜 278 | 279 | 280 | 52 281 | 00:03:46,093 --> 00:03:48,028 282 | 这是我的app开发时间表 283 | 284 | 285 | 53 286 | 00:03:48,161 --> 00:03:50,230 287 | 它看上去跟您的可能类似 288 | 289 | 290 | 54 291 | 00:03:50,731 --> 00:03:54,134 292 | 从设计阶段开始 293 | 然后我将开发app 294 | 295 | 296 | 55 297 | 00:03:54,568 --> 00:03:57,604 298 | 在App Store发布它 299 | 并扩大我的用户基础 300 | 301 | 302 | 56 303 | 00:03:59,873 --> 00:04:02,276 304 | 目前我正处在 305 | LiteRight的设计阶段 306 | 307 | 308 | 57 309 | 00:04:02,809 --> 00:04:05,045 310 | 但是我已经在考虑商业模式 311 | 312 | 313 | 58 314 | 00:04:05,112 --> 00:04:07,181 315 | 以及如何才能 316 | 让我的app实现货币转化 317 | 318 | 319 | 59 320 | 00:04:08,782 --> 00:04:10,784 321 | 由于LiteRight 322 | 将是一个免费app 323 | 324 | 325 | 60 326 | 00:04:11,451 --> 00:04:13,554 327 | 我已决定让它由广告支持 328 | 329 | 330 | 61 331 | 00:04:13,987 --> 00:04:16,723 332 | 以便能立刻开始产生收入 333 | 334 | 335 | 62 336 | 00:04:19,493 --> 00:04:20,827 337 | 而我已经选择iAd 338 | 339 | 340 | 63 341 | 00:04:21,094 --> 00:04:24,798 342 | 作为我的首选广告平台 343 | 来将我的app货币化 344 | 345 | 346 | 64 347 | 00:04:25,465 --> 00:04:27,901 348 | 因为iAd负责整个过程 349 | 350 | 351 | 65 352 | 00:04:28,202 --> 00:04:31,839 353 | 包括找到很好的广告主 提供广告 354 | 355 | 356 | 66 357 | 00:04:32,339 --> 00:04:35,642 358 | 以及为我的app上运行的广告 359 | 提供报告和账单 360 | 361 | 362 | 67 363 | 00:04:37,244 --> 00:04:42,816 364 | 为此iAd直接与我分享 365 | 创造的广告收入的70% 366 | 367 | 368 | 68 369 | 00:04:44,651 --> 00:04:46,653 370 | 而且iAd并不是一个排他性的网络 371 | 372 | 373 | 69 374 | 00:04:47,054 --> 00:04:50,224 375 | 因此我可以与其他广告网络 376 | 和中介伙伴合作 377 | 378 | 379 | 70 380 | 00:04:50,290 --> 00:04:51,391 381 | 只要我选择那么做即可 382 | 383 | 384 | 71 385 | 00:04:52,292 --> 00:04:54,695 386 | 但是因为我在试图将我的收入最大化 387 | 388 | 389 | 72 390 | 00:04:54,828 --> 00:04:58,232 391 | 而且我关注的是高等级 高质量的广告 392 | 393 | 394 | 73 395 | 00:04:58,799 --> 00:05:00,901 396 | 我将把iAd作为我的首选 397 | 398 | 399 | 74 400 | 00:05:04,004 --> 00:05:07,207 401 | 因为我已花费了很多时间 402 | 打造一个美妙的app 403 | 404 | 405 | 75 406 | 00:05:07,441 --> 00:05:09,977 407 | 所以在我的app上的广告 408 | 也应该是同样美妙的 409 | 410 | 411 | 76 412 | 00:05:11,378 --> 00:05:12,212 413 | 为了实现这个目的 414 | 415 | 416 | 77 417 | 00:05:12,513 --> 00:05:15,616 418 | iAd与一些顶尖的创意机构合作 419 | 420 | 421 | 78 422 | 00:05:15,716 --> 00:05:20,020 423 | 以实现来自于世界最受认可品牌的 424 | 425 | 426 | 79 427 | 00:05:20,420 --> 00:05:23,290 428 | 高生产价值的广告 429 | 430 | 431 | 80 432 | 00:05:24,825 --> 00:05:29,830 433 | 此外 每条广告都经过 434 | iAd团队的审核和认证 435 | 436 | 437 | 81 438 | 00:05:30,163 --> 00:05:33,166 439 | 因此我能确定 440 | 出现在我的app上的广告 441 | 442 | 443 | 82 444 | 00:05:33,567 --> 00:05:35,569 445 | 均遵从苹果公司的创意准则 446 | 447 | 448 | 83 449 | 00:05:37,171 --> 00:05:41,942 450 | 而且我可以用关键词 451 | 和iTunes URL屏蔽任何广告 452 | 453 | 454 | 84 455 | 00:05:43,277 --> 00:05:46,180 456 | 所有这些都有助于创造良好的用户体验 457 | 458 | 459 | 85 460 | 00:05:49,683 --> 00:05:52,186 461 | LiteRight 462 | 将是一个全球化的app 463 | 464 | 465 | 86 466 | 00:05:52,553 --> 00:05:56,757 467 | 意味着我的用户将在世界各地 468 | iAd也将是全球化的 469 | 470 | 471 | 87 472 | 00:05:57,691 --> 00:06:01,929 473 | 能够触及100多个国家的iOS用户 474 | 475 | 476 | 88 477 | 00:06:04,565 --> 00:06:05,999 478 | 而谈到用户 479 | 480 | 481 | 89 482 | 00:06:06,567 --> 00:06:11,805 483 | iAd解决方案是具有隐私意识的 484 | 内置了隐私管理 485 | 486 | 487 | 90 488 | 00:06:12,639 --> 00:06:15,742 489 | 意味着我的用户数据是高度安全的 490 | 491 | 492 | 91 493 | 00:06:16,109 --> 00:06:18,212 494 | 而且绝不会与第三方共享 495 | 496 | 497 | 92 498 | 00:06:18,745 --> 00:06:20,614 499 | 这一点会得到用户的欣赏 500 | 501 | 502 | 93 503 | 00:06:21,682 --> 00:06:23,450 504 | 由于与iOS的深度集成 505 | 506 | 507 | 94 508 | 00:06:23,750 --> 00:06:29,156 509 | 它遵从“限制广告跟踪”策略 510 | 而且由iAd自动管理 511 | 512 | 513 | 95 514 | 00:06:32,860 --> 00:06:36,029 515 | 而且由于iAd被置到iOS框架内 516 | 517 | 518 | 96 519 | 00:06:36,830 --> 00:06:40,167 520 | 将其集成到我的app内 521 | 是快速而简单的 522 | 523 | 524 | 97 525 | 00:06:40,868 --> 00:06:47,341 526 | 没有额外的SDK和静态库 527 | 或第三方头文件让我的项目乱成一团 528 | 529 | 530 | 98 531 | 00:06:48,141 --> 00:06:50,844 532 | 以极少的代码我就可以让它启动 533 | 534 | 535 | 99 536 | 00:06:51,979 --> 00:06:55,716 537 | 也有文稿和示例代码为我一路提供帮助 538 | 539 | 540 | 100 541 | 00:06:58,886 --> 00:07:01,088 542 | 这里是iAd提供的所有广告格式 543 | 544 | 545 | 101 546 | 00:07:02,155 --> 00:07:05,058 547 | 我可以集成其中的一种或多种广告格式 548 | 549 | 550 | 102 551 | 00:07:05,125 --> 00:07:09,463 552 | 取决于哪种能够 553 | 使我的app内容和体验更完美 554 | 555 | 556 | 103 557 | 00:07:12,132 --> 00:07:15,435 558 | 横幅广告通常出现在app底部 559 | 560 | 561 | 104 562 | 00:07:17,938 --> 00:07:22,643 563 | 中等矩形广告适合被内嵌到 564 | 有大量内容的app中 565 | 566 | 567 | 105 568 | 00:07:25,612 --> 00:07:30,017 569 | 前置式视频广告最适合 570 | 主要提供视频的app 571 | 572 | 573 | 106 574 | 00:07:32,319 --> 00:07:35,656 575 | 而插播式广告适合 576 | 有良好逻辑过渡的app 577 | 578 | 579 | 107 580 | 00:07:35,722 --> 00:07:38,225 581 | 比如在游戏中 582 | 当用户等级提升的时候 583 | 584 | 585 | 108 586 | 00:07:41,295 --> 00:07:44,865 587 | 而作为即将推出的特性 588 | iAd将支持前置式视频广告 589 | 590 | 591 | 109 592 | 00:07:45,566 --> 00:07:49,369 593 | 它是另一个帮助进一步提高 594 | 我的app的货币化水平的途径 595 | 596 | 597 | 110 598 | 00:07:54,141 --> 00:07:57,611 599 | 现在让我们看一下如何将iAd集成 600 | 到我的LiteRight app内 601 | 602 | 603 | 111 604 | 00:07:59,847 --> 00:08:04,184 605 | 对于LiteRight 606 | 我将在图库屏幕上加入横幅广告 607 | 608 | 609 | 112 610 | 00:08:04,918 --> 00:08:08,088 611 | 并在每隔两次用户分享照片后 612 | 加入一个插播式广告 613 | 614 | 615 | 113 616 | 00:08:10,624 --> 00:08:14,828 617 | 对于横幅广告 618 | 我需链接到iAd框架并导入iAd库 619 | 620 | 621 | 114 622 | 00:08:15,462 --> 00:08:17,998 623 | 使其成为我项目的一部分 624 | 625 | 626 | 115 627 | 00:08:20,501 --> 00:08:22,503 628 | 然后我将需要配置视图控件 629 | 630 | 631 | 116 632 | 00:08:22,569 --> 00:08:24,972 633 | 以致于不管我希望 634 | 让横幅广告出现在哪里 635 | 636 | 637 | 117 638 | 00:08:25,339 --> 00:08:28,041 639 | 我都将把can Display Banner Ads 640 | 设为true 641 | 642 | 643 | 118 644 | 00:08:28,542 --> 00:08:32,044 645 | 进行此设置的一个好处是 646 | 在view Did Load回调中 647 | 648 | 649 | 119 650 | 00:08:33,547 --> 00:08:35,649 651 | iAd将负责处理视图 652 | 653 | 654 | 120 655 | 00:08:35,716 --> 00:08:38,452 656 | 以便让横幅广告以动画形式 657 | 出现在屏幕上 658 | 659 | 660 | 121 661 | 00:08:38,519 --> 00:08:40,854 662 | 并相应地让我的内容框架发生折叠 663 | 664 | 665 | 122 666 | 00:08:44,358 --> 00:08:46,593 667 | 设置完成之后 668 | 这就是它可能的样子 669 | 670 | 671 | 123 672 | 00:08:50,330 --> 00:08:52,766 673 | 与横幅广告不同的是 674 | 让我的app显示插播式广告 675 | 676 | 677 | 124 678 | 00:08:52,833 --> 00:08:54,902 679 | 需要更多一点设置 680 | 681 | 682 | 125 683 | 00:08:56,336 --> 00:08:57,371 684 | 在app Delegate里 685 | 686 | 687 | 126 688 | 00:08:57,437 --> 00:09:01,542 689 | 在application Did Finish Launching 690 | with Options 回调中 691 | 692 | 693 | 127 694 | 00:09:02,976 --> 00:09:04,611 695 | 我需要让iAd服务器知道 696 | 697 | 698 | 128 699 | 00:09:04,678 --> 00:09:07,247 700 | 我的app将通过 701 | 702 | 703 | 129 704 | 00:09:07,881 --> 00:09:10,584 705 | prepare Interstitial Ads调用 706 | 请求一个插播式广告 707 | 708 | 709 | 130 710 | 00:09:13,554 --> 00:09:16,490 711 | 而在视图控件内 712 | 就在插播式广告之前 713 | 714 | 715 | 131 716 | 00:09:16,623 --> 00:09:18,392 717 | 我可以设置显示方式 718 | 719 | 720 | 132 721 | 00:09:18,792 --> 00:09:22,029 722 | 以便让插播式广告 723 | 刚好出现在下一个屏幕之前 724 | 725 | 726 | 133 727 | 00:09:23,096 --> 00:09:26,700 728 | prepare For Segue 729 | 是进行该设置的最佳地方 730 | 731 | 732 | 134 733 | 00:09:29,937 --> 00:09:31,138 734 | iAd让这个工作变得简单 735 | 736 | 737 | 135 738 | 00:09:31,872 --> 00:09:32,739 739 | 我所需要的不过是 740 | 741 | 742 | 136 743 | 00:09:32,806 --> 00:09:36,310 744 | 将插播式广告的显示策略 745 | 设置为“自动” 746 | 747 | 748 | 137 749 | 00:09:36,810 --> 00:09:41,682 750 | 而这让iAd在视图控件内 751 | 显示插播式广告 752 | 753 | 754 | 138 755 | 00:09:45,052 --> 00:09:47,221 756 | 当我完成设置后 757 | 我会看到它会是的样子 758 | 759 | 760 | 139 761 | 00:09:49,122 --> 00:09:51,992 762 | 我已向您展示了如何集成 763 | 横幅和插播式广告 764 | 765 | 766 | 140 767 | 00:09:52,359 --> 00:09:55,229 768 | 但是集成其他格式的广告也同样简单 769 | 770 | 771 | 141 772 | 00:09:56,396 --> 00:10:00,400 773 | 而iAd有一些工具 774 | 让我对集成效果进行测试 775 | 776 | 777 | 142 778 | 00:10:00,467 --> 00:10:03,770 779 | 因此我能确保在发布之前 780 | 已经正确执行了所有操作 781 | 782 | 783 | 143 784 | 00:10:05,772 --> 00:10:07,207 785 | 对于你们中的一些人 786 | 787 | 788 | 144 789 | 00:10:07,541 --> 00:10:10,310 790 | 在这个阶段仍可能 791 | 有一些app开发工作 792 | 793 | 794 | 145 795 | 00:10:11,044 --> 00:10:15,816 796 | 但是既然我已经在早期花时间 797 | 将iAd整合到我的开发周期内 798 | 799 | 800 | 146 801 | 00:10:16,283 --> 00:10:19,052 802 | 所以我不必担心 803 | 日后回来再继续开发工作 804 | 805 | 806 | 147 807 | 00:10:19,486 --> 00:10:22,890 808 | 而且一旦我发布了app 809 | 就可以开始创造年收入了 810 | 811 | 812 | 148 813 | 00:10:26,593 --> 00:10:28,595 814 | 那么现在我们已经 815 | 发布了LiteRight 816 | 817 | 818 | 149 819 | 00:10:29,997 --> 00:10:31,532 820 | 它目前就在App Store中 821 | 822 | 823 | 150 824 | 00:10:31,632 --> 00:10:33,901 825 | 用户正在下载和使用这个app 826 | 827 | 828 | 151 829 | 00:10:36,136 --> 00:10:39,173 830 | 而且基于刚才我为大家展示的集成操作 831 | 广告也正在其中运行 832 | 833 | 834 | 152 835 | 00:10:39,573 --> 00:10:42,809 836 | 这里是一个横幅广告 837 | 和一个插播式广告的例子 838 | 839 | 840 | 153 841 | 00:10:45,913 --> 00:10:49,516 842 | 而且我可以看到在我的app中 843 | 我从广告创造了多少收入 844 | 845 | 846 | 154 847 | 00:10:50,150 --> 00:10:52,920 848 | 只须查看iTunes Connect 849 | 中的报告入口 850 | 851 | 852 | 155 853 | 00:10:53,353 --> 00:10:57,357 854 | 或使用即将推出的 855 | 发布者报告API即可 856 | 857 | 858 | 156 859 | 00:10:59,293 --> 00:11:03,664 860 | 因为我已经在早期投入精力 861 | 将iAd集成到了我的开发周期内 862 | 863 | 864 | 157 865 | 00:11:04,064 --> 00:11:05,399 866 | 它已经在产生回报 867 | 868 | 869 | 158 870 | 00:11:09,336 --> 00:11:11,939 871 | 现在让我们看一下如何 872 | 进行其他聪明的 873 | 874 | 875 | 159 876 | 00:11:12,339 --> 00:11:14,174 877 | 将会扩大我的app安装基础的投入 878 | 879 | 880 | 160 881 | 00:11:18,278 --> 00:11:21,715 882 | 那么我将通过在app中展示广告 883 | 而获得稳定的收入流水 884 | 885 | 886 | 161 887 | 00:11:22,749 --> 00:11:27,054 888 | 您们中的一些不会选择以这种方式 889 | 将您的app货币化这也是没问题的 890 | 891 | 892 | 162 893 | 00:11:28,222 --> 00:11:34,428 894 | 然而 您们多数人关心推动用户下载 895 | 以及对您的app的使用 896 | 897 | 898 | 163 899 | 00:11:36,530 --> 00:11:40,200 900 | 而为了达到目标 901 | 您需要积极地投入精力推广您的app 902 | 903 | 904 | 164 905 | 00:11:40,434 --> 00:11:42,669 906 | 这也是 907 | 我在LiteRight上将要做的 908 | 909 | 910 | 165 911 | 00:11:44,571 --> 00:11:46,273 912 | 我的成长战略的一部分是 913 | 914 | 915 | 166 916 | 00:11:46,340 --> 00:11:49,943 917 | 将我通过在app中展示广告 918 | 赚取的一些收入 919 | 920 | 921 | 167 922 | 00:11:50,477 --> 00:11:53,614 923 | 重新投入到市场营销活动中 924 | 来推广LiteRight 925 | 926 | 927 | 168 928 | 00:11:54,047 --> 00:11:55,716 929 | 以便扩大我的用户基础 930 | 931 | 932 | 169 933 | 00:11:57,150 --> 00:12:00,521 934 | 随着更多的人发现 下载 935 | 并使用我的app 936 | 937 | 938 | 170 939 | 00:12:01,288 --> 00:12:03,724 940 | 也会有更多的人 941 | 接触到我的app中的广告 942 | 943 | 944 | 171 945 | 00:12:04,324 --> 00:12:07,027 946 | 这将进一步提高货币化的程度 947 | 948 | 949 | 172 950 | 00:12:07,794 --> 00:12:09,897 951 | 而这也将创造一个持续的循环 952 | 953 | 954 | 173 955 | 00:12:11,398 --> 00:12:15,602 956 | 因此我既可以进行货币化 957 | 也可以进行推广 958 | 959 | 960 | 174 961 | 00:12:16,603 --> 00:12:20,040 962 | 但是经验表明 963 | 当我两者都做的话会是最成功的 964 | 965 | 966 | 175 967 | 00:12:22,009 --> 00:12:24,778 968 | 刚才我们谈了 969 | 如何使用iAd进行货币化 970 | 971 | 972 | 176 973 | 00:12:26,680 --> 00:12:27,548 974 | 现在让我们谈谈 975 | 976 | 977 | 177 978 | 00:12:27,614 --> 00:12:30,784 979 | 如何使用iAd对我的app 980 | 进行推广并驱动增长 981 | 982 | 983 | 178 984 | 00:12:34,788 --> 00:12:37,558 985 | 我的LiteRight推广计划 986 | 分为两个方向 987 | 988 | 989 | 179 990 | 00:12:38,759 --> 00:12:41,662 991 | 首先 我需要获取新的用户 992 | 993 | 994 | 180 995 | 00:12:42,663 --> 00:12:45,999 996 | 因为App Store里 997 | 有超过150万的app 998 | 999 | 1000 | 181 1001 | 00:12:46,066 --> 00:12:50,204 1002 | 我需要某种途径 1003 | 让我的app脱颖而出被人发现 1004 | 1005 | 1006 | 182 1007 | 00:12:51,972 --> 00:12:56,510 1008 | 为此我将积极推广LiteRight 1009 | 并为我的app创造知名度 1010 | 1011 | 1012 | 183 1013 | 00:12:58,478 --> 00:13:02,850 1014 | iAd有帮助我推广app的工具 1015 | 无须任何额外代码 1016 | 1017 | 1018 | 184 1019 | 00:13:03,684 --> 00:13:05,752 1020 | 我们将在稍后的讲座中 1021 | 为您展示如何做到 1022 | 1023 | 1024 | 185 1025 | 00:13:07,454 --> 00:13:10,057 1026 | 而且根据 1027 | 我从其他app上学到的经验 1028 | 1029 | 1030 | 186 1031 | 00:13:10,891 --> 00:13:13,727 1032 | 我不能只关注获得新用户 1033 | 1034 | 1035 | 187 1036 | 00:13:16,029 --> 00:13:20,767 1037 | 我也要吸引已下载我的app的 1038 | 现有用户的注意力 1039 | 1040 | 1041 | 188 1042 | 00:13:21,235 --> 00:13:25,706 1043 | 因为四分之一被下载的app 1044 | 永远不会被使用 1045 | 1046 | 1047 | 189 1048 | 00:13:26,673 --> 00:13:32,479 1049 | 而且在下载了某个app的一周后 1050 | 只有32%的用户会继续使用它 1051 | 1052 | 1053 | 190 1054 | 00:13:34,581 --> 00:13:37,284 1055 | 为了有效地吸引那些 1056 | 已经下载的用户的注意力 1057 | 1058 | 1059 | 191 1060 | 00:13:37,851 --> 00:13:40,521 1061 | 我需要了解他们是哪类用户 1062 | 1063 | 1064 | 192 1065 | 00:13:41,321 --> 00:13:45,225 1066 | 以便让我能量身定做营销信息 1067 | 并相应地定向投放我的广告开支 1068 | 1069 | 1070 | 193 1071 | 00:13:46,560 --> 00:13:51,298 1072 | 为此我将需要根据我的用户 1073 | 在我的app中的行为对他们进行划分 1074 | 1075 | 1076 | 194 1077 | 00:13:53,133 --> 00:13:56,069 1078 | iAd让我建立数百个受众分组 1079 | 1080 | 1081 | 195 1082 | 00:13:57,271 --> 00:14:01,074 1083 | 但是开始时我将只把用户 1084 | 分为两个自定义组 1085 | 1086 | 1087 | 196 1088 | 00:14:02,476 --> 00:14:06,547 1089 | 一组是休眠用户 1090 | 指的是那些已下载但是不再积极的用户 1091 | 1092 | 1093 | 197 1094 | 00:14:07,281 --> 00:14:10,184 1095 | 对于他们我打算 1096 | 通过特价促销进行推广 1097 | 1098 | 1099 | 198 1100 | 00:14:12,252 --> 00:14:14,454 1101 | 另一组是初学者安装包购买组 1102 | 1103 | 1104 | 199 1105 | 00:14:14,922 --> 00:14:18,425 1106 | 这些是已购买了我app中 1107 | 滤镜初学者安装包的用户 1108 | 1109 | 1110 | 200 1111 | 00:14:19,393 --> 00:14:22,629 1112 | 对于他们 我打算 1113 | 推广我们的白金滤镜安装包 1114 | 1115 | 1116 | 201 1117 | 00:14:24,765 --> 00:14:26,767 1118 | 如果要创建一个自定义受众组 1119 | 1120 | 1121 | 202 1122 | 00:14:26,967 --> 00:14:31,071 1123 | 让我们看一下如何将受众分组代码 1124 | 集成到我的app中 1125 | 1126 | 1127 | 203 1128 | 00:14:31,438 --> 00:14:33,440 1129 | 使其作为对我的app的下一个更新 1130 | 1131 | 1132 | 204 1133 | 00:14:34,374 --> 00:14:37,277 1134 | 我将以初学者安装包购买组为例 1135 | 1136 | 1137 | 205 1138 | 00:14:40,747 --> 00:14:45,719 1139 | 首先 1140 | 我将查看用户是否购买了初学者滤镜 1141 | 1142 | 1143 | 206 1144 | 00:14:45,786 --> 00:14:50,891 1145 | 意味着我应该把他们添加到 1146 | 初学者安装包购买组 1147 | 1148 | 1149 | 207 1150 | 00:14:53,527 --> 00:14:56,129 1151 | 然后我需要获得 1152 | 对共享客户端的引用 1153 | 1154 | 1155 | 208 1156 | 00:14:57,431 --> 00:15:01,568 1157 | 接下来我需要告诉iAd 1158 | 要把用户添加到哪些分组 1159 | 1160 | 1161 | 209 1162 | 00:15:01,835 --> 00:15:05,606 1163 | 实现的途径就是跟踪那些 1164 | 已经购买初学者滤镜安装包的用户行为 1165 | 1166 | 1167 | 210 1168 | 00:15:08,108 --> 00:15:12,346 1169 | 我可以通过调用 1170 | add Client To Segments实现 1171 | 1172 | 1173 | 211 1174 | 00:15:13,046 --> 00:15:14,882 1175 | 这个方法使用了两个参数 1176 | 1177 | 1178 | 212 1179 | 00:15:16,550 --> 00:15:17,384 1180 | 第一个 1181 | 1182 | 1183 | 213 1184 | 00:15:17,584 --> 00:15:22,022 1185 | 是我从iAd WorkBench 1186 | 工具获取的分组ID 1187 | 1188 | 1189 | 214 1190 | 00:15:23,323 --> 00:15:26,026 1191 | 如果我试图发送一些随机分组ID 1192 | 1193 | 1194 | 215 1195 | 00:15:26,593 --> 00:15:27,594 1196 | 它们将会被忽略 1197 | 1198 | 1199 | 216 1200 | 00:15:27,761 --> 00:15:31,265 1201 | 因此我必须从 1202 | iAd WorkBench获取它们 1203 | 1204 | 1205 | 217 1206 | 00:15:31,331 --> 00:15:33,967 1207 | 而我们将在今天的演示的 1208 | 稍晚时候向您展示从哪里获取 1209 | 1210 | 1211 | 218 1212 | 00:15:36,904 --> 00:15:37,738 1213 | 第二步 1214 | 1215 | 1216 | 219 1217 | 00:15:37,804 --> 00:15:40,741 1218 | 我将把replace existing 1219 | 设为false 1220 | 1221 | 1222 | 220 1223 | 00:15:41,141 --> 00:15:46,146 1224 | 因为我不希望这些用户 1225 | 被从他们在的任何分组中移除 1226 | 1227 | 1228 | 221 1229 | 00:15:48,615 --> 00:15:51,952 1230 | 现在既然我已经完成了 1231 | 适当的用户分组准备工作 1232 | 1233 | 1234 | 222 1235 | 00:15:52,753 --> 00:15:56,123 1236 | 我已准备好为LiteRight 1237 | 执行我的推广计划 1238 | 1239 | 1240 | 223 1241 | 00:15:57,291 --> 00:15:59,793 1242 | 为此 1243 | 我将使用iAd WorkBench 1244 | 1245 | 1246 | 224 1247 | 00:16:00,928 --> 00:16:04,531 1248 | iAd的自助推广管理工具 1249 | 1250 | 1251 | 225 1252 | 00:16:05,999 --> 00:16:12,806 1253 | 它让我全面控制我的app推广活动的 1254 | 创建 管理和优化 1255 | 1256 | 1257 | 226 1258 | 00:16:13,440 --> 00:16:15,442 1259 | 而且可以让我获取全面的报告 1260 | 1261 | 1262 | 227 1263 | 00:16:19,279 --> 00:16:25,419 1264 | 这里您可以看到我已经创建了 1265 | 一些推广活动用以执行我的推广计划 1266 | 1267 | 1268 | 228 1269 | 00:16:25,919 --> 00:16:29,656 1270 | 以便获得新用户 1271 | 并重新吸引休眠用户 1272 | 1273 | 1274 | 229 1275 | 00:16:31,191 --> 00:16:33,160 1276 | 接下来我们将使用 1277 | iAd WorkBench 1278 | 1279 | 1280 | 230 1281 | 00:16:33,227 --> 00:16:37,064 1282 | 再次将我的初学者安装包 1283 | 购买受众组作为推广对象 1284 | 1285 | 1286 | 231 1287 | 00:16:37,331 --> 00:16:39,533 1288 | 来推广我的白金滤镜安装包 1289 | 1290 | 1291 | 232 1292 | 00:16:40,334 --> 00:16:44,671 1293 | 对于此活动 1294 | 我们将从用户点击广告开始 1295 | 1296 | 1297 | 233 1298 | 00:16:45,005 --> 00:16:47,608 1299 | 直接将他们带入我的app中的页面 1300 | 1301 | 1302 | 234 1303 | 00:16:48,008 --> 00:16:49,910 1304 | 在那里他们可以进行app内购买 1305 | 1306 | 1307 | 235 1308 | 00:16:51,178 --> 00:16:53,580 1309 | 而我将 1310 | 交由 莎尚克 来进行演示 1311 | 1312 | 1313 | 236 1314 | 00:16:56,016 --> 00:16:56,850 1315 | 谢谢 1316 | 1317 | 1318 | 237 1319 | 00:17:02,356 --> 00:17:03,190 1320 | 谢谢 卡洛 1321 | 1322 | 1323 | 238 1324 | 00:17:03,891 --> 00:17:04,858 1325 | 大家上午好 1326 | 1327 | 1328 | 239 1329 | 00:17:05,092 --> 00:17:07,694 1330 | 我叫莎尚克·珐德克 1331 | 是iAd团队的一员 1332 | 1333 | 1334 | 240 1335 | 00:17:08,996 --> 00:17:12,965 1336 | 今天我将展示iAd WorkBench中 1337 | 两大令人惊叹的特性 1338 | 1339 | 1340 | 241 1341 | 00:17:13,700 --> 00:17:18,372 1342 | 首先我将向您展示 1343 | 您在哪里可以查看并管理您的受众组 1344 | 1345 | 1346 | 242 1347 | 00:17:19,606 --> 00:17:21,675 1348 | 其次我想向您展示 1349 | 1350 | 1351 | 243 1352 | 00:17:21,742 --> 00:17:25,579 1353 | 将那些受众组作为对象进行再次推广 1354 | 1355 | 1356 | 244 1357 | 00:17:26,079 --> 00:17:27,981 1358 | 是多么的容易 1359 | 1360 | 1361 | 245 1362 | 00:17:28,549 --> 00:17:29,550 1363 | 那么让我们开始 1364 | 1365 | 1366 | 246 1367 | 00:17:38,825 --> 00:17:42,196 1368 | 当我登入iAd WorkBench 1369 | 就会看到我的控制面板 1370 | 1371 | 1372 | 247 1373 | 00:17:42,963 --> 00:17:47,334 1374 | 在这里您可以看到 1375 | 您的所有app上的推广活动 1376 | 1377 | 1378 | 248 1379 | 00:17:49,369 --> 00:17:51,438 1380 | 为了查看您的受众组 1381 | 1382 | 1383 | 249 1384 | 00:17:52,072 --> 00:17:57,511 1385 | 您可以使用页面右侧的下拉式菜单 1386 | 转到my audiences页面 1387 | 1388 | 1389 | 250 1390 | 00:17:58,912 --> 00:18:01,915 1391 | 这里在 1392 | my audiences页面上 1393 | 1394 | 1395 | 251 1396 | 00:18:02,783 --> 00:18:07,821 1397 | 您可以看到在您的各个app上 1398 | 所定义的所有受众组 1399 | 1400 | 1401 | 252 1402 | 00:18:10,190 --> 00:18:12,392 1403 | 对于您创建的每个受众组 1404 | 1405 | 1406 | 253 1407 | 00:18:12,960 --> 00:18:16,763 1408 | iAd WorkBench 1409 | 分配一个独一无二的组ID 1410 | 1411 | 1412 | 254 1413 | 00:18:18,332 --> 00:18:22,002 1414 | 比如 对于LiteRight 1415 | 初学者安装包购买 1416 | 1417 | 1418 | 255 1419 | 00:18:22,369 --> 00:18:25,572 1420 | 这是iAd WorkBench 1421 | 分配给我的组ID 1422 | 1423 | 1424 | 256 1425 | 00:18:26,807 --> 00:18:31,245 1426 | 这是您在代码中用于向该组提交指示 1427 | 1428 | 1429 | 257 1430 | 00:18:31,545 --> 00:18:34,181 1431 | 并开始添加用户的ID 1432 | 1433 | 1434 | 258 1435 | 00:18:36,350 --> 00:18:38,552 1436 | 通过那种方法我可以看到 1437 | 1438 | 1439 | 259 1440 | 00:18:38,619 --> 00:18:45,192 1441 | 在我的初学者安装包购买组 1442 | 已经有了一万多个用户 1443 | 1444 | 1445 | 260 1446 | 00:18:48,896 --> 00:18:53,400 1447 | 当然 随着越来越多的用户 1448 | 下载我的初学者安装包 1449 | 1450 | 1451 | 261 1452 | 00:18:53,867 --> 00:18:55,435 1453 | 这个数字将持续更新 1454 | 1455 | 1456 | 262 1457 | 00:18:57,838 --> 00:19:01,041 1458 | 现在让我们看下如何利用这个组 1459 | 1460 | 1461 | 263 1462 | 00:19:01,542 --> 00:19:06,146 1463 | 为我的最新白金滤镜安装包 1464 | 做一个再次定向推广活动 1465 | 1466 | 1467 | 264 1468 | 00:19:09,516 --> 00:19:12,853 1469 | 为此 我回到控制面板 1470 | 1471 | 1472 | 265 1473 | 00:19:13,620 --> 00:19:18,225 1474 | 并点击create campaign 1475 | 按钮来启动这个活动 1476 | 1477 | 1478 | 266 1479 | 00:19:21,595 --> 00:19:25,399 1480 | 我要选择我希望 1481 | 推广一个app或是产品 1482 | 1483 | 1484 | 267 1485 | 00:19:25,966 --> 00:19:28,535 1486 | 在此例中 我将推广我的app 1487 | 因此我选择"app" 1488 | 1489 | 1490 | 268 1491 | 00:19:30,270 --> 00:19:33,540 1492 | 正如您所看到的 1493 | 我的所有app都已被列出 1494 | 1495 | 1496 | 269 1497 | 00:19:34,608 --> 00:19:36,643 1498 | 我为这次活动选择LiteRight 1499 | 1500 | 1501 | 270 1502 | 00:19:38,612 --> 00:19:42,049 1503 | 然后我要选择是否希望在app网络 1504 | 或iTunes Radio上 1505 | 1506 | 1507 | 271 1508 | 00:19:42,783 --> 00:19:45,452 1509 | 推广并运行此广告 1510 | 1511 | 1512 | 272 1513 | 00:19:46,520 --> 00:19:47,888 1514 | 我选择app网络 1515 | 1516 | 1517 | 273 1518 | 00:19:48,155 --> 00:19:55,028 1519 | 而且我看到我的广告 1520 | 将在已经支持它的100多个国家运行 1521 | 1522 | 1523 | 274 1524 | 00:19:57,431 --> 00:19:59,366 1525 | 接下来我要选择 1526 | 我的出价类型 1527 | 1528 | 1529 | 275 1530 | 00:20:00,901 --> 00:20:04,905 1531 | CPC 1532 | 即按照每次点击计费 1533 | 1534 | 1535 | 276 1536 | 00:20:05,439 --> 00:20:07,441 1537 | 或CPM 1538 | 即按照每千次展示计费 1539 | 1540 | 1541 | 277 1542 | 00:20:08,809 --> 00:20:09,643 1543 | 对于此次活动 1544 | 1545 | 1546 | 278 1547 | 00:20:09,710 --> 00:20:14,114 1548 | 因为我只想当用户 1549 | 点击我的横幅广告时我才付费 1550 | 1551 | 1552 | 279 1553 | 00:20:14,314 --> 00:20:15,549 1554 | 所以我将选择CPC 1555 | 1556 | 1557 | 280 1558 | 00:20:17,251 --> 00:20:21,522 1559 | 让我们把这个活动命名为 1560 | 1561 | 1562 | 281 1563 | 00:20:23,190 --> 00:20:24,858 1564 | LiteRight白金推广活动 1565 | 1566 | 1567 | 282 1568 | 00:20:29,096 --> 00:20:32,900 1569 | 接下来我会看到 1570 | 此推广活动的规则列表 1571 | 1572 | 1573 | 283 1574 | 00:20:33,400 --> 00:20:34,401 1575 | 我还没有任何规则 1576 | 1577 | 1578 | 284 1579 | 00:20:35,169 --> 00:20:37,738 1580 | 那么让我向您展示如何创建规则 1581 | 1582 | 1583 | 285 1584 | 00:20:38,405 --> 00:20:39,940 1585 | 点击创建规则按钮 1586 | 1587 | 1588 | 286 1589 | 00:20:41,708 --> 00:20:45,445 1590 | 首先我选择希望这个广告 1591 | 在哪个国家运行 1592 | 1593 | 1594 | 287 1595 | 00:20:47,080 --> 00:20:48,282 1596 | 我选择美国 1597 | 1598 | 1599 | 288 1600 | 00:20:49,416 --> 00:20:51,852 1601 | 而现在对于我的白金滤镜安装包 1602 | 1603 | 1604 | 289 1605 | 00:20:52,586 --> 00:20:58,458 1606 | 我想特别针对那些 1607 | 已经下载了初学者安装包的用户 1608 | 1609 | 1610 | 290 1611 | 00:20:59,760 --> 00:21:04,798 1612 | 在此例中我将把 1613 | “再次定向推广”选项 1614 | 1615 | 1616 | 291 1617 | 00:21:07,801 --> 00:21:12,105 1618 | 选择为yes 1619 | 如您所见我的所有受众组都已在此列出 1620 | 1621 | 1622 | 292 1623 | 00:21:12,973 --> 00:21:16,043 1624 | 这与我们在my audiences 1625 | 看到的相同视图 1626 | 1627 | 1628 | 293 1629 | 00:21:17,044 --> 00:21:17,945 1630 | 对于此次推广活动 1631 | 1632 | 1633 | 294 1634 | 00:21:18,011 --> 00:21:23,417 1635 | 我想影响一万多个LiteRight 1636 | 初学者安装包的购买者 1637 | 1638 | 1639 | 295 1640 | 00:21:23,550 --> 00:21:24,518 1641 | 因此我将选择它 1642 | 1643 | 1644 | 296 1645 | 00:21:26,954 --> 00:21:29,256 1646 | 除了受众组外 1647 | 1648 | 1649 | 297 1650 | 00:21:29,957 --> 00:21:32,492 1651 | 我还可以选择其他定向推广参数 1652 | 1653 | 1654 | 298 1655 | 00:21:33,994 --> 00:21:35,395 1656 | 比如 如果我希望 1657 | 1658 | 1659 | 299 1660 | 00:21:36,530 --> 00:21:40,267 1661 | 我的广告运行在特定的设备上 1662 | iPhone或iPad 1663 | 1664 | 1665 | 300 1666 | 00:21:42,069 --> 00:21:46,740 1667 | 或者我可以选择用户的不同地区 1668 | 1669 | 1670 | 301 1671 | 00:21:48,175 --> 00:21:51,578 1672 | 或者我还可以指定app频道属性 1673 | 1674 | 1675 | 302 1676 | 00:21:52,279 --> 00:21:54,615 1677 | 它是我希望运行的广告 1678 | 1679 | 1680 | 303 1681 | 00:21:54,948 --> 00:21:56,483 1682 | 在iTunes上对app的分类 1683 | 1684 | 1685 | 304 1686 | 00:21:59,086 --> 00:22:01,822 1687 | 或者我可以安排我的广告 1688 | 在特定的时间运行 1689 | 1690 | 1691 | 305 1692 | 00:22:01,889 --> 00:22:03,590 1693 | 一天中的某个时间或一周中的某些天 1694 | 1695 | 1696 | 306 1697 | 00:22:05,626 --> 00:22:08,695 1698 | 在选定了这些定向推广属性之后 1699 | 1700 | 1701 | 307 1702 | 00:22:08,962 --> 00:22:11,465 1703 | 我可以看到我能影响到一万多用户 1704 | 1705 | 1706 | 308 1707 | 00:22:12,232 --> 00:22:16,837 1708 | 它超过了对再次定向推广的 1709 | 最小用户数要求 1710 | 1711 | 1712 | 309 1713 | 00:22:17,137 --> 00:22:18,071 1714 | 因此我是符合要求的 1715 | 1716 | 1717 | 310 1718 | 00:22:20,240 --> 00:22:22,109 1719 | 接下来选择我的广告类型 1720 | 1721 | 1722 | 311 1723 | 00:22:22,543 --> 00:22:23,644 1724 | 它将是一个横幅广告 1725 | 1726 | 1727 | 312 1728 | 00:22:24,511 --> 00:22:27,981 1729 | 而且我将选择 1730 | app深度链接的目标类型 1731 | 1732 | 1733 | 313 1734 | 00:22:28,949 --> 00:22:32,319 1735 | 在下个屏幕上我将为大家 1736 | 讲一下app深度链接 1737 | 1738 | 1739 | 314 1740 | 00:22:33,520 --> 00:22:35,022 1741 | 我选择我的广告运行日期 1742 | 1743 | 1744 | 315 1745 | 00:22:35,722 --> 00:22:38,158 1746 | 让它从明天开始持续一个月 1747 | 1748 | 1749 | 316 1750 | 00:22:40,627 --> 00:22:42,796 1751 | 然后我为推广活动指定我的预算 1752 | 1753 | 1754 | 317 1755 | 00:22:43,997 --> 00:22:46,567 1756 | 我将花费比如说3000美元 1757 | 1758 | 1759 | 318 1760 | 00:22:48,135 --> 00:22:49,870 1761 | 然后输入我的CPC出价 1762 | 1763 | 1764 | 319 1765 | 00:22:51,705 --> 00:22:53,507 1766 | 比如说 50美分 1767 | 1768 | 1769 | 320 1770 | 00:22:54,241 --> 00:22:56,677 1771 | 现在iAd是一个基于拍卖的市场 1772 | 1773 | 1774 | 321 1775 | 00:22:57,544 --> 00:23:01,582 1776 | 因此我明确知道不会付出超过50美分 1777 | 1778 | 1779 | 322 1780 | 00:23:02,616 --> 00:23:04,151 1781 | 实际上 我可以付得更少 1782 | 1783 | 1784 | 323 1785 | 00:23:05,919 --> 00:23:07,054 1786 | 让我们为规则命名 1787 | 1788 | 1789 | 324 1790 | 00:23:13,293 --> 00:23:15,062 1791 | 一旦我定义了规则 1792 | 1793 | 1794 | 325 1795 | 00:23:15,863 --> 00:23:22,503 1796 | 在下个屏幕上我就会看见一个 1797 | 我为此次推广活动定义的规则列表 1798 | 1799 | 1800 | 326 1801 | 00:23:23,136 --> 00:23:24,872 1802 | 如果愿意 您可以定义多个规则 1803 | 1804 | 1805 | 327 1806 | 00:23:25,405 --> 00:23:27,741 1807 | 但是目前暂且让我们先只有一个规则 1808 | 1809 | 1810 | 328 1811 | 00:23:29,243 --> 00:23:30,677 1812 | 点击“下一步” 1813 | 1814 | 1815 | 329 1816 | 00:23:31,979 --> 00:23:33,213 1817 | 开始创建您的广告 1818 | 1819 | 1820 | 330 1821 | 00:23:36,350 --> 00:23:37,584 1822 | 现在为了定义一条广告 1823 | 1824 | 1825 | 331 1826 | 00:23:38,285 --> 00:23:41,722 1827 | 您将定义点击前和点击后的体验 1828 | 1829 | 1830 | 332 1831 | 00:23:42,956 --> 00:23:46,093 1832 | 对于我的广告 1833 | 我想让它在点击前是一个横幅 1834 | 1835 | 1836 | 333 1837 | 00:23:46,793 --> 00:23:50,964 1838 | 我想让广告在所有设备上运行 1839 | iPhones iPads 1840 | 1841 | 1842 | 334 1843 | 00:23:51,131 --> 00:23:52,900 1844 | 因此我将选择 1845 | “universal” 1846 | 1847 | 1848 | 335 1849 | 00:23:54,234 --> 00:23:55,502 1850 | 我选择自己的语言 1851 | 1852 | 1853 | 336 1854 | 00:23:57,437 --> 00:23:58,705 1855 | 而至于创意方面 1856 | 1857 | 1858 | 337 1859 | 00:23:59,907 --> 00:24:03,177 1860 | 我使用iAd WorkBench 1861 | 为我提供的一套 1862 | 1863 | 1864 | 338 1865 | 00:24:03,243 --> 00:24:07,281 1866 | 有不同颜色方案的标准模版 1867 | 1868 | 1869 | 339 1870 | 00:24:08,582 --> 00:24:11,618 1871 | 或者如果我愿意 1872 | 我可以从我的桌面电脑上传图片 1873 | 1874 | 1875 | 340 1876 | 00:24:12,753 --> 00:24:15,722 1877 | 目前让我们快速采用一个标准模版 1878 | 1879 | 1880 | 341 1881 | 00:24:18,425 --> 00:24:20,127 1882 | 我可以给它定一个标题 1883 | 1884 | 1885 | 342 1886 | 00:24:26,033 --> 00:24:29,636 1887 | 一条表明它是我的白金安装包的信息 1888 | 1889 | 1890 | 343 1891 | 00:24:31,271 --> 00:24:32,973 1892 | 以及一条“行为召唤”文本 1893 | 1894 | 1895 | 344 1896 | 00:24:36,510 --> 00:24:37,377 1897 | 如您所见 1898 | 1899 | 1900 | 345 1901 | 00:24:37,611 --> 00:24:42,349 1902 | 我将看到它在设备上 1903 | 将是何种样子的预览 1904 | 1905 | 1906 | 346 1907 | 00:24:42,516 --> 00:24:47,287 1908 | 实际上 1909 | 我可以获得它在所有不同设备上的预览 1910 | 1911 | 1912 | 347 1913 | 00:24:51,291 --> 00:24:55,429 1914 | 现在 我该选择 1915 | 我希望用户在点击后获得什么样的体验 1916 | 1917 | 1918 | 348 1919 | 00:24:57,764 --> 00:24:59,733 1920 | 我将选择app深度链接 1921 | 1922 | 1923 | 349 1924 | 00:25:00,200 --> 00:25:02,870 1925 | 因此在此例中 1926 | 针对我的白金安装包 1927 | 1928 | 1929 | 350 1930 | 00:25:03,337 --> 00:25:05,205 1931 | 每次用户点击横幅的时候 1932 | 1933 | 1934 | 351 1935 | 00:25:05,906 --> 00:25:09,309 1936 | 我都希望我的app在设备上打开 1937 | 1938 | 1939 | 352 1940 | 00:25:09,910 --> 00:25:16,950 1941 | 并把用户直接带到能够购买 1942 | 我的白金滤镜安装包的页面内 1943 | 1944 | 1945 | 353 1946 | 00:25:17,317 --> 00:25:18,285 1947 | 进行app内购买 1948 | 1949 | 1950 | 354 1951 | 00:25:19,987 --> 00:25:24,424 1952 | 为了对此进行配置 1953 | 我需要插入一个深度链接URL 1954 | 1955 | 1956 | 355 1957 | 00:25:26,994 --> 00:25:29,530 1958 | 我插入了我的自定义方案 1959 | 1960 | 1961 | 356 1962 | 00:25:30,397 --> 00:25:34,768 1963 | 我希望直接转到白金滤镜安装包 1964 | 1965 | 1966 | 357 1967 | 00:25:35,302 --> 00:25:39,006 1968 | 在进行app内购买的页面 1969 | 1970 | 1971 | 358 1972 | 00:25:40,774 --> 00:25:44,311 1973 | 现在 大多数时间我的app将被 1974 | 安装到用户的设备上 1975 | 1976 | 1977 | 359 1978 | 00:25:44,645 --> 00:25:45,746 1979 | 但是出于某种原因 1980 | 1981 | 1982 | 360 1983 | 00:25:46,046 --> 00:25:50,817 1984 | 如果app未安装 1985 | 在用户点击横幅之后 1986 | 1987 | 1988 | 361 1989 | 00:25:51,218 --> 00:25:54,821 1990 | 我可以直接把他们带到 1991 | iTunes App Store 1992 | 1993 | 1994 | 362 1995 | 00:25:55,722 --> 00:25:56,890 1996 | 以便重新下载app 1997 | 1998 | 1999 | 363 2000 | 00:25:57,791 --> 00:26:00,894 2001 | 或者如果我希望把他们 2002 | 带到另一个我选择的网站 2003 | 2004 | 2005 | 364 2006 | 00:26:01,094 --> 00:26:01,995 2007 | 我也可以做到 2008 | 2009 | 2010 | 365 2011 | 00:26:02,796 --> 00:26:05,933 2012 | 现在我希望把他们带到下载页 2013 | 2014 | 2015 | 366 2016 | 00:26:11,004 --> 00:26:14,741 2017 | 我将为目标命名 2018 | LiteRight深度链接 2019 | 2020 | 2021 | 367 2022 | 00:26:16,043 --> 00:26:18,946 2023 | 我把创建的规则与这条进行关联 2024 | 2025 | 2026 | 368 2027 | 00:26:20,447 --> 00:26:21,448 2028 | 并为广告命名 2029 | 2030 | 2031 | 369 2032 | 00:26:27,120 --> 00:26:27,988 2033 | 点击"下一步" 2034 | 2035 | 2036 | 370 2037 | 00:26:32,492 --> 00:26:33,460 2038 | 在下一个屏幕上 2039 | 2040 | 2041 | 371 2042 | 00:26:33,794 --> 00:26:37,130 2043 | 您将会看到您已为此推广活动 2044 | 创建的所有广告 2045 | 2046 | 2047 | 372 2048 | 00:26:37,497 --> 00:26:38,665 2049 | 我们只是创建了这条广告 2050 | 2051 | 2052 | 373 2053 | 00:26:39,366 --> 00:26:42,402 2054 | 再次强调 2055 | 如果您愿意 您可以创建更多广告 2056 | 2057 | 2058 | 374 2059 | 00:26:43,337 --> 00:26:45,005 2060 | 但是目前 让我们只保持一条广告 2061 | 2062 | 2063 | 375 2064 | 00:26:47,140 --> 00:26:50,611 2065 | 点击 "下一步" 2066 | 查看您目前为止为此推广活动 2067 | 2068 | 2069 | 376 2070 | 00:26:50,844 --> 00:26:51,812 2071 | 所做的设置的概览 2072 | 2073 | 2074 | 377 2075 | 00:26:52,779 --> 00:26:54,381 2076 | 我可以看到我创建的那条规则 2077 | 2078 | 2079 | 378 2080 | 00:26:54,915 --> 00:26:57,718 2081 | 我可以看到与该条规则关联的广告 2082 | 2083 | 2084 | 379 2085 | 00:26:59,620 --> 00:27:02,122 2086 | 我也可以输入我的付款信息 2087 | 2088 | 2089 | 380 2090 | 00:27:02,656 --> 00:27:04,391 2091 | 因为当我注册的时候 2092 | 2093 | 2094 | 381 2095 | 00:27:04,458 --> 00:27:07,494 2096 | iAd WorkBench已经 2097 | 有了我的信用卡 2098 | 2099 | 2100 | 382 2101 | 00:27:07,561 --> 00:27:08,795 2102 | 因此我将直接使用它 2103 | 2104 | 2105 | 383 2106 | 00:27:10,564 --> 00:27:11,398 2107 | 就是这样 2108 | 2109 | 2110 | 384 2111 | 00:27:11,465 --> 00:27:14,968 2112 | 我可以提交这个推广活动了 2113 | 2114 | 2115 | 385 2116 | 00:27:17,371 --> 00:27:19,039 2117 | 一旦您提交了推广活动 2118 | 2119 | 2120 | 386 2121 | 00:27:19,773 --> 00:27:24,311 2122 | 您所创建的所有广告将 2123 | 通过一个认证流程 2124 | 2125 | 2126 | 387 2127 | 00:27:25,112 --> 00:27:27,548 2128 | 而一旦它们被批准 2129 | 2130 | 2131 | 388 2132 | 00:27:28,482 --> 00:27:31,185 2133 | 而且到了您规则的起始日 2134 | 2135 | 2136 | 389 2137 | 00:27:31,752 --> 00:27:33,220 2138 | 您的推广活动将开始运行 2139 | 2140 | 2141 | 390 2142 | 00:27:33,654 --> 00:27:36,523 2143 | 而且您的广告将开始服务于各种设备上 2144 | 2145 | 2146 | 391 2147 | 00:27:38,825 --> 00:27:41,261 2148 | 现在 让我为您展示 2149 | 在您创建推广活动之后 2150 | 2151 | 2152 | 392 2153 | 00:27:41,762 --> 00:27:44,565 2154 | 您如何监控您的推广活动表现 2155 | 2156 | 2157 | 393 2158 | 00:27:46,166 --> 00:27:50,437 2159 | 我刚运作了一个推广活动 2160 | 2161 | 2162 | 394 2163 | 00:27:50,504 --> 00:27:55,075 2164 | 那么让我点击推广 2165 | 活动选项卡上的分析工具部分 2166 | 2167 | 2168 | 395 2169 | 00:27:55,742 --> 00:27:57,811 2170 | 来到分析工具部分 2171 | 2172 | 2173 | 396 2174 | 00:28:05,586 --> 00:28:07,154 2175 | 分析工具控制面板页面 2176 | 2177 | 2178 | 397 2179 | 00:28:10,490 --> 00:28:15,195 2180 | 这里您可以看到针对此推广活动的 2181 | 各种度量指标 2182 | 2183 | 2184 | 398 2185 | 00:28:16,296 --> 00:28:18,365 2186 | 总花费 总展示数 2187 | 2188 | 2189 | 399 2190 | 00:28:19,399 --> 00:28:21,568 2191 | 总转化率等所有指标 2192 | 2193 | 2194 | 400 2195 | 00:28:23,170 --> 00:28:25,672 2196 | 我还可以按照特定日期范围进行筛选 2197 | 2198 | 2199 | 401 2200 | 00:28:26,740 --> 00:28:28,942 2201 | 对此数据进行切片和切块分析 2202 | 2203 | 2204 | 402 2205 | 00:28:30,477 --> 00:28:35,015 2206 | 或者我可以在活动层面上 2207 | 规则层面上 2208 | 2209 | 2210 | 403 2211 | 00:28:36,416 --> 00:28:38,752 2212 | 甚至广告层面或设备类型层面上 2213 | 查看数据 2214 | 2215 | 2216 | 404 2217 | 00:28:41,755 --> 00:28:45,859 2218 | 在您看到的图表中 2219 | 我可以设计一个特定的度量指标 2220 | 2221 | 2222 | 405 2223 | 00:28:46,159 --> 00:28:51,365 2224 | 比如 我的活动期间的每日开销 2225 | 2226 | 2227 | 406 2228 | 00:28:52,332 --> 00:28:55,669 2229 | 或者我也可以和其他度量指标叠加 2230 | 2231 | 2232 | 407 2233 | 00:28:55,969 --> 00:28:57,671 2234 | 比如 展示次数随时间的变化 2235 | 2236 | 2237 | 408 2238 | 00:28:58,906 --> 00:29:00,741 2239 | 或点击数随时间的变化 2240 | 2241 | 2242 | 409 2243 | 00:29:03,443 --> 00:29:07,114 2244 | 如果我愿意把所有的切片 2245 | 和切块分析拿到线下来做 2246 | 2247 | 2248 | 410 2249 | 00:29:07,681 --> 00:29:12,886 2250 | 我可以一直使用这里的这个图标 2251 | 下载数据 2252 | 2253 | 2254 | 411 2255 | 00:29:16,890 --> 00:29:20,961 2256 | 这些所有的功能和分析报告工具 2257 | 2258 | 2259 | 412 2260 | 00:29:21,929 --> 00:29:26,133 2261 | 我也可以用于iAd的广告API 2262 | 2263 | 2264 | 413 2265 | 00:29:26,667 --> 00:29:27,968 2266 | 如果我愿意的话 2267 | 2268 | 2269 | 414 2270 | 00:29:28,902 --> 00:29:31,605 2271 | 借助iAd WorkBench 2272 | 您还可以做许多其他的事情 2273 | 2274 | 2275 | 415 2276 | 00:29:32,206 --> 00:29:34,141 2277 | 但是现在 2278 | 我要把舞台还给卡洛 2279 | 2280 | 2281 | 416 2282 | 00:29:35,742 --> 00:29:36,577 2283 | 卡洛？ 2284 | 2285 | 2286 | 417 2287 | 00:29:43,517 --> 00:29:44,618 2288 | 谢谢 莎尚克！ 2289 | 2290 | 2291 | 418 2292 | 00:29:45,652 --> 00:29:48,255 2293 | 正如您从iAd WorkBench 2294 | 的演示可以看出 2295 | 2296 | 2297 | 419 2298 | 00:29:48,422 --> 00:29:52,826 2299 | 我对app推广活动的设置和运作 2300 | 拥有完全掌控 2301 | 2302 | 2303 | 420 2304 | 00:29:53,660 --> 00:29:56,997 2305 | 而且在关于报告的几屏页面上 2306 | 我们也能看到我的推广活动的效果 2307 | 2308 | 2309 | 421 2310 | 00:29:58,332 --> 00:30:01,034 2311 | 我不仅能在 2312 | iAd WorkBench内做 2313 | 2314 | 2315 | 422 2316 | 00:30:01,735 --> 00:30:05,105 2317 | 而且也可以使用iAd归因于API 2318 | 2319 | 2320 | 423 2321 | 00:30:05,606 --> 00:30:10,410 2322 | 来衡量效果并跟踪源自于 2323 | iAd推广活动的app下载 2324 | 2325 | 2326 | 424 2327 | 00:30:12,045 --> 00:30:14,248 2328 | 它是ADclient类的一个方法 2329 | 2330 | 2331 | 425 2332 | 00:30:14,915 --> 00:30:17,584 2333 | 叫做lookup Ad Conversion Details 2334 | 2335 | 2336 | 426 2337 | 00:30:17,651 --> 00:30:19,119 2338 | 这将返回两个日期 2339 | 2340 | 2341 | 427 2342 | 00:30:21,388 --> 00:30:25,926 2343 | 第一个是app Download Date 2344 | 即用户下载app的日期 2345 | 2346 | 2347 | 428 2348 | 00:30:28,762 --> 00:30:30,531 2349 | 第二个是 2350 | last Click Date 2351 | 2352 | 2353 | 429 2354 | 00:30:31,164 --> 00:30:36,503 2355 | 这个将是用户购买app之前 2356 | 点击广告的最后日期 2357 | 2358 | 2359 | 430 2360 | 00:30:37,971 --> 00:30:40,641 2361 | 如果两个日期都存在且是真实的 2362 | 2363 | 2364 | 431 2365 | 00:30:41,041 --> 00:30:44,545 2366 | 意味着这次app下载可直接归因于 2367 | 2368 | 2369 | 432 2370 | 00:30:44,678 --> 00:30:49,650 2371 | 一条正在推广我app的iAd互动 2372 | 和对它的点击 2373 | 2374 | 2375 | 433 2376 | 00:30:53,120 --> 00:30:53,987 2377 | 所以 就是那样 2378 | 2379 | 2380 | 434 2381 | 00:30:54,688 --> 00:30:59,259 2382 | 通过这个虚构的LiteRight app 2383 | 开发和发布之旅 2384 | 2385 | 2386 | 435 2387 | 00:31:00,093 --> 00:31:05,933 2388 | 我希望您已经明白如何 2389 | 应用最成功app开发者的最佳实践 2390 | 2391 | 2392 | 436 2393 | 00:31:08,168 --> 00:31:10,137 2394 | 即使早在设计阶段 2395 | 2396 | 2397 | 437 2398 | 00:31:10,537 --> 00:31:12,673 2399 | 他们已经在考虑商业模式 2400 | 2401 | 2402 | 438 2403 | 00:31:12,973 --> 00:31:15,209 2404 | 以及他们将如何使他们的app货币化 2405 | 2406 | 2407 | 439 2408 | 00:31:17,177 --> 00:31:19,346 2409 | 而且仅仅通过几行代码 2410 | 2411 | 2412 | 440 2413 | 00:31:19,413 --> 00:31:22,783 2414 | 您就看到将iAd集成到您的app中 2415 | 2416 | 2417 | 441 2418 | 00:31:23,717 --> 00:31:27,321 2419 | 并早在发布时就开始产生收入 2420 | 是多么的容易 2421 | 2422 | 2423 | 442 2424 | 00:31:30,123 --> 00:31:33,126 2425 | 然后我们谈到了通过精明的投资 2426 | 而向您的用户进行推广 2427 | 2428 | 2429 | 443 2430 | 00:31:33,493 --> 00:31:36,663 2431 | 从而让您的app成长壮大的最佳实践 2432 | 2433 | 2434 | 444 2435 | 00:31:37,431 --> 00:31:41,335 2436 | 如何指示您的app 2437 | 识别和划分您的用户 2438 | 2439 | 2440 | 445 2441 | 00:31:41,702 --> 00:31:45,906 2442 | 从而更好地了解您试图获取的各种受众 2443 | 2444 | 2445 | 446 2446 | 00:31:47,541 --> 00:31:52,479 2447 | 如何通过具有相关性的消息和吸引人 2448 | 的广告体验 对他们进行定向推广 2449 | 2450 | 2451 | 447 2452 | 00:31:53,146 --> 00:31:56,750 2453 | 从而让您的推广活动 2454 | 在驱动下载和app内购买方面 2455 | 2456 | 2457 | 448 2458 | 00:31:56,817 --> 00:31:59,419 2459 | 更加有效 也更加高效 2460 | 2461 | 2462 | 449 2463 | 00:32:00,921 --> 00:32:04,992 2464 | 以及如何利用 2465 | iAd WorkBench和归因API 2466 | 2467 | 2468 | 450 2469 | 00:32:05,325 --> 00:32:08,829 2470 | 对推广活动的有效性 2471 | 进行持续的监控和衡量 2472 | 2473 | 2474 | 451 2475 | 00:32:12,199 --> 00:32:17,104 2476 | 这就是iAd使每个app开发者 2477 | 都是一套了不起的工具的原因 2478 | 2479 | 2480 | 452 2481 | 00:32:18,205 --> 00:32:22,676 2482 | 不管您处于app开发的任何阶段 2483 | 都可以轻易地利用iAd 2484 | 2485 | 2486 | 453 2487 | 00:32:22,976 --> 00:32:25,479 2488 | 以便对您的app的未来的成功 2489 | 产生重大影响 2490 | 2491 | 2492 | 454 2493 | 00:32:26,079 --> 00:32:27,181 2494 | 而同样重要的是 2495 | 2496 | 2497 | 455 2498 | 00:32:27,514 --> 00:32:29,716 2499 | 也对您业务的未来成功产生重大影响 2500 | 2501 | 2502 | 456 2503 | 00:32:31,218 --> 00:32:32,586 2504 | 还有额外一点是 2505 | 2506 | 2507 | 457 2508 | 00:32:34,087 --> 00:32:39,526 2509 | 对于您们中的那些昨天宣布 2510 | 最新新闻app的内容发布者而言 2511 | 2512 | 2513 | 458 2514 | 00:32:40,527 --> 00:32:44,798 2515 | 您将能够利用iAd将您的内容货币化 2516 | 并进行推广 2517 | 2518 | 2519 | 459 2520 | 00:32:46,133 --> 00:32:50,771 2521 | 请访问苹果开发者站点上的 2522 | 新闻发布者页以便了解更多信息 2523 | 2524 | 2525 | 460 2526 | 00:32:52,439 --> 00:32:54,308 2527 | 而若要了解更多关于iAd的信息 2528 | 2529 | 2530 | 461 2531 | 00:32:54,374 --> 00:32:58,312 2532 | 您可以参考iAd开发者指南 2533 | 和iAd开发者论坛 2534 | 2535 | 2536 | 462 2537 | 00:32:58,579 --> 00:33:01,181 2538 | 或联系我们的技术传播者团队 2539 | 2540 | 2541 | 463 2542 | 00:33:03,684 --> 00:33:06,453 2543 | 明天还将会有一场与 2544 | iTunes Connect相关的讲座 2545 | 2546 | 2547 | 464 2548 | 00:33:07,487 --> 00:33:09,690 2549 | 谢谢大家 2550 | 请尽情欣赏大会的剩余内容 2551 | 2552 | -------------------------------------------------------------------------------- /HD/804_hd_introducing_the_new_system_fonts.srt: -------------------------------------------------------------------------------- 1 | 1 2 | 00:00:28,495 --> 00:00:29,329 3 | 嗨 大家好 4 | 5 | 6 | 2 7 | 00:00:29,997 --> 00:00:31,665 8 | 我叫 9 | 安东尼奥安东尼奥·卡瑞多尼 10 | 11 | 12 | 3 13 | 00:00:31,865 --> 00:00:35,402 14 | 我是San Francisco字体 15 | 设计小组的一名成员 16 | 17 | 18 | 4 19 | 00:00:35,502 --> 00:00:37,971 20 | 很荣幸在此为 21 | 大家介绍这种字体 22 | 23 | 24 | 5 25 | 00:00:39,039 --> 00:00:42,543 26 | 在今天的介绍中我们将会了解到 27 | San Francisco字体 28 | 29 | 30 | 6 31 | 00:00:43,744 --> 00:00:46,380 32 | 它们的设计过程及这些字体对我们 33 | 的平台具有哪些意义 34 | 35 | 36 | 7 37 | 00:00:47,047 --> 00:00:48,916 38 | 我们将会看到若干新功能 39 | 40 | 41 | 8 42 | 00:00:49,183 --> 00:00:52,152 43 | 并学习如何利用这些功能让你 44 | 所设计的app应用变得更出色 45 | 46 | 47 | 9 48 | 00:00:52,386 --> 00:00:54,688 49 | 这种变化将体现在 50 | 代码和设计两个层面上 51 | 52 | 53 | 10 54 | 00:00:56,056 --> 00:00:59,960 55 | 最后我们会讲到在app应用中 56 | 57 | 58 | 11 59 | 00:01:00,494 --> 00:01:04,697 60 | 加入这些新字体时 61 | 可能会遇到的 API 隐患 62 | 63 | 64 | 12 65 | 00:01:05,799 --> 00:01:06,834 66 | 现在开始进入正题 67 | 68 | 69 | 13 70 | 00:01:09,369 --> 00:01:10,504 71 | 文字随处可见 72 | 73 | 74 | 14 75 | 00:01:12,806 --> 00:01:17,311 76 | 而文字存在的前提则是字体 77 | 78 | 79 | 15 80 | 00:01:19,346 --> 00:01:20,981 81 | 其实字体本身也具有表现力 82 | 83 | 84 | 16 85 | 00:01:23,517 --> 00:01:29,356 86 | 好字体能让你的app应用 87 | 内容和用户界面更加美观 88 | 89 | 90 | 17 91 | 00:01:29,823 --> 00:01:31,358 92 | 它们看起来会更顺眼 93 | 94 | 95 | 18 96 | 00:01:34,228 --> 00:01:36,597 97 | 你无时无刻不在阅读字体 98 | 99 | 100 | 19 101 | 00:01:37,464 --> 00:01:41,502 102 | 在不同的屏幕上 103 | 在不同的设备上 104 | 105 | 106 | 20 107 | 00:01:42,503 --> 00:01:43,804 108 | 阅读不同磅值的字体 109 | 110 | 111 | 21 112 | 00:01:44,538 --> 00:01:46,707 113 | 另外你在阅读时的视觉环境也不尽相同 114 | 115 | 116 | 22 117 | 00:01:46,773 --> 00:01:49,676 118 | 有时是明亮环境 119 | 有时是远距离环境 120 | 121 | 122 | 23 123 | 00:01:50,010 --> 00:01:51,912 124 | 还有各种屏幕尺寸和分辨率 125 | 126 | 127 | 24 128 | 00:01:52,613 --> 00:01:58,585 129 | 因此我们有必要改善平台上的字体样式 130 | 131 | 132 | 25 133 | 00:01:59,152 --> 00:02:03,390 134 | 于是全新字体 135 | San Francisco便应运而生了 136 | 137 | 138 | 26 139 | 00:02:05,392 --> 00:02:11,999 140 | San Francisco是加州Apple 141 | 公司设计的一款全新字体样式 142 | 143 | 144 | 27 145 | 00:02:13,367 --> 00:02:17,104 146 | 外观风格简单而优美 147 | 148 | 149 | 28 150 | 00:02:18,539 --> 00:02:23,477 151 | San Francisco以其连续 152 | 流畅的字形表现力和易读性 153 | 154 | 155 | 29 156 | 00:02:24,077 --> 00:02:25,846 157 | 实现了整个平台的高度统一 158 | 159 | 160 | 30 161 | 00:02:26,747 --> 00:02:28,615 162 | 这是它的外观 163 | 164 | 165 | 31 166 | 00:02:30,284 --> 00:02:33,787 167 | San Francisco 168 | 在字体样式中属于grotesque 169 | 170 | 171 | 32 172 | 00:02:33,854 --> 00:02:35,956 173 | Grotesque也称为 174 | sans serif 175 | 176 | 177 | 33 178 | 00:02:37,224 --> 00:02:39,626 179 | 请看字体分类图 180 | 181 | 182 | 34 183 | 00:02:40,427 --> 00:02:43,063 184 | San Francisco设计 185 | 包含两个子类别 186 | 187 | 188 | 35 189 | 00:02:44,331 --> 00:02:47,367 190 | 其中SF用于iOS和OS X 191 | 192 | 193 | 36 194 | 00:02:47,835 --> 00:02:49,770 195 | SF Compact 196 | 用于苹果的手表系统 197 | 198 | 199 | 37 200 | 00:02:51,371 --> 00:02:56,443 201 | 这两个类别又各自包含两种字体 202 | “文字”类和“显示”类 203 | 204 | 205 | 38 206 | 00:02:56,510 --> 00:02:57,978 207 | 两者都属于视觉尺寸 208 | 209 | 210 | 39 211 | 00:02:58,045 --> 00:02:59,813 212 | 稍后我会具体介绍 213 | 214 | 215 | 40 216 | 00:03:00,881 --> 00:03:04,251 217 | 其中文字类字体共有6种字重 218 | 219 | 220 | 41 221 | 00:03:04,718 --> 00:03:07,588 222 | 显示类字体共有9种字重 223 | 224 | 225 | 42 226 | 00:03:08,422 --> 00:03:12,593 227 | 刚才我说过 228 | SF用于iOS和OS X 229 | 230 | 231 | 43 232 | 00:03:13,327 --> 00:03:15,963 233 | 而SF Compact是 234 | 用在苹果的手表系统 235 | 236 | 237 | 44 238 | 00:03:18,031 --> 00:03:20,200 239 | 现在我们了解一下两者的不同之处 240 | 241 | 242 | 45 243 | 00:03:22,102 --> 00:03:26,406 244 | SF和SF Compact 245 | 在设计上采用了孪生理念 246 | 247 | 248 | 46 249 | 00:03:26,507 --> 00:03:28,141 250 | 也就是说它们相似而不相同 251 | 252 | 253 | 47 254 | 00:03:28,809 --> 00:03:32,613 255 | 二者的主要区别在于 256 | 对圆形部分的处理方式 257 | 258 | 259 | 48 260 | 00:03:34,548 --> 00:03:38,819 261 | SF字体是完全圆滑的 262 | SF Compact则略带扁平效果 263 | 264 | 265 | 49 266 | 00:03:39,586 --> 00:03:41,555 267 | 这样的设计能达到双重目的 268 | 269 | 270 | 50 271 | 00:03:42,022 --> 00:03:46,593 272 | 前者实现了风格化 273 | 而更重要的是后者具备了功能性 274 | 275 | 276 | 51 277 | 00:03:46,994 --> 00:03:52,499 278 | 这些扁平的侧面提供了更大的字母间距 279 | 在文字较小时更容易阅读 280 | 281 | 282 | 52 283 | 00:03:53,300 --> 00:04:00,174 284 | 当这个看似不起眼的功能 285 | 在文字中一遍又一遍地重复时 286 | 287 | 288 | 53 289 | 00:04:00,407 --> 00:04:02,042 290 | 就能带来明显的效果 291 | 292 | 293 | 54 294 | 00:04:03,777 --> 00:04:06,380 295 | 现在我们来看比例问题 296 | 297 | 298 | 55 299 | 00:04:06,446 --> 00:04:09,183 300 | SF和SF Compact 301 | 的比例区别并不明显 302 | 303 | 304 | 56 305 | 00:04:09,616 --> 00:04:11,285 306 | 所以我就以SF为例解释一下 307 | 308 | 309 | 57 310 | 00:04:12,452 --> 00:04:16,322 311 | 我会提到一些字体方面的专业的词汇 312 | 大家可能对这些词汇已经很熟悉了 313 | 314 | 315 | 58 316 | 00:04:17,257 --> 00:04:21,528 317 | 拉丁文的设计以基准线作为标准 318 | 319 | 320 | 59 321 | 00:04:22,996 --> 00:04:26,934 322 | 小写字母的对齐 323 | 标准叫做x height 324 | 325 | 326 | 60 327 | 00:04:27,000 --> 00:04:28,802 328 | 即小写x的高度 329 | 330 | 331 | 61 332 | 00:04:29,703 --> 00:04:31,672 333 | 大写字母以大写X作为对齐标准 334 | 335 | 336 | 62 337 | 00:04:33,140 --> 00:04:39,680 338 | 此外还有一个概念叫“下伸部分” 339 | 它是基准线以下小写字母的对齐位置 340 | 341 | 342 | 63 343 | 00:04:42,316 --> 00:04:44,985 344 | 在比例问题上 345 | 346 | 347 | 64 348 | 00:04:45,252 --> 00:04:51,458 349 | SF字族可以兼容我们之前 350 | 发布的所有UI字体量度 351 | 352 | 353 | 65 354 | 00:04:51,792 --> 00:04:55,796 355 | 因此你的app应用不会出现 356 | 明显的垂直回流问题 357 | 358 | 359 | 66 360 | 00:04:55,863 --> 00:04:58,365 361 | 实际上垂直回流问题根本不会出现 362 | 363 | 364 | 67 365 | 00:04:59,700 --> 00:05:04,271 366 | 在这些所兼容的垂直量度中 367 | 我们进行了比例上的细微改动 368 | 369 | 370 | 68 371 | 00:05:04,738 --> 00:05:08,141 372 | 比方说我们把大写字母变得短了一些 373 | 374 | 375 | 69 376 | 00:05:08,775 --> 00:05:12,045 377 | 这样做是为了 378 | 改善大小写混合设置的显示效果 379 | 380 | 381 | 70 382 | 00:05:13,714 --> 00:05:17,351 383 | 与此同时我们还把 384 | x height的高度增加了一些 385 | 386 | 387 | 71 388 | 00:05:17,718 --> 00:05:20,187 389 | 从而使小写字母和大写字母更接近 390 | 391 | 392 | 72 393 | 00:05:20,921 --> 00:05:22,723 394 | 这样不但大小写混合设置的效果更好 395 | 396 | 397 | 73 398 | 00:05:22,823 --> 00:05:24,525 399 | 还能让小写字母看起来更大一些 400 | 401 | 402 | 74 403 | 00:05:24,591 --> 00:05:28,562 404 | 这就是大家平时看到的 405 | 更加清晰易读的效果 406 | 407 | 408 | 75 409 | 00:05:29,563 --> 00:05:32,065 410 | 最后一点 411 | 数字是与大写字母对齐的 412 | 413 | 414 | 76 415 | 00:05:36,803 --> 00:05:41,508 416 | SF属于一种泛欧洲字体 417 | 它包含了拉丁文 418 | 419 | 420 | 77 421 | 00:05:41,975 --> 00:05:47,347 422 | 而拉丁文又包含着 423 | 波兰语 冰岛语 匈牙利文语 424 | 425 | 426 | 78 427 | 00:05:47,681 --> 00:05:50,951 428 | 甚至像越南语那样 429 | 需要叠加音的语言 430 | 431 | 432 | 79 433 | 00:05:51,718 --> 00:05:57,524 434 | 另外它还包含俄语里所使用的 435 | 西里尔文以及希腊文 436 | 437 | 438 | 80 439 | 00:06:01,094 --> 00:06:02,596 440 | 这就是San Francisco 441 | 442 | 443 | 81 444 | 00:06:03,063 --> 00:06:07,201 445 | 这就是我们在加州Apple 446 | 公司设计的一款全新字体 447 | 448 | 449 | 82 450 | 00:06:10,204 --> 00:06:13,240 451 | iOS和OS X采用的字体类别 452 | 叫做 SF 453 | 454 | 455 | 83 456 | 00:06:14,274 --> 00:06:16,577 457 | 苹果手表系统采用的是 458 | SF Compact 459 | 460 | 461 | 84 462 | 00:06:18,312 --> 00:06:21,281 463 | 这两种字体类别有着不同的比例 464 | 对不起 是相似的比例 465 | 466 | 467 | 85 468 | 00:06:22,249 --> 00:06:23,650 469 | 但它们在设计上却有所不同 470 | 471 | 472 | 86 473 | 00:06:24,351 --> 00:06:29,556 474 | 今天大家就可以下载到这两种字体 475 | 476 | 477 | 87 478 | 00:06:30,157 --> 00:06:31,158 479 | 其实现在就可以 480 | 481 | 482 | 88 483 | 00:06:31,825 --> 00:06:37,297 484 | 在Apple网站的字体页面上 485 | developer.apple.com/fonts 486 | 487 | 488 | 89 489 | 00:06:38,232 --> 00:06:39,900 490 | 请注意 491 | 这些字体目前还只是预览版 492 | 493 | 494 | 90 495 | 00:06:40,901 --> 00:06:43,670 496 | 等到OS系统最终确定 497 | 以后才会发布最终版本 498 | 499 | 500 | 91 501 | 00:06:46,340 --> 00:06:47,608 502 | 在继续讲解 503 | 504 | 505 | 92 506 | 00:06:48,809 --> 00:06:53,680 507 | San Francisco字体 508 | 的优秀创意 “视觉尺寸”之前 509 | 510 | 511 | 93 512 | 00:06:54,181 --> 00:06:56,750 513 | 我想先为大家介绍 514 | 一些设计领域的基本原理 515 | 516 | 517 | 94 518 | 00:06:59,720 --> 00:07:02,556 519 | 视觉感知基本上属于错觉 520 | 521 | 522 | 95 523 | 00:07:03,457 --> 00:07:04,992 524 | 在理解这句话的时候 525 | 526 | 527 | 96 528 | 00:07:05,592 --> 00:07:08,262 529 | 请设想在你眼前有两个形状 530 | 一个方形和一个圆形 531 | 532 | 533 | 97 534 | 00:07:09,029 --> 00:07:13,433 535 | 为了让两个形状看起来高度相等 536 | 537 | 538 | 98 539 | 00:07:15,068 --> 00:07:18,505 540 | 需要把它们并列排放 541 | 上下准确对齐 542 | 543 | 544 | 99 545 | 00:07:19,139 --> 00:07:21,909 546 | 但实际上 547 | 圆形看起来很短 548 | 549 | 550 | 100 551 | 00:07:22,743 --> 00:07:25,679 552 | 为了弥补这一缺陷就要 553 | 使用一点迷惑性的手段 554 | 555 | 556 | 101 557 | 00:07:26,280 --> 00:07:29,750 558 | 也就是说 559 | 要让圆形更大些 560 | 561 | 562 | 102 563 | 00:07:30,517 --> 00:07:33,554 564 | 在字体领域里我们会说 565 | 用圆形“冲越”方形 566 | 567 | 568 | 103 569 | 00:07:35,489 --> 00:07:41,995 570 | 换句话说 想让两个形状看起来相似 571 | 通常要让它们相异 572 | 573 | 574 | 104 575 | 00:07:43,030 --> 00:07:45,399 576 | 这个原理不仅适用于形状本身 577 | 578 | 579 | 105 580 | 00:07:46,133 --> 00:07:49,069 581 | 还适用于形状周围的空间 582 | 583 | 584 | 106 585 | 00:07:49,136 --> 00:07:51,071 586 | 我用刻度标记的方式 587 | 让大家看得更清楚些 588 | 589 | 590 | 107 591 | 00:07:51,572 --> 00:07:57,711 592 | 大家会看到 593 | 在屏幕中间插入文字时 594 | 595 | 596 | 108 597 | 00:07:58,212 --> 00:07:59,546 598 | 文字的位置看起来会很低 599 | 600 | 601 | 109 602 | 00:08:00,380 --> 00:08:01,215 603 | 正如刚才所讲到的 604 | 605 | 606 | 110 607 | 00:08:02,015 --> 00:08:04,885 608 | 想要形状看起来相似 609 | 需要进行差异化处理 610 | 611 | 612 | 111 613 | 00:08:06,153 --> 00:08:09,156 614 | 顺便普及一个小知识 615 | 你们知道这个字符是什么吗？ 616 | 617 | 618 | 112 619 | 00:08:09,256 --> 00:08:10,390 620 | 它叫什么？ 621 | 622 | 623 | 113 624 | 00:08:11,191 --> 00:08:12,960 625 | 英镑符号还是井号？ 626 | 627 | 628 | 114 629 | 00:08:13,360 --> 00:08:16,296 630 | 意大利语叫cancelletto 631 | 意思是“小门” 632 | 633 | 634 | 115 635 | 00:08:17,064 --> 00:08:18,966 636 | 当然它属于数字符号 637 | 638 | 639 | 116 640 | 00:08:20,067 --> 00:08:25,672 641 | 由四条线相交组成的数字符号 642 | 643 | 644 | 117 645 | 00:08:26,039 --> 00:08:27,574 646 | 而这四条线的交汇处 647 | 648 | 649 | 118 650 | 00:08:28,475 --> 00:08:30,577 651 | 中间的这部分区域 652 | 当字体尺寸较小的时候 653 | 654 | 655 | 119 656 | 00:08:30,644 --> 00:08:33,246 657 | 该区域会变得很暗 658 | 甚至是一团黑 659 | 660 | 661 | 120 662 | 00:08:33,580 --> 00:08:35,883 663 | 所以当字体较小时你很难看到它 664 | 665 | 666 | 121 667 | 00:08:36,616 --> 00:08:41,522 668 | 这时还是需要调整一下 669 | 670 | 671 | 122 672 | 00:08:41,955 --> 00:08:47,461 673 | 不必去动四条线的交汇处 674 | 只要让中间的方块变大一点 675 | 676 | 677 | 123 678 | 00:08:48,395 --> 00:08:52,733 679 | 这就是San Francisco 680 | 字体的重磅值井字符 681 | 682 | 683 | 124 684 | 00:08:53,066 --> 00:08:55,569 685 | 以上是我们在字体 686 | 设计中经常采用方法 687 | 688 | 689 | 125 690 | 00:08:58,038 --> 00:09:00,574 691 | 这就是刚才所说的 692 | 视觉感知即与错觉相关 693 | 694 | 695 | 126 696 | 00:09:01,575 --> 00:09:05,379 697 | 明白了这个道理 698 | 我们再来讲视觉尺寸 699 | 700 | 701 | 127 702 | 00:09:06,547 --> 00:09:09,850 703 | 在刚才看到的分类图中 704 | 它在这个分支上 705 | 706 | 707 | 128 708 | 00:09:12,052 --> 00:09:16,423 709 | 假设有一小段文字 710 | 用两种不同的字体尺寸显示出来 711 | 712 | 713 | 129 714 | 00:09:16,823 --> 00:09:18,792 715 | 顺便说一下 716 | 这个单词没有任何实际意义 717 | 718 | 719 | 130 720 | 00:09:19,092 --> 00:09:23,830 721 | 它只是字体设计人员用来查看字体 722 | 及其组合样态 723 | 724 | 725 | 131 726 | 00:09:23,897 --> 00:09:25,699 727 | 因为其中包含着一些扁形和圆形 728 | 729 | 730 | 132 731 | 00:09:26,567 --> 00:09:32,272 732 | 当你看着它的时候你会发现 733 | 这段文字在小字号状态下清晰度不好 734 | 735 | 736 | 133 737 | 00:09:32,339 --> 00:09:35,375 738 | 这是因为对于grotesque 739 | 这种字体样式 740 | 741 | 742 | 134 743 | 00:09:35,442 --> 00:09:37,778 744 | 它的字母显示正常并且字母间距很小 745 | 746 | 747 | 135 748 | 00:09:38,512 --> 00:09:41,148 749 | 如果我用模糊处理 750 | 来模拟低清晰度效果的话 751 | 752 | 753 | 136 754 | 00:09:41,448 --> 00:09:42,482 755 | 较小的字体... 756 | 757 | 758 | 137 759 | 00:09:43,750 --> 00:09:46,587 760 | 在较小的这部分字母 761 | 开始变得混淆不清了 对吗？ 762 | 763 | 764 | 138 765 | 00:09:47,354 --> 00:09:50,691 766 | 这种情况下 767 | 我们想要的效果应该是这样的 768 | 769 | 770 | 139 771 | 00:09:51,558 --> 00:09:54,695 772 | 也就是说要微调一下 773 | 以便让小字体也能清晰显示 774 | 775 | 776 | 140 777 | 00:09:56,129 --> 00:09:59,266 778 | 大家可能觉得我只不过是让它动了起来 779 | 并稍微增加了一些宽度 780 | 781 | 782 | 141 783 | 00:09:59,666 --> 00:10:03,136 784 | 其实我是在变换字体 785 | 所呈现给你的整体印象 786 | 787 | 788 | 142 789 | 00:10:04,872 --> 00:10:10,310 790 | 在解释“显示”和“文字” 791 | 这两种字体的区别之前 792 | 793 | 794 | 143 795 | 00:10:10,711 --> 00:10:14,081 796 | 请记住 797 | 此处的“显示”并非指显示器屏幕 798 | 799 | 800 | 144 801 | 00:10:14,147 --> 00:10:16,550 802 | 它在字形领域代表字体大小 803 | 而“文字”是指文本的大小 804 | 805 | 806 | 145 807 | 00:10:16,650 --> 00:10:20,320 808 | 所以“显示”字体用于较大的字号 809 | “文字”字体用于较小的字号 810 | 811 | 812 | 146 813 | 00:10:21,321 --> 00:10:24,157 814 | 在解释两者区别之前 815 | 我首先介绍负空间的概念 816 | 817 | 818 | 147 819 | 00:10:24,525 --> 00:10:27,861 820 | 负空间是指字母内侧 周围 821 | 822 | 823 | 148 824 | 00:10:28,929 --> 00:10:30,297 825 | 和轮廓内部的空间 826 | 827 | 828 | 149 829 | 00:10:30,998 --> 00:10:35,035 830 | 负空间是分辨形状 831 | 和阅读形状的关键之处 832 | 833 | 834 | 150 835 | 00:10:36,036 --> 00:10:37,971 836 | 在刚才的示例下方区域中 837 | 838 | 839 | 151 840 | 00:10:39,039 --> 00:10:44,711 841 | 对于文字来说 其周边空间的面积 842 | 几乎是字体显示面积的两倍 843 | 844 | 845 | 152 846 | 00:10:46,246 --> 00:10:50,684 847 | 因此包括San Francisco 848 | 在内的grotesque字体样式 849 | 850 | 851 | 153 852 | 00:10:50,851 --> 00:10:51,818 853 | 都面临着同一个问题 854 | 855 | 856 | 154 857 | 00:10:52,085 --> 00:10:54,922 858 | 它们的形状在足够大时看起来确实漂亮 859 | 860 | 861 | 155 862 | 00:10:56,557 --> 00:10:59,393 863 | 但在结构上却过于相似 864 | 所以很容易造成混淆 865 | 866 | 867 | 156 868 | 00:10:59,893 --> 00:11:01,128 869 | 如果将两者叠加起来 870 | 871 | 872 | 157 873 | 00:11:02,863 --> 00:11:06,133 874 | 你会发现它们的整体形态是完全相同的 875 | 876 | 877 | 158 878 | 00:11:06,200 --> 00:11:09,837 879 | 在顶部和底部都有弯曲部分 880 | 881 | 882 | 159 883 | 00:11:10,671 --> 00:11:14,174 884 | 它们都含有两个这样的区域 885 | 我们称之为反向对称区 886 | 887 | 888 | 160 889 | 00:11:15,075 --> 00:11:18,312 890 | 反向对称区的位置基本大小基本一致 891 | 892 | 893 | 161 894 | 00:11:19,179 --> 00:11:21,381 895 | 另外在中间位置还有这样的半横区 896 | 897 | 898 | 162 899 | 00:11:22,449 --> 00:11:26,119 900 | 半横区的形状实际上 901 | 是由这些圆圈所界定的 902 | 903 | 904 | 163 905 | 00:11:26,820 --> 00:11:29,756 906 | 如果空气能够进入到字母里面的话 907 | 那么气流就是从这些圆圈进去的 908 | 909 | 910 | 164 911 | 00:11:30,958 --> 00:11:33,527 912 | 在改变显示字体时 913 | 914 | 915 | 165 916 | 00:11:33,727 --> 00:11:37,331 917 | 文字字体和显示字体 918 | 具体处理过程是这样的 919 | 920 | 921 | 166 922 | 00:11:37,531 --> 00:11:39,066 923 | 我们举例说明 924 | 925 | 926 | 167 927 | 00:11:42,803 --> 00:11:44,304 928 | 以小写字母a为例 929 | 930 | 931 | 168 932 | 00:11:44,471 --> 00:11:46,406 933 | 其实要改变的是冲越部分 934 | 935 | 936 | 169 937 | 00:11:46,473 --> 00:11:48,876 938 | 因为当字体尺寸较小时 939 | 940 | 941 | 170 942 | 00:11:48,942 --> 00:11:52,379 943 | 我们要让圆边部分 944 | 能够从x height上突显出来 945 | 946 | 947 | 171 948 | 00:11:53,180 --> 00:11:54,982 949 | 同时还要打开此处的圆圈 950 | 951 | 952 | 172 953 | 00:11:56,650 --> 00:11:59,253 954 | 对小写g的底部区域 955 | 也采取同样的处理方式 956 | 957 | 958 | 173 959 | 00:12:02,256 --> 00:12:05,292 960 | 小写s 961 | 也是打开这里的圆圈 962 | 963 | 964 | 174 965 | 00:12:06,927 --> 00:12:12,366 966 | 处理字母r时 967 | 我们把它右上角的弯转部分加大 968 | 969 | 970 | 175 971 | 00:12:13,433 --> 00:12:16,737 972 | 小写f和小写t也有类似的形状区域 973 | 974 | 975 | 176 976 | 00:12:16,803 --> 00:12:18,805 977 | 因此处理方法相同 978 | 但这两个字母更大 更高一些 979 | 980 | 981 | 177 982 | 00:12:19,907 --> 00:12:21,275 983 | 小写i就比较有趣了 984 | 985 | 986 | 178 987 | 00:12:21,341 --> 00:12:25,746 988 | 因为当字号很小时 989 | i头顶上的圆点看起来 990 | 991 | 992 | 179 993 | 00:12:25,812 --> 00:12:29,483 994 | 好像和下半部分的竖线顶撞在一起 995 | 996 | 997 | 180 998 | 00:12:29,550 --> 00:12:32,486 999 | 所以我们就把它调大 调高一些 1000 | 1001 | 1002 | 181 1003 | 00:12:34,054 --> 00:12:38,292 1004 | SF和SF Compact 1005 | 有两种截然不同的字族 1006 | 1007 | 1008 | 182 1009 | 00:12:38,492 --> 00:12:42,329 1010 | 分别叫做“显示”和“字体” 1011 | 它们用于不同的字体磅值 1012 | 1013 | 1014 | 183 1015 | 00:12:42,729 --> 00:12:47,134 1016 | 系统能够在这两个字族之间自动转换 1017 | 所以不需要用户自己选择 1018 | 1019 | 1020 | 184 1021 | 00:12:48,435 --> 00:12:50,137 1022 | 这就是视觉尺寸 1023 | 1024 | 1025 | 185 1026 | 00:12:52,072 --> 00:12:52,906 1027 | 谢谢 1028 | 1029 | 1030 | 186 1031 | 00:12:58,579 --> 00:13:03,383 1032 | San Francisco 1033 | 有两种视觉尺寸 文字和显示 1034 | 1035 | 1036 | 187 1037 | 00:13:03,851 --> 00:13:05,919 1038 | 系统会在20磅时 1039 | 自动切换文字和显示字体 1040 | 1041 | 1042 | 188 1043 | 00:13:06,486 --> 00:13:09,756 1044 | 这一点对平台的代码编写 1045 | 不会产生任何影响 1046 | 1047 | 1048 | 189 1049 | 00:13:09,990 --> 00:13:13,193 1050 | 不过对于app设计而言 1051 | 还是很有必要了解这一点 1052 | 1053 | 1054 | 190 1055 | 00:13:13,260 --> 00:13:17,064 1056 | 因为Photoshop Sketch 1057 | 或其他类似的软件程序 1058 | 1059 | 1060 | 191 1061 | 00:13:17,130 --> 00:13:18,365 1062 | 不会自动执行字体切换 1063 | 1064 | 1065 | 192 1066 | 00:13:18,532 --> 00:13:20,701 1067 | 这种情况下 1068 | 你就要自己更改字体 1069 | 1070 | 1071 | 193 1072 | 00:13:22,903 --> 00:13:26,473 1073 | 讲完了视觉尺寸 1074 | 1075 | 1076 | 194 1077 | 00:13:27,307 --> 00:13:31,178 1078 | 我想介绍一下和文字尺寸有关的 1079 | 另一个概念 字间距 1080 | 1081 | 1082 | 195 1083 | 00:13:33,413 --> 00:13:37,784 1084 | 字间距在字母的负空间里起到调节作用 1085 | 1086 | 1087 | 196 1088 | 00:13:38,785 --> 00:13:42,523 1089 | 看屏幕上的动画演示 大家可能会认为 1090 | 哦 原来是字符串的偶距变了 1091 | 1092 | 1093 | 197 1094 | 00:13:42,890 --> 00:13:46,827 1095 | 没错 基本上就是这样 1096 | 字间距和字偶距的区别很小 1097 | 1098 | 1099 | 198 1100 | 00:13:47,728 --> 00:13:49,263 1101 | 字间距是 1102 | 1103 | 1104 | 199 1105 | 00:13:49,329 --> 00:13:55,235 1106 | 正向或反向调节所有字符 1107 | 1108 | 1109 | 200 1110 | 00:13:56,036 --> 00:14:00,574 1111 | 而字偶距只是调节两字母之间的距离 1112 | 也就是相邻字母的距离 1113 | 1114 | 1115 | 201 1116 | 00:14:01,808 --> 00:14:03,343 1117 | 这就是两者的区别所在 1118 | 1119 | 1120 | 202 1121 | 00:14:04,711 --> 00:14:07,314 1122 | 字间距是普遍调整 1123 | 字偶距是局部调整 1124 | 1125 | 1126 | 203 1127 | 00:14:11,185 --> 00:14:13,921 1128 | San Francisco 1129 | 的每种字体都内置一个字间距表 1130 | 1131 | 1132 | 204 1133 | 00:14:15,189 --> 00:14:21,495 1134 | 该字间距表带有具体的字符尺寸 1135 | 并且定义了磅值和字间距值 1136 | 1137 | 1138 | 205 1139 | 00:14:22,329 --> 00:14:24,198 1140 | 就是这种效果 对吧？ 1141 | 1142 | 1143 | 206 1144 | 00:14:24,264 --> 00:14:28,802 1145 | 它能让较小的文字更宽松 1146 | 也能让较大的文字更紧凑 1147 | 1148 | 1149 | 207 1150 | 00:14:30,003 --> 00:14:32,840 1151 | 就像刚才我说的那样 1152 | 1153 | 1154 | 208 1155 | 00:14:32,906 --> 00:14:35,876 1156 | 若使用新San Francisco 1157 | 字体进行编码 可以不用了解上述原理 1158 | 1159 | 1160 | 209 1161 | 00:14:35,943 --> 00:14:38,912 1162 | 如果使用Photoshop 1163 | 绘制app应用的话 1164 | 1165 | 1166 | 210 1167 | 00:14:39,046 --> 00:14:41,014 1168 | 再次记住软件本身不会自动切换字体 1169 | 1170 | 1171 | 211 1172 | 00:14:43,483 --> 00:14:46,720 1173 | 这时就可以下载这样一份 1174 | 带有系统字体的字间距表 1175 | 1176 | 1177 | 212 1178 | 00:14:47,387 --> 00:14:49,122 1179 | 下载地址和我刚才 1180 | 给出的页面地址一样 1181 | 1182 | 1183 | 213 1184 | 00:14:52,059 --> 00:14:53,460 1185 | 以上是关于字间距的内容 1186 | 1187 | 1188 | 214 1189 | 00:14:56,163 --> 00:15:00,334 1190 | 接下来我要讲的是字重 1191 | 1192 | 1193 | 215 1194 | 00:15:04,671 --> 00:15:10,511 1195 | 字重这一概念用来描述 1196 | 字母笔画的粗细程度 1197 | 1198 | 1199 | 216 1200 | 00:15:12,379 --> 00:15:16,016 1201 | 在San Francisco 1202 | 和SF Compact字族里 1203 | 1204 | 1205 | 217 1206 | 00:15:16,083 --> 00:15:20,821 1207 | 两者的文字字体都有6种字重 1208 | 1209 | 1210 | 218 1211 | 00:15:21,355 --> 00:15:25,425 1212 | 另外再加上斜体 1213 | 就构成了9种显示字体 1214 | 1215 | 1216 | 219 1217 | 00:15:25,893 --> 00:15:31,198 1218 | 大家可能会问 1219 | 为什么显示字体字重比文字字体重更多 1220 | 1221 | 1222 | 220 1223 | 00:15:32,199 --> 00:15:36,870 1224 | 这是因为极粗字体 1225 | 其实只是为了标题而设计的 1226 | 1227 | 1228 | 221 1229 | 00:15:37,571 --> 00:15:40,774 1230 | 所以在20磅以下使用 1231 | 就没有多大意义可言了 1232 | 1233 | 1234 | 222 1235 | 00:15:43,110 --> 00:15:47,047 1236 | 有些字重是新增加到平台上的 1237 | 1238 | 1239 | 223 1240 | 00:15:47,114 --> 00:15:48,215 1241 | 以前几乎找不到它们 1242 | 1243 | 1244 | 224 1245 | 00:15:50,083 --> 00:15:53,554 1246 | 即便原有的字重也很难获取 1247 | 1248 | 1249 | 225 1250 | 00:15:53,921 --> 00:15:58,659 1251 | 现在我们提供了新的API 1252 | 大家可以从中获取所有字重和系统字体 1253 | 1254 | 1255 | 226 1256 | 00:15:59,326 --> 00:16:01,228 1257 | 它们都包含在UIKit 1258 | 和AppKit里 1259 | 1260 | 1261 | 227 1262 | 00:16:01,295 --> 00:16:05,232 1263 | 且已是systemFontOfSize 1264 | 里面的一个新参数 1265 | 1266 | 1267 | 228 1268 | 00:16:08,001 --> 00:16:10,771 1269 | 这些是它们使用的引数 1270 | 1271 | 1272 | 229 1273 | 00:16:12,639 --> 00:16:16,710 1274 | 有了这些字重 1275 | 接下来的问题的就是如何使用它们 1276 | 1277 | 1278 | 230 1279 | 00:16:16,910 --> 00:16:19,413 1280 | 我指的不是在编码方面 1281 | 而是在设计方面 1282 | 1283 | 1284 | 231 1285 | 00:16:20,681 --> 00:16:23,884 1286 | 通过使用字重 1287 | 可以实现三个主要目标 1288 | 1289 | 1290 | 232 1291 | 00:16:24,251 --> 00:16:25,485 1292 | 首先是差异化 1293 | 1294 | 1295 | 233 1296 | 00:16:25,552 --> 00:16:28,989 1297 | 你可以让一段文字产生差别 1298 | 并制作层级效果 1299 | 1300 | 1301 | 234 1302 | 00:16:30,190 --> 00:16:31,925 1303 | 第二个目标是相似性 1304 | 1305 | 1306 | 235 1307 | 00:16:33,327 --> 00:16:35,395 1308 | 第三个是实现风格化效果 1309 | 1310 | 1311 | 236 1312 | 00:16:35,462 --> 00:16:37,698 1313 | 这样文字就具备了表现力 1314 | 1315 | 1316 | 237 1317 | 00:16:38,465 --> 00:16:39,433 1318 | 请看屏幕 1319 | 1320 | 1321 | 238 1322 | 00:16:41,802 --> 00:16:43,136 1323 | 假设有一段文字 1324 | 1325 | 1326 | 239 1327 | 00:16:43,437 --> 00:16:45,072 1328 | 现在要将其中的某个单词突出显示 1329 | 1330 | 1331 | 240 1332 | 00:16:45,606 --> 00:16:48,475 1333 | 把它设成动态 链接或强调效果 1334 | 1335 | 1336 | 241 1337 | 00:16:48,775 --> 00:16:50,644 1338 | 这时字重就能派上用场了 1339 | 1340 | 1341 | 242 1342 | 00:16:52,613 --> 00:16:55,716 1343 | 另外 它还可以为列表制作层级效果 1344 | 1345 | 1346 | 243 1347 | 00:16:55,782 --> 00:17:02,556 1348 | 比如我想把第一行文字做成列表的标题 1349 | 而下面的部分是列表的具体内容 1350 | 1351 | 1352 | 244 1353 | 00:17:03,891 --> 00:17:07,761 1354 | 字重还有一个巧妙的功能 1355 | 制作相似效果 1356 | 1357 | 1358 | 245 1359 | 00:17:08,595 --> 00:17:09,896 1360 | 请看这个示例 1361 | 1362 | 1363 | 246 1364 | 00:17:09,963 --> 00:17:13,599 1365 | Apple手表系统的 1366 | Glances模拟界面 1367 | 1368 | 1369 | 247 1370 | 00:17:13,800 --> 00:17:16,869 1371 | 上面是一个较大的数字 1372 | 下面是几个较小的文字 1373 | 1374 | 1375 | 248 1376 | 00:17:17,771 --> 00:17:22,309 1377 | 如果把它们设成相同字重 1378 | 看起来会有头重脚轻的感觉 1379 | 1380 | 1381 | 249 1382 | 00:17:22,910 --> 00:17:25,546 1383 | 如果要制作相似效果 1384 | 让其产生平衡感 1385 | 1386 | 1387 | 250 1388 | 00:17:25,612 --> 00:17:28,214 1389 | 就需要使用不同的字重 1390 | 以此来达到相似的目的 1391 | 1392 | 1393 | 251 1394 | 00:17:29,116 --> 00:17:32,619 1395 | 所以我们下面的字体从light 1396 | 变成regular 效果就好多了 1397 | 1398 | 1399 | 252 1400 | 00:17:34,621 --> 00:17:35,856 1401 | 记住这个方法 1402 | 1403 | 1404 | 253 1405 | 00:17:35,923 --> 00:17:38,992 1406 | 字号大时 字重调重一些 1407 | 字号小时 字重调轻一些 1408 | 1409 | 1410 | 254 1411 | 00:17:39,359 --> 00:17:44,331 1412 | 这样一来就能达到 1413 | 相似而协调的理想效果 1414 | 1415 | 1416 | 255 1417 | 00:17:46,567 --> 00:17:48,969 1418 | 最后 字重还能帮助提高文字的表现力 1419 | 1420 | 1421 | 256 1422 | 00:17:49,136 --> 00:17:52,005 1423 | 为了解释这个问题 1424 | 我制作了一款新式app应用 1425 | 1426 | 1427 | 257 1428 | 00:17:52,840 --> 00:17:54,408 1429 | 叫做“蜜蜂天气预报” 1430 | 1431 | 1432 | 258 1433 | 00:17:54,842 --> 00:17:57,377 1434 | 一款蜜蜂风格的小软件 1435 | 1436 | 1437 | 259 1438 | 00:17:58,011 --> 00:18:02,516 1439 | 我想让它看起来简单粗犷一些 1440 | 1441 | 1442 | 260 1443 | 00:18:03,016 --> 00:18:06,653 1444 | 但我想说的是 1445 | 如果保持界面布局不变 1446 | 1447 | 1448 | 261 1449 | 00:18:06,987 --> 00:18:09,323 1450 | 在布局不变的情况下 1451 | 只改动字重 1452 | 1453 | 1454 | 262 1455 | 00:18:09,990 --> 00:18:13,026 1456 | 整个界面在风格上将会截然不同 1457 | 表现力完全不一样 1458 | 1459 | 1460 | 263 1461 | 00:18:13,861 --> 00:18:17,264 1462 | 如果你觉得 1463 | 哦 肯定是颜色的问题 1464 | 1465 | 1466 | 264 1467 | 00:18:17,931 --> 00:18:19,633 1468 | 没关系 1469 | 我还做了一个斑马版的 1470 | 1471 | 1472 | 265 1473 | 00:18:20,167 --> 00:18:22,769 1474 | 这个就完全能证明我是对的 1475 | 1476 | 1477 | 266 1478 | 00:18:24,137 --> 00:18:27,374 1479 | 虽然字重能改变风格和效果 1480 | 1481 | 1482 | 267 1483 | 00:18:28,909 --> 00:18:31,044 1484 | 但别忘了 1485 | 1486 | 1487 | 268 1488 | 00:18:31,945 --> 00:18:37,050 1489 | 文字是有字体的 1490 | 易读性最重要 1491 | 1492 | 1493 | 269 1494 | 00:18:38,452 --> 00:18:41,088 1495 | 你可以制作层级效果 1496 | 清晰连贯的层级效果 1497 | 1498 | 1499 | 270 1500 | 00:18:42,089 --> 00:18:43,690 1501 | 如果不喜欢自己做的话 1502 | 1503 | 1504 | 271 1505 | 00:18:43,991 --> 00:18:45,959 1506 | 可以使用iOS准备 1507 | 的一套现成系统 1508 | 1509 | 1510 | 272 1511 | 00:18:46,493 --> 00:18:50,531 1512 | 里面已经设置了层级 1513 | 以及字体尺寸和字重 1514 | 1515 | 1516 | 273 1517 | 00:18:51,031 --> 00:18:52,699 1518 | 它们就是文字样式API 1519 | 1520 | 1521 | 274 1522 | 00:18:52,966 --> 00:18:56,537 1523 | 主要用于功能很多的 1524 | Dynamic Type 1525 | 1526 | 1527 | 275 1528 | 00:18:57,070 --> 00:18:59,873 1529 | 用户可以进入它的偏好设置 1530 | 1531 | 1532 | 276 1533 | 00:19:00,274 --> 00:19:03,577 1534 | 改变字体大小 1535 | 然后app应用就会做出相应改变 1536 | 1537 | 1538 | 277 1539 | 00:19:05,345 --> 00:19:07,614 1540 | 在使用字重时请记住 1541 | 1542 | 1543 | 278 1544 | 00:19:07,714 --> 00:19:11,985 1545 | iOS和watchOS系统 1546 | 中都有一个设定选项 1547 | 1548 | 1549 | 279 1550 | 00:19:12,419 --> 00:19:16,290 1551 | 用于改变用户设备上的字重 1552 | 1553 | 1554 | 280 1555 | 00:19:16,890 --> 00:19:20,394 1556 | 如果你使用的字体很粗 1557 | 1558 | 1559 | 281 1560 | 00:19:20,928 --> 00:19:23,463 1561 | 那很可能已经达到了极限 1562 | 1563 | 1564 | 282 1565 | 00:19:24,231 --> 00:19:28,902 1566 | 相反 如果你使用的字体很细 1567 | 那么文字的易读性就会好一些 1568 | 1569 | 1570 | 283 1571 | 00:19:29,403 --> 00:19:33,607 1572 | 字重的使用没有固定的标准方法 1573 | 1574 | 1575 | 284 1576 | 00:19:34,341 --> 00:19:38,879 1577 | 但这些基本原理还是能 1578 | 起到一些抛砖引玉的作用 1579 | 1580 | 1581 | 285 1582 | 00:19:40,647 --> 00:19:44,051 1583 | 以上讲的是 1584 | San Francisco字族的字重 1585 | 1586 | 1587 | 286 1588 | 00:19:45,185 --> 00:19:49,656 1589 | 还有更多的字重 1590 | 和包含字重的API供大家使用 1591 | 1592 | 1593 | 287 1594 | 00:19:51,258 --> 00:19:54,461 1595 | 刚才介绍的易读性 1596 | 层级和精细质量效果 1597 | 1598 | 1599 | 288 1600 | 00:19:54,761 --> 00:19:57,631 1601 | 等基本原理同样 1602 | 适用于这些字重和API 1603 | 1604 | 1605 | 289 1606 | 00:20:01,068 --> 00:20:07,808 1607 | 下面是San Francisco 1608 | 字族的另一个功能 字形功能 1609 | 1610 | 1611 | 290 1612 | 00:20:11,512 --> 00:20:17,518 1613 | 功能赋予字体生命力 1614 | 因为它们是嵌入字体内部的行为片段 1615 | 1616 | 1617 | 291 1618 | 00:20:19,052 --> 00:20:22,055 1619 | 其主要作用是用来表达复杂文字 1620 | 1621 | 1622 | 292 1623 | 00:20:22,756 --> 00:20:26,527 1624 | 同时也可以通过它们 1625 | 来获得字体的外延形状 1626 | 1627 | 1628 | 293 1629 | 00:20:27,294 --> 00:20:29,329 1630 | 对获取外延形状来说 1631 | 有时字形功能是唯一途径 1632 | 1633 | 1634 | 294 1635 | 00:20:29,396 --> 00:20:32,099 1636 | 有时字形功能是更加便捷的途径 1637 | 1638 | 1639 | 295 1640 | 00:20:33,133 --> 00:20:35,068 1641 | 我们通过示例来了解 1642 | 它们功能的实际作用 1643 | 1644 | 1645 | 296 1646 | 00:20:35,636 --> 00:20:37,704 1647 | 首先看分数的显示 1648 | 1649 | 1650 | 297 1651 | 00:20:38,539 --> 00:20:41,208 1652 | 比如在设计过程中 1653 | 需要把它加到app应用里 1654 | 1655 | 1656 | 298 1657 | 00:20:41,542 --> 00:20:42,409 1658 | 这时你会想 1659 | 1660 | 1661 | 299 1662 | 00:20:43,343 --> 00:20:46,213 1663 | 肯定可以在Unicode找到该符号 1664 | 1665 | 1666 | 300 1667 | 00:20:46,747 --> 00:20:50,617 1668 | 但不知道San Francisco里面有没有 1669 | 1670 | 1671 | 301 1672 | 00:20:50,884 --> 00:20:52,786 1673 | 于是你找了一下还真找到了 1674 | 直接把它打出来 1675 | 1676 | 1677 | 302 1678 | 00:20:53,020 --> 00:20:53,854 1679 | 很好 1680 | 1681 | 1682 | 303 1683 | 00:20:54,488 --> 00:20:56,690 1684 | 不过要是这种情况的话又该怎么办呢？ 1685 | 1686 | 1687 | 304 1688 | 00:20:57,357 --> 00:20:59,226 1689 | 字体里面没有 1690 | Unicode里也没有 1691 | 1692 | 1693 | 305 1694 | 00:21:00,027 --> 00:21:06,867 1695 | 你可以用迭代法 1696 | 用这个字符串来写代码 1697 | 1698 | 1699 | 306 1700 | 00:21:07,234 --> 00:21:08,302 1701 | 然后复制成其它形状 1702 | 1703 | 1704 | 307 1705 | 00:21:09,169 --> 00:21:12,973 1706 | 再把这些形状逐个排好位置 1707 | 1708 | 1709 | 308 1710 | 00:21:13,807 --> 00:21:18,879 1711 | 必要时调整一下字重 1712 | 让整体效果看起来更加相似 匀称 1713 | 1714 | 1715 | 309 1716 | 00:21:19,479 --> 00:21:22,349 1717 | 也许你会想到字体里面是有分号线的 1718 | 1719 | 1720 | 310 1721 | 00:21:22,416 --> 00:21:24,585 1722 | 那就到San Francisco里面去找一找 1723 | 找到了 1724 | 1725 | 1726 | 311 1727 | 00:21:24,651 --> 00:21:25,485 1728 | 直接放进去 1729 | 1730 | 1731 | 312 1732 | 00:21:26,353 --> 00:21:29,857 1733 | 就这样你写了一大堆代码 1734 | 其实根本不用这么麻烦 1735 | 1736 | 1737 | 313 1738 | 00:21:29,957 --> 00:21:35,262 1739 | 因为分数功能会 1740 | 自动执行这一操作 1741 | 1742 | 1743 | 314 1744 | 00:21:36,430 --> 00:21:39,132 1745 | 该功能适用于任意分数 1746 | 1747 | 1748 | 315 1749 | 00:21:40,067 --> 00:21:41,802 1750 | 就像这个数字 1751 | 1752 | 1753 | 316 1754 | 00:21:41,935 --> 00:21:47,641 1755 | 我不可能设计出 1756 | 一个65/324这么大的连字符 1757 | 1758 | 1759 | 317 1760 | 00:21:48,141 --> 00:21:53,447 1761 | 实际上它是由小号数字和分号线组成的 1762 | 系统能够根据实际字体 1763 | 1764 | 1765 | 318 1766 | 00:21:54,448 --> 00:21:58,185 1767 | 将数字和分号线组合在一起 1768 | 1769 | 1770 | 319 1771 | 00:21:58,852 --> 00:22:04,525 1772 | 这样做的好处在于 1773 | 它们都是独立的形状 可以调整字间距 1774 | 1775 | 1776 | 320 1777 | 00:22:05,926 --> 00:22:08,529 1778 | 功能的种类还有很多 1779 | 1780 | 1781 | 321 1782 | 00:22:08,629 --> 00:22:11,031 1783 | 大家可以在Typography面板 1784 | 里启用这些功能 1785 | 1786 | 1787 | 322 1788 | 00:22:11,098 --> 00:22:14,301 1789 | 该面板是OS X字体 1790 | 面板中的一个用户界面 1791 | 1792 | 1793 | 323 1794 | 00:22:15,602 --> 00:22:19,339 1795 | 另外也可以通过代码来启用功能 1796 | 毕竟在座各位使用代码的时候比较多 1797 | 1798 | 1799 | 324 1800 | 00:22:20,307 --> 00:22:26,713 1801 | 我用新的systemFontOfSize 1802 | 字重API实现了轻字重效果 1803 | 1804 | 1805 | 325 1806 | 00:22:27,848 --> 00:22:29,716 1807 | 这是字体描述符 1808 | 1809 | 1810 | 326 1811 | 00:22:30,617 --> 00:22:34,688 1812 | 找到以后就可以为它添加各种属性 1813 | 1814 | 1815 | 327 1816 | 00:22:35,155 --> 00:22:37,791 1817 | 某些属性本身就是字形功能 1818 | 1819 | 1820 | 328 1821 | 00:22:38,458 --> 00:22:41,695 1822 | 每次可以打开一个功能 1823 | 或者关闭一个功能 1824 | 1825 | 1826 | 329 1827 | 00:22:41,762 --> 00:22:44,398 1828 | 也可以批量处理多个功能 1829 | 1830 | 1831 | 330 1832 | 00:22:45,265 --> 00:22:48,402 1833 | 有了字体描述符 1834 | 就可以用它创建另一个UIFont 1835 | 1836 | 1837 | 331 1838 | 00:22:49,036 --> 00:22:49,870 1839 | 或者NSFont 1840 | 1841 | 1842 | 332 1843 | 00:22:51,738 --> 00:22:54,942 1844 | 此外还有其他功能供大家使用 1845 | 1846 | 1847 | 333 1848 | 00:22:55,008 --> 00:22:59,613 1849 | 比如高体字和上角标 1850 | 或者矮体字和下角表 1851 | 1852 | 1853 | 334 1854 | 00:23:01,882 --> 00:23:07,187 1855 | 或在数字和大写字母之间输入数学符号 1856 | 1857 | 1858 | 335 1859 | 00:23:07,254 --> 00:23:10,224 1860 | 或其它符号时所使用的大写形式 1861 | 1862 | 1863 | 336 1864 | 00:23:11,925 --> 00:23:15,362 1865 | San Francisco字体的 1866 | 某些功能在设计上确实非常特殊 1867 | 1868 | 1869 | 337 1870 | 00:23:15,562 --> 00:23:16,797 1871 | 我来具体解释一下 1872 | 1873 | 1874 | 338 1875 | 00:23:17,965 --> 00:23:20,100 1876 | 首先是垂直居中冒号 1877 | 1878 | 1879 | 339 1880 | 00:23:21,502 --> 00:23:25,839 1881 | 默认状态下它是与小写字母对齐的 1882 | 所以顶靠在基准线上 1883 | 1884 | 1885 | 340 1886 | 00:23:26,206 --> 00:23:30,711 1887 | 但在对时间显示进行排版设计时 1888 | 我们希望它能垂直居中于数字之间 1889 | 1890 | 1891 | 341 1892 | 00:23:31,445 --> 00:23:34,882 1893 | 因此我们在iOS的表盘设计中 1894 | 全部采用了这种居中垂直法 1895 | 1896 | 1897 | 342 1898 | 00:23:35,315 --> 00:23:39,319 1899 | 既用在OS X的标题栏 1900 | 也用在啊Apple手表系统 1901 | 1902 | 1903 | 343 1904 | 00:23:39,920 --> 00:23:41,788 1905 | 还用在秒表程序上 1906 | 1907 | 1908 | 344 1909 | 00:23:42,489 --> 00:23:48,562 1910 | 后来我们决定把该功能设成自动生效 1911 | 这样能为UI设计的时间显示带来便利 1912 | 1913 | 1914 | 345 1915 | 00:23:51,298 --> 00:23:54,334 1916 | 当然必要时 1917 | 你也可以退出该功能 1918 | 1919 | 1920 | 346 1921 | 00:23:54,401 --> 00:23:58,272 1922 | 退出的功能代码和 1923 | 和启用代码基本是一样的 1924 | 1925 | 1926 | 347 1927 | 00:23:59,206 --> 00:24:03,110 1928 | 另外一个功能是6和9的替代形状 1929 | 1930 | 1931 | 348 1932 | 00:24:03,944 --> 00:24:08,682 1933 | 这两个形状当字体较大时看起来很漂亮 1934 | 采用的是grotesque字体 1935 | 1936 | 1937 | 349 1938 | 00:24:09,283 --> 00:24:12,653 1939 | 但是它们却存在视觉混淆问题 1940 | 1941 | 1942 | 350 1943 | 00:24:12,986 --> 00:24:16,957 1944 | 当它们以小字体并列显示 1945 | 或者与8并列示时就会变得混淆不清 1946 | 1947 | 1948 | 351 1949 | 00:24:18,225 --> 00:24:23,931 1950 | 因此我们在San Francisco字体 1951 | 中设计了6和9的替代形状 1952 | 1953 | 1954 | 352 1955 | 00:24:24,164 --> 00:24:25,566 1956 | 看起来更加平直化 1957 | 1958 | 1959 | 353 1960 | 00:24:26,200 --> 00:24:30,170 1961 | 这种设计被应用在 1962 | Apple手表系统的小表盘上 1963 | 1964 | 1965 | 354 1966 | 00:24:30,604 --> 00:24:33,941 1967 | 以及Apple手表背面的序列号上 1968 | 1969 | 1970 | 355 1971 | 00:24:34,408 --> 00:24:37,711 1972 | 其实在任何序列号不易分辨的情况下 1973 | 你都可以使用这一功能 1974 | 1975 | 1976 | 356 1977 | 00:24:37,978 --> 00:24:39,179 1978 | 让6和9显示地更加清晰 1979 | 1980 | 1981 | 357 1982 | 00:24:40,047 --> 00:24:42,783 1983 | 因为使用时要取决其它数字的实际大小 1984 | 1985 | 1986 | 358 1987 | 00:24:43,083 --> 00:24:45,686 1988 | 所以我们没有把该功能设为自动开启 1989 | 1990 | 1991 | 359 1992 | 00:24:46,620 --> 00:24:50,224 1993 | 如果需要的话可以使用 1994 | 这段功能代码来启动它 1995 | 1996 | 1997 | 360 1998 | 00:24:53,360 --> 00:24:55,729 1999 | 接下来 2000 | 我要把两种理念结合起来 2001 | 2002 | 2003 | 361 2004 | 00:24:55,796 --> 00:24:58,298 2005 | 第一种是我们刚刚看到的字形功能 2006 | 2007 | 2008 | 362 2009 | 00:24:58,732 --> 00:25:00,834 2010 | 第二种是我们先前讲过的视觉尺寸 2011 | 2012 | 2013 | 363 2014 | 00:25:02,836 --> 00:25:05,572 2015 | 显示字体和文字字体 2016 | 在设计上的区别很大 2017 | 2018 | 2019 | 364 2020 | 00:25:05,639 --> 00:25:10,010 2021 | 因此我们不得不将 2022 | 磅值纳入到考虑范围内 2023 | 2024 | 2025 | 365 2026 | 00:25:10,544 --> 00:25:12,813 2027 | 在设计过程中 2028 | 如果用显示字体来表达分数 2029 | 2030 | 2031 | 366 2032 | 00:25:12,880 --> 00:25:15,082 2033 | 那么使用卷曲形的6不会有任何问题 2034 | 2035 | 2036 | 367 2037 | 00:25:15,482 --> 00:25:19,253 2038 | 但如果是文字字体的话 2039 | 最好能换成另一种形状 2040 | 2041 | 2042 | 368 2043 | 00:25:19,319 --> 00:25:22,222 2044 | 因为如果将磅值设为12 2045 | 2046 | 2047 | 369 2048 | 00:25:22,456 --> 00:25:24,525 2049 | 那么分数部分的磅值就应该是6 2050 | 对吧？ 2051 | 2052 | 2053 | 370 2054 | 00:25:25,092 --> 00:25:26,660 2055 | 所以我们采取了不同的设计方式 2056 | 2057 | 2058 | 371 2059 | 00:25:26,994 --> 00:25:28,762 2060 | 并且让它们间隔更远一些 2061 | 2062 | 2063 | 372 2064 | 00:25:29,196 --> 00:25:32,733 2065 | 我们在 San Francisco字体中 2066 | 专门进行了很多这样形状的处理 2067 | 2068 | 2069 | 373 2070 | 00:25:32,799 --> 00:25:39,406 2071 | 目的就是将文本和显示区别开来 2072 | 从而让文字更加美观或者更加易读 2073 | 2074 | 2075 | 374 2076 | 00:25:42,209 --> 00:25:44,178 2077 | 这些就是字形功能 2078 | 2079 | 2080 | 375 2081 | 00:25:44,778 --> 00:25:46,914 2082 | 它们是被嵌入文字内部的行为作用 2083 | 2084 | 2085 | 376 2086 | 00:25:48,448 --> 00:25:52,085 2087 | 有些功能是由系统字体默认开启的 2088 | 2089 | 2090 | 377 2091 | 00:25:52,819 --> 00:25:55,656 2092 | 而其它功能则需要大家自己启用 2093 | 2094 | 2095 | 378 2096 | 00:25:59,092 --> 00:26:02,996 2097 | 接下来我们谈谈数字 2098 | 2099 | 2100 | 379 2101 | 00:26:03,163 --> 00:26:06,366 2102 | 不是app里面的数字 2103 | 而是字体里面的数字 2104 | 2105 | 2106 | 380 2107 | 00:26:07,601 --> 00:26:12,239 2108 | 字体设计人员花费大量 2109 | 时间去研究数字的形状 2110 | 2111 | 2112 | 381 2113 | 00:26:12,306 --> 00:26:15,309 2114 | 想让数字更加美观 实用更加完善 2115 | 2116 | 2117 | 382 2118 | 00:26:16,310 --> 00:26:19,146 2119 | 不过我想谈谈数字的间距 2120 | 2121 | 2122 | 383 2123 | 00:26:19,213 --> 00:26:20,147 2124 | 它们的宽度问题 2125 | 2126 | 2127 | 384 2128 | 00:26:21,949 --> 00:26:23,417 2129 | 默认状态下 2130 | 对于我们的平台而言 2131 | 2132 | 2133 | 385 2134 | 00:26:23,483 --> 00:26:27,120 2135 | 数字采用的是等宽式设计 2136 | 就是说它们的宽度完全相同 2137 | 2138 | 2139 | 386 2140 | 00:26:28,789 --> 00:26:33,594 2141 | 对于编排表格之类的设计非常适用 2142 | 2143 | 2144 | 387 2145 | 00:26:33,961 --> 00:26:37,164 2146 | 等宽数字简单方便 2147 | 因为它们很容易对齐 2148 | 2149 | 2150 | 388 2151 | 00:26:37,798 --> 00:26:40,801 2152 | 而且还可以用来制作多行样式 2153 | 2154 | 2155 | 389 2156 | 00:26:42,436 --> 00:26:45,672 2157 | 但它并非San Francisco 2158 | 字体中唯一的数字形式 2159 | 2160 | 2161 | 390 2162 | 00:26:46,139 --> 00:26:49,042 2163 | 我们还设计了一种比例数字 2164 | 2165 | 2166 | 391 2167 | 00:26:49,376 --> 00:26:53,080 2168 | 使每个数字都有其“自然”宽度 2169 | 2170 | 2171 | 392 2172 | 00:26:54,248 --> 00:26:58,919 2173 | 某些情况下 2174 | 我们的确需要等宽数字 2175 | 2176 | 2177 | 393 2178 | 00:27:01,388 --> 00:27:06,426 2179 | 比如像这样有小数的时候 2180 | 2181 | 2182 | 394 2183 | 00:27:06,493 --> 00:27:10,531 2184 | 会有摆动效果 2185 | 等宽数字能保持静止不动 2186 | 2187 | 2188 | 395 2189 | 00:27:11,865 --> 00:27:16,870 2190 | 当然有时也需要在静态标签里使用数字 2191 | 2192 | 2193 | 396 2194 | 00:27:16,937 --> 00:27:20,774 2195 | 比如说一条数据 一个电话号码 2196 | 2197 | 2198 | 397 2199 | 00:27:21,341 --> 00:27:26,880 2200 | 收件箱阅读提示 2201 | 或者Email地址以及URL网址 2202 | 2203 | 2204 | 398 2205 | 00:27:27,347 --> 00:27:31,285 2206 | 这时最好使用比例数字 2207 | 2208 | 2209 | 399 2210 | 00:27:32,653 --> 00:27:37,858 2211 | 现在我们用数字内容比较多的 2212 | 日历程序来做个演示 2213 | 2214 | 2215 | 400 2216 | 00:27:39,126 --> 00:27:42,462 2217 | 请看我们在这款应用中所使用的数字 2218 | 以及我们的编排设计方式 2219 | 2220 | 2221 | 401 2222 | 00:27:42,796 --> 00:27:47,034 2223 | 它们没有任何对齐标准 2224 | 只与文字保持一致 2225 | 2226 | 2227 | 402 2228 | 00:27:47,267 --> 00:27:52,506 2229 | 也就是说 我们可以使用 2230 | 应该使用 也确实使用了比例数字 2231 | 2232 | 2233 | 403 2234 | 00:27:55,709 --> 00:27:58,745 2235 | 了解这一点 2236 | 我们就能实现质的飞跃 2237 | 2238 | 2239 | 404 2240 | 00:27:59,413 --> 00:28:02,082 2241 | 就能改变我们的平台默认样式 2242 | 2243 | 2244 | 405 2245 | 00:28:02,182 --> 00:28:07,154 2246 | 为大家提供默认状态下的比例数字 2247 | 并将等宽数字设为可选功能 2248 | 2249 | 2250 | 406 2251 | 00:28:08,422 --> 00:28:11,358 2252 | Apple手表已经率先 2253 | 采用了这种设计方式 2254 | 2255 | 2256 | 407 2257 | 00:28:11,825 --> 00:28:14,027 2258 | 系统默认使用比例数字 2259 | 2260 | 2261 | 408 2262 | 00:28:15,295 --> 00:28:17,531 2263 | 但这毕竟是一次重大变更 2264 | 可能会对布局产生影响 2265 | 2266 | 2267 | 409 2268 | 00:28:17,831 --> 00:28:21,235 2269 | 有鉴于此 2270 | 我们制定了一些规则 2271 | 2272 | 2273 | 410 2274 | 00:28:22,736 --> 00:28:25,639 2275 | 如果app应用 2276 | 未链接到iOS 10.11 2277 | 2278 | 2279 | 411 2280 | 00:28:25,873 --> 00:28:28,041 2281 | 对不起 2282 | 是OS X 10.11和iOS 9 2283 | 2284 | 2285 | 412 2286 | 00:28:28,342 --> 00:28:32,513 2287 | 默认使用的仍是等宽数字 2288 | 系统会自动启用等宽数字 2289 | 2290 | 2291 | 413 2292 | 00:28:34,081 --> 00:28:38,886 2293 | 但如果是重新编译 2294 | 则会使用比例数字 2295 | 2296 | 2297 | 414 2298 | 00:28:39,987 --> 00:28:45,325 2299 | 在AppKit中有款新的快捷API 2300 | 它提取了这一功能代码 2301 | 2302 | 2303 | 415 2304 | 00:28:45,526 --> 00:28:48,395 2305 | 就是刚才给大家看的那段代码 2306 | 所以用起来会更方便 2307 | 2308 | 2309 | 416 2310 | 00:28:52,099 --> 00:28:55,068 2311 | 最后我们来了解一下潜在隐患的问题 2312 | 2313 | 2314 | 417 2315 | 00:28:55,135 --> 00:28:59,139 2316 | 我们的字体API 2317 | 同时包含了新旧字体 2318 | 2319 | 2320 | 418 2321 | 00:29:01,775 --> 00:29:04,578 2322 | 细心的人可能会留意到 2323 | 2324 | 2325 | 419 2326 | 00:29:04,645 --> 00:29:08,048 2327 | 在预览版的OS X和iOS系统中 2328 | 2329 | 2330 | 420 2331 | 00:29:08,515 --> 00:29:12,753 2332 | SF字体的名称前面有一个小点 2333 | 2334 | 2335 | 421 2336 | 00:29:13,587 --> 00:29:17,191 2337 | 这个小点是用来告诉大家 2338 | 该字体是Apple的独家字体 2339 | 2340 | 2341 | 422 2342 | 00:29:17,558 --> 00:29:20,294 2343 | 所以不要过于相信它的稳定性 2344 | 2345 | 2346 | 423 2347 | 00:29:22,329 --> 00:29:25,098 2348 | 我们曾经见过一些框架开发人员 2349 | 2350 | 2351 | 424 2352 | 00:29:25,199 --> 00:29:27,067 2353 | 使用他们自己的字体加载代码 2354 | 2355 | 2356 | 425 2357 | 00:29:27,134 --> 00:29:29,469 2358 | 比如游戏框架的开发人员就是这样 2359 | 2360 | 2361 | 426 2362 | 00:29:29,970 --> 00:29:32,206 2363 | 之所以这样做是因为 2364 | 2365 | 2366 | 427 2367 | 00:29:32,539 --> 00:29:35,843 2368 | 他们觉得字体就存放在文件系统中 2369 | 的某个具体位置上 2370 | 2371 | 2372 | 428 2373 | 00:29:36,343 --> 00:29:37,477 2374 | 这种想法是很危险的 2375 | 2376 | 2377 | 429 2378 | 00:29:37,878 --> 00:29:43,584 2379 | 我们希望大家在字体路径 2380 | 的处理方式上能宽泛一些 2381 | 2382 | 2383 | 430 2384 | 00:29:43,650 --> 00:29:47,688 2385 | 就是说可以通过 2386 | Core text访问字体文件 2387 | 2388 | 2389 | 431 2390 | 00:29:47,754 --> 00:29:51,024 2391 | 而不必到文件系统里面查找 2392 | 2393 | 2394 | 432 2395 | 00:29:52,960 --> 00:29:56,830 2396 | 另外如果要通过 2397 | 名称来获取字体文件的话 2398 | 2399 | 2400 | 433 2401 | 00:29:57,431 --> 00:30:00,300 2402 | 可以使用fontWithName API 2403 | 里面全都是用户字体 2404 | 2405 | 2406 | 434 2407 | 00:30:00,367 --> 00:30:03,136 2408 | 如果你有自己的字体 2409 | 可以这样写出来完全没问题 2410 | 2411 | 2412 | 435 2413 | 00:30:03,637 --> 00:30:05,339 2414 | 但如果你对某个系统字体执行了实例化 2415 | 2416 | 2417 | 436 2418 | 00:30:05,572 --> 00:30:09,109 2419 | 然后再提取它的名称 2420 | 并尝试建立另外一个字体 2421 | 2422 | 2423 | 437 2424 | 00:30:09,610 --> 00:30:13,413 2425 | 这时会导致所有的 2426 | 系统自动设置完全退出 2427 | 2428 | 2429 | 438 2430 | 00:30:13,480 --> 00:30:18,552 2431 | 自动功能 字体大小行为 2432 | 自动间距等等都会退出 2433 | 2434 | 2435 | 439 2436 | 00:30:18,619 --> 00:30:20,921 2437 | 所以建议大家不要这样操作 2438 | 2439 | 2440 | 440 2441 | 00:30:21,455 --> 00:30:23,991 2442 | 其实我们可以调用字体描述符 2443 | 2444 | 2445 | 441 2446 | 00:30:24,458 --> 00:30:29,396 2447 | 用它来实现某个字体功能 2448 | 2449 | 2450 | 442 2451 | 00:30:29,463 --> 00:30:32,699 2452 | 这是使用字体对象的推荐方案 2453 | 2454 | 2455 | 443 2456 | 00:30:35,169 --> 00:30:37,104 2457 | 最后在视觉尺寸问题上 2458 | 2459 | 2460 | 444 2461 | 00:30:37,171 --> 00:30:42,442 2462 | 我们仍然在挑战一些 2463 | 字体显示方面的旧观念 2464 | 2465 | 2466 | 445 2467 | 00:30:42,809 --> 00:30:46,113 2468 | 比如在设计过程中 2469 | 把一个单词的磅值设为15 2470 | 2471 | 2472 | 446 2473 | 00:30:46,380 --> 00:30:51,585 2474 | 将其比例放大后 2475 | 再重新使用相同的字体对象 2476 | 2477 | 2478 | 447 2479 | 00:30:51,919 --> 00:30:57,824 2480 | 这时你可能在用 2481 | 比如说120磅来显示15磅的字体 2482 | 2483 | 2484 | 448 2485 | 00:30:58,425 --> 00:31:03,497 2486 | 那么就要对120磅的字体 2487 | 重新执行实例化 2488 | 2489 | 2490 | 449 2491 | 00:31:03,564 --> 00:31:05,465 2492 | 这样才能得到正确的字体行为 2493 | 2494 | 2495 | 450 2496 | 00:31:08,769 --> 00:31:13,941 2497 | 希望大家能把字体当作一种宽泛的对象 2498 | 并使用系统API来获取字体 2499 | 2500 | 2501 | 451 2502 | 00:31:15,375 --> 00:31:18,846 2503 | 具备了视觉属性 2504 | 字体便能够打破旧有观念 2505 | 2506 | 2507 | 452 2508 | 00:31:20,214 --> 00:31:25,819 2509 | 基于系统字体的API将会 2510 | 一直提供正确的字体行为 2511 | 2512 | 2513 | 453 2514 | 00:31:25,886 --> 00:31:28,288 2515 | 所以大家尽管放心使用 2516 | 2517 | 2518 | 454 2519 | 00:31:30,090 --> 00:31:32,226 2520 | 以上就是今天的全部内容 2521 | 2522 | 2523 | 455 2524 | 00:31:32,292 --> 00:31:34,261 2525 | 我们介绍了 2526 | 新的San Francisco字体 2527 | 2528 | 2529 | 456 2530 | 00:31:34,328 --> 00:31:38,165 2531 | 及San Francisco的优秀创意 视觉尺寸 2532 | 还有其它一些概念 2533 | 2534 | 2535 | 457 2536 | 00:31:38,732 --> 00:31:42,870 2537 | 介绍了自动字符间距和字体字重 2538 | 及San Francisco的各种功能 2539 | 2540 | 2541 | 458 2542 | 00:31:43,337 --> 00:31:46,573 2543 | 还有即将在平台上普及的 2544 | 数字显示方面的重大变更 2545 | 2546 | 2547 | 459 2548 | 00:31:46,640 --> 00:31:50,143 2549 | 这将使用比例数字作为默认显示 2550 | 2551 | 2552 | 460 2553 | 00:31:50,511 --> 00:31:53,814 2554 | 最后我们介绍了API的潜在隐患 2555 | 2556 | 2557 | 461 2558 | 00:31:54,648 --> 00:31:58,485 2559 | 如果您有任何问题 2560 | 可以联系 迈克 或 柯特 2561 | 2562 | 2563 | 462 2564 | 00:31:59,052 --> 00:32:00,954 2565 | 或者访问我们的开发者网站 2566 | 2567 | 2568 | 463 2569 | 00:32:02,623 --> 00:32:05,225 2570 | 稍后的演讲是手表设计的要诀和技巧 2571 | 2572 | 2573 | 464 2574 | 00:32:05,592 --> 00:32:08,395 2575 | 之后是文字与字体实验室 2576 | 届时会有答疑环节 2577 | 2578 | 2579 | 465 2580 | 00:32:08,962 --> 00:32:10,564 2581 | 谢谢大家 2582 | 2583 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # WWDC中文字幕 2 | -------------------------------------------------------------------------------- /SD/502_sd_content_protection_for_http_live_streaming.srt: -------------------------------------------------------------------------------- 1 | 1 2 | 00:00:20,020 --> 00:00:21,555 3 | HTTP实时流媒体播放的扩展 4 | 5 | 6 | 2 7 | 00:00:25,425 --> 00:00:26,326 8 | 大家早上好！ 9 | 10 | 11 | 3 12 | 00:00:27,427 --> 00:00:31,098 13 | 欢迎参加今年的全球开发者大会 14 | 15 | 16 | 4 17 | 00:00:31,532 --> 00:00:33,901 18 | 这是您参加的 19 | 第一个真正的讲座环节 20 | 21 | 22 | 5 23 | 00:00:34,601 --> 00:00:35,836 24 | 因此欢迎您！ 25 | 26 | 27 | 6 28 | 00:00:37,137 --> 00:00:39,106 29 | 今天... 30 | 谢谢你 31 | 32 | 33 | 7 34 | 00:00:39,773 --> 00:00:44,411 35 | 今天我们将讨论 36 | HTTP实时流媒体播放的 37 | 38 | 39 | 8 40 | 00:00:44,678 --> 00:00:46,380 41 | 一个非常激动人心的扩展 42 | 43 | 44 | 9 45 | 00:00:47,681 --> 00:00:53,453 46 | 你知道我们一直在关注 47 | 究竟是什么阻止了你们 48 | 49 | 50 | 10 51 | 00:00:53,520 --> 00:00:57,591 52 | 以自己喜欢的方式 53 | 使用HLS来部署内容 54 | 55 | 56 | 11 57 | 00:00:58,292 --> 00:01:00,027 58 | 而内容保护 59 | 60 | 61 | 12 62 | 00:01:00,260 --> 00:01:05,699 63 | 是指让您的用户观看或收听您的内容 64 | 65 | 66 | 13 67 | 00:01:06,400 --> 00:01:08,635 68 | 却不授权使用它 69 | 70 | 71 | 14 72 | 00:01:09,203 --> 00:01:14,308 73 | 一直是一个真正有难度的问题 74 | 你们中的很多人曾经不得不设法应对 75 | 76 | 77 | 15 78 | 00:01:15,075 --> 00:01:18,745 79 | 而且随着比特率的升高 80 | 以及分辨率的上升 81 | 82 | 83 | 16 84 | 00:01:18,912 --> 00:01:20,614 85 | 那些需求将只会增大 86 | 87 | 88 | 17 89 | 00:01:21,481 --> 00:01:27,588 90 | 那也是我为何 91 | 终于能够高兴地宣布 92 | 93 | 94 | 18 95 | 00:01:28,589 --> 00:01:30,390 96 | FairPlay流媒体的诞生 97 | 98 | 99 | 19 100 | 00:01:31,692 --> 00:01:32,626 101 | 那么它是什么？ 102 | 103 | 104 | 20 105 | 00:01:34,394 --> 00:01:40,901 106 | 首先 107 | 它是我们最出色的内容保护技术 108 | 109 | 110 | 21 111 | 00:01:41,101 --> 00:01:46,139 112 | 它的封装方式允许您将其用于 113 | 保护您的HLS内容 114 | 115 | 116 | 22 117 | 00:01:47,140 --> 00:01:48,175 118 | 现在 它已不是新事物了 119 | 120 | 121 | 23 122 | 00:01:48,809 --> 00:01:52,279 123 | 我们在过去三年一直在 124 | 125 | 126 | 24 127 | 00:01:52,880 --> 00:01:55,082 128 | 与一些主要内容合作伙伴进行合作 129 | 130 | 131 | 25 132 | 00:01:55,849 --> 00:01:59,553 133 | 帮助它们在app 134 | 或Apple TV上部署FPS 135 | 136 | 137 | 26 138 | 00:02:00,187 --> 00:02:05,158 139 | 现在它已被用来保护大量的内容 140 | 141 | 142 | 27 143 | 00:02:05,425 --> 00:02:10,597 144 | 包括一些世界上最热门的 145 | 电影和电视节目 146 | 147 | 148 | 28 149 | 00:02:15,836 --> 00:02:21,642 150 | 现在您可以将它用于iOS 151 | 及Apple TV和OS X上 152 | 153 | 154 | 29 155 | 00:02:22,910 --> 00:02:26,513 156 | 当然 157 | 在我们的移动设备上 电池寿命是王道 158 | 159 | 160 | 30 161 | 00:02:27,080 --> 00:02:30,217 162 | 所以当我们设计 163 | FairPlay流媒体的时候 164 | 165 | 166 | 31 167 | 00:02:31,185 --> 00:02:35,656 168 | 我们所做的每个决定都是建立在 169 | 为您实现良好的电池寿命的基础上的 170 | 171 | 172 | 32 173 | 00:02:35,756 --> 00:02:38,759 174 | 我们选择的编解码器 175 | 我们选择的加密技术 176 | 177 | 178 | 33 179 | 00:02:39,092 --> 00:02:41,929 180 | 我们的实施方式 181 | 甚至我们利用的硬件 182 | 183 | 184 | 34 185 | 00:02:42,329 --> 00:02:45,632 186 | 所以您会有极大的安全性 187 | 也会有很好的电池寿命 188 | 189 | 190 | 35 191 | 00:02:47,000 --> 00:02:52,806 192 | 而且它也与AirPlay无缝集成 193 | 因此它会伴随全面的保护 194 | 195 | 196 | 36 197 | 00:02:54,141 --> 00:02:57,945 198 | 不过您可能会说： 199 | “好吧 那听上去很不错 200 | 201 | 202 | 37 203 | 00:02:58,412 --> 00:02:59,546 204 | 但是我有很多内容 205 | 206 | 207 | 38 208 | 00:02:59,680 --> 00:03:04,251 209 | 我的意思是Apple 210 | 将如何让我为这个FPS付费？ 211 | 212 | 213 | 39 214 | 00:03:04,318 --> 00:03:07,454 215 | 它将是按照影片收费？ 216 | 按每次播放还是统一价格？” 217 | 218 | 219 | 40 220 | 00:03:08,722 --> 00:03:12,326 221 | 我们反复尝试 222 | 最后我们确定采用统一价格 223 | 224 | 225 | 41 226 | 00:03:13,794 --> 00:03:14,628 227 | 零 228 | 229 | 230 | 42 231 | 00:03:15,996 --> 00:03:19,800 232 | 如果大家每年向我们 233 | 支付99美元的开发者费用 234 | 235 | 236 | 43 237 | 00:03:20,100 --> 00:03:24,838 238 | 您将不必再向苹果公司支付一分钱 239 | 就能尽情使用FPS 240 | 241 | 242 | 44 243 | 00:03:26,240 --> 00:03:31,645 244 | 那么现在 观众中间任何从事 245 | 市场营销的朋友可能会说这样的话： 246 | 247 | 248 | 45 249 | 00:03:31,712 --> 00:03:33,146 250 | “哦 那听上去棒极了！” 251 | 252 | 253 | 46 254 | 00:03:33,480 --> 00:03:36,483 255 | 而坐你旁边的工程师可能会说： 256 | “不 不 真的吗？ 它是什么？” 257 | 258 | 259 | 47 260 | 00:03:36,850 --> 00:03:37,784 261 | 好了 那么 262 | 263 | 264 | 48 265 | 00:03:38,352 --> 00:03:41,121 266 | 它实际上是非常简单的 267 | 268 | 269 | 49 270 | 00:03:41,922 --> 00:03:46,326 271 | 我们所做的就是着手解决了DRM系统 272 | 273 | 274 | 50 275 | 00:03:46,393 --> 00:03:48,962 276 | 最重要的组成部分 即密钥保护 277 | 278 | 279 | 51 280 | 00:03:49,963 --> 00:03:55,335 281 | 那么FPS在本质上及实际上是一个 282 | 安全的密钥传送系统 283 | 284 | 285 | 52 286 | 00:03:55,669 --> 00:03:59,006 287 | 它是一种将密钥 288 | 从您在互联网上的服务器 289 | 290 | 291 | 53 292 | 00:03:59,473 --> 00:04:01,775 293 | 转移到设备上的方式 294 | 295 | 296 | 54 297 | 00:04:02,543 --> 00:04:07,648 298 | 让您在该设备上使用密钥 299 | 同时不让攻击者获取它并解密您的内容 300 | 301 | 302 | 55 303 | 00:04:08,849 --> 00:04:12,920 304 | 在设计方面 305 | 我们让它容易使用和采用 306 | 307 | 308 | 56 309 | 00:04:13,487 --> 00:04:15,822 310 | 我们认识到你们中的很多人 311 | 312 | 313 | 57 314 | 00:04:15,889 --> 00:04:20,360 315 | 尤其是当您以流媒体提供 316 | 高级内容或订阅内容时 317 | 318 | 319 | 58 320 | 00:04:20,427 --> 00:04:22,963 321 | 您已经在与某种安全后端对话了 322 | 323 | 324 | 59 325 | 00:04:23,664 --> 00:04:26,233 326 | 因此我们设计了FPS 327 | 328 | 329 | 60 330 | 00:04:26,300 --> 00:04:30,003 331 | 让传送这部分工作成为不可知 332 | 让您使用的协议成为隐蔽 333 | 334 | 335 | 61 336 | 00:04:30,070 --> 00:04:34,842 337 | 如果您拥有安全连接 338 | 您可以极其容易地采用FPS 339 | 340 | 341 | 62 342 | 00:04:35,342 --> 00:04:37,878 343 | 如果没有 你也可以使用HTTPS 344 | 它是一个很不错的选择 345 | 346 | 347 | 63 348 | 00:04:39,346 --> 00:04:42,683 349 | 最后 过去很多朋友 350 | 问我关于HDCP方面的事情 351 | 352 | 353 | 64 354 | 00:04:43,250 --> 00:04:45,586 355 | FPS就是这个问题的答案 356 | 357 | 358 | 65 359 | 00:04:46,987 --> 00:04:51,992 360 | 如果您的设备连接了电视 361 | 或其他外部输入 362 | 363 | 364 | 66 365 | 00:04:52,593 --> 00:04:54,094 366 | 它一定是HDMI 367 | 368 | 369 | 67 370 | 00:04:54,661 --> 00:04:56,763 371 | 而HDCP一定是活跃的 372 | 373 | 374 | 68 375 | 00:04:57,164 --> 00:05:00,400 376 | 否则任何FPS内容播放都会失败 377 | 378 | 379 | 69 380 | 00:05:01,235 --> 00:05:02,135 381 | 没有例外 382 | 383 | 384 | 70 385 | 00:05:04,204 --> 00:05:07,207 386 | 当我们设计它的时候 387 | 388 | 389 | 71 390 | 00:05:07,708 --> 00:05:13,013 391 | 我们知道有很多商业规则或逻辑的区别 392 | 而每个人都有自己的口味 393 | 394 | 395 | 72 396 | 00:05:13,080 --> 00:05:15,382 397 | 而我们不希望 398 | 建立一个庞大而复杂的东西 399 | 400 | 401 | 73 402 | 00:05:15,749 --> 00:05:17,284 403 | 并迫使你们进入我们的盒子 404 | 405 | 406 | 74 407 | 00:05:17,784 --> 00:05:21,255 408 | 所以我们建立了 409 | 这个密钥传送机制 410 | 411 | 412 | 75 413 | 00:05:21,722 --> 00:05:25,259 414 | 我们并不是创建了一种 415 | 权利表达语言评估工具 416 | 417 | 418 | 76 419 | 00:05:25,325 --> 00:05:28,695 420 | 或者是一长串您需要遵守的策略 421 | 422 | 423 | 77 424 | 00:05:29,363 --> 00:05:33,667 425 | 而那意味着 426 | 如果您的商业逻辑要求那些东西 427 | 428 | 429 | 78 430 | 00:05:33,734 --> 00:05:35,936 431 | 您是可以掌控的 432 | 您依然是守门员 433 | 434 | 435 | 79 436 | 00:05:36,470 --> 00:05:39,273 437 | 因此 一旦您为媒体堆栈 438 | 赋予了一个FPS密钥 439 | 440 | 441 | 80 442 | 00:05:39,339 --> 00:05:40,774 443 | 毫无问题 444 | 我们将播放它 445 | 446 | 447 | 81 448 | 00:05:40,841 --> 00:05:42,376 449 | 我们将保护密钥 450 | 我们将去播放它 451 | 452 | 453 | 82 454 | 00:05:43,076 --> 00:05:46,146 455 | 如果您需要实施某种策略实施 456 | 457 | 458 | 83 459 | 00:05:46,246 --> 00:05:50,751 460 | 或进行用户认证 461 | 或对每个设备插槽进行管理 462 | 463 | 464 | 84 465 | 00:05:51,151 --> 00:05:53,987 466 | 那么您就可以在FPS上那么做 467 | 468 | 469 | 85 470 | 00:05:54,421 --> 00:05:57,224 471 | 而且它将是非常容易整合的 472 | 473 | 474 | 86 475 | 00:05:58,458 --> 00:06:00,694 476 | 那么现在让我们讨论一些具体步骤 477 | 478 | 479 | 87 480 | 00:06:01,161 --> 00:06:03,096 481 | 那就是FPS为您提供的基本功能 482 | 483 | 484 | 88 485 | 00:06:03,430 --> 00:06:06,200 486 | 让我们讨论一下 487 | 您采用它需要采取的步骤 488 | 489 | 490 | 89 491 | 00:06:07,467 --> 00:06:09,002 492 | 主要有三步 493 | 494 | 495 | 90 496 | 00:06:09,603 --> 00:06:12,039 497 | 第一步 498 | 也极可能是最重要的一步是 499 | 500 | 501 | 91 502 | 00:06:12,372 --> 00:06:15,709 503 | 由于FPS是一个在线密钥传送协议 504 | 505 | 506 | 92 507 | 00:06:16,343 --> 00:06:20,447 508 | 您必须在线获取您的密钥 509 | 而一旦播放停止密钥即消失 510 | 511 | 512 | 93 513 | 00:06:21,248 --> 00:06:26,386 514 | 您需要把我们所谓的“密钥安全模块” 515 | 集成到您的密钥服务器中 516 | 517 | 518 | 94 519 | 00:06:27,421 --> 00:06:31,024 520 | 因此那是最重大的一步 521 | 稍后我们将详细讨论那个话题 522 | 523 | 524 | 95 525 | 00:06:31,692 --> 00:06:35,462 526 | 但是第二件事情是 527 | 您需向您的应用添加一些代码 528 | 529 | 530 | 96 531 | 00:06:36,029 --> 00:06:39,166 532 | 称为AV Asset Resource Loader Delegate 533 | 534 | 535 | 97 536 | 00:06:39,766 --> 00:06:45,372 537 | 那段代码负责将来自 538 | AV Foundation的密钥请求传送到后端 539 | 540 | 541 | 98 542 | 00:06:45,706 --> 00:06:49,610 543 | 然后将您后端发出的响应 544 | 并返回给AV Foundation 545 | 546 | 547 | 99 548 | 00:06:50,310 --> 00:06:52,513 549 | 最后您需要做的是准备您的内容 550 | 551 | 552 | 100 553 | 00:06:52,579 --> 00:06:57,784 554 | 而那意味着您需要 555 | 使用AES示例加密法将其加密 556 | 557 | 558 | 101 559 | 00:06:58,085 --> 00:07:03,290 560 | 巧的是 这是我们三年前引入的 561 | 562 | 563 | 102 564 | 00:07:04,558 --> 00:07:10,864 565 | 因此与最初HLS使用的传统 566 | 整段代码加密不同的是 567 | 568 | 569 | 103 570 | 00:07:11,098 --> 00:07:14,168 571 | 这种加密法仅加密 572 | 每段示例代码中小的片段 573 | 574 | 575 | 104 576 | 00:07:14,434 --> 00:07:19,106 577 | 这确保了我们能够 578 | 在系统基本水平上进行解密工作 579 | 580 | 581 | 105 582 | 00:07:20,140 --> 00:07:22,476 583 | 因此您需要选择一个内容密钥 584 | 585 | 586 | 106 587 | 00:07:22,543 --> 00:07:24,111 588 | 将其存放在您的后端数据库内 589 | 590 | 591 | 107 592 | 00:07:24,411 --> 00:07:25,479 593 | 对您的内容进行加密 594 | 595 | 596 | 108 597 | 00:07:25,746 --> 00:07:28,649 598 | 然后将对那个密钥的引用加入播放列表 599 | 600 | 601 | 109 602 | 00:07:28,882 --> 00:07:31,652 603 | 以便当您的那小段代码 604 | 接到对密钥的请求时 605 | 606 | 607 | 110 608 | 00:07:31,718 --> 00:07:33,854 609 | 能够知道向后端请求哪个密钥 610 | 611 | 612 | 111 613 | 00:07:35,155 --> 00:07:40,928 614 | 那么我接下来将要做的 615 | 是进一步详述这三个步骤 616 | 617 | 618 | 112 619 | 00:07:41,328 --> 00:07:45,465 620 | 在那之前 我想介绍我的一位同事 621 | 622 | 623 | 113 624 | 00:07:45,799 --> 00:07:47,434 625 | 他是FairPlay团队成员之一 626 | 627 | 628 | 114 629 | 00:07:47,734 --> 00:07:48,936 630 | 詹保罗 法索里 631 | 632 | 633 | 115 634 | 00:07:50,070 --> 00:07:50,904 635 | 欢迎！ 636 | 637 | 638 | 116 639 | 00:07:56,143 --> 00:07:57,044 640 | 谢谢你 罗哲斯！ 641 | 642 | 643 | 117 644 | 00:07:58,145 --> 00:08:00,214 645 | 大家早上好！ 646 | 我叫詹保罗 法索里 647 | 648 | 649 | 118 650 | 00:08:00,280 --> 00:08:02,783 651 | 是Apple的FPS工程师 652 | 653 | 654 | 119 655 | 00:08:03,684 --> 00:08:06,753 656 | 继罗哲斯所做的概述 657 | 我想跟大家谈一下 658 | 659 | 660 | 120 661 | 00:08:06,820 --> 00:08:09,256 662 | 设计一个FPS系统需要些什么 663 | 664 | 665 | 121 666 | 00:08:09,323 --> 00:08:10,791 667 | 我想讲的第一件事 668 | 669 | 670 | 122 671 | 00:08:11,291 --> 00:08:17,631 672 | 是我们所谓的FairPlay流媒体 673 | 证书的目的和重要性 674 | 675 | 676 | 123 677 | 00:08:18,365 --> 00:08:23,270 678 | 接下来 679 | 我将识别系统和数据流中的活动要素 680 | 681 | 682 | 124 683 | 00:08:24,638 --> 00:08:27,975 684 | 然后我将讨论苹果公司将在您 685 | 构建的东西中会提供哪些东西 686 | 687 | 688 | 125 689 | 00:08:28,041 --> 00:08:31,144 690 | 而在您将构建的东西中 691 | 我们将先从服务器端讲起 692 | 693 | 694 | 126 695 | 00:08:31,211 --> 00:08:36,683 696 | 以及如何将Roger刚才所讲的 697 | 密钥安全模块集成到您的密钥服务器中 698 | 699 | 700 | 127 701 | 00:08:37,217 --> 00:08:39,586 702 | 我们将讨论如何测试集成 703 | 704 | 705 | 128 706 | 00:08:40,254 --> 00:08:45,492 707 | 接下来我们将讨论客户端 708 | 以及如何将FPS集成到您的应用中 709 | 710 | 711 | 129 712 | 00:08:45,559 --> 00:08:52,232 713 | 然后我们将讨论 714 | 您将对内容制作工作流的更新 715 | 716 | 717 | 130 718 | 00:08:52,966 --> 00:08:57,337 719 | 以便将内容加密 并确认 720 | 您将对工作流的更改 721 | 722 | 723 | 131 724 | 00:08:59,239 --> 00:09:02,910 725 | 那么当我们讨论FPS证书的时候 726 | 727 | 728 | 132 729 | 00:09:03,010 --> 00:09:05,946 730 | 我们有那些证书是为了 731 | 732 | 733 | 133 734 | 00:09:06,013 --> 00:09:12,519 735 | 能够将您的FPS部署 736 | 和那里已经存在的部署区分开来 737 | 738 | 739 | 134 740 | 00:09:13,053 --> 00:09:16,290 741 | 之所以需要它们是因为有了它们 742 | 743 | 744 | 135 745 | 00:09:16,356 --> 00:09:20,494 746 | 您的客户才可以在他们的设备上 747 | 实际播放他们的内容 748 | 749 | 750 | 136 751 | 00:09:21,929 --> 00:09:27,968 752 | 出于这些原因 753 | 保护FPS证书资产资源就十分重要了 754 | 755 | 756 | 137 757 | 00:09:28,202 --> 00:09:30,204 758 | 不管是当它们被部署在服务器上 759 | 760 | 761 | 138 762 | 00:09:30,270 --> 00:09:31,505 763 | 还是在您的服务器上被使用 764 | 765 | 766 | 139 767 | 00:09:32,306 --> 00:09:33,674 768 | 要确保它们得到保护 769 | 770 | 771 | 140 772 | 00:09:34,641 --> 00:09:40,380 773 | 那么现在继续往下看图表 774 | 左边我们已经有了服务器组件 775 | 776 | 777 | 141 778 | 00:09:40,681 --> 00:09:42,216 779 | 也就是您的密钥服务器 780 | 781 | 782 | 142 783 | 00:09:42,316 --> 00:09:46,119 784 | 它内部已经集成了FPS密钥安全模块 785 | 786 | 787 | 143 788 | 00:09:46,854 --> 00:09:51,458 789 | 密钥数据库里面含有 790 | 用来为您的流媒体加密内容密钥值 791 | 792 | 793 | 144 794 | 00:09:51,725 --> 00:09:56,029 795 | 而在右边我们有客户端活动要素 796 | 即是您的应用 797 | 798 | 799 | 145 800 | 00:09:56,396 --> 00:09:59,600 801 | 罗哲斯刚才讲的 802 | AVFoundation Delegate和AVFoundation 803 | 804 | 805 | 146 806 | 00:09:59,666 --> 00:10:03,470 807 | 已经为我们提供了部分操作系统 808 | 即我们的iOS或Mac OS X 809 | 810 | 811 | 147 812 | 00:10:04,938 --> 00:10:09,176 813 | 那么让我们讨论一下 当用户在您的 814 | 应用中点击播放的时候会发生什么 815 | 816 | 817 | 148 818 | 00:10:09,243 --> 00:10:10,544 819 | 第一件会发生的事情是 820 | 821 | 822 | 149 823 | 00:10:11,011 --> 00:10:13,514 824 | 您的应用将调用AVFoundation 825 | 826 | 827 | 150 828 | 00:10:13,580 --> 00:10:16,683 829 | 并为其提供即将赋予 830 | 加密内容的m3u8 URL 831 | 832 | 833 | 151 834 | 00:10:17,184 --> 00:10:21,288 835 | AVFoundation将从互联网 836 | 抽取那个播放列表并对其进行解析 837 | 838 | 839 | 152 840 | 00:10:21,655 --> 00:10:23,790 841 | 当它注意到内容被加密的时候 842 | 843 | 844 | 153 845 | 00:10:23,857 --> 00:10:28,028 846 | 它将回调您的Delegate 847 | 告诉它需要一个密钥以便播放内容 848 | 849 | 850 | 154 851 | 00:10:29,196 --> 00:10:32,299 852 | Delegate将进行处理 853 | 它将调入AVFoundation 854 | 855 | 856 | 155 857 | 00:10:32,366 --> 00:10:37,070 858 | 并请求后者创建 859 | 所谓的服务器上下文播放 860 | 861 | 862 | 156 863 | 00:10:37,971 --> 00:10:40,841 864 | 在FPS术语中 865 | 我们将其简称为SPC 866 | 867 | 868 | 157 869 | 00:10:40,908 --> 00:10:41,942 870 | 而那是什么？ 871 | 872 | 873 | 158 874 | 00:10:42,209 --> 00:10:47,414 875 | 它是一个Delegate的密钥请求 876 | 它将用post方法提交给密钥服务器 877 | 878 | 879 | 159 880 | 00:10:48,248 --> 00:10:51,818 881 | 以便完成其工作并传递内容密钥 882 | 883 | 884 | 160 885 | 00:10:52,186 --> 00:10:53,921 886 | 这里需要注意的重要一点是 887 | 888 | 889 | 161 890 | 00:10:54,321 --> 00:11:01,061 891 | SPC是在客户端上的 892 | FPS传递上下文中创建的 893 | 894 | 895 | 162 896 | 00:11:01,495 --> 00:11:03,964 897 | 而那是一个特定会话上下文 898 | 899 | 900 | 163 901 | 00:11:05,098 --> 00:11:07,734 902 | 只有那台设备能够创建它 903 | 904 | 905 | 164 906 | 00:11:07,801 --> 00:11:11,905 907 | 也只有那台设备能够为其处理 908 | 来自于服务器的响应 909 | 910 | 911 | 165 912 | 00:11:11,972 --> 00:11:13,807 913 | 它是和设备以及会话绑定的 914 | 915 | 916 | 166 917 | 00:11:14,675 --> 00:11:18,212 918 | 因此当您的服务器准备利用KSM 919 | 920 | 921 | 167 922 | 00:11:18,645 --> 00:11:24,351 923 | 来破解SPC队列请求 924 | 对其格式和加密方法进行验证 925 | 926 | 927 | 168 928 | 00:11:24,718 --> 00:11:27,888 929 | 并在密钥服务器数据库中 930 | 查找对应的内容密钥时 931 | 932 | 933 | 169 934 | 00:11:28,589 --> 00:11:34,828 935 | 它将把那个内容密钥值 936 | 打包为我们所称的内容密钥上下文 937 | 938 | 939 | 170 940 | 00:11:35,162 --> 00:11:36,530 941 | 或简称为CKC 942 | 943 | 944 | 171 945 | 00:11:37,164 --> 00:11:40,634 946 | 而您的app delegate 947 | 将要执行的最后一步是 948 | 949 | 950 | 172 951 | 00:11:40,701 --> 00:11:43,504 952 | 将那个CKC 953 | 返回给AVFoundation 954 | 955 | 956 | 173 957 | 00:11:44,471 --> 00:11:48,942 958 | 那么此刻设备已经有了 959 | 它对内容的解密和播放所需要的一切 960 | 961 | 962 | 174 963 | 00:11:49,643 --> 00:11:53,947 964 | 那么现在我们已经谈及了FP系统中的 965 | 活动要素和数据流 966 | 967 | 968 | 175 969 | 00:11:54,014 --> 00:11:55,816 970 | 让我们谈一下Apple将供哪些东西 971 | 972 | 973 | 176 974 | 00:11:56,984 --> 00:11:58,785 975 | 当然我们提供AVFoundation 976 | 977 | 978 | 177 979 | 00:11:58,852 --> 00:12:03,023 980 | 在iOS和Mac OS中 981 | AVFoundation的一部分是 982 | 983 | 984 | 178 985 | 00:12:03,090 --> 00:12:05,726 986 | 您将用于执行delegate的API 987 | 988 | 989 | 179 990 | 00:12:06,527 --> 00:12:09,730 991 | 我们提供的另一个工具是 992 | developer.apple.com上的 993 | 994 | 995 | 180 996 | 00:12:09,863 --> 00:12:11,865 997 | FairPlay Streaming SDK 998 | 999 | 1000 | 181 1001 | 00:12:11,932 --> 00:12:13,834 1002 | 那个SDK包含一些特定的内容 1003 | 1004 | 1005 | 182 1006 | 00:12:13,901 --> 00:12:17,504 1007 | 首先它包含一个协议规范 1008 | 1009 | 1010 | 183 1011 | 00:12:18,005 --> 00:12:22,709 1012 | 里面有关于SPC和CKC消息 1013 | 编写格式的全部详细信息 1014 | 1015 | 1016 | 184 1017 | 00:12:23,110 --> 00:12:29,783 1018 | 和您将使用哪些加密原函数 1019 | 来处理密钥请求 及生成密钥响应 1020 | 1021 | 1022 | 185 1023 | 00:12:30,651 --> 00:12:36,757 1024 | 它包含一个在网络控制中心的 1025 | 对密钥安全模块服务器的引用实施 1026 | 1027 | 1028 | 186 1029 | 00:12:37,824 --> 00:12:43,664 1030 | 它包含一整套能够用于服务器部署的 1031 | 服务器测试矢量和验证工具 1032 | 1033 | 1034 | 187 1035 | 00:12:44,398 --> 00:12:47,334 1036 | 它包含一些客户端示例内容 1037 | 1038 | 1039 | 188 1040 | 00:12:48,902 --> 00:12:54,842 1041 | 而它包含的最后一点内容是 1042 | 一套客户端示例代码 1043 | 1044 | 1045 | 189 1046 | 00:12:56,376 --> 00:13:01,982 1047 | 因此如罗哲斯指出的 1048 | 密钥服务器的首要职责是加密 1049 | 1050 | 1051 | 190 1052 | 00:13:02,149 --> 00:13:05,018 1053 | 以及对SPC密钥请求的验证 1054 | 1055 | 1056 | 191 1057 | 00:13:05,619 --> 00:13:10,457 1058 | 然后它将根据资源识别符 1059 | 查找客户希望播放的内容 1060 | 1061 | 1062 | 192 1063 | 00:13:10,824 --> 00:13:13,193 1064 | 然后它将生成CKC响应 1065 | 1066 | 1067 | 193 1068 | 00:13:13,260 --> 00:13:15,262 1069 | 它是您的密钥安全模块中 1070 | 1071 | 1072 | 194 1073 | 00:13:15,329 --> 00:13:17,197 1074 | 将发生的第一个和第三个操作 1075 | 1076 | 1077 | 195 1078 | 00:13:18,165 --> 00:13:21,335 1079 | 您有两种执行该操作的方式 1080 | 1081 | 1082 | 196 1083 | 00:13:21,401 --> 00:13:23,837 1084 | 您可以使用FPS SDK中 1085 | 提供的协议规范 1086 | 1087 | 1088 | 197 1089 | 00:13:23,904 --> 00:13:27,841 1090 | 从零开始执行这个逻辑系统 1091 | 1092 | 1093 | 198 1094 | 00:13:28,542 --> 00:13:33,447 1095 | 或者您也可以直接采用C参考实施 1096 | 1097 | 1098 | 199 1099 | 00:13:33,514 --> 00:13:36,950 1100 | 并通过您自己选择的语言 1101 | 1102 | 1103 | 200 1104 | 00:13:37,017 --> 00:13:40,654 1105 | 或直接将其集成到现有密钥服务器中 1106 | 而对其进行定制化处理 1107 | 1108 | 1109 | 201 1110 | 00:13:42,356 --> 00:13:45,726 1111 | 那么在执行完集成之后 1112 | 让我们谈一谈您将如何测试KSM 1113 | 1114 | 1115 | 202 1116 | 00:13:46,894 --> 00:13:48,695 1117 | 我们建议您做的第一件事当然是 1118 | 1119 | 1120 | 203 1121 | 00:13:48,762 --> 00:13:51,498 1122 | 使用我们提供 1123 | 作为SDK一部分的测试矢量 1124 | 1125 | 1126 | 204 1127 | 00:13:51,965 --> 00:13:55,202 1128 | 来验证KSM将生成的响应的正确性 1129 | 1130 | 1131 | 205 1132 | 00:13:55,269 --> 00:14:01,074 1133 | 而您执行此步骤的方式 1134 | 是使用我们提供的SPC测试矢量 1135 | 1136 | 1137 | 206 1138 | 00:14:01,508 --> 00:14:04,144 1139 | 将它们提供给KSM执行 1140 | 1141 | 1142 | 207 1143 | 00:14:04,545 --> 00:14:08,048 1144 | 然后运行由KSM通过验证工具 1145 | 产生并输出的CKC 1146 | 1147 | 1148 | 208 1149 | 00:14:08,415 --> 00:14:14,488 1150 | 以确保它们不管从加密的角度 1151 | 或格式的角度都是正确的 1152 | 1153 | 1154 | 209 1155 | 00:14:15,522 --> 00:14:16,390 1156 | 需要注意的是 1157 | 1158 | 1159 | 210 1160 | 00:14:16,456 --> 00:14:20,694 1161 | 我们在SDK中提供的测试矢量 1162 | 是基于开发专用凭证的 1163 | 1164 | 1165 | 211 1166 | 00:14:20,761 --> 00:14:24,264 1167 | 它们是专为您的开发工作而存在的 1168 | 1169 | 1170 | 212 1171 | 00:14:24,331 --> 00:14:28,569 1172 | 它们不可被用于向活跃的客户设备 1173 | 部署解决方案 1174 | 1175 | 1176 | 213 1177 | 00:14:28,635 --> 00:14:32,639 1178 | 为了向活跃的客户设备部署解决方案 1179 | 您将需要专用于生产目的的FPS凭证 1180 | 1181 | 1182 | 214 1183 | 00:14:33,373 --> 00:14:36,577 1184 | 那么既然我们已经谈了服务器端 1185 | 让我们谈谈客户端 1186 | 1187 | 1188 | 215 1189 | 00:14:36,643 --> 00:14:39,346 1190 | 将FPS集成到您的应用中 1191 | 需要些什么呢？ 1192 | 1193 | 1194 | 216 1195 | 00:14:39,413 --> 00:14:40,347 1196 | 您应做的第一件事是 1197 | 1198 | 1199 | 217 1200 | 00:14:40,414 --> 00:14:44,518 1201 | 用AVAsset注册一个 1202 | AVasset Resource Loader delegate 1203 | 1204 | 1205 | 218 1206 | 00:14:44,685 --> 00:14:48,388 1207 | 而那个delegate的职责 1208 | 有三个方面 1209 | 1210 | 1211 | 219 1212 | 00:14:48,455 --> 00:14:50,991 1213 | 首先它要做的是生成SPC 1214 | 1215 | 1216 | 220 1217 | 00:14:51,291 --> 00:14:53,660 1218 | 这需要通过以下两步完成 1219 | 1220 | 1221 | 221 1222 | 00:14:53,727 --> 00:14:54,828 1223 | 首先您将为密钥请求处理 1224 | 1225 | 1226 | 222 1227 | 00:14:55,162 --> 00:14:56,330 1228 | “should Wait For 1229 | Loading 1230 | 1231 | 1232 | 223 1233 | 00:14:56,396 --> 00:14:59,032 1234 | Of Requested 1235 | Resource”命令 1236 | 1237 | 1238 | 224 1239 | 00:14:59,099 --> 00:15:00,267 1240 | 然后您将做的第二步是调用 1241 | 1242 | 1243 | 225 1244 | 00:15:00,334 --> 00:15:02,836 1245 | “VAsset Resource 1246 | Loading Request 1247 | 1248 | 1249 | 226 1250 | 00:15:02,903 --> 00:15:04,972 1251 | Streaming Content 1252 | Key Request Data 1253 | 1254 | 1255 | 227 1256 | 00:15:05,038 --> 00:15:06,240 1257 | For App” 1258 | 1259 | 1260 | 228 1261 | 00:15:06,306 --> 00:15:07,875 1262 | 以便生成SPC 1263 | 1264 | 1265 | 229 1266 | 00:15:08,842 --> 00:15:11,912 1267 | 一旦您获得了那个 SPC 1268 | 您将把它传送给您的密钥服务器 1269 | 1270 | 1271 | 230 1272 | 00:15:12,379 --> 00:15:14,248 1273 | 而当您的密钥服务器做出响应时 1274 | 1275 | 1276 | 231 1277 | 00:15:14,314 --> 00:15:15,582 1278 | 您将把CKC响应提供给 1279 | 1280 | 1281 | 232 1282 | 00:15:15,649 --> 00:15:17,551 1283 | “AVAsset Resource 1284 | Loading Request” 1285 | 1286 | 1287 | 233 1288 | 00:15:18,452 --> 00:15:21,588 1289 | 那么我们就完成了服务器端的执行 1290 | 也完成了客户端的执行 1291 | 1292 | 1293 | 234 1294 | 00:15:21,655 --> 00:15:25,025 1295 | 让我们谈一谈工作流更新中内容制作 1296 | 1297 | 1298 | 235 1299 | 00:15:25,692 --> 00:15:28,128 1300 | 为了将内容解密您将必须做些什么？ 1301 | 1302 | 1303 | 236 1304 | 00:15:28,195 --> 00:15:29,363 1305 | 您应做的第一件事是 1306 | 1307 | 1308 | 237 1309 | 00:15:29,429 --> 00:15:33,367 1310 | 去从developer.apple.com 1311 | 获取HLS加密规范 1312 | 1313 | 1314 | 238 1315 | 00:15:33,700 --> 00:15:35,636 1316 | 不管比特流是音频还是视频 1317 | 1318 | 1319 | 239 1320 | 00:15:35,702 --> 00:15:39,706 1321 | 它将为您提供您需要了解的 1322 | 对比特流本身加密的所有细节 1323 | 1324 | 1325 | 240 1326 | 00:15:41,275 --> 00:15:45,612 1327 | 一旦您对比特流加密后 1328 | 您将必须更新m3u8播放列表 1329 | 1330 | 1331 | 241 1332 | 00:15:45,679 --> 00:15:47,981 1333 | 首先您采用的是何种加密方式 1334 | 1335 | 1336 | 242 1337 | 00:15:48,048 --> 00:15:50,484 1338 | 这是通过 1339 | 将m3u8列表中的Method标签 1340 | 1341 | 1342 | 243 1343 | 00:15:50,951 --> 00:15:53,420 1344 | 设为Sample-AES而实现的 1345 | 1346 | 1347 | 244 1348 | 00:15:54,655 --> 00:15:57,491 1349 | 您应向客户端发送的另一个信号是 1350 | 1351 | 1352 | 245 1353 | 00:15:57,558 --> 00:15:59,993 1354 | 您希望用FPS来传递密钥的事实 1355 | 1356 | 1357 | 246 1358 | 00:16:00,060 --> 00:16:05,465 1359 | 实现的方式则是对m3u8播放列表中 1360 | 的另一个标签即密钥格式标签进行更新 1361 | 1362 | 1363 | 247 1364 | 00:16:05,532 --> 00:16:07,835 1365 | 应把它设为 1366 | com.apple.streamingkeydelivery 1367 | 1368 | 1369 | 248 1370 | 00:16:10,270 --> 00:16:12,539 1371 | 事实上我们三年多前就开始部署了 1372 | 1373 | 1374 | 249 1375 | 00:16:12,606 --> 00:16:16,844 1376 | 这意味着目前在解码器方面 1377 | 有相当多的第三方支持 1378 | 1379 | 1380 | 250 1381 | 00:16:16,910 --> 00:16:22,349 1382 | 您可以选择搭配其中之一作为替代 1383 | 而不是您亲自更新工作流 1384 | 1385 | 1386 | 251 1387 | 00:16:23,417 --> 00:16:25,085 1388 | 一旦您更新了您的工作流 1389 | 1390 | 1391 | 252 1392 | 00:16:25,319 --> 00:16:29,389 1393 | 这里是您如何检查 1394 | 加密工作流的正确性的方法 1395 | 1396 | 1397 | 253 1398 | 00:16:30,490 --> 00:16:33,894 1399 | 您大体上可以做两个比较 1400 | 1401 | 1402 | 254 1403 | 00:16:35,062 --> 00:16:36,563 1404 | 但它们都是以同样的方式开始的 1405 | 1406 | 1407 | 255 1408 | 00:16:36,630 --> 00:16:39,633 1409 | 开始时先从 1410 | 示例SDK选取一段明文内容 1411 | 1412 | 1413 | 256 1414 | 00:16:40,000 --> 00:16:43,971 1415 | 并使其运行通过您的新工作流 1416 | 1417 | 1418 | 257 1419 | 00:16:44,771 --> 00:16:50,911 1420 | 然后将其与SDK中相同加密资源对比 1421 | 1422 | 1423 | 258 1424 | 00:16:51,578 --> 00:16:57,351 1425 | 也可将其与在HLS媒体文件切割 1426 | 工具上通过的该资源加密版本进行比较 1427 | 1428 | 1429 | 259 1430 | 00:16:57,651 --> 00:17:00,921 1431 | 之所以第二点比较有意思有吸引力 1432 | 是因为您也可以使用自己的内容 1433 | 1434 | 1435 | 260 1436 | 00:17:00,988 --> 00:17:02,489 1437 | 而不是示例内容完成检查工作 1438 | 1439 | 1440 | 261 1441 | 00:17:03,857 --> 00:17:05,425 1442 | 那么现在我们已经讨论了 1443 | 1444 | 1445 | 262 1446 | 00:17:05,492 --> 00:17:09,630 1447 | 客户端开发和服务器端开发所需的工作 1448 | 以及对您的工作流的更新 1449 | 1450 | 1451 | 263 1452 | 00:17:10,564 --> 00:17:12,566 1453 | 接下来我们讨论功能性本地回放 1454 | 1455 | 1456 | 264 1457 | 00:17:12,633 --> 00:17:15,636 1458 | 现在我想很大家谈谈 1459 | AirPlay中对FPS的支持 1460 | 1461 | 1462 | 265 1463 | 00:17:17,069 --> 00:17:23,443 1464 | 我们对FPS和AirPlay的支持 1465 | 是通过AirPlay视频路径实现的 1466 | 1467 | 1468 | 266 1469 | 00:17:23,810 --> 00:17:29,816 1470 | 就是说当您从应用中的 1471 | 本地回放过渡到Apple TV时 1472 | 1473 | 1474 | 267 1475 | 00:17:30,384 --> 00:17:34,421 1476 | 实际上是Apple TV 1477 | 从互联网上读取内容 是吗？ 1478 | 1479 | 1480 | 268 1481 | 00:17:34,488 --> 00:17:36,757 1482 | 它不再是发送方的设备了 1483 | 1484 | 1485 | 269 1486 | 00:17:37,925 --> 00:17:39,426 1487 | 这里的好消息是 1488 | 1489 | 1490 | 270 1491 | 00:17:39,493 --> 00:17:43,430 1492 | 在您的应用中或服务器端 1493 | 都不需要写任何额外代码了 1494 | 1495 | 1496 | 271 1497 | 00:17:43,564 --> 00:17:48,702 1498 | KSM支持来自于Apple TV 1499 | 1500 | 1501 | 272 1502 | 00:17:49,069 --> 00:17:53,173 1503 | 或来自于iOS设备传入的密钥请求 1504 | 1505 | 1506 | 273 1507 | 00:17:55,042 --> 00:17:58,612 1508 | 需要明确的是 1509 | SPC仍是Apple TV上生成的 1510 | 1511 | 1512 | 274 1513 | 00:17:59,146 --> 00:18:03,884 1514 | 而您的密钥服务器上生成的CKC响应 1515 | 也将在AppleTV上进行处理 1516 | 1517 | 1518 | 275 1519 | 00:18:05,152 --> 00:18:10,657 1520 | 然而app仍然负责Apple TV 1521 | 和密钥服务器之间的消息 1522 | 1523 | 1524 | 276 1525 | 00:18:10,724 --> 00:18:12,659 1526 | 因此必须有发送设备的参与 1527 | 1528 | 1529 | 277 1530 | 00:18:14,261 --> 00:18:17,364 1531 | 这给了我们与本地回放同水平的安全性 1532 | 1533 | 1534 | 278 1535 | 00:18:17,431 --> 00:18:21,502 1536 | 因为SPC和CKC消息 1537 | 都来自于并终止于 1538 | 1539 | 1540 | 279 1541 | 00:18:21,668 --> 00:18:23,904 1542 | 实际播放内容的那个设备 1543 | 1544 | 1545 | 280 1546 | 00:18:24,004 --> 00:18:26,406 1547 | 在这种情况下是Apple TV 1548 | 也即AirPlay 1549 | 1550 | 1551 | 281 1552 | 00:18:27,975 --> 00:18:29,743 1553 | 需要注意的一点是 1554 | 1555 | 1556 | 282 1557 | 00:18:29,810 --> 00:18:33,847 1558 | 实际上FPS内容将不会 1559 | 以AirPlay镜像模式执行 1560 | 1561 | 1562 | 283 1563 | 00:18:34,281 --> 00:18:36,984 1564 | 那也适用于在您的本地设备上 1565 | 1566 | 1567 | 284 1568 | 00:18:37,317 --> 00:18:39,987 1569 | 播放的FPS内容所做的 1570 | 屏幕截图和音视频录制 1571 | 1572 | 1573 | 285 1574 | 00:18:41,355 --> 00:18:44,157 1575 | 在我们谈了关于如何 1576 | 在您的app上或AirPlay上 1577 | 1578 | 1579 | 286 1580 | 00:18:44,858 --> 00:18:47,661 1581 | 在本地消费内容之后 1582 | 1583 | 1584 | 287 1585 | 00:18:48,128 --> 00:18:50,264 1586 | 我骄傲地宣布： 1587 | 1588 | 1589 | 288 1590 | 00:18:50,330 --> 00:18:53,066 1591 | 今年我们将增加 1592 | 对El Capitan的FPS支持 1593 | 1594 | 1595 | 289 1596 | 00:18:54,668 --> 00:18:59,873 1597 | 这种大家支持 1598 | 且集成到网站的方式 1599 | 1600 | 1601 | 290 1602 | 00:19:00,240 --> 00:19:04,444 1603 | 是通过加密的媒体扩展 1604 | 1605 | 1606 | 291 1607 | 00:19:04,912 --> 00:19:07,080 1608 | 它们是HTML5的一部分 1609 | 是一个W3C规范 1610 | 1611 | 1612 | 292 1613 | 00:19:07,147 --> 00:19:08,715 1614 | 您可以从它们的网站下载它 1615 | 1616 | 1617 | 293 1618 | 00:19:09,383 --> 00:19:13,187 1619 | 您与EME集成的方式是 1620 | 1621 | 1622 | 294 1623 | 00:19:13,253 --> 00:19:16,623 1624 | 将您的JavaScript格式 1625 | 密钥传递代码写到您的网站上 1626 | 1627 | 1628 | 295 1629 | 00:19:17,124 --> 00:19:21,161 1630 | 我们在SDK中 1631 | 提供了一个这种实施的例子 1632 | 1633 | 1634 | 296 1635 | 00:19:21,261 --> 00:19:22,663 1636 | 它更多地是一个小片段 1637 | 1638 | 1639 | 297 1640 | 00:19:24,097 --> 00:19:30,437 1641 | 这里的好消息是 1642 | 不管是在KSM端或AirPlay端 1643 | 1644 | 1645 | 298 1646 | 00:19:30,504 --> 00:19:32,673 1647 | 都不需要任何新的代码 1648 | 1649 | 1650 | 299 1651 | 00:19:33,106 --> 00:19:34,474 1652 | 它是开箱即用型的 1653 | 1654 | 1655 | 300 1656 | 00:19:34,908 --> 00:19:38,145 1657 | 且写好了JavaScript代码后 1658 | 它将对一切都是完全支持的 1659 | 1660 | 1661 | 301 1662 | 00:19:38,212 --> 00:19:39,179 1663 | 现在让我们谈一下 1664 | 1665 | 1666 | 302 1667 | 00:19:39,246 --> 00:19:43,450 1668 | 您为了在网页上支持FPS 1669 | 而将要写的JavaScript代码 1670 | 1671 | 1672 | 303 1673 | 00:19:43,650 --> 00:19:46,753 1674 | 您要做的第一件事是 1675 | 将m3u8 URL设为 1676 | 1677 | 1678 | 304 1679 | 00:19:47,054 --> 00:19:51,091 1680 | HTML5视频标签的来源属性 1681 | 1682 | 1683 | 305 1684 | 00:19:51,825 --> 00:19:53,427 1685 | 正像您为一个非加密内容所做的那样 1686 | 1687 | 1688 | 306 1689 | 00:19:54,394 --> 00:20:00,634 1690 | 然后为WebKitNeedKey调用 1691 | 添加视频元素Event Listener 1692 | 1693 | 1694 | 307 1695 | 00:20:01,535 --> 00:20:02,402 1696 | 当被触发的时候 1697 | 1698 | 1699 | 308 1700 | 00:20:02,569 --> 00:20:07,641 1701 | 那个Event Listener 1702 | 将把EME内容加密模块设置到FPS 1703 | 1704 | 1705 | 309 1706 | 00:20:08,509 --> 00:20:11,378 1707 | 它还将在video/MP4上 1708 | 创建一个keySession 1709 | 1710 | 1711 | 310 1712 | 00:20:11,445 --> 00:20:14,381 1713 | 以便在密钥系统 1714 | 和您的密钥服务器之间传递消息 1715 | 1716 | 1717 | 311 1718 | 00:20:15,115 --> 00:20:16,717 1719 | 您将 1720 | web kit key message 1721 | 1722 | 1723 | 312 1724 | 00:20:16,783 --> 00:20:19,286 1725 | 向那个keySession 1726 | 添加Event Handler 1727 | 1728 | 1729 | 313 1730 | 00:20:19,786 --> 00:20:25,058 1731 | 那个Event Handler负责 1732 | 把SPC密钥请求传送到您的服务器上 1733 | 1734 | 1735 | 314 1736 | 00:20:25,425 --> 00:20:30,030 1737 | 然后通过更新密钥会话 1738 | 处理CKC响应 1739 | 1740 | 1741 | 315 1742 | 00:20:31,131 --> 00:20:34,701 1743 | 在数据流方面 1744 | 我们在左侧有非常类似的活动要素 1745 | 1746 | 1747 | 316 1748 | 00:20:34,768 --> 00:20:36,703 1749 | 我们在右侧有同样的活动要素 1750 | 1751 | 1752 | 317 1753 | 00:20:36,770 --> 00:20:41,241 1754 | 我们现在有Apple提供的 1755 | Safari以及EME堆栈 1756 | 1757 | 1758 | 318 1759 | 00:20:41,708 --> 00:20:43,377 1760 | 在Safari内我们有您的网站 1761 | 1762 | 1763 | 319 1764 | 00:20:43,911 --> 00:20:50,684 1765 | 及您将在网站上支持FPS内容播放和 1766 | 新写的JavaScript代码片段 1767 | 1768 | 1769 | 320 1770 | 00:20:52,786 --> 00:20:56,123 1771 | 让我们讨论下当用户在Safari中 1772 | 点击Play会发生什么 1773 | 1774 | 1775 | 321 1776 | 00:20:56,256 --> 00:20:59,493 1777 | 那么当用户点击play时 1778 | 将要发生的第一件事是 1779 | 1780 | 1781 | 322 1782 | 00:20:59,927 --> 00:21:03,530 1783 | m3u8将在操作系统中 1784 | 点击EME和AVFoundation 1785 | 1786 | 1787 | 323 1788 | 00:21:03,597 --> 00:21:07,401 1789 | 而EME将会注意到内容已被加密 1790 | 1791 | 1792 | 324 1793 | 00:21:07,467 --> 00:21:12,706 1794 | 这将使它触发 1795 | Web kit need key message 1796 | 1797 | 1798 | 325 1799 | 00:21:12,773 --> 00:21:14,374 1800 | 您的事件监听器将收到这条消息 1801 | 1802 | 1803 | 326 1804 | 00:21:16,410 --> 00:21:18,478 1805 | 然后您的事件监听器将创建密钥会话 1806 | 1807 | 1808 | 327 1809 | 00:21:18,545 --> 00:21:21,081 1810 | 并将等待Web kit key message 1811 | 1812 | 1813 | 328 1814 | 00:21:21,181 --> 00:21:23,183 1815 | 后者又将触发 1816 | Event Handler 1817 | 1818 | 1819 | 329 1820 | 00:21:23,817 --> 00:21:26,286 1821 | 而Event Handler 1822 | 将接收到SPC 1823 | 1824 | 1825 | 330 1826 | 00:21:26,620 --> 00:21:30,123 1827 | 并将其传给您的密钥服务器 1828 | 密钥服务器将对其照常处理 1829 | 1830 | 1831 | 331 1832 | 00:21:30,190 --> 00:21:32,693 1833 | 包括提取内容密钥和创建内容密钥响应 1834 | 1835 | 1836 | 332 1837 | 00:21:33,026 --> 00:21:36,396 1838 | 然后将那个CKC传回 1839 | 给JavaScript代码 1840 | 1841 | 1842 | 333 1843 | 00:21:36,463 --> 00:21:39,900 1844 | 后者再将CKC 1845 | 向下传递返回给EME层以便播放 1846 | 1847 | 1848 | 334 1849 | 00:21:42,202 --> 00:21:43,504 1850 | 正如罗哲斯刚才所说 1851 | 1852 | 1853 | 335 1854 | 00:21:43,570 --> 00:21:48,442 1855 | 我们从最初部署该解决方案 1856 | 到现在已超过三年 1857 | 1858 | 1859 | 336 1860 | 00:21:48,909 --> 00:21:55,716 1861 | 这几年间我们学会了一些 1862 | 如何解决FPS集成问题的秘诀和窍门 1863 | 1864 | 1865 | 337 1866 | 00:21:56,250 --> 00:21:58,886 1867 | 而您可能面对的典型问题 1868 | 1869 | 1870 | 338 1871 | 00:21:59,586 --> 00:22:03,657 1872 | 如果您的集成工作不幸出错的话 1873 | 是内容不播放 1874 | 1875 | 1876 | 339 1877 | 00:22:04,358 --> 00:22:08,095 1878 | 那么您要怎样对那种情况进行调试呢？ 1879 | 1880 | 1881 | 340 1882 | 00:22:08,262 --> 00:22:11,231 1883 | 我们建议您做的一件事是... 1884 | 1885 | 1886 | 341 1887 | 00:22:11,298 --> 00:22:14,935 1888 | 而且这仅限于调试目的 1889 | 我们不建议您在生产环境中这么做 1890 | 1891 | 1892 | 342 1893 | 00:22:15,269 --> 00:22:19,206 1894 | 那就是将您在m3u8播放列表中的 1895 | 密钥格式设为identity 1896 | 1897 | 1898 | 343 1899 | 00:22:19,806 --> 00:22:22,442 1900 | 而不是 1901 | com.apple.streamingkeydelivery 1902 | 1903 | 1904 | 344 1905 | 00:22:22,509 --> 00:22:23,877 1906 | 这有什么作用呢？ 1907 | 1908 | 1909 | 345 1910 | 00:22:23,944 --> 00:22:26,713 1911 | 它将同样的内容传送到客户端 1912 | 1913 | 1914 | 346 1915 | 00:22:27,214 --> 00:22:31,718 1916 | 但并不是用FPS将内容解密 1917 | 而是用明文AES密钥解密 1918 | 1919 | 1920 | 347 1921 | 00:22:32,586 --> 00:22:35,956 1922 | 而我们最终会是两种情况之一 1923 | 1924 | 1925 | 348 1926 | 00:22:36,023 --> 00:22:37,457 1927 | 第一种是您的内容仍不播放 1928 | 1929 | 1930 | 349 1931 | 00:22:37,758 --> 00:22:42,196 1932 | 这种情况下很有可能是内容制作问题 1933 | 1934 | 1935 | 350 1936 | 00:22:42,529 --> 00:22:45,165 1937 | 而那些问题通常分为四类 1938 | 1939 | 1940 | 351 1941 | 00:22:45,566 --> 00:22:48,969 1942 | 或者是您的加密样本存在问题 1943 | 1944 | 1945 | 352 1946 | 00:22:49,036 --> 00:22:53,240 1947 | 如果是那种情况 1948 | 我建议您参考HLS示例加密规范 1949 | 1950 | 1951 | 353 1952 | 00:22:53,540 --> 00:22:55,876 1953 | 它可能是PAT/PMT音频设置问题 1954 | 1955 | 1956 | 354 1957 | 00:22:56,410 --> 00:23:02,182 1958 | 那些是您需要对采用FPS编码 1959 | 和加密的音频流采取的步骤 1960 | 1961 | 1962 | 355 1963 | 00:23:02,249 --> 00:23:04,718 1964 | 需要对一些元数据进行更新 1965 | 1966 | 1967 | 356 1968 | 00:23:05,786 --> 00:23:08,188 1969 | 可能是这样的情况 1970 | 您使用的编解码器不被支持 1971 | 1972 | 1973 | 357 1974 | 00:23:08,388 --> 00:23:09,690 1975 | 而且如罗哲斯稍早提到的 1976 | 1977 | 1978 | 358 1979 | 00:23:09,756 --> 00:23:14,962 1980 | 目前我们在FPS中支持的是 1981 | H.264 AAC 以及加密的AC3 1982 | 1983 | 1984 | 359 1985 | 00:23:15,729 --> 00:23:21,869 1986 | 最后 有可能您将在非HLS片段上 1987 | 重置您的内容密钥 1988 | 1989 | 1990 | 360 1991 | 00:23:22,302 --> 00:23:27,474 1992 | 那么我们建议您将密钥 1993 | 在最细粒度的HLS片段上重置 1994 | 1995 | 1996 | 361 1997 | 00:23:27,841 --> 00:23:32,379 1998 | 或者您也可以转换比特率时 1999 | 更改内容密钥值 2000 | 2001 | 2002 | 362 2003 | 00:23:33,914 --> 00:23:37,985 2004 | 如果在您将密钥格式标签 2005 | 更新为identity之后 2006 | 2007 | 2008 | 363 2009 | 00:23:38,051 --> 00:23:40,187 2010 | 您的内容已经可以播放 2011 | 但可能面临密钥传递问题 2012 | 2013 | 2014 | 364 2015 | 00:23:40,721 --> 00:23:45,292 2016 | 如果那样的话 2017 | 您要做的就是跟踪我们刚才所考查的 2018 | 2019 | 2020 | 365 2021 | 00:23:45,893 --> 00:23:50,464 2022 | 图表中的数据流 2023 | 并确保SPC由客户端正确生成 2024 | 2025 | 2026 | 366 2027 | 00:23:50,531 --> 00:23:55,235 2028 | 它被传送到服务器 2029 | 您的服务器能正确无误处理该密钥请求 2030 | 2031 | 2032 | 367 2033 | 00:23:55,502 --> 00:23:57,771 2034 | 您的服务器在数据库中查找正确的密钥 2035 | 2036 | 2037 | 368 2038 | 00:23:58,172 --> 00:24:02,142 2039 | 而且服务器能够将内容密钥 2040 | 封装为内容密钥响应 2041 | 2042 | 2043 | 369 2044 | 00:24:02,209 --> 00:24:06,880 2045 | 而且客户端能够正确无误地 2046 | 处理那一响应 2047 | 2048 | 2049 | 370 2050 | 00:24:08,015 --> 00:24:12,152 2051 | 既然我们已经考查了 2052 | 在Apple生态系统内 2053 | 2054 | 2055 | 371 2056 | 00:24:12,219 --> 00:24:15,055 2057 | 消费FPS内容的各种方式 2058 | 2059 | 2060 | 372 2061 | 00:24:15,122 --> 00:24:17,524 2062 | 我想把舞台还给罗哲斯 2063 | 让他为这节讲座做一个总结 2064 | 2065 | 2066 | 373 2067 | 00:24:17,624 --> 00:24:18,926 2068 | 非常感谢大家为此付出的时间 2069 | 2070 | 2071 | 374 2072 | 00:24:25,966 --> 00:24:27,067 2073 | 非常感谢谢詹保罗 法索里 2074 | 2075 | 2076 | 375 2077 | 00:24:27,501 --> 00:24:29,236 2078 | 那么让我们在这里快速地总结一下 2079 | 2080 | 2081 | 376 2082 | 00:24:30,137 --> 00:24:33,874 2083 | 面向HLS的FPS 2084 | 2085 | 2086 | 377 2087 | 00:24:34,107 --> 00:24:40,848 2088 | 为您提供业内颇具优势的 2089 | HLS内容保护工具 2090 | 2091 | 2092 | 378 2093 | 00:24:42,082 --> 00:24:48,355 2094 | 您在iOS上 Apple TV上 2095 | 以及在OS X上都能使用它 2096 | 2097 | 2098 | 379 2099 | 00:24:48,689 --> 00:24:53,627 2100 | 自从iOS 6就开始提供了 2101 | 因此已有相当程度的兼容性 2102 | 2103 | 2104 | 380 2105 | 00:24:54,061 --> 00:24:56,797 2106 | 在Apple TV上也是如此 2107 | 2108 | 2109 | 381 2110 | 00:24:57,231 --> 00:24:58,866 2111 | OS X仍较新 2112 | 2113 | 2114 | 382 2115 | 00:24:58,932 --> 00:25:00,868 2116 | 您可以在之后的实验室活动中 2117 | 跟我们聊聊 2118 | 2119 | 2120 | 383 2121 | 00:25:00,934 --> 00:25:03,804 2122 | 我们将向您和盘托出 2123 | 您可以把它用在什么地方 2124 | 2125 | 2126 | 384 2127 | 00:25:05,239 --> 00:25:07,341 2128 | 它已被深度集成到OS内部 2129 | 2130 | 2131 | 385 2132 | 00:25:07,441 --> 00:25:10,677 2133 | 意味着它能够向下兼容到极低的版本 2134 | 2135 | 2136 | 386 2137 | 00:25:10,744 --> 00:25:12,246 2138 | 而且我们也尽可能确保其安全性 2139 | 2140 | 2141 | 387 2142 | 00:25:12,446 --> 00:25:14,882 2143 | 它的电源效率也达到了 2144 | 我们能够达到的极致 2145 | 2146 | 2147 | 388 2148 | 00:25:15,215 --> 00:25:18,085 2149 | 而且它有极佳的电池寿命 2150 | 以及高度的安全性 2151 | 2152 | 2153 | 389 2154 | 00:25:19,052 --> 00:25:22,990 2155 | 而且它支持我们所有生态系统特性 2156 | 2157 | 2158 | 390 2159 | 00:25:23,357 --> 00:25:28,061 2160 | 比如AirPlay 2161 | HDCP HTML5 2162 | 2163 | 2164 | 391 2165 | 00:25:28,128 --> 00:25:32,566 2166 | 而且随着不断推出新特性 2167 | 我们将持续改进它 2168 | 2169 | 2170 | 392 2171 | 00:25:36,069 --> 00:25:37,204 2172 | 那么下一步是什么呢？ 2173 | 2174 | 2175 | 393 2176 | 00:25:38,338 --> 00:25:39,773 2177 | 第一站是在 2178 | 2179 | 2180 | 394 2181 | 00:25:40,174 --> 00:25:43,977 2182 | developer.apple.com 2183 | 上最新的FPS门户 2184 | 2185 | 2186 | 395 2187 | 00:25:44,044 --> 00:25:48,415 2188 | 它现在就在运转中 2189 | 所以您可以去那里看看 2190 | 2191 | 2192 | 396 2193 | 00:25:48,482 --> 00:25:53,921 2194 | 而且您还可以从门户下载SDK 2195 | 您可以查看概述文件 2196 | 2197 | 2198 | 397 2199 | 00:25:53,987 --> 00:25:58,759 2200 | 它会让您对FPS的细节 2201 | 有一点更深入的见解 2202 | 2203 | 2204 | 398 2205 | 00:25:59,259 --> 00:26:04,631 2206 | 而且通过那个站点 2207 | 您也可以申请生产目的的开发者证书 2208 | 2209 | 2210 | 399 2211 | 00:26:04,698 --> 00:26:08,769 2212 | 它们对实现iOS设备或Safari 2213 | 2214 | 2215 | 400 2216 | 00:26:09,036 --> 00:26:12,539 2217 | 上的来回播放是必要的 2218 | 2219 | 2220 | 401 2221 | 00:26:15,742 --> 00:26:22,149 2222 | 我应该提到的下一件事情 2223 | 在那个站点 在登录页上 2224 | 2225 | 2226 | 402 2227 | 00:26:22,516 --> 00:26:27,788 2228 | 你们中间的某些人 2229 | 可能并没有一个现成的后端 2230 | 2231 | 2232 | 403 2233 | 00:26:28,155 --> 00:26:34,261 2234 | 或者一想到将FPS集成到后端 2235 | 就被这个想法吓到了 2236 | 2237 | 2238 | 404 2239 | 00:26:34,661 --> 00:26:38,565 2240 | 那么在那个登录页面上 2241 | 我们有一个小小的清单 2242 | 2243 | 2244 | 405 2245 | 00:26:38,866 --> 00:26:44,004 2246 | 列出了我们的集成合作伙伴 2247 | 像Irdeto 像Adobe 2248 | 2249 | 2250 | 406 2251 | 00:26:44,571 --> 00:26:49,109 2252 | 它们已经为希望使用FPS 2253 | 2254 | 2255 | 407 2256 | 00:26:49,176 --> 00:26:54,081 2257 | 保护HLS内容的朋友 2258 | 建立了一些支持 2259 | 2260 | 2261 | 408 2262 | 00:26:55,282 --> 00:26:58,051 2263 | 我建议您也查看一下那些合作伙伴 2264 | 2265 | 2266 | 409 2267 | 00:26:58,118 --> 00:27:02,789 2268 | 如果您觉得在FPS设置 2269 | 及如何使其为您工作方面 2270 | 2271 | 2272 | 410 2273 | 00:27:03,290 --> 00:27:04,124 2274 | 一点帮助的话 2275 | 2276 | 2277 | 411 2278 | 00:27:04,525 --> 00:27:06,426 2279 | 我觉得这是很容易做的 2280 | 2281 | 2282 | 412 2283 | 00:27:06,493 --> 00:27:09,029 2284 | 但并不是每个人都是业内人士 2285 | 2286 | 2287 | 413 2288 | 00:27:09,463 --> 00:27:11,265 2289 | 因此如果您需要的话 2290 | 我们会为您提供帮助 2291 | 2292 | 2293 | 414 2294 | 00:27:12,099 --> 00:27:18,272 2295 | 此外 2296 | 如果您想让HLS和FPS开始工作 2297 | 2298 | 2299 | 415 2300 | 00:27:18,605 --> 00:27:23,410 2301 | 但是感觉仍然存在问题 2302 | 或者您已经尝试过且遇到了一些问题 2303 | 2304 | 2305 | 416 2306 | 00:27:23,777 --> 00:27:25,679 2307 | 如果您不是在WWDC上 2308 | 2309 | 2310 | 417 2311 | 00:27:25,979 --> 00:27:29,950 2312 | 那么对您来说最佳的第一站 2313 | 就是我们的开发者论坛 2314 | 2315 | 2316 | 418 2317 | 00:27:30,117 --> 00:27:33,453 2318 | 而且我们实际上 2319 | 已经建立了目前处于测试阶段 2320 | 2321 | 2322 | 419 2323 | 00:27:33,754 --> 00:27:37,824 2324 | 但是我们已建立了一个新的论坛 2325 | 它是专门面向FPS的 2326 | 2327 | 2328 | 420 2329 | 00:27:38,225 --> 00:27:41,228 2330 | 因此请查看一下这个论坛 2331 | 2332 | 2333 | 421 2334 | 00:27:41,361 --> 00:27:44,131 2335 | 如果您遇到了困难 2336 | 或者是有什么问题 2337 | 2338 | 2339 | 422 2340 | 00:27:44,398 --> 00:27:48,836 2341 | 很可能其他人也有 2342 | 同样的问题 同样的困难 2343 | 2344 | 2345 | 423 2346 | 00:27:49,102 --> 00:27:51,438 2347 | 而你可能通过查看论坛 2348 | 就能找到答案 2349 | 2350 | 2351 | 424 2352 | 00:27:52,840 --> 00:27:54,374 2353 | 如果那样做失败的话 2354 | 2355 | 2356 | 425 2357 | 00:27:54,441 --> 00:27:57,411 2358 | 还有您的非常友好的社区 2359 | 以及开发者技术支持代表 2360 | 2361 | 2362 | 426 2363 | 00:27:57,477 --> 00:27:59,780 2364 | 将乐于为您提供帮助且收费低廉 2365 | 2366 | 2367 | 427 2368 | 00:28:01,615 --> 00:28:02,616 2369 | 我想就是这样了 2370 | 2371 | 2372 | 428 2373 | 00:28:03,884 --> 00:28:05,052 2374 | 再次感谢您的光临！ 2375 | 2376 | 2377 | 429 2378 | 00:28:05,352 --> 00:28:06,820 2379 | 希望您在大会期间开心！ 2380 | 2381 | -------------------------------------------------------------------------------- /SD/503_sd_monetize_and_promote_your_app_with_iad.srt: -------------------------------------------------------------------------------- 1 | 1 2 | 00:00:19,219 --> 00:00:24,691 3 | 如何在iAd中推广你的App并营利 4 | 从设计到发布 5 | 6 | 7 | 2 8 | 00:00:25,025 --> 00:00:26,760 9 | 大家好！ 10 | 欢迎大家！ 11 | 12 | 13 | 3 14 | 00:00:28,195 --> 00:00:34,968 15 | 你们开发者中有很多人 16 | 把时间精力血汗以及泪水 17 | 18 | 19 | 4 20 | 00:00:35,235 --> 00:00:40,607 21 | 投入到构建一些最令人惊叹的 22 | 引人入胜的以及美妙的app中 23 | 24 | 25 | 5 26 | 00:00:41,975 --> 00:00:44,344 27 | 然而最成功的开发者 28 | 29 | 30 | 6 31 | 00:00:45,312 --> 00:00:47,814 32 | 并不只是关注打造优秀的app 33 | 34 | 35 | 7 36 | 00:00:48,749 --> 00:00:50,984 37 | 他们也认识到了围绕他们的app 38 | 39 | 40 | 8 41 | 00:00:51,451 --> 00:00:54,688 42 | 建立良好的业务的重要性 43 | 44 | 45 | 9 46 | 00:00:56,023 --> 00:00:58,225 47 | 而那正是我们今天在这里 48 | 跟您要讨论的话题 49 | 50 | 51 | 10 52 | 00:00:59,560 --> 00:01:00,961 53 | 我叫卡洛·鄧/邓 54 | 55 | 56 | 11 57 | 00:01:01,328 --> 00:01:04,298 58 | 我的同事莎尚克·珐德克 59 | 将和我一起完成讲座 60 | 61 | 62 | 12 63 | 00:01:04,397 --> 00:01:06,233 64 | 我们都来自于iAd团队 65 | 66 | 67 | 13 68 | 00:01:08,368 --> 00:01:10,304 69 | 今天我们在这里将向您介绍iAd 70 | 71 | 72 | 14 73 | 00:01:10,838 --> 00:01:13,106 74 | Apple的数字广告平台 75 | 76 | 77 | 15 78 | 00:01:14,341 --> 00:01:18,212 79 | 不管您是大型开发机构 80 | 或是小型独立开发者 81 | 82 | 83 | 16 84 | 00:01:18,812 --> 00:01:23,550 85 | iAd都为您提供广泛的解决方案 86 | 帮助您扩大业务 87 | 88 | 89 | 17 90 | 00:01:25,452 --> 00:01:28,655 91 | 而所有业务面临的一些共同挑战 92 | 93 | 94 | 18 95 | 00:01:29,289 --> 00:01:33,894 96 | 如何创造收入以及如何吸引和留住客户 97 | 98 | 99 | 19 100 | 00:01:34,995 --> 00:01:36,964 101 | iAd有针对这两个问题的解决方案 102 | 103 | 104 | 20 105 | 00:01:38,365 --> 00:01:39,800 106 | 为了帮助创造收入 107 | 108 | 109 | 21 110 | 00:01:40,868 --> 00:01:43,170 111 | 将iAd集成到您的app中 112 | 是简单易行的 113 | 114 | 115 | 22 116 | 00:01:44,171 --> 00:01:46,206 117 | 而且以极少的代码就能够实现 118 | 119 | 120 | 23 121 | 00:01:47,007 --> 00:01:49,376 122 | 稍后在讲座中我们会为您展示 123 | 124 | 125 | 24 126 | 00:01:52,045 --> 00:01:54,147 127 | 一方面 对于app开发者来说 128 | 129 | 130 | 25 131 | 00:01:54,414 --> 00:01:57,017 132 | 获取客户可能尤其是 133 | 一件让人望而生畏的事情 134 | 135 | 136 | 26 137 | 00:01:58,085 --> 00:01:59,353 138 | 昨天您也听说了 139 | 140 | 141 | 27 142 | 00:01:59,753 --> 00:02:03,223 143 | 在App Store 144 | 有超过150万个app 145 | 146 | 147 | 28 148 | 00:02:03,757 --> 00:02:07,361 149 | 而平均每件用户设备上 150 | 就有119个app 151 | 152 | 153 | 29 154 | 00:02:08,195 --> 00:02:11,765 155 | 有大量的争夺用户注意力的竞争 156 | 157 | 158 | 30 159 | 00:02:12,299 --> 00:02:15,269 160 | 那么您怎样让您的app被注意到？ 161 | 162 | 163 | 31 164 | 00:02:17,671 --> 00:02:20,274 165 | 对此问题 166 | iAd的解决方案可以帮您 167 | 168 | 169 | 32 170 | 00:02:20,340 --> 00:02:23,577 171 | 在iOS生态系统中高效地推广app 172 | 173 | 174 | 33 175 | 00:02:23,977 --> 00:02:27,514 176 | 以便为您的app创造知名度 177 | 并获取客户 178 | 179 | 180 | 34 181 | 00:02:30,450 --> 00:02:33,921 182 | 为您的app进行推广 183 | 涉及到三个主要概念 184 | 185 | 186 | 35 187 | 00:02:34,922 --> 00:02:38,192 188 | 首先 确认并划分您的用户 189 | 190 | 191 | 36 192 | 00:02:38,692 --> 00:02:42,362 193 | 以便了解您试图影响的不同受众 194 | 195 | 196 | 37 197 | 00:02:43,897 --> 00:02:45,199 198 | 在您的app推广活动中 199 | 200 | 201 | 38 202 | 00:02:45,399 --> 00:02:49,603 203 | 用具有相关性和针对性的消息 204 | 与那些用户建立联系 205 | 206 | 207 | 39 208 | 00:02:50,737 --> 00:02:57,211 209 | 然后衡量那些活动的有效性 210 | 以便能够持续优化和改善活动效果 211 | 212 | 213 | 40 214 | 00:03:00,447 --> 00:03:03,417 215 | 我们将向您演示 216 | 如何利用工具和最佳实践 217 | 218 | 219 | 41 220 | 00:03:03,717 --> 00:03:05,285 221 | 让您做到这两点： 222 | 223 | 224 | 42 225 | 00:03:05,652 --> 00:03:09,957 226 | 在您app开发的整个生命周期内 227 | 对其进行货币转化和推广 228 | 229 | 230 | 43 231 | 00:03:10,891 --> 00:03:11,892 232 | 让我们开始吧 233 | 234 | 235 | 44 236 | 00:03:15,295 --> 00:03:16,997 237 | 设想我是一个app开发者 238 | 239 | 240 | 45 241 | 00:03:17,998 --> 00:03:19,733 242 | 我在App Store里 243 | 有几个app 244 | 245 | 246 | 46 247 | 00:03:20,234 --> 00:03:24,004 248 | 而且我正打算发布我的下一个 249 | 伟大的app名为LiteRight 250 | 251 | 252 | 47 253 | 00:03:25,339 --> 00:03:27,374 254 | LiteRight 255 | 是一个最新的照相app 256 | 257 | 258 | 48 259 | 00:03:27,441 --> 00:03:31,478 260 | 它有一些极为特殊的滤镜 261 | 在其他任何地方都没有 262 | 263 | 264 | 49 265 | 00:03:32,880 --> 00:03:34,314 266 | 它将是一款免费app 267 | 268 | 269 | 50 270 | 00:03:34,581 --> 00:03:37,618 271 | 让用户能够使用那样的一些滤镜 272 | 273 | 274 | 51 275 | 00:03:37,951 --> 00:03:43,190 276 | 而app内置的购买功能 277 | 让用户能够接触到更棒的滤镜 278 | 279 | 280 | 52 281 | 00:03:46,093 --> 00:03:48,028 282 | 这是我的app开发时间表 283 | 284 | 285 | 53 286 | 00:03:48,161 --> 00:03:50,230 287 | 它看上去跟您的可能类似 288 | 289 | 290 | 54 291 | 00:03:50,731 --> 00:03:54,134 292 | 从设计阶段开始 293 | 然后我将开发app 294 | 295 | 296 | 55 297 | 00:03:54,568 --> 00:03:57,604 298 | 在App Store发布它 299 | 并扩大我的用户基础 300 | 301 | 302 | 56 303 | 00:03:59,873 --> 00:04:02,276 304 | 目前我正处在 305 | LiteRight的设计阶段 306 | 307 | 308 | 57 309 | 00:04:02,809 --> 00:04:05,045 310 | 但是我已经在考虑商业模式 311 | 312 | 313 | 58 314 | 00:04:05,112 --> 00:04:07,181 315 | 以及如何才能 316 | 让我的app实现货币转化 317 | 318 | 319 | 59 320 | 00:04:08,782 --> 00:04:10,784 321 | 由于LiteRight 322 | 将是一个免费app 323 | 324 | 325 | 60 326 | 00:04:11,451 --> 00:04:13,554 327 | 我已决定让它由广告支持 328 | 329 | 330 | 61 331 | 00:04:13,987 --> 00:04:16,723 332 | 以便能立刻开始产生收入 333 | 334 | 335 | 62 336 | 00:04:19,493 --> 00:04:20,827 337 | 而我已经选择iAd 338 | 339 | 340 | 63 341 | 00:04:21,094 --> 00:04:24,798 342 | 作为我的首选广告平台 343 | 来将我的app货币化 344 | 345 | 346 | 64 347 | 00:04:25,465 --> 00:04:27,901 348 | 因为iAd负责整个过程 349 | 350 | 351 | 65 352 | 00:04:28,202 --> 00:04:31,839 353 | 包括找到很好的广告主 提供广告 354 | 355 | 356 | 66 357 | 00:04:32,339 --> 00:04:35,642 358 | 以及为我的app上运行的广告 359 | 提供报告和账单 360 | 361 | 362 | 67 363 | 00:04:37,244 --> 00:04:42,816 364 | 为此iAd直接与我分享 365 | 创造的广告收入的70% 366 | 367 | 368 | 68 369 | 00:04:44,651 --> 00:04:46,653 370 | 而且iAd并不是一个排他性的网络 371 | 372 | 373 | 69 374 | 00:04:47,054 --> 00:04:50,224 375 | 因此我可以与其他广告网络 376 | 和中介伙伴合作 377 | 378 | 379 | 70 380 | 00:04:50,290 --> 00:04:51,391 381 | 只要我选择那么做即可 382 | 383 | 384 | 71 385 | 00:04:52,292 --> 00:04:54,695 386 | 但是因为我在试图将我的收入最大化 387 | 388 | 389 | 72 390 | 00:04:54,828 --> 00:04:58,232 391 | 而且我关注的是高等级 高质量的广告 392 | 393 | 394 | 73 395 | 00:04:58,799 --> 00:05:00,901 396 | 我将把iAd作为我的首选 397 | 398 | 399 | 74 400 | 00:05:04,004 --> 00:05:07,207 401 | 因为我已花费了很多时间 402 | 打造一个美妙的app 403 | 404 | 405 | 75 406 | 00:05:07,441 --> 00:05:09,977 407 | 所以在我的app上的广告 408 | 也应该是同样美妙的 409 | 410 | 411 | 76 412 | 00:05:11,378 --> 00:05:12,212 413 | 为了实现这个目的 414 | 415 | 416 | 77 417 | 00:05:12,513 --> 00:05:15,616 418 | iAd与一些顶尖的创意机构合作 419 | 420 | 421 | 78 422 | 00:05:15,716 --> 00:05:20,020 423 | 以实现来自于世界最受认可品牌的 424 | 425 | 426 | 79 427 | 00:05:20,420 --> 00:05:23,290 428 | 高生产价值的广告 429 | 430 | 431 | 80 432 | 00:05:24,825 --> 00:05:29,830 433 | 此外 每条广告都经过 434 | iAd团队的审核和认证 435 | 436 | 437 | 81 438 | 00:05:30,163 --> 00:05:33,166 439 | 因此我能确定 440 | 出现在我的app上的广告 441 | 442 | 443 | 82 444 | 00:05:33,567 --> 00:05:35,569 445 | 均遵从苹果公司的创意准则 446 | 447 | 448 | 83 449 | 00:05:37,171 --> 00:05:41,942 450 | 而且我可以用关键词 451 | 和iTunes URL屏蔽任何广告 452 | 453 | 454 | 84 455 | 00:05:43,277 --> 00:05:46,180 456 | 所有这些都有助于创造良好的用户体验 457 | 458 | 459 | 85 460 | 00:05:49,683 --> 00:05:52,186 461 | LiteRight 462 | 将是一个全球化的app 463 | 464 | 465 | 86 466 | 00:05:52,553 --> 00:05:56,757 467 | 意味着我的用户将在世界各地 468 | iAd也将是全球化的 469 | 470 | 471 | 87 472 | 00:05:57,691 --> 00:06:01,929 473 | 能够触及100多个国家的iOS用户 474 | 475 | 476 | 88 477 | 00:06:04,565 --> 00:06:05,999 478 | 而谈到用户 479 | 480 | 481 | 89 482 | 00:06:06,567 --> 00:06:11,805 483 | iAd解决方案是具有隐私意识的 484 | 内置了隐私管理 485 | 486 | 487 | 90 488 | 00:06:12,639 --> 00:06:15,742 489 | 意味着我的用户数据是高度安全的 490 | 491 | 492 | 91 493 | 00:06:16,109 --> 00:06:18,212 494 | 而且绝不会与第三方共享 495 | 496 | 497 | 92 498 | 00:06:18,745 --> 00:06:20,614 499 | 这一点会得到用户的欣赏 500 | 501 | 502 | 93 503 | 00:06:21,682 --> 00:06:23,450 504 | 由于与iOS的深度集成 505 | 506 | 507 | 94 508 | 00:06:23,750 --> 00:06:29,156 509 | 它遵从“限制广告跟踪”策略 510 | 而且由iAd自动管理 511 | 512 | 513 | 95 514 | 00:06:32,860 --> 00:06:36,029 515 | 而且由于iAd被置到iOS框架内 516 | 517 | 518 | 96 519 | 00:06:36,830 --> 00:06:40,167 520 | 将其集成到我的app内 521 | 是快速而简单的 522 | 523 | 524 | 97 525 | 00:06:40,868 --> 00:06:47,341 526 | 没有额外的SDK和静态库 527 | 或第三方头文件让我的项目乱成一团 528 | 529 | 530 | 98 531 | 00:06:48,141 --> 00:06:50,844 532 | 以极少的代码我就可以让它启动 533 | 534 | 535 | 99 536 | 00:06:51,979 --> 00:06:55,716 537 | 也有文稿和示例代码为我一路提供帮助 538 | 539 | 540 | 100 541 | 00:06:58,886 --> 00:07:01,088 542 | 这里是iAd提供的所有广告格式 543 | 544 | 545 | 101 546 | 00:07:02,155 --> 00:07:05,058 547 | 我可以集成其中的一种或多种广告格式 548 | 549 | 550 | 102 551 | 00:07:05,125 --> 00:07:09,463 552 | 取决于哪种能够 553 | 使我的app内容和体验更完美 554 | 555 | 556 | 103 557 | 00:07:12,132 --> 00:07:15,435 558 | 横幅广告通常出现在app底部 559 | 560 | 561 | 104 562 | 00:07:17,938 --> 00:07:22,643 563 | 中等矩形广告适合被内嵌到 564 | 有大量内容的app中 565 | 566 | 567 | 105 568 | 00:07:25,612 --> 00:07:30,017 569 | 前置式视频广告最适合 570 | 主要提供视频的app 571 | 572 | 573 | 106 574 | 00:07:32,319 --> 00:07:35,656 575 | 而插播式广告适合 576 | 有良好逻辑过渡的app 577 | 578 | 579 | 107 580 | 00:07:35,722 --> 00:07:38,225 581 | 比如在游戏中 582 | 当用户等级提升的时候 583 | 584 | 585 | 108 586 | 00:07:41,295 --> 00:07:44,865 587 | 而作为即将推出的特性 588 | iAd将支持前置式视频广告 589 | 590 | 591 | 109 592 | 00:07:45,566 --> 00:07:49,369 593 | 它是另一个帮助进一步提高 594 | 我的app的货币化水平的途径 595 | 596 | 597 | 110 598 | 00:07:54,141 --> 00:07:57,611 599 | 现在让我们看一下如何将iAd集成 600 | 到我的LiteRight app内 601 | 602 | 603 | 111 604 | 00:07:59,847 --> 00:08:04,184 605 | 对于LiteRight 606 | 我将在图库屏幕上加入横幅广告 607 | 608 | 609 | 112 610 | 00:08:04,918 --> 00:08:08,088 611 | 并在每隔两次用户分享照片后 612 | 加入一个插播式广告 613 | 614 | 615 | 113 616 | 00:08:10,624 --> 00:08:14,828 617 | 对于横幅广告 618 | 我需链接到iAd框架并导入iAd库 619 | 620 | 621 | 114 622 | 00:08:15,462 --> 00:08:17,998 623 | 使其成为我项目的一部分 624 | 625 | 626 | 115 627 | 00:08:20,501 --> 00:08:22,503 628 | 然后我将需要配置视图控件 629 | 630 | 631 | 116 632 | 00:08:22,569 --> 00:08:24,972 633 | 以致于不管我希望 634 | 让横幅广告出现在哪里 635 | 636 | 637 | 117 638 | 00:08:25,339 --> 00:08:28,041 639 | 我都将把can Display Banner Ads 640 | 设为true 641 | 642 | 643 | 118 644 | 00:08:28,542 --> 00:08:32,044 645 | 进行此设置的一个好处是 646 | 在view Did Load回调中 647 | 648 | 649 | 119 650 | 00:08:33,547 --> 00:08:35,649 651 | iAd将负责处理视图 652 | 653 | 654 | 120 655 | 00:08:35,716 --> 00:08:38,452 656 | 以便让横幅广告以动画形式 657 | 出现在屏幕上 658 | 659 | 660 | 121 661 | 00:08:38,519 --> 00:08:40,854 662 | 并相应地让我的内容框架发生折叠 663 | 664 | 665 | 122 666 | 00:08:44,358 --> 00:08:46,593 667 | 设置完成之后 668 | 这就是它可能的样子 669 | 670 | 671 | 123 672 | 00:08:50,330 --> 00:08:52,766 673 | 与横幅广告不同的是 674 | 让我的app显示插播式广告 675 | 676 | 677 | 124 678 | 00:08:52,833 --> 00:08:54,902 679 | 需要更多一点设置 680 | 681 | 682 | 125 683 | 00:08:56,336 --> 00:08:57,371 684 | 在app Delegate里 685 | 686 | 687 | 126 688 | 00:08:57,437 --> 00:09:01,542 689 | 在application Did Finish Launching 690 | with Options 回调中 691 | 692 | 693 | 127 694 | 00:09:02,976 --> 00:09:04,611 695 | 我需要让iAd服务器知道 696 | 697 | 698 | 128 699 | 00:09:04,678 --> 00:09:07,247 700 | 我的app将通过 701 | 702 | 703 | 129 704 | 00:09:07,881 --> 00:09:10,584 705 | prepare Interstitial Ads调用 706 | 请求一个插播式广告 707 | 708 | 709 | 130 710 | 00:09:13,554 --> 00:09:16,490 711 | 而在视图控件内 712 | 就在插播式广告之前 713 | 714 | 715 | 131 716 | 00:09:16,623 --> 00:09:18,392 717 | 我可以设置显示方式 718 | 719 | 720 | 132 721 | 00:09:18,792 --> 00:09:22,029 722 | 以便让插播式广告 723 | 刚好出现在下一个屏幕之前 724 | 725 | 726 | 133 727 | 00:09:23,096 --> 00:09:26,700 728 | prepare For Segue 729 | 是进行该设置的最佳地方 730 | 731 | 732 | 134 733 | 00:09:29,937 --> 00:09:31,138 734 | iAd让这个工作变得简单 735 | 736 | 737 | 135 738 | 00:09:31,872 --> 00:09:32,739 739 | 我所需要的不过是 740 | 741 | 742 | 136 743 | 00:09:32,806 --> 00:09:36,310 744 | 将插播式广告的显示策略 745 | 设置为“自动” 746 | 747 | 748 | 137 749 | 00:09:36,810 --> 00:09:41,682 750 | 而这让iAd在视图控件内 751 | 显示插播式广告 752 | 753 | 754 | 138 755 | 00:09:45,052 --> 00:09:47,221 756 | 当我完成设置后 757 | 我会看到它会是的样子 758 | 759 | 760 | 139 761 | 00:09:49,122 --> 00:09:51,992 762 | 我已向您展示了如何集成 763 | 横幅和插播式广告 764 | 765 | 766 | 140 767 | 00:09:52,359 --> 00:09:55,229 768 | 但是集成其他格式的广告也同样简单 769 | 770 | 771 | 141 772 | 00:09:56,396 --> 00:10:00,400 773 | 而iAd有一些工具 774 | 让我对集成效果进行测试 775 | 776 | 777 | 142 778 | 00:10:00,467 --> 00:10:03,770 779 | 因此我能确保在发布之前 780 | 已经正确执行了所有操作 781 | 782 | 783 | 143 784 | 00:10:05,772 --> 00:10:07,207 785 | 对于你们中的一些人 786 | 787 | 788 | 144 789 | 00:10:07,541 --> 00:10:10,310 790 | 在这个阶段仍可能 791 | 有一些app开发工作 792 | 793 | 794 | 145 795 | 00:10:11,044 --> 00:10:15,816 796 | 但是既然我已经在早期花时间 797 | 将iAd整合到我的开发周期内 798 | 799 | 800 | 146 801 | 00:10:16,283 --> 00:10:19,052 802 | 所以我不必担心 803 | 日后回来再继续开发工作 804 | 805 | 806 | 147 807 | 00:10:19,486 --> 00:10:22,890 808 | 而且一旦我发布了app 809 | 就可以开始创造年收入了 810 | 811 | 812 | 148 813 | 00:10:26,593 --> 00:10:28,595 814 | 那么现在我们已经 815 | 发布了LiteRight 816 | 817 | 818 | 149 819 | 00:10:29,997 --> 00:10:31,532 820 | 它目前就在App Store中 821 | 822 | 823 | 150 824 | 00:10:31,632 --> 00:10:33,901 825 | 用户正在下载和使用这个app 826 | 827 | 828 | 151 829 | 00:10:36,136 --> 00:10:39,173 830 | 而且基于刚才我为大家展示的集成操作 831 | 广告也正在其中运行 832 | 833 | 834 | 152 835 | 00:10:39,573 --> 00:10:42,809 836 | 这里是一个横幅广告 837 | 和一个插播式广告的例子 838 | 839 | 840 | 153 841 | 00:10:45,913 --> 00:10:49,516 842 | 而且我可以看到在我的app中 843 | 我从广告创造了多少收入 844 | 845 | 846 | 154 847 | 00:10:50,150 --> 00:10:52,920 848 | 只须查看iTunes Connect 849 | 中的报告入口 850 | 851 | 852 | 155 853 | 00:10:53,353 --> 00:10:57,357 854 | 或使用即将推出的 855 | 发布者报告API即可 856 | 857 | 858 | 156 859 | 00:10:59,293 --> 00:11:03,664 860 | 因为我已经在早期投入精力 861 | 将iAd集成到了我的开发周期内 862 | 863 | 864 | 157 865 | 00:11:04,064 --> 00:11:05,399 866 | 它已经在产生回报 867 | 868 | 869 | 158 870 | 00:11:09,336 --> 00:11:11,939 871 | 现在让我们看一下如何 872 | 进行其他聪明的 873 | 874 | 875 | 159 876 | 00:11:12,339 --> 00:11:14,174 877 | 将会扩大我的app安装基础的投入 878 | 879 | 880 | 160 881 | 00:11:18,278 --> 00:11:21,715 882 | 那么我将通过在app中展示广告 883 | 而获得稳定的收入流水 884 | 885 | 886 | 161 887 | 00:11:22,749 --> 00:11:27,054 888 | 您们中的一些不会选择以这种方式 889 | 将您的app货币化这也是没问题的 890 | 891 | 892 | 162 893 | 00:11:28,222 --> 00:11:34,428 894 | 然而 您们多数人关心推动用户下载 895 | 以及对您的app的使用 896 | 897 | 898 | 163 899 | 00:11:36,530 --> 00:11:40,200 900 | 而为了达到目标 901 | 您需要积极地投入精力推广您的app 902 | 903 | 904 | 164 905 | 00:11:40,434 --> 00:11:42,669 906 | 这也是 907 | 我在LiteRight上将要做的 908 | 909 | 910 | 165 911 | 00:11:44,571 --> 00:11:46,273 912 | 我的成长战略的一部分是 913 | 914 | 915 | 166 916 | 00:11:46,340 --> 00:11:49,943 917 | 将我通过在app中展示广告 918 | 赚取的一些收入 919 | 920 | 921 | 167 922 | 00:11:50,477 --> 00:11:53,614 923 | 重新投入到市场营销活动中 924 | 来推广LiteRight 925 | 926 | 927 | 168 928 | 00:11:54,047 --> 00:11:55,716 929 | 以便扩大我的用户基础 930 | 931 | 932 | 169 933 | 00:11:57,150 --> 00:12:00,521 934 | 随着更多的人发现 下载 935 | 并使用我的app 936 | 937 | 938 | 170 939 | 00:12:01,288 --> 00:12:03,724 940 | 也会有更多的人 941 | 接触到我的app中的广告 942 | 943 | 944 | 171 945 | 00:12:04,324 --> 00:12:07,027 946 | 这将进一步提高货币化的程度 947 | 948 | 949 | 172 950 | 00:12:07,794 --> 00:12:09,897 951 | 而这也将创造一个持续的循环 952 | 953 | 954 | 173 955 | 00:12:11,398 --> 00:12:15,602 956 | 因此我既可以进行货币化 957 | 也可以进行推广 958 | 959 | 960 | 174 961 | 00:12:16,603 --> 00:12:20,040 962 | 但是经验表明 963 | 当我两者都做的话会是最成功的 964 | 965 | 966 | 175 967 | 00:12:22,009 --> 00:12:24,778 968 | 刚才我们谈了 969 | 如何使用iAd进行货币化 970 | 971 | 972 | 176 973 | 00:12:26,680 --> 00:12:27,548 974 | 现在让我们谈谈 975 | 976 | 977 | 177 978 | 00:12:27,614 --> 00:12:30,784 979 | 如何使用iAd对我的app 980 | 进行推广并驱动增长 981 | 982 | 983 | 178 984 | 00:12:34,788 --> 00:12:37,558 985 | 我的LiteRight推广计划 986 | 分为两个方向 987 | 988 | 989 | 179 990 | 00:12:38,759 --> 00:12:41,662 991 | 首先 我需要获取新的用户 992 | 993 | 994 | 180 995 | 00:12:42,663 --> 00:12:45,999 996 | 因为App Store里 997 | 有超过150万的app 998 | 999 | 1000 | 181 1001 | 00:12:46,066 --> 00:12:50,204 1002 | 我需要某种途径 1003 | 让我的app脱颖而出被人发现 1004 | 1005 | 1006 | 182 1007 | 00:12:51,972 --> 00:12:56,510 1008 | 为此我将积极推广LiteRight 1009 | 并为我的app创造知名度 1010 | 1011 | 1012 | 183 1013 | 00:12:58,478 --> 00:13:02,850 1014 | iAd有帮助我推广app的工具 1015 | 无须任何额外代码 1016 | 1017 | 1018 | 184 1019 | 00:13:03,684 --> 00:13:05,752 1020 | 我们将在稍后的讲座中 1021 | 为您展示如何做到 1022 | 1023 | 1024 | 185 1025 | 00:13:07,454 --> 00:13:10,057 1026 | 而且根据 1027 | 我从其他app上学到的经验 1028 | 1029 | 1030 | 186 1031 | 00:13:10,891 --> 00:13:13,727 1032 | 我不能只关注获得新用户 1033 | 1034 | 1035 | 187 1036 | 00:13:16,029 --> 00:13:20,767 1037 | 我也要吸引已下载我的app的 1038 | 现有用户的注意力 1039 | 1040 | 1041 | 188 1042 | 00:13:21,235 --> 00:13:25,706 1043 | 因为四分之一被下载的app 1044 | 永远不会被使用 1045 | 1046 | 1047 | 189 1048 | 00:13:26,673 --> 00:13:32,479 1049 | 而且在下载了某个app的一周后 1050 | 只有32%的用户会继续使用它 1051 | 1052 | 1053 | 190 1054 | 00:13:34,581 --> 00:13:37,284 1055 | 为了有效地吸引那些 1056 | 已经下载的用户的注意力 1057 | 1058 | 1059 | 191 1060 | 00:13:37,851 --> 00:13:40,521 1061 | 我需要了解他们是哪类用户 1062 | 1063 | 1064 | 192 1065 | 00:13:41,321 --> 00:13:45,225 1066 | 以便让我能量身定做营销信息 1067 | 并相应地定向投放我的广告开支 1068 | 1069 | 1070 | 193 1071 | 00:13:46,560 --> 00:13:51,298 1072 | 为此我将需要根据我的用户 1073 | 在我的app中的行为对他们进行划分 1074 | 1075 | 1076 | 194 1077 | 00:13:53,133 --> 00:13:56,069 1078 | iAd让我建立数百个受众分组 1079 | 1080 | 1081 | 195 1082 | 00:13:57,271 --> 00:14:01,074 1083 | 但是开始时我将只把用户 1084 | 分为两个自定义组 1085 | 1086 | 1087 | 196 1088 | 00:14:02,476 --> 00:14:06,547 1089 | 一组是休眠用户 1090 | 指的是那些已下载但是不再积极的用户 1091 | 1092 | 1093 | 197 1094 | 00:14:07,281 --> 00:14:10,184 1095 | 对于他们我打算 1096 | 通过特价促销进行推广 1097 | 1098 | 1099 | 198 1100 | 00:14:12,252 --> 00:14:14,454 1101 | 另一组是初学者安装包购买组 1102 | 1103 | 1104 | 199 1105 | 00:14:14,922 --> 00:14:18,425 1106 | 这些是已购买了我app中 1107 | 滤镜初学者安装包的用户 1108 | 1109 | 1110 | 200 1111 | 00:14:19,393 --> 00:14:22,629 1112 | 对于他们 我打算 1113 | 推广我们的白金滤镜安装包 1114 | 1115 | 1116 | 201 1117 | 00:14:24,765 --> 00:14:26,767 1118 | 如果要创建一个自定义受众组 1119 | 1120 | 1121 | 202 1122 | 00:14:26,967 --> 00:14:31,071 1123 | 让我们看一下如何将受众分组代码 1124 | 集成到我的app中 1125 | 1126 | 1127 | 203 1128 | 00:14:31,438 --> 00:14:33,440 1129 | 使其作为对我的app的下一个更新 1130 | 1131 | 1132 | 204 1133 | 00:14:34,374 --> 00:14:37,277 1134 | 我将以初学者安装包购买组为例 1135 | 1136 | 1137 | 205 1138 | 00:14:40,747 --> 00:14:45,719 1139 | 首先 1140 | 我将查看用户是否购买了初学者滤镜 1141 | 1142 | 1143 | 206 1144 | 00:14:45,786 --> 00:14:50,891 1145 | 意味着我应该把他们添加到 1146 | 初学者安装包购买组 1147 | 1148 | 1149 | 207 1150 | 00:14:53,527 --> 00:14:56,129 1151 | 然后我需要获得 1152 | 对共享客户端的引用 1153 | 1154 | 1155 | 208 1156 | 00:14:57,431 --> 00:15:01,568 1157 | 接下来我需要告诉iAd 1158 | 要把用户添加到哪些分组 1159 | 1160 | 1161 | 209 1162 | 00:15:01,835 --> 00:15:05,606 1163 | 实现的途径就是跟踪那些 1164 | 已经购买初学者滤镜安装包的用户行为 1165 | 1166 | 1167 | 210 1168 | 00:15:08,108 --> 00:15:12,346 1169 | 我可以通过调用 1170 | add Client To Segments实现 1171 | 1172 | 1173 | 211 1174 | 00:15:13,046 --> 00:15:14,882 1175 | 这个方法使用了两个参数 1176 | 1177 | 1178 | 212 1179 | 00:15:16,550 --> 00:15:17,384 1180 | 第一个 1181 | 1182 | 1183 | 213 1184 | 00:15:17,584 --> 00:15:22,022 1185 | 是我从iAd WorkBench 1186 | 工具获取的分组ID 1187 | 1188 | 1189 | 214 1190 | 00:15:23,323 --> 00:15:26,026 1191 | 如果我试图发送一些随机分组ID 1192 | 1193 | 1194 | 215 1195 | 00:15:26,593 --> 00:15:27,594 1196 | 它们将会被忽略 1197 | 1198 | 1199 | 216 1200 | 00:15:27,761 --> 00:15:31,265 1201 | 因此我必须从 1202 | iAd WorkBench获取它们 1203 | 1204 | 1205 | 217 1206 | 00:15:31,331 --> 00:15:33,967 1207 | 而我们将在今天的演示的 1208 | 稍晚时候向您展示从哪里获取 1209 | 1210 | 1211 | 218 1212 | 00:15:36,904 --> 00:15:37,738 1213 | 第二步 1214 | 1215 | 1216 | 219 1217 | 00:15:37,804 --> 00:15:40,741 1218 | 我将把replace existing 1219 | 设为false 1220 | 1221 | 1222 | 220 1223 | 00:15:41,141 --> 00:15:46,146 1224 | 因为我不希望这些用户 1225 | 被从他们在的任何分组中移除 1226 | 1227 | 1228 | 221 1229 | 00:15:48,615 --> 00:15:51,952 1230 | 现在既然我已经完成了 1231 | 适当的用户分组准备工作 1232 | 1233 | 1234 | 222 1235 | 00:15:52,753 --> 00:15:56,123 1236 | 我已准备好为LiteRight 1237 | 执行我的推广计划 1238 | 1239 | 1240 | 223 1241 | 00:15:57,291 --> 00:15:59,793 1242 | 为此 1243 | 我将使用iAd WorkBench 1244 | 1245 | 1246 | 224 1247 | 00:16:00,928 --> 00:16:04,531 1248 | iAd的自助推广管理工具 1249 | 1250 | 1251 | 225 1252 | 00:16:05,999 --> 00:16:12,806 1253 | 它让我全面控制我的app推广活动的 1254 | 创建 管理和优化 1255 | 1256 | 1257 | 226 1258 | 00:16:13,440 --> 00:16:15,442 1259 | 而且可以让我获取全面的报告 1260 | 1261 | 1262 | 227 1263 | 00:16:19,279 --> 00:16:25,419 1264 | 这里您可以看到我已经创建了 1265 | 一些推广活动用以执行我的推广计划 1266 | 1267 | 1268 | 228 1269 | 00:16:25,919 --> 00:16:29,656 1270 | 以便获得新用户 1271 | 并重新吸引休眠用户 1272 | 1273 | 1274 | 229 1275 | 00:16:31,191 --> 00:16:33,160 1276 | 接下来我们将使用 1277 | iAd WorkBench 1278 | 1279 | 1280 | 230 1281 | 00:16:33,227 --> 00:16:37,064 1282 | 再次将我的初学者安装包 1283 | 购买受众组作为推广对象 1284 | 1285 | 1286 | 231 1287 | 00:16:37,331 --> 00:16:39,533 1288 | 来推广我的白金滤镜安装包 1289 | 1290 | 1291 | 232 1292 | 00:16:40,334 --> 00:16:44,671 1293 | 对于此活动 1294 | 我们将从用户点击广告开始 1295 | 1296 | 1297 | 233 1298 | 00:16:45,005 --> 00:16:47,608 1299 | 直接将他们带入我的app中的页面 1300 | 1301 | 1302 | 234 1303 | 00:16:48,008 --> 00:16:49,910 1304 | 在那里他们可以进行app内购买 1305 | 1306 | 1307 | 235 1308 | 00:16:51,178 --> 00:16:53,580 1309 | 而我将 1310 | 交由 莎尚克 来进行演示 1311 | 1312 | 1313 | 236 1314 | 00:16:56,016 --> 00:16:56,850 1315 | 谢谢 1316 | 1317 | 1318 | 237 1319 | 00:17:02,356 --> 00:17:03,190 1320 | 谢谢 卡洛 1321 | 1322 | 1323 | 238 1324 | 00:17:03,891 --> 00:17:04,858 1325 | 大家上午好 1326 | 1327 | 1328 | 239 1329 | 00:17:05,092 --> 00:17:07,694 1330 | 我叫莎尚克·珐德克 1331 | 是iAd团队的一员 1332 | 1333 | 1334 | 240 1335 | 00:17:08,996 --> 00:17:12,965 1336 | 今天我将展示iAd WorkBench中 1337 | 两大令人惊叹的特性 1338 | 1339 | 1340 | 241 1341 | 00:17:13,700 --> 00:17:18,372 1342 | 首先我将向您展示 1343 | 您在哪里可以查看并管理您的受众组 1344 | 1345 | 1346 | 242 1347 | 00:17:19,606 --> 00:17:21,675 1348 | 其次我想向您展示 1349 | 1350 | 1351 | 243 1352 | 00:17:21,742 --> 00:17:25,579 1353 | 将那些受众组作为对象进行再次推广 1354 | 1355 | 1356 | 244 1357 | 00:17:26,079 --> 00:17:27,981 1358 | 是多么的容易 1359 | 1360 | 1361 | 245 1362 | 00:17:28,549 --> 00:17:29,550 1363 | 那么让我们开始 1364 | 1365 | 1366 | 246 1367 | 00:17:38,825 --> 00:17:42,196 1368 | 当我登入iAd WorkBench 1369 | 就会看到我的控制面板 1370 | 1371 | 1372 | 247 1373 | 00:17:42,963 --> 00:17:47,334 1374 | 在这里您可以看到 1375 | 您的所有app上的推广活动 1376 | 1377 | 1378 | 248 1379 | 00:17:49,369 --> 00:17:51,438 1380 | 为了查看您的受众组 1381 | 1382 | 1383 | 249 1384 | 00:17:52,072 --> 00:17:57,511 1385 | 您可以使用页面右侧的下拉式菜单 1386 | 转到my audiences页面 1387 | 1388 | 1389 | 250 1390 | 00:17:58,912 --> 00:18:01,915 1391 | 这里在 1392 | my audiences页面上 1393 | 1394 | 1395 | 251 1396 | 00:18:02,783 --> 00:18:07,821 1397 | 您可以看到在您的各个app上 1398 | 所定义的所有受众组 1399 | 1400 | 1401 | 252 1402 | 00:18:10,190 --> 00:18:12,392 1403 | 对于您创建的每个受众组 1404 | 1405 | 1406 | 253 1407 | 00:18:12,960 --> 00:18:16,763 1408 | iAd WorkBench 1409 | 分配一个独一无二的组ID 1410 | 1411 | 1412 | 254 1413 | 00:18:18,332 --> 00:18:22,002 1414 | 比如 对于LiteRight 1415 | 初学者安装包购买 1416 | 1417 | 1418 | 255 1419 | 00:18:22,369 --> 00:18:25,572 1420 | 这是iAd WorkBench 1421 | 分配给我的组ID 1422 | 1423 | 1424 | 256 1425 | 00:18:26,807 --> 00:18:31,245 1426 | 这是您在代码中用于向该组提交指示 1427 | 1428 | 1429 | 257 1430 | 00:18:31,545 --> 00:18:34,181 1431 | 并开始添加用户的ID 1432 | 1433 | 1434 | 258 1435 | 00:18:36,350 --> 00:18:38,552 1436 | 通过那种方法我可以看到 1437 | 1438 | 1439 | 259 1440 | 00:18:38,619 --> 00:18:45,192 1441 | 在我的初学者安装包购买组 1442 | 已经有了一万多个用户 1443 | 1444 | 1445 | 260 1446 | 00:18:48,896 --> 00:18:53,400 1447 | 当然 随着越来越多的用户 1448 | 下载我的初学者安装包 1449 | 1450 | 1451 | 261 1452 | 00:18:53,867 --> 00:18:55,435 1453 | 这个数字将持续更新 1454 | 1455 | 1456 | 262 1457 | 00:18:57,838 --> 00:19:01,041 1458 | 现在让我们看下如何利用这个组 1459 | 1460 | 1461 | 263 1462 | 00:19:01,542 --> 00:19:06,146 1463 | 为我的最新白金滤镜安装包 1464 | 做一个再次定向推广活动 1465 | 1466 | 1467 | 264 1468 | 00:19:09,516 --> 00:19:12,853 1469 | 为此 我回到控制面板 1470 | 1471 | 1472 | 265 1473 | 00:19:13,620 --> 00:19:18,225 1474 | 并点击create campaign 1475 | 按钮来启动这个活动 1476 | 1477 | 1478 | 266 1479 | 00:19:21,595 --> 00:19:25,399 1480 | 我要选择我希望 1481 | 推广一个app或是产品 1482 | 1483 | 1484 | 267 1485 | 00:19:25,966 --> 00:19:28,535 1486 | 在此例中 我将推广我的app 1487 | 因此我选择"app" 1488 | 1489 | 1490 | 268 1491 | 00:19:30,270 --> 00:19:33,540 1492 | 正如您所看到的 1493 | 我的所有app都已被列出 1494 | 1495 | 1496 | 269 1497 | 00:19:34,608 --> 00:19:36,643 1498 | 我为这次活动选择LiteRight 1499 | 1500 | 1501 | 270 1502 | 00:19:38,612 --> 00:19:42,049 1503 | 然后我要选择是否希望在app网络 1504 | 或iTunes Radio上 1505 | 1506 | 1507 | 271 1508 | 00:19:42,783 --> 00:19:45,452 1509 | 推广并运行此广告 1510 | 1511 | 1512 | 272 1513 | 00:19:46,520 --> 00:19:47,888 1514 | 我选择app网络 1515 | 1516 | 1517 | 273 1518 | 00:19:48,155 --> 00:19:55,028 1519 | 而且我看到我的广告 1520 | 将在已经支持它的100多个国家运行 1521 | 1522 | 1523 | 274 1524 | 00:19:57,431 --> 00:19:59,366 1525 | 接下来我要选择 1526 | 我的出价类型 1527 | 1528 | 1529 | 275 1530 | 00:20:00,901 --> 00:20:04,905 1531 | CPC 1532 | 即按照每次点击计费 1533 | 1534 | 1535 | 276 1536 | 00:20:05,439 --> 00:20:07,441 1537 | 或CPM 1538 | 即按照每千次展示计费 1539 | 1540 | 1541 | 277 1542 | 00:20:08,809 --> 00:20:09,643 1543 | 对于此次活动 1544 | 1545 | 1546 | 278 1547 | 00:20:09,710 --> 00:20:14,114 1548 | 因为我只想当用户 1549 | 点击我的横幅广告时我才付费 1550 | 1551 | 1552 | 279 1553 | 00:20:14,314 --> 00:20:15,549 1554 | 所以我将选择CPC 1555 | 1556 | 1557 | 280 1558 | 00:20:17,251 --> 00:20:21,522 1559 | 让我们把这个活动命名为 1560 | 1561 | 1562 | 281 1563 | 00:20:23,190 --> 00:20:24,858 1564 | LiteRight白金推广活动 1565 | 1566 | 1567 | 282 1568 | 00:20:29,096 --> 00:20:32,900 1569 | 接下来我会看到 1570 | 此推广活动的规则列表 1571 | 1572 | 1573 | 283 1574 | 00:20:33,400 --> 00:20:34,401 1575 | 我还没有任何规则 1576 | 1577 | 1578 | 284 1579 | 00:20:35,169 --> 00:20:37,738 1580 | 那么让我向您展示如何创建规则 1581 | 1582 | 1583 | 285 1584 | 00:20:38,405 --> 00:20:39,940 1585 | 点击创建规则按钮 1586 | 1587 | 1588 | 286 1589 | 00:20:41,708 --> 00:20:45,445 1590 | 首先我选择希望这个广告 1591 | 在哪个国家运行 1592 | 1593 | 1594 | 287 1595 | 00:20:47,080 --> 00:20:48,282 1596 | 我选择美国 1597 | 1598 | 1599 | 288 1600 | 00:20:49,416 --> 00:20:51,852 1601 | 而现在对于我的白金滤镜安装包 1602 | 1603 | 1604 | 289 1605 | 00:20:52,586 --> 00:20:58,458 1606 | 我想特别针对那些 1607 | 已经下载了初学者安装包的用户 1608 | 1609 | 1610 | 290 1611 | 00:20:59,760 --> 00:21:04,798 1612 | 在此例中我将把 1613 | “再次定向推广”选项 1614 | 1615 | 1616 | 291 1617 | 00:21:07,801 --> 00:21:12,105 1618 | 选择为yes 1619 | 如您所见我的所有受众组都已在此列出 1620 | 1621 | 1622 | 292 1623 | 00:21:12,973 --> 00:21:16,043 1624 | 这与我们在my audiences 1625 | 看到的相同视图 1626 | 1627 | 1628 | 293 1629 | 00:21:17,044 --> 00:21:17,945 1630 | 对于此次推广活动 1631 | 1632 | 1633 | 294 1634 | 00:21:18,011 --> 00:21:23,417 1635 | 我想影响一万多个LiteRight 1636 | 初学者安装包的购买者 1637 | 1638 | 1639 | 295 1640 | 00:21:23,550 --> 00:21:24,518 1641 | 因此我将选择它 1642 | 1643 | 1644 | 296 1645 | 00:21:26,954 --> 00:21:29,256 1646 | 除了受众组外 1647 | 1648 | 1649 | 297 1650 | 00:21:29,957 --> 00:21:32,492 1651 | 我还可以选择其他定向推广参数 1652 | 1653 | 1654 | 298 1655 | 00:21:33,994 --> 00:21:35,395 1656 | 比如 如果我希望 1657 | 1658 | 1659 | 299 1660 | 00:21:36,530 --> 00:21:40,267 1661 | 我的广告运行在特定的设备上 1662 | iPhone或iPad 1663 | 1664 | 1665 | 300 1666 | 00:21:42,069 --> 00:21:46,740 1667 | 或者我可以选择用户的不同地区 1668 | 1669 | 1670 | 301 1671 | 00:21:48,175 --> 00:21:51,578 1672 | 或者我还可以指定app频道属性 1673 | 1674 | 1675 | 302 1676 | 00:21:52,279 --> 00:21:54,615 1677 | 它是我希望运行的广告 1678 | 1679 | 1680 | 303 1681 | 00:21:54,948 --> 00:21:56,483 1682 | 在iTunes上对app的分类 1683 | 1684 | 1685 | 304 1686 | 00:21:59,086 --> 00:22:01,822 1687 | 或者我可以安排我的广告 1688 | 在特定的时间运行 1689 | 1690 | 1691 | 305 1692 | 00:22:01,889 --> 00:22:03,590 1693 | 一天中的某个时间或一周中的某些天 1694 | 1695 | 1696 | 306 1697 | 00:22:05,626 --> 00:22:08,695 1698 | 在选定了这些定向推广属性之后 1699 | 1700 | 1701 | 307 1702 | 00:22:08,962 --> 00:22:11,465 1703 | 我可以看到我能影响到一万多用户 1704 | 1705 | 1706 | 308 1707 | 00:22:12,232 --> 00:22:16,837 1708 | 它超过了对再次定向推广的 1709 | 最小用户数要求 1710 | 1711 | 1712 | 309 1713 | 00:22:17,137 --> 00:22:18,071 1714 | 因此我是符合要求的 1715 | 1716 | 1717 | 310 1718 | 00:22:20,240 --> 00:22:22,109 1719 | 接下来选择我的广告类型 1720 | 1721 | 1722 | 311 1723 | 00:22:22,543 --> 00:22:23,644 1724 | 它将是一个横幅广告 1725 | 1726 | 1727 | 312 1728 | 00:22:24,511 --> 00:22:27,981 1729 | 而且我将选择 1730 | app深度链接的目标类型 1731 | 1732 | 1733 | 313 1734 | 00:22:28,949 --> 00:22:32,319 1735 | 在下个屏幕上我将为大家 1736 | 讲一下app深度链接 1737 | 1738 | 1739 | 314 1740 | 00:22:33,520 --> 00:22:35,022 1741 | 我选择我的广告运行日期 1742 | 1743 | 1744 | 315 1745 | 00:22:35,722 --> 00:22:38,158 1746 | 让它从明天开始持续一个月 1747 | 1748 | 1749 | 316 1750 | 00:22:40,627 --> 00:22:42,796 1751 | 然后我为推广活动指定我的预算 1752 | 1753 | 1754 | 317 1755 | 00:22:43,997 --> 00:22:46,567 1756 | 我将花费比如说3000美元 1757 | 1758 | 1759 | 318 1760 | 00:22:48,135 --> 00:22:49,870 1761 | 然后输入我的CPC出价 1762 | 1763 | 1764 | 319 1765 | 00:22:51,705 --> 00:22:53,507 1766 | 比如说 50美分 1767 | 1768 | 1769 | 320 1770 | 00:22:54,241 --> 00:22:56,677 1771 | 现在iAd是一个基于拍卖的市场 1772 | 1773 | 1774 | 321 1775 | 00:22:57,544 --> 00:23:01,582 1776 | 因此我明确知道不会付出超过50美分 1777 | 1778 | 1779 | 322 1780 | 00:23:02,616 --> 00:23:04,151 1781 | 实际上 我可以付得更少 1782 | 1783 | 1784 | 323 1785 | 00:23:05,919 --> 00:23:07,054 1786 | 让我们为规则命名 1787 | 1788 | 1789 | 324 1790 | 00:23:13,293 --> 00:23:15,062 1791 | 一旦我定义了规则 1792 | 1793 | 1794 | 325 1795 | 00:23:15,863 --> 00:23:22,503 1796 | 在下个屏幕上我就会看见一个 1797 | 我为此次推广活动定义的规则列表 1798 | 1799 | 1800 | 326 1801 | 00:23:23,136 --> 00:23:24,872 1802 | 如果愿意 您可以定义多个规则 1803 | 1804 | 1805 | 327 1806 | 00:23:25,405 --> 00:23:27,741 1807 | 但是目前暂且让我们先只有一个规则 1808 | 1809 | 1810 | 328 1811 | 00:23:29,243 --> 00:23:30,677 1812 | 点击“下一步” 1813 | 1814 | 1815 | 329 1816 | 00:23:31,979 --> 00:23:33,213 1817 | 开始创建您的广告 1818 | 1819 | 1820 | 330 1821 | 00:23:36,350 --> 00:23:37,584 1822 | 现在为了定义一条广告 1823 | 1824 | 1825 | 331 1826 | 00:23:38,285 --> 00:23:41,722 1827 | 您将定义点击前和点击后的体验 1828 | 1829 | 1830 | 332 1831 | 00:23:42,956 --> 00:23:46,093 1832 | 对于我的广告 1833 | 我想让它在点击前是一个横幅 1834 | 1835 | 1836 | 333 1837 | 00:23:46,793 --> 00:23:50,964 1838 | 我想让广告在所有设备上运行 1839 | iPhones iPads 1840 | 1841 | 1842 | 334 1843 | 00:23:51,131 --> 00:23:52,900 1844 | 因此我将选择 1845 | “universal” 1846 | 1847 | 1848 | 335 1849 | 00:23:54,234 --> 00:23:55,502 1850 | 我选择自己的语言 1851 | 1852 | 1853 | 336 1854 | 00:23:57,437 --> 00:23:58,705 1855 | 而至于创意方面 1856 | 1857 | 1858 | 337 1859 | 00:23:59,907 --> 00:24:03,177 1860 | 我使用iAd WorkBench 1861 | 为我提供的一套 1862 | 1863 | 1864 | 338 1865 | 00:24:03,243 --> 00:24:07,281 1866 | 有不同颜色方案的标准模版 1867 | 1868 | 1869 | 339 1870 | 00:24:08,582 --> 00:24:11,618 1871 | 或者如果我愿意 1872 | 我可以从我的桌面电脑上传图片 1873 | 1874 | 1875 | 340 1876 | 00:24:12,753 --> 00:24:15,722 1877 | 目前让我们快速采用一个标准模版 1878 | 1879 | 1880 | 341 1881 | 00:24:18,425 --> 00:24:20,127 1882 | 我可以给它定一个标题 1883 | 1884 | 1885 | 342 1886 | 00:24:26,033 --> 00:24:29,636 1887 | 一条表明它是我的白金安装包的信息 1888 | 1889 | 1890 | 343 1891 | 00:24:31,271 --> 00:24:32,973 1892 | 以及一条“行为召唤”文本 1893 | 1894 | 1895 | 344 1896 | 00:24:36,510 --> 00:24:37,377 1897 | 如您所见 1898 | 1899 | 1900 | 345 1901 | 00:24:37,611 --> 00:24:42,349 1902 | 我将看到它在设备上 1903 | 将是何种样子的预览 1904 | 1905 | 1906 | 346 1907 | 00:24:42,516 --> 00:24:47,287 1908 | 实际上 1909 | 我可以获得它在所有不同设备上的预览 1910 | 1911 | 1912 | 347 1913 | 00:24:51,291 --> 00:24:55,429 1914 | 现在 我该选择 1915 | 我希望用户在点击后获得什么样的体验 1916 | 1917 | 1918 | 348 1919 | 00:24:57,764 --> 00:24:59,733 1920 | 我将选择app深度链接 1921 | 1922 | 1923 | 349 1924 | 00:25:00,200 --> 00:25:02,870 1925 | 因此在此例中 1926 | 针对我的白金安装包 1927 | 1928 | 1929 | 350 1930 | 00:25:03,337 --> 00:25:05,205 1931 | 每次用户点击横幅的时候 1932 | 1933 | 1934 | 351 1935 | 00:25:05,906 --> 00:25:09,309 1936 | 我都希望我的app在设备上打开 1937 | 1938 | 1939 | 352 1940 | 00:25:09,910 --> 00:25:16,950 1941 | 并把用户直接带到能够购买 1942 | 我的白金滤镜安装包的页面内 1943 | 1944 | 1945 | 353 1946 | 00:25:17,317 --> 00:25:18,285 1947 | 进行app内购买 1948 | 1949 | 1950 | 354 1951 | 00:25:19,987 --> 00:25:24,424 1952 | 为了对此进行配置 1953 | 我需要插入一个深度链接URL 1954 | 1955 | 1956 | 355 1957 | 00:25:26,994 --> 00:25:29,530 1958 | 我插入了我的自定义方案 1959 | 1960 | 1961 | 356 1962 | 00:25:30,397 --> 00:25:34,768 1963 | 我希望直接转到白金滤镜安装包 1964 | 1965 | 1966 | 357 1967 | 00:25:35,302 --> 00:25:39,006 1968 | 在进行app内购买的页面 1969 | 1970 | 1971 | 358 1972 | 00:25:40,774 --> 00:25:44,311 1973 | 现在 大多数时间我的app将被 1974 | 安装到用户的设备上 1975 | 1976 | 1977 | 359 1978 | 00:25:44,645 --> 00:25:45,746 1979 | 但是出于某种原因 1980 | 1981 | 1982 | 360 1983 | 00:25:46,046 --> 00:25:50,817 1984 | 如果app未安装 1985 | 在用户点击横幅之后 1986 | 1987 | 1988 | 361 1989 | 00:25:51,218 --> 00:25:54,821 1990 | 我可以直接把他们带到 1991 | iTunes App Store 1992 | 1993 | 1994 | 362 1995 | 00:25:55,722 --> 00:25:56,890 1996 | 以便重新下载app 1997 | 1998 | 1999 | 363 2000 | 00:25:57,791 --> 00:26:00,894 2001 | 或者如果我希望把他们 2002 | 带到另一个我选择的网站 2003 | 2004 | 2005 | 364 2006 | 00:26:01,094 --> 00:26:01,995 2007 | 我也可以做到 2008 | 2009 | 2010 | 365 2011 | 00:26:02,796 --> 00:26:05,933 2012 | 现在我希望把他们带到下载页 2013 | 2014 | 2015 | 366 2016 | 00:26:11,004 --> 00:26:14,741 2017 | 我将为目标命名 2018 | LiteRight深度链接 2019 | 2020 | 2021 | 367 2022 | 00:26:16,043 --> 00:26:18,946 2023 | 我把创建的规则与这条进行关联 2024 | 2025 | 2026 | 368 2027 | 00:26:20,447 --> 00:26:21,448 2028 | 并为广告命名 2029 | 2030 | 2031 | 369 2032 | 00:26:27,120 --> 00:26:27,988 2033 | 点击"下一步" 2034 | 2035 | 2036 | 370 2037 | 00:26:32,492 --> 00:26:33,460 2038 | 在下一个屏幕上 2039 | 2040 | 2041 | 371 2042 | 00:26:33,794 --> 00:26:37,130 2043 | 您将会看到您已为此推广活动 2044 | 创建的所有广告 2045 | 2046 | 2047 | 372 2048 | 00:26:37,497 --> 00:26:38,665 2049 | 我们只是创建了这条广告 2050 | 2051 | 2052 | 373 2053 | 00:26:39,366 --> 00:26:42,402 2054 | 再次强调 2055 | 如果您愿意 您可以创建更多广告 2056 | 2057 | 2058 | 374 2059 | 00:26:43,337 --> 00:26:45,005 2060 | 但是目前 让我们只保持一条广告 2061 | 2062 | 2063 | 375 2064 | 00:26:47,140 --> 00:26:50,611 2065 | 点击 "下一步" 2066 | 查看您目前为止为此推广活动 2067 | 2068 | 2069 | 376 2070 | 00:26:50,844 --> 00:26:51,812 2071 | 所做的设置的概览 2072 | 2073 | 2074 | 377 2075 | 00:26:52,779 --> 00:26:54,381 2076 | 我可以看到我创建的那条规则 2077 | 2078 | 2079 | 378 2080 | 00:26:54,915 --> 00:26:57,718 2081 | 我可以看到与该条规则关联的广告 2082 | 2083 | 2084 | 379 2085 | 00:26:59,620 --> 00:27:02,122 2086 | 我也可以输入我的付款信息 2087 | 2088 | 2089 | 380 2090 | 00:27:02,656 --> 00:27:04,391 2091 | 因为当我注册的时候 2092 | 2093 | 2094 | 381 2095 | 00:27:04,458 --> 00:27:07,494 2096 | iAd WorkBench已经 2097 | 有了我的信用卡 2098 | 2099 | 2100 | 382 2101 | 00:27:07,561 --> 00:27:08,795 2102 | 因此我将直接使用它 2103 | 2104 | 2105 | 383 2106 | 00:27:10,564 --> 00:27:11,398 2107 | 就是这样 2108 | 2109 | 2110 | 384 2111 | 00:27:11,465 --> 00:27:14,968 2112 | 我可以提交这个推广活动了 2113 | 2114 | 2115 | 385 2116 | 00:27:17,371 --> 00:27:19,039 2117 | 一旦您提交了推广活动 2118 | 2119 | 2120 | 386 2121 | 00:27:19,773 --> 00:27:24,311 2122 | 您所创建的所有广告将 2123 | 通过一个认证流程 2124 | 2125 | 2126 | 387 2127 | 00:27:25,112 --> 00:27:27,548 2128 | 而一旦它们被批准 2129 | 2130 | 2131 | 388 2132 | 00:27:28,482 --> 00:27:31,185 2133 | 而且到了您规则的起始日 2134 | 2135 | 2136 | 389 2137 | 00:27:31,752 --> 00:27:33,220 2138 | 您的推广活动将开始运行 2139 | 2140 | 2141 | 390 2142 | 00:27:33,654 --> 00:27:36,523 2143 | 而且您的广告将开始服务于各种设备上 2144 | 2145 | 2146 | 391 2147 | 00:27:38,825 --> 00:27:41,261 2148 | 现在 让我为您展示 2149 | 在您创建推广活动之后 2150 | 2151 | 2152 | 392 2153 | 00:27:41,762 --> 00:27:44,565 2154 | 您如何监控您的推广活动表现 2155 | 2156 | 2157 | 393 2158 | 00:27:46,166 --> 00:27:50,437 2159 | 我刚运作了一个推广活动 2160 | 2161 | 2162 | 394 2163 | 00:27:50,504 --> 00:27:55,075 2164 | 那么让我点击推广 2165 | 活动选项卡上的分析工具部分 2166 | 2167 | 2168 | 395 2169 | 00:27:55,742 --> 00:27:57,811 2170 | 来到分析工具部分 2171 | 2172 | 2173 | 396 2174 | 00:28:05,586 --> 00:28:07,154 2175 | 分析工具控制面板页面 2176 | 2177 | 2178 | 397 2179 | 00:28:10,490 --> 00:28:15,195 2180 | 这里您可以看到针对此推广活动的 2181 | 各种度量指标 2182 | 2183 | 2184 | 398 2185 | 00:28:16,296 --> 00:28:18,365 2186 | 总花费 总展示数 2187 | 2188 | 2189 | 399 2190 | 00:28:19,399 --> 00:28:21,568 2191 | 总转化率等所有指标 2192 | 2193 | 2194 | 400 2195 | 00:28:23,170 --> 00:28:25,672 2196 | 我还可以按照特定日期范围进行筛选 2197 | 2198 | 2199 | 401 2200 | 00:28:26,740 --> 00:28:28,942 2201 | 对此数据进行切片和切块分析 2202 | 2203 | 2204 | 402 2205 | 00:28:30,477 --> 00:28:35,015 2206 | 或者我可以在活动层面上 2207 | 规则层面上 2208 | 2209 | 2210 | 403 2211 | 00:28:36,416 --> 00:28:38,752 2212 | 甚至广告层面或设备类型层面上 2213 | 查看数据 2214 | 2215 | 2216 | 404 2217 | 00:28:41,755 --> 00:28:45,859 2218 | 在您看到的图表中 2219 | 我可以设计一个特定的度量指标 2220 | 2221 | 2222 | 405 2223 | 00:28:46,159 --> 00:28:51,365 2224 | 比如 我的活动期间的每日开销 2225 | 2226 | 2227 | 406 2228 | 00:28:52,332 --> 00:28:55,669 2229 | 或者我也可以和其他度量指标叠加 2230 | 2231 | 2232 | 407 2233 | 00:28:55,969 --> 00:28:57,671 2234 | 比如 展示次数随时间的变化 2235 | 2236 | 2237 | 408 2238 | 00:28:58,906 --> 00:29:00,741 2239 | 或点击数随时间的变化 2240 | 2241 | 2242 | 409 2243 | 00:29:03,443 --> 00:29:07,114 2244 | 如果我愿意把所有的切片 2245 | 和切块分析拿到线下来做 2246 | 2247 | 2248 | 410 2249 | 00:29:07,681 --> 00:29:12,886 2250 | 我可以一直使用这里的这个图标 2251 | 下载数据 2252 | 2253 | 2254 | 411 2255 | 00:29:16,890 --> 00:29:20,961 2256 | 这些所有的功能和分析报告工具 2257 | 2258 | 2259 | 412 2260 | 00:29:21,929 --> 00:29:26,133 2261 | 我也可以用于iAd的广告API 2262 | 2263 | 2264 | 413 2265 | 00:29:26,667 --> 00:29:27,968 2266 | 如果我愿意的话 2267 | 2268 | 2269 | 414 2270 | 00:29:28,902 --> 00:29:31,605 2271 | 借助iAd WorkBench 2272 | 您还可以做许多其他的事情 2273 | 2274 | 2275 | 415 2276 | 00:29:32,206 --> 00:29:34,141 2277 | 但是现在 2278 | 我要把舞台还给卡洛 2279 | 2280 | 2281 | 416 2282 | 00:29:35,742 --> 00:29:36,577 2283 | 卡洛？ 2284 | 2285 | 2286 | 417 2287 | 00:29:43,517 --> 00:29:44,618 2288 | 谢谢 莎尚克！ 2289 | 2290 | 2291 | 418 2292 | 00:29:45,652 --> 00:29:48,255 2293 | 正如您从iAd WorkBench 2294 | 的演示可以看出 2295 | 2296 | 2297 | 419 2298 | 00:29:48,422 --> 00:29:52,826 2299 | 我对app推广活动的设置和运作 2300 | 拥有完全掌控 2301 | 2302 | 2303 | 420 2304 | 00:29:53,660 --> 00:29:56,997 2305 | 而且在关于报告的几屏页面上 2306 | 我们也能看到我的推广活动的效果 2307 | 2308 | 2309 | 421 2310 | 00:29:58,332 --> 00:30:01,034 2311 | 我不仅能在 2312 | iAd WorkBench内做 2313 | 2314 | 2315 | 422 2316 | 00:30:01,735 --> 00:30:05,105 2317 | 而且也可以使用iAd归因于API 2318 | 2319 | 2320 | 423 2321 | 00:30:05,606 --> 00:30:10,410 2322 | 来衡量效果并跟踪源自于 2323 | iAd推广活动的app下载 2324 | 2325 | 2326 | 424 2327 | 00:30:12,045 --> 00:30:14,248 2328 | 它是ADclient类的一个方法 2329 | 2330 | 2331 | 425 2332 | 00:30:14,915 --> 00:30:17,584 2333 | 叫做lookup Ad Conversion Details 2334 | 2335 | 2336 | 426 2337 | 00:30:17,651 --> 00:30:19,119 2338 | 这将返回两个日期 2339 | 2340 | 2341 | 427 2342 | 00:30:21,388 --> 00:30:25,926 2343 | 第一个是app Download Date 2344 | 即用户下载app的日期 2345 | 2346 | 2347 | 428 2348 | 00:30:28,762 --> 00:30:30,531 2349 | 第二个是 2350 | last Click Date 2351 | 2352 | 2353 | 429 2354 | 00:30:31,164 --> 00:30:36,503 2355 | 这个将是用户购买app之前 2356 | 点击广告的最后日期 2357 | 2358 | 2359 | 430 2360 | 00:30:37,971 --> 00:30:40,641 2361 | 如果两个日期都存在且是真实的 2362 | 2363 | 2364 | 431 2365 | 00:30:41,041 --> 00:30:44,545 2366 | 意味着这次app下载可直接归因于 2367 | 2368 | 2369 | 432 2370 | 00:30:44,678 --> 00:30:49,650 2371 | 一条正在推广我app的iAd互动 2372 | 和对它的点击 2373 | 2374 | 2375 | 433 2376 | 00:30:53,120 --> 00:30:53,987 2377 | 所以 就是那样 2378 | 2379 | 2380 | 434 2381 | 00:30:54,688 --> 00:30:59,259 2382 | 通过这个虚构的LiteRight app 2383 | 开发和发布之旅 2384 | 2385 | 2386 | 435 2387 | 00:31:00,093 --> 00:31:05,933 2388 | 我希望您已经明白如何 2389 | 应用最成功app开发者的最佳实践 2390 | 2391 | 2392 | 436 2393 | 00:31:08,168 --> 00:31:10,137 2394 | 即使早在设计阶段 2395 | 2396 | 2397 | 437 2398 | 00:31:10,537 --> 00:31:12,673 2399 | 他们已经在考虑商业模式 2400 | 2401 | 2402 | 438 2403 | 00:31:12,973 --> 00:31:15,209 2404 | 以及他们将如何使他们的app货币化 2405 | 2406 | 2407 | 439 2408 | 00:31:17,177 --> 00:31:19,346 2409 | 而且仅仅通过几行代码 2410 | 2411 | 2412 | 440 2413 | 00:31:19,413 --> 00:31:22,783 2414 | 您就看到将iAd集成到您的app中 2415 | 2416 | 2417 | 441 2418 | 00:31:23,717 --> 00:31:27,321 2419 | 并早在发布时就开始产生收入 2420 | 是多么的容易 2421 | 2422 | 2423 | 442 2424 | 00:31:30,123 --> 00:31:33,126 2425 | 然后我们谈到了通过精明的投资 2426 | 而向您的用户进行推广 2427 | 2428 | 2429 | 443 2430 | 00:31:33,493 --> 00:31:36,663 2431 | 从而让您的app成长壮大的最佳实践 2432 | 2433 | 2434 | 444 2435 | 00:31:37,431 --> 00:31:41,335 2436 | 如何指示您的app 2437 | 识别和划分您的用户 2438 | 2439 | 2440 | 445 2441 | 00:31:41,702 --> 00:31:45,906 2442 | 从而更好地了解您试图获取的各种受众 2443 | 2444 | 2445 | 446 2446 | 00:31:47,541 --> 00:31:52,479 2447 | 如何通过具有相关性的消息和吸引人 2448 | 的广告体验 对他们进行定向推广 2449 | 2450 | 2451 | 447 2452 | 00:31:53,146 --> 00:31:56,750 2453 | 从而让您的推广活动 2454 | 在驱动下载和app内购买方面 2455 | 2456 | 2457 | 448 2458 | 00:31:56,817 --> 00:31:59,419 2459 | 更加有效 也更加高效 2460 | 2461 | 2462 | 449 2463 | 00:32:00,921 --> 00:32:04,992 2464 | 以及如何利用 2465 | iAd WorkBench和归因API 2466 | 2467 | 2468 | 450 2469 | 00:32:05,325 --> 00:32:08,829 2470 | 对推广活动的有效性 2471 | 进行持续的监控和衡量 2472 | 2473 | 2474 | 451 2475 | 00:32:12,199 --> 00:32:17,104 2476 | 这就是iAd使每个app开发者 2477 | 都是一套了不起的工具的原因 2478 | 2479 | 2480 | 452 2481 | 00:32:18,205 --> 00:32:22,676 2482 | 不管您处于app开发的任何阶段 2483 | 都可以轻易地利用iAd 2484 | 2485 | 2486 | 453 2487 | 00:32:22,976 --> 00:32:25,479 2488 | 以便对您的app的未来的成功 2489 | 产生重大影响 2490 | 2491 | 2492 | 454 2493 | 00:32:26,079 --> 00:32:27,181 2494 | 而同样重要的是 2495 | 2496 | 2497 | 455 2498 | 00:32:27,514 --> 00:32:29,716 2499 | 也对您业务的未来成功产生重大影响 2500 | 2501 | 2502 | 456 2503 | 00:32:31,218 --> 00:32:32,586 2504 | 还有额外一点是 2505 | 2506 | 2507 | 457 2508 | 00:32:34,087 --> 00:32:39,526 2509 | 对于您们中的那些昨天宣布 2510 | 最新新闻app的内容发布者而言 2511 | 2512 | 2513 | 458 2514 | 00:32:40,527 --> 00:32:44,798 2515 | 您将能够利用iAd将您的内容货币化 2516 | 并进行推广 2517 | 2518 | 2519 | 459 2520 | 00:32:46,133 --> 00:32:50,771 2521 | 请访问苹果开发者站点上的 2522 | 新闻发布者页以便了解更多信息 2523 | 2524 | 2525 | 460 2526 | 00:32:52,439 --> 00:32:54,308 2527 | 而若要了解更多关于iAd的信息 2528 | 2529 | 2530 | 461 2531 | 00:32:54,374 --> 00:32:58,312 2532 | 您可以参考iAd开发者指南 2533 | 和iAd开发者论坛 2534 | 2535 | 2536 | 462 2537 | 00:32:58,579 --> 00:33:01,181 2538 | 或联系我们的技术传播者团队 2539 | 2540 | 2541 | 463 2542 | 00:33:03,684 --> 00:33:06,453 2543 | 明天还将会有一场与 2544 | iTunes Connect相关的讲座 2545 | 2546 | 2547 | 464 2548 | 00:33:07,487 --> 00:33:09,690 2549 | 谢谢大家 2550 | 请尽情欣赏大会的剩余内容 2551 | 2552 | --------------------------------------------------------------------------------